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.


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.

Claims data in PHRs

Today the Boston Globe has published an article about Dave deBronkart’s problem with claim data in his Google Health PHR. I think it is awesome that the main stream press is picking up on the problem of using billing data for clinical work!

A little digging reveals that there is an much better post over at that details exactly what his experience is.

I have been aware of this problem for some time. For me it all started when CVS Minuteclinic imported a ‘condition’ of ‘Blood Pressure Screening’ as  ‘Active’ condition onto my record.

Why did they do this? Because their system must have an ICD code for the purposes of billing for my procedure, even though I payed in cash.

One of the best things about being deeply involved in both FOSS Health IT and a blogger, is that when something hits the main stream press, I get to prove that ‘I told you so’ with reference to posts that are months or even years old. Heck, I bet that ‘I told you so’ feelings are a full 25% of my motivation to blog! That puts it way ahead of ‘joy of shameless self promotion’ and ‘muuust raaannt’ as motivation components!

The problem here is that the current diagnosis onotology system in the United States is based on billing data. With the migration to ICD 10, this problem will only get worse. Most doctors do not really understand how to use ICD 9, and ICD 10 is muuuch bigger.

I got wind of this article from the Modern Healthcare Health IT Strategist.


Trust but Verify and Trust but Fork

I have enjoyed participating in the National Dialogue about Health IT. One of the challenges put forward to my suggestion that decision makers should insist on FOSS in Health IT, was the following comment:

 in terms of privacy, there’s nothing inherent in FOSS that makes it superior to all proprietary products.

I have discussed this issue before, mostly when discussing HealthVault, but my comments have been spread out over several articles.

There is an inherent benefit to privacy, confidentiality and security for FOSS health IT systems.

There is another idea on the National Dialogue site that I thought was useful. It separates the concepts of privacy and confidentiality. Most people blur the concepts of privacy, security and confidentiality and talk about them in the same mouthful. For now I will consider that “privacy” is the ability to control who gets to see your data. Although my points apply to confidentiality and security as well.

FOSS Health IT  are inherently better ways to respect privacy because they support “trust-but-verify”, while proprietary systems just support trust.

The only way to know what a program is doing is to read the most human-readable version of that program, which is typically called sourcecode. There are countless examples of programs doing things other than what they appear to be doing. Viruses, Spyware, Monitoring features and Bugs are classic examples of this.

When a proprietary Health IT program says it respects your privacy, there is no way to know for a user to know if this is true directly, he must trust the proprietary vendor. The fact that most proprietary vendors are honest is irrelevant. The trouble with dishonest people is that you cannot tell the difference between them and honest people. We cannot know which proprietary Health IT vendors are respecting privacy and which are not. Also, the same large organizations who you might normally “trust” have in fact a very poor history of abusing privacy; Microsoft being the best example.

So does HealthVault respect privacy? Probably. But there is no way to be sure without reading the code.

Does Dossia respect privacy? Probably. But we can check by auditing the sourcecode of Indivo, because Dossia is based the FOSS Indivo project. Suppose that you believe that Indivo does not do a sufficient job of respecting privacy, or you find a back door (unlikely). You can fork the code, remove or change the offending portions of Indivo, and then run your own Indivo server with the privacy features that you want.

FOSS supports both trust-but-verify and trust-but-fork which is the only way to absolutely certain that privacy is maintained.

Therefore FOSS does have a fundamental advantage over proprietary software with regards to privacy concerns.


The coming problem with the ASP-lock

Here is an interesting post about a person who was locked out of their google account.

Apparently, this person lost access to:

  • Google Docs
  • Gmail
  • Family photos in Picasa

If you read the updated post, you will find that he has already gotten back in.

But this person knew to write a blog post. And knew how to get it covered by the most popular blog on the planet.

What if this person had a PHR using Google Health?

I am not trying spread FUD here. Google Health and HealthVault are good ideas and I generally support them. But these kinds of issues are going to become more and more important as time goes on.  Both Google and Microsoft have relatively fair ways of dealing with these kinds of issues, but “relatively fair” means there will be ways to fall between the cracks. Once we have PHR usage begins to go up, these kinds of issues will become extremely important.

(Update 09/29/09:  I am not the first person to point out that ASP EHR systems are a threat to the freedom of healthcare providers.  This short post is just to say that it impacts patients too)




Defining terms

NAHIT has released its definitions.

In summary:

An EMR is a record for the doctor.

An EHR is a record for the doctors. (with data ready to move)

A PHR is a record for the patient.

A HIE is the process of moving health data.

A HIO is a O that does HIE.

A RHIO is a HIO that is Regional.

Well now that that is settled, I am sure that the whole industry will stop using the terms EMR and EHR interchangeably. I am sure that no one will refer to a RHIO as an HIE.

Thank God for the government.


HealthVault team responds to security model criticism.

In further evidence that the Microsoft HealthVault team might actually be making good on a move towards real openness. Sean Nolan has addressed some of my criticisms in a post entitled Sharing Data using HealthVault

I have updated the post in question to correct the errors that I had made. However, even with the correction made I still think the HealthVault authorization model has erred too much on the “functional” side. It is worth pointing out that this is a design decision that many programmers would side with Microsoft on. It is a tricky issue: How do you allow for the transfer of ownership of a record without also creating a system that can be easily abused? Microsoft has historically taken the view that functionality comes first, and so they have always released operating systems that are extremely functional, but that hackers inevitably have a field day with. They have done pretty well with the “functionality first” design paradigm. (who am I to argue with the whole Windows install base?)

I will not reply fully to Seans post until I have had the opportunity to study HealthVault more closely and perhaps even ask Sean some very specific questions, however, the most significant thing here is that Microsoft is responding at all. This is awfully quick turn-around for a company that has historically ignored criticism.

I do believe Microsoft is listening.