ABBI - The Pitch

When developing a standard, there are two audiences you have to pitch it to: The developers who will use it, and the organizations that are making decisions about whether or not they are going to implement it.  I've spent quite a bit of time talking to the former, but not enough to the latter.

Assumptions

First of all, I'm going to assume that you already know a little bit about Meaningful Use, and the Nationwide Health Information Network (NwHIN), and maybe the fact that there are two standards for exchange specified for the NwHIN: Direct and Exchange.  Direct is the simplified on-ramp using e-mail, and NwHIN Exchange is a bit heavier, but also widely deployed set of standards used to support communication of healthcare data between Federal agencies and mostly larger healthcare provider systems.

A Quick Overview

What is ABBI?

ABBI stands for Automate the Blue Button Initiative.  The project came out of a White House sponsored meeting which both I and my 14-year-old daughter (named Abby) attended.  The point of this project is to develop a technology (actually a set of standards that technology can be developed to implement) that will enable patients to set up a way to get their healthcare data once, and it will simply happen.

What kind of Healthcare data?

The same data that is required to be given to patients in the same electronic format as is specified under the View, Download and Transmit requirements of Meaningful Use Stage 2, using the exact same standards.  Plus, any additional documents a provider wants to make available through the API.

I've got enough to deal with for Meaningful Use Stage 2, why do I need ABBI?

One of the key goals of the ABBI project is that providers could use these specifications to meet the View/Download/Transmit requirements of Meaningful Use.  A patient who downloaded their documents using an application supporting the ABBI API, would qualify in the numerator of patients who have used the View/Download/Transmit capability of the Certified EHR.

How does it work?

The way that it works is pretty straightforward (although many of the details still need to be ironed out).  Here are the essentials:

1. Patient obtain Application(s)
   Patient obtains or is provided access to an application that will facilitate communication of patient data to them.  This could be a portal, a PHR, a cloud-based repository of health information (e.g., Health Vault), or an application running on a laptop, tablet or smart phone, or an NwHIN Direct address.
2. Agree on the patient identity
   The patient supplies an identity to their healthcare provider, that the provider can be used to securely identify them.  This could be an NwHIN Direct address, a username/password combination, or any number of commonly available identities on the Internet by which the patient will identify themselves.  The provider authorizes the patient identity to access the data within their system.

At this stage, the choices bifurcate, depending on whether the patient data is being pushed to or pulled by their application.

Push Model

The push model utilizes NwHIN Direct.  The provider's EHR communicates to the patient by sending NwHIN Direct messages whenever new information is available:

1. Provider's EHR is configured to "push" patient data to the selected NwHIN Direct address.
2. As new encounters occur, the encounter summary is pushed to the patient's NwHIN Direct address.

Pull Model

The pull model utilizes the ABBI Pull specifications, which are based on RESTful specifications developed using the HL7 FHIR protocol, and which can work with the NwHIN Exchange specifications.

1. Patient authorizes "subscriptions" to that data by the application described above (using OAuth 2.0).
2. As new encounters occur, the encounter summary is made available in the EHR (e.g., through the patient portal).
3. Application requests (from the EHR/portal) either the current "Patient Summary", or a list of current documents available for the patient, and downloads those documents as needed via the authorized "subscription".

Security

All communications in either model are encrypted using web encryption standards, and the patient identity is assured through other web security standards (e.g., S/MIME or OAuth 2.0).  For push, ABBI uses NwHIN Direct, and thus uses S/MIME and TLS to secure and encrypt communications.

For PULL, the ABBI efforts are being coordinated with other efforts in the Internet Engineering Task Force (IETF), and with Integrating the Healthcare Enterprise's Internet User Authentication profile currently under development, in order to establish a secure way for patients to authorize applications to access their health data.

Standards

The ABBI Protocol is being implemented in Open Source for the Pull Model described above, and is hosted in Google Code.  A test server has been created and is hosted in the cloud (it may be down from time to time).

The basics of the ABBI PULL Protocol make use of the HL7 FHIR xdsentry resource.  FHIR is a new RESTful standard being developed by HL7 that supports simple XML and JSON representations of healthcare data.  This same work is being considered as the basis for other Healthcare standards efforts, including IHE's Mobile Access to Health Documents profile.

The advantage of using this standard is that it is closely aligned with other standards (IHE's XDM and XDR used in NwHIN Direct, and XCA used in the NwHIN Exchange specification, and supported by the CONNECT Open Source project.

As FHIR evolves, it expects to produce clinical resource specifications that would support access to fine-grained patient data, including problems, medications, allergies, immunizations, lab results, vital signs, et cetera.  By starting with the FHIR infrastructure resources for documents, we enable access to existing health data in CDA documents, while paving the way for future, targeted access to patient data in later phases.  This data could be packaged together in document form (as is done today with the CDA standard), or used in other services.

Finally, FHIR provides a mechanism for patients and providers to store data as well.

A Last Word from Abby, on ABBI