FDA Regulation of EHRs

On February 25, 2009, at a Health Information Technology Policy Committee Adoption/Certification Workgroup meeting, Dr. Jeffrey Shuren, Director of FDA’s Center for Devices and Radiological highlighted concerns with the current state of regulation around Health Information Systems which are not currently actively regulated by FDA.  Dr. Shuren’s testimony highlighted three areas of concern:

• The FDA’s legal and regulatory authorities over medical devices and the approach we have taken with respect to HIT to date;
• A Review of various safety issues that have been reported to the FDA and other unique challenges presented by HIT; and
• Possible approaches the FDA could take in the future to help address these concerns.

(See Page 1 of prepared testimony of Jeffery Shuren, Director FDA Center for Devices and Radiological).

Legal and Regulatory Background

Traditionally the FDA’s regulatory process for health information systems has taken a hands-off approach – Dr. Shuren noted “To date, FDA has largely refrained from enforcing our regulatory requirements with respect to HIT devices. (See Page 1 of prepared testimony of Jeffery Shuren, Director FDA Center for Devices and Radiological).

In February 2008, the FDA proposed that Medical Device Data System (MDDS) Rule that would exempt certain medical systems from premarket disclosures under 510(k) of the Food, Drug and Cosmetic Act which generally requires device manufacturers who must register, to notify FDA of their intent to market a medical device at least 90 days in advance. The proposed MDDS Rule would change premarket notification requirements for medical system used only by a healthcare professional.  The software may transmit, store, or display data from medical devices without altering the function or parameters of the connected devices and system does not contain any diagnostic, decision support, alarm functions, and does not utilize irreversible compression. (73 Fed. Reg. 7503, 7504 (Feb. 8, 2008)(proposed rule 21 CFR § 880.6310)(available at http://edocket.access.gpo.gov/2008/pdf/E8-2307.pdf).While this rule has not officially become law, the FDA has to date refrained from imposing regulatory requirements on certain medical device data systems.

Issues Identified

Some HIT vendors have voluntarily registered and listed their software devices with the FDA, and some have provided submissions for premarket review. Additionally, patients, clinicians, and user facilities have voluntarily reported HIT -related adverse events. In the past two years, we have received 260 reports of HIT-related malfunctions with the potential for patient harm – including 44 reported injuries and 6 reported deaths.  Dr. Shuren emphasized that: “Because these reports are purely voluntary, they may represent only the tip of the iceberg in terms of the HIT-related problems that exist.” (See Page 2 of prepared testimony of Jeffery Shuren, Director FDA Center for Devices and Radiological).

A summary (refer to the table below for detailed information on the issues encountered) of the issues identified include-

1. Errors of commission, such as accessing the wrong patient’s record or overwriting one patient’s information with another’s (this sometimes can be an issue in incidents involving medical identity theft);
2. Errors of omission or transmission, such as the loss or corruption of vital patient data;
3. Errors in data analysis, including medication dosing errors of several orders of magnitude; and
4. Incompatibility between multi-vendor software applications and systems, which can lead to any of the above.

(See Page 2 of prepared testimony of Jeffery Shuren, Director FDA Center for Devices and Radiological).

Examples of Reported Adverse Events Involving Health Information Technology

Proposed Solutions

Dr. Shuren proposed three alternatives:

• The first approach would be to focus on post-market safety by requiring HIT device establishments to electronically register and list their HIT devices, and to submit Medical Device Reports (MDRs) to the FDA.  Under this approach, HIT device manufacturers would be responsible for correcting identified safety issues;
• A second approach would be to focus on manufacturing quality and post-market safety by requiring HIT device manufacturers to comply with the requirements described above, and also to adhere to FDA’s Quality Systems Regulation (QSR).  QSR requires manufacturers to adhere to specific minimum guidelines to assure the quality and consistency of products on the market. For example, the regulation requires that device manufacturers establish procedures for handling complaints from users, and for correcting and preventing recurrence of problems.  In addition the QSR requires all software devices comply with appropriate design controls to reduce the potential for problems.  Design controls are an interrelated set of practices and procedures that are incorporated into the design and development process of a device, in order to check for problems and make corrections in the design of the device before it is put into production; and
• The third approach, the FDA would apply its traditional regulatory framework, and require Health Information Systems to meet all the same regulatory requirements as other, more traditional devices, including risk-based premarket review.  Through pre-market review, the FDA could assess the safety and effectiveness of high- and medium-risk devices before they go into market use. The FDA could require that manufacturers provide as prerequisites for approval a clear installation plan for a given HIT device, or a hazard analysis of risk associated with medical-facility-specific configuration.  The FDA could also require post-market studies or specific product labeling for particular devices as conditions for approval.

(See Page 3 of prepared testimony of Jeffery Shuren, Director FDA Center for Devices and Radiological).

Guidance from the FDA on the Software Development Process

The FDA has encouraged vendors to follow normal software development practices for medical software for the last two decades.  In early, August 2001 the FDA published a guidance document for electronic health record systems and digital signatures.  This document is entitled Guidance for Industry, 21 CFR Part 11; Electronic Records; Electronic Signatures Validation (Draft Guidance) available at http://www.fda.gov/ora/compliance_ref/part11.htm.  This document is consistent with the FDA’s traditional approach of not regulating medical software that is not embedded http://www.fda.gov/cdrh/ode/351.pdf in medical devices.  Generally it is assumed that a trained medical professional will always evaluate any software-generated information, calculation, or medical recommendation. (See http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/default.htm). (18 CFR 880)(available at http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfr&tpl=/ecfrbrowse/Title21/21cfr880_main_02.tpl).

The FDA’s recommendation in this guidance document follows traditional software development methodologies:

• System Requirements Specifications. Software requirements are extremely important for computer systems validation.  The FDA (and standard software development practices) require that one document end user needs and intended uses, and then should obtain evidence that the computer system implements those needs correctly and that they are traceable to system design requirements and specifications.  Often software requirements tests (unit tests) are written before the software is created;
• Ensuring Confidentiality, Integrity and Availability of Electronic Health Records.  The FDA emphasizes the importance of ensuring the authenticity, integrity, availability, confidentiality of electronic health records.  Safeguards typically include data encryption and use of digital signatures (asymmetric encryption keys) to ensure record authenticity, integrity, and confidentiality;
• Documentation of Validation Activity.  The FDA’s guidance’s emphasizes the importance of documenting a validation plan, procedures, and report.  “The validation report should document detailed results of the validation effort, including test results. Whenever possible, test results should be expressed in quantified terms rather than stated as “pass/fail.” The report should be reviewed and approved by designated management.” (Section 5.2.3 of FDA Draft Guidance.);
• System Integration of Hardware and Software.  With each deployment to perform test cases, prior to testing, one should confirm that all hardware and software are properly installed.  EHR systems should include standard operating procedures, equipment lists, specification sheets, and document administrative procedures; and
• Dynamic Testing.  Test conditions should include “normal” and also boundary values including a high number of users accessing a network at the same time). Test conditions should extend to boundary values, unexpected data entries, error conditions, reasonableness challenges (e.g., empty fields, and date outliers), branches, data flow, and combinations of inputs.  The FDA recommends both black (functional) and white box (structural) testing.

Further Reading

FDA’s 510(k) Operations Could Be Improved, GAO Report

MEDICAL DEVICES Shortcomings in FDA’s Premarket Review, Postmarket Surveillance, and Inspections of Device Manufacturing Establishments, GAO Report

Dr. Shruden Prepared Testiony February 2010

Draft Guidance for Industry, User Facilities and FDA Staff eMDR – Electronic Medical Device Reporting Document Issued on: August 21, 2009

Guidance for Industry 21 CFR Part 11; Electronic Records; Electronic Signatures Validation

GAO Report, MEDICAL DEVICES FDA- Should Take Steps to Ensure That High-Risk Device Types Are Approved through the Most Stringent Premarket Review Process

[thumb]http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/Overview/[/thumb]

Related Blogs

• Computer Internet network security News » Guidance On Effective …
• Best forex trading system for low price? | SEAL America, Larry Huggins
• PHP Development India – maglev08.com
• Metropolitan Library System – Stephen's Lighthouse
• North Suburban Library System – Stephen's Lighthouse
• FCC, FDA to work on effective mHealth regulation | mobihealthnews
• Iran Document: Mousavi Speech on “Patience and Resistance” (15 …
• Book preview: PHP 5 E-commerce Development « Eirik Hoem's Blog
• Device Allows Blind Man to See with his Tongue
• Microsoft Courier – Digital Journal Tablet Device? (Rumour)
• Mr Klein the underwear washing machine by Yoon Kisang » Yanko Design
• Agricultural Urbanism by Greg Chung Whan Park » Yanko Design
• Amylin, Alkermes Diabetes Drug Delayed by FDA | Xconomy
• VG247 » Blog Archive » Rockstar going for a “different approach …
• Device Enables Blind People To “See” With Their Tongue – PSFK
• Postal Service's parent agency urges go-slow approach | Postal Project
• Electoral Commission publishes draft guidance on whether counts …
• Is the U.S. Census Form a Legal Document? « LewRockwell.com Blog
• Laserfiche News Portal – Document Management and Enterprise …
• Document Management Software Benubird PDF

          

Related posts:

1. P2P Leaks of Protected Health Information –HIPAA Covered Entities and Business Associates Should Have a P2P Software Policy Either Prohibiting the Use of P2P Software or Instructing Users on the Safe Use of P2P Software. One of the most common (and high risk) user installed...
2. Health Information Technology Public Utility Act of 2009 Would Facilitate the Adoption of Open Source EMR Solutions On April 23rd Senator John Rockefeller IV introduced the Health...
3. The Elephant in the Room – Implementation Issues for a National Health Information Network from HIMSS 2010 HIMSS is the largest health care technology conference in the...
4. NIST announced the publication of Initial Public Draft Special Publication 800-128, Guide for Security Configuration Management of Information Systems. Configuration management remains a challenging issue especially for small and...
5. Analysis of the HITECH Act’s Incentives to Facilitate Adoption of Health Information Technology The “Health Information Technology for Economic and Clinical Health Act’’...