A fundamental issue around EMR Usability
Designing a good Electronic Health Record (EHR) system – one which balances usability and flexibility with structure and interoperability – is a challenge (to say the least). Not just for us, but for the entire industry.
It is clear that good usability is critically important in order that EHR technology be embraced by health care practitioners and patients (the general public) alike. It is also clear that bad usability can result not only in workflow slowdown (and therefore lost revenue), but also in actual patient harm.
Many observers have commented that a “good” EHR system should be able to capture the unique narrative that describes a clinical encounter. Each specialty, each practitioner – indeed, each encounter – should have documentation tools that allow capture of the unique clinical content of the encounter. In a pre-EHR environment, this has been done by handwritten (or dictated) chart notes – in an EHR environment, this would be considered Free Text. Free Text is infinitely flexible and is what clinicians are used. It contains meaning (in a human sense).
The problem with Free Text is precisely its flexibility – it is not standardized. Thus, the ability of computers to extract and interpret meaning (in a computer sense) is very limited. Sharing data between different systems – including other clinicians’ EHRs, as well as health plans, Health Information Exchanges (HIEs), and quality metric and public health reporting to government centers – is very difficult with Free Text. An EHR needs Structured Data as much as possible.
Balancing Free Text with Structured Data is an art. Different approaches – different EHRs – vary all along the spectrum on this balance. On the Structured Data end of the spectrum are highly “template-oriented” systems, where the User Interface (UI) consists of a collection of forms which can be picked and clicked, resulting in highly-structured data capture (the form forces the user to select among specified lists and fixed options). This is great for computer querying and report generation. It is also terrible for capturing the unique nuances of real-life clinical encounters, and conveying meaning (in a human sense).
As an example, the Emergency Room of my local hospital recently adopted an EHR tailored to ERs. It is highly structured, and creates visit documentation that is almost impossible to interpret. One has to filter through the 5 or 6 pages of printout and glean the two or three critical elements of clinical importance – what was your presenting complaint, what tests were done, what was the ER doc’s reasoning and conclusions as to the diagnosis, what meds were given, and what was the follow-up recommended? It actually takes a learning-curve to learn how to interpret the documentation! It is little better than the pre-EHR illegible scribbles on a standardized paper form – well… at least the new approach is legible.
We are in an age of rapidly-evolving Health IT, and the direction of change in this sector might be thought of as “modularity and interoperability.” The old, massive, legacy client/server all-inclusive EHRs which had dominated the landscape (prior to the emergence of web-based Health 2.0 technologies, including full web-based EHRs) has difficulty adapting to these rapid changes, and will likely continue to offer excessively form-driven UIs (with the strategic view that Structured Data is more important that Usability). However, web technologies are in the process of fundamentally changing that landscape. In fact, the Health 2.0 Developer’s Challenge, which encourages the developer community to come up with modular and interoperable tools for clinicians and patients to use – sort of an “App Store” for Health IT – is a great example of this trend.
So how do we balance Structured Data (needed for interoperability) with meaning (in a human sense) that clinicians need? As a wide array of new apps hit the market, the market will decide. Our own approach has been to capture Structured Data where needed for reporting, quality metrics, and sharing – demographic information, vital signs, medications, diagnoses, allergies, immunizations, lab data, etc. – and allow for robust areas of Free Text (helped along by flexible Smart Templates, which really function as macros for semi-structured free-text creation) in areas where nuanced clinical content is needed (such as in the body of a chart note).
The right balance will emerge, as the needs for interoperability, for usability, and ease-of-adoption become clearer with accumulating experience. The balance may seem like an arcane discussion, but it is critically important if we are to build tools that clinicians use, that patients can use, that improve the quality of healthcare delivered (while reducing disparities), and render meaning (both in a human and computer sense).
Robert Rowley, MD
Chief Medical Officer
Practice Fusion EMR