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	Applicability Statement for Secure Health Transport Version 1.2	Final	Production		Yes	Free	Yes
Standard	HL7® FHIR® RESTful API	Final	Production		Yes	Free	Yes
Implementation Specification	Implementation Guide for Delivery Notification In Direct Version 1.0	Final	Production		Yes	Free	Yes
Implementation Specification	NCPDP® SCRIPT Standard, Implementation Guide, Version 2017071	Final	Production		Yes	$	Yes
Implementation Specification	Implementation Guide for Direct Edge Protocols Version 1.1	Final	Production		Yes	Free	Yes
Implementation Specification	XDR and XDM for Direct Messaging Specification Version 1.0	Final	Production		Yes	Free	Yes
Implementation Specification	Applicability Statement for Secure Health Transport Also known as the Direct Standard® 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	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 Version 1.1	Final	Production		No	Free	No
Implementation Specification	IHE-MHD (Mobile access to Health Documents)	Final	Production	Feedback Requested	No	Free	Yes Yes
Implementation Specification	Specialty Medication Enrollment HL7 FHIR	Final	Production		No	Free	No
Emerging Standard	ANSI/DS 2019-02-100-2021 - Trusted Instant Messaging Plus (TIM+) Applicability Statement Version 1.1.1	Final	Pilot	Feedback Requested	No	Free	No
Implementation Specification	NCPDP SCRIPT Standard, Implementation Guide, Version 2023011	Final	Feedback requested	Feedback Requested	Yes
Standard	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	Free	Yes

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 depend on establishing “trust” between two parties and vary based on the trust community(ies) to which parties belong. DirectTrust is a trust community which facilitates Direct communication among users for provider messaging and consumer-mediated exchange. The Direct Standard was approved as American National Standard ANSI/DS 2019-01-100-2021-Applicability Statement for Secure Health Transport Version 1.3. The ITU implementation specifications are Continual 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. As of September 30, 2012, ANSI/DS 2019-02-100-2021 the Trusted Instant Messaging Plus (TIM+) Applicability Statement was approved as an ANSI Standard version 1.1.1. 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, 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). The implementation guide for expressing context in Direct has been incorporated into the widely adopted Event Notifications via Direct Standard® and some organizations are sending metadata utilizing this model to communicate context according to the guide.	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 depend on establishing “trust” between two parties and vary based on the trust community(ies) to which parties belong. DirectTrust is a trust community which facilitates Direct communication among users for provider messaging and consumer-mediated exchange.
The Direct Standard was approved as American National Standard ANSI/DS 2019-01-100-2021-Applicability Statement for Secure Health Transport Version 1.3.
The ITU implementation specifications are Continual 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. As of September 30, 2012, ANSI/DS 2019-02-100-2021 the Trusted Instant Messaging Plus (TIM+) Applicability Statement was approved as an ANSI Standard version 1.1.1.
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, 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).
The implementation guide for expressing context in Direct has been incorporated into the widely adopted Event Notifications via Direct Standard® and some organizations are sending metadata utilizing this model to communicate context according to the guide.

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 2024-08-13

NCPDP Comment

NCPDP recommends removing NCPDP SCRIPT Standard, Implementation Guide, Version 2022011, as this version was never implemented. NCPDP SCRIPT Standard Implementation Guide, Version 2023011 is the next version named by CMS and Medicare. Federally required should be changed to a Yes for the NCPDP SCRIPT Standard Implementation Guide, Version 2023011.
NCPDP recommends removing NCPDP SCRIPT Standard, Implementation Guide, Version 2019071, as this version was never implemented. NCPDP SCRIPT Standard Implementation Guide, Version 2023011 is the next version named by CMS.
NCPDP recommends updating Standard NCPDP Pharmacist eCare Plan Version 1.0: Guidance on the Use of the HL7 CDA Consolidated Templates for Clinical Notes R2.1 Care Plan to have Cost updated to “Free”.

Submitted by pwilson@ncpdp.org on 2023-10-06

NCPDP Comment

NCPDP recommends that ONC add the following:

Type- Implementation Specification

Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2022011

Standards Process Maturity – Final

Implementation Maturity- Pilot

Adoption Level – 1

Federally Required – No

Cost – $

Test Tool Availability – No

NCPDP recommends that ONC update Specialty Medication Enrollment HL7 FHIR Type to “Implementation Specification”, Standards Process Maturity to “Final” and Implementation Maturity to “Production”.

Submitted by shellyspiro on 2023-10-02

Pharmacy HIT Collaborative (PHIT) comment

PHIT supports the following NCPDP recommendations: adding NCPDP SCRIPT Standard, Implementation Guide, Version 2022011 to the implementation specification; updating Specialty Medication Enrollment HL7 FHIR Type to implementation specification, Standards Process Maturity to final, and implementation maturity to production.

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.