The Red, White and Blue Buttons

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

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

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

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.

Spread the love

17 replies »

  1. Great beat ! I would like to apprentice while you amend your site, how can i subscribe for a blog site? The account helped me a acceptable deal. I had been tiny bit familiar of this your broadcast offered brilliant clear concept

  2. I recommend the Just5 cell phone when speaking of a medical alert system. This is what my grandma is using for her emergency needs. This is a great phone that has PERS features including automatic dialing, alarm, and loudspeaker. All these features can be activated in a press of a button. I found this phone at http://www.just5.com.

  3. Thank you, Margalit. This is a very interesting discussion, around a well written article.
    We at Qoppa Software are participating in the AIIM PDF/H committee, authors of PDF Healthcare, a BPG (Best Practices Guide) with an IG (Implementation Guide). The BPG and IG describe little known attributes of the Portable Document Format (PDF, a global, open standard since July 1, 2008; ISO 32000-1:2008) —freely viewable on almost every laptop/desktop around the world— to facilitate the capture, exchange, preservation and protection of healthcare information.
    Because PDF is well-known and widely accepted, PDF Healthcare complements the CCR, CDA, CCD or other existing healthcare interoperability standards. In addition, it stores and exchanges health information prior to – or in lieu of – deploying, for example, complex EHR exchange platform applications.
    Further information and links to the actual BPG and IG can be seen by visiting the article I’ve just quoted: http://www.aiim.org/healthcare/infonomics/what-is-pdf-healthcare.aspx.

  4. The red button should be activated first. It should be of sturdy workmanship.
    The FDA will fulfill POTUS’ need to have more people working… to deal with the reports.

    “We will lower medical costs.”
    “We have lowered medical costs.”
    News-flash: no one is buying this BS.

  6. I applaud the concept of the blue button, as we should have access to our health records in the manner you suggest.
    My biggest issue is that from what I can determine, once again in the conception of this “product” they pretend that all the un-structured data (for lack of a better term) does not exist. It was the same for the health reform bill just passed this year. It is a total “day-forward” mind set, where all the legacy paper/images/data should basically just be ignored. As the EMR/EHR vendors like to say, you can just re-enter all the data in paper later when the patient comes in.
    As someone who is thousands of boxes deep in paper health records each and every day, I just once would like to see it at least acknowledged that it exists, that the data is important, and something will have to be done about it.

  7. Brian, I don’t see a conceptual problem with that. Right now the so called Blue Button is in its infancy. It should eventually provide text files with your discrete data, accompanied by PDF attachments and if you so choose a standards based CCR/CCD file with the structured data which you may use to upload into a commercial PHR, or your own local medical records keeping software.
    The idea should be that when you click that button, you should be presented with choices of what you want to download, from just an immunization list for school, to a comprehensive copy of your entire chart (and you should be able to select your preferred format as well).
    Hopefully, that’s the direction it will take, otherwise I agree with you.

  8. When I go into a hospital or my docs office now and request all my data I get printouts of electronic data, printouts of scanned images, and/or photocopies of paper depending on how they keep their charts. How is the “Blue Button” going to handle this? Will all this “un-structured” data be converted to pdf for me to download as well?
    This is just another “grand idea” or concept that makes a good sound byte, but does not deliver on what it promises. Like it or not, paper (or a scanned image of it) is still how the vast majority of health data is stored, and therefore must be addressed or the blue button is just another marketing ploy.

    When there is data theft — and there will be —
    Who is ACCOUNTABLE??? As in, “you’re fired!”
    Those who enter systems without ACCOUNTABILITY are either naive, clueless or dumb.
    And I REFUSE to pay for the data-theft mess that will result. Anyone with an iota of common sense should be able to see the problem.
    There’s a lot of lip service about ACCOUNTABILITY. I refuse believe any of that BS until a few INCOMPETENTS are fired.
    “Heck’a job, Brownie”
    “Your taxes will not go up”
    “I’m from the government, and I’m here to help.”

  10. Thanks, bev.
    John, ASCII text can be easily processed electronically. If the format is the same, one set of parsers can take care of everything. If the formats differ, they will need to write one parser per proprietary format. It gets messy after a while. Perhaps they should make available a second choice of download for those using PHRs and provide a standard CCR/CCD in addition to the text file.
    As to the red button, I disagree with your assessment. It is actually rather trivial to implement. It could be as simple as a formatted email being created, with the EHR vendor/version already in the header. The user would check some boxes corresponding to the the MAUDE fields and enter a description of the event for the comments field and click Send. The sender field would be set to the EHR vendor’s support email or something like that. Completely anonymous from the user perspective, if he/she so chooses. If not sent to the FDA then to some other supervising organization, with a copy to the vendor for transparency.
    I would estimate this at 60 hours development, including full testing. It would be lovely if MU Stage 2 required such button.
    BTW, very nice article at the Chilmark site, as usual.

  11. “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.”
    I wonder if the use of XML could solve that problem? It’s extensively used by pharmaceutical companies for the sharing and transmitting of information.

  12. Great conceptual post, Margalit. It’s one of those face-palm moments – the feds want interoperability, but fail to think of it in their own shop! This will be replicated over and over with vendors. But anything is better than nothing, which is what we’ve had for decades.

  13. Hi Margalit,
    You raise some very valid points regarding the differences btwn the clinical data of the VA and the administrative data coming from CMS. While it is great to see the feds take a leadership role in consumer access and control of their PHI, I am concerned that once a consumer gets their claims data, they may have some significant difficulty in making sense of it all. Also, still not quite sure how simple ASCII text files will upload into an existing data model of say Google Health, Dossia or HealthVault, but I’m sure they’ll figure something out.
    As for the red and white buttons: White is fine provided the consumer provides consent for a provider to access their records (break the glass feature?) and while the red button is a nice idea, believe it next to impossible to implement in an effective manner.
    As an FYI, Chilmark did a post as well on the topic that can be found at http://www.chilmarkresearch.com

  14. Wow. I am in awe. I had no idea this had been announced. Absolutely brilliant, and a triumph for advocates of patient access to the data. This initiative will greatly streamline the otherwise slow-going evolution of interoperability; whoever came up with it deserves a medal.

  15. Yes. A green button is necessary and with a green button comes big responsibility. Hopefully, we are all able and willing to assume it, but I am not entirely certain that we are.
    And also the green button should only be triggered by the white button – no shady gray buttons allowed.

  16. In order for the white button to work, you’re going to need a green button. Green is for “Go.” The green button will be for the patient to give permission to share their data. It’s critical that everyone who has a blue button also has a green button nearby, and that this be connected somehow to a central repository.

Leave a Reply to F.S. Cancel reply

Your email address will not be published. Required fields are marked *