Monday, September 6, 2010

The Red, White and Blue Buttons

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.


  1. Every time I see this announcement I keep hearing "Take the red pill or the blue pill," (just shows how my weird brain works). The problems of interoperability are one problem. My other question would be how easy to login and/or secure are these buttons? My bank allows two login attempts and then freezes the account, requiring a call to an 800 number to open it back up. Then there's the issue of people keeping up with yet another password.

    Of course these aren't issues with e-records per se, merely the ongoing issue of how to facilitate ease of use and security via an open platform like the Web.

  2. Funny, Michelle, I was thinking about little red pills too :-)

  3. You raise a very important point about standards...

  4. Honestly, Brian, I was quite surprised by the discrepancy.