PHRs are much like the tides, news about them ebbs and flows. Right now, with the relatively recent demise of Google Health, Dossia’s attempts at rebirth, and the significant inquiries we are receiving regarding meaningful use requirements to host a PHR (patient portal). But in and amongst all this Chilmark has heard on more than one occasion the following statement: “The problem with PHRs is that they are a technology in search of a market.”
This statement is simply wrong for the following reasons:
1) As we have said countless times before in previous posts, very few people are interested in a digital filing cabinet for their health records. Unfortunately, many PHRs in the market today are just that, digital filing cabinets. In this case it is not an issue of a technology in search of a market, it is just a bad product that really has no market.
2) Technology adoption does not occur for its own sake, it occurs when there is perceived value by the user that leads to adoption. PHRs, PHPs (personal health platforms), patient portals, etc., is certainly a technology, that when well-designed, and implemented can deliver significant value and subsequently see high adoption rates. Just look to Kaiser-Permanente’s instance of MyChart, where patient adoption is well over 40%. Up in the Pacific Northwest, the Group Health Collaborative (GHC) is seeing PHR adoption that is well over 50%. That’s a market!
This is another in the numerous “death of Google Health” stories that have been appearing since Friday when the Google blog announced the pulling of the plug. I must admit to being more than a little pissed off with Larry Page or whomever it was within Google that made the decision. After all, Google Health was only introduced a tad more than 3 years ago (premiered at HIMSS in Feb 2008; launched officially later that year). And just nine months ago they hired a new product manager and debuted some interesting new features connecting to the new wave of personal sensors. I know that Wall Street has been telling Google to focus on fewer products and that Page as new CEO has decided to do that but for a company as rich as Google the effort involved in keeping Google Health alive would be trivial. And props here to our friends at Microsoft who are integrating HealthVault into their wider health care business.
The sunsetting of Google Health has meant an outpouring of articles from the factual (Deb Linton at Health 2.0 News), to the historical (John Moore at Chilmark) to the winners/losers assessment (Fred Trotter) to the mega-quotes including mine (Marshall Kirkpatrick at ReadWriteWeb). There’s also been a steady stream of both sad and (sadly) happy people commenting on the Society for Participatory Medicine listserv, and Mr HISTalk was his cynical self–basically saying that tech know-nothings should stay out of our complicated health care business. He’s wrong and now Google is wrong, and here’s why.
With the very notable exception of HealthVault and (hopefully) some new innovation from Dossia, we are now dependent on a number of small companies to maintain the emerging data utility layer. The data utility layer in health is the place that is going to collectively store all the data that is being generated. Apparently Google didn’t have the real patience for two rapid developments.
First, with a combination of the Direct Project and the stipulation in the meaningful use regulations that EHR users share data with other providers and with patients, individuals are going to find that more and more data about themselves is available and easily accessible. Whether or not it’s a Farmville-type hit, the ability to capture all that information in one place is very important. Currently it’s also very time consuming to put together so very few people do it. But I do know of instances where people have laboriously entered lab values into Google Health just to store them. Sooner rather than later that data will be available much more easily in machine readable format, and as those barriers to use fall so the desire to look at that data will increase.