BlueButton+Plus+-+Push+Workgroup

include component="page" wikiName="siframework" page="ABBI Header" flat =Announcements= include component="page" wikiName="siframework" page="BlueButton Plus - Meeting Information" =Timeline= =BlueButton+ Implementation Guidance Documents= [|BB+ IG - Transmitting Data Using the Direct Protocol] @ http://bluebuttonplus.org [|BB+ IG - Receiving Health Data Using the Direct Protocol] @ http://bluebuttonplus.org =Background= Over the last few years the community has developed many of the components of a successful BlueButton+ approach: [|Blue Button] to show the way, [|CCD (as defined as a Consolidated CDA)] for summary content, and [|Direct] to move information from providers to patients. This proposal attempts to add the last, minimal guidance on top of these advances to satisfy the ABBI goal of "//automating transmission of personal health data to a specific location, using the Blue Button//." This proposal is confined to the "push" pattern, although some of it may be useful in other contexts as well. =Charter=
 * **Call for Participation- BlueButton Plus Pilots!** If you are interested in becoming a Pilot for the BlueButton initiative, please take a moment to fill out our BlueButton Plus RI-Pilots Interest Survey.
 * **PUSH and PULL WG TRANSITION:** Push and Pull WG meetings are CANCELLED . The Push (DIRECT) and Pull (RESTful) guidance are both complete in their draft form and we are now switching our focus to Pilot WG activities. All of our WG members are invited to continue their valuable contributions and participation as we will be transitioning to a monthly, Blue Button Community All Hands meeting to keep everyone apprised of the latest activities. Please stay tuned for meeting dates and other announcements.
 * The Push Guidance (http://blue-button.github.io/docs/) is complete in its draft form and we are now switching our focus to supporting our adopters. A huge thank you to the group for all the hard work that got us here!
 * PUSH: Automating the transmission of personal health data.**


 * In Scope**
 * Existing transport standards, services, and specifications
 * Existing content standards
 * Frequency of data updates
 * Customizable parameters for receiving auto alerts / updates


 * Requirements**
 * 1) User (patient or provider) is already authenticated in data holder's system.
 * 2) Transport must be secure
 * 3) Data that is sent must be both human-readable and machine-readable.


 * Use Cases**
 * Use Case 1 (UC1) - ABBI Push via Direct from a physician's office
 * Use Case 2 (UC2) - ABBI Push via Direct from a patient portal
 * Use Case 3 (UC3) - ABBI Push via email

=Artifacts=


 * Use Cases**
 * Use Case 1 (UC1) - A patient can specify in a dataholder's system to be sent an updated copy of his/her personal health information as it becomes available.
 * Use Case 2 (UC2) - By patient request, a provider can specify in an EHR that a patient be sent an updated copy of his/her personal health information as it becomes available.
 * Use Case 3 (UC3) - Use of transmit to a 3rd party specific to the MU-2 requirements. [From 2012-8-29 Call]

Push for Developers Push for Patients

The below is an elaboration of a concept proposed by Arien Malec at the White House Patient Access Summit on 6/4/2102. Any mangling of his intent is mine and unintentional.

1. Assumptions

 * 1) Clinical systems have or will obtain the ability to generate a Consolidated CDA CCD document (per MU1, with potential minor tweaks to fit Consolidated CDA restrictions)
 * 2) Clinical systems have or will obtain the ability to send Direct Project secure messages (per MU2 transitions of care)
 * 3) Patients will have the ability to obtain a Direct address from a service of their choosing, and will be made aware of their options through various channels. See section 5 for an open issue around awareness.
 * 4) Providers will receive Direct address from patients in a way that appropriately "identity proofs" the bearer. That is, generally but not exclusively through in-person identity assurance, providers will verify that the address is controlled by and associated with the subject (or guardian) whose health information will be shared using it.
 * 5) Use of this scenario would count towards the denominator for view, download and transmit of Meaningful Use Stage 2

2. Transport

 * 1) Direct Project messaging will be used to deliver ABBI push messages to patients.
 * 2) The Direct configuration must include a set of known patient trust anchors for sending to patients.

3. Content

 * 1) To support machine and human use cases, each ABBI exchange will include two versions of the content:
 * 2) A human-readable representation, formatted as HTML or plain text (MIME Types text/html or text/plain)
 * 3) A structured representation, formatted as a Consolidated CDA CCD document (MIME Type application/xml+ccd)
 * 4) The message should be a multipart/mixed document. The first part will present the human-readable content; the second will present the structured document as an attachment.
 * 5) Additional attachments MAY be included, for example a PDF version or a JPG or TIFF image file containing additional information relevant to the visit.

4. New Functionality
//...to be added to the EHR or elsewhere as appropriate in the data holder's environment.//
 * 1) Enable each patient record to have associated with it a set of patient-supplied Direct Addresses (additions to the data model)
 * 2) Create, at a responsible point in the intake/admit/encounter workflow, forms to add/view/edit these addresses
 * 3) Enable a trigger point (e.g., close of encounter or finalization of patient discharge plan) where the health record will be sent
 * 4) At that trigger point, construct and send the message to each configured patient address

5. Additional Open Issues

 * 1) 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?
 * 2) Historical data. Once a "push" relationship has been established, new information will be sent as it becomes available. On first connection, should historical information be sent as well? If so, should it be a snapshot or individual messages for past visits?

Discussion:
 media type="custom" key="20683596"

include component="page" wikiName="siframework" page="BlueButton Plus - Initiative Contacts" include component="page" wikiName="siframework" page="space.template.inc_contentleft_end"