Thursday, February 28, 2008

Cool Technology of the Week

As I've mentioned in my entries about personal health records and my recent Dispatch from HIMSS , 2008 is an important year for personal health records that are linked to clinical EHRs, employer sponsored, payer based, and commercially offered. Yesterday, Google publicly announced their Google Health application which is the Cool Technology of the Week. A disclosure - I did serve on the Google Health Advisory Council over the past year.

The concept behind Google Health is that patients login to the Google application using credentials that are secure but not trusted. This means that anyone can set up a Google Health profile, but there is no specific assertion of identity. I can claim I'm Bill Clinton if I want to.

Once in Google Health, I can manually add information about my problem lists, medication lists, allergies etc. and get decision support about my conditions. However, it's unlikely that many people will enter their data manually. A much more powerful approach is self populate the personal health record based on standards-based connections to hospitals, laboratories, clinics and pharmacies. Cleveland Clinic was the first partner to support this connection. Beth Israel Deaconess will be a part of the next group of connections.

To self populate the Google Health record, a patient who has a relationship to one of the Google interfaced providers, just clicks on the icon of their hospital. That icon offers up to 3 links. In the case of BIDMC, we'll offer

Upload your records
Make an Appointment
Securely Email your Clinicians

If a patient clicks on Upload your records, they will be asked to login to BIDMC's Personal Health Record, Patientsite, using the secure credentials that have been issued by their doctor, validating the patient's identity. Once they sign a consent, they will be given the option to initiate an upload of problems, medications, allergies and laboratories into Google Health. The patient initiates this transfer, with their consent, after understanding the risks and benefits of doing so. Once the data is in Google Health, the value to the consumer is expert decision support, disease information, and medication information based on the patient's data.

There have been several articles about the Google/Cleveland Clinic pilot and Microsoft Health Vault/Mayo pilot noting that none of the organizations have signed HIPAA business associate agreements with each other. The reason for this is that Google and Microsoft are not HIPAA covered entities or business associates. Their products are just secure storage containers used by the patient, like a flash drive. The patient can delete the data at any time, apply privacy flags, print the data, and add to the data. Since the patient is in total control, there are no covered entity or business associate issues.

As part of the Google Advisory Council, I can tell you that many thoughtful people worked on the legal, technical, and policy issues around data use. Google will not advertise based on this data, resell it, data mine it , or repurpose it in an way. These consumer centric policies are similiar to the best practices adopted by Microsoft Health Vault.

It's important to me that in my role as chair of the national standards effort, HITSP, that I support all the major personal health record initiatives with interoperability. I've committed to Microsoft that BIDMC will work with Health Vault. I've committed to Dossia that we'll link with their Indivo Health platform. It's my hope that all of these efforts will converge to use one plug and play standard for clinical content and transport. Once they do, patients will be able to select the personal health record of their choice based on features, not just data.


Doug said...


Can you comment about the Google/Microsoft approaches from a clinician's point of view. I can understand some of the value to patients (although that value is limited unless multiple sources can be uploaded and coordinated). However, I can't envision the use from a clinician's standpoint with concerns over the validity, currency and trusted source of the data. Thanks.

Anonymous said...

I know Bill Clinton, and you are no Bill Clinton (I am happy to say!)

John Halamka said...

A few thoughts on the value to clinicians

1. The patient will be able to combine data from many sources - hospitals, clinics, and pharmacies - to create a comprehensive medication list, which can be used for medication reconciliation. Since this reconciliation is a joint commission requirement, the clinicians will really benefit from having a multi-institutional consolidated medication list

2. Our experience with PHRs is that better communication leads to less malpractice assertions. Using a PHR to keep the patient informed and education about their health could reduce legal expenses and time for clinicians

3. Finally, it's important to know that patients can control the flow of information using Google/Microsoft tools, but cannot alter information provided by a lab/pharmacy/doctor etc. Thus, they can keep their medications private but cannot change the dose of a medication history record provided by a pharmacy.

Benjamin Wright said...

John: The World Privacy Forum argues that because Google and Microsoft are not HIPAA "covered entities", the legal privacy available for the records they manage is less. I believe WPF overstates the problem. The law of privacy affords patients (and records managers like Google) many options. For example, to address the privacy fears associated with Google health records, patients might directly embed legal terms and conditions in their records.

Chris Scarboro said...

I listened to Eric Schmidt’s talk Thursday morning and saw the demo at the Google booth Tuesday at HIMSS. The technology looks great even though you can tell the product isnt quite ready for “prime time” – it crashed during the demo we witnessed.

Is the goal to eventually allow for the uploading of diagnostic images from sources such as PACS? That’s a tremendous amount of potential storage, which leads to the question of ‘what’s in it’ for Google, considering Schmidt stated Google would not advertise on the site or charge for the service.

Overall, I was extremely excited about the potential of the technology, and hope this will increase the continued path towards truly interoperable system standards. I noticed the initial pilots are scheduled for extremely large institutions. I’d be interested to see some testing in more rural areas to study the rate of adoption and the potential benefits provided in less progressive communities.

Chris Scarboro said...
This comment has been removed by the author.
Jen S McCabe said...

John - I'd certainly find this useful. I'm ready to participate in a trial as soon as it's available to consumers.

Excellent post that makes some relevant connections no one else is mentioning - the ability to enhance med compliance and help prevent interactions as per JCAHO Patient Safety Goals, for instance.

Unknown said...

To ensure the Privacy & Security of Personal Health Information, why not use a variation of theme of FIPS-201 and use a Biometric Authentication model?

The technology is available and affordable. Once my biometric ID is linked to my personal health record (Google / MS / EPIC et al) there will be no doubt WHO-is-WHO.

Add a MoC smart card appliance to the mix with EMV capabilities and viola!

No Fuss, No Muss, No Mas.


Anonymous said...

I am ready to drink the Kool-Aid. How do I get in the queue to connect my 2M patients?

Will Weider
Ministry Health Care

Rennasauce said...

From a privacy and security perspective, if Microsoft or Google were to suffer a breach - and end users potentially lose personally identifiable information, is there any requirement for the companies to disclose the breach? (I understand that the rules of HIPAA do not apply here.)

Unknown said...

For an insightful read and to better understand Privacy & Security Issues surrounding PHR's and where HIPAA comes into play, you might ping over to the World Privacy Forum ---->

Original publication February 20, 2008 at
Document URL:

Benjamin Wright said...

Rennasauce asked: >>if Microsoft or Google were to suffer a breach - and end users potentially lose personally identifiable information, is there any requirement for the companies to disclose the breach? <<

Some states do require that patients get notice of certain data security breaches. Also, patients might embed legal terms in their records that require service providers to give notice of security breaches. [This idea is not legal advice, just something to think about.]

Johnnysmooth said...

Good post John to see how BIDMC plans to work with these large consumer focused entities.

But what I would like to know is how will it be done. When I spoke to Google at HIMSS, they told they are developing a specific API into Cleveland's EPIC patient portal, is that what you will need to work out as well with Google, a custom API? This hardly seems scalable.

As for Microsoft, are you adopting their SDK/published APIs so consumer data can flow from PatientSite into their HealthVault account?

Any thoughts on this is most appreciated. As an aside, I'm an industry analyst presently doing research on the PHR market and publish over at

David said...

I enjoy the blog, and this entry in particular. Reading between the lines, and seeing some other articles, I became concerned about what is entailed to connect to GoogleHealth, HealthVault, Dossia, etc. You expressed hope that they will converge on common standards, but that seemed to imply that they have already started out with divergent approaches, and that there is a need to "converge" which can prove difficult. Why not get all parties to the table to agree to use common standards now, before lots of non-interoperable PHRs come into existence? While this is free enterprise, can't national initiatives like AHIC or HITSP be leveraged to do this?

Anonymous said...

Really a great work. We have to appreciate the author who has given us such clear details.


Anonymous said...