Using HTML5 as the basis for HL7 CDA v3

Keith Boone, well known and liked Health IT standards geek has written up a proposal that would make the next release of HL7 CDA based on HTML5 rather than XHTML.

I have just become more deeply familiar with this set of standards as the result of the extensive research I have done on my new book on meaningful use  of Health IT.

I can say, without a moment of hesitation, that this is a really good idea.

Everyone should support this proposal, b/c otherwise, CDA is a huge mess.

Which is not to say that an HTML5 version would not also be a huge mess. But I believe that it would be less of one.

-FT

Unethical Blue Button Contest

This contest is deeply problematic.

The blue button initiative was a good initiative because it allowed greater access. It made that possible by ensuring that access to patient data did not have to wait for the VA/DOD/Whatever to create a download that conformed to the still-forming XML standards that make true interoperability possible.

But now the VA is promoting the Blue Button format as something that should be integrated into other EHR systems. That is unacceptable.

Meaningful use requries that doctors allow patients access to their health record summaries using CCR or CCD. Both of those standards can easily be translated to printable reports that are very readable. Meaningful use -also- requires that patients be provided a summary in a printed form. The simplest way to do this is just to have onsite printing of the CCR or CCD reports.

Blue Button data format is not as readable as a summary printout, and is not as parseable as XML. It is the worst compromise between human and computer readability. No clinician should ever make a clinical decision based on the content of a Blue Button download. The data is simply not rich enough to transfer into another health record or PHR. Essentially that makes the blue-button data format standard an FYI-only use case.

The innovation of Blue Button is to not let standards compliance get in the way of access. For this reason the DOD and the VA use of the Blue Button format should be applauded! The Blue Button initiative was fully give-me-my-damn-data compliant! But promoting it as an alternative process to a process that supports fundamental data reuse and is -already- required by meaningful use is unethical.

I formally request that the VA withdraw this contest, or make it clear that a CCR/CCD/printable report download meets the requirements of the contest.

Either you are promoting the notion of patient access, which is wonderful, or you are promoting shitty health data standards, which is unethical.

Cross posted on the VA challenge forums here.

Here is the example of the file format in question.

-FT

QR code stencil upmanship

As far as I know, I was the first person to publish a generalizable method for creating a QR code stencil or to even clearly document why such a method was difficult.

However, since that time, I have realized that other approaches would ultimately be superior. The two I have been pursuing are automated embroidery of qr codes and improved stencils using laser cutting or 3d printing.

I will likely be abandoning the latter work, now that my early attempts have been eclipsed by Golan Levin at the Studio for Creative Inquiry at Carnegie Mellon. This work is being released from fffff.at, whose motto is: release early, often and with rap music.

Here is a link to his post on his new laser-cutter QR code stencil generation code. Along with his first application, a remake of hobo-coding.

Golan gave me a shout-out on the post he made. In some ways, it is hardly justified, since his method obviously surpasses my chicken-wire method in several ways. In fact, the only outstanding benefit to my method now is that it is much cheaper, and you do not need access to a laser cutter. The codes generated from his method are cleaner, and could probably be made smaller than my methods, and do not require an hour of working with caulk.

In a private email, he mentioned the possibility of a githib release soon…

In any case, take a look at the wonderful photos of the stencil in action.

WorldVista Meaningful Use Certified

Not sure why this was not formally annouced, but I was just doing some last minute fact-checking on my new health IT book, and I discovered that WorldVista EHR is a meaningful use certified product.

This is quite an accomplishment, and I am somewhat surprised that WorldVistA has not had an announcement about this. This is really important news and have broad implications. WorldVistA, unlike ClearHealth and Medsphere, is a non-profit organization.

Medsphere and ClearHealth provide only “pro” customers with the benifit of certification. How will WorldVistA handle this?

It is not clear to me if this could be the first completely available (sans proprietary ontologies of course) meaningful use certified Open Source EHR that you do not have to pay for support for. To make an analogy its like the difference between Fedora getting a certification vs RedHat Enterprise Linux getting a certification. Both are Open Source, but the latter is expensive

The other Open Source options as I understand them:

Tolven is partially certified as is OpenEMR.

ClearHealth was the first to be fully certified, and Medsphere also has a fully certified product.

Sharks, Bees and Privacy

Hi,

I am happy to announce that my new article on healthcare privacy and interoperability has been accepted in the Journal of Participatory Medicine.

I am not against privacy in healthcare, but I am against the notion that privacy concerns should trump issues relating to good healthcare.

You can read the full article here:

http://www.jopm.org/opinion/commentary/2011/07/05/sharks-bees-and-health-privacy-paranoia/

-FT

Google Health: influential, controversial and gone.

Google Health is no more.

Thats a shame, because I am writing a book on Health IT for O’Reilly and before this announcement, my rough draft featured Google Health extensively.

I guess this is better, though, than having Google Health shut down just -after- I finished writing my book.

Of course, I am going to have to change lots of content in the book, but Google Health will still be there.

For a project that no longer exists, it will end up being one of the most influential Health IT projects of our era. Google Health, and for that matter Google generally, has always been willing to make strong statements when they evaluate technology and technology protocols. In fact, Google has made two controversial technology picks and the opening and closing of Google Health.

At the opening Google decided that they would support CCR (Continuity of Care Record) from ASTM and AFFP rather than the much more complex CDA/CCD from HL7. The CCR vs CCD debate has been one of the most controversial and long-standing arguments in Health IT. HealthVault, the Microsoft product which survives Google Health has always elected to support both standards. But Google insisted that the CCD standard was too complex, and not only insisted on CCR, but a smaller subset of that standard.

Now, as the end support for Google Health, Google is choosing to allow export under the Direct Protocol. Again this is the simpler of the two protocols that is supported by ONC to be part of the NWHIN (the precursor to the Health Internet). The other protocol, IHE, is getting no love from Google Health.

Goodbye Google Health, whatever else I may have said about you, I must admit that you made some ballsy technical stands.

-FT

Google Health is dead, HealthVault Indivo win

Recently, Google announce that the Google Health PHR will be retiring.

I posted the announcement to the Society for Participatory Medicine mailing list, and there has been alot of discussion about this, there. There are several issues that lots of people do not seem to understand, and some implications of this that have been missed.

Losers: Google Health Users

Let me be perfectly clear. If you trusted Google Health with your healthcare data you are screwed, unless the Microsoft HealthVault team rescues you. Even then, you are likely screwed anyways.

The whole point of Google Health was that it was more than a mere store of your XML patient data. It was a network of providers, like pharmacies, drug companies, non-profits and countless other service providers who added value to your health record.

I love the Direct Project but it only makes health data mobile, it is another matter altogether to make your health data semantically useful again. There is no way that the HealthVault team will be able to replicate 100% of the value that Google Health was providing based merely on the XML output from Google Health. As service providers and patients themselves added to their Google Health record, it made those records more complex than HealthVault, or any other PHR system, can easily understand. This is called Lossy Data Conversion.

The patients who will lose the most useful data, are those patients who leveraged Google Health the most. The more you invested in Google Health, the more screwed you are now. Of course, the other group who is going to be really screwed are the people who do not pay attention to announcements like this at all, (and ignore or filter email warnings) who will try to find data they stored in Google Health four years from now, only to discover that the deadline for data download had passed, and their data is gone. Ironically, the people who this is most likely to happen to are older people, who are not terribly tech savvy -and- who might have stored data in Google Health precisely so that they could ensure it would be available as they aged. Again the more they invested, (seemed like a good idea at the time), the more screwed they are today. Not good.

Probably the most important lesson to take away from all of this is that trusting proprietary health software vendors or services with critical health data is a bad idea. But sadly, that will not likely be a lesson learned here.

Losers: PHR vendors

Second, there is the implications for  PHR vendors. It does not look good for you. Google is in a unique position as a company. It is capable of making money giving away very valuable services, because it makes more money on advertising when someone merely uses the site. The business plan on Google Health was, essentially

“Lets spend a few 10’s of millions on this, and then make it back because a few million people will click on ads, after leaving Google Health to do a web search of some kind.”

Your average PHR company cannot make that kind of play. Most companies do not have a way to translate mass visitors into dollars. That is what makes the gmail service work for Google. Enough people click on ads through the service to pay for the entire thing for everyone. Google specifically admitted this problem in the post above with:

But we haven’t found a way to translate that limited usage into widespread adoption in the daily health routines of millions of people. That’s why we’ve made the difficult decision to discontinue the Google Health service

So if you are trying to start a PHR business and you cannot afford to give away a product you spent millions developing for years… this spells trouble. Google Health and Microsoft Healthvault together spelled the end of the still languishing dot-com bubble PHR services. I cannot imagine an investor in their right mind who would touch this space with a business model anything like Google Health.

Here is the basic takeaway from Google Health PHR:

People are not willing to use a good stand-alone PHR, even if it is free.

That word  “stand-alone” is critical.

Losers: Me

I have been wondering, as a right this, if I should be a winner or a loser on this one. I get to say “I told you so” to everyone I warned not to invest in a proprietary platform… which is fun. But I also now have to almost entirely re-write a chapter in my new book.

I (along with intrepid David Uhlman) am writing the first book on Health IT for O’Reilly media, called “Getting to Meaningful Use and Beyond“. I wrote the chapter on patient-facing software, and I featured Google Health extensively. After all, it was relevant, last week. I felt reassured after I asked Roni Zeiger a month or two ago if Google Health would survive? After all, I had heard rumors. He told me not to listen to gossip and I left feeling like my chapter would be published intact.

So much for meeting my deadline.

Winners: Direct Project

As Google Health dies it is giving a ringing endorsement to the Direct Project (of which I am a contributor). Hopefully this will raise some awareness regarding Direct as the foundation for the first generation of the Health Internet.

Winners: Microsoft HealthVault

Most of the industry pundits, like myself, have recognized for years that the “build the platform” business model that worked for Facebook and Itunes, was not going to work for Personal Health Records. Why? No “killer app”. Itunes+Ipod was the killer app for the Iphone platform, for Xbox it was the original Halo. For Facebook it was your ‘wall’, or perhaps (shudder) FarmVille.

The killer app for a PHR is dead simple: Healthcare. The two most widely used and successful PHR deployments in the country are the Kaiser Permanente and the VA’s My Healthevet. Why? You can get a message to your doctor through them, and receive replies back. They are a component of your actual healthcare. You do not have to type data into them, its just there. If you want to schedule an appointment or view your lab results you can do that. If you want to renew a prescription, the PHR can help. In short, the PHR is a workhorse in your actual healthcare process.

The Microsoft Healthvault team gets this. That is why they have been working on the Direct Project for months. They know that the Direct Project is the only way that they can have their PHR connect to -all- doctors the same way that Kaiser and the VA connect to their doctors.

Moreover, HealthVault has the only working mass-scale Direct beta in deployment: It is very likely that the only place you will be able to transfer Google Health records will be directly into HealthVault, for the foreseeable future.

HealthVault just became the 800 gorilla in the space.

My only question is why didn’t the Google leadership see the strategic significance of the Direct Project? They were obviously aware of it technically, and they usually do a good job translating technical understanding into strategic understanding.

Seems pretty simple to me. PHR usage is high -only- in systems where you can communicate with your healthcare provider in various ways. Google was disappointed by how few people were using their PHR. Direct is the only chance in hell that you have to reach every healthcare provider in the United States in the next five years. When you put it like that, Microsoft’s strategy seems pretty obvious… why didn’t the Google leadership catch on? Probably the Direct opportunity was too little too late for the internal political process at Google.

Winners: Indivo X

Indivo X has almost all of the same benefits as HealthVault (they are little behind on the Direct implementation and beta deployment), but if you actually want to avoid a repeat of the Google Health fiasco, this is the way to go. If you import your Google Health record into an Indivo X instance, you are not locked-in again.

Indivo X is Open Source, you can run your own instance if you want..

From now on, people will regard Indivo X as the safe option for PHR deployment, and rightly so, it is the only safe option. Until I can convince Sean and the rest of the HealthVault team to go full kimono, Indivo X is by far the most mature Open Source option available.

Why I do not think Google Health will, or should go Open Source

If Google drops code for Google Health, thats cool and I would take a look…  but I am not going to hold my breath.

Its pretty simple; Indivo was Open Source and available before Google Health launched. Some people believe that Google Health, like Dossia, is actually a long-ago fork of Indivo.

Indivo has moved on to bigger and better things. Indivo X, the current version of Indivo already has substantial functionality that Google Health is missing. It is already a mature codebase, with a community, and is generally operating openly as an Open Source project should. The Indivo project is not perfect, but they have steam.

Steam, motion, community, these are the things that make the Open Source garden grow.

Google Health would not actually help the Open Source community that much. We already have a better PHR project, and anything coming out of Google would compete for developers and attention with Indivo X.

Even if they wanted to, I am not sure that Google could usefully Open Source the whole Google Health codebase. Google projects often run on Googles custom, and proprietary database and network services. It is entirely possible that Google  Health would be useless without that back end.

What -would- help is for Google Health to release any components that Indivo X is missing. If they have an interesting Blue Button parser (which I happen to know they do) for instance, or some generalizable code for managing CCRs (that CCR-in-a-feed thing was a nice trick for instance…) then those components would be very useful.

Moreover, any components that would help people to parse their own Google Health data would be very welcome.

Probably the most important thing that they can do is license their API under several Open Source licenses. This way, Indivo X and HealthVault would be able to write a bridge that would allow currently existing Google partners to interface with Indivo X, without re-writing code. That would be pretty cool.

Meaningful Use book

The first chapters of Getting to Meaningful Use are available online for public comment.

I am often surprised to meet people at conferences who say “I read your blog”. I mean, I know you read… because I have server logs to prove it…. but actually meeting someone kind of blows my mind.

So if you read my blog, and you enjoy it, please take a moment to read the first chapters of my book and give me some feedback on it.

I would especially like feedback on the Introduction. I was the primary author on that part (although that chapter especially had help from both co-author David Uhlman and my editor Andy Oram). Getting that chapter right is really important to me, because it is really sets the tone for the whole book. It details how Health IT is really different from normal IT.

If you are a regular reader, please, take a look.

-FT