Draft Revision of FDA's Medical Device Software Policy Raises Warning Flags

Medical Device & Diagnostic Industry Magazine
MDDI Article Index

PRODUCT DEVELOPMENT

Unless industry gets involved now, complex and prohibitive regulation looms on the horizon.

A pacemaker and the software that operates it are clearly medical devices that fall under FDA's regulatory authority. But what about a software program that helps a health-care practitioner diagnose osteoporosis? If you don't know, you aren't alone. FDA isn't certain either.

In 1986, former FDA commissioner Frank Young declared that FDA's policy toward software would require the "least regulation consistent with the requirements of public health and safety." However, in the 11 years since he made that statement, the agency's demands on companies developing software that can be used with medical devices have been growing. The resulting policy is a confusing patchwork of exemptions and case-by-case assessments.

Recognizing this situation, FDA is reexamining and reformulating its medical software policy and asking industry to participate in the process. If industry wants to ensure that any new policy or guidance document for medical software conforms with the spirit of Commissioner Young's approach and does not unduly inhibit technological advances in the United States, it must get involved at the outset. To do this, however, manufacturers must understand FDA's current policy on software and how it developed.

BACKGROUND

FDA first formally stated its software policy in the 1987 "Draft Policy on the Regulation of Computer Products."¹ This document provided guidelines about which software products were regulated as medical devices and which were exempt from particular regulatory controls, such as premarket notifications. A 1989 draft policy statement, "FDA Policy for the Regulation of Computer Products," reiterated the 1987 draft and has been the agency's operational policy ever since.

Supplementing this policy is the Reviewer Guidance for Computer Controlled Medical Devices Undergoing 510(k) Review, issued in 1991 by FDA's Office of Device Evaluation (ODE) in the Center for Devices and Radiological Health. This document focused on the software development process and described what information FDA reviewers expect to be included in 510(k) notifications and the approach reviewers should take when reviewing computer-controlled devices.

However, FDA's software policy began to slip behind technological advances. Thus, in September 1996, the agency began a major effort to reexamine its computer policy by sponsoring, with the National Library of Medicine (NLM), a public workshop to discuss the definition of medical software device, the criteria for defining risk categories, software quality audits, premarket notification, and other issues.² The workshop's avowed purpose was to work with industry to better assess the risks to public health associated with different types of medical device software and to reduce the regulatory burden on industry. However, on the same day that FDA held this first medical software device workshop, ODE quietly released for comment to a limited number of trade associations and individuals the 82-page ODE Guidance for the Content of Premarket Submission for Medical Devices Containing Software (draft, September 3, 1996). This document, if finalized, would replace the 1991 reviewer guidance and, rather than reduce the regulatory burden on industry, would substantially increase the documentation requirements for U.S. medical software products subject to premarket submission requirements.

Because the 1996 draft ODE guidance represents a substantial investment of agency resources, one must question how amenable the agency will be to modifying it in response to industry comments. In addition, it is important to realize that the document will set the parameters for FDA's future software policy. With so much at stake, it is clear that the draft deserves more than a passing glance.

DEFINITION OF A MEDICAL DEVICE

Under the Federal Food, Drug, and Cosmetic Act (FD&C Act), a medical device is any "instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including any component, part, or accessory, which is . . . intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease . . . or intended to affect the structure or any function of the body."³ Software that meets this definition is considered a device subject to all applicable FDA medical device statutory and regulatory provisions. Software can be a device by itself (i.e., stand-alone) or it can be incorporated into another device as a component, part, or accessory. Under the current policy, FDA distinguishes between stand-alone software and software that is a component, part, or accessory to a device.

STAND-ALONE SOFTWARE

Stand-alone medical software is neither a component nor an accessory to another device, but a separate product intended to receive medically related data as input and to relay the results through a general-purpose computer to a health-care practitioner or other user.⁴ Software that helps diagnose osteoporosis could meet this definition. Other examples include blood bank software systems that control donor deferrals and the release of blood products, software that analyzes potential therapeutic interventions for a particular patient, and hospital information systems. Any such software intended to aid in the diagnosis, cure, mitigation, or treatment of disease meets the definition of a medical device. However, it may be subject to different degrees of regulation depending on whether it falls into any one of three categories of exemptions: it may not be formally treated as a medical device, it may be exempted by a specific FDA regulation, or it may involve competent human intervention.

Not Formally Treated as a Medical Device. The first category exempts certain classes of software from the device definition. According to the 1989 draft policy, the following systems are exempt from FDA regulations and authorities, even though they technically meet the definition of a medical device:

Exemption by FDA Regulation. The second category applies to those stand-alone software products that are subject to exemption by a specific FDA regulation. These exempted software products include the following:

These products are currently exempt from most of the general controls under the FD&C Act, medical device reporting (MDR) requirements, and good manufacturing practice (GMP) requirements. However, they remain subject to the adulteration and misbranding provisions of the act.

The reference to products used in nonclinical research implies that diagnostic software (i.e., a medical expert system) would not fall within this exemption and could be subject to premarket submission requirements for a Class III device. For companies trying to find newer, more cost-effective approaches to the costly data collection currently entailed by clinical trials, this category is worth careful review. There could be circumstances involving minimal risk and reasonably prompt clinician intervention where the diagnostic system should be exempted and, under the current guidelines, is not.

Competent Human Intervention. This third category has been the most controversial. FDA stated in its 1989 draft policy that unclassified, stand-alone software products that are "intended to involve competent human intervention before any impact on human health occurs" would not be subject to active regulatory oversight. It is important to note that the term competent human intervention is only relevant to those stand-alone software products that meet the definition of a medical device, are not components or accessories, are unclassified, and do not fall into one of the above exempted groups of products.

If these criteria are met, the software product is exempt from registration, listing, premarket notification, MDR, and GMP regulations. Therefore, a stand-alone software program intended to be used by a physician to diagnose osteoporosis and calculate a drug-dosing regimen after he or she has manually input the variables would be exempt from FDA regulation.

However, because of confusion over the "competent human intervention" standard and the increasingly complex and sophisticated nature of software, FDA intends to eliminate this language from future policy statements. This elimination would represent a substantial change for many companies relying on stand-alone software and could subject them to the most stringent premarket regulatory requirements.

COMPONENTS, PARTS, AND ACCESSORIES

According to FDA's current policy, medical software that meets the definition of a component, part, or accessory is regulated according to the requirements of the parent device, unless the software is separately classified.

Software as a Component or Part. A software component is "any . . . software . . . which is intended to be included as part of the finished, packaged and labeled device."⁹ Most of the medical device software used by health-care practitioners is incorporated into medical devices as software components. For example, software is frequently used in infusion pumps, pacemakers, ventilators, magnetic resonance imaging (MRI) devices, diagnostic x-ray systems, and clinical laboratory instruments. If an osteoporosis software program were integrated into an MRI device, for example, it would be considered a software component and regulated as a Class II device, like the MRI device itself. Software components are actively regulated by FDA in the course of evaluating the parent device.

Software as an Accessory. A software accessory is a software "unit which is intended to be attached to or used in conjunction with another finished device, although the accessory may be sold or promoted as an independent unit."¹⁰ Accessories are typically marketed as finished devices, often not by the same manufacturer who produces the device with which the accessory is used. Some examples that FDA has given are software for the conversion of pacemaker telemetry data, off-line analysis of EEG data, calculation of rate response for a cardiac pacemaker, calculation of bone fracture risk from bone densitometry data, statistical analysis of pulse oximetry data, and calculation of the refractive power of intraocular lenses.

To determine whether a software product is an accessory, FDA asks, "Is the software specified or otherwise intended for use with a classified device?" and "Is the software directly interfaced with another device for transfer of data to and from the other device?" If the answer to either of these questions is yes, FDA has generally concluded that the software is an accessory subject to the same level of regulation as the parent device. Thus, if an osteoporosis software program were used in conjunction with an MRI system, it would be subject to regulation as a Class II device.

In some cases, the software accessory has a significantly lower inherent risk than the parent device. For example, a calculator programmed to automate simple calculations used with a Class III device might not pose a risk that would warrant a premarket approval application. In other cases, the software might introduce new capabilities for a device for which there is no predicate device. While premarket approval or clinical data could be needed to ensure the safety and efficacy of the new device application, FDA has not developed alternative, less restrictive procedures for evaluating software that imposes less risk than the parent device or that makes it safer to operate. This omission will pose a potential barrier for certain medical software applications if the 1996 ODE draft guidance is not modified.

OFF-THE-SHELF SOFTWARE

Off-the-shelf (OTS) software is usually considered "general purpose" and exempted from active FDA regulation except for prohibitions against adulteration and misbranding. Thus, if an osteoporosis program were developed from a Microsoft Windows program and limited to listing symptoms like those found in a medical text, it would fall under this exemption. If, however, the OTS software were used to create a hospital information system or a medical treatment planning program involving radiation therapy, or to program a life-supporting device such as a pacemaker, the degree of regulatory oversight would increase, sometimes substantially.¹¹

On June 4, 1997, ODE informally released a draft guidance specifically for OTS software, "Guidance for Off-the-Shelf Software Use in Medical Devices." At press time, it has not yet been announced in the Federal Register. Although the document was intended to expand upon the 1996 ODE draft guidance, its effect, if finalized, will be to substantially increase the documentation requirements for companies using OTS software.

According to this draft, all medical device manufacturers using OTS software in their products must perform a hazard analysis of the software as part of their overall system hazard analysis. The detail of documentation required by FDA and the level of life-cycle control needed by the device manufacturer would increase as the hazard to the patient from software failure increased.

If the hazard analysis shows that the software represents a minimal hazard (i.e., no possibility of serious injury), companies must fulfill certain basic requirements that include identifying the software and its developer; testing, verifying, and validating the software to ensure its proper use in the device; and developing a plan to maintain and control the software.

If the hazard analysis shows that the software represents a significant hazard (i.e., failure, malfunction, or misuse is likely to result in death or serious injury to the patient), the device manufacturer must meet a series of special requirements in addition to the basic ones. These special requirements include auditing the software developer's methods of designing the software and demonstrating that it was verified and validated using "appropriate and sufficient" procedures for the intended use of the OTS software. The phrase appropriate and sufficient is not defined in the draft guidance.

If the OTS software represents more than a minimal hazard upon failure but, after hazard mitigation, the residual hazard does not represent a significant hazard, the device manufacturer will be required to prepare a detailed discussion of that residual hazard and the concomitant benefits and risks the OTS software presents. According to the draft guidance, acceptable levels of hazard mitigation will depend on the specific medical device application.

PREMARKET SUBMISSIONS

The content of premarket submissions for medical devices containing software (i.e., 510(k) notifications and premarket approval applications) is discussed in ODE's 1996 draft guidance. If finalized, the guidance would apply to all software, including embedded software, operator-assisted software, and software accessories to medical devices. It would also revise the current three-tier process for determining the level of concern or severity of risk for medical device software.

The Federal Register notice of the 1996 draft guidance specifically sought comment on the proposal to replace the current three-tier process with a two-tier process where a lower level of concern exists "if latent failures or design flaws (direct or indirect) would not be expected to result in death or serious injury." A higher level of concern exists "if latent failures or design flaws (direct or indirect) could result in death or serious injury."¹² A major problem with this proposed two-tier approach is the probability that most devices will be placed into the higher-level category. This would result in more extensive documentation demands and, ultimately, costly delays in the entry in these devices into the marketplace.

With regard to submissions for modifications to currently manufactured devices containing software, the FDA guidance "Deciding When to Submit a 510(k) for a Change to an Existing Device" (January 10, 1997) continues to be relevant. For OTS software, FDA has stated in its 1997 ODE OTS software draft guidance that changes representing a minimal hazard would not typically require a new 510(k) notification. For other devices, the intended use, function of the software, and degree of hazard mitigation would affect whether a new 510(k) notification was required.¹³ However, regardless of the significance of the change, FDA has recently stated in a draft guidance on software validation that the validation status of the entire software system should be addressed, not just the validation of the individual change.¹⁴

CONCLUSION

To a certain degree, FDA's review of its computer policy is an extension of its revision of the GMP regulations. Because of the new design control requirements, it is timely to ask whether these requirements lessen the need for 510(k) submissions for stand-alone and accessory software devices. FDA is currently considering this question as well as replacing the existing policy with one that classifies software on the basis of its own level of risk rather than on that of its parent device.

FDA is also considering software quality audits (SQA) and certification as a replacement for premarket notification of stand-alone software products. Such certification would be, in effect, a special control established for medical software devices. The SQA would be a critical review of the software quality assurance system, performed by a qualified and independent third-party auditor, to provide documentary evidence that a particular medical software device had been developed in accordance with appropriate industry standards or according to a recognized quality process, specification, or procedure established by the developer. The intent of the SQA would be to reduce or eliminate unnecessary paperwork for both industry and the agency without compromising the safety and effectiveness of medical software devices.

As FDA examines and prepares to revise its medical software policy, two new documents, ODE's 1996 draft guidance and 1997 OTS software draft guidance, threaten to impose new and more substantial documentation burdens on manufacturers who use software in their products. Industry must examine those documents and ask, among other questions:

FDA's position on many of the issues surrounding medical software is still being developed, and the agency is actively soliciting input. If industry wants to avoid restrictive medical software policies and increased regulatory burdens, it must fully understand the issues and implications of FDA's efforts and the new draft guidances and become an active participant in the policy making process.

REFERENCES

1. Federal Register, 52 FR:36104.

2. 61 FR:36886.

3. Federal Food, Drug, and Cosmetic Act, as Amended, Sec. 201(h), Washington, DC, U.S. Government Printing Office, 1993.

4. FDA Regulation of Medical Device Software (Background), distributed at the FDA/NLM Software Policy Workshop, September 3­4, 1996, Rockville, MD, FDA, 1996.

5. "FDA Policy for the Regulation of Computer Products" (draft), November 13, 1989.

6. Code of Federal Regulations, 21 CFR 807.65(c).

7. 21 CFR 807.65(d).

8. 21 CFR 807.65(f).

9. 61 FR:52602, 52655.

10. "Everything You Always Wanted to Know about the Medical Device Amendments... And Weren't Afraid to Ask," FDA 92-4173, Rockville, MD, FDA, 1992.

11. "ODE Guidance for the Content of Premarket Submission for Medical Devices Containing Software" (draft), lines 2136­2147, 6379­6434, Rockville, MD, FDA, September 3, 1996. See also, "FDA Draft Guidance on Interventional Cardiology Devices (ICD)" (draft 4.1), Rockville, MD, FDA, March 3, 1996.

12. "ODE Guidance for the Content of Premarket Submission for Medical Devices Containing Software" (draft), lines 2136­2147, 6379­6434, Rockville, MD, FDA, September 3, 1996.

13. "Guidance for Off-the-Shelf Software Use in Medical Devices" (draft), Rockville, MD, FDA, Office of Device Evaluation, June 4, 1997.

14. "General Principles of Software Validation" (draft), Rockville, MD, FDA, Office of Compliance, June 9, 1997.

Suzan Onel is an attorney at the law office of McKenna & Cuneo llp (Washington, DC).

Illustration by Warren Gebert

Copyright ©1997 Medical Device & Diagnostic Industry