The Health IT report is very good; some opinionated suggestions

“Oy,” I thought, when I received a copy of “REPORT TO THE PRESIDENT REALIZING THE FULL POTENTIAL OF HEALTH INFORMATION TECHNOLOGY TO IMPROVE HEALTHCARE FOR AMERICANS: THE PATH FORWARD” [PDF]. I worried this would be a lot of vague, easy-to-agree-with advice with little actionable material. I was wrong. Hats off to the team that wrote this!

Problem Analysis is right on

Some nuggets of the problem analysis, all from the executive summary (a quick and useful read):

First, most current health IT systems are proprietary applications that are not easily adopted into the workflow of a clinician’s day, and whose proprietary data formats are not directly exchangeable from one system to another.

Yes! Proprietary systems and data formats are the number one problem, as I’ve complained about before.

Second, most healthcare organizations that utilize electronic health records (EHRs) view them as purely internal resources, and have little incentive for investment in secondary or external uses, such as making them accessible in appropriate form to patients, to a patient’s healthcare providers at other organizations, and in de­identified or aggregated form to public health agencies and researchers.

Yes! I’ve heard someone phrase this as “there’s no billing code for sharing data with a patient or another hospital.”

Third, legitimate patient concerns about privacy and security make patients uneasy about participating in health IT systems or granting consent for their information to be used in research. Fourth, health IT has historically been oriented toward administrative functions, not better care. This is in part because, under the current fee­-for­-service payment model, the economic benefits of investing in health IT can rarely be realized by the provider or organization that makes the investment.

OK, so the privacy-and-security point is a little bit vague, but the point about administrative functions vs. care is right on. Overall, this is one of the clearest explanation of the problems with Health IT today that I’ve seen.

Patient Involvement: too timid

2. […] achievement of the President’s goals requires significantly accelerated progress toward the robust exchange of health information.

Effectively, the meaningful use rules are too modest in their interoperability demands. I agree. That said, the report doesn’t sufficiently emphasize the role patients could play. They certainly talk about giving patients their data, but not about how giving patients their data is the natural path to secure health-data exchange between providers. No one can argue that the patient doesn’t have the right to see their own data, and if the patient is the messenger, then consent is inherently part of the mix. Instead, for some reason, Health IT folks are obsessed with solving every problem on the backend, fuzzy matching master patient indexes, etc. I continue to believe that the patient (as in, you, me, every user of the healthcare system) is far better positioned to manage their health data than anyone else. Giving patients their data is not just an end-goal, it’s a means to accomplishing other health data exchanges.

So when the report says:

The best way to give clinicians a unified, patient­-centric record tailored for each medical encounter is to store, maintain, update, and exchange the data as small, distributed, metadata-­tagged elements.

I disagree. The solution isn’t a specific technology used in expressing the data, it’s about how/where the data flows. The best way to give clinicians a unified patient-centric record is to give patients all of their data and the means to share it easily with the doctors of their choice.

Data Exchange and Interoperability: needs more work

The report then spends a good bit of time talking about a universal exchange language, and an infrastructure for locating and assembling […] a patient’s record. These are interesting points, but the devil is in the details.

On the universal exchange language: it’s a lot harder than it sounds. The report does mention extensibility as a key feature to allow for private industry to build on top of this universal language, and that’s a very good thing. The report also briefly says the language must be “open.” That’s very, very good, assuming we have the same definition of open: anyone can use it and redistribute it, without asking for permission from anyone.

The problem is that existing standards organizations in health IT believe existing solutions to be “extensible” and “open.” SNOMED is open! RxNorm is open! HL7 is open! CCR is open! No, they’re not. Most are free of cost, but they’re not free of obstacles: you still need to sign up to get a “free license,” which means any organization must check that every other organization it deals with has signed those many “free licenses” to those vocabularies before data can flow. We need truly free medical vocabularies and formats, and we don’t have them yet. I wish the report emphasized this need more, since only the Federal government can make this happen.

And then there’s the “extensible” issue. This is, in my opinion, the worst part of the report:

We believe that the natural syntax for such a universal exchange language will be some kind of exten­sible markup language (an XML variant, for example) capable of exchanging data from an unspecified number of (not necessarily harmonized) semantic realms.

The emphasis is mine. Not necessarily harmonized? Then what is the point? We already have dozens of syntaxes for expressing medical data, and they all punt on semantic interoperability. That is insanity. We need semantic interoperability in this universal exchange language, lest we once again define the envelope without ever standardizing what goes inside the envelope. This is, sadly, how most health IT standards have defined interoperability: you can put anything in the envelope, so it’s extensible, right? No. Think about the implementer: where do they start on parsing that completely unspecified payload?

Let’s make this universal exchange language truly open and truly extensible. For best practices on openness, we can look to Open Source and Creative Commons for advice. For best practices on interoperability/extensibility, we can look to the World Wide Web Consortium‘s standards on Linked Open Data and RDF. These problems have been solved before, let’s not recreate half-baked solutions for health IT. And in the name of all that is holy, enough with the payload-agnostic interoperability standards. Payload agnosticism is anti-interoperable.

Privacy and Security: some good, some bad

The report recommends data provenance and privacy preferences tied to the data. That is a very good idea. It’s hard to do in practice, though, so if we go down this path, let’s really invest the time and money needed to figure out how to do provenance and privacy-preferences right. This is a big endeavor.

The report also recommends giving patients more control over the flow of their data. This is great, but it’s almost impossible for the average patient to understand what the various flows mean and how they’re used. This is yet another reason for giving patients their data so they can choose who gets to see it directly, rather than having to make decisions about transitive trust: do you allow doctor A, who spoke to doctor B yesterday, to speak to doctor C? Good luck with that.

Then the report goes into far too much detail about security and cryptography. It talks about keys, and digital signatures, and shared keys, and never storing the key on the same machine as the encrypted data (really? It’s only going to come together in RAM? How’s that going to work for gigabytes of MRI data?) There’s even discussion of how Data Entity Access Services can run authorization checks before delivering the encryption keys, and other descriptions of crypto protocol details. This is bad. It’s overly prescriptive and thus cannot take into account recent innovation, such as secure access delegation via attribute-based encryption. Instead, the report should have focused on general principles and requirements, such as:

• data should be secure even if someone eavesdrop on the network
• data should be secure even if someone obtains the hard drives from a decommissioned server
• authorized physicians, as certified by the AMA, should have access to any record via a break-the-glass approach, as long as there is an audit trail

Focus on requirements, and don’t mandate specific crypto concepts, as if all crypto innovation had stopped in the 80s. Let the technologists find/discover/invent the specific solution that meets the requirements.

Conclusions

I’m harsh on a few pieces of this report because, overall, I think it’s quite good. (And I thought this even before I realized, just now, that my colleague Ken Mandl was on the advisory committee for this report.) There are a few points that need more emphasis, however:

1. the government should NOT be building a concrete infrastructure for health data exchange. We don’t know the best way to exchange data nationwide, and we shouldn’t have a central, expensive top-down effort to achieve this. The market can figure this out… with some help (see next points.)
2. the government can and should define a truly interoperable syntax and semantics for medical record exchange. This may involve one-time purchases of proprietary coding systems, but at the end of the day, the output should be a truly free set of codes for all major medical concepts, an abstract model for representing them, and one default syntax for serializing this data.
3. the government should mandate that any healthcare provider make available, to any patient that wants it, all of their data in digital form using the universal syntax and semantics just mentioned, using a standard, open protocol. This should include transfer of said data to any Personal Health Record provider that complies with proper privacy protections and with the standard protocols, data format, and data semantics. No more one-off deals between one hospital and one PHR.
4. the government should mandate that any healthcare provider be capable of receiving, from a compliant PHR, a patient’s record, using the standard protocol, data format, and data semantics.
5. the government should sponsor Personal Health Records for all medicare/medicaid patients, say $5/month. Providers of these PHRs should fit conformance criteria for data portability and exchange, but otherwise should provide a relatively complete PHR service that the government can subsidize. The choice of the specific PHR should remain the patient’s, not any large hospital’s or other organization’s. We need market forces at work improving the PHR space, but we can use medicare to kickstart this market.

The standard protocol for exchanging data between two endpoints could be NHIN Direct / the Direct Project, assuming they continue to simplify their approach.

There is an opportunity for the government to significantly improve health IT, mostly by greasing the wheels of data exchange and interoperability. There are some tough decisions to make, however. We cannot punt on the medical data payload and semantics. And we must involve the patient at the crux of the architecture. Once the government has established fertile ground for innovation, by standardizing the data exchanges, privacy standards, and otherwise removing silly licensing obstacles, the market can do what it does best: find the set of optimal solutions within those principled constraints.