BlueButton+Plus+-+Pull+Strawman+Option+1

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

<== Take me back to the Pull WG Page

Courtesy of Adrian Gropper
Pull is already a feature of a Blue Button portal to the extent that a browser (or a system that impersonates a browser) can pull data from any web portal. ABBI Pull is designed to reduce, if not eliminate, the incentive for services to impersonate a patient.

The success and rapid adoption of Blue Button is due in large measure to a design that introduces a minimum of new privacy issues. This proposed ABBI Pull scenario is also designed for least privacy impact. For example, we make the assumption that Direct messaging is available to both the data source, destination, and to the patient and we do not link the ABBI Pull service to any particular institutional affiliation, certification or capability.


 * 1) Pull Scenario
 * The patient's BB Portal (BBP) is the data source
 * The patient signs in to BBP to provide limited authorization to pull from her BBP
 * The patient will provide three elements of authorization:
 * Destination of the BB data (who is authorized to pull from BBP)
 * Content of the BB data (what subset of available data is accessible to pull for this specific authorization)
 * Expiration and Notification (one time, until date, renewable by request, cc the patient)
 * Destination
 * Entered as a Direct address
 * Selected from any people or institutions already listed in the patient's BB file
 * Selected from a directory (e.g.: state HIE directory)
 * Content
 * Preset documents (default to current BB file)
 * Exclusion of specific categories within a document is supported
 * Claims-related restrictions and other presets are available
 * Research data sharing restrictions
 * Date Ranges (including restrictions on whether new data will be automatically available)
 * Imaging is available
 * Expiration and Access Restrictions
 * Default to 1 year, renewable, cc the patient
 * Role of pulling user
 * Specific person (do not forward )
 * Department (e.g.: Psychiatry, Radiology)
 * Institution (includes both HIPAA CE and consumer PHR services)
 * Role (e.g.: credentialed emergency physicians)
 * A Direct message with the authorization parameters is sent to the destination
 * A Direct message is returned to the patient by the destination (may be delayed seconds to days)
 * Pull enabled and active
 * Additional information or modification required (a link to BBP page with specifics is in the message)
 * Pull request is pending acceptance
 * Pull request is denied (with specific reason such as patient Direct ID email address not recognized)

Protocol Assumptions
 * Patient and destination are adequately described and secured by their Direct addresses and corresponding certificates (no added restrictions)
 * Authorization protocol and parameters are standardized and profiled (e.g.: OAuth, UMA)
 * Pull is accessible from a web browser, including mobile
 * Pull user authentication is standards-based (e.g.: OpenID Connect)
 * Patient can set up pull to her own personal destination (no institutional restrictions)

Additional Considerations
 * Pull requests from HIEs and other sites that do not have the benefit of in-person authentication should be able to offer similar BBP capability and user experience. Some additional authentication may be required
 * Pull capability as a way to provide legally authentic records for disability, legal disputes, etc...
 * Patients should have the right to restrict exchange of any data that's not also available via ABBI Pull
 * A Direct message authorizing Pull can be forwarded to a separate server or service for processing as long as the actual user of the pull (human or machine) meets the authorization requirements of the BBP contract

2. Transport Direct Project messaging will be used to deliver ABBI Pull requests between participants and messages to patients. HTTPS and OAuth will secure data transfer

3. Content Content format will be negotiated along with the authorization for Pull. Streaming of randomly accessible content such as images or waveforms will be supported.

4. New Functionality ...to be added to the EHR or elsewhere as appropriate in the data holder’s environment.
 * Enable each patient record to have associated with it a set of patient-supplied Pull Authorizations (additions to the data model) and corresponding tokens
 * Create, at a responsible point in the intake/admit/encounter workflow, forms to add/view/edit these authorizations
 * Evaluate and service data requests matching the stored authorization tokens

5. Additional Open Issues include component="page" wikiName="siframework" page="ABBI Initiative Contacts" include component="page" wikiName="siframework" page="space.template.inc_contentleft_end"
 * Awareness. How will patients come to know about and receive a Direct address for use in ABBI exchanges? Is this in scope for the ABBI project or should we assume that it will be handled externally to our work?