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.

Direct gathers steam

Recently, the AAFP and Surescripts announced Physicians Direct, a secure messaging service for providers.  But neither the article nor the signup page for Physicians Direct detail the most critical single issue regarding the service. This is a very large deployment of the Direct Project. This is by far the most important part of the story, but it is buried deep with the FAQs.

That means that the service is compatible with other large adopters of the Direct Protocol. Most notably, HealthVault has just launched a beta deployment of Direct.
Think of the implications of this. One of the largest PHR providers in the country is on the network, one of the largest network of doctors is on this network.

We are watching the birth of the Health Internet.. its is truly wonderful to be involved in this work.

When I tell my grandkids what I did with my life, I hope the links to my early posts on the Security and Trust Working Group of the Direct Project are still up. “I was part of that from the beginning” I will say… My previous plan was to tell them that I invented bubble-gum ice cream, and then enjoy basking in their amazed adoration, until they discovered that Grampa’s stories are “unreliable”.

This will work out much better.

This is also a tremendous step for Surescripts away from being a proprietary network provider. For those who are unfamiliar with Health IT, Surescripts has a monopoly in e-prescribing after buying out its only competitor several years ago. If you e-prescribe in the United States, there is a 99% chance that the data cross the Surescripts network. Surescripts is free to use for Doctors, but the pharmacies pay for the privilege. But that business model will die as the Health Internet grows. Once the pharmacies realize that you can use the Health Internet to exchange prescriptions rather than the expensive Surescripts network, that business will dry up quickly. Moving into the Health Internet provider business is the only chance Surescripts has at long term survival. This is a very smart move for them.

Of course, this also has implications for meaningful use. Providers can use this exchange network, without making an expensive investment in EHR technology, and still qualify for part of the meaningful use dollars. $15 a month might seem expensive for glorified email, buts a whole lot cheaper than an EHR.


Microsoft may allow FOSS implementations of HealthVault API

Sean Nolan has announced that Microsoft has placed the HealthVault API specification, under the Microsoft Community Promise (CP) at the time of the writing, this page has not been updated to list the HealthVault API, but the text is provided in the specification download. This may allow for FOSS implementations of HealthVault.

The Microsoft CP is not the same as Microsofts Open Specification Promise (OSP). That is problematic because the Open Specification Promise is already doubted by the larger FOSS community,  and the CP seems even more limiting.

Most notably the CP is different from the OS (from the CP FAQ):

The CP requires that implementations conform to all of required parts of the mandatory portions of the specification. Also, in specified cases (such as where the specifications have uses that exceed those needed to achieve the interoperability needs for which the release under the CP is being made), the CP may have special terms concerning what kinds of implementations are covered.


The CP applies only if the implementation conforms fully to required portions of the specification. Partial implementations are not covered.

The CP for Healthvault does have special terms (from the specification download)

Community Promise Restrictions on the Field of Use for the HealthVault Service Specification

HealthVault Service Specification is intended to support personalized healthcare. This technology is designed to be used by individuals to manage their health information, and is not intended to be provider-centric or health enterprise-centric.

That is a problem for projects like Tolven, which is a combined PHR/EHR system. If the PHR component of Tolven were to implement the HealthVault API,would the CP still be ineffect? In Tolvens architecture, the PHR and EHR are based on the same database. While Tolvens PHR is patient centric, the EHR is user centric.

Further it is not defined, as far as I can tell, what a ‘full’ vs. ‘partial’  implementation means. I could create an implementation of the web service calls for HealthVault over a long weekend, by stubbing everything. Now, my system would be a complete implementation from the protocol perspective, every call made to HealthVault would also work on my system, but nothing my system did would have any meaning. It would be much harder to implement things so that they conformed to the specification and actually worked (as opposed to merely appearing to). We might call an implementation that had no stubs and instead contained attempts at real working parts a ‘robust implementation’. But even a robust implementation would have bugs. It would typically work just like HealthVault, but sometimes it would behave differently, mysteriously.

Those ‘differences’ are what programmers like me might call a  ‘bug’. But would an implementation with bugs fall under the Microsoft CP?

More importantly, who decides if an implementation is buggy? HealthVault is still labelled as ‘beta’ and it is entirely possible that if HealthVault and a FOSS implementation of the HealthVault API worked differently, it would be because HealthVault had moved past its own specification.

At this point, I cannot recommend that anyone implement this API. There are too many unanswered questions here.

Having said that, Microsoft is  obviously trying to open up with HealthVault. I hope to convice them that the OSP is a better vehicle, but this is a step in the right direction. So far Google has released no information on the rules for re-implementing the Google Health API. At this point, Microsoft is (surprisingly) more open than Google.


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)




In all Fairness

Its time to set the record straight on what are valid criticisms of HealthVault and Google Health and what are not. If you have ever read my posts, then you can be sure that when an organization needs criticizing I am the first to give it them with both barrels. But here both Google and Microsoft need defending.

  • Neither Google Health nor HealthVault are HIPAA covered.
  • This is a very good thing

But to understand why, I must beg the reader for patience.

My mother died of ovarian cancer. My Grandmother had a bout of cancer, but survived. Now she is battling Alzhiemers and it will probably kill her. I have talked about this before as the fundamental basis for the Seven Generation Test.

Now read the sentences above again… and ask yourself: “what has this writer just revealed?” Extremely sensitive personal medical information about himself. Note that I did not say “information about my mother or grandmother”, though I did reveal information about them too (obviously).

I have two people in my direct line of parentage that have both had cancer. Statistically, that makes me substantially more likely to get cancer. Further, alzheimers also has a genetic component. So I just revealed to you critical information about my personal health, specifically something that would go into the “family history” section of my health record. It is exactly the kind of information that a Health Insurance company would love to be able to use when setting my premium. It is exactly that kind of information that HIPAA was designed to keep my healthcare providers from telling insurance companies without my knowledge.

Just because HIPAA protects me from my doctors making this type of disclosure does not, and should not, mean that I should not be able to make that disclosure myself. There are many reasons why I might want to make this disclosure: I might want to make a point on my blog. I might want to explicitly tell my insurance company about this, in writing, so that they could adjust my insurance premiums accordingly. This way I would be well-armed in the event that they should try and deny me coverage for cancer treatment.

Lets consider the current paradigm of personal health information management. To facilitate this lets imagine that I was allergic to anticonvulsants (which is common). I have been to about fifteen or twenty doctors, each of whom has extensive records regarding my healthcare. I had knee surgery, and somewhere I have a orthoscopic video of the inside of my knee during the surgery (in VHS format). I have pages and pages of immunization and dental records from my in-processing during bootcamp for the USMC. I did not have a seizure in bootcamp, and if I had they would have sent me packing. But lets imagine that I did, and that the navy docs discovered that I was allergic to anticonvulsants. They would have promptly added it to my record.

I have all of my Marine Corps records in my file cabinet. But, these are just the records that I have in the house. I probably have about 1/10th of the medical information that is available, somewhere, regarding my healthcare.

Lets imagine that I had some kind of life event that would require me to gather those records together. To do that, I would need to call every doctor I have ever visited, and request a copy of my records. Healthcare providers are mandated by HIPAA to give me this information, and many of them, as a professional courtesy, would waive the costs of transferring my record to me. All of the providers I might contact would prefer to fax me my records. Faxing is simple, easy and well-understood by the medical practices. Faxing over phone lines is the de facto “health exchange network”  in the United States. (Unless you are lucky enough to be a Veteran, and have a record in VA VistA)

If my Marine Corps comrades understood the implications of this, they would say “that sucks salty balls”. Or something even more uncouth, but just as disturbing. Why does that suck? Because the resulting documents are largely valueless.

After making all of the requests and getting all of the faxes. I would have a briefcase full of documents of my healthcare. 95% of it would be redundant, showing my slowly rising cholesterol and blood pressure scores. The 5% that was really critical, like my imaginary allergy, would be buried so deep in my briefcase of papers that it would never be seen.

Given current primary care reimbursements, my doctor is incented do everything in his power to spend under 10 minutes talking to me. If he actually had to read through my briefcase of papers, then he would spend an hour doing nothing but shuffling papers. It is a much better use of his time just to ask “are you allergic to anything?”. I would of course say “not that I know of” in response. (Marine Corps boot camp is largely spent fluctuating between extreme emotions of hate, anguish and triumph. While you are guaranteed to learn some things, obscure allergies are not one of them. For all I know, I really am allergic to anticonvulsants)

I will not belabor my point. If I am lucky I will not convulse. If I do, they would give me an injection which will probably kill me. Why would I be dead? It is not because I had an allergy, that is only the proximate cause, the ultimate cause was very different.

The ultimate cause would have been: our ability to generate medical information has vastly outpaced our methods for handling that information.

That sentence should explain why we need storehouses of health data, that we can use to effectively deal with our own health information. HIPAA is designed to cover healthcare providers and those who come into contact with patient data, serving the business needs of those healthcare providers. Assuming that the same kinds of rules are a good idea for “data about me that me providers hold” as for “data that I hold” is silly once you see that they are very different circumstances.

Now lets imagine a world in which my various doctors medical records professionals all understood how to connect with HealthVault and Google Health. When I called them for my records, they would enter my email address instead of my fax number and press “send”. On their side, Google, Microsoft or Dossia (based on open source) would sift that information and allow me to transfer the resulting summary to anyone I wanted to, including my family, my friends, and my future healthcare providers. I could also forward the information to my insurance company, if I felt like that was a good idea. All three system would recognize the significance of an allergy and would prominently display the information.

HIPAA covers healthcare providers. Healthcare providers are the only people who know your health information, without you giving them permission to know it. Here are some of the things that HIPAA prevents your healthcare provider from doing:

  • They cannot tell your aunt Sue about your health conditions
  • They cannot tell cousin Joe, Rick, or uncle Eddie about your health conditions.
  • They cannot tell your insurance company about your health conditions.
  • They cannot post your name and information to their blog
  • They cannot tell the press about your health conditions, even if you are famous.

Here is what HIPAA does not cover.

  • If you tell aunt Sue about your health conditions she can tell uncle Eddie.
  • If you tell your health information to cousin Joe, he can tell cousin Rick.
  • You can post any medical information to your blog that you want.
  • If you post to your blog, that does not mean that wordpress needs to be HIPAA compliant.
  • You can tell your insurance company whatever you want.
  • You can do an interview about how rehab went for you.

Google and Microsoft are not healthcare providers. To have accurate data in those PHR systems your healthcare providers, at your request, must send them your data. Then Google and Microsoft help you to sort out the information. Compared to the way it works today, both systems are an improvement. Both of them help you organize your health information and both of them will help you to transmit that information where it needs to go.

Are they useful? Not really, and they will not be until your medical practices understand them as well as they do the fax machine. Will they be useful when that happens? Yes and very.

HIPAA stands for Health Insurance Portability and Accountability Act. It is not an accident that HIPAA does not include Google or Microsoft. The whole point was to make healthcare providers accountable for certain issues, while generally encouraging data to move around. Sadly, paranoia about HIPAA has caused data moving to grind to an almost standstill. Everyone is paranoid about it and to data transfer does not happen. Or worse, as Dr. Peel suggests, they transfer the data anyway, but in secret.

Under HIPPA the patient has a right to force data transfer to themselves. Currently providers do this with faxes which is ends up creating a massive problem. If they used Google Health, HealthVault or Dossia instead, the patient would actually be able to exercise those records!!

Saying that Google “should be covered” by HIPAA means that somehow, the person on the other end of the fax machine should be covered by HIPAA too! That means that if you faxed your records to aunt Sally, and then she showed them to uncle Bob, she could go to jail for a HIPAA violation? Or if you actually faxed them to yourself and then accidentally left them on the table at your local burger joint that the burger boy who cleans the tables needs to be sure to not just throw your records away, and instead have a policy for maintaining those records? Perhaps you had them faxed to Kinkos; should they have to maintain a separate safe for holding your faxes?

People who are shocked that Google and Microsoft are not covered by HIPAA, never actually understood the point of the law at all. Instead they generalized HIPAA into a kind of “patient right to privacy” umbrella that is just not there. You do have the right to privacy for those with whom you must share your secrets with; your healthcare providers. You do not have a right to privacy that covers your own stupidity, your gossiping family or your tendency to leave papers in the grocery store.

Both Google Health and HealthVault are designed to make the process of dissemination of your health information to people you want them to be disseminated to easier. Are they doing that in a secure, privacy respecting way? Excellent question; fodder for further posts. Should they be covered by the same laws that cover your healthcare providers? No. The law does not work that well for your healthcare providers anyway.

The whole point of a PHR is to allow a patient to control who gets to see their data. HIPAA works at “limiting” who can see your data. Because of HIPAA medical provider typically never share your data without written consent for every data sharing instance. Think about that. Suppose I have a chronic condition and I want everyone in my family to get regular updates on my lab results. Do I need to sign a document, for each family member and for each test? It does not take much time for me to get sick of the process. Also, my doctor might get sick of it too. He has the right to charge me a nominal fee for access to my record, and after a while he would probably feel he had to use that right. On the other hand, if there were an automated way to share the same information…

A PHR is all about balancing the ability to share and the ability to limit access. If a PHR were HIPAA covered, then it would lean strongly towards limiting and sharing would be impaired.

Everyone who talks about Google Health and HealthVault needs to stop harping on the HIPAA issue. HIPAA was not meant to cover the services that Google and Microsoft are offering. Here are some examples:

Quoting from Nathan McFeters at ZDnet:

Hawhhhaaaaattttt??? So Google doesn’t have to respect HIPPA laws?!

Thats HIPAA with two AAs man… Google respects HIPAA just fine. Google is probably relieved to find that the law makes some sense here, as opposed to the typical knee jerk legislation.

It feels like, and this is just a gut reaction here, law should have a strong and violent reaction to Google skirting around HIPPA concerns.

Again. There is no skirting. Google is not “slipping” out of responsibility. It is not covered, and that is a good thing.

The article linked to above also details that Google does not typically follow standard procedures for publicly disclosing flaws. That is a big problem and one that deserves attention, but it is not a HIPAA problem.

Quoting from Robert “RSnake” Hansen:

I think it’s a shame Google found a legal get out of jail free card to absolve themselves from securing consumer medical records in the same way everyone else who handles this kind of data does.

Here we have two problems. First the assumption that Google should be covered by HIPAA, which I hope I have shown is not true. Second, the assumption that Google would invest more technical security if they had HIPAA liability. Perhaps Google is not doing enough for security, but its not like security programmers code better when lawyers stand over them. They might code “differently”, but not “better”.

If there is a structural flaw in Google or Microsoft’s architecture, that is something that they should both fix and take public responsibility for but that does not mean that they should be covered by HIPAA.

Frankly these two bloggers, who have been featured on slashdot are only the start of the problem. I had the privilege of covering HIMSS as a blogger, and as a result I got to ask one question to Google CEO Dr. Eric Schmidt, upon his announcement of Google Health, as did every other reporter in the room.

Three different reporters asked “Is Google covered by HIPAA?”. Each one got the same answer: “No we are not”. All three of them asked these questions in such a way that it was obvious that they had read to many “tough reporter” novels. A little hint: perhaps the first time a really good question is asked it might trip up the executive at the massive fortune 500 company. But the second and third times the question is asked in a press conference is waste of time for everyone.

This kind of useless heckling is not just a problem for Google. I just came from TEPR where a Microsoft guy was talking on HealthVault. It was the same “HealthVault is a platform” story that you can read about in the brochure, but at the end, there was time for only one question. Guess what it was? “Is HealthVault covered by HIPAA?”

I really really wish we could stop talking about this issue and talk about real problems. Real issues include:

  • Google does not typically disclose vulnerabilities.
  • Microsoft still has terms that indicate that it can host your HealthVault data in China.
  • How are we going to make connecting to HealthVault or Google Health simple enough for small medical office personnel to handle? Do you know how many “HIPAA violations” we have every year because people do not understand how to dial 9 before getting an outside line when faxing?

Critics also have silly notions about how people who are covered under HIPAA are behaving. Most of the healthcare in the United States are delivered by practice with under 5 physicians. I cannot tell you how many practices I have seen that have a locked closet for paper records but have the EHR server sitting under the receptionists desk. If you want to illegally access my medical records which do you honestly think is easier:

A: walk into my doctors office at three in the afternoon with a shirt with “IBM” written on it and just grab the server and walk out.


B: hacking Google or HealthVault, who both have extensive Firewalls and Intrusion Detection systems, along with well-educated network security personnel on duty 24-7.

If you really felt that Hacking was the way to go, then you would have a much easier time hacking through the average clinics firewall than Microsoft’s or Google’s. Most of the doctors I know do not even know what a firewall is, much less the steps to lock one down. (that is not a criticism, I have no idea how to remove an appendix.)

I am not making the case that Google Health or HealthVault are secure. I am not saying that they are respecting privacy. Those are discussions that we need to have.

But HIPAA is not the answer.


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.


Google Health vs. HealthVault round 1

Everyone is talking about Googles new PHR offering vs. Microsoft HealthVault. Mostly the talk is drivel. I was able to get a seat at the Press Interview with Google CEO Eric Schmidt at HIMSS and, I kid you not, two reporters asked “Is the data in Google Health covered by HIPAA?” within five minutes of each other. Frankly, not-covered-by-HIPAA is an industry standard for PHRs, and the fact that the question was asked at all is an indication that the press covering this largely have no idea what is going on. (I will talk more about HIPAA and PHRs in a future post.)

Rather than finding drama in all of the wrong places, I wanted to highlight a couple of differences that really are worth paying attention to. I have had the privilege of speaking with the programming leads for both projects extensively, and it is not yet time to give a close blow by blow of where these two system are in comparison to each other. (that will happen after Google Health goes live) I hope that what little technical meat I was able to dig up will be interesting to you.

Privacy Policies:

Google has not published its privacy policy. However, it has historically given great weight to privacy concerns. Most notably take the Google Toolbar privacy notice. It begins “Please read this carefully, it’s not the usual Yada Yada”. It does a fair job of warning a user about the considerably privacy issues surrounding a tool placed directly within a browser. In fact, the sites you browse on the internet is probably as great a privacy concern as any health information you have. If you have any serious health conditions you have probably already searched for them and visited sites with content relevant to that condition. If you use toolbars, the information about where you visited was potentially transmitted back to the author of that toolbar. Google is upfront about this, and gives you an opt-out. This is much better than your average toolbar.

Microsoft’s Privacy Policy is awful. It has language that includes things like: “you give us permission to host your data off-shore”, and “we can change this policy anytime we like”. The current HealthVault privacy policy does nothing to protect a patients privacy from future policy changes within Microsoft. Based on the current language, the privacy policy might as well not exist. I discussed this with the HealthVault team and their response was “boiler-plate language”.

Frankly, the fact that ANY boiler-plate language was included in a privacy policy is a good indication that the thinking at Microsoft Legal is totally backwards. It is currently thinking “What will the market let us get away with” rather than “Hey this is a new moral sphere, if we do the right thing here, maybe the Government(s) will not make our lives completely miserable by over-regulating this industry.”

Privacy Policy Verdict:

Google wins. Without even releasing a Privacy Policy. On a scale of 1-10 Healthvaults scores a -2 which in English translates “hell-no”. That makes Google’s lack of score actually come out ahead.

API Design:

Google Health uses a CCR record wrapped in some of its standard web-service APIs. It would be better if they could have adopted CCD. But they said it was not ready when they started, which is a fair response. Still CCR is already a popular standard and a smart move for Google.

HealthVault has released its own XML specification. While they have promised to promise not to sue the pants of people like me who decide to use those specifications, creating a “new standard” in the healthcare space is regrettable step backwards.

API Design Verdict:

Google wins for respecting current standards.

Security Architecture:
Google is using their authsub system to allow users to provide token based access to other people (care-givers etc) for temporary and limited access.

HealthVault is using a “root” user notion that is transitive. That means that if I trust bob enough to make him a “root” user on my PHR record, then he can do anything with my record. Including passing the root privilege to Jenny, who can pass it to Sam, who can pass it to Ruth who can then do anything with my PHR account. See the problem? While the HealthVault system does allow for finer grain control, there is no concept of passing along “complete control” without also passing along the ability to create other “root” users.

(updated 03-04-08 Sean Nolan from Microsoft has posted a rebuttal to the previous sentence, while the rebuttal does not address my criticisms of a “transitive root” privilege system, it does argue that this design can be considered a feature rather than a flaw)

Security Architecture Verdict:

Obviously Google has time to screw this up before coming out of beta, but it looks like its access control system has been better thought out.

Time to Market Verdict:

Obviously, Microsoft wins here. HealthVault has been out for months. However, if they do not get their act together they will not have any remaining first-mover advantage. Google is obviously making very sharp moves, in fact, maybe their best move was not coming to market before they were ready.

Now that Microsoft has made some FOSS friendly sounds, I will take a closer look at their software. When Google Health is finally released, I will do a complete comparison.


Meeting Dr. Peel

Medsphere, and the Shreeve Tragedy have left me a little jaded. I have little patience for those who threaten the health FOSS community. Believe it or not, I rarely allow my aggression to turn public. I can think of at least 5 friendships with current FOSS community members, that began with rather nasty emails originating from me. Most of these useful harassments never make it into the public eye. The work that Dr. Peel has done with Microsoft around their HealthVault line has been a notable exception. Dr. Peels public endorsement of Microsoft originally shocked me so greatly that I felt I had to publicly respond.

So it was with great anticipation that I was able to hear Dr. Peel speak for the very first time today at HIMSS 08. In her talk, she indirectly addressed many of my criticisms. Lets review some of the “potshots” that I have taken at her, and detail what I heard in her talk about this issues.

Dr. Peel detailed her plans to create a new organization to perform privacy reviews of PHR sourcecode and privacy policies.

Apparently the new certifying organization will not certify PHR systems, without performing a sourcecode review.

Obviously, through the new certifying organization, the “endorsement” of Microsoft would become a formal matter. The endorsement would be withdrawn, if Microsoft started behaving badly.

I wish that I could believe that Dr. Peel started these initiatives in response to my criticisms (it would make me feel very important indeed to know that she was listening), however it is entirely possible that she may have had this plan in her organizations Skunk Works long before I was saying anything.

Here are some further snippets that I found comforting from her presentation.

  • She has claimed that she has not taken any money from Microsoft, she gets her funds from her own network of friends and supporters. (Transparency is good)
  • When I asked about the clause in Microsoft’s privacy policy that specifically gave permission for Microsoft to off-shore data storage, she immediately replied that she thought that was totally unacceptable.
  • While she listed Microsofts Healthvault as a “good” project, she also listed Microsoft on the pages of privacy violators, so she both endorsed and condemned them in the same talk.
  • She talked to me after her talk and was quite friendly

The only thing I could criticize about her talk specifically was her slide about the VA data thefts. She had put a WorldVistA logo on the top of the page, but the data breaches were a problem within the VA, and had nothing to do with WorldVistA. WorldVistA is a private organization that shares an interest in VistA with the VA, but otherwise is not connected with the VA at all, and certainly had nothing to do with the data breaches. In fact WorldVistA has and will continue to improve the overall privacy and security of private installations of VistA. Still, I am probably the only person in the crowd who even noticed this, and I doubt anyone thinks negatively about WorldVistA as the result of her talk.

In short, Dr. Peel is probably going to address the bulk of my complaints. She may have been planning to for months before I said anything.

So this is not a retraction of my attacks against her, but rather a reprieve. (When someone turns around like this a reprieve from criticism is popular within our community). If she continues on this path, I will fully retract my criticisms towards her personally.

Also note, that despite the fact that HealthVault has surprised me recently, it has NOT earned a reprieve yet. That may happen in a following post. There seem to be some changes in the privacy policy, and there has been some movement towards open-ness. HealthVault has invited me to engage them in person and I plan to do that before the conference is over. I am hopeful.


HealthVault: becoming un-Microsoft?

What I have read this morning almost made me choke on my cheerios.

Neil Versel (one of the most in-the-loop Health IT journalist I know) turned me on to a blog post from Sean Nolan, that I obviously did not want to miss. The post, aptly titled Opening up the Vault revealed several important claims:

  • Microsoft is releasing a Java wrapper library under the OSI approved Microsoft Public License
  • Microsoft is releasing some .NET code under a read-only license (i.e. not open source)
  • Most importantly Microsoft is releasing the entire HealtVault XML interface specification under the Microsoft Open Specification Promise

I need to research the Microsoft Open Specification Promise, to say the least it appears that there is some confusion as to its legitimacy for FOSS developers. I have “call” into the Software Freedom Law Center, to see what their current evaluation of the promise is. Still the significance of this cannot be underestimated. Sean claims:

“With this information, developers will be able to reimplement the HealthVault service and run their own versions of the system.”

Don’t get me wrong, I trust Microsoft about as far as I can throw them (all of them… at once), but this is definitely a step in the right direction. It will take me some time to sort out just how meaningful a step.

This is a smart time to do this too. There is like a 90% probability that Google will be officially announcing its PHR effort at HIMSS. (Heck its been leaked already) By releasing an API, Microsoft is essentially challenging Google to do the same, and that could mean that hacktivists like myself could build arbitrary bridges between the two (now this is hopeful…) which would mean that Google and Microsoft’s systems would compete on merit rather than most-effective-lock-in.


HealthVault: Michael Zimmer digs deeper

Michael Zimmer, a new media commentator and blogger, that I had not heard of before now has gotten access to the HealthVault team. He just wrote a new post called “Designing for Privacy: Microsoft HealthVault” that is worth reading from start to finish.

There are several interesting things about his post. First, he details several specific technical measures that Microsoft claims that they will be undertaking in order to protect the privacy of its users. Here is a brief summary, and my impressions:

  • HealthVault will use HTTPS only : Pretty obvious first step.
  • “Bluntly targeted” ads : What does this mean? Whatever Microsoft wants it to.
  • HealthVault tracking cookie will expire with each session or 90 days : This is probably the most exciting point here, since we can test this.
  • HealthVault will destroy search history after 90 days : Bold Claim. It would be great if this was true.
  • HealthVault will submit to audits : By whom? Again, this means little without being able to gauge the neutrality of the auditors, or to what standard they would be auditing.
  • HealthVault will allow “apps” to access data, but will show users a log of exactly what apps or people accessed the data : This seems like a good idea, but I am dubious to see if this can remain useful. A potential deluge of access means that users will cease to pay attention.

Michael obviously has at least a clue about the concepts of privacy and security. At least he uses terms like “https” and “cookies” in relevant ways. It is ironic that Michael gives the following caveat

“I must note that I haven’t been able to verify these technical claims, and my research in this area is only beginning — many other harms could remain even if all the above are fully implemented.”

That is the kind of thing technical people say when they know they do not have the full story. Compare this to the response that Dr. Deborah Peel has, to what was probably the similar technical information:

“Microsoft is setting an industry standard for privacy”

I like Michaels conservative approach to these kinds of claims. It should be noted that he has ties to Micorsoft, he is the Microsoft Fellow at the Information Society Project at Yale Law School. His association with Microsoft explains how he got access. I hope he continues to use that access to generate similarly good posts.

Probably the most important thing we have now is some objective technical standards that we can watch. If anyone feels like testing out the HealthVault cookie content and expiration to see if it squares with what Michael was told, give me a buzz. I would be happy to post or link to your results.