User login
In a little-noticed action last month, so as to meet an objective of the Medicare Promoting Interoperability Program, starting next year.
Experts praised the move but said that EHR developers should share the responsibility for ensuring that the use of their products doesn’t harm patients.
A number of safety problems are associated with hospital EHR systems, ranging from insufficient protection against medication errors and inadvertent turnoffs of drug interaction checkers to allowing physicians to use free text instead of coded data for key patient indicators. Although hospitals aren’t required to do anything about safety problems that turn up in their self-audits, practitioners who perform the self-assessment will likely encounter challenges that they were previously unaware of and will fix them, experts say.
Studies over the past decade have shown that improper configuration and use of EHRs, as well as design flaws in the systems, can cause avoidable patient injuries or can fail to prevent them. For example, one large study found that clinical decision support (CDS) features in EHRs prevented adverse drug events (ADEs) in only 61.6% of cases in 2016. That was an improvement over the ADE prevention rate of 54% in 2009. Nevertheless, nearly 40% of ADEs were not averted.
Another study, sponsored by the Leapfrog Group, found that EHRs used in U.S. hospitals failed to detect up to 1 in 3 potentially harmful drug interactions and other medication errors. In this study, about 10% of the detection failures were attributed to design problems in EHRs.
The new CMS measure requires hospitals to evaluate their EHRs using safety guides that were developed in 2014 and were revised in 2016 by the Office of the National Coordinator for Health IT (ONC). Known as the Safety Assurance Factors for Resilience (SAFER) guides, they include a set of recommendations to help health care organizations optimize the safety of EHRs.
Surprises in store for hospitals
Dean Sittig, PhD, a professor at the University of Texas Health Science Center, Houston, told this news organization that a 2018 study he conducted with his colleague Hardeep Singh, MD, MPH, found that eight surveyed health care organizations were following about 75% of the SAFER recommendations.
He said that when hospitals and health care systems start to assess their systems, many will be surprised at what they are not doing or not doing right. Although the new CMS rule doesn’t require them to correct deficiencies, he expects that many will.
For this reason, Dr. Sittig believes the requirement will have a positive effect on patient safety. But the regulation may not go far enough because it doesn’t impose any requirements on EHR vendors, he said.
In a commentary published in JAMA, Dr. Sittig and Dr. Hardeep, a professor at the Michael E. DeBakey VA Medical Center and Baylor College of Medicine, cite a study showing that 40% of “EHR-related products” had “nonconformities” with EHR certification regulations that could potentially harm patients. “Many nonconformities could have been identified by the developer prior to product release,” they say.
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.”
Configuration problems
A handful of vendors are working on what the JAMA article suggests, but there are about 1,000 EHR developers, Dr. Sittig notes. Moreover, there are configuration problems in the design of many EHRs, even if the products have the recommended features.
“For example, it’s often possible to meet the SAFER recommendations, but not all the vendors make that the default setting. That’s one of the things our paper says they should do,” Dr. Sittig says.
Conversely, some hospitals turn off certain features because they annoy doctors, he notes. For instance, the SAFER guides recommend that allergies, problem list entries, and diagnostic test results be entered and stored using standard, coded data elements in the EHR, but often the EHR makes it easier to enter free text data.
Default settings can be wiped out during system upgrades, he added. That has happened with drug interaction checkers. “If you don’t test the system after upgrades and reassess it annually, you might go several months without your drug-drug interaction checker on. And your doctors aren’t complaining about not getting alerts. Those kinds of mistakes are hard to catch.”
Some errors in an EHR may be caught fairly quickly, but in a health system that treats thousands of patients at any given time, those mistakes can still cause a lot of potential patient harm, Dr. Sittig points out. Some vendors, he says, are building tools to help health care organizations catch those errors through what is called “anomaly detection.” This is similar to what credit card companies do when they notice you’ve bought a carpet in Saudi Arabia, although you’ve never traveled abroad, he notes.
“You can look at alert firing data and notice that all of a sudden an alert fired 500 times today when it usually fires 10 times, or it stopped firing,” Dr. Sittig observes. “Those kinds of things should be built into all EHRs. That would be an excellent step forward.”
A version of this article first appeared on Medscape.com.
In a little-noticed action last month, so as to meet an objective of the Medicare Promoting Interoperability Program, starting next year.
Experts praised the move but said that EHR developers should share the responsibility for ensuring that the use of their products doesn’t harm patients.
A number of safety problems are associated with hospital EHR systems, ranging from insufficient protection against medication errors and inadvertent turnoffs of drug interaction checkers to allowing physicians to use free text instead of coded data for key patient indicators. Although hospitals aren’t required to do anything about safety problems that turn up in their self-audits, practitioners who perform the self-assessment will likely encounter challenges that they were previously unaware of and will fix them, experts say.
Studies over the past decade have shown that improper configuration and use of EHRs, as well as design flaws in the systems, can cause avoidable patient injuries or can fail to prevent them. For example, one large study found that clinical decision support (CDS) features in EHRs prevented adverse drug events (ADEs) in only 61.6% of cases in 2016. That was an improvement over the ADE prevention rate of 54% in 2009. Nevertheless, nearly 40% of ADEs were not averted.
Another study, sponsored by the Leapfrog Group, found that EHRs used in U.S. hospitals failed to detect up to 1 in 3 potentially harmful drug interactions and other medication errors. In this study, about 10% of the detection failures were attributed to design problems in EHRs.
The new CMS measure requires hospitals to evaluate their EHRs using safety guides that were developed in 2014 and were revised in 2016 by the Office of the National Coordinator for Health IT (ONC). Known as the Safety Assurance Factors for Resilience (SAFER) guides, they include a set of recommendations to help health care organizations optimize the safety of EHRs.
Surprises in store for hospitals
Dean Sittig, PhD, a professor at the University of Texas Health Science Center, Houston, told this news organization that a 2018 study he conducted with his colleague Hardeep Singh, MD, MPH, found that eight surveyed health care organizations were following about 75% of the SAFER recommendations.
He said that when hospitals and health care systems start to assess their systems, many will be surprised at what they are not doing or not doing right. Although the new CMS rule doesn’t require them to correct deficiencies, he expects that many will.
For this reason, Dr. Sittig believes the requirement will have a positive effect on patient safety. But the regulation may not go far enough because it doesn’t impose any requirements on EHR vendors, he said.
In a commentary published in JAMA, Dr. Sittig and Dr. Hardeep, a professor at the Michael E. DeBakey VA Medical Center and Baylor College of Medicine, cite a study showing that 40% of “EHR-related products” had “nonconformities” with EHR certification regulations that could potentially harm patients. “Many nonconformities could have been identified by the developer prior to product release,” they say.
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.”
Configuration problems
A handful of vendors are working on what the JAMA article suggests, but there are about 1,000 EHR developers, Dr. Sittig notes. Moreover, there are configuration problems in the design of many EHRs, even if the products have the recommended features.
“For example, it’s often possible to meet the SAFER recommendations, but not all the vendors make that the default setting. That’s one of the things our paper says they should do,” Dr. Sittig says.
Conversely, some hospitals turn off certain features because they annoy doctors, he notes. For instance, the SAFER guides recommend that allergies, problem list entries, and diagnostic test results be entered and stored using standard, coded data elements in the EHR, but often the EHR makes it easier to enter free text data.
Default settings can be wiped out during system upgrades, he added. That has happened with drug interaction checkers. “If you don’t test the system after upgrades and reassess it annually, you might go several months without your drug-drug interaction checker on. And your doctors aren’t complaining about not getting alerts. Those kinds of mistakes are hard to catch.”
Some errors in an EHR may be caught fairly quickly, but in a health system that treats thousands of patients at any given time, those mistakes can still cause a lot of potential patient harm, Dr. Sittig points out. Some vendors, he says, are building tools to help health care organizations catch those errors through what is called “anomaly detection.” This is similar to what credit card companies do when they notice you’ve bought a carpet in Saudi Arabia, although you’ve never traveled abroad, he notes.
“You can look at alert firing data and notice that all of a sudden an alert fired 500 times today when it usually fires 10 times, or it stopped firing,” Dr. Sittig observes. “Those kinds of things should be built into all EHRs. That would be an excellent step forward.”
A version of this article first appeared on Medscape.com.
In a little-noticed action last month, so as to meet an objective of the Medicare Promoting Interoperability Program, starting next year.
Experts praised the move but said that EHR developers should share the responsibility for ensuring that the use of their products doesn’t harm patients.
A number of safety problems are associated with hospital EHR systems, ranging from insufficient protection against medication errors and inadvertent turnoffs of drug interaction checkers to allowing physicians to use free text instead of coded data for key patient indicators. Although hospitals aren’t required to do anything about safety problems that turn up in their self-audits, practitioners who perform the self-assessment will likely encounter challenges that they were previously unaware of and will fix them, experts say.
Studies over the past decade have shown that improper configuration and use of EHRs, as well as design flaws in the systems, can cause avoidable patient injuries or can fail to prevent them. For example, one large study found that clinical decision support (CDS) features in EHRs prevented adverse drug events (ADEs) in only 61.6% of cases in 2016. That was an improvement over the ADE prevention rate of 54% in 2009. Nevertheless, nearly 40% of ADEs were not averted.
Another study, sponsored by the Leapfrog Group, found that EHRs used in U.S. hospitals failed to detect up to 1 in 3 potentially harmful drug interactions and other medication errors. In this study, about 10% of the detection failures were attributed to design problems in EHRs.
The new CMS measure requires hospitals to evaluate their EHRs using safety guides that were developed in 2014 and were revised in 2016 by the Office of the National Coordinator for Health IT (ONC). Known as the Safety Assurance Factors for Resilience (SAFER) guides, they include a set of recommendations to help health care organizations optimize the safety of EHRs.
Surprises in store for hospitals
Dean Sittig, PhD, a professor at the University of Texas Health Science Center, Houston, told this news organization that a 2018 study he conducted with his colleague Hardeep Singh, MD, MPH, found that eight surveyed health care organizations were following about 75% of the SAFER recommendations.
He said that when hospitals and health care systems start to assess their systems, many will be surprised at what they are not doing or not doing right. Although the new CMS rule doesn’t require them to correct deficiencies, he expects that many will.
For this reason, Dr. Sittig believes the requirement will have a positive effect on patient safety. But the regulation may not go far enough because it doesn’t impose any requirements on EHR vendors, he said.
In a commentary published in JAMA, Dr. Sittig and Dr. Hardeep, a professor at the Michael E. DeBakey VA Medical Center and Baylor College of Medicine, cite a study showing that 40% of “EHR-related products” had “nonconformities” with EHR certification regulations that could potentially harm patients. “Many nonconformities could have been identified by the developer prior to product release,” they say.
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.”
Configuration problems
A handful of vendors are working on what the JAMA article suggests, but there are about 1,000 EHR developers, Dr. Sittig notes. Moreover, there are configuration problems in the design of many EHRs, even if the products have the recommended features.
“For example, it’s often possible to meet the SAFER recommendations, but not all the vendors make that the default setting. That’s one of the things our paper says they should do,” Dr. Sittig says.
Conversely, some hospitals turn off certain features because they annoy doctors, he notes. For instance, the SAFER guides recommend that allergies, problem list entries, and diagnostic test results be entered and stored using standard, coded data elements in the EHR, but often the EHR makes it easier to enter free text data.
Default settings can be wiped out during system upgrades, he added. That has happened with drug interaction checkers. “If you don’t test the system after upgrades and reassess it annually, you might go several months without your drug-drug interaction checker on. And your doctors aren’t complaining about not getting alerts. Those kinds of mistakes are hard to catch.”
Some errors in an EHR may be caught fairly quickly, but in a health system that treats thousands of patients at any given time, those mistakes can still cause a lot of potential patient harm, Dr. Sittig points out. Some vendors, he says, are building tools to help health care organizations catch those errors through what is called “anomaly detection.” This is similar to what credit card companies do when they notice you’ve bought a carpet in Saudi Arabia, although you’ve never traveled abroad, he notes.
“You can look at alert firing data and notice that all of a sudden an alert fired 500 times today when it usually fires 10 times, or it stopped firing,” Dr. Sittig observes. “Those kinds of things should be built into all EHRs. That would be an excellent step forward.”
A version of this article first appeared on Medscape.com.