grassley feb 24 letters

8/14/2019 Grassley Feb 24 Letters

1/30

February 24, 2010

Via Electronic Transmission

The Honorable Kathleen SebeliusSecretaryU.S. Department of Health and Human Services200 Independence Avenue, SWWashington, 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 responsibilityto protect the health of the programs more than 100 million beneficiaries as well as thecongressionally authorized tax dollars used to fund these programs. This includesensuring the effective and efficient use of taxpayer money by the health care industry inimplementing Health Information Technology (HIT), such as Computerized PhysicianOrder Entry systems and Electronic Health Records (EHR).

On February 12, 2010, you announced over $750 million in grant awards as partof a federal effort to help hospitals and physicians adopt electronic health records.American taxpayers and health care facilities are making substantial investments in theHIT 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 potentialto prevent medical errors and increase the efficiency and effectiveness of health caredelivery, thereby improving the safety and quality of care. However, I have also beensurprised by the lack of discussion about patient safety concerns when, for example, HITproducts 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 Committees Adoption/Certification Wo rkgroup isholding a workshop tomorrow to solicit comments on patient safety issues related to EHRuse, including approaches for preventing harm and mitigating risks.

Over the last year, I have heard from many health care providers around thecountry regarding problems they experienced with implementation and use of certain HITproducts in their hospitals and clinics. In most cases, they tried raising their concerns tohospital administrators and/or to the HIT vendors, but they told me that their concernswere often ignored or dismissed. In October 2009, I wrote to ten major HIT companiesin the U.S. regarding some of these issues and concerns. Last month, I also sent letters to


2/30

2

31 hospitals to obtain their perspective and experiences with HIT. Both letters areenclosed.

I am also enclosing for your consideration an article entitled, Recommendationfor Responsible Monitoring and Regulation of Clinical Software Systems. That positionpaper was published in the Journal of the American Medical Informatics Association (JAMIA) in 1997. Interestingly, according to the article, the Food and DrugAdministration (FDA) had called for discussions on the regulation of clinical softwaresystems in 1996 and in response, a consortium of health information-relatedorganizations 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 suchsystems. One of the recommendations addressed FDAs regulatory role. Anotherrecommendation called for the adoption of a code of good business practices by healthcare 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 Depar tments thoughts on it . In particular, I am requestingresponses to the following questions. Please repeat the enumerated question and followwith the appropriate response and documentation.

1) What is the Departments position on the proposals in the JAMIA article?

2) To what extent have the recommendations regarding FDAs regulation of HITproducts been adopted?

3) To what extent are additional efforts needed to respond to the evolving, complexhealth information technologies and the meaningful use requirements issued bythe Centers for Medicare and Medicaid Services in December 2009?

4) Earlier this month, I submitted questions to you following the Committeeshearing on The Presidents Fiscal Year 2011 Health Care Proposals. I wouldlike to reiterate some of those questions in this letter. In particular, I asked thefollowing:

a. With over $20 billion in taxpayer money at stake and with increasingcomplexity in the technologies being used in our hospitals, do you believeit is time to revisit FDAs responsibilities in regulating HIT products beingused in clinical care?

b. If not, how is HHS making sure that the health information technologiesbeing developed and implemented are safe and effective?

c. Who is or should be responsible for ensuring that the HIT vendors aremeeting quality manufacturing processes?


3/30

3

5) In addition, does the FDA have sufficient authority to regulate HIT products, or isthere a lack of clarity regarding the FDAs role? If additional authorities areneeded to ensure adequate oversight of HIT products, please specify whatauthorities may be needed. If clarification is required, please specify whereadditional 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 whenintegrated with other software pro ducts or with unsupported network interfaces. The authors also stated that Because each clinical site combines differentsoftware products in different combinations, a universal evaluation of whether ornot a given product will function safely when embedded in a clinical environmentis impractical, and suggested the establishment of local and regional SoftwareOversight Committees.

a. Has HHS considered establishing local or regional oversight committeesfor HIT products?

b. To what extent should the Regional Extension Centers and/or BeaconCommunity 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 typeof review?

Thank you for your attention to this important matter. I would appreciateresponses to the questions set forth in this letter by no later than March 10, 2010. If youhave any questions, please contact Angela Choy of my Committee staff at (202) 224-4515. Any formal correspondence should be sent electronically in PDF searchableformat to [email protected].

Sincerely,

Charles E. GrassleyRanking Member

cc: The Honorable Margaret A. HamburgCommissionerU.S. Food and Drug Administration10903 New Hampshire Ave.Silver Spring, MD 20993

Enclosures


4/30

October 16, 2009


Neal PattersonChief Executive OfficerCerner Corporation2800 Rockcreek ParkwayKansas City, MO 64117

Dear Mr. Patterson:

The United States Senate Committee on Finance (Committee) has jurisdictionover the Medicare and Medicaid programs. As a senior member of the United StatesSenate and Ranking Member of the Committee, I have a special responsibility to protectthe health of Medicare and Medicaid beneficiaries and safeguard taxpayer dollarsauthorized by Congress for these programs. This includes the responsibility to conductoversight of the health care industry, including the manufacturers of Health InformationTechnology and Computer Physician Order Entry Systems (HIT/CPOE), for which about$19 billion in taxpayer dollars has been earmarked for its development andimplementation.

Over the past year, I have received complaints from patients, medicalpractitioners and technologies engineers regarding difficulties they have encounteredwith the HIT and CPOE devices in their medical facilities. These complaints include, forexample, faulty software that miscalculated intracranial pressures and interchangedkilograms and pounds, resulting in incorrect medication dosages.

In addition, it has been reported that HIT/CPOE manufacturers rely on a legaldoctrine known as learned intermediaries, to shift responsibility for errors in the HITsystems to physicians, nurses, pharmacists, and other health care providers. Themanufacturers allegedly argue that the health care provider should be able to identify andcorrect errors caused by the software. It has also been reported that HIT/CPOE contractswith medical facilities may include hold harmless provisions that absolvemanufacturers of these products of any liability for errors that are allegedly HIT/CPOEsystem or software failures. These contracts may also include gag orders, whichprohibit 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 ahealth care providers ability to make informed decisions regarding the implementationof an HIT/CPOE system.


5/30

2

American taxpayers will be investing substantially in the HIT/CPOE industry, andit is important that their monies are appropriately spent on effective and interoperableHIT systems and devices. Accordingly, I would appreciate your response to the followingquestions 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 throughthe date of this letter. In responding to this letter, please repeat the enumerated questionand follow with the appropriate response and documentation.

1) Please provide a product list and description and function of all HIT/CPOEproducts manufactured and distributed by Cerner Corporation (Cerner) and itssubsidiaries.

2) Does Cerner include language in its contracts that could be considered HoldHarmless provisions? If so, please provide a copy of sample contracts with suchprovisions.

3) Does Cerner incorporate the learned intermediaries doctrine in the HIT/CPOEcontract? If so, please provide a copy of sample contracts with such language.

4) Please describe Cerner s role in ensur ing that health care providers are adequatelytrained to use your products. Please also provide a copy of any and all trainingmanuals, training schedules, and power point presentations that illustrateHIT/CPOE functionality and use.

5) Please provide a copy of communications, including but not limited tomemoranda, letters, meeting minutes and notes, email and correspondence,regarding complaints and/or concerns from health care providers/professionalsand other clients with the HIT/CPOE systems manufactured by Cerner.

6) Does Cerner have any system in place to track, catalogue or maintain complaintsand/or concerns regarding Cerner s HIT/CPOE products? If so, please describethat system in detail.

7) Does Cerner offer health care facilities and/or providers any financial incentivesfor purchasing Cerner s products, such as shares in the company or financialinterests 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 orindirectly to its HIT/CPOE devices and products in the past 18 months. If no, sostate. If yes, please state how many have been executed.

In cooperating with the Committees review, no documents, records, data or information related to these matters shall be destroyed, modified, removed or otherwisemade inaccessible to the Committee.


6/30


7/30

1

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 orcorporations with which Cerner Corporation entered into a partnership, joint venture orany other business agreement or arrangement.

2. In complying with this document request, produce all responsive documents that are inyour possession, custody, or control, whether held by you or your past or present agents,employees, and representatives acting on your behalf. In addition, produce documentsthat you have a legal right to obtain, documents that you have a right to copy or haveaccess to, and documents that you have placed in the temporary possession, custody, orcontrol of any third party.

3. No documents, records, data or information requested by the Committee shall bedestroyed, 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 theextent possible, which shall include an explanation of why full compliance is notpossible.

5. In complying with this document request, respond to each enumerated request byrepeating 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 followinginformation 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) therelationship of the author and addressee to each other.

7. Each document produced shall be produced in a form that renders the documentsusceptible of copying.

8. It shall not be a basis for refusal to produce documents that any other person or entityalso 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, orcontrol.

10. This request is continuing in nature. Any document, record, compilation of data orinformation, not produced because it has not been located or discovered by the returndate, shall be produced immediately upon location or discovery subsequent thereto.

11. All documents shall be Bates stamped sequentially and produced sequentially.


8/30

2

GENERAL DEFINITIONS

1. The term document means any written, recorded, or graphic matter of anynature 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 officecommunications, electronic mail (E-mail), contracts, cables, notations of any typeof 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, financialstatements, reviews, opinions, offers, studies and investigations, questionnairesand 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 orrepresentations of any kind (including without limitation, photographs, charts,graphs, microfiche, microfilm, videotape, recordings and motion pictures), andelectronic, mechanical, and electric records or representations of any kind(including, without limitation, tapes, cassettes, discs, and recordings) and otherwritten, 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 textis to be considered a separate document. A draft or non-identical copy is aseparate document within the meaning of this term.

2. The term records is to be construed in the broadest sense and shall mean anywritten or graphic material, however produced or reproduced, of any kind ordescription, consisting of the original and any non-identical copy (whetherdifferent from the original because of notes made on or attached to such copy orotherwise) and drafts and both sides thereof, whether printed or recordedelectronically or magnetically or stored in any type of data bank, including, butnot limited to, the following: correspondence, memoranda, records, summaries of personal conversations or interviews, minutes or records of meetings orconferences, 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, taperecordings, video recordings, e-mails, voice mails, computer tapes, or othercomputer stored matter, magnetic tapes, microfilm, microfiche, punch cards, allother 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 canceledchecks, bank statements, ledgers, books, records or statements of accounts, andpapers and things similar to any of the foregoing, however denominated.


9/30

3

3. The terms relate, related, relating, or regarding as to any given subjectmeans 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 informationwhich might otherwise be construed to be outside its scope. The singular includesplural number, and vice versa to bring within the scope of this document requestany information which might otherwise be construed to be outside its scope. Themasculine includes the feminine and neuter genders to bring within the scope of this document request any information that might otherwise be construed to beoutside 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, bytelephone, mail, telexes, discussions, releases, personal delivery, or otherwise.Documents that typically reflec t 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.


10/30

January 19, 2010


Glenn Steele Jr. M.D., PhD.President and Chief Executive OfficerGeisinger Medical CenterN. Academy AvenueDanville, PA 17821

Dear Dr. Steele:

As Ranking Member of the Senate Committee on Finance, which has jurisdictionover the Medicare and Medicaid programs, I have a special responsibility to protect thehealth of the programs more than 100 million beneficiaries as well as thecongressionally authorized tax dollars used to fund these programs. This includesensuring the effective and efficient use of taxpayer money by the health care industry inimplementing Health Information Technology (HIT), such as Computerized PhysicianOrder Entry systems and Electronic Health Records.

In recent legislation, approximately $19 billion in taxpayer funds wasappropriated to encourage development and implementation of HIT systems, whichfurther emphasizes the importance of responsible use and thorough oversight. Over thepast several months, however, I have been made increasingly aware of difficulties andchallenges associated with HIT implementation. The reported problems appear to beassociated with administrative complications in implementation, formatting and usabilityissues, and actual computer errors stemming from the programs themselves, as well as,interoperability between programs. For example, I have heard from health care providersregarding faulty software that produced incorrect medication dosages because itmiscalculated body weights by interchanging kilograms and pounds.

In addition, I have heard from health care providers around the country that whenthey report such problems to their facilities and/or the product vendors, their concerns aresometimes ignored or dismissed. Some sources recount difficulties in approaching theHIT vendor with problems and the lack of venue to discuss these issues either with thevendor 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 theirfacilities from sharing information outside of their facilities regarding product defects andother HIT product-related concerns.

Some HIT products, I understand, are medical devices regulated by the Food andDrug Administration (FDA). Therefore, the manufacturers of these devices are requiredto meet specific reporting requirements, such as the reporting of adverse events to FDAsManufacturer and User Facility Experience database. However, for HIT products that


11/30

2

may not fall under FDA regulation, there appears to be a lack of a national system forreporting product errors or failures and adverse events associated with the use of suchproducts. Thus, problems with these products may go without remedy thereby inhibitingthe ability of the health care professional to provide quality care and potentiallyimpacting patient safety. Furthermore, contractual restrictions on the sharing of experiences and information related to specific vendor products limit a health carefacilitys ability to make informed decisions about HIT adoption and implementation.

American taxpayers and health care facilities across the country will be investingsubstantially in the HIT industry, and it is important that their monies are appropriatelyspent on effective and interoperable HIT systems. In October 2009, I wrote to ten majorHIT companies regarding similar issues and concerns. The purpose of todays letter is togather information from hospitals regarding their perspective and experiences with HIT.Accordingly, I would appreciate your response to the following questions and requestsfor information regarding the HIT products being implemented at your facility and anyissues or concerns that have been raised by your health care providers. Unless otherwisenoted, the requests cover the period of January 1, 2007 through December 31, 2009. Inresponding to this letter, please repeat the enumerated question and follow with theappropriate response and documentation.

1. Please describe in detail your facilitys 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 yourfacility provide input regarding the specific HIT items to be implementedwithin your facility?

c. Who or what department within your facility is responsible for makingHIT purchase decisions?

2. Three of the companies that I wrote to in October 2009 informed me that they donot manufacture HIT software or hardware, but instead assist their health careclients, such as hospitals, with the implementation and management of HITsystems. To what extent do you contract with such entities to assist with thepurchase, implementation and/or management of HIT products in your facility?

3. Please describe the training process implemented in your facility to familiarizeemployees 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?


12/30

3

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 productsor systems implemented in your facility? If so, please provide a description of thepolicies or processes. If not, please explain why not.

5. When patient care and/or safety problems related to HIT systems arise, how arethese problems reported within the facility and what is the process or mechanismfor addressing them?

a. Are these problems also reported to the HIT vendor, and if so, what is theprocess for reporting them?

b. If patient care and/or safety problems related to HIT systems are notroutinely reported to the HIT vendors, please explain how your facilitydecides which problems or issues are reported to a vendor and/oraddressed by a vendor and which problems are addressed internally by thefacility.

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 productsthat may directly or indirectly involve or impact the delivery of care or patientsafety.

7. Please provide a list of HIT problems or complaints that have been identified byor reported to your facility since January 2008 that directly or indirectly impactedpatient safety or the delivery of care, including any complications or adverseevents that have occurred as a result of HIT product design and/or usability.Please describe whether and how each of those problems or complaints wasresolved and whether these issues have resulted in a change in policy to preventthe problem in the future.

8. Does your facility have policies regarding the discussion of problems in your HITsystems with other health care facilities or with government officials or anyindividuals or entities outside your facility? If so, please describe those policies.To what extent are these policies driven by contractual agreements with the HITvendors, and to what extent do they stem from internal processes? Please provideexamples 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 donot include language that would hold them harmless for failures of their productsor for the companys own negligence or recklessness. However, they mayinclude provisions that spell out the vendors and the health care clientsrespective legal responsibilities and obligations in the use of the product. Forexample, one vendor stated that it is accountable for the performance of itsproduct as long as the client uses the product appropriately. Another vendorstated that it is not liable when harm or loss results from the clients use of theproduct in diagnosing and/or treating patients.


13/30

4

a. Do any of the HIT vendors include language in their contracts with yourfacility that could be considered hold harmless provisions, i.e. , thetransferring of liability associated with the services or products providedto your facility, or otherwise limit their liability? If so, please provide acopy 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 productspurchased by health care facilities have stated in their responses to me thatthey do not offer any financial incentives for purchasing their products,such as shares in the company or financial interests in a particularproduct. At least one vendor stated, however, that it does offer financialincentives in the form of discounts based on purchase size. Anothervendor said that health care clients may receive royalty payments whenthe clients collaborate with the vendor to develop a product. Whatfinancial interest, if any, does your facility have in HIT vendors and/ortheir products?

b. Do the vendors offer your facility and/or any of your health care providersany 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, productdiscounts, or other items of value from any vendor for discussing and/or

promoting that vendors 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. Pleaseprovide your response to the questions and requests set forth in this letter by no later thanFebruary 16, 2010. If you have any questions, please do not hesitate to contact AngelaChoy at (202) 224-4515. All formal correspondence should be sent electronically in PDFformat to [email protected] or via facsimile to (202) 228-2131.

Sincerely,

Charles E. GrassleyRanking Member


14/30

doi: 10.1136/jamia.1997.00404421997 4: 442-457JAMIA

(AHIMA), the American Nurses AssociationLibraries (AAHSL), the American Health Information Management AssociationMedical Library Association (MLA), the Association of Academic Health ScienceAssociation (AMIA), the Computer-based Patient Record Institute (CPRI), theRandolph A Miller, Reed M Gardner and For the American Medical Informatics

and Regulation of Clinical Software SystemsRecommendations for Responsible Monitoring

http://jamia.bmj.com/content/4/6/442.full.htmlUpdated information and services can be found at:

These include:

References

http://jamia.bmj.com/content/4/6/442.full.html#related-urlsArticle cited in:

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

serviceEmail alerting

the top right corner of the online article.Receive free email alerts when new articles cite this article. Sign up in the box at

Notes

http://jamia.bmj.com/cgi/reprintformTo order reprints of this article go to:

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

group.bmj.comon January 27, 2010 - Published by jamia.bmj.comDownloaded from
http://jamia.bmj.com/content/4/6/442.full.htmlhttp://jamia.bmj.com/content/4/6/442.full.html#related-urlshttp://jamia.bmj.com/content/4/6/442.full.html#ref-list-1http://jamia.bmj.com/content/4/6/442.full.html#ref-list-1http://jamia.bmj.com/cgi/reprintformhttp://jamia.bmj.com/subscriptionshttp://group.bmj.com/http://group.bmj.com/http://jamia.bmj.com/http://group.bmj.com/http://jamia.bmj.com/http://jamia.bmj.com/subscriptionshttp://jamia.bmj.com/cgi/reprintformhttp://jamia.bmj.com/content/4/6/442.full.html#related-urlshttp://jamia.bmj.com/content/4/6/442.full.html#ref-list-1http://jamia.bmj.com/content/4/6/442.full.html


15/30

442 MILLER, GARDNER, Monitoring and Regulation of Clinical Software

JAMIAThe Practice of Informatics

Position Paper

Recommendations forResponsible Monitoring andRegulation of Clinical

Software SystemsRANDOLPH A. MILLER , MD, REED M. GARDNER, PHD. For the American MedicalInformatics Association (AMIA), the Computer-based Patient Record Institute(CPRI), the Medical Library Association (MLA), the Association of Academic HealthScience Libraries (AAHSL), the American Health Information ManagementAssociation (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 softwareprograms as medical devices. In response, a consortium of organizations dedicated to improvinghealth care through information technology has developed recommendations for the responsibleregulation and monitoring of clinical software systems by users, vendors, and regulatoryagencies. Organizations assisting in development of recommendations, or endorsing theconsortium position include the American Medical Informatics Association, the Computer-basedPatient Record Institute, the Medical Library Association, the Association of Academic HealthSciences Libraries, the American Health Information Management Association, the AmericanNurses Association, the Center for Healthcare Information Management, and the AmericanCollege of Physicians. The consortium proposes four categories of clinical system risks and fourclasses of measured monitoring and regulatory actions that can be applied strategically based onthe level of risk in a given setting. The consortium recommends local oversight of clinicalsoftware 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 thatthe FDA can regulate effectively. FDA regulation should exempt most clinical software systemsand focus on those systems posing highest clinical risk, with limited opportunities for competenthuman intervention.

J Am Med Inform Assoc. 1997;4:442457.

Afliations of the authors: Past President (RAM), and President(RMG) of the American Medical Informatics Association, Be-thesda, MD.

Dr. Millers efforts have been supported in part by Grants 5-G08-LM-05443 and 1-R01-LM-06226 from the National Libraryof Medicine.

Correspondence and reprints: Randolph A. Miller, MD, Room436, Eskind Library, 2209 Garland Ave., Vanderbilt UniversityMedical Center, Nashville, TN 37232.E-mail: [email protected]

Received for publication: 7/3/97; accepted for publication:7/17/97.

Health care practitioners, clinical facilities, industry,and regulatory agencies share an obligation to man-age clinical software systems responsibly, using a

common, equitable framework. In mid-1996, theUnited States Food and Drug Administration (FDA)called for new discussions on the regulation of stand-

http://group.bmj.com/http://group.bmj.com/http://group.bmj.com/http://jamia.bmj.com/http://group.bmj.com/http://jamia.bmj.com/


16/30

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-sponse, a consortium of health information-related or-ganizations has developed recommendations for publicand private actions to accomplish responsible monitor-ing and regulation of clinical software systems.

The consortium believes that implementation of anynew procedures for regulation of clinical software sys-tems as medical devices requires detailed prior anal-ysis of regulatory relevance to, or impact on, clinicalsoftware vendors, health care providers, and patients.Failure to carry out analyses prior to regulatory ac-tions could halt progress in an emerging new industrythat has substantial potential to improve the qualityof health care delivery. Manufacturers, users, and pa-tients cannot tolerate the delays in critical softwareimprovements that might result from excessive gov-ernmental review and approval processes.

All parties (including the FDA, consortium members,and organizations endorsing the consortium position)emphasize the same objectivesprotection and safetyof patients, and facilitation of approaches that im-prove health care delivery and outcomes.

The authors, in consultation with the Editors of JAMIA and the Annals of Internal Medicine, have pre-pared a condensed version of this manuscript, moresuitable for a clinical audience, for concurrent publi-cation in the Annals of Internal Medicine (Miller RA,Gardner RM, American Medical Informatics Associa-tion, et al. Summary Recommendations for the Re-sponsible Monitoring and Regulation of Clinical Soft-ware Systems. Forthcoming, Ann Intern Med, Vol.127, November 1997.)

Background

Benets of Clinical Software Systems

Clinical software systems are dened here as individ-ual computer application programs, or interconnectedgroups of such programs, that are directly used in

providing health care. Clinical software systems re-quire supportive environments, including computeroperating systems and network interfaces. A growingliterature documents how clinical software systemscan improve health care delivery processes andoutcomes. 443 Users employ such systems to track andmanage patient-related information, to retrieve localand general clinical information, and to apply clinicalknowledge in making patient-specic decisions. Clin-ical system usage encompasses hospital informationsystems and electronic record-keeping 411; clinicaldata repositories 1213; health service-specic support(e.g., laboratory, pharmacy, and dietary systems);decision support for diagnosis, therapy, or progno-

sis1426; guidelines and reminders 2738; protocol man-agement 3940; telecommunication and tele-health 41;signal processing (e.g., ECG interpretation sys-tems) 42; image storage and analysis (e.g., picturearchival and communications systemsPACS) 43;advice-giving systems for patients; and other health-related applications.

To maximize benet, providers should integrate signif-icant technological advances promptly and safely intoclinical practice. Currently, there are no widely accepted,practical standards for the evaluation, use, and moni-toring of clinical software systems. The FDA is only be-ginning to formulate a denitive policy with respect tosuch systems. In our opinion, regulation and oversightof clinical systems is both too important and too com-plicated to be the sole responsibility of users, vendors,or regulatory agencies a combined approach is re-quired, with roles for each category of participants.

Obstacles to Evaluation and Monitoring ofClinical Software Systems

Determination of the safety of clinical software systemsis difcult because of the varied nature of clinical soft-ware, the changes that occur when a software productis integrated into a complex clinical information man-agement infrastructure, the changes to systems that oc-cur during maintenance, and the miscellaneous inter-actions between software programs and their users.

Evaluation of Simple TurnkeyClinical Applications

It is difcult to evaluate and monitor even simple in-dependent, turnkey programssingle software prod-ucts that do not connect to or depend upon other ap-plication programs (other than an operating system).Such programs are often used as is on microcom-puters in individual practitioners ofces, and onlymodied when users upgrade to the next version. Ac-cording to a recent survey, individual clinical vendorproducts number at least several thousand. 45 In addi-tion, there exist thousands of health-related, Internet- based World Wide Web resources of variable quality.

Persons evaluating the performance of a clinical soft-ware system employ numerous criteria in determin-ing whether a system merits purchase, installation,continued utilization, or approval by a regulatoryagency. 4652 The appropriateness of a given evaluationmethod varies with the stage of system develop-ment. 47 While it is important during system develop-ment to evaluate system performance in isolated, ar-ticially controlled situations, evaluators of moremature systems should compare clinicians caring foractual patients using the software to clinicians with-



17/30


out accessand not simply report system perfor-mance on a series of cases.

With respect to patient safety, approval of any sys-tems performance should be based on demonstrationof either absolute or relative benet. For absolute ben-et, system use should cause no measurable harm,produce outcomes at least as good as the status quo,and do so at an acceptable cost in time and money.For relative benet, system use should demonstratenet improvement over the status quoi.e., the systemwill reduce the overall level of patient morbidity, mor-tality, or costs, even though the system itself maycause adverse effects. For example, electrocardiogram(EKG) interpretation programs have acceptable rela-tive benet in patient care settings because they im-prove upon many physicians ability to rapidly andeffectively interpret EKGs, even though it is widelyknown that they are not as authoritative as expertCardiologists, and may on occasion mislead healthcare providers.

Evaluation and Monitoring of Complex,Interconnected Clinical Software Systems

A software product may work well in isolation butfail when integrated with other software products orwith unsupported network interfaces. Large clinicalsites (such as tertiary referral centers) contain diverse

hardware platforms, multiple networks, and manyvendors software products. Clement J. McDonald re-cently estimated that large U.S. health centers inter-connect several dozen major clinical software systems,consisting of both vendors clinical software productsand locally developed software programs. 44 A dia-gram of the HELP System, developed at LDS Hospitalin Salt Lake City, Utah, 6 illustrates how complex suchsystems can become (Fig. 1). Suppose, for example,that a small to medium-sized health care institutiondecides to purchase and connect via a network a se-ries of applications for their laboratory, pharmacy, ad-mission/discharge/transfer (ADT), dietary, and cleri-

cal order processing activities. If the institutionconsiders ten different vendors that produce productsof the sort being considered, there are 100,000 differ-ent basic congurations possible. Major referral cen-ters install dozens of individual software components,each selected from more than a hundred possibleproduct congurations (Fig. 1). One hundred choicesfor each of 12 components yields a trillion trillion(1024) possible overall congurations for each largesite! Because each clinical site combines different soft-ware products in different combinations, a universalevaluation of whether or not a given product willfunction safely when embedded in a clinical environ-ment is impractical.

Evaluation of Clinical Software Systems thatChange Over Time

A clinical application categorized as safe and effec-tive based on extensive testing at its inception might become less than effective over time due to improperor inadequate maintenance. Both system softwarecode and the clinical data supporting system func-tions may be altered in a manner that invalidates eval-uation results for previous baseline products. Cong-uration and integration of complex systems requirestesting, tuning, correction of software errors, modi-cations based on installation environments and userfeedback, and upgrades, all of which increase localvariability over time. These changes occur on an al-most daily basis. Requiring a formal evaluation ofsafety or efcacy related to each system change wouldparalyze ongoing implementation.

Users: An Important Consideration in Evaluationand Monitoring

Clinical software users include institutions, individualhealth care providers, and the general public, includ-ing patients. In analyzing causes of system-related ad-verse events, it is essential to consider end-userfactors. 4652 Systems with exemplary hardware andsoftware components can cause problems when usersdo not understand system applicability and limita-tions; when users do not understand how to inputcritical information into the system, when users can-not reliably interpret system output; or when it is dif-cult to integrate system use into common workowpatterns. Monitoring to detect problems often requiresaggregation of objective observations from a numberof sources and a perspective that goes beyond indi-vidual system components. Hence, raw complaintsfrom individual users need to be analyzed to deter-mine if the problem is in the software or in the usereducation program.

Past and Current FDA Regulation of ClinicalSoftware Systems

Through its mandate from Congress to safeguard thepublic, the FDA has regulated marketing and use ofmedical devices. Section 201(h) of the 1976 FederalFood, Drug, and Cosmetic Act denes a medical de-vice as any instrument, apparatus, implement, ma-chine, contrivance, implant, in vitro reagent, or othersimilar or related article, including any component,part, or accessory, which is . . . intended for use in thediagnosis of disease or other conditions, or in the cure,mitigation, treatment, or prevention of disease. . . or intended to affect the structure or any functionof the body. 53 The FDA asserts that all clinical soft-ware programs, whether associated with biomedical



18/30


F i g u r e 1 Diagram of HELP Information System at LDSHospital, Salt Lake City, Utah. 6

devices or stand-alone, are contrivances, and there-fore fall within the FDAs realm of responsibility forregulating medical devices.

The FDA regulates medical devices that are: (a) com-mercial products used in patient care; (b) devices usedin the preparation or distribution of clinical biologicalmaterials (such as blood products); or (c) experimentaldevices used in research involving human subjects.Commercial vendors of specied types of medical de-vices must register as manufacturers with the FDAand list their devices as products with the FDA. Uponlisting, FDA classies medical devices by categories.In its regulation of classied medical devices, the FDAusually takes one of three courses of action. First, theFDA can exempt specic devices, or categories ofdevices, deemed to pose little or no risk. Second, theFDA employs the so-called 510(k) process pre-mar-ket noticationfor non-exempt systems. Throughthe 510(k) process, manufacturers attempt to demon-strate that their devices are equivalent, in purpose andfunction, to low-risk (FDA Class I or Class II) devicespreviously approved by FDA (or to devices marketed before 1976). Such devices can be cleared by FDA di-rectly. Finally, the FDA requires pre-market approval(PMA) for higher-risk (FDA Class III) products andfor products with new (unclassied) designs inventedafter 1976. Through the pre-market approval process,

a manufacturer provides evidence to the FDA that aproduct performs its stated functions safely and effec-tively. Evidence for PMAs usually is presented in theform of controlled trials. Pre-market approval is es-pecially important for those products which pose sig-nicant potential clinical risk. Exemption can takeplace in two ways: a device can be exempt from reg-istration, and thus not subject to 510(k) requirements;or, a category of listed (classied) devices may be spe-cically exempted from certain regulatory require-ments. Whenever a non-exempt product is modiedsubstantially (as dened by FDA guidelines), the ven-dor must re-apply to the FDA for new clearancethrough the 510(k) or PMA mechanisms. The pro-cesses of 510(k) pre-market notication and pre-mar-ket approval typically take a few to many months tocomplete, and may involve numerous exchanges anditerations.

The FDA has a long history of regulating hardwaremedical devices, making it important to distinguish between medical device-associated software and otherclinical software. Clinical software can be categorizedas stand-aloneexternal to and independent of amedical hardware deviceor embeddedan in-tegral component of a medical hardware device. Ofnote, a second connotation of stand-alone system

a single, independent turnkey systemwas pre-viously discussed. However, in the context of FDAdiscussions, stand-alone refers to independencefrom a traditional (hardware) medical device. Embed-ded software is often placed on a computer ROM(read-only-memory) chip that physically controls allor part of a hardware medical device, such as a lab-oratory auto-analyzer or a cardiac pacemaker. TheFDA regulates any embedded software program aspart of the medical hardware device itself.

In general, the FDA does not actively regulate locallydeveloped stand-alone software programs, whetherdeveloped by an individual or an institution, unlessspecial circumstances apply. One such circumstance islocal preparation of FDA-regulated biomaterials, suchas blood products. The FDA regulates individualstand-alone software products that are commerciallymarketed by individual manufacturers. It rarely spec-ies or controls how independent vendors productscan be combined at a specic site, unless such prod-ucts are components of a single, larger system, suchas a PACS system. This is similar to FDA regulationof commercial pharmaceuticals, wherein the FDA reg-ulates each individual drug comprising a chemother-apy protocol, but does not regulate multiple drug che-motherapy protocols themselves. The requirementsfor re-review are somewhat controversial, in that up-grading the network operating system of a compo-nent part of an FDA-regulated PACS system from ver-sion 3.1 to version 4.0 could potentially be viewed bythe FDA as requiring resubmission for 510(k) or PMAapproval. For this reason, the FDA has drafted andperiodically updated guidelines on when to submitfor re-approval.

In 1986, Frank Young, then director of the FDA, pro-posed a commendable plan for the oversight and reg-ulation of clinical software. 54 This plan evolved into a



19/30


1989 draft FDA policy statement that was never for-mally adopted. That draft policy has served, until re-cently, as the basis for the FDAs actions with respectto stand-alone software systems. The 1989 draft policyrecommended that the FDA exempt from regulation both information-providing educational systems andsystems that generate patient-related advice for clini-cians in a manner that licensed practitioners (users)could easily override. During the 1990s, the FDA hasdeveloped new draft regulations and guidelines for blood bank software systems 55,56 and for PACS sys-tems. 57 The FDA is developing new guidelines for te-lemedicine systems as well. 58

At present, aspects of FDA regulation of clinical soft-

ware systems can be applied in an arbitrary manner.Although the FDA can initiate review of software prod-ucts brought to its attention, for the most part, theagency depends on vendors to submit their productsvoluntarily both for initial review, and review aftermodications. The review process itself may vary, be-cause the FDA often employs a variety of different ev-aluators and consultants in reviewing similar products.Some vendors may be more likely than others to con-sider their software products as requiring FDA review.

3 Participating Organizations and

Consensus Process

Participating Organizations

The American Medical Informatics Association(AMIA) is a non-prot organization dedicated to im-proving health care through the application of infor-mation technology. The more than 3,700 members ofAMIA represent professions associated with health-care informaticsphysicians, nurses, biomedical en-gineers, computer scientists, information scientists,programmer-analysts, librarians, biomedical educa-

tors, biomedical researchers, vendor-consultants, den-tists, veterinarians, students, and a variety of otherhealth care practitioners. AMIAs goals are to promotethe development of health care informatics as a rec-ognized academic and professional discipline; to helpsolve health care problems through informatics re-search and development; and to promote diffusion ofknowledge in the discipline of health care informatics.The Computer-based Patient Record Institute (CPRI)is a non-prot membership organization committed toadvancing improvements in health care quality, costand access through routine use of information tech-nology. CPRI serves as a neutral forum for bringingthe diverse interests of all health care stakeholders to-

gether to develop common solutions. The Medical Li- brary Association (MLA) is a professional organizationrepresenting approximately 5,000 individuals and in-stitutions involved in the management and dissemi-nation of biomedical information to support patientcare, education, and research. MLA members serve so-ciety by developing new health information deliverysystems, fostering educational and research programsfor health sciences information professionals, and en-couraging an enhanced public awareness of health careissues. The Association of Academic Health SciencesLibraries (AAHSL) is composed of the directors of libraries of 142 accredited U.S. and Canadian medicalschools. AAHSLs goals are to promote excellence inacademic health sciences libraries and to ensure that

the next generation of health practitioners is trained ininformation-seeking skills that enhance the quality ofhealth care delivery. The American Health InformationManagement Association (AHIMA) is the professionalorganization of more than 37,000 specialists in secur-ing, analyzing, and managing patient records andhealth information. AHIMA members support qualitypatient care through advancing data accuracy, advo-cating condentiality, and championing new informa-tion management technology. AHIMA, founded in1928, accredits educational programs at 250 collegesand universities and is the certifying agency for healthinformation managers and technicians. The American

Nurses Association (ANA) is the only full-service pro-fessional organization representing the nations 2.5 mil-lion Registered Nurses through its 53 constituent as-sociations. ANA advances the nursing profession byfostering high standards of nursing practice, promotingthe economic and general welfare of nurses in theworkplace, projecting a positive and realistic view ofnursing, and by lobbying the Congress and regulatoryagencies on health care issues affecting nurses and thepublic. ANA has been involved in healthcare infor-matics since the early 1970s and continues to activelyengage in diverse informatics activities. The AmericanCollege of Physicians (ACP) was founded in 1915 touphold the highest standards in medical education,practice, and research. Today, the College is the largestmedical specialty society in the world. It has more than100,000 members, including medical students as wellas practicing physicians, and it is the only society ofinternists dedicated to providing education resourcesand information resources to the entire eld of internalmedicine as well as its subspecialties. The Center forHealthcare Information Management (CHIM) is a na-tional, 100-plus member association for companiessupplying information technology products and ser-vices to the healthcare industryincluding softwaresuppliers, consultants, hardware rms, network inte-grators, medical imaging companies, publishers, and



20/30


executive recruiters. CHIM members seek to bring agreater understanding and awareness among health-care professionals as to how information technologycan be harnessed to improve the quality and cost-ef-fectiveness of patient care.

Consensus Process

In an attempt to develop a parsimonious approach tohandling proposals for changed regulations, the FDAhas conducted, during 1996 and 1997, a series of publicmeetings that have included leaders from the informa-tion technology and health care arenas, representativeprofessional organizations, and vendors. The rst draftof the consensus recommendations was prepared as adiscussion document by authors RAM and RMG, as

representatives of the American Medical Informatics As-sociation (AMIA) at the rst (and subsequent) publicmeetings held by the FDA. Key contributions to theevolving position paper were then made by other members of the AMIA Public Policy Committee and theAMIA Board of Directors. After initial endorsement bythe AMIA Board of Directors, subsequent suggestionsand further revisions were contributed by the Center forHealthcare Information Management (CHIM); the Com-puter-based Patient Record Institute (CPRI), the MedicalLibrary Association, the Association of Academic HealthSciences Libraries (AAHSL), the American Health Infor-mation Management Association (AHIMA), and the

American Nurses Association (ANA). The Boards of Di-rectors (or Regents) of the following not-for-prot or-ganizations have now endorsed the recommendationsentailed in this document: the American Medical Infor-matics Association (AMIA), the Computer-based PatientRecord Institute (CPRI), the Medical Library Association(MLA), the Association of Academic Health Sciences Li- braries (AAHSL), the American Health InformationManagement Association (AHIMA), the AmericanNurses Association (ANA), and the American Collegeof Physicians (ACP). The Center for Healthcare Infor-mation Management (CHIM) has reviewed successivedrafts of this document and contributed to its writing.

CHIM is supportive of the consortiums position, andholds the same opinions expressed in this document inall areas except for the denitions for proposed risk cat-egories of clinical software systems and classes of reg-ulations. The Appendix presents an algorithm prepared by CHIM suggesting how the FDA might review stand-alone clinical software systems for regulatory purposes.It should be noted that, while CHIM includes in itsmembership a number of commercial vendors from thehealthcare information industry, the viewpoints of in-dividual members have not been represented in thisconsensus document, and the original and subsequentdrafts of the consortiums recommendations have beenprepared and endorsed by not-for-prot organizations.

Consortium Recommendations

The consortium recommends that users, vendors,and regulatory agencies (including the FDA) adoptthe guidelines detailed below. Detailed explanationsand justications follow in the section after the rec-ommendations themselves. The recommendations go beyond the scope of interventions that the FDA orother vendor groups would ordinarily undertake,since they include clinical software products that arelocally developed, shareware, non-commercial, andcommercial.Recommendation 1: We propose four categories ofclinical software system risks and four classes of mea-sured regulatory actions as a template for clinical fa-cilities, vendors, and regulatory agencies to use in de-termining how to monitor or regulate any givenclinical software system (Tables 1A and 1B).Recommendation 2: We recommend local oversightof clinical software systems whenever possible,through creation of Software Oversight Committees,or SOCs (Tables 2A through 2D).Recommendation 3: Budgetary and other constraintslimit the type and number of systems that the FDAcan regulate effectively. We recommend that the FDAfocus its regulatory efforts on those systems posing

highest clinical risk that give limited opportunities forcompetent human intervention (Tables 2A2D). Themajority of clinical software systems should be ex-empt from FDA regulation. The FDA should requireproducers of exempt clinical software systems to listthem as products with the FDA for simple monitoringpurposes i.e., without having to undergo the 510(k)or PMA processes. The FDA should develop new,comprehensive standards for product labeling that areappropriate for clinical software products. The FDAshould require manufacturers of most exempt and allnon-exempt software products to adhere to labelingstandards (Tables 2A2D).Recommendation 4: We recommend adoption byhealth care information system vendors and local soft-ware producers of a code of good business practices.The practices should include (but not be limited to)guidelines for quality manufacturing processes; stan-dardized, detailed product labeling; responsible ap-proaches to customer support; and, adoption of in-dustry-wide standards for electronic informationhandling and sharing including standards forhealth care information format, content, and trans-port.Recommendation 5: We recommend that health in-formation-related organizations work together with



21/30


Table 1A

Consortium Recommendations for Risk-based Categories of Clinical Software Systems

Category Description Category Description

0 Informational or generic systems that providefactual content (electronic textbooks); veria- bly calculate (showing all parameters used)simple quantities, such as drug dosage based on body weight; or give simple,straightforward advice based on user-re-viewed guidelines (e.g., give potassiumsupplementation to patients receiving di-goxin who are hypokalemic). Includescontent-free generic software such as gen-eral database programs, generic spreadsheetprograms. Non-clinical systems also fall inthis category.

provide easy opportunities for practitioners toignore or override them. For example, systemsin this category might recommend a single pa-tient-specic therapy over a number of alter-native forms of therapy; recommend that thepractitioner commit to (conclude) a specic di-agnosis from a patient-specic differential di-agnosis; or guide patients in determiningwhich advanced-care directives might be ap-propriate for their situation. Systems in thiscategory might also store and transmit patient-specic instructions for life-critical care (e.g.,ventilator management or chemotherapy or-ders) to practitioners in a manner that is

1 Low-risk, patient-specic systems that performcomplex health-related functions with rela-tively low clinical risk and provide ampleopportunities for practitioners to ignore oroverride them. Such systems might non- judgmentally suggest a number of alterna-tive forms of therapy; list a comprehensivepatient-specic differential diagnosis with-out making a conclusion; or provide an esti-mate of the patients prognosis based onmatched cases from a clinical database. Sys-tems in this category might also store andtransmit patient-specic passive data (e.g.,laboratory results or clinical reports) in amanner that is easily veried.

3

easily veried.

High-risk, patient-specic systems that pro-vide complex, health-related functions thathave high clinical impact and provide littleif any opportunity for practitioners to inter-vene in their function or to override them.For example, systems in this category mightinclude individualized chemotherapy mixingand dispensing systems, systems that auton-omously plan courses of radiation therapyfor uploading into automated equipment todeliver the therapy, and systems that moni-tor physiological parameters and automati-cally adjust settings related to therapy (forexample, a ventilator auto-pilot).

2 Intermediate-risk, patient-specic systems thatprovide complex, health-related functionsthat have relatively high clinical risk, but

other groups, including clinical professional associa-tions, vendor organizations, regulatory agencies, anduser communities, to advance our understanding andknowledge of approaches to regulating and monitor-ing clinical software systems.

Explanation and Justication forConsortium Recommendations

Explanation of Recommendation 1: Risk andRegulatory Categories

Software installation and maintenance must be treatedas a process, not a single event. Review of a softwareenvironment at one point in time does not guaranteesafety or efciency at a later point in time. Decisionsabout whether to install and how to monitor clinicalsoftware systems should take into account: (a) theclinical risks posed by software malfunction or mis-

use; (b) the extent of system autonomy from useroversight and control the inability for qualiedusers, such as licensed practitioners, to recognizeand easily override clinically inappropriate recom-mendations (or other forms of substandard softwareperformance); (c) the pattern of distribution and de-

gree of support for the software system, including lo-cal customization; (d) the complexity and variety ofclinical software environments at installation sites; (e)evolution of systems and their environments overtime; and, (f) the ability of proposed monitors or reg-ulators to detect and correct problems in a timelymanner that protects patients. The ability of licensedclinician-users to override a system should be a con-sideration for decreased regulatory intervention. It isimportant to identify the most logical forum for sys-tem oversight. The best choice will often be local mon-itoring through SOCs (as described below), ratherthan nationally centralized data collection and moni-toring.



22/30


Table 1B

Consortium Recommendations for Regulatory Classes

Class Description Recommendation

A Exempt from FDA regulation; local SOC monitoring op-tional

Good business practices would be applied by develop-ers, vendors, and users.

B Exempt from FDA regulation; local SOC monitoringmandatory

Commercial products in this category should adhere toproduct labeling standards, and commercial vendorsshould list products with FDA for simple identica-tion purposes (no FDA review required). Good busi-ness practices recommended. Standardized surveys ofisolated users could be conducted on request by theFDA (or FDA-approved regional organizations) for in-dividuals who lack resources or expertise to imple-ment local monitoring and review guidelines. TheFDA would serve as a consultant to manufacturers,vendors, and SOC committees, rather than as a regu-lator.

C Simplied, expedited initial FDA approval through ver-ication that product labeling is accurate and adheresto standards; mandatory listing of products with FDAfor post-marketing surveillance; application of usualFDA 510(k) or PMA processes to any productsgenerKating concerns during post-marketing surveil-lance; local SOC monitoring mandatory.

Good business practices required. Reporting and re-cording of adverse events required with FDA collat-ing and aggregating standardized reports after localcollection and verication. FDA can require vendorswith unusually large number of unexplained adverseevent reports to undergo 510(k) or PMA to documentsafety and efcacy. In such trials, FDA should employstandard that the system demonstrates absolute orrelative benet (as dened above). Vendors requiredto maintain lists of users of each version of each sys-tem in this class.

D Usual FDA 510(k) or PMA processes applied prior tomarketing; local SOC monitoring mandatory.

Prior to marketing, vendors must submit to FDA evidencethat system safely and efcaciously performs its statedfunctions. Good business practices required. Vendorsmust maintain lists of users of each version. Recordingof adverse events required locally and reported to FDAusing standardized forms for aggregation of data.Troubleshooting activities aggregated locally and re-ported after ltering 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-tems based on patient risk and classes of regulatoryinterventions, as detailed in Tables 1A and 1B. Tables2A through 2D represent our recommendations onhow to apply the classes of regulatory actions respon-sibly to all clinical systems, based on the systems risk

categories. The recommendations in Tables 2Athrough 2D cannot be carried out solely by the FDAor by local institutions, vendors, or users. A combinedapproach with shared responsibilities is required. Theconsortium recommendations represent such an ap-proach.

Explanation of Recommendation 2: LocalMonitoring of Clinical Software Systems

Local software installation sites have the greatest abil-ity to detect software problems, analyze their impact,and develop timely solutions. It would be advanta-geous to develop a program of institutional- and ven-

dor-level controls for the majority of clinical softwareproducts, rather than to mandate comprehensive,cumbersome, inefcient, and costly national-levelmonitoring.

Institutional Review Boards (IRBs) provide an exam-

ple of a local monitoring process that is in widespreaduse. 5961 In order to protect the human subjects of re-search, federal law has required each clinical facilityengaged in patient research have an IRB to review,approve, and monitor research protocols locally. EachIRB includes clinical experts, administrators, individ-uals familiar with research study designs and meth-ods, and persons experienced in data analysis. SomeIRBs also include laypersons as representatives of thepatient community. The IRBs review the purpose ofproposed research; the anticipated benets to individ-uals and to the general community; the risks to subjects in terms of health outcomes, pain and suffering,and expenses; informed consent, voluntary participa-



23/30


Table 2A

Proposed Classes of Clinical Software Exemptions

and Regulation by Category of SoftwareType of

Software Description

Class A Software exempt from FDA regulation; lo-cal SOC monitoring optional. (Please re-fer to denitions of risk categories andregulatory classes in Table 1.)

Category 0 Informational or generic productsCategory 0 Non-clinical systems

Any system not directly involved in patientcare and any system not serving as anintegral component of a larger systemproviding patient carei.e., systems thatdo not play any role in suggesting diag-noses, suggesting prognoses, or suggest-ing or implementing orders or treat-ments.

Table 2B

Proposed Classes of Clinical Software Exemptionsand Regulation by Category of Software

Type of

Software DescriptionClass B Software Exempt from FDA regulation; lo-

cal SOC monitoring required. (Please re-fer to denitions of risk categories andregulatory classes in Table 1.)

All Category 1 All low-risk, patient-specic, low-impactsoftware giving adequate control to li-censed practitioner (easily overridden).

Some Category 2 Intermediate-risk, high-impact patient-spe-cic software giving adequate control tolicensed practitioner (easily overridden),including locally developed or share-ware non-commercial software systems;local SOC monitoring recommended forsuch software. EXCEPT: Category 2 sys-

tems commercially distributed that arenot modied in any way locally andthat do not serve as part of an inte-grated local system.

Some Category 3 Locally developed, non-commercial, pa-tient-specic, high-impact systems withminimal ability of practitioner to over-ride. It is mandatory, on an ethical basis,that such systems have careful local re-view and institutional oversight through both IRBs and SOCs. Such systemsshould adhere to product labeling stan-dards and be registered for simple iden-tication purposes with FDA, eventhough non-commercial. EXCEPT: Cate-

gory 3 systems distributed commercially.

tion, and ability to withdraw from the research study;and the plans for monitoring and conduct of the re-search protocol itselfe.g., ability to detect adverseoutcomes or grossly positive benets so that the studycan be terminated early, if indicated. In making deci-sions, the locally autonomous IRBs can take regionaldemographics, local practice patterns, patient con-cerns, and individual researchers skills and pastrecords into account much more efciently and effec-

tively than could a centralized national agency.While IRBs per se are not well qualied to review andmonitor clinical software systems, they provide amodel for creating a multidisciplinary team with ap-propriate expertise at the local level. Local and re-gional Software Oversight Committees (SOCs) couldenlist members with expertise in health care infor-matics, clinical practice, data quality, biomedicalethics, patients perspectives, and quality improve-ment. When the complexity, diversity, and number ofclinical software and computer hardware products atan installation site reach a critical size, a local SOCshould be formed to review clinical software on anongoing basis within the institution. On a similarnote, the Joint Council for the Accreditation of Health-care Organizations (JCAHO) reviews organizationssystems and processes for improving their perfor-mance, and specically includes information manage-ment as one of the areas reviewed. Small practitionersofces or smaller community hospitals without ade-quate expertise could participate in regional SOCs, orpossibly request consultations from local SOCs atlarger institutions.

The SOCs would develop and follow guidelines forlocal or regional software quality maintenance similarto the International Organization for Standardiza-

tions (ISO) 9000 guidelines 62 for quality manufactur-ing processes. More than 80 countries have adoptedthe ISO 9000 for consistency in manufacturing pro-cesses. ISO 9000 requires that manufacturers produceexplicit documentation for accepted procedures for all business activities; implement methods to prove thatprocedures are followed correctly and perform theirintended functions; conduct audits of process quality;and implement improvements or corrections whenproblems are detected. The SOCs would monitor pro-cedures by which an institution goes through opera-tional needs assessment; specication of desired sys-tem functions; selection of vendors products (or localproduct design and development); testing of productsin a realistic environment before going live; ade-

quate training of prospective users; installation andfollow-up during and after installation of softwaresystems; monitoring of users competencies and com-plaints; and the adequate provision of a help desktied to documentation procedures and methods formaking software improvements. SOCs could help en-sure that institutions build clinical enterprises to-



24/30


Table 2C

Proposed Classes of Clinical Software Exemptions

and Regulation by Category of SoftwareType of

Software Description

Class C Software subject to simplied, expeditedinitial FDA approval through verica-tion that product labeling is accurateand adheres to standards; mandatorylisting of products with FDA for post-marketing surveillance; application ofusual FDA 510(k) or PMA processes toany products generating concerns dur-ing post-marketing surveillance; localSOC monitoring mandatory. (Please re-fer to denitions of risk categories andregulatory classes in Table 1.)

Some Category 2 Intermediate-risk, high-impact, patient-specic software giving adequate controlto licensed practitioner (easily overrid-den), commercially distributed and notmodied in any way locally.

Table 2D

Proposed Classes of Clinical Software Exemptionsand Regulation by Category of SoftwareType of Software Description

Class D Software subject to FDA 510(k) and PMAapproval before marketing; Local SOCmonitoring mandatory. (Please refer todenitions of risk categories and regula-tory classes in Table 1.)

Some Category 3 High-risk, high-impact, patient-specicsoftware giving adequate control to li-censed practitioners (not easily overrid-den), commerically distributed and notmodied signicantly locally. Systemswould also adhere to product labeling

standards.

ward a reference architecture with a modular designso that components can be replaced as they are out-dated.

SOCs would work with system administrators, users,and vendors to make sure there is ongoing monitor-ing to detect adverse events, address them, and to in-

sure that the overall system performs as designed;and, that adequate attention is paid by vendors tomake sure that vendor-product related problems de-tected are corrected in a timely manner (appropriatefor the clinical risk posed by the problem). It wouldalso be important to develop ethical guidelines thatwould specify behavior for employees and SOC com-mittee members who might have special relationshipswith vendors or have software-related companies oftheir own.

Explanation of Recommendation 3: A FocusedFDA Strategy for Exemption and Regulation of

Clinical Software SystemsThe consortium recommends local oversight of clini-cal software systems through SOCs (as describedabove) whenever possible, and adoption by healthcare information system developers and vendors of acode of good business practices (see Explanation ofRecommendation 4, below). Governmental regulatorshave a legislative obligation to play a meaningful rolein assuring patient safety. To maximize benet of FDAefforts, we believe that the agency should focus onthose commercial stand-alone systems presenting thehighest degree of clinical risk (as dened in Tables 1Aand 2A to 2D). The FDA should move to formalizethe spirit of the 1989 FDA draft policy 54 in a clearly

worded new policy. The FDA should now dene ex-plicitly the categories of clinical software systems thatwill be exempt from its regulation. Recently, the Cen-ter for Healthcare Information Management (CHIM)has prepared an algorithm, expressed in the form ofa ow sheet, suggesting how the FDA might go aboutclassifying stand-alone clinical software systems forregulatory purposes (see Appendix). This documenthas not been reviewed for endorsement by consor-tium members. However, the document is consistent,for the most part, with the portion of consortium rec-ommendations related to the FDA.

Other than exemption, the two actions now availableto FDA for medical software devicesthe 510(k) pro-cess and the PMA processare inappropriately cumbersome for all but the highest risk category of clinicalsoftware systems. However, the FDA might serve aless intrusive monitoring role by requiring producersof exempt clinical software systems to list them asproducts with the FDA for monitoring purposes,without having to undergo the 510(k) or PMA pro-cesses. By assigning a universal registration ID to eachproduct, the FDA could develop a centralized database repository for collecting information on adverseclinical software events. Reporting of problems withindividual products could come to the FDA throughSOCs, or from individual users in sites without SOCs.The FDA could then collect and distribute aggregated,standardized reports of system-specic and globalproblems (including interactions).

Another benecial role the FDA could play would beto develop, in conjunction with vendors, clinical sites,professional organizations, and users, new, compre-hensive standards for clinical software product label-ing. Labels should describe system requirements,functions, document sources of medical information,and describe limitations of use. Labeling standards for



25/30


clinical software would be different than existing FDAstandards developed primarily for hardware medicaldevices. The FDA could require manufacturers of bothexempt and non-exempt software products to adhereto the labeling standards. As noted in Table 2C, theFDA could modify its approach to certain intermedi-ate-risk commercial products by creating an expeditedprocess to verify that the products labeling conformsto FDA standards. The FDA would then assign a post-marketing surveillance ID to such products and care-fully monitor for evidence of adverse effects. If a suf-cient number of concerns were raised duringproduct monitoring, the manufacturer would then berequired to submit full-scale 510(k) or PMA applica-tions to be permitted to continue marketing.

Explanation of Recommendation 4: Adoption ofGuidelines by Clinical Software Producersand Distributors

The health care information system industry, throughthe Center for Healthcare Information Management(CHIM), is in the process of rening its code of good business practices. This code, in conjunction with ISO-9000, is expected to address use of sound softwaredevelopment and implementation methods appropri-ate to the level of clinical risk posed by a softwaresystem. It will also address the need for adequatetraining, for support of open industry standards formessages and communication, for protecting patientcondentiality, and for other relevant matters. Adher-ence to the guidelines should be strongly encouragedfor all clinical software systems, and be mandatory forhigher-risk systems. The FDA Current Good Manu-facturing Procedures (CGMPs) for individual prod-ucts may not work effectively for the complex soft-ware environments in large health care deliveryfacilities (see Fig. 1). The FDA currently requires med-ical device manufacturers to comply with ISO-9000-like regulations as part of their manufacturing pro-cess. Through SOCs, local institutions should developguidelines for the acquisition, testing, installation,training, and monitoring of the potentially complexsystems under their control, in the spirit of ISO-9000.Local SOCs should also oversee implementation andmonitoring of local guidelines, and interinstitutionalsharing of experiences.

Examples of guidelines for good business practices in-clude the following: Manufacturers should discloseexisting evaluations of software products (noting howthey relate, if at all, to the current product) for usersto review before purchasing systems. Developersshould help users to estimate how often and by whatmechanism system componentsincluding databasesor knowledge bases, as well as software codeneed

to be upgraded or replaced. Users and/or external re-viewers should determine if upgrades are of profes-sional quality. Vendors and users should verify thatupgrades are made available or distributed to all whoshould receive them. Vendors should help local usersto ensure that only users who are well qualied (i.e.,possess sufcient biomedical knowledge) and welltrained (i.e., have adequate skill in using the program)will have access to a given clinical software system.In addition to standard software version control prac-tices, developers should document sources and datesof creation/revision for biomedical knowledge embedded in software programs. Manufacturers shoulddisclose any known risks and limitations associatedwith a clinical software product, and inform users of

their responsibility to detect and override faulty sys-tem recommendations. Outdated systems shouldadvertise to users that their components are poten-tially invalid e.g., through start-up screens thatforce users to acknowledge that the system is out-dated before allowing the users to proceed, or throughprominent banners displayed at all times during sys-tem usage. If warnings are not adequate for high-riskor signicantly compromised outdated components,the system might simply prevent users from usingoutdated functions by removing access to the func-tions from the system. Vendors, as well as regulators,should provide standardized forms and convenient

avenues for problem reporting. Manufacturers shouldensure that notication procedures are in force forhigher-risk product categories to ensure users areaware of product alerts, recalls, and upgrades. Man-ufacturers should continue to utilize guidelines thatprotect patients and users through the expedited, ef-cient testing of new system components and up-grades. Last but not least, manufacturers shouldadopt and adhere to, whenever possible, national orinternational standards for data representation andexchange. 63

Explanation of Recommendation 5:Collaboration to Evolve Clinical SoftwareMonitoring and Regulation

Institutions with installed advanced health care infor-mation systems should implement SOCs and sharetheir experiences and recommendations with others.The expanded consortium, consisting of clinical pro-fessional associations, vendor organizations, regula-tory agencies, and user communities, should evolvethe guidelines contained in recommendations 1through 4 as they gain increasing experience withapproaches to monitoring and regulating clinicalsoftware systems. Focus groups, the peer-reviewedliterature, regional and national conferences, Internet-



26/30


based information resources, and other means should be used to disseminate the information.

Summary

Clinical software systems are ubiquitous. A growingliterature documents the benets of such systems forimproved health care delivery. While no reports sug-gest that many patients are being harmed by stand-alone clinical software systems, concerns for patientsafety must be addressed. The consortium recom-mends local oversight of clinical software systemsthrough Software Oversight Committees (SOCs), andadoption by health care information system vendorsof a code of good business practices. Budgetary andother constraints limit the type and number of sys-tems that the FDA can regulate effectively. Most clin-ical software systems should be exempted from FDAregulation. FDA regulation should focus on patient-specic commercial software systems that pose highclinical risk (e.g., directly control life support systemsor directly administer potentially dangerous thera-pies) that are not modied locally (i.e., are not underlocal programming control) and which offer little orno opportunity for practitioner intervention. For suchclosed loop systems, based on the degree of riskposed, we recommend the traditional FDA 510(k) no-tication process and full-scale pre-market approval.

During pre-market trials for such narrowly dened,high-risk, closed loop systems, it must b