Page History

...

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 360X Project relies upon the Direct standard, as defined by the Applicability Statement for Secure Health Transport, as it’s 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. An example is provided in Appendix A.

5.1.1 Certificate Discovery

...

The message body consists of the actual payload content. Payloads MAY be broken into of 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.

...

5.3.1 XDM

At the time of writing, there does not currently exist 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.

...

5.3.2 CDA Documents

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

...

The HL7 messages MUST be formatted according to Appendix C.