Entries in google (2)

Tuesday
Jun282011

Google Health Post-Mortem

Last Friday, June 24, Google announced that it will shut down Google Health, which had become a much-hyped platform within the health IT community for storing one’s personal health and wellness data. Outside of the health IT community, Google Health made little impact.  I have read at least a dozen other articles that dissect the technical reasons and health IT insider viewpoints on why Google Health failed.  I’d like to discuss the reasons why Google Health never gained traction within Google.

I’ve followed Google from the very early days when they burst on the scene as a new search engine when nobody thought we needed a new search engine.  Google transformed search by using an algorithmic approach to identify the most relevant results.  Among the three key factors that differentiated Google from the pack were 1) algorithms that ranked pages based on popularity (Page Rank) and 2) scale: the larger the collection of sites that were crawled, the better the results (at the time circa 2000).  Since its introduction, Google’s algorithms have changed many times, but the fundamental fact that Google prefers to depend on programmable solutions that don’t require human intervention remains constant.  And, Google continues to chase large-scale opportunities where it can become an essential layer of the infrastructure.

Factor 3) is the business model. Remember the early 2000s when we all wondered how Google would make money?  After Yahoo acquired Overture in 2003, the revenue model was decided.  Keyword-driven advertising became the preferred method to monetize traffic on the popular search engine sites and scale matters in this model.    

With these three key factors in mind: algorithms not people, scale, and an advertising-driven revenue model, let’s consider why Google Health was destined for failure.

Google has done an excellent job of staying ahead in the “scale” category.  Google loves large repositories of data that it can monetize via advertising.  Google Books is an example. Once the legal hurdles have been worked out, Google Books will run without much human intervention –and has the bonus of providing an e-commerce revenue stream along with an advertising revenue stream.

Where Google got into some early trouble with Google Books was they wanted to side-step the hard work involved in working out agreements with publishers, so they did a deal with AAP and the Writers Guild that required authors and publishers to opt-out and take action if they wanted to set their own pricing terms.  When it came to orphan works, Google would be the presumptive copyright owner if the rightful owner couldn’t be located. So far, Google Books fits with the scale and business model elements. But, Google Books required a heavy initial investment in scanning books.  That certainly requires significant human effort, but Google was able to hire inexpensive labor and only older books needed to be scanned.  Newer books are available in electronic form, so once the initial investment is completed, the humans that place the books on the scanners will no longer be necessary. 

With Google Health I have to agree with Kent Bottles who wrote that Google found the degree of complexity in healthcare too great because it required too much specialized conversion programming and relationship-building with multiple stakeholders.  This variability that cannot be easily managed algorithmically is beyond Google’s chosen core competencies.

With respect to revenue models, Google said they would never put ads around PHR data in Google Health.  I think I still have a copy of the initial terms and conditions that stated that Google planned to monetize Google Health through data-mining aggregated patient data and then presumably selling the results to interested parties, with Pharma undoubtedly at the top of the list. In order for the mined data to be useful, scale and consistency of content types and formats would be necessary.  The revenue models could include keyword and display ads or content sales.

So, in effect, Google Health fell short on all three factors: scale, ability to use an algorithmic approach to content management and search, and revenue model.  Yes, health represents over 17% of our economy, so scale was still a possibility, but rate of adoption was slow—and was named as the primary reason for discontinuing the service.  Google will continue to reap benefits of health care searches via its advertising programs on its existing online and mobile search engines, but a Google Health product that was defined as a personal health data repository just doesn’t represent a big enough opportunity for Google. 

Like most of the healthcare publishing and health IT community, I was excited when I first heard that Google was establishing a health group.  Note, I first wrote about Google Health in 2006 when Google Health was envisioned as part of the Google Co-op program that had a crowdsourced model that encouraged publishers and subject matter experts to tag healthcare information.  Google Health took several turns during its short lifetime and who knows, it could come back in five or ten years once the healthcare industry grows up to resemble the financial services industry where the majority of customers log on to their computers to manage their accounts.  But, even then, its business model will have to measure up to Google’s broad business objectives for it to have any chance of succeeding.

Thursday
Apr162009

Google Health: PHRs Still Need Human Touch

Google has been very good at establishing a broad-based platform for search and search advertising.  However, they’ve always taken a “hands-off” approach when it comes to content.  Google doesn’t get involved in the dirty work of “data cleansing”, especially when it requires domain-specific knowledge and human intervention. Instead, Google focuses its resources where they can rely on existing metadata to fuel their engineering powerhouse. 

Therein lies the problem that came to light this week when the Boston Globe ran an article that detailed the experience of e-Patient Dave (Dave deBronkart) in transferring his medical record info from Boston’s Beth Israel  Deaconess Medical Center (BIDMC) hospital to Google Health, the highly anticipated personal health record (PHR) utility from Google.  Dave described in the Globe article and on the E-Patient.net blog some of the unacceptable outcomes that occurred when Google inferred information from content that was imported into his Google Health PHR from electronic records at BIDMC.   For instance, dates did not accompany most of the information, so Google Health issued alerts that assumed all of the conditions and meds listed in his record were occurring simultaneously. 

 

The article also highlights serious flaws in using medical billing codes to infer information about medical conditions.  E-Patient Dave delves more deeply into the medical coding issue on his blog and offers a good round-up of the various codes used by medical providers.  These billing codes are imperfect for their primary purpose; using them as the primary metadata to infer a patient’s medical history is a fatal flaw.

So, should we conclude that Google Health is a DOA as some have suggested?  Not necessarily.  But, I think it may be fair to say that Google Health isn’t ready for the average patient/consumer and won’t be until more progress is made in harmonizing the codes and terminology used by various stakeholders in the healthcare economy. 

One conclusion is clear:  given the current stage of development of PHRs, there are opportunities for content intermediaries in healthcare to solve some of the data inconsistency problems.  One new company,  Zweena Health, added its voice to the Google Health bashing to promote its own service that creates PHRs for individuals.  According to their site, they “do all the work” to convert information from providers into a usable information resource. 

Traditional healthcare publishers represent another group that is well-positioned to help solve the data translation and transfer problem for patient records.  Healthcare publishers like Elsevier, ThomsonReuters, and Wolters Kluwer have been combining content with technology to create clinical and workflow tools for years.  Their expertise in understanding content, technology and workflow of healthcare professionals should be included in efforts to develop electronic records for providers and patients.

Finally, medical librarians have expertise and hands-on experience in translating medical information for consumer audiences.  Perhaps it is time for Google to fund medical librarians to take on the work of creating taxonomies and harmonization schemes that would better serve multiple stakeholders.  I’ll forward this post to David Rothman and other medical librarians who blog to get their feedback.

One final thought.  Google likes to aim high and target projects that reach large numbers of people where Google can add value through low-touch high-tech projects that leverage their computing and coding resources.   In the case of digital health records, perhaps Google should take the approach that CMS has used and tackle a smaller piece of the puzzle first, starting with drug information.  Digital drug databases have evolved to a state where they are more reliable and CMS is advancing e-prescribing by providers through financial incentives and promotions.   This week’s announcement that Express Scripts is acquiring Wellpoint’s NextRx pharmacy benefits management (PBM) unit for $4.68 billion is another sign of progress in this arena.  The market apparently approves of the acquisition:  Express Scripts’ stock price has risen since the announcement and has been upgraded to a buy by UBS.

As we wrote last month on the subject of health IT, it is imperative that architects of the health IT software systems understand the content that will flow through their systems and how it will be used.   The same imperative applies to developers of PHR software and tools to an even greater extent, because of the need to translate or explain medical terminology for consumer audiences.