The Health 2.0 Developer Challenge announced more details this week on its Blue Button Challenge, including the recruitment of Craig Newmark as a judge. The challenge comes from Markle Foundation & the Robert Wood Johnson Foundation, and it’s looking for solutions that will best use that new data source and make it meaningful for consumers. In the post below, Margalit gives a few hints as to what she’d like to see!–Matthew

By MARGALIT GUR-ARIE

On August 3rd President Obama announced the advent of a new button: The
Blue Button. The Blue Button is a health data download button. Consumers
can presumably click on the Blue Button and their medical records will
then commence downloading to their computer (securely, of course).
Anybody can get a complete medical record on demand; with no delays from
the busy medical records department and no special fees and no rims and
rims of paper records to carry around. Sounds like an awesome step
forward for medical records portability.

The Centers for Medicare & Medicaid Services (CMS) will make Blue Buttons available for Medicare beneficiaries and so is the Veterans Administration (VA). The Markle Foundation issued a policy paper and a challenge to developers to do something meaningful with the Blue Button data (in partnership
with Health 2.0). Crunching the numbers yields about 30% of us with full
electronic access to our medical records by virtue of a Blue Button.
This is all very exciting and definitely warrants a closer look.

The VA delivers health care and it has an EHR (VistA) and gigantic
amounts of electronic medical records to share. The VA also has a
website, My HealtheVet, where
members can access their latest medical records, view benefits and
perform simple transactions, such as requesting meds refills and
updating information. My HealtheVet, which is truly a PHR, will now be
sporting a Blue Button, so members can download their electronic medical
records in ASCII text format. The VA has a sample download file and it looks very useful.

CMS, on the other hand, is basically a payer. CMS will be adding the
Blue Button to their member portal, MyMedicare, where claim data will be
available for download and also, what seems to be, Self Entered
clinical data. Presumably Medicare beneficiaries will update their
clinical histories and then push the button to download the file,
also in ASCII text format. Unlike the VA, CMS is not quite ready to
allow beneficiaries to download this data to their own computers, but
prefers that the data is transferred to a commercial PHR instead (e.g.
Google Health, Microsoft Health Vault). Why CMS thinks beneficiaries
cannot be trusted with their own data, while commercial PHRs can, or how
they propose to prevent consumers from keeping copies of their own
data, is a bit unclear to me at this point, but CMS “may be conducting a project called “the BlueButton”” to test the concept. As we all know, CMS is very good at pilot projects, so we will probably learn more in time.

The Blue Button is a step in the right direction, but immediately
exposes one big problem, a problem that has plagued health care
informatics from the start. The VA Blue Button and the CMS Blue Button
are creating incompatible text files. There is no common standard for
the downloadable information.  Fields have different names (e.g. DOB vs.
Date of Birth) and different definitions (e.g. First Name, Last Name
vs. Full Name) and objects (e.g. Allergies, Problems) have different
subfields. If you compare the VA file and the CMS file, you would be
hard pressed to guess that their intended use is identical. Any
commercial PHR interested in receiving and incorporating Blue Button
files will have to write two separate sets of software to process both
VA and CMS files. If private EHRs and payers start adding Blue Buttons
to their portals, each providing different information in different
formats, we will end up with yet another bewildering array of
incompatible data. Shouldn’t the parent “company” of both the VA and CMS
(the Federal Government) have defined a Blue Button standard first?

While the Feds work out the Blue Button kinks, I would like to suggest
two other buttons that may be even more beneficial than the Blue one,
and together will make quite a patriotic splash on any website.

The White Button, so named for those wearing white coats while at
work, should allow a physician to get all records for the patient in
front of her/him with one click of the White Button. We have the
beginnings of a White Button in the form of the, almost complete,
medication list that can be obtained in real time from Surescripts.
We should build on that concept, which interestingly enough, evolved
without the support of massive infrastructure financed by Federal
stimulus money. It just made good business sense and it works like a
charm.

The Red Button, which will hopefully be used less and less as
technology improves, should allow any clinician and any patient who uses
health care technology to report safety issues to the FDA, from within
the software, and as they occur. Much has been written lately on the
need for physicians and hospitals to admit errors, apologize and learn
from mistakes. We want to measure quality of physicians’ work and pay
them according to outcomes. The same logic should apply to EHR vendors.
The Red Button will be our quality measurement tool and should be viewed
by HIT vendors as a learning tool as well.

Pay 4 Performance is a two way street.

Appropriately, the day when EHRs routinely come with Red, White and Blue
Buttons will be the day we will know that HIT victory has been
achieved.

Margalit Gur-Arie blogs frequently at her website, On Healthcare Technology. She was COO at GenesysMD (Purkinje), an HIT company focusing on web based EHR/PMS and billing services for physicians. Prior to GenesysMD, Margalit was Director of Product Management at Essence/Purkinje and HIT Consultant for SSM Healthcare, a large non-profit hospital organization.