EHR Event of the Month: "Yes - It's a Problem"
- Michael Victoroff, M.D., Editor-in-Chief
This isn't really an 'event,' just more of a problem. Our EHR generates notes after you check little boxes on millions of pages of menus. The boxes are tiny and menus are incredibly detailed, so it takes forever to find what you want, and easy to miss something, or check something wrong. Then, the finished note is incredibly boring and fake, just line after line of mostly normal findings. I can't find the 'meat' in my partners' notes. My eyes actually blur. I tell myself to read every word, but all notes are 95% identical. I've missed important things...I think this system produces [pejorative]...You can't tell what actually happened at the visit, because all the notes look the same...
This reporter insightfully raises what I think may be the greatest concern we should have about many EHRs. S/he apologized for not being able to point to an injury resulting from notes generated by "click-tation" (my term). I think the hazard is real, though subtle.
"Computer-assisted documentation" technologies include pick-lists, auto-fill, paste-forward, templates, canned text and other methods to bypass natural language. These arose because, 30 years ago, data was constrained by processor power. Free text had two drawbacks: It consumed a lot of storage and it was hard to perform calculations upon. To analyze data, it had to be in structured fields. So, providers were forced to use baby-talk so computers could understand them. Complex ideas were crammed into weak nosologies like ICD9 that have no terms for many critical concepts like "maybe." Observations that couldn't be formatted in 30 characters were just discarded.
The price of encoding is sacrifice of detail. And, this legacy persists. Ironically, as EHRs have finally made records legible in many facilities, they have sometimes reduced their usefulness. It's painful to contemplate the information irretrievably lost in years of cryptic, structured records. Even today, with magnitudes more processing power, many designers still eschew natural language in favor of nicely-computable records that humans find difficult both to generate and interpret – and which may not faithfully describe patient encounters.
The chief purpose of medical records should be to help the next provider in line. But, I often hear from EHR-users, "I don’t bother reading machine-generated progress notes." Reasons given are that they're formulaic, uninformative and untrustworthy.
To be sure, a certain cohort of practitioners generates better notes thanks to EHRs. But, another cohort has seen its data enfeebled. And, this trend has not peaked. Structured documents dominate the EHR market. Long after being replaced by richer formats, they will leave a gap in the population record that will never be filled. Meanwhile, we may have to cope with a generation of users who don't bother reading notes. How does this help?
To report a suspected EHR Safety Event, visit www.EHRevent.org.
The IOM Report on HIT & Patient Safety - Part 2
Last month we announced the release of the Institute of Medicine's report, Health IT and Patient Safety: Building Safer Systems for Better Care (http://iom.edu/Reports/2011/Health-IT-and-Patient-Safety-Building-Safer-Systems-for-Better-Care.aspx).
Most germane to our mission at http://www.EHRevent.org is the report's recommendation to create an agency modeled on the NTSB, whose primary function would be to investigate (but not adjudicate) instances of harm and safety events related to HIT. We'll have to see where this goes.
A major problem the Committee struggled with, was whether the FDA's current framework for device regulation appropriately addresses software products. The majority felt that software represents a novel class of items warranting a new set of regulatory concepts. One member dissented, arguing that HIT is properly dealt with in rules for Class III Devices.
I side with the majority. The FDA regulates drugs and devices. Nobody thinks software is a drug. But, calling it a "medical device" is only an analogy, or maybe a metaphor. (In a poetic twist, software is writing, and likening it to a device is a figure of speech, which, in dizzying spirality, makes it a "literary device.") However, there is real danger grouping together real world objects whose commonality is mainly semantic.
The word "software" itself is a linguistic construct synthesized from a play on "hardware." But, analogies have limits. For example, people, birds and wine all have "legs." But, what looks like a knee in a stork is analogous to the human ankle, and wine doesn’t have joints at all (although there are beer joints, but you see where this is leading). You can't regulate your seat cushion as a "watercraft" just because it can be used as a "floatation device." The hazard of calling software a device is not only being distracted by a quibble, but being led astray by illogic.
Seriously regulating HIT presents theoretical and pragmatic questions. Does the FDA schema for device regulation work for software? Would categorizing software in Class III be constructive for vendors and users? My short answers are "No" and "No."
Best practices (from NIST, ANSI, AAMI, ISO, and others) do exist for software design, usability, security, etc. But, there is no generally accepted template for safe use. This seems to be what the IOM majority is advocating to be developed. To the FDA, a medical device is "an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including a component part, or accessory [used in medicine]." Class III devices include pacemakers, pulse generators, HIV tests, automated external defibrillators, endosseous implants, heart valves, silicone breast implants and implanted cerebella stimulators. This definition just doesn't fit most medical software.
Second, in practical terms, the development and cycle for software is fast compared to hardware. If the FDA took a year or two to approve a computer program, the software could have undergone several bug fixes and upgrades during the interval. Withholding the product to test every new version would essentially amount to a perpetual embargo. This isn't to argue there should be no oversight of medical software – I agree with the IOM that we are in grave jeopardy without it.
But, software spans a range of functions from those obvious to users (like spell checkers) to programs that are black boxes, with workings invisible to, and non-verifiable by users. These and other reasons justify putting software in a special class, rather than relegating it to a category of convenience.
On behalf of all at EHRevent and PDR Secure, thank you for reading and please enjoy a safe and happy holiday season.