An Unsolicited “Push” of Clinical Health Information to a Known Destination Between Systems

Type	Standard / Implementation Specification	Standards Process Maturity	Implementation Maturity	Federally required	Cost	Test Tool Availability
Standard	SOAP-Based Secure Transport Requirements Traceability Matrix (RTM) version 1.0 specification	Final	Production	Yes	Free	Yes
Standard	Direct (Applicability Statement for Secure Health Transport v1.2)	Final	Production	Yes	Free	Yes
Standard	HL7® FHIR® DSTU 2	Balloted Draft	Pilot	No	Free	No
Standard	HL7® FHIR® R4	Final	Production	No	Free	No
Implementation Specification	eHealth Exchange Specification: Messaging Platform	Final	Production	No	Free	Yes
Implementation Specification	eHealth Exchange Specification: Authorization Framework	Final	Production	No	Free	Yes
Implementation Specification	eHealth Exchange Specification: Document Submission	Final	Production	No	Free	Yes
Implementation Specification	IHE-XDR (Cross-Enterprise Document Reliable Interchange)	Final	Production	No	Free	Yes
Implementation Specification	NCPDP SCRIPT Standard, Implementation Guide, Version 2017071	Final	Production	No	$	Yes
Implementation Specification	NCPDP SCRIPT Standard, Implementation Guide, Version 2019071	Final	Pilot	No	$	Yes

Limitations, Dependencies, and Preconditions for Consideration	Applicable Security Patterns for Consideration
The IHE-XDR implementation specification is based upon the underlying standards: SOAP v2, and OASIS ebXML Registry Services 3.0 The eHealth Exchange Specification: Authorization Framework implementation specification is based upon the underlying standards: SAML v1.2, XSPAv1.0, and WS-1.1. “The Direct Standard”(TM) is based upon the underlying standard: 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. 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). The reference to FHIR for this interoperability need is in relation to the transport services that are conformant to the “RESTful FHIR API” See Direct, FHIR, and IHE projects in the Interoperability Proving Ground.	Secure Communication – create a secure channel for client-to-server and server-to-server communication. Secure Message Router – securely route and enforce policy on inbound and outbound messages without interruption of delivery. Authentication Enforcer – centralized authentication processes. Authorization Enforcer – specifies access control policies . Credential Tokenizer – encapsulate credentials as a security token for reuse (e.g., – SAML, Kerberos). Assertion Builder – define processing logic for identity, authorization and attribute statements. User Role – identifies the role asserted by the individual initiating the transaction. Security Labeling – the health information is labeled with security metadata necessary for access control by the end user. Purpose of Use - Identifies the purpose for the transaction.

Limitations, Dependencies, and Preconditions for Consideration

Applicable Security Patterns for Consideration

The IHE-XDR implementation specification is based upon the underlying standards: SOAP v2, and OASIS ebXML Registry Services 3.0
The eHealth Exchange Specification: Authorization Framework implementation specification is based upon the underlying standards: SAML v1.2, XSPAv1.0, and WS-1.1.
“The Direct Standard”(TM) is based upon the underlying standard: 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.
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).
The reference to FHIR for this interoperability need is in relation to the transport services that are conformant to the “RESTful FHIR API”
See Direct, FHIR, and IHE projects in the Interoperability Proving Ground.

Secure Communication – create a secure channel for client-to-server and server-to-server communication.
Secure Message Router – securely route and enforce policy on inbound and outbound messages without interruption of delivery.
Authentication Enforcer – centralized authentication processes.
Authorization Enforcer – specifies access control policies .
Credential Tokenizer – encapsulate credentials as a security token for reuse (e.g., – SAML, Kerberos).
Assertion Builder – define processing logic for identity, authorization and attribute statements.
User Role – identifies the role asserted by the individual initiating the transaction.
Security Labeling – the health information is labeled with security metadata necessary for access control by the end user.
Purpose of Use - Identifies the purpose for the transaction.

About the ISA

ISA Content

ISA Sections

Appendices

Specialty Care and Settings

ISA Publications

Recent ISA Updates

21st Century Cures

An Unsolicited “Push” of Clinical Health Information to a Known Destination Between Systems

Comment