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.
Categories: Uncategorized
““This encounter may be recorded for quality assurance purposes…”
___
NFL version: “The ruling on the exam table is ‘spondylosis with myelopathy.’ The prior encounter is under further review.”
Yes, the technology is here to implement Bentham’s vision (pun intended) in ways he couldn’t have dreamed of… 🙂
Interesting article at The Atlantic:
The Unregulated Rise of the Medical Scribe
Demand for note-keepers in doctors’ offices is booming, but standards and training haven’t caught up.
http://www.theatlantic.com/health/archive/2015/12/why-so-many-doctors-are-hiring-scribes/419838/
__
My comment there:
I call chart coding “lossy compression.” And, in a way, any type of charting documentation is that, whether it’s digital “structured data” or handwritten physician narrative impressions in a paper chart. The only way to get at the full contextual clinical encounter would be to videotape it (and then transcribe it — which would essentially be equivalent to a “deposition” in the legal field). Given that the cost of digital A/V storage capacity is now effectively nil (how many banal YouTube cat vids are out there?), it’s technologically possible.
Yes, there would be privacy obstacles to that — going beyond mere HIPAA.
Maybe we could try it via explicit patient “informed consent opt-in” permission, so we could assess the reliability of scribe charting.
“This encounter may be recorded for quality assurance purposes…”
Quoted this on my blog.
From “House of God” (2025 version):
“Show me a Watson that only triples my work, and I’ll kiss your feet.”
(with apologies to Dr. Samuel Shem!)
Yes, yes. HiTech INDUCED premature adoption…..and with the subsidies and incentives got the administrators to buy EHR products with indifference to their impact or perhaps blind faith that they would reduce medical errors, reduce cost and enhance collaboration….after all the ‘thought leaders” were extolling the benefits and promise…..
Andy, my first ever blog post was published over 6 years ago, here at THCB in March 2009 (thank you Matt & John), and it was basically a plea to listen to practicing docs. I was so very optimistic about health IT back then, but I had a bunch of concerns and questions. It makes an interesting, and for me painful, read today:
https://thehealthcareblog.com/blog/2009/03/17/for-whom-the-hitech-bill-tolls/
Unfortunately, 6 years later, all my questions have been answered. This is why my original optimism turned into unbridled bitter cynicism.
” When Watson learns how to put in a chest tube during a trauma code, let me know.”
Yeah, and I bet Watson won’t want to do the scut work anymore either! (:
With all due respect, Mr. Oram, doctors do NOT “need a lot of help making the right diagnosis.”
Doctors will occasionally benefit from having access to a vast amount of easily retrievable data in order to help confirm a difficult diagnosis. But the overwhelming number of physician decisions made thousands of times every day all over the world are accurate without the assistance of Watson, or Siri, or Medscape, or Oprah. They are made with the assistance of 4 years of medical school, 3-7 years of residency, and many untold years of clinical experience seeing tens of thousands of patients.
It does not help doctors to turn them into data-entry clerks, creating a 17-page electronic documentation stream that serves only to support billing a suture removal as a level 5 ED visit. I went to doctor school, not typing school. I prefer to see patients, talk to them, examine them, and hopefully make them better.
I can assure you that no one will be happier than I to see the day when the “robot doctor” spits out prescriptions for z-paks to runny nosed kids at a kiosk in the mall. Why? Because it means that I don’t have to do it. Will I get paid a little bit less? sure, but I’m fine with that. I can then treat real injuries, serious illnesses, and difficult cases, which is what I was trained in medical school and residency to do. When Watson learns how to put in a chest tube during a trauma code, let me know.
The practice of medicine should be based on science. In the absence of “scientific proof” that a new medicine or medical device/tool is truly helpful, history has repeatedly demonstrated that it is better for society to assume that the new invention will probably not be useful and society should certainly not mandate that a physician be required to use/adopt an unproven Rx or medical device.
Once there is definitive scientific proof that the new medicine or tool actually “works,” the medical community will voluntarily and eagerly adopt the new medicine or tool as part of their armamentarium.
“What’s happening among skeptics, I believe, is an assumption that the current immature state of technology is an eternal feature of that technology. ”
The reason we believe this is because health IT is not following the normal rules for progressive technology. Using VR as an example, users of VR just kept walking away from the product until someone got it right. Now it works reasonably well. Current health IT is a top down mandate, reinforced by sanctions, mired in bureaucracy and it’s associated special interest influence which is corrupting it’s evolution. There is no such thing as “vendor lock” in other forms of evolutionary technology. So until the entire philosophy of how health IT evolves is completely changed, yes… it certainly may be a near eternal feature of a poorly functioning product reinforced by monopoly power and administrative sloth. This is why your smart phone evolved to be indispensable within a few years, and your EMR looks like a Windows 95 Pac-Man, except much slower, and less relevant to patient care. That is despite millions and millions invested. There is good reason for hopelessness for the near future.
Silos.
Everything in this space – healthcare, and health IT – happens in silos. There’s little (no?) real communication wired up between/among those silos, either, which makes it reallyreally hard to even realize that you’re in a daggone silo.
Regulators, developers, clinicians, health system administrators, payers all have their silos … and the patient silo got built at the nexus of the sewage outflow of all the other silos.
And all because we’re still trying to wrassle a many-headed hydra of a data management issue that’s rooted in PAYMENT, not in OUTCOME.
“What we’ve got here is failure to communicate.” On crank. And on an endless loop …
I’m touched by the thoughtful responses to this article (and Margalit’s) and admit that the commenters have a great deal more experience in health IT than I do. I believe, Margalit, I understand your position as a distinction between routine processing for documents, bills, etc. and the subtle decision-making that should be left to humans. However, I think doctors need a lot of help making the right diagnosis, and that technology can help. See for instance:
http://www.hopkinsmedicine.org/news/media/releases/diagnostic_errors_more_common_costly_and_harmful_than_treatment_mistakes
What’s happening among skeptics, I believe, is an assumption that the current immature state of technology is an eternal feature of that technology. Right up till Apple’s release of Siri, many of us dismissed the idea of effective voice recognition, an unattainable goal for generations of previous AI researchers. I am still a skeptic regarding self-driving cars (has Google tried a self-driving car in Minnesota in February?) but many observers insist we’ll be sitting in them during our lifetimes.
And Hayward, I also suggest that what “doctors think” or “doctors report” should not necessarily be accepted as guidance for policy. Doctors, too, have a dysfunctional status quo to protect. That said, I recognize that many MU requirements had unintended effects. But patients really should be using their electronic records online. The problem with that MU requirement is that providers offered lousy portals that lacked useful information and were hard to use, then complained that patients didn’t use them.
We are not converging on a single viewpoint during this discussion, but we are finding common ground where we can all work together to attack the serious problems with EHRs and health IT that we agree on.
Gentlemen, let me first express my admiration for the hard work you both do in this space, which I have also been following for years, and thank you for your thorough analysis. As to the differences between our positions, they would probably be considered minor by most observers, but I think a couple of points may warrant some consideration.
I want to start with a nit. Perhaps I wasn’t clear in my previous piece, but IBM Watson, in my opinion, should not even try to offer “clinical decision support” of any kind at this time. I suggested that the software should be used behind the scenes exclusively for translating analog to digital. If I am not mistaken, this task alone should require years of additional development.
Although I did not mention that in the original, I think Watson type of software should perhaps go to coding school instead of medical school and take care of the drudgery of billing, authorizations, and all the red tape, which can and should be automated. That’s what computers are for.
As to the notion that doctors are in dire need of help with thinking things through and diagnosing, why don’t we do the most basic thing that any developer should do, and ask doctors if they feel incapable of diagnosing disease? Why don’t we ask them if they need help with figuring out what to do after they diagnose something?
We have never posed these questions to physicians (and I will go out on a limb here and say that I think I know what the answer will be). We did however make a unilateral decision to intervene based on opinions from very interested quarters stating that medicine has become too complex for the human mind (or some other cliche along these lines). To me, the reasons behind this decision are suspect, to say the least. But even if I assume good intentions, the reality remains unchanged – we are in the way. Oh, and a template based sonnet would probably sound & feel like a template based sonnet….
I do admire (and sometimes envy) your ability to believe that future technology will somehow justify what we are doing today, which is burning out physicians in droves and taking time away from direct (and individual) patient care. I don’t share your faith in analytics, population segmentation (profiling?) and the entire notion of having physicians bear risk for what we as a greed-driven society inflict on individuals.
I do however believe that it is possible that one day, far far in the future, if we get our act together, we may reach a time and place where all your optimism will be justified. Lots of things will have to align for that, least of all is pure technology. My preference would be to continue growing technology on a small (voluntary) scale until the day arrives when we need not base our decisions on pointing out to the “potential” it could have, but instead present well researched and well tested facts, as we do in all scientific endeavor.
Bravo. The cure is always “just around the corner” isn’t it?
“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.”
This paragraph demonstrates the thinking which underlies the proponents of health information technology, which is their perennial belief that more health information technology will yield benefits to society. Every step of the way, since EHR were introduced, the mantra has been “once we get over the next health information technology hurdle, the cost quality issue will be solved.” First, it was we need EHRs, but that did not solve the cost quality problem. Then it was we need CCHIT certified EHRs, but that did not solve the cost quality problem. Then it was we need MU1 certified EHRs, but that did not solve the cost quality problem. Then it was we need MU2 certified EHRs, but that did not solve the cost quality problem.
Now it is: we need MU3 certified EHRs and full interoperability… But to date, we have no data to expect that this will solve the cost quality problem.
Unfortunately, as we have seen over and over again in the practice of medicine, ideas/products/devises which seem rational, reasonable, theoretically irrefutable or “is the accepted community standard,” when subject to data analysis, ultimately turn out to be an incorrect conviction/truism/fact which is then left in the dust of the practice of medicine. (Think leeches, HRT, etc)
Health information technology should be subject to the same rigorous standards as any new medicine or technology. The purveyor of the tool should be required to prove its utility before it is foisted on the patient and medical community. Until then, physicians should be allowed to choose to use their best judgement and not be subjected to financial penalties or ridicule simply because that are not using Epic/Cerner/etc.
I am a committed health information technology geek. I wrote a highly rated electronic medical record program (ComChart EMR, no longer for sale) which was certified under Stage I Meaningful Use. I am not a Luddite. I like using HIT but I fully acknowledge that, in the real world, health information technology has yet to prove that it will reduce the cost of healthcare or improve the quality of healthcare.
Electronic accounting programs, like Quicken, make it easier for a medical practice to maintain their accounting. So many practices choose to use an electronic accounting system in their office. However, the fact that a medical practice has a computerized accounting does mean the cost of maintaining the US bank system will be reduced nor is the quality banking system enhanced. So there can be a utility to the individual practice of using advance computer technology, even though there is little demonstrated benefit to society as a whole. Thus I would encourage others to use HIT but I would not force them to use HIT.
Electronic health records can help physicians run a more efficient practice, and I would not practice without one, but we should not tell physicians that they must use electronic health record, or worse, specify what type of electronic health record they must use, and which buttons they must click, until such time as we have proven, definitively, that electronic health records reduce the cost of healthcare or improve the quality of healthcare.
Please see my posting on THCB “25 Reasons It Is Time to Kill Meaningful Use.”
https://thehealthcareblog.com/blog/2015/11/22/it-is-time-to-kill-meaningful-use-a-25-point-manifesto/
“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.”
__
The other day I interviewed Allscripts’ Stanley Crane for my blog (post not up yet). He said that they’re doing precisely that kind of thing, that they view their EHRs as “the operating system” atop which 3rd party developers, within their “Open API” program can add broad and deep value ot extend functionality and “interoperability.” He said that they recognize that “MOST of the smartest people in Health IT don’t work for Allscripts.”
We’ll see.