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

Printer Friendly, PDF & Email
Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 3
Yes
Free
Yes
Standard
Final
Production
Rating 2
Yes
Free
Yes
Standard
Balloted Draft
Pilot
Rating 1
No
Free
No
Implementation Specification
Final
Production
Rating 3
No
Free
Yes
Implementation Specification
Final
Production
Rating 3
No
Free
Yes
Implementation Specification
Final
Production
Rating 3
No
Free
Yes
Implementation Specification
Final
Production
Rating 4
No
Free
Yes
Emerging Standard
Final
Production
Rating 1
No
Free
No
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 NwHIN Specification: Authorization Framework implementation specification is based upon the underlying standards: SAML v1.2, XSPAv1.0, and WS-1.1.
  • “Direct” standard 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.

Comment

Use of Direct for System-to-System Communication

There are many systems in the field today that have Direct-enabled endpoints in use to send or accept data for automated workflows at the system level. This model is most commonly used in care coordination, public health, and related applications. We see a lot of continued growth in the number of organizations joining Direct networks to take advantage of the system-to-system transmission enabled by Direct. Adoption Level of 1 understates this use and I encourage ONC to increase the stated Adoption Level to 2 or 3.  

Julie Maas

CEO, EMR Direct