Off the Shelf Software

["Robert C. Leif, Ph.D." <rleif@MAIL.CTS.COM>]

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.