Skip to content

Latest commit

 

History

History
125 lines (80 loc) · 7.69 KB

receive-using-direct.md

File metadata and controls

125 lines (80 loc) · 7.69 KB
layout title
default
Receiving Blue Button+ Data Using Direct

Receiving Health Data Using Direct

This section describes the use of the Direct Project specification to receive health data securely from a data holder on behalf of a patient or their authorized representative. The ability to receive health data securely enables an ecosystem to be built on patient health data.

Receive Diagram

1. Using the Direct Protocol to Receive Data

Direct Project offers a specification for how existing standards can be used to securely transport health information over the Internet. Direct uses SMTP, S/MIME, and X.509 certificates to achieve security, privacy, data integrity, and authentication of sender and receiver sufficient to meet the data transport needs of health information exchange.

Your application will need to integrate with a component that can accept Direct messages and their payloads. This component is called a Security/Trust Agent (STA). A STA uses SMTP and S/MIME to ensure messages and their payload are delivered securely. A STA can be a component internal to your system, or hosted externally.

When an STA is hosted externally, it is usually by a Health Information Services Provider (HISP).

For Blue Button+, your Direct STA must be able to:

  • Generate valid Direct addresses for your users and use cases.
  • Publish certificates for its addresses via DNS or LDAP. If the addresses are patient-controlled, you must assign an individual certificate to each.
  • Verify incoming messages to ensure they are proper Direct message and that they have been signed by an appropriate certificate from a trust community or an extended validation (EV) certificate. These Provider anchors can be found at https://secure.bluebuttontrust.org.

Your application must be able to:

  • Receive decrypted/validated messages from the HISP/STA via its native interface. This interface will vary from component to component.
  • Be able to parse and meaningfully represent the Blue Button+ information in a method appropriate for your users and use cases.

Sample code: .NET Reference Implementation, and Java Reference Implementation.

Learn more: Direct Project's Documentation Library and Direct Project's Applicability Statement for Secure Health Transport

Detailed Flow Diagram

The following diagram depicts a successful transmission. See it full-size.

Direct Transmit Flow Diagram

2. Blue Button+ Format and Payload

Once your application has received the message and payload, it needs to process it. It needs to understand what files have been included. It also needs to handle cases in which it receives multiple updates from the same user, over a period of time.

As with all Direct messages, Blue Button+ messages that your application receives from the STA/HISP will be Internet-format Messages following RFC 5322 and Multipart MIME. Blue Button+ provides additional guidance on the contents of these messages to support a higher level of semantic exchange.

Blue Button+ messages will contain:

  • A human-readable message body. This body may be in text/plain or text/html format, or (as is common in many mail systems) both of these. The content of the body is up to the sending application, except that it will always begin with the text “This message was sent by Data Holder Name at the request of Patient Name.” This tag is intended to clarify the context under which information delivery was authorized.

  • A clinical summary containing a snapshot of the patient or member’s health history. The summary will be a Consolidated CDA w. Meaningful Use Stage 2 Sections and Fields. This section will have a MIME type of application/xml.

  • Optional additional documents. These may include any relevant documents, images, or healthcare-specific items such as Transition of Care / Referral Summaries, Ambulatory Summaries or Inpatient Summaries.

  • A Request.txt that captures the context of the message in a semi-structured way.

Anatomy of Request.txt

In addition to the friendly message in the body, you may receive a request.txt. This is a simple way, much like robots.txt works to provide some semi-structured context to machines.

{% highlight text %} Destination: [Direct Address] Patient: [Patient Name] Data-holder: [Data Holder Name] Recurring: [Yes / No] {% endhighlight %}

An example of what a request.txt would look like:

{% highlight text %} Destination: [email protected] Patient: Ellen Ross Data-holder: Ashby Medical Center Recurring: Yes {% endhighlight %}

3. Frequency

For a given address, there is the likelihood that your application will receive multiple documents over a period of time. This will be especially so if the consumer sets up an "automated" transmission when ever their health data changes.

This is beneficial for your application, because it will be getting an up-to-date stream of data. However, your application may need to handle the merging of these transmissions. The means of this merge is up to you as the receiver and not part of Blue Button+ guidelines.

4. Blue Button+ Patient Trust Bundle {#bundle}

You need to submit the trust anchor for your application to the Blue Button+ Trust Bundle in order for a data holder participating in the Blue Button+ ecosystem to send messages to Direct addresses issued by your application. Follow these steps:

  1. Visit https://secure.bluebuttontrust.org
  2. Register your application
  3. Demonstrate that your application is secured via SSL/HTTPS
  4. Provide a link to the Model Privacy Notice on your website or in your application

Once your application's trust anchor is in the system, it will take 24-48 hours for data holders to sync your certificate.