1997 511FDA SOFTWARE POLICY AND REGULATION

FDA Software Policy and Regulation of Medical DeviceSoftware

E. STEWART CRUMPLER*

HARVEY RUDOLPH, PH.D.**

Why the Food and Drug Administration (FDA) is interested in developing a newsoftware 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 medicaldevice, and describes the agency’s progress toward developing a new risk-based soft-ware policy.

The basis for FDA regulation of software is found in the definition of “device” asstated in section 201(h) of the Federal Food, Drug, and Cosmetic Act (FDCA).1 Adevice is

[A]n instrument, apparatus, implement, machine, contrivance, implant, invitro reagent, or related article, including any component, part, or acces-sory, which is

(1) recognized in the National Formulary, or the United States Phar-macopeia . . .

(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 abovecertainly would encompass some software products; at the very least, software fitsunder the term “contrivance” in the Act. Therefore, when it is intended for use indiagnosis, cure, mitigation, treatment, or prevention of disease, software itself can bea device that is subject to the FDCA. The software developer’s intended use is a veryimportant factor in determining whether and how a particular software product isregulated.

If a software product meets the definition of a device, this has important conse-quences. Unless specifically exempted, any product fitting the definition of a device issubject 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 RadiologicalHealth, Food and Drug Administration.

This article is an updated version of a speech that was presented at FDLI’s 40th Annual EducationalConference, 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

VOL. 52512 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.

While the exemption process is an important one for medical software devices,3 itis 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 estab-lishment information management systems, expert medical decision support systems,and any other software product promoted for medical use. These are examples ofstand-alone devices for which the software is not an accessory to another device. FDAdoes not actively regulate hospital information and prescription ordering systems.4 InJune 1988, laboratory information management systems were reclassified into Class Iand exempted from premarket notification requirements.5 Although these laboratorymanagement products are exempt from section 510(k), they remain subject to otherrequirements of the FDCA. Blood establishment software is regulated actively, andFDA’s Center for Biologics Evaluation and Research has required vendors to submitsection 510(k) premarket notifications for these software products. In general, anysoftware product can be a device, if it is specifically intended for medical use.

Software components of devices and software accessories to devices are them-selves also devices. FDA’s policy is that, unless separately classified, components andaccessories are regulated in the same way as their “parent” devices.6

Over the past seven years, there has been confusion over FDA’s software regula-tory 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 “[asoftware] accessory is a [software] unit which is intended to be attached to or used inconjunction with another finished device, although an accessory may be sold or pro-moted as an independent unit.”7 A second definition of “accessory” is the workingdefinition that FDA has used over the past two years in the discussions about theagency’s software policy. According to this definition, a software accessory to a medi-cal device either accepts data from the user and modifies it for input to a medicaldevice, 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 cal-culator, digital imaging and image conversion software, picture archiving and com-munication system, pacemaker rate response factor calculator, EEG and ECG wave-form analysis software, hemodialysis calculator, and corrective shoe orthosis software(exempted). The AFP calculator is a good example of the need to classify certainaccessories separately based on their own level of risk. In that case, the accessory has

3 See infra text accompanying notes 9-11.4 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. 92-

4165) (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 regulationpreamble. 42 Fed. Reg. 52,808 (Sept. 30, 1977).

1997 513FDA SOFTWARE POLICY AND REGULATION

a much lower risk than the Class III parent device, but current policy required that theAFP calculator be brought to market initially via a premarket approval application.Digital imaging, and picture archiving and communications systems are the subjectsof proposed reclassification regulations that were issued in December 1996.8 Correc-tive shoe orthosis software is an example of an accessory to a low-risk Class I devicethat 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 toapply the least degree of regulatory control necessary to provide reasonable assuranceof safety and effectiveness. As previously stated, a computer product can be a device.Computer products intended only for library, general accounting, communications, oreducation are not subject to regulation. Components, parts, or accessories to a classi-fied device are regulated like that parent device.

For unclassified computer products that are not components or accessories toanother device, the 1989 draft policy proposed several exemptions from FDA regula-tions. For example, computer products that are either general purpose, developed forpersonal or local institutional use, intended for teaching, or intended for nonclinicalresearch are all exempted from active regulation. The draft policy included a “compe-tent human intervention” criterion for exemption of unclassified decision support sys-tems, and FDA stated its intent to develop further exemptions that would be imple-mented 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. Althoughmanufacturers and their attorneys frequently argue for this exemption, many fail torealize that under the 1989 draft policy, the proposed exemptions applied only tounclassified computer products and not to accessories of classified devices. When aseparately marketed software product is intended specifically for use with a classifieddevice, it is an accessory to that parent device and does not qualify for any of the citedexemptions, including competent human intervention. Also, as medical software de-vices have become more complex, it has become increasingly difficult to interpretwhat constitutes competent human intervention.

There are several other provisions of the 1989 draft policy. Exempted computerproducts and software devices are still subject to the general prohibition against adul-teration and misbranding. In addition, blood bank systems specifically are not ex-empted. For all nonexempt computer products (including blood bank systems),premarket notification, establishment registration, device listing, and all other appli-cable requirements must be met. In 1989 the agency knew of no medical softwaredevices requiring premarket approval, but the draft policy held out that possibility forthe future.

After almost ten years with the existing draft policy, there are several factors thatexplain 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 regard-

8 61 Fed. Reg. 63,769 (Dec. 2, 1996).9 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 an-

nounced the availability of the draft 1987 software policy. 52 Fed. Reg. 36,104 .

VOL. 52514 FOOD AND DRUG LAW JOURNAL

ing “competent human intervention.” The agency has had to depend on case-by-case device status determinations, and some participants in the process have notrealized that the competent human intervention exemption is not applicable toaccessories.

• As with other parts of society, there has been a dramatic increase in the complex-ity and impact of device software, and this makes it extremely difficult to definecriteria for a “competent human.”

• The new Quality Systems Regulation for medical devices,12 which became effec-tive June 1, 1997, will have significant effects on this area. The design controlsprovisions of that regulation13 provide for new regulatory approaches that aremore properly suited to medical software devices than traditional FDA premarketreview.

• Limited FDA resources highlight the need for the agency to find new and innova-tive ways to accomplish its job.

For all of these reasons, FDA believes that now is the time for a new device softwarepolicy.

Contrary to the fears of some people, FDA actually is seeking to reduce its regu-latory role for low-risk software. To do so, however, the agency must go through aformal exemption process. This will mean classification or reclassification of soft-ware devices and accessories, based on the risk of each.

The agency wants to make the best use of its limited resources and to minimizethe overlap between design controls in the new Quality System Regulation and thepremarket clearance reviews for software. Software development is primarily a designprocess. For software, a large part of FDA’s premarket review concentrates on themanufacturer’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 ofhazard analysis and other tools. Thus, the agency’s review of software is, for manydevices, primarily an assessment of software development practices (comparable toFDA inspections of design controls under the Quality System Regulation).

What is the new FDA software policy? This is a difficult question to answerbecause the offices in FDA’s Center for Devices and Radiological Health (CDRH) isstill in at the early stages of developing the software policy and is seeking broad publicinput to that process. CDRH, however, does have some guiding principles in the mat-ter.

• FDA’s starting premise is that some software products meet the definition of amedical device and must be regulated as such, unless specifically exempted.

• FDA will take a risk-based approach to regulation, as exemplified in its classifi-cation 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 identi-fication of appropriate software standards.

• FDA will actively engage the regulated industry and device users in designing aregulatory framework.

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

1997 515FDA SOFTWARE POLICY AND REGULATION

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

In the process of developing FDA’s software policy, the agency sought input fromusers and developers on what FDA’s role should be, i.e., where it is appropriate forFDA to exercise oversight. In particular, between 1995 and 1996, FDA communi-cated with representatives of a number of national organizations, including the Ameri-can Medical Association, the American Hospital Association, the American Collegeof Radiology, the Society for Nuclear Medicine, the Society for Medical DecisionMaking, and the National Medical Association. Agency personnel also spoke at roundtables sponsored by groups such as the American Medical Informatics Association,the Health Informatics Management System Society, and the American Associationfor the Advancement of Science. Discussion at these meetings concentrated on theappropriate level of regulatory oversight and on the development of good risk-basedcriteria for classifying devices so that the appropriate exemptions could be put inplace. Results of these efforts were surprisingly consistent, given the wide spectrum ofviews represented at the meetings.

Primarily, the agency concluded that most individuals believed there should beFDA oversight for some medical software devices, at least for those that would exposepatients 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 pa-tients, and that FDA “intrusion” in those instances could have a chilling effect ontheir development.

As a natural expansion of this outreach to various constituencies, FDA and theNational Library of Medicine cosponsored a public workshop14 to elicit more inputfrom 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 describedin that paper, low-risk devices would have the least amount of control and would beexempt from all requirements except misbranding and adulteration; high-risk deviceswould undergo premarket review; and moderate-risk products could be regulated us-ing a special control involving an independent audit of the software developmentprocess in place of all, or most, of a 510(k) application.16

Almost 600 people attended the FDA/NLM Software Policy Workshop. Seven-teen groups and individuals took the opportunity to make formal public statements. Alarge number of people spoke at both the plenary and breakout sessions. The results ofthe breakout sessions were reported back on the second day. Although many insight-ful observations were made, there obviously was no consensus on any of the issuesraised, and much additional work needed to be undertaken. FDA personnel asked theworkshop attendees to help address the unresolved issues and solve the problems iden-tified at the workshop.

The response to this request has been quite positive. For example, since the Sep-tember 1996 workshop, FDA was invited to attend independently sponsored work-shops 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 atFood 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.

VOL. 52516 FOOD AND DRUG LAW JOURNAL

the Center for Healthcare Information Management, and the Health Industry Manu-facturers Association.17 The information developed at these workshops ultimately willbe used in FDA’s regulatory proposals for medical software devices.

When asked what FDA’s software policy will be, the authors describe that agencyas currently in a “listening mode” on this issue. The exact nature of the policy willdepend in large part on the results of ongoing public meetings and workshops. Theagency’s next step could be in one of several directions:

(1) FDA could synthesize the results of the workshops and the proposals that havebeen submitted to the agency into a notice of proposed rulemaking on the imple-mentation of the new policy. This would be an appropriate strategy if the agencywere 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 con-sensus prior to any formal proposal.

(3) The agency might try to speed consensus-building through an intensive effortlike negotiated rulemaking.

(4) If consensus exists on some part of the policy, FDA could try to implement thataspect 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 con-fidently assert that they do not know when (or how) it will end. A reasonable timeframewould identify the next procedural step to be started by early 1998. For those inter-ested in the development of FDA’s software policy, regular visits to the CDRH website should provide pertinent information.18

17 American Medical Informatics Association Annual Meeting, Washington, D.C., Oct. 30, 1996; CHIM-FDA 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>; Centerfor Devices and Radiological Health, Food and Drug Admin., CDRH Homepage <http://www.fda.gov/cdrh>.