Skip to content. Skip to main navigation.


  • November 18 2013

    Blue Button: have you heard of it? If you keep an eye on health care or health IT social media, the term is almost impossible to miss. You may have heard other names such as ABBI, Blue Button+, Blue Button+ Direct, Blue Button+ REST, and Blue Button Connector.

    So what is Blue Button? Since its inception in 2010, the term Blue Button has become overloaded and, to some extent, ambiguous. But no matter which definition you use, the underlying theme has always been the same: enabling consumers to have access to their personal health data. So follow me as I break Blue Button down into tangible and meaningful entities.

    Blue Button: The Noun

    The original Blue Button concept was born in the VA in 2010, and consisted of a simple text document containing personal health data that a consumer could download or view from the VA website. The definition of the term actually referred to the document itself and its contents and format. The format was a plain ASCII text file, but over the course of next two years, it evolved to support the more structured Consolidated CDA format with Meaningful Use Stage 2 specific fields.

    If you think of this in terms of Farzad Mostashari’s now infamous noun vs. verb, Blue Button would have qualified as a noun. The ability to download the document was denoted with a blue button that was clicked to either download the document to persistent storage or to print it. Others soon followed suit and began to implement the document spec and offer the same ability download and print personal health data.

    What does a consumer do with the data? That’s really beyond the scope of this post, but an important question nonetheless. Without use cases and workflow, the data is just data. If one were to just read the document content in raw format (let’s say over the phone to provide medical history to another provider), he or she may have trouble based on the limited formatting capability of a plain text document or understanding the sections of a C-CDA XML file.

    In 2011, the VA held a Blue Button challenge to kick start innovation using the ASCII document format. In 2012 ONC issued the Blue Button Mash-Up challenge to build upon the initial challenge and champion a higher level of integration with other data and workflow. The winners of the latter challenge proved that data could be utilized in innovative and meaningful use cases, and was an important milestone for the growing patient engagement movement. In 2013, additional challenges were issued from various groups utilizing the latest Blue Button+ specifications pushing the envelope into the bleeding edge.

    Blue Button+: The Verb

    In the summer of 2012, a group gathered in Washington, D.C., to explore initiatives to accelerate patient engagement. The outcome was the creation of ABBI (Automate Blue Button Initiative), and their vision was to make it incredibly easy for a consumer to get access to their personal health data. This concept implied new use cases and workflows and quickly moved the context of Blue Button from a noun to a verb. Shortly after the project workgroups kicked off, the name was changed from ABBI to Blue Button+ indicating that the concept was a long-term initiative with goals expanding beyond automation. The workgroups focused on three main use case themes: download, push and pull.

    The download and transmit use cases are modeled after the Meaningful Use Stage 2 VDT (view, download, and transmit) requirements. The download function is in line with the original Blue Button noun concept, with expanded data formats to match those of both Meaningful Use Stage 1 and 2. Data can be downloaded in one of the following formats:

    • Consolidated CDA with MU2 fields and sections
    • MU1 Continuity of Care Document/C32
    • Human readable formats such as PDF, TXT, or a Microsoft Word DOC

    The transmit functionality, now called called Blue Button+ Direct because of its use of the Direct Project as its transport specification, is aligned with the VDT transmit function. However, it’s a profiled approach to VDT, meaning it targets a very specific set of functional and technical requirements that are part of the VDT catalog plus a few additional requirements. Specific requirements include:

    • The receiving Direct address of choice is a personal health system
    • The message body specifies an optional text section indicating that the message was sent from a patient or on behalf of a patient’s request.
    • Messages may be automatically sent based on systemic triggers, implementing the automate function of ABBI.  Because the transmission of data to the patient can be triggered without the patient having to sign into a portal or request the information by other manual means, this can significantly simply the workflow from the patient’s perspective
    • Blue Button-specific trust bundles are available for data holders and personal health systems.  I described the importance of trust bundles in Direct exchange and patient engagement in my scalable trust story blog.

    Through the remainder of 2012 and into early 2013, the workgroups formalized the Blue Button+ specification and published a detailed implementation guide in February 2013. The good news is that if you were implementing EHR technology that included the MU2 VDT functions, you were already implementing a vast majority of Blue Button+.

    It’s worth mentioning that the initial Blue Button+ Direct use cases only move data from the data holder to the consumer. Part of the reason was for simplicity and to accelerate adoption of the technology, but another is based on policy. The implementation guide contains privacy and security sections outlining the policy implications of the workflow, and the Blue Button+ trust bundle inclusion requirements were developed with these issues in mind. Currently, Blue Button+ Direct use case enhancements are being considering that include consumer-generated data being transmitted to data holders. The necessary security and privacy policies to support these use cases are also currently being investigated and developed.

    As Blue Button+ Direct came to market, the Blue Button community sought other types of data and transport methods. Blue Button+ is now an umbrella for a growing portfolio of standards, which include not only the Blue Button+ Direct specifications, but also Blue Button+ REST and the Blue Button+ Payer workgroups.

    The Blue Button+ REST specifications are built on contemporary technologies, some of which are still in IETF draft state or under IHE ballot consideration. They are based on the RESTful API paradigm and increase the number of data access methods and types of data that can be retrieved.  The paradigm differs from Blue Button+ Direct in that the patient health system applications can programmatically access authorized patient data on demand instead of waiting for the data to be pushed from the data holder. To some extent, this puts the consumer in more control of when they access their data. The REST workgroup has completed their initial implementation guide, and is activity-seeking pilots from both data holders and personal health systems.

    The Blue Button+ Payer workgroup recently kicked off as part of the Standards and Interoperability Framework. This effort will standardize financial data such as claims and evidence of benefits (EOB) for consumer purposes.

    Blue Button Connector and The Movement

    ONC is ramping up for a campaign that will kick off in January 2014 called the Blue Button Connector. It consists of a tool that helps consumers find providers and various entities that support Blue Button technologies.  The connector will initially list providers that have successfully attested to meeting the MU2 VDT requirements and will list any provider, as well as data holders such as insurance companies, labs, and pharmacies. It will reveal what type of data patients can access, access options, support of automation triggers, and use of the Blue Button trust bundle. The connector will also enumerate personal health systems that can access and consume Blue Button data. ONC is also vigorously engaging data holders and other patient engagement activists to support the propagation of Blue Button, and holding a series of developer forums and competitions to encourage the development of personal health systems ready to receive Blue Button data.

    From its inception, to now, and moving into the future, Blue Button is all about consumer access to person health data. It is constantly evolving to meet the challenges of today and tomorrow, both functionally and technically, with the vision of ubiquitous data liberation. Rather than aligning with a specific technology, the Blue Button term is moving towards a branding philosophy consisting of a portfolio of technologies and use cases. Consumers will simply associate the Blue Button brand with access to their personal health data.

    Greg (@Greg_Meyer93) is a director and distinguished engineer at Cerner. He’s responsible for the HISP architecture of the Cerner Direct solution and remains actively engaged in development/coding and mentoring new software engineers and upcoming architects. Also responsible for the Direct Project Java reference implementation architecture and a primary source contributor, Greg serves as co-chair for the Direct reference implementation workgroup, is a contributing member of ONC's Standards and Interoperability Framework initiative, and the Trust Bundle Operations workgroup lead with

  • Comment
  • Bookmark
  • Print