An Unsolicited "Push" of Clinical Health Information to a Known Destination and Information System User

Type	Standard / Implementation Specification	Standards Process Maturity	Implementation Maturity	Adoption Level	Federally required	Cost	Test Tool Availability
Standard	Direct™ (Applicability Statement for Secure Health Transport v1.2)	Final	Production		Yes	Free	Yes
Standard	HL7® FHIR® RESTful API	Final	Production		Yes	Free	Yes
Implementation Specification	IG for Delivery Notification in Direct	Final	Production		Yes	Free	Yes
Implementation Specification	NCPDP® SCRIPT Standard, Implementation Guide, Version 2017071	Final	Production		Yes	$	Yes
Implementation Specification	IG for Direct Edge Protocols	Final	Feedback requested		Yes	Free	Yes
Implementation Specification	XDR and XDM for Direct Messaging Specification	Final	Production		Yes	Free	Yes
Implementation Specification	Applicability Statement for Secure Health Transport Version 1.3	Final	Production		Yes	Free	Yes
Implementation Specification	IHE-XDR (Cross-Enterprise Document Reliable Interchange)	Final	Production		No	Free	Yes Yes Yes
Implementation Specification	NCPDP Pharmacist eCare Plan Version 1.0: Guidance on the Use of the HL7 CDA Consolidated Templates for Clinical Notes R2.1 Care Plan	Final	Production		No	$	No
Implementation Specification	NCPDP SCRIPT Standard, Implementation Guide, Version 2019071	Final	Production		No	$	No
Implementation Specification	ITU H.810, H.811, H.812, and H.813	Final	Production		No	Free	Yes
Implementation Specification	Implementation Guide for Expressing Context in Direct Messaging v1.1	Final	Production		No	Free	No
Implementation Specification	IHE-MHD (Mobile access to Health Documents)	Final	Production	Feedback Requested	No	Free	Yes Yes
Emerging Standard	Specialty Medication Enrollment HL7 FHIR	Balloted Draft	Pilot		No	Free	No
Emerging Standard	DirectTrust™ Trusted Instant Messaging Plus (TIM+)	Balloted Draft	Pilot	Feedback Requested	No	Free	No

Limitations, Dependencies, and Preconditions for Consideration	Applicable Security Patterns for Consideration
This interoperability need also includes transport for the following purposes, primarily using the Direct Standard: The Direct Standard is based upon the underlying Simple Mail Transfer Protocol (SMTP) RFC 5321 and for security uses Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification, RFC 5751. Transport for Transition of Care or Referral to Another Health Care Provider. Transport for a Notification of a Patient’s Admission, Discharge and/or Transfer Status to Other Providers. For Direct, interoperability may be dependent on the establishment of “trust” between two parties and may vary based on the trust community(ies) to which parties belong. The leading trust communities to enable communication amongst the most users include DirectTrust (for provider messaging and consumer-mediated exchange) and NATE (for consumer-mediated exchange). DirectTrust Standards announced that the Direct Standard has been approved as American National Standard ANSI/DS 2019-01-100-2021-Applicability Statement for Secure Health TransportVersion 1.3. The new version has been submitted to the SVAP process in 2021 and is under consideration. The ITU implementation specifications are Continua Design Guidelines, developed to provide a suite of open industry standards and specifications that provide several means to end-to-end interoperability between personal medical devices and health information systems. Unrestricted access to the implementation specification: http://www.pchalliance.org/continua-design-guidelines . The DirectTrust Trusted Instant Messaging Plus standard provides secure instantaneous communication via the XMPP standard between servers allowing for federated trust communities and cross-platform communication. The draft standard supports text-based communication, file transfers, group messaging, and "presence". Future versions of the Standard are expected to support audio and video communications. See Direct and IHE projects in the Interoperability Proving Ground. IHE-MHD is very similar to IHE-XDR, but uses FHIR. The typical use case for MHD in this mode is when documents are known to be needed by a recipient. Such as a patient referral in the use case given in XDR. In addition, the MHD can be used as a push API to a system that ultimately delivers the content. For example, diagrammed below is MHD initiating a push to an Intermediary. In this use case the MHD push request could be handled by the intermediary that further pushes the content using XDR or an e-mail carrying XDM (e.g., the Direct Project). On the recipient side, the MHD could be used by an intermediary to forward a XDR or XDM push content. MHD could also be used on the recipient side as a query/retrieve where the intermediary has cached content addressed to that recipient. This Intermediary is an example of a Direct Project HISP with the added functionality provided by MHD, enabling FHIR based push with end-to-end interoperability between three different transport stacks in MHD, XDR, and e-mail XDM. The Applicability Statement for Secure Health Transport Version 1.3 is a newer version of the standard that is available for health IT developers to voluntarily update and provide to their customers. It became available when it was added to the Approved Standards for 2022 through ONC’s Standards Version Advancement Process (SVAP).	System Authentication – The information and process necessary to authenticate the systems involved. Recipient Encryption – The message and health information are encrypted for the intended user. Sender Signature – Details that are necessary to identity of the individual sending the message. Secure Communication – Create a secure channel for client-to- serve and server-to-server communication. Secure Message Router – Securely route and enforce policy on inbound and outbound messages without interruption of delivery. Patient Consent Information - Identifies the patient consent information that may be required before data can be accessed. May be required to authorize any exchange of patient information. May be required to authorize access and use of patient information. May be required to be sent along with disclosed patient information. Advise the receiver about policies to which end users must comply. Security Labeling – The health information is labeled with security metadata necessary for access control by the end user.

Limitations, Dependencies, and Preconditions for Consideration

Applicable Security Patterns for Consideration

This interoperability need also includes transport for the following purposes, primarily using the Direct Standard: The Direct Standard is based upon the underlying Simple Mail Transfer Protocol (SMTP) RFC 5321 and for security uses Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification, RFC 5751.
- Transport for Transition of Care or Referral to Another Health Care Provider.
- Transport for a Notification of a Patient’s Admission, Discharge and/or Transfer Status to Other Providers.
For Direct, interoperability may be dependent on the establishment of “trust” between two parties and may vary based on the trust community(ies) to which parties belong. The leading trust communities to enable communication amongst the most users include DirectTrust (for provider messaging and consumer-mediated exchange) and NATE (for consumer-mediated exchange).
DirectTrust Standards announced that the Direct Standard has been approved as American National Standard ANSI/DS 2019-01-100-2021-Applicability Statement for Secure Health TransportVersion 1.3. The new version has been submitted to the SVAP process in 2021 and is under consideration.
The ITU implementation specifications are Continua Design Guidelines, developed to provide a suite of open industry standards and specifications that provide several means to end-to-end interoperability between personal medical devices and health information systems. Unrestricted access to the implementation specification: http://www.pchalliance.org/continua-design-guidelines .
The DirectTrust Trusted Instant Messaging Plus standard provides secure instantaneous communication via the XMPP standard between servers allowing for federated trust communities and cross-platform communication. The draft standard supports text-based communication, file transfers, group messaging, and "presence". Future versions of the Standard are expected to support audio and video communications.
See Direct and IHE projects in the Interoperability Proving Ground.
IHE-MHD is very similar to IHE-XDR, but uses FHIR. The typical use case for MHD in this mode is when documents are known to be needed by a recipient. Such as a patient referral in the use case given in XDR. In addition, the MHD can be used as a push API to a system that ultimately delivers the content. For example, diagrammed below is MHD initiating a push to an Intermediary. In this use case the MHD push request could be handled by the intermediary that further pushes the content using XDR or an e-mail carrying XDM (e.g., the Direct Project).
On the recipient side, the MHD could be used by an intermediary to forward a XDR or XDM push content. MHD could also be used on the recipient side as a query/retrieve where the intermediary has cached content addressed to that recipient. This Intermediary is an example of a Direct Project HISP with the added functionality provided by MHD, enabling FHIR based push with end-to-end interoperability between three different transport stacks in MHD, XDR, and e-mail XDM.
The Applicability Statement for Secure Health Transport Version 1.3 is a newer version of the standard that is available for health IT developers to voluntarily update and provide to their customers. It became available when it was added to the Approved Standards for 2022 through ONC’s Standards Version Advancement Process (SVAP).

System Authentication – The information and process necessary to authenticate the systems involved.
Recipient Encryption – The message and health information are encrypted for the intended user.
Sender Signature – Details that are necessary to identity of the individual sending the message.
Secure Communication – Create a secure channel for client-to- serve and server-to-server communication.
Secure Message Router – Securely route and enforce policy on inbound and outbound messages without interruption of delivery.
Patient Consent Information - Identifies the patient consent information that may be required before data can be accessed.
- May be required to authorize any exchange of patient information.
- May be required to authorize access and use of patient information.
- May be required to be sent along with disclosed patient information.
- Advise the receiver about policies to which end users must comply.
Security Labeling – The health information is labeled with security metadata necessary for access control by the end user.

Comment

Submitted by pwilson@ncpdp.org on 2021-09-29

NCPDP Comments

NCPDP SCRIPT Standard, Implementation Guide, Version 2017071 - Update adoption level to 5.
NCPDP SCRIPT Standard, Implementation Guide, Version 2019071 - This version has been published and available by trading partner agreement. Currently 2017071 is required by Medicare Part D and ONC certification.

Submitted by John Moehrke on 2021-09-08

IHE - Mobile Access to Health Documents

The IHE Mobile Access to Health Documents (MHD) includes support for PUSH based exchanges. This functionality is very similar to XDR, but uses FHIR. see IHE publication -- https://profiles.ihe.net/ITI/HIE-Whitepaper/index.html#:~:text=the%20three%20models.-,3.1%20Push,-3.1.1%20Cross-Enterprise The MHD Profile provides a point-to-point method of sending documents to a specific recipient. It leverages common principles described in Section 2. It sends documents and metadata using FHIR Rest push to deliver one or more documents to a Document Recipient. The typical use case for MHD in this mode is when documents are known to be needed by a recipient. Such as a patient referral in the use case given in XDR. In addition the MHD can be used as an push API to a system that ultimately delivers the content. For example diagrammed below is MHD initiating a push to an Intermediary. In this use case the MHD push request could be handled by the intermediary that further pushes the content using XDR or an e-mail carrying XDM (e.g., the Direct Project). On the recipient side (not shown in the diagram) the MHD could be used by an intermediary to forward a XDR or XDM push content. MHD (not shown in the diagram) could also be used on the recipient side as a query/retrieve where the intermediary has cached content addressed to that recipient. This Intermediary is an example of a Direct Project HISP with the added functionality provided by MHD, enabling FHIR based push with end-to-end interoperability between three different transport stacks in MHD, XDR, and e-mail XDM.

About the ISA

ISA Content

ISA Sections

Appendices

Specialty Care and Settings

ISA Publications

Recent ISA Updates

An Unsolicited "Push" of Clinical Health Information to a Known Destination and Information System User

Comment

NCPDP Comments

IHE - Mobile Access to Health Documents