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.
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:
Your application must be able to:
The following diagram depicts a successful transmission. See it full-size.
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.
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.
Destination: [Direct Address] Patient: [Patient Name] Data-holder: [Data Holder Name] Recurring: [Yes / No]
An example of what a request.txt would look like:
Destination: email@example.com Patient: Ellen Ross Data-holder: Ashby Medical Center Recurring: Yes
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.
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:
Once your application’s trust anchor is in the system, it will take 24-48 hours for data holders to sync your certificate.