The martyr: Google Health
Primary Cause of Demise: Human/Organizational factors such as ‘Control (and fear of loss) of patient Data’ the main cause of Google health’s early death (and of many other HIT products)
The Big Announcement: Google Health to shut down
Over the last few days there has been considerable discussion in the blogosphere (John Chillmark [John, always good to hear your opinion] , at Techcrunch [where the usual 'failure of the reimbursement model' was held as the culprit]) about Google’s Announcement to shut down Google Health. And we have even seen emails in list serves, lamenting that this signifies the death of PHRs themselves.
We at TrialX too were saddened by this development, particularly because the genesis of TrialX goes back to a Google Hackathon and ultimately to launching the first clinical trial matching application built on a PHR; on Google Health initially, followed by Microsoft HealthVault, and then Indivo. Read our resident informatics guru, Dr. Patel’s post reminiscing the early days). Yes, that was the summer of code in 2008 when we began as a “fired-up, ready to go” startup with heady visions of a consumer-driven health information economy (lest you think otherwise, we still have the same headiness)
Fast forward three years and we are dissecting and diagnosing the death of Google Health. However, i am convinced that this is no way a death for PHRs. In fact, one can contend that this is just the kind of sacrifice and martyrdom that signifies a true revolution. The PHR revolution is alive. And i dont mean the “closed” tethered PHRs that are being made available by hospital and other healthcare organizations. But first lets get to understanding, how we believe, Google Health got killed.
Back to the Genesis:
To really understand why Google Health is shutting down , we need go back and understand the two fundamental aspects in the health information economy that Google Health and Microsoft HealthVault tried to address in their PHR platforms (and ecosystem) in the first place. Because the real reasons, as we strongly believe, lie in there.
Now, just to be clear, Google Health and HealthVault neither invented the concept of PHRs nor were the first to launch a PHR. They came in fact much later. But sure they came bringing along very innovative thinking of how to utilize this technology for putting patients in control of their data. There have been dozens of PHRs before GH and MHV and many exist even now, mostly tied (tethered) to vendor’s Electronic Health Record (EHR) system, as a half-hearted attempt to really satisfy the meaningful use criteria stipulated by the federal government (which in its capacity has itself produced a shallow effort to put patients in control).
So what was refreshingly different about the Google Health (GH) and Microsoft HealthVault (MHV) PHR Platforms?
Both GH and MHV addressed two major barriers in making PHRs successful by
1) Enabling consumers to easily obtain their health data across different organization with the click of a few buttons. Now existing PHRs can do the same, that iswhen you login, they show you parts of your records like diagnosis,laboratory values etc. But the big difference being that these PHRs were tied to a single provider organization. For example, if you went to hospital X, they may (and in the future are required to) provide you access to your health record online. But that system would only show you the data from that hospital X.
With GH and MHV, you could import your health records from any number of healthcare providers and hospitals, provided these entities were hooked in the backend with GH and MHV (more on that later in a bit). This was truly about being able to “get your data out from the control of your provider organization”.
Reading this you may have guessed by now that the GH and MHV models sound similar to say a consumer signing up on Mint.com and syncing their Mint.com with their different bank account (say both Chase and Bank of America) in just a few clicks.
2) Both GH and MHV also addressed the issue of data control and privacy by letting the patients decide if they wanted to import their records in the first place and who they wanted to share their record with once imported. The beauty of the whole process was that unless the patient actively and willingly pulled their data into the GH and MHV systems, the data would not be transferred from the hospital system to Google and Microsoft (a point that many people i have interacted with didn’t understand or know and thus misjudged the privacy implications). And because GH and MHV model was built around patients voluntarily pulling their data into their online accounts, the (dreaded) HIPAA rules didn’t apply to these PHR platforms.Figure 1. explains how the Google Health and Microsoft HealthVault Model works (this appeared in our paper for the ACRP’s Monitor in August 2010)
Morever, the two platforms provided consumers granular controls to decide who they wanted to share their record with and exactly control what part of the record to share with. For example you could chose to share your meds and labs with say your primary care doctor but only your meds with say a friend. MHV provided control at each data element level.
Google Health and Microsoft HealthVault went even beyond #1 and #2. They did something even more transformative. And that goes to point #3.
3) Both GH and MHV actually built their PHRs as a platform that allows third-party application builders to build applications that can let consumers do something useful with their health record
Yes John, you are write when you said ” Few consumers are interested in a digital filing cabinet for their records. What they are interested in is what that data can do for them. Can it help them better manage their health?” The is precisely what we have learnt giving patient dumbed down PHRs that just regurgitate part of their medical records. Barring a few successes like with Kaiser’s PHR (and there are reasons why Kaiser succeeded, but that is a different post) , most such efforts failed to entice patients. Precisely because such PHRs were closed to the innovation of a world of developers that could have built the killer apps for consumers.
The fact that GH and MHV allowed developers to build on top of the PHR platform was a killer (see Figure 1). This is why we at TrialX have been so excited about GH and MHV – they were the first solution even in the HIT landscape that brought in the same engineering and software design that Facebook and later iPhone brought with their platform – open the innovation to hundreds of thousands of app developers than build the apps themselves. It can be envisioned that patients may want to use their record for a variety of purposes. For instance, patients may add an application that provides them reminders for different vaccines or preventive screening tests based on their health profiles, or one that helps them find clinical trials that match their health profile and express an interest in enrolling in them. The latter usage scenario can create a new scale of data liquidity, by moving information from hundreds of hospital clinical databases into PHR platforms and into applications that match patients to clinical trials (Steps 2 and 3, Figure 2).
How many of you genuinely believe that Facebook could have made a Farmville. Or that Steve Jobs would have demoed ‘Tap Tap’ in his keynote speech as ann app built by apple. No. It would neve have happened. They knew the platform had to be built by the developers outside their com pany. And so did Google Health and Microsoft HealthVault
This was indeed a giant step because the entire HIT industry have lived on by building closed system and failed to to see the potential for transformative change if they only allowed their EHR/PHR system to allow plug and play third-party applications.
In fact this was the promise of PHR – the unprecedented liquidity of information that would unfold if only the millions of patients records currently locked in siloed hospitals systems, could be pulled in with the click of a button by voluntary action of patients. The launch of paradigm changing Google Health and Microsoft HealthVault platforms could have possible been this “tectonic shift” , as Mandl and Kohane wrote in their seminal article in the NEJM in 2008 describing the liquidity of information that could happen if patients were giving access to their data and were given simple controls to share it with anyone they liked (with hospitals no more serving to act as gatekeepers or guardians of patients “protected” health information).
In short combining #1, #2 and #3, the new PHR platforms represented a paradigm shift in how consumers were given the control to obtain their health information, share it and use it (Figure 1). This was a new model for the entire HIT industry – and one which should have been embraced with open arms by the healthcare provider organizations. But as you will read on, it didnt (or hasnt happened as of yet) effectively killing Google Health. Many a revolutionary ideas and pioneers have been martyred. Is Google health the martyr of the PHR revolution? But i will come to that in a bit. Because we still have one more aspect of the PHR to talk about because
So why did Google Health Get Killed (or rather die a Martyr) ?
In our view as a healthcare information technology company, and having observed the EHR/PHR landscape for some years, the reasons for Google health failure and often of many HIT startups/products is not technical but human/organizational reasons.
The reason why PHRs didn’t get mass adoption is because the provider organizations holding the patients electronic medical records, failed (refused perhaps) to integrate their EMR databases to either Healthvault and Google Health. Only a few hospitals like the Cleveland Clinic, Beth Israel in Boston and later NYP, did some integration with either Google Health or HealthVault. Now, you can ask any academic medical center or hospital administrator and most will acknowledge that PHRs are of value and patients should get access. However, they have been very reluctant to have a data pipeline with PHRs like GH or MHV. Such third-party systems are considered ‘OUT OF CONTROL’ or direct oversight. Forget pushing PHR data, many hospital IT DEPT heads we have either talked to or heard in conferences, will not let any patient data leave their firewalls!
And this issue of”Data ownership and control” (for a myriad of factors) is at the heart of the matter – the critical barrier that will always prevent PHRs like GH or MHV from being a success.
So the next question is, “Why are hospitals reluctant to hook up with the Google Health, Healthvault or a third-party system?”
1. Control of data - provider organizations, hospitals believe they own the patient record and that data is value. The thought of patients easily exporting their data in a third party system beyond their control invites many frowns and concerns such as
- Fear of lawsuits. This is almost palpable. Try this for yourself – next time you are in a hospital, try to get a copy of your actual record when admitted or after getting discharged. In fact all hospitals will forbid you to even look at the doctors notes in your record. To get copy can take weeks
- Concern of patient attrition – there is a pervasive concern that by easily making a patient’s record available, the hospital may lose the patient to another
- Fear of identification of errors in the record and embarrassment – the much talked about case highlighting this issue was with ePatient Dave who found several errors in the way diagnostics codes has been applied to his record when he imported his record using Google Health back in 2009 – within a day of two of the incident, the story was in the Boston Globe.
2. Inadequate policy directive - the biggest opportunity to ensure that patients data could be pushed out to third-party PHRs of their choosing was lost in the meaningful use stipulation – the meaningful use stipulation, though based on patient-centered care, missed the opportunity to specify that an organization must allow patients to export their data to any third party system of their choice, not just a glorified patient portal that many EHR vendors have been peddling through to meet their certification criteria. In fact both Google Health and HealthVault had commented on this during the open comments interval for meaningful use definition.
3. Lack of Proper incentives (a contributory factor though not necessarily the main reason as suggested in the TC article) – in the current model of reimbursements there is no incentive for a hospital to really share patient data with patients or other provider organizations. In fact by sharing data there is the concern that service utilization may drop, leading to less revenue (which is precisely one of the possible benefits of electronic data sharing)
4. Other factors for failure – John has written that the fact that Google implemented a much bastardized version of the continuity of care record, many hospitals were not keen on integrating with Google Health. It may have been a reason, though we feel a rather small one. There has also been mention that the interface to allow patients to enter data was probably not the easiest. Again, i feel these are small factors in the bigger scheme of things. I think data entry interfaces are moot if the system would have easily pulled in records from the back-end hospital databases in the first place. Plus in our experience, we have noted that most patients are not very familiar with their medical history (they may not even know the name of their medication). Yes, i think Google Health could have done more to attract the hospitals to integrate with them. Perhaps, Google Health was never a major initiative within the organization.
So where do we go from here?
I think the failure of Google Health was not a technical failure or a failure of a product consumers would not see value in. PHRs like Google Health can only succeed if they have more than a critical number of hospitals integrated with them so that a typical patient can import their records across 3-4 different providers very easily. It was and remains absolutely CRITICAL that hospitals and other providers organizations willingly support integration of their EMR data with third-party PHRs like GH and MHV. The old model of providing a closed PHR or patient portal will not suffice. Closed portals can only have so many applications that a patient will find useful. Just imagine, if your iPhone app store only had a like dozen applications designed by a few really “enterprise” like software companies. It wouldnt be very useful., It wouldnt be very cool. And it would be even more consumer unfriendly that you would have to login to 3 different PHRs being provided by three different provider organizations that you may have visited (one your local doctor PHR, a hospital and one say of your insurance company). All your data would remain fragmented and as a consumer you would have little incentive to make all the effort to use three systems.
It is still early in the days of the inevitable PHR revolution. The more hospitals and doctor office get digitized and there is pressure to make data available to patients, we will eventually realize that a third-party provider organization neutral PHR platform that allows useful apps to be developed by external developers, is the way to go. In healthcare, technology is not the issue. At the heart of the barriers to innovation like the age old human limitations – issues of control and fear.