Proposed+Straw+man+changes

include component="page" wikiName="siframework" page="ABBI Header"

=**Strawman For Provider/Payer communications with Patients/Members**=

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)  Patie 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.nts will have the ability to
 * 4)  Patient will be able to use the email system of their choice including direct
 * 5)  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.

2. Transport
> > 1. Transports shall provide a secure and audit able method of transport > >
 * 1) Direct Project messaging will be used to deliver ABBI push messages to patients
 * 1) 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)
 * 1) 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.
 * 2) Additional attachments MAY be included, for example a PDF version or a JPG or TIFF image file containing additional information relevant to the visit.
 * 3)  Content should be encrypted with a key either provided by the patient or known to the patient

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 ) Email Addresses
 * 2)  Enable each patient record to have associated with it Key for decryption
 * 3) Create, at a responsible point in the intake/admit/encounter workflow, forms to add/view/edit these addresses
 * 4) Enable a trigger point (e.g., close of encounter or finalization of patient discharge plan) where the health record will be sent
 * 5) 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?

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