Concrete Implementation Workgroup > IHE Implementation Development Team > IHE NHIN 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

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

XDR Specification - 2009

XDM:

Metadata used in XDR, XDS, XDM, XCA:

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.