Grassley Feb 24 Letters

February 24, 2010
Via Electronic Transmission
The Honorable Kathleen Sebelius

Secretary
U.S. Department of Health and Human Services
200 Independence Avenue, SW
Washington, DC 20201
Dear Secretary Sebelius:
As Ranking Member of the Senate Committee on Finance (Committee), which

has jurisdiction over the Medicare and Medicaid programs, I have a special responsibility
to protect the health of the programs’ more than 100 million beneficiaries as well as the
congressionally authorized tax dollars used to fund these programs. This includes
ensuring the effective and efficient use of taxpayer money by the health care industry in
implementing Health Information Technology (HIT), such as Computerized Physician
Order Entry systems and Electronic Health Records (EHR).
On February 12, 2010, you announced over $750 million in grant awards as part
of a federal effort to help hospitals and physicians adopt electronic health records.
American taxpayers and health care facilities are making substantial investments in the
HIT industry, and it is important that their monies are appropriately spent on safe,
effective and interoperable HIT systems.
As I stated in recent questions to you, I strongly agree that HIT has the potential
to prevent medical errors and increase the efficiency and effectiveness of health care
delivery, thereby improving the safety and quality of care. However, I have also been
surprised by the lack of discussion about patient safety concerns when, for example, HIT
products are not functioning properly or when they are being used incorrectly. Therefore,
I was pleased to see the Department of Health and Human Services’ (Department)
announcement that the HIT Policy Committee’s Adoption/Certification Workgroup is
holding a workshop tomorrow to solicit comments on patient safety issues related to EHR
use, including approaches for preventing harm and mitigating risks.
Over the last year, I have heard from many health care providers around the
country regarding problems they experienced with implementation and use of certain HIT
products in their hospitals and clinics. In most cases, they tried raising their concerns to
hospital administrators and/or to the HIT vendors, but they told me that their concerns
were often ignored or dismissed. In October 2009, I wrote to ten major HIT companies
in the U.S. regarding some of these issues and concerns. Last month, I also sent letters to
31 hospitals to obtain their perspective and experiences with HIT. Both letters are
enclosed.
I am also enclosing for your consideration an article entitled, “Recommendation

for Responsible Monitoring and Regulation of Clinical Software Systems.” That position
paper was published in the Journal of the American Medical Informatics Association
(JAMIA) in 1997. Interestingly, according to the article, the Food and Drug
Administration (FDA) had called for discussions on the regulation of clinical software
systems in 1996 and in response, a consortium of health information-related
organizations drafted and published recommendations for the regulation of such systems.
At the time of publication, the authors noted, “Currently, there are no widely accepted,
practical standards for the evaluation, use, and monitoring of clinical software systems.
The FDA is only beginning to formulate a definitive policy with respect to such
systems.” One of the recommendations addressed FDA’s regulatory role. Another
recommendation called for the adoption of a code of good business practices by health
care information system vendors and software producers.
It has been more than a dozen years since the publication of the JAMIA article,
and I would appreciate the Department’s thoughts on it. In particular, I am requesting
responses to the following questions. Please repeat the enumerated question and follow
with the appropriate response and documentation.
1) What is the Department’s position on the proposals in the JAMIA article?
2) To what extent have the recommendations regarding FDA’s regulation of HIT

products been adopted?
3) To what extent are additional efforts needed to respond to the evolving, complex
health information technologies and the meaningful use requirements issued by
the Centers for Medicare and Medicaid Services in December 2009?
4) Earlier this month, I submitted questions to you following the Committee’s

hearing on “The President’s Fiscal Year 2011 Health Care Proposals.” I would
like to reiterate some of those questions in this letter. In particular, I asked the
following:
a. With over $20 billion in taxpayer money at stake and with increasing
complexity in the technologies being used in our hospitals, do you believe
it is time to revisit FDA’s responsibilities in regulating HIT products being
used in clinical care?
b. If not, how is HHS making sure that the health information technologies
being developed and implemented are safe and effective?
c. Who is or should be responsible for ensuring that the HIT vendors are
meeting quality manufacturing processes?
2
5) In addition, does the FDA have sufficient authority to regulate HIT products, or is
there a lack of clarity regarding the FDA’s role? If additional authorities are
needed to ensure adequate oversight of HIT products, please specify what
authorities may be needed. If clarification is required, please specify where
additional clarification is needed.
6) The JAMIA article discussed the evaluation of complex, interconnected systems,

noting that “A software product may work well in isolation but fail when
integrated with other software products or with unsupported network interfaces.”
The authors also stated that “Because each clinical site combines different
software products in different combinations, a universal evaluation of whether or
not a given product will function safely when embedded in a clinical environment
is impractical,” and suggested the establishment of local and regional Software
Oversight Committees.
a. Has HHS considered establishing local or regional oversight committees

for HIT products?
b. To what extent should the Regional Extension Centers and/or Beacon

Community Programs play a role in the reviewing and/or monitoring of
complex HIT systems?
c. What other suggestions do you have for establishing a system for this type
of review?
Thank you for your attention to this important matter. I would appreciate
responses to the questions set forth in this letter by no later than March 10, 2010. If you
have any questions, please contact Angela Choy of my Committee staff at (202) 224-
4515. Any formal correspondence should be sent electronically in PDF searchable
format to Brian_Downey@finance-rep.senate.gov.
Sincerely,
Charles E. Grassley
Ranking Member
cc: The Honorable Margaret A. Hamburg

Commissioner
U.S. Food and Drug Administration
10903 New Hampshire Ave.
Silver Spring, MD 20993
Enclosures
3
October 16, 2009
Neal Patterson
Chief Executive Officer
Cerner Corporation
2800 Rockcreek Parkway
Kansas City, MO 64117
Dear Mr. Patterson:
The United States Senate Committee on Finance (Committee) has jurisdiction

over the Medicare and Medicaid programs. As a senior member of the United States
Senate and Ranking Member of the Committee, I have a special responsibility to protect
the health of Medicare and Medicaid beneficiaries and safeguard taxpayer dollars
authorized by Congress for these programs. This includes the responsibility to conduct
oversight of the health care industry, including the manufacturers of Health Information
Technology and Computer Physician Order Entry Systems (HIT/CPOE), for which about
$19 billion in taxpayer dollars has been earmarked for its development and
implementation.
Over the past year, I have received complaints from patients, medical
practitioners and technologies engineers regarding difficulties they have encountered
with the HIT and CPOE devices in their medical facilities. These complaints include, for
example, faulty software that miscalculated intracranial pressures and interchanged
kilograms and pounds, resulting in incorrect medication dosages.
In addition, it has been reported that HIT/CPOE manufacturers rely on a legal

doctrine known as “learned intermediaries,” to shift responsibility for errors in the HIT
systems to physicians, nurses, pharmacists, and other health care providers. The
manufacturers allegedly argue that the health care provider should be able to identify and
correct errors caused by the software. It has also been reported that HIT/CPOE contracts
with medical facilities may include “hold harmless” provisions that absolve
manufacturers of these products of any liability for errors that are allegedly HIT/CPOE
system or software failures. These contracts may also include “gag orders,” which
prohibit health care providers from disclosing system flaws and software defects.
Furthermore, it was also reported to me that there is no system in place to track,

monitor and report the performance of these systems/devices, which could impact a
health care provider’s ability to make informed decisions regarding the implementation
of an HIT/CPOE system.
American taxpayers will be investing substantially in the HIT/CPOE industry, and
it is important that their monies are appropriately spent on effective and interoperable
HIT systems and devices. Accordingly, I would appreciate your response to the following
questions and requests for information and documents by no later than November 6,
2009. Unless otherwise noted, the requests cover the period of January 1, 2007 through
the date of this letter. In responding to this letter, please repeat the enumerated question
and follow with the appropriate response and documentation.
1) Please provide a product list and description and function of all HIT/CPOE
products manufactured and distributed by Cerner Corporation (Cerner) and its
subsidiaries.
2) Does Cerner include language in its contracts that could be considered “Hold
Harmless” provisions? If so, please provide a copy of sample contracts with such
provisions.
3) Does Cerner incorporate the “learned intermediaries” doctrine in the HIT/CPOE

contract? If so, please provide a copy of sample contracts with such language.
4) Please describe Cerner’s role in ensuring that health care providers are adequately
trained to use your products. Please also provide a copy of any and all training
manuals, training schedules, and power point presentations that illustrate
HIT/CPOE functionality and use.
5) Please provide a copy of communications, including but not limited to

memoranda, letters, meeting minutes and notes, email and correspondence,
regarding complaints and/or concerns from health care providers/professionals
and other clients with the HIT/CPOE systems manufactured by Cerner.
6) Does Cerner have any system in place to track, catalogue or maintain complaints
and/or concerns regarding Cerner’s HIT/CPOE products? If so, please describe
that system in detail.
7) Does Cerner offer health care facilities and/or providers any financial incentives
for purchasing Cerner’s products, such as shares in the company or financial
interests in a Cerner product? If so, please describe the different types of
incentives offered by Cerner.
8) Has Cerner executed any settlement agreements relating either directly or

indirectly to its HIT/CPOE devices and products in the past 18 months. If no, so
state. If yes, please state how many have been executed.
In cooperating with the Committee’s review, no documents, records, data or

information related to these matters shall be destroyed, modified, removed or otherwise
made inaccessible to the Committee.
2
I look forward to your cooperation and assistance on this important matter. If you
have any questions, please do not hesitate to contact Emilia DiSanto or Angela Choy at
(202) 224-4515. All formal correspondence should be sent electronically in PDF format
to Brian_Downey@finance-rep.senate.gov or via facsimile to (202) 228-2131.
Sincerely,
Charles E. Grassley
Ranking Member
Attachment
3
GENERAL INSTRUCTIONS
1. The term “Cerner Corporation” means its corporation, or one or more of its divisions,
subsidiaries or affiliates, or related entities, including any other companies or
corporations with which “Cerner Corporation” entered into a partnership, joint venture or
any other business agreement or arrangement.
2. In complying with this document request, produce all responsive documents that are in
your possession, custody, or control, whether held by you or your past or present agents,
employees, and representatives acting on your behalf. In addition, produce documents
that you have a legal right to obtain, documents that you have a right to copy or have
access to, and documents that you have placed in the temporary possession, custody, or
control of any third party.
3. No documents, records, data or information requested by the Committee shall be

destroyed, modified, removed or otherwise made inaccessible to the Committee.
4. If the document request cannot be complied with in full, it shall be complied with to the
extent possible, which shall include an explanation of why full compliance is not
possible.
5. In complying with this document request, respond to each enumerated request by

repeating the enumerated request and identifying the responsive document(s).
6. In the event that a document is withheld on the basis of privilege, provide the following
information concerning any such document: (a) the privilege asserted; (b) the type of
document; (c) the general subject matter; (d) the date, author and addressee; and (e) the
relationship of the author and addressee to each other.
7. Each document produced shall be produced in a form that renders the document
susceptible of copying.
8. It shall not be a basis for refusal to produce documents that any other person or entity
also possesses non-identical or identical copies of the same document.
9. If any document responsive to this request was, but no longer is, in your possession,
custody, or control, identify the document (stating its date, author, subject and recipients)
and explain the circumstances by which the document ceased to be in your possession, or
control.
10. This request is continuing in nature. Any document, record, compilation of data or
information, not produced because it has not been located or discovered by the return
date, shall be produced immediately upon location or discovery subsequent thereto.
11. All documents shall be Bates stamped sequentially and produced sequentially.
1
GENERAL DEFINITIONS
1. The term “document” means any written, recorded, or graphic matter of any
nature whatsoever, regardless of how recorded, and whether original or copy,
including, but not limited to the following: memoranda, reports, statistical or
analytical reports, books, manuals, instructions, financial reports, working papers,
records notes, letters, notices, confirmations, telegrams, receipts, appraisals,
pamphlets, magazines, newspapers, prospectuses, interoffice and intra office
communications, electronic mail (E-mail), contracts, cables, notations of any type
of conversation, telephone call, meeting or other communication, bulletins,
printed matter, computer printouts, teletypes, invoices, transcripts, diaries,
analyses, returns, summaries, minutes, bills, accounts, estimates, projections,
comparisons, messages, correspondence, press releases, circulars, financial
statements, reviews, opinions, offers, studies and investigations, questionnaires
and surveys, and work sheets (and all drafts, preliminary versions, alterations,
modifications, revisions, changes, and amendments of any of the foregoing, as
well as any attachments or appendices thereto), and graphic or oral records or
representations of any kind (including without limitation, photographs, charts,
graphs, microfiche, microfilm, videotape, recordings and motion pictures), and
electronic, mechanical, and electric records or representations of any kind
(including, without limitation, tapes, cassettes, discs, and recordings) and other
written, printed, typed, or other graphic or recorded matter of any kind or nature,
however produced or reproduced, and whether preserved in writing, film, tape,
disc, or videotape. A document bearing any notation not a part of the original text
is to be considered a separate document. A draft or non-identical copy is a
separate document within the meaning of this term.
2. The term “records” is to be construed in the broadest sense and shall mean any
written or graphic material, however produced or reproduced, of any kind or
description, consisting of the original and any non-identical copy (whether
different from the original because of notes made on or attached to such copy or
otherwise) and drafts and both sides thereof, whether printed or recorded
electronically or magnetically or stored in any type of data bank, including, but
not limited to, the following: correspondence, memoranda, records, summaries of
personal conversations or interviews, minutes or records of meetings or
conferences, opinions or reports of consultants, projections, statistical statements,
drafts, contracts, agreements, purchase orders, invoices, confirmations,
telegraphs, telexes, agendas, books, notes, pamphlets, periodicals, reports, studies,
evaluations, opinions, logs, diaries, desk calendars, appointment books, tape
recordings, video recordings, e-mails, voice mails, computer tapes, or other
computer stored matter, magnetic tapes, microfilm, microfiche, punch cards, all
other records kept by electronic, photographic, or mechanical means, charts,
photographs, notebooks, drawings, plans, inter-office communications, intra-
office and intra-departmental communications, transcripts, checks and canceled
checks, bank statements, ledgers, books, records or statements of accounts, and
papers and things similar to any of the foregoing, however denominated.
2
3. The terms “relate,” “related,” “relating,” or “regarding” as to any given subject
means anything that discusses, concerns, reflects, constitutes, contains, embodies,
identifies, deals with, or is any manner whatsoever pertinent to that subject,
including but not limited to documents concerning the preparation of other
documents.
4. The terms “and” and “or” shall be construed broadly and either conjunctively or
disjunctively to bring within the scope of this document request any information
which might otherwise be construed to be outside its scope. The singular includes
plural number, and vice versa to bring within the scope of this document request
any information which might otherwise be construed to be outside its scope. The
masculine includes the feminine and neuter genders to bring within the scope of
this document request any information that might otherwise be construed to be
outside its scope.
5. The term “communication” means each manner or means of disclosure or

exchange of information, regardless of means utilized, whether oral, written,
electronic, by document or otherwise, and whether face to face, in a meeting, by
telephone, mail, telexes, discussions, releases, personal delivery, or otherwise.
Documents that typically reflect a “communication” include handwritten notes,
telephone memoranda slips, daily appointment books and diaries, bills, checks,
correspondence and memoranda, and includes all drafts of such documents.
3
January 19, 2010
Glenn Steele Jr. M.D., PhD.

President and Chief Executive Officer
Geisinger Medical Center
N. Academy Avenue
Danville, PA 17821
Dear Dr. Steele:
As Ranking Member of the Senate Committee on Finance, which has jurisdiction

over the Medicare and Medicaid programs, I have a special responsibility to protect the
health of the programs’ more than 100 million beneficiaries as well as the
congressionally authorized tax dollars used to fund these programs. This includes
ensuring the effective and efficient use of taxpayer money by the health care industry in
implementing Health Information Technology (HIT), such as Computerized Physician
Order Entry systems and Electronic Health Records.
In recent legislation, approximately $19 billion in taxpayer funds was

appropriated to encourage development and implementation of HIT systems, which
further emphasizes the importance of responsible use and thorough oversight. Over the
past several months, however, I have been made increasingly aware of difficulties and
challenges associated with HIT implementation. The reported problems appear to be
associated with administrative complications in implementation, formatting and usability
issues, and actual computer errors stemming from the programs themselves, as well as,
interoperability between programs. For example, I have heard from health care providers
regarding faulty software that produced incorrect medication dosages because it
miscalculated body weights by interchanging kilograms and pounds.
In addition, I have heard from health care providers around the country that when
they report such problems to their facilities and/or the product vendors, their concerns are
sometimes ignored or dismissed. Some sources recount difficulties in approaching the
HIT vendor with problems and the lack of venue to discuss these issues either with the
vendor or peer organizations. Often this is attributed to alleged “gag orders” or non-
disclosure clauses in the HIT contract that prohibit health care providers and their
facilities from sharing information outside of their facilities regarding product defects and
other HIT product-related concerns.
Some HIT products, I understand, are medical devices regulated by the Food and
Drug Administration (FDA). Therefore, the manufacturers of these devices are required
to meet specific reporting requirements, such as the reporting of adverse events to FDA’s
Manufacturer and User Facility Experience database. However, for HIT products that
may not fall under FDA regulation, there appears to be a lack of a national system for
reporting product errors or failures and adverse events associated with the use of such
products. Thus, problems with these products may go without remedy thereby inhibiting
the ability of the health care professional to provide quality care and potentially
impacting patient safety. Furthermore, contractual restrictions on the sharing of
experiences and information related to specific vendor products limit a health care
facility’s ability to make informed decisions about HIT adoption and implementation.
American taxpayers and health care facilities across the country will be investing
substantially in the HIT industry, and it is important that their monies are appropriately
spent on effective and interoperable HIT systems. In October 2009, I wrote to ten major
HIT companies regarding similar issues and concerns. The purpose of today’s letter is to
gather information from hospitals regarding their perspective and experiences with HIT.
Accordingly, I would appreciate your response to the following questions and requests
for information regarding the HIT products being implemented at your facility and any
issues or concerns that have been raised by your health care providers. Unless otherwise
noted, the requests cover the period of January 1, 2007 through December 31, 2009. In
responding to this letter, please repeat the enumerated question and follow with the
appropriate response and documentation.
1. Please describe in detail your facility’s process for identifying HIT products for
purchase and choosing an HIT vendor(s).
a. What is the personnel structure of those involved in the purchase?
b. To what extent do physicians and other health care providers within your
facility provide input regarding the specific HIT items to be implemented
within your facility?
c. Who or what department within your facility is responsible for making

HIT purchase decisions?
2. Three of the companies that I wrote to in October 2009 informed me that they do
not manufacture HIT software or hardware, but instead assist their health care
clients, such as hospitals, with the implementation and management of HIT
systems. To what extent do you contract with such entities to assist with the
purchase, implementation and/or management of HIT products in your facility?
3. Please describe the training process implemented in your facility to familiarize

employees with new technology systems.
a. How does your facility budget for HIT training?
b. What are the vendors’ roles in helping your facility train in the use of their
products?
2
4. Does your facility have any policies or processes governing the reporting of
problems or concerns by your health care employees related to the HIT products
or systems implemented in your facility? If so, please provide a description of the
policies or processes. If not, please explain why not.
5. When patient care and/or safety problems related to HIT systems arise, how are
these problems reported within the facility and what is the process or mechanism
for addressing them?
a. Are these problems also reported to the HIT vendor, and if so, what is the
process for reporting them?
b. If patient care and/or safety problems related to HIT systems are not
routinely reported to the HIT vendors, please explain how your facility
decides which problems or issues are reported to a vendor and/or
addressed by a vendor and which problems are addressed internally by the
facility.
6. Please describe in detail any system your facility has in place to document, track,
catalogue, and maintain complaints, concerns or issues related to HIT products
that may directly or indirectly involve or impact the delivery of care or patient
safety.
7. Please provide a list of HIT problems or complaints that have been identified by
or reported to your facility since January 2008 that directly or indirectly impacted
patient safety or the delivery of care, including any complications or adverse
events that have occurred as a result of HIT product design and/or usability.
Please describe whether and how each of those problems or complaints was
resolved and whether these issues have resulted in a change in policy to prevent
the problem in the future.
8. Does your facility have policies regarding the discussion of problems in your HIT
systems with other health care facilities or with government officials or any
individuals or entities outside your facility? If so, please describe those policies.
To what extent are these policies driven by contractual agreements with the HIT
vendors, and to what extent do they stem from internal processes? Please provide
examples of contracts with HIT vendors that include non-disclosure clauses.
9. Some of the HIT vendors stated specifically in their responses to me that they do
not include language that would hold them harmless for failures of their products
or for the company’s own negligence or recklessness. However, they may
include provisions that spell out the vendor’s and the health care client’s
respective legal responsibilities and obligations in the use of the product. For
example, one vendor stated that it is accountable for the performance of its
product as long as the client uses the product appropriately. Another vendor
stated that it is not liable when harm or loss results from the client’s use of the
product in diagnosing and/or treating patients.
3
a. Do any of the HIT vendors include language in their contracts with your
facility that could be considered “hold harmless” provisions, i.e., the
transferring of liability associated with the services or products provided
to your facility, or otherwise limit their liability? If so, please provide a
copy of sample contracts containing such provisions.
10. What is the relationship between your facility and any HIT vendors?
a. HIT vendors that manufacture software, hardware and/or other products

purchased by health care facilities have stated in their responses to me that
they do not offer any financial incentives for purchasing their products,
such as shares in the company or financial interests in a particular
product. At least one vendor stated, however, that it does offer financial
incentives in the form of discounts based on purchase size. Another
vendor said that health care clients may receive royalty payments when
the clients collaborate with the vendor to develop a product. What
financial interest, if any, does your facility have in HIT vendors and/or
their products?
b. Do the vendors offer your facility and/or any of your health care providers
any financial incentives for purchasing the vendors’ products? If so,
please describe the types and value of the incentives.
11. Did your staff, health care providers and/or facility receive any payments, product
discounts, or other items of value from any vendor for discussing and/or
promoting that vendor’s HIT products? If so, please list the different types of
payments and discounts and their value.
I look forward to your cooperation and assistance on this important matter. Please
provide your response to the questions and requests set forth in this letter by no later than
February 16, 2010. If you have any questions, please do not hesitate to contact Angela
Choy at (202) 224-4515. All formal correspondence should be sent electronically in PDF
format to Brian_Downey@finance-rep.senate.gov or via facsimile to (202) 228-2131.
Sincerely,
Charles E. Grassley
Ranking Member
4
Downloaded from jamia.bmj.com on January 27, 2010 - Published by group.bmj.com
Recommendations for Responsible Monitoring

and Regulation of Clinical Software Systems
Randolph A Miller, Reed M Gardner and For the American Medical Informatics
Association (AMIA), the Computer-based Patient Record Institute (CPRI), the
Medical Library Association (MLA), the Association of Academic Health Science
Libraries (AAHSL), the American Health Information Management Association
(AHIMA), the American Nurses Association
JAMIA 1997 4: 442-457

doi: 10.1136/jamia.1997.0040442
Updated information and services can be found at:

http://jamia.bmj.com/content/4/6/442.full.html
These include:
References This article cites 44 articles, 29 of which can be accessed free at:
http://jamia.bmj.com/content/4/6/442.full.html#ref-list-1
Article cited in:

http://jamia.bmj.com/content/4/6/442.full.html#related-urls
Email alerting Receive free email alerts when new articles cite this article. Sign up in the box at
service the top right corner of the online article.
Notes
To order reprints of this article go to:

http://jamia.bmj.com/cgi/reprintform
To subscribe to Journal of the American Medical Informatics Association go to:

http://jamia.bmj.com/subscriptions
442 MILLER, GARDNER, Monitoring and Regulation of Clinical Software
Position Paper 䡲
Recommendations for
JAMIA
The Practice of Informatics
Responsible Monitoring and

Regulation of Clinical
Software Systems
RANDOLPH A. MILLER, MD, REED M. GARDNER, PHD. For the American Medical
Informatics Association (AMIA), the Computer-based Patient Record Institute
(CPRI), the Medical Library Association (MLA), the Association of Academic Health
Science Libraries (AAHSL), the American Health Information Management
Association (AHIMA), and the American Nurses Association
A b s t r a c t In mid-1996, the FDA called for discussions on regulation of clinical software

programs as medical devices. In response, a consortium of organizations dedicated to improving
health care through information technology has developed recommendations for the responsible
regulation and monitoring of clinical software systems by users, vendors, and regulatory
agencies. Organizations assisting in development of recommendations, or endorsing the
consortium position include the American Medical Informatics Association, the Computer-based
Patient Record Institute, the Medical Library Association, the Association of Academic Health
Sciences Libraries, the American Health Information Management Association, the American
Nurses Association, the Center for Healthcare Information Management, and the American
College of Physicians. The consortium proposes four categories of clinical system risks and four
classes of measured monitoring and regulatory actions that can be applied strategically based on
the level of risk in a given setting. The consortium recommends local oversight of clinical
software systems, and adoption by healthcare information system developers of a code of good
business practices. Budgetary and other constraints limit the type and number of systems that
the FDA can regulate effectively. FDA regulation should exempt most clinical software systems
and focus on those systems posing highest clinical risk, with limited opportunities for competent
human intervention.
䡲 J Am Med Inform Assoc. 1997;4:442 – 457.
Health care practitioners, clinical facilities, industry, common, equitable framework. In mid-1996, the
and regulatory agencies share an obligation to man- United States Food and Drug Administration (FDA)
age clinical software systems responsibly, using a called for new discussions on the regulation of stand-
Affiliations of the authors: Past President (RAM), and President Correspondence and reprints: Randolph A. Miller, MD, Room
(RMG) of the American Medical Informatics Association, Be- 436, Eskind Library, 2209 Garland Ave., Vanderbilt University
thesda, MD. Medical Center, Nashville, TN 37232.
E-mail: randy.miller@mcmail.vanderbilt.edu
Dr. Miller’s efforts have been supported in part by Grants 5-
G08-LM-05443 and 1-R01-LM-06226 from the National Library Received for publication: 7/3/97; accepted for publication:
of Medicine. 7/17/97.
Journal of the American Medical Informatics Association Volume 4 Number 6 Nov / Dec 1997 443
alone software programs as medical devices.1,2 In re- sis14 – 26; guidelines and reminders27 – 38; protocol man-
sponse, a consortium of health information-related or- agement39 – 40; telecommunication and tele-health41;
ganizations has developed recommendations for public signal processing (e.g., ECG interpretation sys-
and private actions to accomplish responsible monitor- tems)42; image storage and analysis (e.g., picture
ing and regulation of clinical software systems. archival and communications systems— PACS)43;
advice-giving systems for patients; and other health-
The consortium believes that implementation of any
related applications.
new procedures for regulation of clinical software sys-
tems as medical devices requires detailed prior anal- To maximize benefit, providers should integrate signif-
ysis of regulatory relevance to, or impact on, clinical icant technological advances promptly and safely into
software vendors, health care providers, and patients. clinical practice. Currently, there are no widely accepted,
Failure to carry out analyses prior to regulatory ac- practical standards for the evaluation, use, and moni-
tions could halt progress in an emerging new industry toring of clinical software systems. The FDA is only be-
that has substantial potential to improve the quality ginning to formulate a definitive policy with respect to
of health care delivery. Manufacturers, users, and pa- such systems. In our opinion, regulation and oversight
tients cannot tolerate the delays in critical software of clinical systems is both too important and too com-
improvements that might result from excessive gov- plicated to be the sole responsibility of users, vendors,
ernmental review and approval processes. or regulatory agencies—a combined approach is re-
All parties (including the FDA, consortium members, quired, with roles for each category of participants.
and organizations endorsing the consortium position)
emphasize the same objectives—protection and safety Obstacles to Evaluation and Monitoring of
of patients, and facilitation of approaches that im- Clinical Software Systems
prove health care delivery and outcomes. Determination of the safety of clinical software systems
The authors, in consultation with the Editors of is difficult because of the varied nature of clinical soft-
JAMIA and the Annals of Internal Medicine, have pre- ware, the changes that occur when a software product
pared a condensed version of this manuscript, more is integrated into a complex clinical information man-
suitable for a clinical audience, for concurrent publi- agement infrastructure, the changes to systems that oc-
cation in the Annals of Internal Medicine (Miller RA, cur during maintenance, and the miscellaneous inter-
Gardner RM, American Medical Informatics Associa- actions between software programs and their users.
tion, et al. Summary Recommendations for the Re- Evaluation of Simple ‘‘Turnkey’’
sponsible Monitoring and Regulation of Clinical Soft- Clinical Applications
ware Systems. Forthcoming, Ann Intern Med, Vol.
127, November 1997.) It is difficult to evaluate and monitor even simple in-
dependent, turnkey programs—single software prod-
Background ucts that do not connect to or depend upon other ap-
plication programs (other than an operating system).
Benefits of Clinical Software Systems Such programs are often used ‘‘as is’’ on microcom-
puters in individual practitioners’ offices, and only
Clinical software systems are defined here as individ-
modified when users upgrade to the next version. Ac-
ual computer application programs, or interconnected
cording to a recent survey, individual clinical vendor
groups of such programs, that are directly used in
products number at least several thousand.45 In addi-
providing health care. Clinical software systems re-
tion, there exist thousands of health-related, Internet-
quire supportive environments, including computer
based World Wide Web resources of variable quality.
operating systems and network interfaces. A growing
literature documents how clinical software systems Persons evaluating the performance of a clinical soft-
can improve health care delivery processes and ware system employ numerous criteria in determin-
outcomes.4 – 43 Users employ such systems to track and ing whether a system merits purchase, installation,
manage patient-related information, to retrieve local continued utilization, or approval by a regulatory
and general clinical information, and to apply clinical agency.46 – 52 The appropriateness of a given evaluation
knowledge in making patient-specific decisions. Clin- method varies with the stage of system develop-
ical system usage encompasses hospital information ment.47 While it is important during system develop-
systems and electronic record-keeping4 – 11; clinical ment to evaluate system performance in isolated, ar-
data repositories12 – 13; health service-specific support tificially controlled situations, evaluators of more
(e.g., laboratory, pharmacy, and dietary systems); mature systems should compare clinicians caring for
decision support for diagnosis, therapy, or progno- actual patients using the software to clinicians with-
out access — and not simply report ‘‘system perfor- Evaluation of Clinical Software Systems that
mance’’ on a series of cases. Change Over Time
With respect to patient safety, approval of any sys- A clinical application categorized as ‘‘safe and effec-
tem’s performance should be based on demonstration tive’’ based on extensive testing at its inception might
of either absolute or relative benefit. For absolute ben- become less than effective over time due to improper
efit, system use should cause no measurable harm, or inadequate maintenance. Both system software
produce outcomes at least as good as the status quo, code and the clinical data supporting system func-
and do so at an acceptable cost in time and money. tions may be altered in a manner that invalidates eval-
For relative benefit, system use should demonstrate uation results for previous baseline products. Config-
net improvement over the status quo—i.e., the system uration and integration of complex systems requires
will reduce the overall level of patient morbidity, mor- testing, tuning, correction of software errors, modifi-
tality, or costs, even though the system itself may cations based on installation environments and user
cause adverse effects. For example, electrocardiogram feedback, and upgrades, all of which increase local
(EKG) interpretation programs have acceptable rela- variability over time. These changes occur on an al-
tive benefit in patient care settings because they im- most daily basis. Requiring a formal evaluation of
prove upon many physicians’ ability to rapidly and safety or efficacy related to each system change would
effectively interpret EKGs, even though it is widely paralyze ongoing implementation.
known that they are not as authoritative as expert Users: An Important Consideration in Evaluation
Cardiologists, and may on occasion mislead health and Monitoring
care providers.
Clinical software users include institutions, individual
Evaluation and Monitoring of Complex, health care providers, and the general public, includ-
Interconnected Clinical Software Systems ing patients. In analyzing causes of system-related ad-
A software product may work well in isolation but verse events, it is essential to consider end-user
fail when integrated with other software products or factors.46 – 52 Systems with exemplary hardware and
with unsupported network interfaces. Large clinical software components can cause problems when users
sites (such as tertiary referral centers) contain diverse do not understand system applicability and limita-
hardware platforms, multiple networks, and many tions; when users do not understand how to input
vendors’ software products. Clement J. McDonald re- critical information into the system, when users can-
cently estimated that large U.S. health centers inter- not reliably interpret system output; or when it is dif-
connect several dozen major clinical software systems, ficult to integrate system use into common workflow
consisting of both vendors’ clinical software products patterns. Monitoring to detect problems often requires
and locally developed software programs.44 A dia- aggregation of objective observations from a number
gram of the HELP System, developed at LDS Hospital of sources and a perspective that goes beyond indi-
in Salt Lake City, Utah,6 illustrates how complex such vidual system components. Hence, ‘‘raw’’ complaints
systems can become (Fig. 1). Suppose, for example, from individual users need to be analyzed to deter-
that a small to medium-sized health care institution mine if the problem is in the software or in the user
decides to purchase and connect via a network a se- education program.
ries of applications for their laboratory, pharmacy, ad-
Past and Current FDA Regulation of Clinical
mission/discharge/transfer (ADT), dietary, and cleri-
Software Systems
cal order processing activities. If the institution
considers ten different vendors that produce products Through its mandate from Congress to safeguard the
of the sort being considered, there are 100,000 differ- public, the FDA has regulated marketing and use of
ent basic configurations possible. Major referral cen- medical devices. Section 201(h) of the 1976 Federal
ters install dozens of individual software components, Food, Drug, and Cosmetic Act defines a medical de-
each selected from more than a hundred possible vice as any ‘‘instrument, apparatus, implement, ma-
product configurations (Fig. 1). One hundred choices chine, contrivance, implant, in vitro reagent, or other
for each of 12 components yields a trillion trillion similar or related article, including any component,
(1024) possible overall configurations for each large part, or accessory, which is . . . intended for use in the
site! Because each clinical site combines different soft- diagnosis of disease or other conditions, or in the cure,
ware products in different combinations, a universal mitigation, treatment, or prevention of disease
evaluation of whether or not a given product will . . . or intended to affect the structure or any function
function safely when embedded in a clinical environ- of the body.’’53 The FDA asserts that all clinical soft-
ment is impractical. ware programs, whether associated with biomedical
devices or stand-alone, are ‘‘contrivances,’’ and there-

fore fall within the FDA’s realm of responsibility for
regulating medical devices.
The FDA regulates medical devices that are: (a) com-

mercial products used in patient care; (b) devices used
in the preparation or distribution of clinical biological
materials (such as blood products); or (c) experimental
devices used in research involving human subjects.
Commercial vendors of specified types of medical de-
vices must register as manufacturers with the FDA
and list their devices as products with the FDA. Upon
listing, FDA classifies medical devices by categories.
In its regulation of classified medical devices, the FDA F i g u r e 1 Diagram of HELP Information System at LDS
usually takes one of three courses of action. First, the Hospital, Salt Lake City, Utah.6
FDA can ‘‘exempt’’ specific devices, or categories of
devices, deemed to pose little or no risk. Second, the
FDA employs the so-called 510(k) process—pre-mar- —a single, independent ‘‘turnkey’’ system—was pre-
ket notification —for non-exempt systems. Through viously discussed. However, in the context of FDA
the 510(k) process, manufacturers attempt to demon- discussions, ‘‘stand-alone’’ refers to independence
strate that their devices are equivalent, in purpose and from a traditional (hardware) medical device. Embed-
function, to low-risk (FDA Class I or Class II) devices ded software is often placed on a computer ROM
previously approved by FDA (or to devices marketed (read-only-memory) chip that physically controls all
before 1976). Such devices can be cleared by FDA di- or part of a hardware medical device, such as a lab-
rectly. Finally, the FDA requires pre-market approval oratory auto-analyzer or a cardiac pacemaker. The
(PMA) for higher-risk (FDA Class III) products and FDA regulates any embedded software program as
for products with new (unclassified) designs invented part of the medical hardware device itself.
after 1976. Through the pre-market approval process, In general, the FDA does not actively regulate locally
a manufacturer provides evidence to the FDA that a developed stand-alone software programs, whether
product performs its stated functions safely and effec- developed by an individual or an institution, unless
tively. Evidence for PMAs usually is presented in the special circumstances apply. One such circumstance is
form of controlled trials. Pre-market approval is es- local preparation of FDA-regulated biomaterials, such
pecially important for those products which pose sig- as blood products. The FDA regulates individual
nificant potential clinical risk. Exemption can take stand-alone software products that are commercially
place in two ways: a device can be exempt from reg- marketed by individual manufacturers. It rarely spec-
istration, and thus not subject to 510(k) requirements; ifies or controls how independent vendors’ products
or, a category of listed (classified) devices may be spe- can be combined at a specific site, unless such prod-
cifically exempted from certain regulatory require- ucts are components of a single, larger system, such
ments. Whenever a non-exempt product is modified as a PACS system. This is similar to FDA regulation
substantially (as defined by FDA guidelines), the ven- of commercial pharmaceuticals, wherein the FDA reg-
dor must re-apply to the FDA for new clearance ulates each individual drug comprising a chemother-
through the 510(k) or PMA mechanisms. The pro- apy protocol, but does not regulate multiple drug che-
cesses of 510(k) pre-market notification and pre-mar- motherapy protocols themselves. The requirements
ket approval typically take a few to many months to for re-review are somewhat controversial, in that up-
complete, and may involve numerous exchanges and grading the network operating system of a compo-
iterations. nent part of an FDA-regulated PACS system from ver-
sion 3.1 to version 4.0 could potentially be viewed by
The FDA has a long history of regulating hardware the FDA as requiring resubmission for 510(k) or PMA
medical devices, making it important to distinguish approval. For this reason, the FDA has drafted and
between medical device-associated software and other periodically updated guidelines on when to submit
clinical software. Clinical software can be categorized for re-approval.
as ‘‘stand-alone’’ —external to and independent of a
medical hardware device—or ‘‘embedded’’—an in- In 1986, Frank Young, then director of the FDA, pro-
tegral component of a medical hardware device. Of posed a commendable plan for the oversight and reg-
note, a second connotation of ‘‘stand-alone’’ system ulation of clinical software.54 This plan evolved into a
1989 draft FDA policy statement that was never for- gether to develop common solutions. The Medical Li-
mally adopted. That draft policy has served, until re- brary Association (MLA) is a professional organization
cently, as the basis for the FDA’s actions with respect representing approximately 5,000 individuals and in-
to stand-alone software systems. The 1989 draft policy stitutions involved in the management and dissemi-
recommended that the FDA exempt from regulation nation of biomedical information to support patient
both information-providing educational systems and care, education, and research. MLA members serve so-
systems that generate patient-related advice for clini- ciety by developing new health information delivery
cians in a manner that licensed practitioners (users) systems, fostering educational and research programs
could easily override. During the 1990s, the FDA has for health sciences information professionals, and en-
developed new draft regulations and guidelines for couraging an enhanced public awareness of health care
blood bank software systems55,56 and for PACS sys- issues. The Association of Academic Health Sciences
tems.57 The FDA is developing new guidelines for te- Libraries (AAHSL) is composed of the directors of li-
lemedicine systems as well.58 braries of 142 accredited U.S. and Canadian medical
schools. AAHSL’s goals are to promote excellence in
At present, aspects of FDA regulation of clinical soft- academic health sciences libraries and to ensure that
ware systems can be applied in an arbitrary manner. the next generation of health practitioners is trained in
Although the FDA can initiate review of software prod- information-seeking skills that enhance the quality of
ucts brought to its attention, for the most part, the health care delivery. The American Health Information
agency depends on vendors to submit their products Management Association (AHIMA) is the professional
voluntarily both for initial review, and review after organization of more than 37,000 specialists in secur-
modifications. The review process itself may vary, being, analyzing, and managing patient records and
cause the FDA often employs a variety of different ev- health information. AHIMA members support quality
aluators and consultants in reviewing similar products. patient care through advancing data accuracy, advo-
Some vendors may be more likely than others to con- cating confidentiality, and championing new informa-
sider their software products as requiring FDA review. tion management technology. AHIMA, founded in
1928, accredits educational programs at 250 colleges
and universities and is the certifying agency for health
3 Participating Organizations and information managers and technicians. The American
Consensus Process Nurses Association (ANA) is the only full-service pro-
fessional organization representing the nation’s 2.5 mil-
lion Registered Nurses through its 53 constituent as-
Participating Organizations sociations. ANA advances the nursing profession by
fostering high standards of nursing practice, promoting
The American Medical Informatics Association the economic and general welfare of nurses in the
(AMIA) is a non-profit organization dedicated to im- workplace, projecting a positive and realistic view of
proving health care through the application of infor- nursing, and by lobbying the Congress and regulatory
mation technology. The more than 3,700 members of agencies on health care issues affecting nurses and the
AMIA represent professions associated with health- public. ANA has been involved in healthcare infor-
care informatics —physicians, nurses, biomedical en- matics since the early 1970s and continues to actively
gineers, computer scientists, information scientists, engage in diverse informatics activities. The American
programmer-analysts, librarians, biomedical educa- College of Physicians (ACP) was founded in 1915 to
tors, biomedical researchers, vendor-consultants, den- uphold the highest standards in medical education,
tists, veterinarians, students, and a variety of other practice, and research. Today, the College is the largest
health care practitioners. AMIA’s goals are to promote medical specialty society in the world. It has more than
the development of health care informatics as a rec- 100,000 members, including medical students as well
ognized academic and professional discipline; to help as practicing physicians, and it is the only society of
solve health care problems through informatics re- internists dedicated to providing education resources
search and development; and to promote diffusion of and information resources to the entire field of internal
knowledge in the discipline of health care informatics. medicine as well as its subspecialties. The Center for
The Computer-based Patient Record Institute (CPRI) Healthcare Information Management (CHIM) is a na-
is a non-profit membership organization committed to tional, 100-plus member association for companies
advancing improvements in health care quality, cost supplying information technology products and ser-
and access through routine use of information tech- vices to the healthcare industry—including software
nology. CPRI serves as a neutral forum for bringing suppliers, consultants, hardware firms, network inte-
the diverse interests of all health care stakeholders to- grators, medical imaging companies, publishers, and
executive recruiters. CHIM members seek to bring a Consortium Recommendations

greater understanding and awareness among health-
care professionals as to how information technology The consortium recommends that users, vendors,
can be harnessed to improve the quality and cost-ef- and regulatory agencies (including the FDA) adopt
fectiveness of patient care. the guidelines detailed below. Detailed explanations
and justifications follow in the section after the rec-
Consensus Process
ommendations themselves. The recommendations go
In an attempt to develop a parsimonious approach to beyond the scope of interventions that the FDA or
handling proposals for changed regulations, the FDA other vendor groups would ordinarily undertake,
has conducted, during 1996 and 1997, a series of public since they include clinical software products that are
meetings that have included leaders from the informa- locally developed, shareware, non-commercial, and
tion technology and health care arenas, representative commercial.
professional organizations, and vendors. The first draft
of the consensus recommendations was prepared as a Recommendation 1: We propose four categories of
discussion document by authors RAM and RMG, as clinical software system risks and four classes of mea-
representatives of the American Medical Informatics As- sured regulatory actions as a template for clinical fa-
sociation (AMIA) at the first (and subsequent) public cilities, vendors, and regulatory agencies to use in de-
meetings held by the FDA. Key contributions to the termining how to monitor or regulate any given
evolving position paper were then made by other mem- clinical software system (Tables 1A and 1B).
bers of the AMIA Public Policy Committee and the Recommendation 2: We recommend local oversight
AMIA Board of Directors. After initial endorsement by of clinical software systems whenever possible,
the AMIA Board of Directors, subsequent suggestions through creation of Software Oversight Committees,
and further revisions were contributed by the Center for or ‘‘SOCs’’ (Tables 2A through 2D).
Healthcare Information Management (CHIM); the Com-
puter-based Patient Record Institute (CPRI), the Medical Recommendation 3: Budgetary and other constraints
Library Association, the Association of Academic Health limit the type and number of systems that the FDA
Sciences Libraries (AAHSL), the American Health Infor- can regulate effectively. We recommend that the FDA
mation Management Association (AHIMA), and the focus its regulatory efforts on those systems posing
American Nurses Association (ANA). The Boards of Di- highest clinical risk that give limited opportunities for
rectors (or Regents) of the following not-for-profit or- competent human intervention (Tables 2A–2D). The
ganizations have now endorsed the recommendations majority of clinical software systems should be ex-
entailed in this document: the American Medical Infor- empt from FDA regulation. The FDA should require
matics Association (AMIA), the Computer-based Patient producers of exempt clinical software systems to list
Record Institute (CPRI), the Medical Library Association them as products with the FDA for simple monitoring
(MLA), the Association of Academic Health Sciences Li- purposes—i.e., without having to undergo the 510(k)
braries (AAHSL), the American Health Information or PMA processes. The FDA should develop new,
Management Association (AHIMA), the American comprehensive standards for product labeling that are
Nurses Association (ANA), and the American College appropriate for clinical software products. The FDA
of Physicians (ACP). The Center for Healthcare Infor- should require manufacturers of most exempt and all
mation Management (CHIM) has reviewed successive non-exempt software products to adhere to labeling
drafts of this document and contributed to its writing. standards (Tables 2A–2D).
CHIM is supportive of the consortium’s position, and Recommendation 4: We recommend adoption by
holds the same opinions expressed in this document in health care information system vendors and local soft-
all areas except for the definitions for proposed risk cat- ware producers of a code of good business practices.
egories of clinical software systems and classes of reg- The practices should include (but not be limited to)
ulations. The Appendix presents an algorithm prepared guidelines for quality manufacturing processes; stan-
by CHIM suggesting how the FDA might review stand- dardized, detailed product labeling; responsible ap-
alone clinical software systems for regulatory purposes. proaches to customer support; and, adoption of in-
It should be noted that, while CHIM includes in its dustry-wide standards for electronic information
membership a number of commercial vendors from the handling and sharing—including standards for
healthcare information industry, the viewpoints of in- health care information format, content, and trans-
dividual members have not been represented in this
port.
consensus document, and the original and subsequent
drafts of the consortium’s recommendations have been Recommendation 5: We recommend that health in-
prepared and endorsed by not-for-profit organizations. formation-related organizations work together with
Table 1A 䡲
Consortium Recommendations for Risk-based Categories of Clinical Software Systems

Category Description Category Description
0 Informational or generic systems that provide provide easy opportunities for practitioners to
factual content (electronic textbooks); verifia- ignore or override them. For example, systems
bly calculate (showing all parameters used) in this category might recommend a single pa-
simple quantities, such as drug dosage tient-specific therapy over a number of alter-
based on body weight; or give simple, native forms of therapy; recommend that the
straightforward advice based on user-re- practitioner commit to (conclude) a specific di-
viewed guidelines (e.g., ‘‘give potassium agnosis from a patient-specific differential di-
supplementation to patients receiving diagnosis; or guide patients in determining
goxin who are hypokalemic’’). Includes which advanced-care directives might be ap-
‘‘content-free’’ generic software such as gen- propriate for their situation. Systems in this
eral database programs, generic spreadsheet category might also store and transmit patient-
programs. Non-clinical systems also fall in specific instructions for life-critical care (e.g.,
this category. ventilator management or chemotherapy or-
ders) to practitioners in a manner that is
1 Low-risk, patient-specific systems that perform easily verified.
complex health-related functions with rela-
tively low clinical risk and provide ample 3 High-risk, patient-specific systems that pro-
opportunities for practitioners to ignore or vide complex, health-related functions that
override them. Such systems might non- have high clinical impact and provide little
judgmentally suggest a number of alterna- if any opportunity for practitioners to inter-
tive forms of therapy; list a comprehensive vene in their function or to override them.
patient-specific differential diagnosis with- For example, systems in this category might
out making a conclusion; or provide an esti- include individualized chemotherapy mixing
mate of the patient’s prognosis based on and dispensing systems, systems that auton-
matched cases from a clinical database. Sys- omously plan courses of radiation therapy
tems in this category might also store and for uploading into automated equipment to
transmit patient-specific ‘‘passive’’ data (e.g., deliver the therapy, and systems that moni-
laboratory results or clinical reports) in a tor physiological parameters and automati-
manner that is easily verified. cally adjust settings related to therapy (for
example, a ventilator ‘‘auto-pilot’’).
2 Intermediate-risk, patient-specific systems that
provide complex, health-related functions
that have relatively high clinical risk, but
other groups, including clinical professional associa- use; (b) the extent of system autonomy from user
tions, vendor organizations, regulatory agencies, and oversight and control—the inability for qualified
user communities, to advance our understanding and users, such as licensed practitioners, to recognize
knowledge of approaches to regulating and monitor- and easily override clinically inappropriate recom-
ing clinical software systems. mendations (or other forms of substandard software
performance); (c) the pattern of distribution and de-
gree of support for the software system, including lo-
Explanation and Justification for cal customization; (d) the complexity and variety of
Consortium Recommendations clinical software environments at installation sites; (e)
evolution of systems and their environments over
Explanation of Recommendation 1: Risk and time; and, (f) the ability of proposed monitors or reg-
Regulatory Categories ulators to detect and correct problems in a timely
manner that protects patients. The ability of licensed
Software installation and maintenance must be treated clinician-users to override a system should be a con-
as a process, not a single event. Review of a software sideration for decreased regulatory intervention. It is
environment at one point in time does not guarantee important to identify the most logical forum for sys-
safety or efficiency at a later point in time. Decisions tem oversight. The best choice will often be local mon-
about whether to install and how to monitor clinical itoring through SOCs (as described below), rather
software systems should take into account: (a) the than nationally centralized data collection and moni-
clinical risks posed by software malfunction or mis- toring.
Table 1B 䡲
Consortium Recommendations for Regulatory Classes

Class Description Recommendation
A Exempt from FDA regulation; local SOC monitoring op- Good business practices would be applied by develop-
tional ers, vendors, and users.
B Exempt from FDA regulation; local SOC monitoring Commercial products in this category should adhere to
mandatory product labeling standards, and commercial vendors
should list products with FDA for simple identifica-
tion purposes (no FDA review required). Good busi-
ness practices recommended. Standardized surveys of
isolated users could be conducted on request by the
FDA (or FDA-approved regional organizations) for in-
dividuals who lack resources or expertise to imple-
ment local monitoring and review guidelines. The
FDA would serve as a consultant to manufacturers,
vendors, and SOC committees, rather than as a regu-
lator.
C Simplified, expedited initial FDA approval through ver- Good business practices required. Reporting and re-
ification that product labeling is accurate and adheres cording of adverse events required with FDA collat-
to standards; mandatory listing of products with FDA ing and aggregating standardized reports after local
for post-marketing surveillance; application of usual collection and verification. FDA can require vendors
FDA 510(k) or PMA processes to any products with unusually large number of unexplained adverse
generKating concerns during post-marketing surveil- event reports to undergo 510(k) or PMA to document
lance; local SOC monitoring mandatory. safety and efficacy. In such trials, FDA should employ
standard that the system demonstrates absolute or
relative benefit (as defined above). Vendors required
to maintain lists of users of each version of each sys-
tem in this class.
D Usual FDA 510(k) or PMA processes applied prior to Prior to marketing, vendors must submit to FDA evidence
marketing; local SOC monitoring mandatory. that system safely and efficaciously performs its stated
functions. Good business practices required. Vendors
must maintain lists of users of each version. Recording
of adverse events required locally and reported to FDA
using standardized forms for aggregation of data.
Troubleshooting activities aggregated locally and re-
ported after filtering to FDA. FDA may require addi-
tional testing if the rate of adverse events is too high.
We have proposed categories of clinical software sys- dor-level controls for the majority of clinical software
tems based on patient risk and classes of regulatory products, rather than to mandate comprehensive,
interventions, as detailed in Tables 1A and 1B. Tables cumbersome, inefficient, and costly national-level
2A through 2D represent our recommendations on monitoring.
how to apply the classes of regulatory actions respon-
sibly to all clinical systems, based on the systems’ risk Institutional Review Boards (IRBs) provide an exam-
categories. The recommendations in Tables 2A ple of a local monitoring process that is in widespread
through 2D cannot be carried out solely by the FDA use.59 – 61 In order to protect the human subjects of re-
or by local institutions, vendors, or users. A combined search, federal law has required each clinical facility
approach with shared responsibilities is required. The engaged in patient research have an IRB to review,
consortium recommendations represent such an ap- approve, and monitor research protocols locally. Each
proach. IRB includes clinical experts, administrators, individ-
uals familiar with research study designs and meth-
Explanation of Recommendation 2: Local ods, and persons experienced in data analysis. Some
Monitoring of Clinical Software Systems IRBs also include laypersons as representatives of the
patient community. The IRBs review the purpose of
Local software installation sites have the greatest abil- proposed research; the anticipated benefits to individ-
ity to detect software problems, analyze their impact, uals and to the general community; the risks to sub-
and develop timely solutions. It would be advanta- jects in terms of health outcomes, pain and suffering,
geous to develop a program of institutional- and ven- and expenses; informed consent, voluntary participa-
Table 2A 䡲 tion’s (ISO) 9000 guidelines62 for quality manufactur-

Proposed Classes of Clinical Software Exemptions ing processes. More than 80 countries have adopted
and Regulation by Category of Software the ISO 9000 for consistency in manufacturing pro-
cesses. ISO 9000 requires that manufacturers produce
Type of
Software Description
explicit documentation for accepted procedures for all
business activities; implement methods to prove that
Class A Software exempt from FDA regulation; lo- procedures are followed correctly and perform their
cal SOC monitoring optional. (Please re-
fer to definitions of risk categories and
intended functions; conduct audits of process quality;
regulatory classes in Table 1.) and implement improvements or corrections when
Category 0 Informational or generic products problems are detected. The SOCs would monitor pro-
Category 0 Non-clinical systems cedures by which an institution goes through opera-
Any system not directly involved in patient tional needs assessment; specification of desired sys-
care and any system not serving as an
integral component of a larger system
tem functions; selection of vendors’ products (or local
providing patient care — i.e., systems that product design and development); testing of products
do not play any role in suggesting diag- in a realistic environment before going ‘‘live’’; ade-
noses, suggesting prognoses, or suggest- quate training of prospective users; installation and
ing or implementing orders or treat- follow-up during and after installation of software
ments.
systems; monitoring of users’ competencies and com-
plaints; and the adequate provision of a ‘‘help desk’’
tion, and ability to withdraw from the research study; tied to documentation procedures and methods for
and the plans for monitoring and conduct of the re- making software improvements. SOCs could help en-
search protocol itself—e.g., ability to detect adverse sure that institutions build clinical enterprises to-
outcomes or grossly positive benefits so that the study
can be terminated early, if indicated. In making deci-
Table 2B 䡲
sions, the locally autonomous IRBs can take regional
demographics, local practice patterns, patient con- Proposed Classes of Clinical Software Exemptions
cerns, and individual researchers’ skills and past and Regulation by Category of Software
records into account much more efficiently and effec- Type of
tively than could a centralized national agency. Software Description
While IRBs per se are not well qualified to review and Class B Software Exempt from FDA regulation; lo-
monitor clinical software systems, they provide a cal SOC monitoring required. (Please re-
model for creating a multidisciplinary team with ap- regulatory classes in Table 1.)
propriate expertise at the local level. Local and re- All Category 1 All low-risk, patient-specific, low-impact
gional Software Oversight Committees (SOCs) could software giving adequate control to li-
enlist members with expertise in health care infor- censed practitioner (easily overridden).
matics, clinical practice, data quality, biomedical Some Category 2 Intermediate-risk, high-impact patient-spe-
cific software giving adequate control to
ethics, patients’ perspectives, and quality improve- licensed practitioner (easily overridden),
ment. When the complexity, diversity, and number of including locally developed or ‘‘share-
clinical software and computer hardware products at ware’’ non-commercial software systems;
an installation site reach a critical size, a local SOC local SOC monitoring recommended for
should be formed to review clinical software on an such software. EXCEPT: Category 2 sys-
tems commercially distributed that are
ongoing basis within the institution. On a similar not modified in any way locally and
note, the Joint Council for the Accreditation of Health- that do not serve as part of an inte-
care Organizations (JCAHO) reviews organizations’ grated local system.
systems and processes for improving their perfor- Some Category 3 Locally developed, non-commercial, pa-
mance, and specifically includes information manage- tient-specific, high-impact systems with
minimal ability of practitioner to over-
ment as one of the areas reviewed. Small practitioners’ ride. It is mandatory, on an ethical basis,
offices or smaller community hospitals without ade- that such systems have careful local re-
quate expertise could participate in regional SOCs, or view and institutional oversight through
possibly request consultations from local SOCs at both IRBs and SOCs. Such systems
larger institutions. should adhere to product labeling stan-
dards and be registered for simple iden-
The SOCs would develop and follow guidelines for tification purposes with FDA, even
local or regional software quality maintenance similar though non-commercial. EXCEPT: Cate-
gory 3 systems distributed commercially.
to the International Organization for Standardiza-
Table 2C 䡲 worded new policy. The FDA should now define ex-
Proposed Classes of Clinical Software Exemptions plicitly the categories of clinical software systems that
and Regulation by Category of Software will be exempt from its regulation. Recently, the Cen-
ter for Healthcare Information Management (CHIM)
Type of
Software Description has prepared an algorithm, expressed in the form of
a flow sheet, suggesting how the FDA might go about
Class C Software subject to simplified, expedited
classifying stand-alone clinical software systems for
initial FDA approval through verifica-
tion that product labeling is accurate regulatory purposes (see Appendix). This document
and adheres to standards; mandatory has not been reviewed for endorsement by consor-
listing of products with FDA for post- tium members. However, the document is consistent,
marketing surveillance; application of for the most part, with the portion of consortium rec-
usual FDA 510(k) or PMA processes to
ommendations related to the FDA.
any products generating concerns dur-
ing post-marketing surveillance; local Other than exemption, the two actions now available
SOC monitoring mandatory. (Please re-
to FDA for medical software devices—the 510(k) pro-
regulatory classes in Table 1.) cess and the PMA process—are inappropriately cum-
Some Category 2 Intermediate-risk, high-impact, patient- bersome for all but the highest risk category of clinical
specific software giving adequate control software systems. However, the FDA might serve a
to licensed practitioner (easily overrid- less intrusive monitoring role by requiring producers
den), commercially distributed and not
of exempt clinical software systems to list them as
modified in any way locally.
products with the FDA for monitoring purposes,
without having to undergo the 510(k) or PMA pro-
ward a reference architecture with a modular design cesses. By assigning a universal registration ID to each
so that components can be replaced as they are out- product, the FDA could develop a centralized data-
dated. base repository for collecting information on adverse
SOCs would work with system administrators, users, clinical software events. Reporting of problems with
and vendors to make sure there is ongoing monitor- individual products could come to the FDA through
ing to detect adverse events, address them, and to in- SOCs, or from individual users in sites without SOCs.
sure that the overall system performs as designed; The FDA could then collect and distribute aggregated,
and, that adequate attention is paid by vendors to standardized reports of system-specific and global
make sure that vendor-product related problems de- problems (including interactions).
tected are corrected in a timely manner (appropriate Another beneficial role the FDA could play would be
for the clinical risk posed by the problem). It would to develop, in conjunction with vendors, clinical sites,
also be important to develop ethical guidelines that professional organizations, and users, new, compre-
would specify behavior for employees and SOC com- hensive standards for clinical software product label-
mittee members who might have special relationships ing. Labels should describe system requirements,
with vendors or have software-related companies of functions, document sources of medical information,
their own. and describe limitations of use. Labeling standards for
Explanation of Recommendation 3: A Focused
FDA Strategy for Exemption and Regulation of Table 2D 䡲
Clinical Software Systems Proposed Classes of Clinical Software Exemptions
The consortium recommends local oversight of clini- and Regulation by Category of Software
cal software systems through SOCs (as described Type of Software Description
above) whenever possible, and adoption by health Class D Software subject to FDA 510(k) and PMA
care information system developers and vendors of a approval before marketing; Local SOC
code of good business practices (see Explanation of monitoring mandatory. (Please refer to
Recommendation 4, below). Governmental regulators definitions of risk categories and regula-
have a legislative obligation to play a meaningful role tory classes in Table 1.)
Some Category 3 High-risk, high-impact, patient-specific
in assuring patient safety. To maximize benefit of FDA software giving adequate control to li-
efforts, we believe that the agency should focus on censed practitioners (not easily overrid-
those commercial stand-alone systems presenting the den), commerically distributed and not
highest degree of clinical risk (as defined in Tables 1A modified significantly locally. Systems
and 2A to 2D). The FDA should move to formalize would also adhere to product labeling
standards.
the spirit of the 1989 FDA draft policy54 in a clearly
clinical software would be different than existing FDA to be upgraded or replaced. Users and/or external re-
standards developed primarily for hardware medical viewers should determine if upgrades are of profes-
devices. The FDA could require manufacturers of both sional quality. Vendors and users should verify that
exempt and non-exempt software products to adhere upgrades are made available or distributed to all who
to the labeling standards. As noted in Table 2C, the should receive them. Vendors should help local users
FDA could modify its approach to certain intermedi- to ensure that only users who are well qualified (i.e.,
ate-risk commercial products by creating an expedited possess sufficient biomedical knowledge) and well
process to verify that the product’s labeling conforms trained (i.e., have adequate skill in using the program)
to FDA standards. The FDA would then assign a post- will have access to a given clinical software system.
marketing surveillance ID to such products and care- In addition to standard software version control prac-
fully monitor for evidence of adverse effects. If a suf- tices, developers should document sources and dates
ficient number of concerns were raised during of creation/revision for biomedical knowledge em-
product monitoring, the manufacturer would then be bedded in software programs. Manufacturers should
required to submit full-scale 510(k) or PMA applica- disclose any known risks and limitations associated
tions to be permitted to continue marketing. with a clinical software product, and inform users of
their responsibility to detect and override faulty sys-
Explanation of Recommendation 4: Adoption of tem recommendations. ‘‘Outdated’’ systems should
Guidelines by Clinical Software Producers advertise to users that their components are poten-
and Distributors tially invalid—e.g., through start-up screens that
The health care information system industry, through force users to acknowledge that the system is out-
the Center for Healthcare Information Management dated before allowing the users to proceed, or through
(CHIM), is in the process of refining its code of good prominent banners displayed at all times during sys-
business practices. This code, in conjunction with ISO- tem usage. If warnings are not adequate for high-risk
9000, is expected to address use of sound software or significantly compromised outdated components,
development and implementation methods appropri- the system might simply prevent users from using
ate to the level of clinical risk posed by a software outdated functions by removing access to the func-
system. It will also address the need for adequate tions from the system. Vendors, as well as regulators,
training, for support of open industry standards for should provide standardized forms and convenient
messages and communication, for protecting patient avenues for problem reporting. Manufacturers should
confidentiality, and for other relevant matters. Adher- ensure that notification procedures are in force for
ence to the guidelines should be strongly encouraged higher-risk product categories to ensure users are
for all clinical software systems, and be mandatory for aware of product alerts, recalls, and upgrades. Man-
higher-risk systems. The FDA Current Good Manu- ufacturers should continue to utilize guidelines that
facturing Procedures (CGMPs) for individual prod- protect patients and users through the expedited, ef-
ucts may not work effectively for the complex soft- ficient testing of new system components and up-
ware environments in large health care delivery grades. Last but not least, manufacturers should
facilities (see Fig. 1). The FDA currently requires med- adopt and adhere to, whenever possible, national or
ical device manufacturers to comply with ISO-9000- international standards for data representation and
like regulations as part of their manufacturing pro- exchange.63
cess. Through SOCs, local institutions should develop
guidelines for the acquisition, testing, installation, Explanation of Recommendation 5:
training, and monitoring of the potentially complex Collaboration to Evolve Clinical Software
systems under their control, in the spirit of ISO-9000. Monitoring and Regulation
Local SOCs should also oversee implementation and
Institutions with installed advanced health care infor-
monitoring of local guidelines, and interinstitutional
mation systems should implement SOCs and share
sharing of experiences.
their experiences and recommendations with others.
Examples of guidelines for good business practices in- The expanded consortium, consisting of clinical pro-
clude the following: Manufacturers should disclose fessional associations, vendor organizations, regula-
existing evaluations of software products (noting how tory agencies, and user communities, should evolve
they relate, if at all, to the current product) for users the guidelines contained in recommendations 1
to review before purchasing systems. Developers through 4 as they gain increasing experience with
should help users to estimate how often and by what approaches to monitoring and regulating clinical
mechanism system components—including databases software systems. Focus groups, the peer-reviewed
or knowledge bases, as well as software code—need literature, regional and national conferences, Internet-
based information resources, and other means should diological Health. Announcements and minutes of meetings
on future regulation of stand-alone clinical software sys-
be used to disseminate the information.
tems. 1996 – 1997. FDA Web site: http://www.fda.gov/cdrh
3. AMIA News. J Am Med Inform Assoc. 1994;1:91 – 2.
Summary 4. Institute of Medicine. Dick RS, Steen EB (eds). The com-
puter-based patient record: an essential technology for
Clinical software systems are ubiquitous. A growing health care. Washington DC: National Academy Press. 1991.
literature documents the benefits of such systems for 5. Ball MJ, Collen MF (eds). Aspects of the Computer-based
improved health care delivery. While no reports sug- Patient Record: Computers in Health Care Series. New
York: Springer-Verlag, 1992.
gest that many patients are being harmed by stand-
6. Kuperman GJ, Gardner RM, Pryor TA. HELP: A Dynamic
alone clinical software systems, concerns for patient Hospital Information System. New York: Springer-Verlag,
safety must be addressed. The consortium recom- 1991.
mends local oversight of clinical software systems 7. McDonald CJ, Tierney WM, Overhage JM, Martin DK, Wil-
through Software Oversight Committees (SOCs), and son GA. The Regenstrief Medical Record System: 20 years
of experience in hospitals, clinics, and neighborhood health
adoption by health care information system vendors
centers. MD Comput. 1992;9:206 – 17.
of a code of good business practices. Budgetary and 8. Barnett GO. The application of computer-based medical rec-
other constraints limit the type and number of sys- ord systems in ambulatory care. N Engl J Med. 1984;310:
tems that the FDA can regulate effectively. Most clin- 1643 – 50.
ical software systems should be exempted from FDA 9. McDonald CJ, Tierney WM. Computer-stored medical
records: their future role in medical practice. JAMA. 1988;
regulation. FDA regulation should focus on patient-
259:3433 – 40.
specific commercial software systems that pose high 10. Garrett LE Jr, Hammond WE, Stead WW. The effects of
clinical risk (e.g., directly control life support systems computerized medical records on provider efficiency and
or directly administer potentially dangerous thera- quality of care. Meth Inform Med. 1986;25:151 – 7.
pies) that are not modified locally (i.e., are not under 11. Rector AL, Glowinski AJ, Nowlan WA, Rossi-Mori A. Med-
ical-concept models and medical records: an approach
local programming control) and which offer little or
based on GALEN and PEN&PAD. J Am Med Inform Assoc.
no opportunity for practitioner intervention. For such 1995;2:19 – 35.
‘‘closed loop’’ systems, based on the degree of risk 12. Yount RJ, Vries JK, Councill CD. The Medical Archival Sys-
posed, we recommend the traditional FDA 510(k) no- tem: an Information Retrieval System based on Distributed
tification process and full-scale pre-market approval. Parallel Processing. Information Processing & Management.
1991;27:379 – 89.
During pre-market trials for such narrowly defined,
13. Vries JK, Yount RJ, Singh J: Total integration of health center
high-risk, closed loop systems, it must be demon- information through distributed parallel processing. HIMSS
strated that the systems cause no harm, or, alterna- Proceedings. 1994;4:241 – 52.
tively, that the automated systems improve upon im- 14. Warner HR, Toronto AF, Veasey LG, Stephenson RA. Math-
perfect baseline (manual) systems at a tolerable ematical approach to medical diagnosis. JAMA. 1961;177:
(non-zero) level of risk and at an affordable cost. 75 – 81.
15. Gorry GA, Barnett GO: Experience with a model of sequen-
We have provided recommendations on how to de- tial diagnosis. Computers & Biomedical Research. 1968;1:
velop and realize processes for responsible monitor- 490 – 507.
16. Bleich HL. Computer evaluation of acid-base disorders. J
ing and regulation of clinical software systems. Our
Clin Invest. 1969;48:1689 – 96.
goal is to encourage a coordinated effort to safeguard 17. Horrocks JC, McCann AP, Staniland JR, Leaper DJ, de Dom-
patients, users, and institutions as clinical systems are bal FT: Computer-aided diagnosis: description of an adapt-
implemented to improve clinical care processes. able system, and operational experience with 2,034 cases.
Br Med J. 1972;2:5 – 9.
18. Pauker SG, Gorry GA, Kassirer JP, Schwartz WB: Toward
This document represents the opinions of the authors and of
the simulation of clinical cognition: taking a present illness
participating consortium organizations, and it does not repre-
by computer. Am J Med. 1976;60:981 – 96.
sent positions of the FDA or of other governmental or regula-
19. Shortliffe EH. Computer-Based Medical Consultations: MY-
tory agencies. The authors thank Harold M. Schoolman, MD,
CIN Artificial Intelligence Series. New York: Elsevier Com-
for his insightful comments during the drafting and revision of
puter Science Library, 1976.
this manuscript. The American Thoracic Society, the Association
20. Yu VL, Fagan LM, Wraith SM, et al: Antimicrobial selection
of Operating Room Nurses, the American Association of Oc-
by computer: a blinded evaluation by infectious disease ex-
cupational Health Nurses, the National Association of School
perts. JAMA. 1979;242:1279 – 82.
Nurses, the Society of Gastroenterology Nurses and Associates,
21. Blois MS. Judgement and computers. N Engl J Med. 1980;
and the American Radiological Nurses Association have sent
303:192 – 7.
letters of support.
22. Miller RA, Pople HE Jr, Myers JD: Internist-1: an experi-
mental computer-based diagnostic consultant for general
References 䡲 internal medicine. N Engl J Med. 1982;307:468 – 76.
23. Barnett GO, Cimino JJ, Hupp JA, Hoffer EP: DXplain: an
1. Federal Register. July 15, 1996. 61:36886 – 7. evolving diagnostic decision-support system. JAMA. 1987;
2. Food and Drug Administration Center for Devices and Ra- 258:67 – 74.
24. Warner HR, Haug P, Bouhaddou O, et al. ILIAD as an 45. Slack W (ed). Medical hardware and software buyer’s
expert consultant to teach differential diagnosis. Proc guide. MD Comput. 1996;13:485 – 576.
Twelfth Ann Symp Comput Appl Med Care. New York: 46. Friedman CP, Wyatt JC. Evaluation methods in medical in-
IEEE Computer Society Press, 1987;371 – 6. formatics. New York: Springer-Verlag, 1997.
25. Bankowitz RA, McNeil MA, Challinor SM, Parker RC, Ka- 47. Stead WW, Haynes RB, Fuller SL, et al. Designing medical
poor WN, Miller RA: A computer-assisted medical diag- informatics research and library-resource projects to in-
nostic consultation service. Implementation and prospective crease what is learned. J Am Med Inform Assoc. 1994;1:
evaluation of a prototype. Ann Intern Med. 1989;110:824 – 28 – 34.
32. 48. Tierney WM, Overhage JM, McDonald CM. A plea for con-
26. Miller RA. Medical diagnostic decision support systems — trolled trials in medical informatics. J Am Med Inform As-
past, present, and future. J Am Med Inform Assoc., 1994;1: soc. 1994;1:353 – 4.
8 – 27. 49. Schoolman HM. Obligations of the expert system builder:
27. McDonald CJ. Protocol-based computer reminders, the meeting the needs of the user. MD Comput. 1991;8:316 – 21.
quality of care and the non-perfectability of man. N Engl J 50. East TD, Morris AH, Wallace CJ, et al. A strategy for de-
Medicine. 1976;295:1351 – 5. velopment of computerized critical care decision support
28. McDonald CJ, Wilson GA, McCabe GP Jr. Physician re- systems. Intl J Clin Monit Comput. 1992;8:263 – 9.
sponse to computer reminders. JAMA. 1980;244:1579 – 81. 51. Miller RA. Why the standard view is standard: people, not
29. Tierney WM, Hui SL, McDonald CJ. Delayed feedback of machines, understand patients’ problems. J Med Philos.
physician performance versus immediate reminders to per- 1990;15:581 – 91.
form preventive care: effects on physician compliance. Med- 52. Miller RA, Schaffner KF, Meisel A. Ethical and legal issues
ical Care. 1986;24:659 – 66. related to the use of computer programs in clinical medi-
30. Tierney WM, McDonald CJ, Martin DK, Rogers MP. Com- cine. Ann Intern Med. 1985;102:529 – 36.
puterized display of past test results: effect on outpatient 53. Public Law 94-295. Medical Device Amendments to the
testing. Ann Intern Med. 1987;107:569 – 74. Federal Food, Drug, and Cosmetic Act (passed on May 28,
31. Tierney WM, McDonald CJ, Hui SL, Martin DK. Computer 1976).
predictions of abnormal test results: effects on outpatient 54. Young FE. Validation of medical software: present policy of
testing. JAMA. 1988;259:1194 – 8. the Food and Drug Administration. Ann Intern Med. 1987;
32. McDonald CJ. Computers. JAMA. 1989;261:2834 – 6. 106:628 – 29.
33. Tierney WM, Miller ME, McDonald CJ. The effect on test 55. FDA Center for Biologics Evaluation and Research, Office
ordering of informing physicians of the charges for outpa- of Blood Research and Review, Office of Compliance, Office
tient diagnostic tests. N Engl J Med. 1990;322:1499 – 504. of Regulatory Affairs. Draft Guideline for the Validation of
34. McDonald CJ, Overhage JM. Guidelines you can follow and Blood Establishment of Computer Systems. Issued Septem-
can trust: an ideal and an example. JAMA. 1994;271:872 – 3. ber 20, 1994. Available from FDA WWW Site: http://
35. Evans RS, Larsen RA, Burke JP, et al. Computer surveillance www.fda.gov
of hospital-acquired infections and antibiotic use. JAMA. 56. FDA Center for Biologics Evaluation and Research, Office
1986;256:1007 – 11.
of Blood Research and Review. Draft Reviewer Guidance
36. Pestotnik SL, Evans RS, Burke JP, Gardner RM, Classen DC.
for a Pre-Market Notification Submission for Blood Estab-
Therapeutic antibiotic monitoring: surveillance using a
lishment Computer Software. Issued April 12, 1996. Avail-
computerized expert system. Am J Med. 1990;88:43 – 8.
able from FDA WWW Site: http://www.fda.gov
37. Gardner RM, Golubjatnikov OK, Laub RM, Jacobson JT,
57. FDA Center for Devices and Radiological Health. Guidance
Evans RS. Computer-critiqued blood ordering using the
for the Content and Review of 510(K) Notifications for
HELP system. Computers & Biomedical Research. 1990;23:
Picture Archiving and Communications Systems (PACS)
514 – 28.
and Related Devices, Issued August 1, 1993. Available
38. Classen DC, Evans RS, Pestotnik SL, Horn SD, Menlove RL,
from FDA WWW Site: http://www.fda.gov//cdrh/ode/
Burke JP. The timing of prophylactic administration of an-
odeot416.html
tibiotics and the risk of surgical-wound infection. N Engl J
Med. 1992;326:281 – 6. 58. FDA Center for Devices and Radiological Health. Tele-
39. Hickam DH, Shortliffe EH, Bischoff MB, Scott AC, Jacobs medicine Related Activities. Issued July 11, 1996. Available
CD. The treatment advice of a computer-based cancer che- from FDA WWW Site: http://www.fda.gov//cdrh/tele-
motherapy protocol advisor. Ann Intern Med. 1985;103: med.html
928 – 36. 59. National Commission for the Protection of Human Subjects
40. Musen MA, Carlson RW, Fagan LM, Deresinski SC, Shor- of Biomedical and Behavioral Research. Ethical principles
tliffe EH. T-HELPER: automated support for community- and guidelines for the protection of human subjects of re-
based clinical research. Proc Annu Symp Comput Appl Med search (The Belmont Report). Federal Register, Document
Care. 1992;719 – 23. 79-12065, April 17, 1979.
41. Institute of Medicine. Telemedicine: A Guide to Assessing 60. Protection of Human Subjects. Code of Federal Regulations,
Telecommunications in Health Care. Washington, DC. Na- Title 45, Part 46, June 18, 1991.
tional Academy Press, 1996. 61. FDA. FDA information sheets for IRBs and clinical investi-
42. Willems JL, Abreu-Lima C, Arnaud P, et al. The diagnostic gators. Issued October 1, 1995. Available from FDA WWW
performance of computer programs for the interpretation of Site: http://www.fda.gov
electrocardiograms. N Engl J Med. 1991;325:1767 – 73. 62. Organization for International Standards. ISO 9000 News
43. Becker SH, Arenson RL. Costs and benefits of picture ar- Service, 1996 – 97. Documentation available from: http://
chiving and communication systems. J Am Med Inform As- www.iso.ch
soc. 1994;1:361 – 71. 63. AMIA Board of Directors. Standards for medical identifiers,
44. McDonald CJ. The barriers to electronic medical record sys- codes, and messages needed to create an efficient computer-
tems and how to overcome them. JAMIA. 1997;4:222 – 32. stored record. J Am Med Inform Assoc. 1994;1:1 – 7.
APPENDIX
Appendix Flow diagram prepared by Center for Healthcare Information Management (CHIM) Suggesting Possible
Decision Algorithm for FDA to Use in its Regulation of Stand-alone Clinical Software Systems as Medical Devices.
Question 1. Is the "stand-alone" software a medical device?
1.1 Is the software sold

(or otherwise commercially
provided) to clinical No Stop, not a medical device
practitioners and/or
institutions?
Yes
1.2 Is the software

embedded in the Refer to FDA Guidance on
Yes
medical device? embedded software
No
1.3 Is the software

an accessory to a Refer to FDA Guidance on
Yes
medical device? accessory software
No
• Used in financial management

1.4 Is the software • Used in administrative management
used in the process • Used in clinical practice management
No Stop, not a medical device
of delivering care • Used in library functions
to a patient? • Used in professional education
Yes
Proceed to
Question 2.
Appendix continued on next page.

Question 2. What are the risks or hazards associated with and the level of concern for the "stand-alone
software"?
2.1 Is the
software a general Yes Exempt from active regulation
purpose article?
No
2.2 Is the software

developed by practitioner Yes Exempt from active regulation
for noncommercial use
in own practice?
No
2.3 Is software's data used

in immediate decisions that
May represent higher level of
could cause death or serious Yes
concern—See FDA guidance.
injury without competent
user review?
No
2.4 Does failure of software

Are there factors that can May represent higher level of
directly caused death or Yes No
be used to reduce hazard? concern—See FDA guidance.
serious injury?
No Yes
Proceed to 2.5
(next page)
2.5 Checklist to establish

suitability for exemption
from active regulation
Software provides or replaces existing software applications with

well understood functions and no history of adverse events. Yes
Software automates well-understood manual/paper

Yes
based processes.
Software simply manages data from clinicians. Yes
Software allows intended/competent user intervention. Yes
Software allows competent user organization to evaluate and test. Yes
Software assures back-end integrity. Yes
System failure does not cause software to add risk to patient. Yes
Software automates difficult manual/paper based functions. Yes
Software monitors events and alerts but takes no action.
Yes Yes
2.6 Is software
characterized by one No Re-evaluate.
or more indicators?
Yes
2.7 Will complete, accurate

labeling provide user with
No Re-examine.
adequate information to
use safely?
Yes
2.8 Software is exempt

from active regulation.

Grassley Feb 24 Letters

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Grassley Feb 24 Letters

Hochgeladen von

Copyright:

Verfügbare Formate

February 24, 2010

Via Electronic Transmission

The Honorable Kathleen Sebelius

Dear Secretary Sebelius:

As Ranking Member of the Senate Committee on Finance (Committee), which

I am also enclosing for your consideration an article entitled, “Recommendation

1) What is the Department’s position on the proposals in the JAMIA article?

2) To what extent have the recommendations regarding FDA’s regulation of HIT

4) Earlier this month, I submitted questions to you following the Committee’s

6) The JAMIA article discussed the evaluation of complex, interconnected systems,

a. Has HHS considered establishing local or regional oversight committees

b. To what extent should the Regional Extension Centers and/or Beacon

cc: The Honorable Margaret A. Hamburg

Via Electronic Transmission

Dear Mr. Patterson:

The United States Senate Committee on Finance (Committee) has jurisdiction

In addition, it has been reported that HIT/CPOE manufacturers rely on a legal

Furthermore, it was also reported to me that there is no system in place to track,

3) Does Cerner incorporate the “learned intermediaries” doctrine in the HIT/CPOE

5) Please provide a copy of communications, including but not limited to

8) Has Cerner executed any settlement agreements relating either directly or

In cooperating with the Committee’s review, no documents, records, data or

3. No documents, records, data or information requested by the Committee shall be

5. In complying with this document request, respond to each enumerated request by

5. The term “communication” means each manner or means of disclosure or

Via Electronic Transmission

Glenn Steele Jr. M.D., PhD.

Dear Dr. Steele:

As Ranking Member of the Senate Committee on Finance, which has jurisdiction

In recent legislation, approximately $19 billion in taxpayer funds was

a. What is the personnel structure of those involved in the purchase?

c. Who or what department within your facility is responsible for making

3. Please describe the training process implemented in your facility to familiarize

a. How does your facility budget for HIT training?

a. HIT vendors that manufacture software, hardware and/or other products

Recommendations for Responsible Monitoring

JAMIA 1997 4: 442-457

Updated information and services can be found at:

Article cited in:

To order reprints of this article go to:

To subscribe to Journal of the American Medical Informatics Association go to:

442 MILLER, GARDNER, Monitoring and Regulation of Clinical Software

Responsible Monitoring and

A b s t r a c t In mid-1996, the FDA called for discussions on regulation of clinical software

444 MILLER, GARDNER, Monitoring and Regulation of Clinical Software

devices or stand-alone, are ‘‘contrivances,’’ and there-

The FDA regulates medical devices that are: (a) com-

446 MILLER, GARDNER, Monitoring and Regulation of Clinical Software

executive recruiters. CHIM members seek to bring a Consortium Recommendations

448 MILLER, GARDNER, Monitoring and Regulation of Clinical Software

Consortium Recommendations for Risk-based Categories of Clinical Software Systems

Consortium Recommendations for Regulatory Classes

450 MILLER, GARDNER, Monitoring and Regulation of Clinical Software

Table 2A 䡲 tion’s (ISO) 9000 guidelines62 for quality manufactur-

452 MILLER, GARDNER, Monitoring and Regulation of Clinical Software

454 MILLER, GARDNER, Monitoring and Regulation of Clinical Software

Question 1. Is the "stand-alone" software a medical device?

1.1 Is the software sold

1.2 Is the software

1.3 Is the software

• Used in financial management

Appendix continued on next page.

456 MILLER, GARDNER, Monitoring and Regulation of Clinical Software

2.2 Is the software