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

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 4
Yes
Free
Yes
Standard
Final
Production
Rating 5
Yes
Free
Yes
Implementation Specification
Final
Production
Rating 2
Yes
Free
Yes
Implementation Specification
Final
Production
Rating 3
Yes
Free
Yes
Implementation Specification
Final
Production
Rating 4
Yes
Free
Yes
Implementation Specification
Final
Production
Rating 1
No
Free
Yes
Emerging Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
No
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • 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 to
    • 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

IG for Expressing Context in Direct Messaging as Draft Standard

As President and CEO of DirectTrust and representing the DirectTrust community, I would encourage ONC to include the Direct Project's "Implementation Guide for Expressing Context in Direct Messaging" as a balloted draft standard in this section of the ISA. 

First publish by the Direct Project as a Draft for Trial Use in December, 2016, this IG has been widely welcomed as a very useful addition to the Direct Standard, one that solves several problems experienced by many users of Direct exchange in the real world.  

This IG document defines an extensible mechanism to express the context of a Direct message exchange by providing a framework for the inclusion of contextual metadata by the message sender. Such metadata may be helpful for routing and processing of Direct messages, such as in cases where the payload format contains limited or no intrinsic metadata, or when the reason for the transmission may not be easily determined from the payload content.

The framework was designed so that the metadata could also be available to users of non-conforming applications in a human-readable format. A separate attachment containing the payload metadata was selected over a series of RFC 822 headers, as such headers may not be as easily viewed by all Mail User Agents (MUAs). Similarly, human-readable metadata parameters and values were selected over Object Identifiers (OIDs) or other non-human-readable representations.

With very kind regards, David C. Kibbe, President and CEO, DirectTrust

IG for Expression of Context in Direct Messages a Draft Standard

As President and CEO of DirectTrust and representing the DirectTrust community, I would encourage ONC to include the Direct Project's "Implementation Guide for Expressing Context in Direct Messaging" as a balloted draft standard in this section of the ISA. 

First publish by the Direct Project as a Draft for Trial Use in December, 2016, this IG has been widely welcomed as a very useful addition to the Direct Standard, one that solves several problems experienced by many users of Direct exchange in the real world.  

This IG document defines an extensible mechanism to express the context of a Direct message exchange by providing a framework for the inclusion of contextual metadata by the message sender. Such metadata may be helpful for routing and processing of Direct messages, such as in cases where the payload format contains limited or no intrinsic metadata, or when the reason for the transmission may not be easily determined from the payload content.

The framework was designed so that the metadata could also be available to users of non-conforming applications in a human-readable format. A separate attachment containing the payload metadata was selected over a series of RFC 822 headers, as such headers may not be as easily viewed by all Mail User Agents (MUAs). Similarly, human-readable metadata parameters and values were selected over Object Identifiers (OIDs) or other non-human-readable representations.

With very kind regards, David C. Kibbe, President and CEO, DirectTrust

IG for Expression of Context in Direct Messages

As a member of the Direct Project Team, I wish to highlight the work in progress.  The IG for Expression of Context in Direct Messages creates a mechanism for edge systems to interpret message attachments other than C-CDA or XDM payloads.  Through the use of a metadata attachment, there is a mechanism for patient identification as well as payload format.  It relieves the need for specific subject line data or attachment types or names.  

This IG extends usability and interoperability for the Direct Protocol.

Bruce Schreiber

CTO, MaxMD

Carrying Large Payloads via the Direct Protocol (RFC2046 5.2.2)

As a member of the Direct Project Team, I wish to highlight a second Direct Protocol Extension that is being worked on.  The Direct Project has been actively discussing and testing an extension to Direct that supports large payloads.  The objective is to transport DICOM studies or other image based payloads that exceed the normal SMTP limits of about 10 MB. 

RFC2046 section 5.2.2 offers a specification for SMTP fragmentation that when combined with the Direct Protocol answers this question.  RFC2046 Fragmentation was never widely adapted as it introduced SMTP attack vectors that could be harmful to most SMTP servers.  The Direct Protocol solves these issues as untrusted fragments are immediately dropped, thus deflecting any potential SMTP attack. 

With a clever merging of the RFC2046 concepts and the Direct Protocol Trust, Encryption, and Notification features, the need for expensive persistent connections can be replaced with Direct Protocol transport.  

Bruce Schreiber

CTO, MaxMD

Implementation Guide for Expressing Context in Direct Messaging

I encourage ONC to include the Direct Project's "Implementation Guide for Expressing Context in Direct Messaging" as a draft standard in this section of the ISA.

Expected benefits from the Context IG's extensible structure include the following initial use cases:

  • Asserting demographic information that can be used for patient matching and other characteristics of an endpoint
  • Providing message metadata for content types that don't already have it, e.g. PDFs, certain image types, plain text
  • Allowing greater workflow automation
  • Signaling a transaction type other than Transitions of Care, e.g. laboratory requests, radiology results, general notifications, etc.
  • Encapsulating transactions such as a FHIR (or any other) query request/response transaction, HL7 message and acknowledgement, etc. as the payloads of secure Direct messages, leveraging established trust policies
  • Providing a mechanism for the recipient to respond indicating that a specific transaction type is unsupported 

To help measure the Adoption Level, I would note that at the 10/19 Direct Project connect-a-thon, EMR Direct and Surescripts successfully piloted Context-enabled messages and a few additional organizations reported receiving Context successfully, with no issues reported by the other receiving parties who were sent a message with Context. This warrants at least Pilot status in the ISA.

There is a lot of enthusiasm about how adopting the basic Context framework defined in the current IG provides a foundation for a wide range of uses for Direct messaging in the future. The framework is designed so that additional use cases can be supported. Here are a few examples that have been discussed in the community:

  • Informing message senders of certain Edge-specific failures, such as payload-related failures that occur beyond the HISP, even after a successful "Dispatched" notification has been received. A Context-enabled response may be sent using an associated Message ID, even if the original message did not include Context.
  • Ability to tag a message with communication preferences for response--e.g. "Reply Requested", "Preserve Recipient List for Collaboration Purposes", or "For person listed in Subject field only".
  • Including assertions regarding authentication, such as whether mutli-factor authentication was used or is always required to authenticate to the account, or other assertions relevant to 800-63-3
  • Signaling other workflow- and content-related information not necessarily reflected in current metadata schemes, such as large messages as a transaction type

Julie Maas

CEO, EMR Direct

Link has been updated -…

Link has been updated - thank you for bringing this to our attention.