1997

FDA SOFTWARE POLICY AND REGULATION

511

FDA Software Policy and Regulation of Medical Device Software E. STEWART CRUMPLER * HARVEY RUDOLPH, PH.D. **
Why the Food and Drug Administration (FDA) is interested in developing a new software policy, and what will that policy be, are issues of concern to many observers. This article provides some background on FDA’s regulation of software as a medical device, and describes the agency’s progress toward developing a new risk-based software policy. The basis for FDA regulation of software is found in the definition of “device” as stated in section 201(h) of the Federal Food, Drug, and Cosmetic Act (FDCA).1 A device is [A]n instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or related article, including any component, part, or accessory, which is (1) recognized in the National Formulary, or the United States Pharmacopeia . . . (2) intended for use in the diagnosis of disease, or other conditions, or in the cure, mitigation, treatment or prevention of disease . . . or (3) intended to affect the structure or function of the body . . . .2 This excerpt demonstrates that a device is defined very broadly, in that components, parts, and accessories are included. The emphasized parts of the definition above certainly would encompass some software products; at the very least, software fits under the term “contrivance” in the Act. Therefore, when it is intended for use in diagnosis, cure, mitigation, treatment, or prevention of disease, software itself can be a device that is subject to the FDCA. The software developer’s intended use is a very important factor in determining whether and how a particular software product is regulated. If a software product meets the definition of a device, this has important consequences. Unless specifically exempted, any product fitting the definition of a device is subject to applicable device regulatory requirements, including:

* Mr. Crumpler is Software Expert, Office of Compliance, Center for Devices and Radiological Health, Food and Drug Administration. ** Dr. Rudolph is Deputy Director, Office of Science and Technology, Center for Devices and Radiological Health, Food and Drug Administration. This article is an updated version of a speech that was presented at FDLI’s 40th Annual Educational Conference, Washington, D.C. (Dec. 10-11, 1996). 1 Pub. L. No. 75-717, § 201(h), 52 Stat. 1040, 1041 (1938) (codified as amended 21 U.S.C. § 321 (1994)). 2 Id. (emphasis added).

511

512
• • • • • •

FOOD AND DRUG LAW JOURNAL
establishment registration, device listing, section 510(k) premarket notification, good manufacturing practices (GMPs), medical device reporting, and prohibition against adulteration and misbranding.

VOL. 52

While the exemption process is an important one for medical software devices,3 it is illustrative to list a few examples of software that do fit the definition of a device. These include hospital information systems, pharmacy prescription ordering systems, drug dosing calculators, laboratory information management systems, blood establishment information management systems, expert medical decision support systems, and any other software product promoted for medical use. These are examples of stand-alone devices for which the software is not an accessory to another device. FDA does not actively regulate hospital information and prescription ordering systems.4 In June 1988, laboratory information management systems were reclassified into Class I and exempted from premarket notification requirements.5 Although these laboratory management products are exempt from section 510(k), they remain subject to other requirements of the FDCA. Blood establishment software is regulated actively, and FDA’s Center for Biologics Evaluation and Research has required vendors to submit section 510(k) premarket notifications for these software products. In general, any software product can be a device, if it is specifically intended for medical use. Software components of devices and software accessories to devices are themselves also devices. FDA’s policy is that, unless separately classified, components and accessories are regulated in the same way as their “parent” devices.6 Over the past seven years, there has been confusion over FDA’s software regulatory policy, and part of that confusion has to do with the variations in the definition of “accessory.” One definition, adapted from FDA’s written guidance, provides that “[a software] accessory is a [software] unit which is intended to be attached to or used in conjunction with another finished device, although an accessory may be sold or promoted as an independent unit.”7 A second definition of “accessory” is the working definition that FDA has used over the past two years in the discussions about the agency’s software policy. According to this definition, a software accessory to a medical device either accepts data from the user and modifies it for input to a medical device, or takes data from a medical device and modifies it for presentation to the user. Some specific examples of software accessories include alpha fetoprotein (AFP) calculator, radiation therapy treatment planning software, intraocular lens power calculator, digital imaging and image conversion software, picture archiving and communication system, pacemaker rate response factor calculator, EEG and ECG waveform analysis software, hemodialysis calculator, and corrective shoe orthosis software (exempted). The AFP calculator is a good example of the need to classify certain accessories separately based on their own level of risk. In that case, the accessory has
See infra text accompanying notes 9-11. FDA, however, does regulate software used in determining drug doses for specific patients. 5 53 Fed. Reg. 21,449 (June 8, 1988). 6 FOOD AND DRUG ADMIN., REGULATORY REQUIREMENTS FOR MEDICAL DEVICES 2-24 to -26 (FDA Pub. No. 924165) (1992). 7 FOOD AND DRUG ADMIN., EVERYTHING YOU ALWAYS WANTED TO KNOW ABOUT MEDICAL DEVICE REQUIREMENTS . . . 20 (FDA Pub. No. 92-4173) (1992). Note that “accessory” was first defined in the device listing regulation preamble. 42 Fed. Reg. 52,808 (Sept. 30, 1977).
4 3

1997

FDA SOFTWARE POLICY AND REGULATION

513

a much lower risk than the Class III parent device, but current policy required that the AFP calculator be brought to market initially via a premarket approval application. Digital imaging, and picture archiving and communications systems are the subjects of proposed reclassification regulations that were issued in December 1996.8 Corrective shoe orthosis software is an example of an accessory to a low-risk Class I device that is exempted from both premarket notification and GMP requirements. So what is FDA’s software policy? A draft software policy was developed in 19879 and revised in November 1989.10 FDA’s basic philosophy for computer products is to apply the least degree of regulatory control necessary to provide reasonable assurance of safety and effectiveness. As previously stated, a computer product can be a device. Computer products intended only for library, general accounting, communications, or education are not subject to regulation. Components, parts, or accessories to a classified device are regulated like that parent device. For unclassified computer products that are not components or accessories to another device, the 1989 draft policy proposed several exemptions from FDA regulations. For example, computer products that are either general purpose, developed for personal or local institutional use, intended for teaching, or intended for nonclinical research are all exempted from active regulation. The draft policy included a “competent human intervention” criterion for exemption of unclassified decision support systems, and FDA stated its intent to develop further exemptions that would be implemented in a classification regulation. There has been much confusion over the term “competent human intervention,”11 and much discussion about the devices to which this exemption may apply. Although manufacturers and their attorneys frequently argue for this exemption, many fail to realize that under the 1989 draft policy, the proposed exemptions applied only to unclassified computer products and not to accessories of classified devices. When a separately marketed software product is intended specifically for use with a classified device, it is an accessory to that parent device and does not qualify for any of the cited exemptions, including competent human intervention. Also, as medical software devices have become more complex, it has become increasingly difficult to interpret what constitutes competent human intervention. There are several other provisions of the 1989 draft policy. Exempted computer products and software devices are still subject to the general prohibition against adulteration and misbranding. In addition, blood bank systems specifically are not exempted. For all nonexempt computer products (including blood bank systems), premarket notification, establishment registration, device listing, and all other applicable requirements must be met. In 1989 the agency knew of no medical software devices requiring premarket approval, but the draft policy held out that possibility for the future. After almost ten years with the existing draft policy, there are several factors that explain why FDA is interested in a new software policy. • • The 1989 draft policy was never published as final, thus it has no legal status. As described above, there has been confusion in both industry and FDA regard8 9

61 Fed. Reg. 63,769 (Dec. 2, 1996). See 52 Fed. Reg. 36,104 (Sept. 25, 1987). 10 CENTER FOR DEVICES AND RADIOLOGICAL HEALTH, FOOD AND DRUG ADMIN., FDA POLICY FOR REGULATION OF COMPUTER PRODUCTS, DRAFT (1989). 11 “Component human intervention” is defined, albeit vaguely, in the Federal Register notice that announced the availability of the draft 1987 software policy. 52 Fed. Reg. 36,104 .

514

FOOD AND DRUG LAW JOURNAL

VOL. 52

ing “competent human intervention.” The agency has had to depend on case-bycase device status determinations, and some participants in the process have not realized that the competent human intervention exemption is not applicable to accessories. As with other parts of society, there has been a dramatic increase in the complexity and impact of device software, and this makes it extremely difficult to define criteria for a “competent human.” The new Quality Systems Regulation for medical devices,12 which became effective June 1, 1997, will have significant effects on this area. The design controls provisions of that regulation13 provide for new regulatory approaches that are more properly suited to medical software devices than traditional FDA premarket review. Limited FDA resources highlight the need for the agency to find new and innovative ways to accomplish its job.

For all of these reasons, FDA believes that now is the time for a new device software policy. Contrary to the fears of some people, FDA actually is seeking to reduce its regulatory role for low-risk software. To do so, however, the agency must go through a formal exemption process. This will mean classification or reclassification of software devices and accessories, based on the risk of each. The agency wants to make the best use of its limited resources and to minimize the overlap between design controls in the new Quality System Regulation and the premarket clearance reviews for software. Software development is primarily a design process. For software, a large part of FDA’s premarket review concentrates on the manufacturer’s hazard assessment and control of the software development process. FDA focuses on the use of standard practices, adherence to recognized standards, good software engineering practices, proper documentation, and appropriate use of hazard analysis and other tools. Thus, the agency’s review of software is, for many devices, primarily an assessment of software development practices (comparable to FDA inspections of design controls under the Quality System Regulation). What is the new FDA software policy? This is a difficult question to answer because the offices in FDA’s Center for Devices and Radiological Health (CDRH) is still in at the early stages of developing the software policy and is seeking broad public input to that process. CDRH, however, does have some guiding principles in the matter. • • • • FDA’s starting premise is that some software products meet the definition of a medical device and must be regulated as such, unless specifically exempted. FDA will take a risk-based approach to regulation, as exemplified in its classification and exemption of medical software devices. FDA will use the least amount of regulatory control necessary to control risks. FDA will regulate medical software devices innovatively to minimize impact on product development, e.g., use of design controls, independent audits, and identification of appropriate software standards. FDA will actively engage the regulated industry and device users in designing a regulatory framework.
12 13

61 Fed. Reg. 52,602 (Oct. 7, 1996) (codified at 21 C.F.R. § 820 (1996)). Id. at 52,657 (codified at 21 C.F.R. § 820.30).

1997

FDA SOFTWARE POLICY AND REGULATION

515

FDA will implement its policy gradually, as the tools are developed.

In the process of developing FDA’s software policy, the agency sought input from users and developers on what FDA’s role should be, i.e., where it is appropriate for FDA to exercise oversight. In particular, between 1995 and 1996, FDA communicated with representatives of a number of national organizations, including the American Medical Association, the American Hospital Association, the American College of Radiology, the Society for Nuclear Medicine, the Society for Medical Decision Making, and the National Medical Association. Agency personnel also spoke at round tables sponsored by groups such as the American Medical Informatics Association, the Health Informatics Management System Society, and the American Association for the Advancement of Science. Discussion at these meetings concentrated on the appropriate level of regulatory oversight and on the development of good risk-based criteria for classifying devices so that the appropriate exemptions could be put in place. Results of these efforts were surprisingly consistent, given the wide spectrum of views represented at the meetings. Primarily, the agency concluded that most individuals believed there should be FDA oversight for some medical software devices, at least for those that would expose patients to moderate-to-high risk in the event of failure. FDA was cautioned, however, that many extremely useful medical software products pose little, if any, risk to patients, and that FDA “intrusion” in those instances could have a chilling effect on their development. As a natural expansion of this outreach to various constituencies, FDA and the National Library of Medicine cosponsored a public workshop14 to elicit more input from an even broader range of participants. As background for part of the workshop, talk/thought papers on FDA regulation of medical software devices were developed, and one among these outlined a risk-based approach to such regulation.15 As described in that paper, low-risk devices would have the least amount of control and would be exempt from all requirements except misbranding and adulteration; high-risk devices would undergo premarket review; and moderate-risk products could be regulated using a special control involving an independent audit of the software development process in place of all, or most, of a 510(k) application.16 Almost 600 people attended the FDA/NLM Software Policy Workshop. Seventeen groups and individuals took the opportunity to make formal public statements. A large number of people spoke at both the plenary and breakout sessions. The results of the breakout sessions were reported back on the second day. Although many insightful observations were made, there obviously was no consensus on any of the issues raised, and much additional work needed to be undertaken. FDA personnel asked the workshop attendees to help address the unresolved issues and solve the problems identified at the workshop. The response to this request has been quite positive. For example, since the September 1996 workshop, FDA was invited to attend independently sponsored workshops held by such organizations as the American Medical Informatics Association,
14 CDRH Software Policy Workshop, Bethesda, MD, Sept. 3-4, 1996 (transcript and summary available at Food and Drug Admin., CDRH Software Policy Workshop (last modified Oct. 3, 1996) <http://www.fda.gov/ cdrh/swpolpg.html>); CDRH Software Policy Workshop, Bethesda, MD, Dec. 3-4, 1996. 15 See Food and Drug Admin., CDRH Software Policy Workshop (last modified Oct. 3, 1996) <http:// www.fda.gov/cdrh/swpolpg.html>. 16 Id.

516

FOOD AND DRUG LAW JOURNAL

VOL. 52

the Center for Healthcare Information Management, and the Health Industry Manufacturers Association.17 The information developed at these workshops ultimately will be used in FDA’s regulatory proposals for medical software devices. When asked what FDA’s software policy will be, the authors describe that agency as currently in a “listening mode” on this issue. The exact nature of the policy will depend in large part on the results of ongoing public meetings and workshops. The agency’s next step could be in one of several directions: (1) FDA could synthesize the results of the workshops and the proposals that have been submitted to the agency into a notice of proposed rulemaking on the implementation of the new policy. This would be an appropriate strategy if the agency were confident that consensus had been reached on the outstanding issues. (2) Short of such a notice, FDA could hold a public workshop to try to achieve consensus prior to any formal proposal. (3) The agency might try to speed consensus-building through an intensive effort like negotiated rulemaking. (4) If consensus exists on some part of the policy, FDA could try to implement that aspect right away, and take more time on the more difficult or contentious issues. Given the uncertainty of opening up the regulatory process, the authors can confidently assert that they do not know when (or how) it will end. A reasonable timeframe would identify the next procedural step to be started by early 1998. For those interested in the development of FDA’s software policy, regular visits to the CDRH web site should provide pertinent information.18

17 American Medical Informatics Association Annual Meeting, Washington, D.C., Oct. 30, 1996; CHIMFDA Workshop, Washington, D.C., Jan. 22, 1997; HIMA Software Task Force, Washington, D.C., Feb. 10, 1997. 18 See Food and Drug Admin., Food and Drug Administration Homepage <http://www.fda.gov>; Center for Devices and Radiological Health, Food and Drug Admin., CDRH Homepage <http://www.fda.gov/cdrh>.