Package Structure and Transport

The following diagrams are provided to help orient the reader to the sections that will follow. The Guide will define and provide examples for the transport protocol and the contents of the payload: XDM request package wrapper, and request package contents for the order, status, result and associated patient information.

An effort has been made in this specification to define the transactions in a way that is most consistent with current application behaviors and existing standards to ease implementation and speed adoption. Most systems manage requests for consultation internally as request items managed on a worklist or other means. When the application logic determines that the request is for a destination to another system, but within the environs of the enterprise network, the request is translated to an HL7 order and is managed between systems with order status updates, scheduling messages, and / or result transactions. Patient information needed with the order is usually limited because the primary patient data is available to requester and request recipient inside the enterprise environs. To keep that behavior consistent but extend it to disparate systems across enterprise environs where networks may be public and where comprehensive, latest patient data may not be available from the requester's system; this Guide seeks to reuse the HL7 order concepts, augment them with robust associated clinical data, and wrap and transport them via accepted transport protocols to support network scalability.

The first diagram intends to depict this concept of a processing and transaction "onion" for requester and recipient processing. It is not intended as a design diagram or to drive application function, but simply to illustrate the point that layers are added to the base request to handle each processing complexity that is added with the requirement to manage the request outside a single system, between disparate environs, over public networks.

Figure 5.1 can then be elaborated in the context of the requester:

This processing flow leads us to the payload component summary below:

5.1 Transport Protocol

The 360X Project relies upon the Direct standard, as defined by the Applicability Statement for Secure Health Transport, as its vehicle for information exchange. All message exchanges between disparate systems MUST be transported using the Direct transport specification.

The Direct transport defines the input and output of the STA as an Internet Message Format document conforming to RFC5322 with a valid MIME body. As such, all payloads MUST be enveloped within a RFC5322 message. A message contains two parts: header section and a body with content described by the message’s Content-Type header.

5.1.1 Certificate Discovery

When the location of an X509 certificate associated to a Direct address (either address or organizationally bound) is unknown, all STA attempts to dynamically locate the certificate SHOULD use the discovery methodology described in the S&I framework’s Implementation Guide for Certificate Discovery to facilitate universal interoperability. STAs MAY use alternate or out of band methods to discover or exchange certificates.

5.1.2 Quality of Service

The Applicability Statement for Secure Health Transport only requires a positive acknowledgement of message receipts when an STA successfully decrypts a message and validates trust; it provides little to no guidance on failed message exchange. To promote consistent transport behavior and provide higher levels of message delivery assurance, message transport MUST comply with the implementation guide for delivery notification. Consequently, the sending edge client MAY set the header with the expectation of receiving an MDN. However, the receiving STA MUST honor the request and send an MDN upon receiving the custom header from the edge client.

5.1.3 SMTP Message Headers

The header section of the RFC5322 message MUST contain the required headers as specified in the applicability statement. These consist of:

• to
• from
• orig-data
• message-id
• subject (While not specified in the applicability statement, the 360x message MUST contain a message subject header with text containing the substring "XDM/1.0/DDM+360x")

The header section of the RFC 5322 message, which is in reference to a previous message for the same referral, SHOULD also contain the following headers:

• in-reply-to
• references

The message MAY contain additional headers as needed for appropriate routing and transport context.

5.2 SMTP Message Body

The message body consists of the actual payload content. Payloads MAY be broken into one or more content parts with each part containing either human readable content or an attachment. Although a message may consist of only a single part, the Content-Type of the message SHALL be multipart/mixed consisting of one or more body parts. The message SHALL contain a human readable part even if it contains no content.

Generally, most mail packages and rendering engines can handle multipart/mixed messages even if only a single human readable part or attachment exists.

Given that the message content type is multipart/mixed, the message body must conform to the multipart media type as described by RFC 2046 section 5.1. The body parts are not ordinal meaning that the sequence in which each part appears in the message is irrelevant.

5.2.1 Human Readable Text

The message body MAY contain human readable text. If there is human readable text, the Content-Type SHALL be one of the following three types:

•  text/plain – Content type for representing plain, non marked up text.
• multipart/alternative – Content type when the content may be represented in multiple formats. If the type is multipart/alternative, text/plain MUST be one of the alternative types.
• text/html – Content type for representing marked up text (HTML file)

While human readable text may be included in body parts beyond the 360X payload package, this implementation guide is silent on the use of this option, and there is no expectation regarding the presentation and conveyance of the human readable text to a user. Implementers are encouraged to utilize fields available within the 360X messages and documents to convey narrative information and are cautioned that content outside of the 360X specified payload may not be displayed and/or may be discarded by receiving systems. As such, implementers are advised to limit the use of such additional body parts to informational updates of a non-urgent, non-clinical nature only.

5.2.2 Non Human Readable Text

The message body SHALL contain one body part, containing the required minimal structured content as determined by the 360X Project, and MAY contain additional structured or non-structured parts.

5.3 Content Representation

The following sections specify how certain use case specific content should be represented in an RFC5322 message.

5.3.1 XDM

At the time of writing, an IANA registered MIME content type for XDM zip files does not exist. XDM files MUST be represented by a message body part of type application/zip.

The Cross-enterprise Document Media Interchange (XDM) profile is defined by IHE (see ITI Technical Framework, Volume 2, section 32) and provides the overall packaging structure for the 360X Payload, as recommended in the Direct specification (see page 7 in the Applicability Statement for Secure Health Transport), and in conformance with the XDR and XDM for Direct Messaging Specification.

The XDM package is a single ZIP file with the following structure:

XDM_SAMPLE.ZIP+--README.TXT
              |
              +--INDEX.HTM
              |
              +--IHE_XDM-------SUBSET01+--DOC00001.XML
              |                        |
              |                        +--DOC00002.HL7
              |                        |
              |                        +--METADATA.XML
              |                        |
              |                        + ... (may contain other files, not referenced in the METADATA.XML file)
              |
              + ... (any other files and directories may be present)

The XDM structure as defined by IHE is generic, and allows for multiple Submission Sets to be present (inside the IHE_XDM directory). For the purposes of the Direct protocol, and in particular for the 360X project, the XDM package shall contain exactly one submission set.

The IHE XDM profile also mentions "multipart" documents within the submissions set. This structure SHALL NOT be used in a 360X conformant XDM package.

The purpose and requirements for the README.TXT and INDEX.HTM files are described on pages 95-96 of the IHE ITI Technical Framework, Vol. 2b.

Requirements:

PS01: The XDM package shall contain a single submission set. The submission set shall contain information for a single patient.

5.3.2 CDA Documents

At the time of writing, an IANA registered MIME content type for CDA or any specific types of CDA documents (C-CDA, CCD, etc) does not exist. CDA based documents MUST be represented by a MIME type of text/xml.

5.3.3 HL7 Files

HL7 Version 2.x is a messaging standard for the exchange of healthcare information. The standard has several versions, with the latest being 2.8.2, which was published in 2015. There are several messages from HL7 Version 2.5.1 already required in the 2014 and 2015 Certification Edition. This implementation guide will also use HL7 Version 2.5.1 messages to represent various state transitions and workflow information, while borrowing a few details from newer versions. This common practice is already in use in the ONC Certification Edition requirements for laboratory orders and laboratory results. The HL7 messages will be part of the XDM package as illustrated in sections 6.1.1 and 7.1.1. HL7 files MUST be represented by a MIME type of x-application/hl7-v2+er7 in the XD Metadata

The HL7 messages MUST be formatted according to Appendix C.