From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,640402846afb9f3a,start X-Google-Attributes: gid103376,public From: "Robert C. Leif, Ph.D." Subject: Off the Shelf Software Date: 1996/10/02 Message-ID: <2.2.32.19961002170112.006f8994@mail.cts.com> X-Deja-AN: 186741528 sender: Ada programming language x-sender: rleif@mail.cts.com comments: cc: "Joanna H. Weitershausen" , content-type: text/plain; charset="us-ascii" mime-version: 1.0 newsgroups: comp.lang.ada x-mailer: Windows Eudora Pro Version 2.2 (32) Date: 1996-10-02T00:00:00+00:00 List-Id: From: Bob Leif Vice President Ada_Med As has been obvious from postings to Comp.Lang.Ada and other Ada distribution lists, the Department of Defense (DoD) is favoring the use of commercial off the shelf software. Very recently the US Food and Drug Administration (FDA) has addressed this subject. Please see below. I have also include the comments on Open systems. For the last few years, I have been arguing that the FDA could learn much from the DoD. I believe in this case the FDA can provide good advice to the DoD. The URL where the full document can be obtained is http://www.fda.gov/cdrh/index.html dtswguid.html is the last part of the path. This document has many figures, and therefore it is advisable to have your browser configured to Auto Load Images. ---------------------------------------------------------------------------- ------------------------------------- ODE Guidance for the Content of Premarket Submission for Medical Devices Containing Software Draft Document. This guidance document is being distributed for comment purposes only. CDRH Software Task Force Group Center for Devices and Radiological Health Draft released for comment on: September 3, 1996 Appendix B, Section B.11 Off-the-Shelf (OTS) Software. Off-the-shelf (OTS) end-user software products are designed, developed, verified and validated for use in an office or industrial environment. Regularly scheduled releases of new versions of OTS software are planned which incorporate corrections and product enhancements. OTS software is not developed with the degree of rigor necessary for safety-critical applications. Hence, the responsibility for verifying and validating the use of OTS software falls to the medical device manufacturer. Verification and validation activities should evaluate the safety, reliability, and integrity of the OTS product and its intended use in a medical device, and allow for appropriate safeguards to be designed and developed for the device. There may be instances in higher level of concern software where the use of OTS is inappropriate since the developer may not have access to appropriate documentation or source code to implement proper corrections and modifications that may be necessary, or subject the software to proper development techniques and risk management activities. Re-engineering (or reverse engineering) is another issue with OTS software; e.g. a firm is working with only executable code and has no supporting documentation or access to source code. For higher level of concern software, finding another vendor who can support OTS software or developing a custom operating system may be a safer choice. Use of OTS software that cannot be evaluated properly, be subjected to software lifecycle processes, or be modified if a bug or anomaly occurs, may not be appropriate to use in higher level of concern software. System level tests can be performed on OTS; however, most errors found at the system level are indicative that there are more serious problems. Errors at this level are considered symptoms, not identification of the problem. A draft policy is being developed concerning the regulation of medical devices employing OTS software. Appendix B, Section, B.12 Open Systems and Open Systems Architecture. Open systems may be viewed differently by many people. One view is the ability to enable dissimilar computers to exchange information and run each other's software via interfaces from independent vendors. These would be considered "open" operating systems with increased interoperability, flexibility, and portability. The idea is freeing proprietary pathways within each system. Another view is one which is used more frequently and pertains to sharing device control and communications within networks, across devices, etc. This allows for flexibilityin configuring networks and systems, and may include various aspects of medical devices and hospital information systems such as intensive care units, critical care units, operating rooms, pulmonary and cardiac labs, clinical laboratories, radiology laboratories, etc. This sharing of information, control, and network time and space increases the complexity of medical devices. This may not be desirable for higher risk devices, especially since the environment will be difficult to model during verification and validation. Appropriate test suites and test cases may be difficult to analyze from a "completeness" point of view; determining when enough testing has taken place and test completion criteria has been met. The term "open system" has typically referred to the flexibility in using several different vendor devices in a network of some kind, which would require that each vendor have appropriate knowledge of proprietary device drivers for appropriate communication. During the verification and validation process, all information needed for proper communication must be well known by all so that devices can be properly developed and tested. Because medical devices of "higher" level of concern require a more robust operating environment, open systems may not be the most appropriate approach.