Plan for Reform of the Administration of Military Health – 3rd report
DoD
NOVEMBER 18 2013
https://www.cerner.com/blog/whats_this_blue_button_thing/?langtype=1033
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 detailedimplementation 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 DirectTrust.org.
- Category: EHR, Technology, Direct Project, Interoperability
- Tags: Blue Button, Direct Project | Comments (0) | Rating: 5/5
Link to Full Text: NDAA 2014 – Section 713
Article link: http://www.nextgov.com/defense/2014/01/quit-wasting-money-e-health-records-congress-tells-defense-and-va/76943/
Worried that the Defense and Veterans Affairs departments might continue to spend years and billions of dollars in a “futile exercise” to develop their own electronic health record systems “and lose sight of the end-goal of an interoperable record,” lawmakers included funding restrictions in the 2014 Omnibus Appropriations Act the House passed Wednesday.
Both the House VA and Defense appropriations committees have defined the goal –interoperability — as the ability to exchange computable information electronically between the departments based on common data standards. Similar language is included in the 2014 National Defense Authorization Act signed by President Obama late last month. The omnibus spending bill eliminated language in an earlier version of the 2014 VA appropriations bill that called for development of a single record to serve both departments.
The two departments abandoned efforts to develop a single EHR in February 2013 when the estimated costs of a system reached $28 billion, four years after President Obama called for development of a joint record in April 2009.
“The committees want to be very clear with both departments: An interoperable record between the two departments is the chief end goal for Congress,” said the VA section of the omnibus bill the House approved Wednesday.
“The evolution and/or procurement of new health record systems is an important project for the departments to undertake, but it will end up being a futile exercise if the result is not the development of systems that will be interoperable, defined as the ability to exchange computable information electronically,” the section said. “There is rising concern the departments will spend years and billions of dollars on their own electronic health record systems and lose sight of the end-goal of an interoperable record.”
The VA section of the omnibus bill transfers $251.9 million that VA originally requested for the integrated EHR to support development of an upgraded version of its Veterans Health Information Systems and Technology Architecture, dubbed VistA Evolution. It provides $32.9 million for the Virtual Lifetime Electronic Record, which includes benefits information.
The language precludes VA from spending more than 25 percent of the VistA Evolution budget until the department describes to Congress how it will adhere to data standards defined by the Interagency Program Office, or IPO, which was originally set up to develop the integrated EHR. The lawmakers also want updates on “how testing will be conducted in order to ensure interoperabity between current and future DoD and VA systems.”
The Defense Appropriations Committee said the IPO — whose director, Barclay Butler, departed last September with little public notice — now has the responsibility to establish and approve the clinical and technical data standards that “will insure seamless integration of health data between the two departments and private health care providers.”
Last May, Defense Secretary Chuck Hagel backed development of a new Defense EHR based on commercial software. In September, the Pentagon established the Defense Healthcare Management Systems Modernization, or DHMSM, office to manage development of the new EHR.
DHMSM plans to kick off a procurement for the new Defense EHR in March. The Defense section of the omnibus bill allows DHMSM to spend only 25 percent of its budget until it provides Congress with a budget for the full cost of the new EHR. The omnibus bill does not break out the DHSM EHR budget, but chopped the overall procurement budget for the Defense Health Agency by $204.2 million for the integrated EHR it now considers as “excess.”
The Defense Appropriations Committee echoed the VA Committee, saying it is “imperative” that the Pentagon “does not lose sight of the ultimate goal of interoperability” with the VA EHR.
Get the Nextgov iPhone app to keep up with government technology news.
(Image via mayamaya/Shutterstock.com)
healthcarereimagined 