IHE Direct Specification
IHE Direct Specification
Status of this Specification
This specification is in Draft state.
IPR Statement
By contributing to this specification, all contributors warrant that all applicable patient or other intellectual policy rights have been disclosed and that any of which contributors are aware of will be disclosed in accordance with the Direct project IPR Policy.
Abstract
This is the specification description for the IHE based implementation defined by the IHE Implementation Development Team. This document presents the use of IHE XDR and XDM profiles, as specied by IHE, to satisfy the Direct User Stories and Direct Abstract Model.
The use of XDR is consistent with existing NHIN Specifications The overarching theme of this mapping is the use of currently existing and widely understood Internet technologies/services/standards
Table of Contents
Introduction
The IHE implementation of Direct is primarily distinguished by the fact that it focuses its efforts on pairing a defined, standardized, and industry-tested protocol for HISP backbone communication with flexible edge communications. Our implementation has focused on two primary goals
- 1) Support multiple edge protocols, providing a structure for and examples of swappable black boxes that can take generic inputs and transform them to appropriate XDR metadata.
- 2) Support a single backbone that can integrate seamlessly into existing interoperability infrastructure currently in place or under development in HIEs around the country
Purpose
This page presents a specification view of the IHE Direct Implementation.
Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
An implementation is not compliant if it fails to satisfy one or more of the MUST or REQUIRED level requirements for the protocols it implements. An implementation that satisfies all the MUST or REQUIRED level and all the SHOULD level requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the MUST level requirements but not all the SHOULD level requirements for its protocols is said to be "conditionally compliant."
Synopsis
| Area |
Transaction |
Payload |
Notes |
| Source to HISP |
Options (potentially more are applicable) a) XDR Provide and Register Transaction b) SMTP sending structured content c) XDM over email d) REST sending structured content e) REST carrying XDM zip file |
XDS metadata + document content or Structured content like CDA or CCD |
Although a) is inherent in the model supporting the other listed options as an edge protocol is simple |
| HISP to HISP |
XDR Provide and Register Transaction |
XDS metadata + document content formated as an MTOM/XOP attachment |
Special Direct requirements for use of intendedRecipient. Otherwise completely conformant to IHE XDR Specification. |
| Destination to HISP |
Options (potentially more are applicable) a) XDR Provide and Register Transaction b) XDM over email c) REST carrying XDM zip file |
XDS metadata + document content |
The IHE Concrete Implementation Capacity Worksheet contains details of:
- Abstract Model mapping - Section 4
- User Stories supported - Section 5
- Security & Trust - Section 6
The content of these sections will be moved to this specification once it is complete.
Security Considerations
All XDR transactions are secured using current NHIN standards, namely:
- TLS encription
- Mutually authenticated X.500 certificates
- SAML assertions as appropriate
Further details are available in the Security & Trust section of the IHE Concrete Implementation Capacity Worksheet .
Examples
This section is non-normative.
Examples will be added once the prototyple implementations are complete.
Authors
Karen Witting - IBM
References
- Overview - Section 16 of IHE ITI TF Volume 1
- Detailed Transaction - Section 3.32 of IHE ITI TF Volume 2b
Metadata used in XDR, XDS, XDM, XCA:
- Section 4.1.7 and 4.1.8 of IHE ITI TF Volume 3
Copyright
By contributing to this specification, all contributors agree to license contributions according to the Creative Commons Attribution 3.0 License which is incorporated into this document by reference.