Summary of HIT Policy Committee Workgroup hearing on EHR Safety.

The certification and Implementation Work Group of the HIT Policy Committee met recently to discuss EHR safety issues. See my previous post on February 21, 2010 in which I discussed some of the aspects of EHR safety before the committee met. I had been planning to discuss the topic for a long time before I learned that the committee had scheduled a meeting dedicated to the safety issue. I will review my impressions of the testimony presented to the committee in this post.

Issue 1: Training. Potential safety issues arise because of the reluctance of clinicians to take the time out from busy and productive patient care for adequate training in the use of EHR systems. This must be understood in the context of the financial stresses on the medical profession, including decreasing reimbursements for clinical care and steadily and rapidly increasing operating expenses. An additional factor may be the impression of many clinicians that EHRs do not increase the practitioner's practice efficiency.

Many of the mature clinicians went through training before EHRs became wide-spread in academic centers so they have little experience using technology for clinical care. This results in a gap in technology aptitude between recently trained and more established clinicians. Another factor is the paucity of well trained educators at higher levels to provide training to clinicians that need it. There is a great need to educate the workforce in informatics at master's degree and PhD levels to support clinical research, public health, and other academic activities.

Issue 2: Error Reporting. An intense discussion was held about error reporting. Published reports on the safety of EHRs are contradictory. The mechanisms for safety reporting varies from state. The NASA ASRS system of the aviation industry should serve as the model for medicine. Characteristics include: anonymous error reporting, a culture that promotes learning from human error rather than punishment, and a third party that collects, aggregates, and distills accident information and then distributes the lessons learned throughout the industry. There was a lot of disagreement about whether error reporting should be voluntary or mandatory. One EHR vendor reports errors voluntarily to the FDA through MedWatch. Likewise, there was controversy about whether reporting should be confidential (as per the FAA program) or public (perhaps more transparent but also potentially more punitive.) Experience has shown that when public reporting programs are used, errors tend to be reported less often.

One regulatory barrier is the differences in reporting requirements at the state and federal level. Each state has its own requirements that generally take precedence over federal regulations. A federal law took effect in 2005 that established Public Safety Organizations (PSOs) that are based on the concept of confidential reporting and protection from legal consequences in most situations. Many members of the committee did not seem to understand fully how PSOs operate.

The possible role of "I'm Sorry" programs also was discussed. Apologizing to patients and their families when errors occur in medical practice has generally been shown to reduce the risk that the issue will be resolved as a tort case. On the other hand, regulations vary from state to state as do legal protections that are sometimes offered with these programs.

Issue #3. Vendor response to reported errors. Several of the vendors denied accusations of complacency in responding to errors in software design reported by their clients. They asserted that the vendor community is anxious to design and build safe EHR systems. It is likely that the major vendors take a proactive approach to dealing with any reported flaws in the software they market. How some of the less successful vendors respond to problems might be open to question.

Issue #4. FDA Role. The FDA representative spoke at length about the FDA role in monitoring EHR systems. The FDA classifies EHRs as medical devices and therefore they fall under its authority and responsibility. So far this authority has just not been exercised. That is not to say that it will not be used in the future. Pre-market oversight has the potential to significantly impact vendors by extending the length of time required to develop new products and increasing the costs of compliance. A new policy could critically impact the capability of vendors to deliver new products needed to fulfill the escalating meaningful use criteria in the new few years.

The FDA does not have a formal infrastructure in place to handle reports of unsafe EHR software. However it does accept voluntary error reports. A mandatory reporting program has not been instituted. Furthermore, unlike the situation in the aviation industry, a program to analyze reports, extract significant findings, and propagate best practices has not been developed.

Safety Issue #5. Safety of "home-grown" vs. vendor systems. Proponents of self-developed systems claim they have many years experience tweaking their EHRs. They have developed the specialized workforce needed to quickly identify, locate, and solve patient safety-related issues. Critics of the home-grown approach note that these systems have often been cobbled together from disparate subsystems over time. Coordinating these different systems via interfaces creates new possibilities for errors caused by the software. Several examples were mentioned.

Vendor created systems are usually fully integrated. They are less likely to cause the types of errors that arise from mismatched subsystems. (This is not always true because many companies have been formed by mergers and acquisitions so multiple components are often melded into a single, branded product.) A criticism of vendors is that because of the difficulty of migrating from one vendor to another there is a "locked-in" situation for the clients. The reasoning goes that vendors would not need to quickly respond to client issues. Realistically, a vendor selling a product that is not safe would not long survive in the active EHR marketplace. Even "out-of-the-box" systems are extensively customized to each installation site. The more customized these systems are, the greater the risk of unanticipated patient safety issues. Vendors may favor standardized implementations to minimize these risks but they still must respond to client demands for highly customized systems.

Issue #6. Certification testing. Several participants discussed the expected NPRM concerning certification. (The NPRM was released on March 2nd and published in the Federal Register on March 10th after the meeting.) Some committee members argued that site specific certification should be required even for vendor supplied products. Site specific testing was mentioned as a way to address the risks that customization introduces into the equation. No one explained how literally thousands of installations would be tested, what type of site-specific certification tests would be needed, and who would bear the costs for specific site testing of all EHRs. I don't think that data has been provided to support establishment of such an extensive program.

The following links are the actual reports and recommendations that the WG presented to the HIT Policy Committee on March 17, 2010.