The IOM on EHRs

The   issue of the EHR relative to safety and effectiveness has again made the news with the November 7, 2011 pre-publication (and downloadable) release of an Institute of Medicine report on EHR safety, commissioned by the U.S. Department of Health and Human Services (HHS). This report expands the discussion beyond the EHR (used henceforth for both EHR and EMR) to include other related electronic information tools collectively called health IT.

Health IT Risks

The potential for health IT to improve both the quality and efficiency of medical care has been much noted to include more complete and timely records, ready exchange of information between providers, clinical decision support, and in turn a reduction in errors associated with the quality and availability of patient information. Efficiencies may arise from electronic capture of data which would eliminate manual entry, and time savings in accessing and reviewing patient information, and perhaps in passing information to third party payers. Additional public health value might accrue from the enhanced searchability of electronic records with respects to trends, treatments and outcomes. These benefits assume well designed, user friendly, compatible systems not withstanding that the U.S. model is to allow for numerous independent products that may or may not be able to exchange information nor display it in a consistent manner. Not surprisingly the report notes that the IT imperative will likely not be fruitful without associated attention to the people and the clinical system they work in.

However there is also the potential for health IT to add to, rather then reduce complexity; misplace, lose or garble patient information, and to provide clinical decision support that is incorrect or unreliable. Thus health IT itself has risks that the IOM found have not yet been adequately addressed or monitored. The IOM also cites the lack of an effective health IT problem reporting system compounded by contractual language that may actually impede such reporting. In addition some vendors include disclaimers as to their responsibilities even for software defects and errors. The latter suggests the all purpose liability disclaimer language: "Notice-this product may be badly designed and therefore not suitable for its intended purpose." Alternatively one could try: "Due to software defects the information in this EHR may or may not be complete and/or may not pertain to  the patient of interest. Do not use this information for medical treatment". The value of such disclaimers will no doubt be tested.

Of course it is not only coding defects that can make heath IT less than effective. The well established issue of usability, or user friendliness, lives on, as does interoperability, training and workflow design. In this regard it might be noted that user friendly features such as pull down menus also facilitate quick but erroneous entries. Thus while an IT product might be theoretically capable of being used properly and effectively, whether it will achieve that goal in the real environment of use, when used by real people, is a separate matter. In this regard when faced with use issues and adverse events vendors will want to say that their product could have provided the correct functionality if only it had been used correctly--and don't forget our disclaimer. The counter argument is that it was badly designed to the degree that "correct" use was predictably not likely to consistently occur. There are many anecdotes in this regard. A favorite of mine was an order entry system to which was added a physical sticky note on the monitor that read "Do not press Enter to Enter".

Actual health IT hazards are at least in part separate from the questions of privacy, hacking and other mischief.

It must also be remembered that quantitative data (e.g. lab results and other medical device data), or reasonably well standardized data (e.g. images) are potentially much easier to capture, transmit and display than narrative information. The selection and arrangement of information on a display can also be a significant challenge with respect to density, utility and how many pages the clinician has to look at to get all the information needed--and you can't spread those pages out. There is also a significant issue with the lack of standardization of "look and feel" factors. In this regard it must be remembered that clinicians of various types, working in multiple environments, might see multiple systems during even a single day. This is analogous to the reality of nurse use of infusion pumps. Ask the nurse if they know how to use an infusion pump and they will most likely say yes (and be insulted). But then ask them if they know how to use a particular infusion pump and they might say, no, I've never seen one of those before. In this regard a health IT application may be plug-and play, but that isn't the same as plug-and-effectively-use.

IOM Report Recommendations

The report has several specific recommendations:

• A comprehensive effort to asses safety and risk
• Vendors should support the free exchange of information about health IT experiences and issues and not prohibit sharing of such information, including details (e.g., screenshots) related to patient safety
• HHS should make comparative user experiences publicly available
• A new Health IT Safety Council should be funded by HHS to evaluate criteria for assessing and monitoring the safe use of health IT and its ability to enhance safety
• The registration and listing of products from all vendors
• Specification of the quality and risk management process requirements that health IT vendors must adopt, with a particular focus on human factors, safety culture, and usability
• Establishment of a mechanism for both vendors and users to report health IT related deaths, serious injuries, or unsafe conditions
• Establishment of an independent federal entity for investigating patient safety deaths, serious injuries,or potentially unsafe conditions associated with health IT
• Regular monitoring and reporting of health IT safety by HHS, and the FDA should be charged with developing applicable regulations
• HHS should support usability research

Readers familiar with the FDA regulation of medical devices will recognize many of these items as standard fare. These include registration and listing, quality systems, and problem reporting. However since the FDA has not asserted that EHRs are medical devices, and the IOM elected not to make that specific recommendation.

Record-type health IT products remain in a regulatory vacuum--except with respect to acquisition funding subject to the meaningful use requirements. In this regard the report includes a dissenting statement from Richard Cook, MD (director of the Cognitive Technologies Laboratory at the University of Chicago) who asserts that health IT products should not only be declared to be medical devices, but that they should be Class III, the most stringently regulated device classification. In this regard he includes the following quote: "Medical and diagnostic devices have produced a therapeutic revolution, but in doing so they have also become more complex and less easily understood by those who use them. When well designed, well made, and properly used they support and lengthen life. If poorly designed, poorly made, and improperly used they can threaten and impair it." While this quote could appear in nearly any one of the posts here, it actually dates to 1976 as part of President Gerald Ford's signing statement for the Medical Device Amendments that ushered in the modern era of medical device regulation. While these amendments are often thought of as the beginning of  FDA medical device regulation, such regulation actually stems from the 1930's. What did start in 1976 was before-marketing restraints as opposed to the FDA's prior post market authority. (And no, 1976 is not ancient history. Some of us actually remember it.)

Health IT is caught in the corn maze of promise vs usability and hazards. With quality design and thoughtful implementation the exit may be found before nightfall. Without it someone is going to have to call 911.