The authors of this article like to believe that we can remain humanists while transitioning from a paper-native to a digital-native industry. We even believe you can remain a humanist while following regulations and sticking to industry guidelines. Margalit Gur-Arie doesn’t seem to feel that way. We have read her work over the years and established that she takes a staunchly humanistic approach to health IT. But even though she’s a leader in that space, she appears to doubt the contributions that either technology or regulation make to a humane health system.
Gur-Arie’s most recent posting dismisses all the tools that electronic health records throw in the way of the doctor: clinical decision support (now often called evidence-based medicine–were we Gur-Arie, we’d say it’s because who can argue against evidence?), reminders, pull-down menus to provide a limited range of choices, and more.
One immediate response is to suggest that, instead of blaming the tools, one should blame the requirements imposed on clinicians by payers and governments–the “thousands of meaningless regulatory words” as Gur-Arie writes eloquently. But the real answer is that these requirements (well, the ones that were thought through) enhance the health care system, and that the problem with current EHRs is that they just “pass through” the requirements, intensifying the burden placed on doctors, instead of finding true innovations when implementing those requirements.
For instance, Gur-Arie complains about “alerts about generic substitutes for brand name medications.” Those are in the EHR because, of course, most payers require generics wherever possible and many doctors are lazily prescribing unnecessarily expensive medicines simply because they’re familiar. We won’t get into complex issues here of the incremental benefits of brand name medications, and the reasons why it may be intelligent for doctors to prescribe them when generics are available. Our point is that health care practices will get slammed if they mistakenly prescribe an expensive brand name drug, and the EHR should be able to help them avoid that simple mistake.
Other bugbears have a rational basis too, albeit with caveats. Reports to PQRS provide data that can potentially turn into critical guidelines for better treatment and avoiding negative effects. If the industry hasn’t seen any improvements yet, it’s because the analytics and research leading to the improvements are complicated and haven’t fallen into place yet. We’re techno-optimistic enough to think they will.
Everybody has heard about the chain of blame for the current situation, where doctors are wasting up to 20% of their time on typing into their computers when they’re with a patient. Whereas other industries use technology to reduce such routine tasks, the rigidity of current EHRs increase the burden. And two culprits behind this have been identified:
- Vendors don’t incorporate clinicians into their design process. EHRs are essentially displays of raw data, not tools for productivity. The various bells and whistles mentioned by Gur-Arie are layered mechanically on top, with little regard to clinicians’ workflows. Proprietary data storage and lack of concern for data exchange hamper the production of new tools that can improve the interfaces.
- Buyers high up in corporate settings don’t realize or care about the increased burden of routine data entry when purchasing EHRs. No one is advocating for the user.
- Gur-Arie contrasts this control over physicians with other interventions of technology that deal with all the complexity of the real world instead of restricting it: Google maps, writing software. It’s true that when you write a sonnet, you don’t pull up a sonnet template that makes sure that lines conform to iambic pentameter and rhyme like Petrarch or Shakespeare. (But such a template probably exists.) Why? The discipline of the sonnet is an intrinsic part of the poetic enterprise that integrates with your ear for alliteration and allusion, your approach to metonymy, and whatever other considerations you use to write.
But no doctor wants to modulate her diagnostic skill with ICD classifications or the public health reporting rules for STDs. Those shouldn’t have to be part of her everyday discipline, the way iambic pentameter came naturally to Shakespeare. There should be tools to help with the external requirements. And the tools can even help with other considerations such as drug interactions, which should be part of the lexicon of any doctor.
Gur-Arie’s solution is to distribute rock-bottom simple EHRs combined with universal adoption of “IBM Watson and the likes,” which use natural language processing and other AI tools to augment the physician’s intelligence. To us, this seems to be moving the complexity from one place to another. We don’t care whether Cerner or IBM warn me about allergic reactions; we just want some help with a treatment decision that involves myriad issues.
If anything, interactive tools should intervene even earlier in the doctor’s thought process than they do now. Currently, the doctor has to make a diagnosis mentally and then pull down a menu to see what the system allows her to enter. Watson allows the doctor to submit a set of symptoms and other relevant information to a search tool that suggests a range of likely diagnoses. The technology still gets in the way. But intelligent technology is appreciated for getting in our way.
When EHRs are designed to expose the institution’s business capabilities and services, instead of raw data, they will support workflows and offload routine tasks as they should. They will also shift their concerns from exchanging large, single-purpose data formats such as the C-CDA to exchanging individual items of data through APIs, as supported by the emerging FHIR standard or Open mHealth’s Shimmer. These ideas are expanded in a talk by Shahid.
We have long supported one implicit requirement of Gur-Arie’s solution: the reduction of the EHR software to a database and API, with support tools being built by competitive third parties on top. This architecture is also implied by the open SMART standard project and specified in the famous JASON report(see page 35). Such a design decision will unleash all the powers of the computer industry, in combination with forward-thinking clinicians. Coding everything with open source software will allow innovations to be freely adapted and recombined to get the best of everybody’s contributions. These changes will free the clinician from the tyranny of current interfaces and allow her to unfold her innate expertise.
We agree with a lot of Gur-Arie’s complaints. We diverge in thinking that the role of computers is not just to get out of the way. They should be intervening in productive ways to help make decisions and avoid errors. Doctors have to deal with too much non-clinical folderol and need the support hour to hour in their work.