Consultant’s Guide to Google Health – Part I of IV – An Architecture View

May 12, 2009 at 2:01 am 6 comments

As a technology consultant working in the health care industry, I decided to educate myself on Google Health.  Google Health is essentially a central hub where individual users can manage information about their health.  The industry calls this a Personal Health Record or PHR.  The documentation available from Google as of now is focused on end users or technical software developers.  There is some information for data providers (who would supply information to the Google Health platform), and service providers (who would leverage the platform).  While I found the available information extremely valuable, I felt there was an opportunity to present it in a way that would help those trying to apply it (such as healthcare and technology consultants).

Google is not alone in this endeavor, Microsoft’s HealthVault, and a host of other PHR vendors are participating in this space, but this series will focus on the Google Health platform, giving consultants a basic understanding of it, and discussing how it can be applied today.

This article is the first in a 4 part series where I plan to cover the following:

  • Part I (the remainder of this article) – An Architecture Overview: An overview of the services, standards, and interfaces that Google Health is comprised of.
  • Part II: A Functional View – A breakdown of the functionality currently being offered by Google Health and current partners.
  • Part III: A Technical Analysis – A technical walkthrough of the Google Health API in the terms of the functional and architectural views.
  • Part IV: Application of Google Health – A discussion of the opportunities to apply Google Health and build on the platform it provides.

As I discuss each of these topics I welcome your feedback and encourage you to share your ideas and experiences.

A quick disclaimer: To quote Vince Kuraitis:  “Let me be clear. I am not speaking for Google; I don’t work for Google. This posting is my collection of inferences drawn from the clues provided…” (in my case) by the Google Health API documentation.


Google Health Architecture Overview

The following is my view of how the services, standards, interfaces, and processes supported by Google Health are layered together based on my interpretation of Google’s documentation.

A layered view of the Google Health Architecture

A layered view of the Google Health Architecture


The main layers are as follows (I will be presenting them roughly in a “bottom-up” sequence):

  • Web Standards
  • Health Information Standards
  • Base Google API Services
  • Google Health (Data & Integration) Services
  • Health Data Providers
  • Third Party Services
  • Google Health Web User Interface
  • Business Processes
  • Personal Health Management Processes

In case anyone is not familiar with this type of architectural view, I am simply implying that Services (to use a general term) in one layer are dependent on the Services in the layer below. Also, Services adjacent to each other but in the same layer are related but distinct.  They share the same basic relationships to the layers above and below.

Web Standards

Google is depending on some technical standards that are part of the Web as a whole that were not developed by Google.


In addition to leveraging the familiar HTTP and XML standards for the basics of communication, The Google Data API also relies on some more advanced (think Web 2.0) standards in RSS and Atom to handle syndication (or distribution) and publishing. We will discuss this in detail in Part III – A Technical Analysis.


Health Standards

Standards pertaining to health care information technology are still emerging.  At this time, the only technical standard from the health care industry being implemented by Google Health is the CCR (Continuity of Care Record).


Google Health is currently only supporting a subset of the CCR standard, but this does cover a significant range of details about a user’s health and the care they receive such as test results, allergies, height and weight and much more.   We will discuss this in detail in Part II – A Functional View.


Base Google API

As mentioned above, the Google Health leverages the Google Data API.  It also leverages the Google Accounts API. 


In a nutshell, the Google Data API is a “a simple standard protocol for reading and writing data on the web”. 

The Accounts API provides two different basic modes of authentication.  Authentication for a web based application, and authentication for an installed client application.  There are two options for web based authentication: AuthSub and OAuth.  AuthSub has been in use longer, but the OAuth is meant to be an open standard.

The Google Data API is provided in the following programming languages for client development: Protocol, .Net, Java, Python, and PHP, Objective C*, and Javascript**Objective C and Javascript are ommitted from the diagram since the Google Health API does not support them.


Google Health (Data & Integration) Services

Leveraging the services and standards already described, the Google Health API provides it to main services… Health Data feeds and queries on those feeds. 


The Profile Feed provides access to the user’s health profile in a subset of the CCR standard.  Applications can send updates to the user’s health profile using the Register feed, as well as sending custom user alerts such as a prescription interaction warnings.

The Google Health API is provided in the following programming languages for client development: .Net, Java, Python*, and PHP*.  *Python and PHP are only supported at version 1.0 of the Google Health API.  .Net and Java are both supported at version 2.0.


Health Data Providers

Google is actively seeking to sign up partners to serve as data providers for Google Health.


The users will be able to import data into their Google Health profile from data providers such as pharmacies, healthcare payers, health care providers, and laboratories. 

NOTE:  Google is not covered by HIPAA, but these partners typically are hippa covered entities.


Third Party Services

Google already has third party service providers integrated with Google health including wellness programs, prescription drug research tools, personal health consultants, and direct to consumer laboratories.   


This seems to be an area where a lot of innovation will spring from with Google Health.  One interesting service already available is a service that can match Google Health users to clinical trials based on their health profile.  We will such innovations much more in Part IV – Application of Google Health.


Google Health Web User Interface

The Google Health platform obviously uses a web interface for users to manage their health information, as well as link their profile to data providers and third party services. 


Google integrates its powerful search engine to help users research their health conditions and medications, as well as find doctors. 

NOTE: Google asserts that search results using the regular search engine will NOT be influenced by the data in your health profile.

Again, we’ll discuss the user functionality in more detail in Part II.


Business Processes

This layer represents the business processes or business model for entities partnering with google health. 


As of now, Google does not charge partners or users to use the Google Health platform.  They claim the business model is basically to drive users towards advertisements in a standard google search.  No advertisements are displayed in Google Health at this time.

Organizations partnering with Google as data providers or services must have a business model in mind.  Patient outreach and cost reduction seem likely, but we’ll discuss this much more in Part IV – Application of Google Health.


Personal Health Management Processes

This layer represents the overall personal health managent processes that users of Google Health will achieve by using the system.


In Part IV – Application of Google Health, we’ll discuss how users can combine all the discrete functions offered by the web user interface as well as data providers and third party service providers in a comprehensive way to manage their health.



I hope the first part of this series was usefull for you. Again, I welcome your feedback and encourage you to share your ideas and experiences regarding Google Health.  Look for Part II – A functional View next week.



Entry filed under: Health Care IT, Personal Health Records. Tags: , , , .

National coverage of the Google Health and MS HealthVault

6 Comments Add your own

  • 1. Twitted by healthcareitjob  |  May 15, 2009 at 2:42 am

    […] This post was Twitted by healthcareitjob – […]

  • 2. GreenLeaves  |  May 16, 2009 at 10:16 pm

    I believe that ARRA has now expanded HIPAA obligations to the likes of Google and Microsoft.

    Looking forward to your next three articles.

  • 3. Saurabh  |  February 8, 2010 at 12:16 pm

    Hi ,

    I read your Part I and I am eager to see your next chapters but I can’t find it here.
    If I am searching in wrong direction plz let me know.

    • 4. Jason L. Stanis  |  February 8, 2010 at 12:40 pm

      Thanks for your interest.

      Since I posted this a lot of changes for me in 2009. Moved to a new city, started a new job, and my wife and I had a new baby. I hope to get back to this in the next month or so.


      • 5. Saurabh  |  February 11, 2010 at 4:30 pm


        Ohh thats great. Congrats for your baby and your new life.


  • 6. Sea Wolf  |  August 12, 2010 at 9:42 pm

    An excellent write up and congratulations on the new baby, new job and new city – that’s a lot of new in 1 year !


Leave a Reply to Jason L. Stanis Cancel reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed


May 2009

Most Recent Posts

%d bloggers like this: