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 soft-
ware 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 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 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 conse-
quences. 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 VOL. 52

• 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 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 estab-
lishment 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 them-
selves 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 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 “[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 pro-
moted 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 medi-
cal 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 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 certain
accessories 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 regulation
preamble. 42 Fed. Reg. 52,808 (Sept. 30, 1977).
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 Correc-
tive 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 classi-
fied 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 regula-
tions. 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 “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. 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 de-
vices 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 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 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 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 .
514 FOOD AND DRUG LAW JOURNAL VOL. 52

ing “competent human intervention.” The agency has had to depend on case-by-
case 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 complex-
ity 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 effec-
tive 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 innova-
tive 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 regu-
latory 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 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 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 mat-
ter.

• 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 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 a
regulatory 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 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 communi-
cated with representatives of a number of national organizations, including the Ameri-
can 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 pa-
tients, 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 us-
ing 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. Seven-
teen 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 insight-
ful 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 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 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 Manu-
facturers 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 imple-
mentation 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 con-
sensus 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 con-
fidently 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 inter-
ested 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; 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>; Center
for Devices and Radiological Health, Food and Drug Admin., CDRH Homepage <http://www.fda.gov/cdrh>.