Designing a Secure Blue Button Health Information Exchange for a Commercial Laboratory

Background: There is a growing demand by patients for easy electronic access to laboratory result data for use in personal health record systems (PHR-S) and for transfer to other health providers. The Blue Button Initiative is a public-private partnership offering a framework based on national standards to support patient access to electronic data. Objective: The aim of this project study was to architect an initial pilot implementation of the Blue Button framework for a commercial laboratory to facilitate patient access to electronic results. Methods: The proposed design architecture includes multiple application services, specifically an Encrypted Data Store, Client Access component, and Result Publishing service to accomplish these goals of the pilot project and meet the security and privacy requirements. Results: The resulting application components and programming interfaces accomplish the initial pilot goals and provide a base to expand the platform to offer support for mobile devices and additional interoperability options. Encryption and isolation of data have been used to safeguard the confidentiality, integrity and availability of protected health information (PHI) and allow for the use of standard cloud services to host external facing components. Conclusions: The Blue Button standards and framework provide a solid basis for facilitating electronic access to result data by patients and for meeting the requirements of View, Download, and Transmit (V/D/T) in Meaningful Use Stage 2 (MU-II).


Introduction
Health information exchange (HIE) is vital to improving health care quality, safety, and patient outcomes. Within the United States, there is growing recognition that healthcare must become more cohesive to achieve the "Triple Aim" goals of improved health outcomes, enhanced patient experience and reduced healthcare costs 1 . In an international study on healthcare systems, the USA ranked last in care coordination with 33% of patients reporting that records were not available for an appointment with a doctor or that a doctor ordered an unnecessary medical test that had already been done 2 . The Blue Button framework is both a HIE methodology and a symbol of a movement towards an improved healthcare system in which patients and healthcare providers use information technology to work together and improve health 3,4,5 .
Blue Button is a registered service mark of the US Department of Health and Human Services and is most often indicated by a clickable blue circle often marked with the text "Download my data". The initial use of the Blue Button was in 2010 when the Department of Veterans Affairs deployed the Blue Button initiative as part of its online combined personal health record (PHR) and patient portal, My HealtheVet to allow simple exchange of a patient's personal health data in a standard, consistent format 6 . As of January 2014, the My HealtheVet (MHV) PHR portal has more than 2.6 million registrants (37% of the VA patient population), with more than 1.4 million VA patients having authenticated access which allows for Blue Button access to their health data (25% of the VA patient population). More than 955,000 veterans have used Blue Button and have downloaded over 5.7 million Blue Button files 7 .
The Blue Button framework has continued to evolve and in 2012, the Office of the National Coordinator for Health IT (ONC) within the US Department of Health and Human Services took on the responsibility for creating a new framework, in collaboration with the VA, the White House, and a host of other public and private sector leaders. The Blue Button pledge program includes over 500 organizations including healthcare providers, insurance companies, labs, drug stores and most recently mobile application developers focused on making personal health data available for electronic access and transmission 6 .
The Blue Button movement is considered a key patient engagement initiative, illustrating this, a May, 2012 study done on over 18,000 My HealtheVet users showed that the most highly endorsed benefit of Blue Button was that it helped patients understand their health history better because all the information was in one place (73%). Of those patients that shared their Blue Button data with a non-VA provider, 87% reported that the non-VA provider found the information somewhat or very helpful 7 . In another study, almost 4 of 5 respondents (79%) were interested in sharing access to their PHR with someone outside of their health system 8 .
In this project, we architect an initial design for a cloud based implementation of the Blue Button frame work for a commercial laboratory to facilitate patient access to electronic results.

Application Components
The following application components were designed for this project:

Encrypted Data Store Component and API
The encrypted data store is a private REST interface published via SSL/TLS which requires authentication. Its primary purpose is the storage of encrypted patient data and the retrieval and decryption of data when the appropriate key is presented. A relational Sql based database has been utilized for this project but non-relational "no-sql" databases such as Hadoop or MongoDB are equally acceptable for this type of record storage and retrieval.

Client Access Component and API
The client access API stores the encryption keys for the records contained in the Encrypted Data Store component and re-encrypts these keys utilizing identity-based encryption methods. For the purposes of this initial project, patient last name and date of birth were selected as the key identity attributes for the encryption of these records. The API has been designed to facilitate additional and alternate key attributes if required. When the appropriate keys and authentication are presented the API retrieves the encrypted data from the Encrypted Data Store via REST and makes it available for presentation or transfer to an authorized provider. The client access API is a REST interface published via TLS.
The client access portal allows for patient registration and retrieval of records when an Encounter ID and the correct identity-based encryption keys are presented. The client access portal also allows a user to select a registered Blue Button provider and authorize Push document transfer of records.
A relational Sql based database has been utilized for the storage of both the encrypted key information and the encrypted patient registration information but non-relational "no-sql" databases such as Hadoop or MongoDB are equally acceptable for this type of record storage and retrieval. To meet the requirements of HIPAA and NIST guidelines, the Client Access Portal component must be hosted on a device (and ideally at a location) separate and distinct from the Encrypted Data Store component.

Result Publisher Component
The  Figure 1 shows the core implementation framework.

HIPAA Compliance and Secure Design Protocols
In architecting this solution, careful consideration has been given to best practices for safeguarding the confidentiality, integrity and availability of protected health information (PHI). This system has been designed to comply with the requirements and guidance from the Centers for Medicare & Medicaid Services (CMS) on the rule titled "Security Standards for the Protection of Electronic Protected Health Information," found at 45 CFR Part 160 and Part 164, Subparts A and C, and in accordance with best practices specified by the National Institute of Technology 9,10,11,12,13 . The application components and storage utilized by the public facing application components and data have been encrypted in accordance with the HIPAA Security Rule, "Guidance to Render Unsecured Protected Health Information Unusable, Unreadable, or Indecipherable to Unauthorized Individuals" 14 . Electronic PHI has been encrypted as specified by "the use of an algorithmic process to transform data into a form in which there is a low probability of assigning meaning without use of a confidential process or key" (45 CFR 164.304 definition of encryption) and such confidential process or key that might enable decryption has not been breached. The application components have been purposely isolated as specified in the guidance "to avoid a breach of the confidential process or key, these decryption tools should be stored on a device or at a location separate from the data they are used to encrypt or decrypt" 14

Results
The resulting application components and programming interfaces accomplish the initial project goals and provide a base to expand the platform to offer support for mobile devices and additional interoperability options. Encryption, isolation and multifactor authentication of data have been used to safeguard the confidentiality, integrity and availability of protected health information (PHI) and allow for the use of standard cloud services to host external facing components.

Discussion
A primary goal of this project was to present a robust solution that would meet HIPAA standards while enabling end users to access their information easily and authorize the transfer of records to other providers in an efficient manner. The resulting design accomplishes this goal and provides an acceptable balance between security, efficiency and timely access to health data. One of the strengths of this solution is the ability to dynamically limit access to the encrypted medical records or change the keys or algorithms used to encrypt the records at any time. As the portal application only grants the user access to encrypted keys, this prevents the loss of PHI in the event of unauthorized access to the encrypted databases. The Result Publisher component, which is secured by a firewall and not accessible via the internet, has the ability to re-encrypt the records or disable access to records.
It is important to note that in a commercial laboratory setting, patient results are encounter centric. This solution, through a relationship database maintained by the result publisher component, allows the linking and retrieval of multiple encounters for a patient if all visits are with a single provider. Although it is theoretically possible to allow a patient to link multiple providers, and by extension, multiple encounters within each provider, this functionality has not yet been implemented in this project. It is currently under consideration and review.
The ability for a patient to authorize additional updates (i.e. new encounters and results) to be sent automatically as labs are performed (often referred to as Blue Button + push update functionality) is not yet implemented in this project. This is currently under development and it is anticipated that the authorization component will be performed within the Client Access component but the authorization will be transferred and stored within the Result Publisher. The Result Publisher will manage the transmission of push updates via the Client Access API. This approach is required to limit the PHI stored within the Client Access component for security reasons.
The current project design does not fully implement the BB+ Pull and Oauth2 API required to support mobile applications. This is currently in the planning stages for future development and will be included in the Client Access API.

Conclusions
The Blue Button standards and framework provide a solid basis for facilitating electronic access to result data by patients and for meeting the requirements of Attachments, and Web Services. The current Blue Button framework is suitable for allowing patients easy electronic access to laboratory result data for use in personal health record systems (PHR-S) and for transfer to other health providers.

Conflicts of Interest
None declared