Electronic Health Records Considered Harmful
Reading An American Sickness, a blood-boiling portrait of the American healthcare system by former doctor and NYT reporter Elisabeth Rosenthal, has led me to reflect on my own small role in this tragedy, back when I was a junior software engineer working at an EHR company. Rosenthal only briefly touches on the role of medical software in rising costs, but where she does her analysis fits with my experience.
For background, most hospitals and doctor's offices will use a single, monolithic piece of software called an Electronic Health Records system or EHR for all of their day-to-day needs, e.g. scheduling appointments, charting patients' visits, prescribing medications, ordering lab tests, and often billing. Insofar as other "endpoint" medical software exists, e.g. imaging software on an MRI machine, it generally feeds directly into the EHR system. Thus EHR systems largely determine the medical software landscape.
Rosenthal cites two ways in which EHRs contribute to rising prices:
- Barriers to competition: EHRs are not compatible with each other, and endpoint medical software tends to be compatible with a specific EHR. Thus patients are forced to use the same, high-priced hospital labs, radiologists and specialists for all of their care.
- Costly defaults: Doctors will almost never choose any but the default option for drugs, lab orders, imaging or specialist referrals. Hospitals know this, and configure their EHRs to default to high-priced in-hospital options. Some EHRs, such as PracticeFusion, make commissions off of orders and prescriptions made through their systems, and set defaults accordingly.
An understated yet critical factor is that EHRs are horrible. Incredibly hard to use and chock full of bugs, there's a good chance that the data one doctor puts in won't be anything like what the next one pulls up. This results in ubiquitous inefficiency and the occasional deadly mistake. But how did it come to this?
As Rosenthal notes, EHR adoption was very fast and is at nearly 100% now due largely to a government program called Meaningful Use, which offered huge tax breaks to doctors who used a "Meaningful Use certified" EHR system. This incentive was so large that no uncertified software could possibly compete in the market, so ever EHR vendor raced to get certified.
However well-intentioned, it delivered a 1-2 punch to medical software as a whole. On one front, it required EHR software to implement a long list of underspecified requirements, such as:
(14) Patient list creation. Enable a user to electronically and dynamically select, sort, access, and create patient lists by: date and time; and based on each one and at least one combination of the following data: (i) Problems; (ii) Medications; (iii) Medication allergies; (iv) Demographics; (v) Laboratory tests and values/results; and (vi) Ambulatory setting only. Patient communication preferences.
It is unclear what any of this means. What exactly does it mean to sort a list of patients by "problems"? Sort by the number of problems? That doesn't seem very useful. Sort by the name of the kind of problem, alphabetically? What if they have multiple problems? Sort by serverity? How do you rank the severity of the problems then? And so on for every item in this list. As a result EHR vendors had no idea what to implement, and so implemented the easiest thing that sort of looked like the requirements. Even if the sorting did not work as the engineers intended, the certifiers had no grounds to object since they had no specifications as to how it should work.
As one of my then colleagues put it:
It was like the Health Department requiring every restaurant to serve each of 1000 dishes, where item 697 was 'Hamburger: has ketchup', and you could serve a brick with ketchup to the inspector and get a pass.
And serve a brick with ketchup they all did; it was the only practical way to meet all of the requirements on time.
On the other front, Meaningful Use has us stuck with the first EHRs to meet its underspecified requirements. Since EHRs are so vast and incompatible, almost no doctor is ever willing to switch EHRs. Thus any new EHR must break into the market by targeting doctors still using paper and pen. Yet Meaningful Use artificially drove almost every doctor to adopt an EHR, so there are almost no doctors for a new EHR to target.
Furthermore, "meaningful" is not at all how I would describe the use of EHRs in American medicine. A shocking amount of the time, EHRs are treated as just one more sink into which data must be manually entered (never to see the light of day again), or as one more source of mutually conflicting data about a patient to find, shake your head at and ignore. What's worse, this may be the correct approach to dealing with current EHRs.
Rosenthal is right that it is practically impossible to transfer data between EHRs, or to use endpoint equipment not specifically built for that EHR, reducing competition and causing wasteful duplication of tests and examinations. Lack of interoperability is nothing new in the software world, but EHRs have definitely refined the art. The most obvious cause is the woeful inadequacy of HL7, the "standard" data format implemented by most healthcare software. It has a host of flaws, but the largest is that it offers far too much flexibility, and as a result all implementations emit very different HL7 for the same data, while only accepting a very limited and arbitrary subset of HL7.
There is some hope in this area: the FHIR draft standard has been gaining traction and has some early implementations. It rectifies the most serious flaws in HL7 by building on more modern data formats (namely JSON and XML) and thereby making it harder to write an overspecialized parser.
But there are two less obvious yet equally crippling limitations to interoperability: network access and authentication. Even if systems can parse each other's data, how are they supposed to locate that data, and how are they supposed to be granted authorization for it? Most systems are made "accessible" over some sort of network, but in bizarre and limited ways:
- on a local intranet,
- behind an aggressive firewall,
- using archaic network protocols—FTP if you're lucky,
- or over HTTPS, but only through a web GUI that only works in IE, and with a certificate of dubious progeny.
Should you actually get network access to a system, how are you supposed to obtain authorization to send or receive data for a patient? Outside of systems installed by the same vendor—which of course are granted full access to each other—the "standard" solution is to implement patient accounts and an OAuth or (shudder) SAML system by which patients can provide authorization to other systems. But even when these are implemented correctly (a rare occurrence), it is rarely clear how to contact the patients with an authorization request, and the patients rarely know that these accounts have been made for them and thus have no idea what to do when they receive a request.
These failures are probably a result of the strong incentives that local monopolies have against interoperability. But it is unclear how to counteract these incentives without first fixing the problem of local monopolies. Normally government regulation could intervene, but regulation has lagged too far behind technology and cannot currently address these issues; the attempts within Meaningful Use to do so were useless at best.
If I had to propose a solution, I would steer clear of having the government regulate EHR software directly and instead have them attempt to force interoperability, so that an actually decent EHR would stand a chance in the market. I would ask them to play the role of data broker. Suppose the government ran a service that all EHRs had to register with, where a patient could log in, view the data each EHR had on them in a standardized format, and check a box for each EHR they wanted to have access to that data.
This system would not have to be good, so long as it was usable. Of course I would expect EHRs to only send partial data to it, and do so unreliably, so it would be important that the agency managing it respond to patient complaints with swift and hefty fines.
There are some obvious criticisms of this plan:
- How do patients authenticate with the system?
- Why trust the government with this data?
- Can we really expect such a government-run system to work?
- Even with data portability, would doctors go through the effort to use a different EHR?
Authentication remains a difficult problem, although at least under this system it only needs to be solved once. For authenticating patients, the system could use the same standards the IRS uses for tax filings. These are not perfect, but if someone can access and manipulate your tax filings, that's usually worse than accessing your medical records. Authenticating EHRs could be fairly simple using existing technologies, for example by having the EHRs use client certificates when sending data to and retrieving data from the system. A more complex authentication system like OAuth would allow EHRs to integrate with the system without waiting for the system to approve them and load their client certificates—instead relying on entirely the patient's confirmation through the OAuth flow—but it is unclear to me that this is worth the extra complexity for both the system and EHRs, or even desirable.
In a more perfect world we shouldn't trust the government with our medical records, but the healthcare data privacy ship has set sail, circumnavigated the globe, caught fire and sunk. By and large the government already has our medical records, whether through Medicare, Medicaid or Meaningful Use audits. So do EHR systems, whose security is a bad joke among infosec professionals—in fact, this is how I became interested in infosec, which is my current field. Doctor's offices and hospitals are even worse: all you have to do is fax them a request for information with a patient's name and date of birth—which can even be wrong—and they will fax medical records back!
While the US Government has had some high-profile tech screw-ups (cough healthcare.gov cough), under the Obama administration it built some good teams at the US Digital Services and especially 18F, which have helped many government agencies run their tech competently. These people also know how to keep data encrypted at rest and in transit, which is better security than the status quo.
At the end of the day, I don't know whether doctors would use this system. Doctors by and large claim to hate current EHRs, and that they want better. But their stated preferences and their revealed preferences are different things, and I've usually been disappointed. If nothing else, this system could at least allow savvy patients with serious conditions to own their data and be their own doctors, which increasingly seems like their only option.
Until recently, that is—PracticeFusion has gone out of business. Good riddance.