If you’re interested in this stuff, you might want to read the blog post I wrote on the SMART site about how SMART addresses the Presidential Report on Health IT. Key ideas:

1. PCAST very eloquently identifies lack of interoperability as the central problem of healthcare IT. To spark innovation, PCAST proposes a universal exchange language, with atomic data elements and a strong metadata philosophy for privacy and provenance. We wholeheartedly agree.
2. One of PCAST’s suggestions is to eschew efforts to define universal semantics, leaving to the market the task of semantic harmonization. While we agree that the market will significantly contribute to semantic harmonization, our experience indicates that an organized initial foray into standardizing semantics for common, well-understood health data is critical to getting the ball rolling.
3. With SMART, we are building such a universal health language — inspired by existing standards and built on existing coding systems — and empowering with it a modern, web-based application ecosystem. We specifically address PCAST recommendations of data atomicity, metadata tagging, and semantic extensibility, while simultaneously addressing what some have identified as weaknesses in the PCAST report, notably the risk of incomplete patient context when working with disaggregated atoms of data.

More details over at the SMART blog.

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.

So, HL7 is unlocking the power of health information, and to do that they’re going to sell you a standard.

Meanwhile, the National Library of Medicine has toiled for years on the Unified Medical Language System (UMLS), which attempts to codify *everything* in medicine, from anatomy to viruses. It’s a pretty impressive piece of work. Conveniently, they provide a “meta-thesaurus” that maps other coding systems, like SNOMED, to UMLS. Brilliant! Awesome! Except… to use UMLS, you have to register. And you have to fill out a yearly survey. And you’re not allowed to redistribute the UMLS codes. Oh, and you have to sign a 10-page licensing agreement that explains how you can use UMLS, but you can only use SNOMED under these conditions, and this other coding system you can only use in these other conditions, and if you don’t have three lawyers and a few weeks on your hands, good luck answering this simple question: “can I use this in my open-source library and release it freely to the world?”

Imagine, for a second, if we had a similar situation without computers. Doctors would have to pay a fee to speak official medical terms when discussing your health. You would have to pay a fee to have those terms translated into plain English. Canon would have to pay a licensing fee before making fax machines able to send medical documents from one doctor to another. In short, every time a health transaction occurs using standardized language, there would be a tax.

This is insane. Folks in the health IT world are focused on much harder problems while ignoring this blatant ball-and-chain on innovation.

I submit that the quickest path to health-IT reform is the complete and unconditional freeing of these medical vocabularies and data formats. And I mean complete. No access fees, no yearly surveys, no constraint on redistribution, country of origin, commercial or non-commercial. Free. like HTTP and HTML. Like English. Like a patient-doctor conversation.

Take a precise example: my group at Children’s Hospital Boston just released Indivo X, the latest version of our Personally Controlled Health Record. It’s great, but there’s one key feature we had to strip out before shipping this free, open-source tool built using federal grant money: SNOMED codes. Sure, we’re a hospital with a license, we can use them internally. But we can’t redistribute them. So now, to install Indivo, instead of a 30-minute process, you need to go get a UMLS ID, wait 3 days for approval, then download the files, extract the codes we think are useful, and load them into the database. No exaggeration, you’ve now multiplied your time-to-working-install by 100.

This must change. Either the existing formats must be opened up, or new formats must emerge that do to the existing formats what HTTP and HTML did to Gopher: kill them with freedom. Taxing human interactions, simply because they’ve been digitized, is an unacceptable brake on innovation, and in a complex field like Health IT, it’s the last thing we need and the first thing we need to eliminate.

I’m a scientist and engineer, but I’m not a medical doctor. Back in 2004, when Robert Kennedy Jr. published his anti-vaccine piece in Salon/Rolling Stone, I worried that there was something to his claims. I asked around. I’m lucky enough to work with some of the world’s top pediatricians, and to be married to a fantastic doctor and geneticist, so I had plenty of expert resources to turn to who set me straight. Not everyone has access to that level of expertise, which is why it is so morally reprehensible for those like Robert Kennedy Jr., Jenny McCarthy, and other know-nothings to be falsely leading those who have no one to set them straight.

And that’s why Ms. Wallace’s article is so crucial. It lays out, in plain English, exactly why vaccination is so important, and exactly how the anti-vaccination movement has shifted its story every time scientific evidence made their claims just too darn difficult to stand by.

Don’t have time to read that great article? Here’s the one fact you need to know: the anti-vaccination crowd kept harping on thimerosal, a vaccine preservative, as the culprit, claiming it was causing autism. Except, in 2001, thimerosal was removed from all childhood vaccines, and autism rates kept going up unchanged. That’s when the anti-vaccination movement changed its tune to “too many too soon”, and to the insane claim that vaccines contain anti-freeze (which would be true only if “ethyl” and “methyl” were the same chemical prefixes, sucks to be precise.)

Also, if you are a scientist, even if you aren’t a medical scientist, take the time to educate yourself briefly on the risks of the diseases we’re talking about, on the failure rates of vaccines, and on the multitude of studies that have shown no statistical link between vaccines and diseases like autism. It doesn’t take an MD or a PhD to figure it out. We need rational thought. Speak out. Don’t let irrational thinking flourish. Defend science, defend rational thinking, you’re not a Big Pharma shill just because you think vaccines are a good thing.

Read Amy Wallace’s article, and follow her on Twitter. She could be the breakthrough voice in this fight for rational thinking in public health.

Before other deCODEme customers get too irate about errors in data for which they have paid almost $1000, the bug affects only a tiny portion of the results presented. Most importantly, the disease-risk summaries provided by deCODEme seem to be based on the correct genetic information.

“seem to be” is the operative terminology, indeed. As is typical in security / quality-control settings, the question here is, if the software can make such a large mistake, what about all the smaller mistakes it’s making that aren’t so obviously detectable?

Seems to me that before we start trusting these genomic tests for clinical purposes, we’ll want to make sure our genomes are read multiple times, ideally using different technologies. 99.99% accuracy sounds great until you realize you’re dealing with millions of data points, each one of which could be significant.

(And I’m not even touching on whether genomic data is sufficiently predictive, given current knowledge, to be clinically relevant, which as Zak Kohane points out in the article, isn’t a given.)

I want my blog to be used for education, training, and research. I hope that its contents appear in derivative works such as other blogs, websites, and wikis. I’d prefer that these derivative works be openly shared.

I would also ask that any material that is repurposed has attribution to me as the author.

Content from my blog should not be sold. Charging for access to that which I make freely available seems wrong.

How do I express these preferences legally?

Exactly! Now, if only health IT interchange specifications followed the same path. For example, HITSP, which aims to “enable healthcare interoperability”, has the following copyright statement:

No portion of the ANSI Sites may be reproduced in any form, electronic or otherwise, for any purpose other than personal use, without prior written permission of ANSI. To the extent that ANSI is not the copyright owner of some portion of an ANSI Site, ANSI has received permission to include such material in such ANSI Site.

The individual specifications might be a bit more lenient, but it’s not clear because they refer to other specifications’ individual copyright licensing terms, so you have to follow your nose to every sub-specification and figure out how to reconcile the terms from these disparate sources. Yeah.

Meanwhile, you have to pay to even see the Continuity of Care Record (CCR) standard. And HL7 licensing handwaves about how “strict copyright” is the only way they can maintain the integrity of their standard (untrue and likely ineffective), with a relatively amusing comparison of their per-download fee to “Apache and Linux distributions”, even though of course you can download Linux and Apache at no cost whatsoever, and you can redistribute them if you wish.

Just this week, there’s a new effort to give individuals control over their health data. I think it’s a great effort, but one of the necessary conditions to get there is to have truly open Health IT standards. No usage fees, no download fees, open licensing that enables others to innovate on top of the standards for novel medical applications, and probably a trademark approach to encouraging interoperability (i.e. you can’t call it “HL7″ unless you pass the HL7 test suite). There will not be widespread patient-controlled flow of health data until there are truly open Health IT standards.

John, if you’re listening, let’s bring that Creative Commons attitude to the Health Standards groups ASAP!

So, for example, if you think your system fits the bill because anyone can write a Java module/extension, you’ve got it wrong. Loose coupling means you’re not forcing one programming language on everyone else, rather you’re embracing the open protocols of the Web.

The work we’re doing with Indivo X, our open-source/free Personally Controlled Health Record, is exactly along those lines. But it’s not just about PCHRs. Really, the entire Health IT ecosystem needs to adapt to the loosely coupled way.

Harvard’s own Donald Berwick explains to the New York Times that it’s time to empower patients (see the original Health Affairs article):

Some examples of this new model of care? Shared decision-making would be mandatory in all areas of care, with patient preference occasionally putting evidence-based care “in the back seat.” Patients and families would participate in the design of health care processes and services and would be a part of daily rounds. Medical records would belong not to clinicians but to patients, who would no longer have to get permission to look at them or call the doctor for lab results.

Read the full interview, it’s brief and highly worthwhile. I completely agree with Dr. Berwick.

Meanwhile, in New Jersey, a proposed state law wants to fine anyone who sells software that has anything to do with health data if it hasn’t been certified by CCHIT. CCHIT is a single entity that would get to certify all health software. CCHIT is also pushing to be the lone certification authority for all stimulus-funded work. So, as if health IT wasn’t already painful enough to deal with, now we’re going to move towards a certification monopoly? Say goodbye to:

• iPhone apps that let you track your kids’s vaccines for $4, and really most small iPhone medical apps in general, as they clearly won’t be able to afford the certification fee,
• storing your health data online at Google Health, Microsoft HealthVault, or Indivo/Dossia.
• open-source medical software. As hard as Fred Totter is working to get CCHIT to see the free/open-source point of view, there’s simply no incentive for a certification authority to spend time on a distributed community where it’s unclear who will pay the certification fee.

No matter how well-intentioned and knowledgeable the folks at CCHIT are, creating a certification monopoly shows a lack of understanding of how these things really work. Once the monopoly is in place, where is the motivation for CCHIT to be efficient, responsive to new healthcare models, adaptable to new software methodologies? In addition, what is the certification really worth when the vendors are paying for it anyways? We’ve seen this conflict before in the election world: the “Independent Testing Authorities” are paid by vendors to certify voting machines. At least there, there’s mild competition. How much do you think that certification really means in terms of voting security/privacy/safety? Here’s a hint: all the voting machines that were found to be laughingly insecure by the Berkeley and Princeton teams had been certified by Independent Testing Authorities.

Now, the question on everyone’s mind should be “ok, but how do we ensure that there’s some kind of oversight for health software?” A good and very important question, which I’ll try to answer in a future blog post. But for now, let’s be clear: we need more patient involvement, not less. We need new software that will enable this patient involvement, not old software with half-baked web interfaces tacked on as an afterthought. The last thing we need is a government-mandated certification monopoly. Even if they asked Dr. Berwick to run it, it would be a bad idea, because the incentives are all wrong. Innovation/disruption, which we so desperately need, comes from the new, small players, the ones that simply won’t be viable if they have to pay an upfront certification tax, both in dollars and process.