Consultant’s Guide to Google Health – Part I of IV – An Architecture View
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.
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.
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.
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.
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 TrialX.org 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.
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.