Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter.
Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.
OCR for page 193
Appendix E
Dissenting Statement:
Health IT Is a Class III Medical Device
Richard I. Cook, M.D.
This appendix is a dissenting statement from committee member
Richard Cook, and contains his alternate recommendation for the regula-
tion of health IT.
Recommendation 9: The Secretary of Health and Human Services
(HHS) should direct the Food and Drug Administration (FDA) to exer-
cise its authority to regulate health IT, including all electronic health
records (EHRs) and associated components, and health information
exchanges, as Class III medical devices.
Medical and diagnostic devices have produced a therapeutic revolution,
but in doing so they have also become more complex and less easily under-
stood by those who use them. When well designed, well made, and prop-
erly used they support and lengthen life. If poorly designed, poorly made,
and improperly used they can threaten and impair it. (President Gerald
Ford, signing statement for Medical Device Amendments, May 28, 1976)
RATIONALE
Proponents and critics agree that health IT plays an important role
in patient care and patient safety. Rather than being an adjunct or ap-
pendage of health care delivery, health IT is necessarily intimately woven
into the fabric of patient care. Electronic medical records, digital imaging,
provider order entry, and test results delivery do not “have an effect” on
core medical functions; they are core medical functions. In contrast with,
193
OCR for page 194
194 HEALTH IT AND PATIENT SAFETY
for example, electronic medical textbooks, health IT involves the genera-
tion, manipulation, storage, and display of patient- and provider-specific
data. This need for specificity imposes special requirements on information
technology. When a provider reads a laboratory result from the computer
screen or enters an order for a medicine by mouse or keyboard, the patient
context matters a great deal.
Until now, health IT’s quality, accuracy, precision, reliability, and safety
have been left almost entirely to vendors. Although facilities and, to a lesser
extent, users can configure and adapt health IT for their own uses, as a
practical matter it is the vendors who control what health IT looks like and
how it performs. While this may be reasonable for consumer or even some
commercial software and hardware, it is unacceptable for health IT that
must provide high-level performance in a hazardous environment. Medical
practice is inherently hazardous and devices used to care for patients are
regulated.
Is health IT a medical device? If so, in the United States, FDA is charged
with its regulation. According to law, a medical device is
. . . an instrument, apparatus, implement, machine, contrivance, implant,
in vitro reagent, or other similar or related article, including any compo-
nent, part, or accessory, which is—
(1) recognized in the official National Formulary, or the United States
Pharmacopeia, or any supplement to them,
(2) intended for use in the diagnosis of disease or other conditions, or in
the cure, mitigation, treatment, or prevention of disease, in man or other
animals, or
(3) intended to affect the structure or any function of the body of man or
other animals, and which does not achieve its primary intended purposes
through chemical action within or on the body of man or other animals
and which is not dependent upon being metabolized for the achievement
of its primary intended purposes. (Federal Food, Drug, and Cosmetic Act,
21 U.S.C. § 321 SEC. 201)
Health IT components include items such as computerized provider
order entry (CPOE), electronic medical records (EMRs), or EHRs. These
components participate directly in diagnosis, cure, mitigation, treatment,
and prevention of specified individual human beings. Health IT is a medical
device and FDA is or should be its regulatory body.
The 1976 Medical Device Amendments to the Federal Food, Drug,
and Cosmetic Act established three regulatory classes for medical devices.
Class I devices are the simplest and are least likely to cause direct or indirect
harm. The tongue depressor is a Class I device (its entry is in the Code of
Federal Regulations at 21 CFR 880.6230). Class II devices include devices
OCR for page 195
195
APPENDIX E
more likely to present some risk of harm. The hearing aid is a Class II device
(21 CFR 801.420). The amendments define a Class III device as “one that
supports or sustains human life or is of substantial importance in prevent-
ing impairment of human health or presents a potential, unreasonable risk
of illness or injury.” Class III includes obvious high-risk devices such as
external cardiac defibrillators (21 CFR 870.5310) but also includes HIV
tests (21 CFR 864.4020).
What class of medical device is health IT? Because some health IT de-
vice characteristics may require a different approach to regulation than is
practical under current classification rules, perhaps health IT should have
its own classification. Under existing rules, however, I believe that health IT
should be classified as a Class III medical device for at least three reasons.
First, health IT functionality is widely regarded as essential for safe
care. The proponents and vendors of health IT regularly and consistently
point to the safety afforded by the use of health IT. According to the Insti-
tute of Medicine (IOM), human clinician errors are a major cause of mor-
bidity and mortality (IOM, 1999). Preventing human clinician errors is one
of the main functions of health IT and a primary rationale for the $32 bil-
lion investment in health IT committed by the Recovery Act of 2009. This
surely makes health IT of “substantial importance in preventing impairment
of human health,” which is the central criterion of a Class III device.
Second, adoption of health IT has pervasive effects on basic health care
delivery. Its use affects virtually every activity that takes place in a hospital,
clinic, or doctor’s office. Health IT receives, stores, and displays clinical
information. It accepts, validates, and transmits orders for care and treat-
ment. It notifies physicians, nurses, pharmacists, and technicians of patient
conditions. It tracks clinical actions and assessments. These are not trivial
functions, and their accuracy and reliability have direct impact on virtually
every patient’s well-being. Adopting health IT amounts to putting all the
clinical eggs in a single basket. Unlike other medical devices, most of which
have effects on a few hundred or thousand patients, health IT is on track to
be a medical device used for every person in the United States.
The third reason it is a Class III device is that health IT can and does
cause significant harm to patients. At least a few U.S. citizens—perhaps
more than a few—have died or been maimed because of health IT. The
extent of the injuries generated by health IT is unknown because no one
has bothered to look for them in a systematic fashion. Indeed the failure to
treat health IT as a medical device has played a significant role in keeping
the problems with health IT from becoming known. Medical device manu-
facturers are obligated to report instances of patient harm connected to
their devices. Health IT vendors are not. Problems and the resulting hazards
from health IT cannot be addressed and fixed without first being identified
through some form of reporting. The government’s failure to treat health IT
OCR for page 196
196 HEALTH IT AND PATIENT SAFETY
as a medical device has allowed manufacturers to keep the problems with
health IT hidden and has made it possible for vendors to require contractual
“gag clauses” that restrict open discussion of its problems.
Simply declaring health IT to be a medical device—even a Class III
medical device—will not rectify the safety problem that health IT creates. It
will, however, begin to bring this burgeoning area out of the shadows and
into the light. This is a necessary part of improving its impact on patient
safety.
Accidents involving health IT are complex events that require sub-
stantial forensic skill to detect and describe. The impact of health IT on
system safety is most easily understood in cases of overt computer outages
(sometimes described as system “crashes”), which deny clinicians access to
the data and communications that these systems usually provide. Absurdly,
when such an outage becomes public knowledge the system owners uni-
formly declare that “no patient was harmed.” If so, the case for health IT
must be weak indeed. There are presently no standards for assessing or
reporting such outages or for judging their effects on safety.
But most of the impact of health IT on safety must be more subtle than
the overt computer crash. The “copy forward” case described in Box E-1
is more representative. Here, data appear out of context and are misinter-
preted. The simple existence of a datum inside a database does not ensure
that its significance will be appreciated. Similarly, the appreciation of a
datum in one circumstance does not ensure that it will be appreciated in
all circumstances. Problems with “pick lists”—e.g., menus of medications,
procedures, or laboratory tests—are common in other areas and also ap-
pear in reports of difficulties with health IT. It is remarkably easy to select
the wrong patient or the wrong drug from these lists.
We know this not so much from studies of health IT as from experience
in other domains. Indeed this experience is the basis for modern methods
B OX E-1
An abdominal ultrasound report in an electronic record appeared
to indicate a blighted ovum, and a dilation and curettage (D&C) was
performed a few days later. The patient returned to the ER [emergency
room] 4 weeks after the D&C with abdominal pain. Repeat ultrasound
revealed a 21-week pregnancy. A damaged fetus was delivered at 26
weeks. The ultrasound result had actually been obtained several weeks
prior to the date of the record in which it appeared. The report had been
copied forward into that record and appeared out of context.
OCR for page 197
197
APPENDIX E
for IT designs for use in hazardous settings. It is not surprising that such
events are now being discovered in health IT. What is surprising is that
those creating and promoting these large systems have neither anticipated
them nor looked for them. The development of health IT is marked by an
optimism about the effects of IT that are unwarranted and naive. And the
willingness to embrace this optimism to the extent of making large-scale
investments in these systems and only later asking what their impact might
be on patient safety borders on recklessness.
Mounting an effort to bring device regulation to health IT will be chal-
lenging and demands both added resources and new methodologies for
FDA. It is clear from a recent IOM report (IOM, 2011) that medical device
regulation itself will benefit from careful review and revision. But make no
mistake: health IT is a medical device. It should be regulated as a medical
device now and should have been regulated as a medical device in the past.
REFERENCES
IOM (Institute of Medicine). 1999. To err is human: Building a safer health system .
Washington, DC: National Academy Press.
IOM. 2011. Medical devices and the public’s health: The FDA 510(k) clearance process at
35 years. Washington, DC: The National Academies Press.
OCR for page 198
