BlueButton+Plus+-+Pull+Strawman+Option+2

include component="page" wikiName="siframework" page="ABBI Header" Note: Content from this strawman has been incorporated into the DRAFT Pull Straw Man Options spreadsheet here:

Courtesy of Bettina Experton (Humetrix)
Pull is an intrinsic feature of Blue Button for consumers to easily view and download their record from a Blue Button enabled portal. The purpose of ABBI Pull is to bring automation into this original pull process for even easier consumer access to their records and sharing of these records under their own direct control while ensuring security and privacy.


 * 1. Assumptions:**

1. Consumer Users select and use an application of their choice to automatically pull on-demand their Blue Button record(s) from data holder(s).

2. User selected application can be exclusively under user's control with data storage solely on user's personal computing device (PC, tablet or smart-phone). An example of this use case for financial data is the use of personal software such as Quicken which pulls data from financial institutions on demand, under the control of the user and stores the data on the user's computing device.

3. Direct accounts for users is not a requirement to auto-pull and share Blue Button records. Until Direct messaging is widely deployed and available to both patients and providers, the proposed option 2 delivers a practical secure protocol for use today by both consumers and providers.

4. The user has previously set up a personal account with data holder(s), and has received a user name and password from each data holder to access these accounts to download blue button records.


 * 2. Automatic Pull/Download Mechanism**

A simple to use Blue Button programmatic auto-pull download mechanism could be put in place with a simple design pattern along these lines:

1) The Blue Button hosting site would provide application developers with a fixed URL endpoint for submission of Blue Button user credentials (user account username/password) obtained by user from data holder
 * This could be the same or similar to the current logging form already in place on many Blue Button data holder sites. The suggestion here is that this URL not change with normal periodic web site updates.

2) The response to the submission of valid credentials would be a token that could be submitted to the download Blue Button record site.
 * Most Blue Button hosting sites store the actual records on a different server than the customer facing web site that accepts the users credentials. This token would be generated by the site validating the credentials and then submitted to the download site.

3) The download site would validate the token and initiate the download. Token validation would check for:
 * Customer Account -- tokens would incorporate information to identify the Blue Button record to be downloaded.
 * Timestamp -- tokens would expire after a fixed time period.
 * One time usage -- tokens would be invalidated after being used so they couldn't be replayed.
 * Optional Developers Key -- tokens could optionally contain unique keys assigned (by the Blue Button site administrator) to individual developers. This would allow the token to be validated as being submitted by an approved developer.

4) All steps would occur over SSL (as they do today).

5)A helpful addition to this pull use case would be a push-notification system that alerts the user or third-party pulling application that there has been a change at the Blue-Button data source.

From the developers viewpoint they would simply submit credentials and receive a token in response. Then submit the token to the download site to start the download.


 * 3. Additional Considerations**

The timeline for implementing this Option 2 for automatic access and downloading of Blue Button records is accelerated compared to Option 1 as it requires minimum development times for data holders. There is a significant advantage to not wait for implementation of Direct email accounts for millions of patients and all of their providers. The ABBI Pull workgroup should focus on providing a rapidly scalable solution with adequate security provisions that does not delay a rapid increase in consumer access to, and use of, their Blue Button records.

include component="page" wikiName="siframework" page="ABBI Initiative Contacts" include component="page" wikiName="siframework" page="space.template.inc_contentleft_end"