Slow electronic health records: two root problems
EHR performance speed is very important to the user experience; but their are two very different sources for the cause of slowdowns.
Please consider contributing to the document trying to collect all causes of EHR speed @ Factors that affect EHR Speed (Google Document)
Listen to this post in audio in your podcast app under Gregory Schmidt, or via YouTube
One of the most common comments clinicians have about their electronic health record is speed. Generally, its too slow.
Clinicians frequently, and rightfully, complain that the introduction of electronic health records (EHRs) have slowed down their previous analog workflows. For many, paper was more efficient than a new digital systems.
The purpose of this post is to underscore the fact that a slow and cumbersome EHR experience may be attributable to two very different groups: software issues and implementation issues. It is important to focus on the right group when trying to optimize the system.
Software issues: are related to the EHR tool itself. Such as its user interface design, the ability to customize to workflows, how easy it is to learn, and the ways it has been optimized to deliver page load speed and performance.
Implementation Issues: related to how the tool is integrated into care. Such as if new fields or mandatory fields have been introduced, what devices the software is installed on, and how the software replaces existing clinical workflows.
Often the organization that is responsible for building the software is different from the organization implementing it.
Many of the criticisms clinicians have about their EHR experience are often the result of both software and implementation issues.
For instance, administration and management committees often add many new mandatory fields and forms that did not exist on paper when electronic health records are introduce. Sometimes new mandatory fields are not added, but everyone skipped over these fields on paper. Clinical slowdowns from this cause are not the fault of the software, but how it was implemented. Solving them requires a conversation between clinical staff and administration.
This does not let the EHR vendors off the hook for the software. In my opinion, EHR vendors too often attribute poor clinician satisfaction with EHRs to ‘bad implementations’. Although it is true that bad implementations can make software even worse, in survey after survey, clinicians raise the poor user interface as a problem with the modern medical record. Many EHR systems also do not preload data to speed of clinic work, or optimize for offline functionality.
Well built software, can make implementations more successful, and even mitigate against bad implementations.
Comprehensive list:
Factors that affect EHR Speed
In order to help validate the hypothesis, "We can build an EHR clinicians eagerly choose to use over paper" it is important that the system is blazingly fast. (Or at least, I'm am assuming this is a critical factor)
I am compiling a comprehensive document of all known factors that affect EHR usability speed.
This document will be used to identify which areas should be targeted first, to optimize the speed of an EHR in real-life clinical workflows. The focus on what to work on would be on highest speed performance relative to least effort required to achieve it.
Please consider contributing to that Google document linked to in the blogpost. I anticipate the list changing over the coming weeks and therefore will leave the details out of this post at this time:
Contribute at: Factors that affect EHR Speed (Google Document)
