Google Pitches Wave For Health Records

Wave's auditable multi-user collaboration turns out to be well-suited for health records, as long as patients don't mind a bit less privacy.

Google Wave, envisioned as a reinvention of e-mail, is not likely to replace e-mail anytime soon. But Google may have found a use for its real-time communications platform beyond puzzling people.

Wave it seems is good for your health records. That's what some Google engineers intend to argue at USENIX HealthSec '10, part of the 19th USENIX Security Symposium, which runs from August 11-13, 2010.


More Healthcare Insights

White Papers

More >>

Reports

More >>

Webcasts

More >>

In a paper to be presented at the conference, Google engineers Shirley Gaw and Umesh Shankar observe that aggregating health records from multiple sources, and merging that data in a way that maintains coherence and attribution while supporting the capacity to make corrections, isn't easy.

Current standards for medical health records -- Continuity of Care Record (CCR) and Continuity of Care Document (CCD) -- aren't intended as living documents, the co-authors claim. They're snapshots of clinical data, often without information that describes how changes in a patient's health should be interpreted over time.

"CCR and CCD are byproducts of walled gardens of care, where all inputs to the system came from the inside and were made by users authenticating to the same system," write Gaw and Shankar. "They do not match the more dynamic, messy, and distributed nature of aggregation---but this is precisely what end users, patients, actually want. And unfortunately this issue is not solved by the technology sector’s currently used protocols, such as REST-style (Google Health) and Database-style (Microsoft HealthVault) APIs in use."

That's where Google's Wave federation protocol comes in. It was designed for aggregating data and resolving data conflicts in a way that can be audited.

"It's built from the ground up to collate multiple sources into a coherent whole," the co-authors state.

The Google Wave federation protocol, the open source code that allows Wave servers from different organizations to interoperate, is designed to present sequential updates from multiple sources in a format suitable for distributed medical record keeping.

Distributed medical records are useful because they allow providers and patients to correct medical errors. At the same time, democratized access represents a potential source of liability for health care organizations if it's not clear how a patent's record got changed.

Gaw and Shankar argue that basing a distributed health records system on the Wave federation protocol provides the audit trail and controls necessary to make such a system work.

There's a price to adopting this approach however: privacy.

Gaw and Shankar argue that increased transparency, with providers being able to edit and see each other's data -- the patient's entire history -- is not a bug but a feature. They suggest health care providers offering second opinions or follow-up examinations could update earlier diagnoses, which presumably would contribute to a better clinical outcome.

As for fears that greater health record transparency -- which could also be phrased "diminished health record privacy" -- might enable insurance companies to discriminate against certain patients, Gaw and Shankar conclude such concerns have been "mitigated by the recent health reform bill."

InformationWeek has published an in-depth report on this year's Healthcare Information and Management Systems Society conference. This report offers the best healthcare IT advice, insight, and analysis coming out of that conference. Download the report here (registration required).

Related Reading




Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

InformationWeek encourages readers to engage in spirited, healthy debate, including taking us to task. However, InformationWeek moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. InformationWeek further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
T-Shirt Giveaway T-Shirt Giveaway: Each week we're selecting one great comment from our readers. The author of the comment will receive an InformaitonWeek Community t-shirt. So get posting!
Subscribe to RSS

Resource Links