Shared responsibility
According to the JAMA commentary, the SAFER guides were developed “to help health care organizations and EHR developers conduct voluntary self-assessments to help eliminate or minimize EHR-related safety risks and hazards.”
In response to a query from this news organization, ONC confirmed that the SAFER guides were intended for use by developers as well as practitioners. ONC said it supports CMS’s approach to incentivize collaborations between EHR vendors and health care organizations. It noted that some entities have already teamed up to the meet the SAFER guides’ recommendations.
Hospitals and EHR developers must share responsibility for safety, Dr. Sittig and Dr. Singh argue, because many SAFER recommendations are based on EHR features that have to be programmed by developers.
For example, one recommendation is that patient identification information be displayed on all portions of the EHR user interface, wristbands, and printouts. Hospitals can’t implement this feature if the developer hasn’t built it into its product.
Dr. Sittig and Dr. Singh suggest three strategies to complement CMS’s new regulation:
- Because in their view, ONC’s EHR certification criteria are insufficient to address many patient safety concerns, CMS should require EHR developers to assess their products annually.
- ONC should conduct annual reviews of the SAFER recommendations with input from EHR developers and safety experts.
- EHR vendors should disseminate guidance to their customers on how to address safety practices, perhaps including EHR configuration guides related to safety.
Safety in EHR certification
At a recent press conference that ONC held to update reporters on its current plans, officials were asked to comment on Dr. Sittig’s and Dr. Singh’s proposition that EHR developers, as well as hospitals, do more to ensure system safety.
Steve Posnack, deputy national coordinator of health IT, noted that the ONC-supervised certification process requires developers to pay attention to how they “implement and integrate safety practices in their software design. We have certification criteria … around what’s called safety-enhanced design – specific capabilities in the EHR that are sensitive to safety in areas like e-prescribing, medication, and high-risk events, where you want to make sure there’s more attention paid to the safety-related dynamics.”
After the conference, ONC told this news organization that among the safety-related certification criteria is one on user-centered design, which must be used in programming certain EHR features. Another is on the use of a quality management system to guide the creation of each EHR capability.
Nevertheless, there is evidence that not all EHR developers have paid sufficient attention to safety in their products. This is shown in the corporate integrity agreements with the Office of the Inspector General (OIG) of the Department of Health and Human Services (HHS) that developers eClinicalWorks and Greenway agreed to sign because, according to the government, they had not met all of the certification criteria they’d claimed to satisfy.
Under these agreements, the vendors agreed to follow “relevant standards, checklists, self-assessment tools, and other practices identified in the ONC SAFER guides and the ICE Report(s) to optimize the safety and safe use of EHRs” in a number of specific areas.
Even if all EHRs conformed to the certification requirements for safety, they would fall short of the SAFER recommendations, Dr. Sittig says. “Those certification criteria are pretty general and not as comprehensive as the SAFER guides. Some SAFER guide recommendations are in existing certification requirements, like you’re supposed to have drug-drug interaction checking capabilities, and they’re supposed to be on. But it doesn’t say you need to have the patient’s identification on every screen. It’s easy to assume good software design, development, and testing principles are a given, but our experience suggests otherwise.”
