Delivery Notifications in Direct Background & Implementation Guidance

Delivery Notifications in Direct

Background & Implementation Guidance

John HallPrincipal, KrysoraCoordinator, Direct Project

Greg MeyerDirector, Distinguished Engineer, Cerner CorporationLeader, Direct Project Reference Implementation Workgroup

• The laboratory industry expressed concerns regarding the potential impact of Direct on laboratory accreditation

• In response, ONC formed the Direct – Laboratory Reporting Workgroup in Q4 2011 that included labs, accrediting agencies, and CLIA

• Charge:1. Identify any regulatory and operational issues with Direct that prevent or limit

adoption by clinical laboratories for transmitting the “Report of Record” to the Final Report Destination

2. Identify mitigation strategies for each of the issues3. For regulatory issues, work with ONC and CMS/CLIA to ensure that, where

appropriate, guidance is issued to accrediting agencies to enable the use of Direct for lab reporting

Background

2

• Timely and predictable acknowledgement of delivery success or failure– Under CLIA, labs are responsible for delivering reports to the Final Report

Destination, and must know when report delivery has succeeded or failed– Existing mechanisms for report delivery provide timely and predictable

acknowledgement of success and failures

• Direct Project’s Applicability Statement for Secure Health Transport specification allows for acknowledgements of delivery success or failure, but does not require them– Security/Trust Agents (STAs), such as HISPs, that receive a Direct Message

MUST acknowledge successful receipt and trust verification of a Message by sending a Message Disposition Notification (MDN) with a processed disposition (i.e., a processed MDN)

– STAs / HISPs MAY issue other notifications under other conditions but are not required to do so

Direct – Laboratory Reporting WGIdentified Concerns

3

• Guide details how to implement timely, predictable acknowledgement of positive or negative delivery within a Direct context

• Requires STAs to indicate successful or failed delivery to destinations

• Guide details how to request destination delivery notifications, what constitutes a delivery “success” or “failed” notification, and the responsibilities of the Sending and Receiving STAs around these notifications

• Guide provides use cases that illustrate when and under what circumstances “success” and “failed” notifications could be sent

Implementation Guide for Delivery Notification in Direct

4

It’s important to note that these delivery notifications are not lab-specific. The specified delivery notifications can be used as part of any transaction to provide predictable, timely acknowledgement of delivery success or failure, including:

• Closed-loop referrals (360X Project)

• Transactions with federal partners

Use of Delivery Notifications

5

If you need to track transactions, such as for Meaningful Use measures, delivery notifications also can be a useful and valuable way to determine if transactions have been successful.

• In a single STA environment, the STA positively knows when delivery to a destination (i.e., Receiver’s system or inbox) has succeeded or failed

• Requirement: The STA must notify the Sending system of successful or failed delivery to the destination

Notification in a single-STA environment(both parties using same STA)

6

Notification in a single-STA environment:Success Flow

7

• The Sender and Receiver (e.g., lab and ordering provider) may be using two different STAs, a Sending STA and Receiving STA

• The Sending STA on its own cannot tell when delivery to the destination (i.e., Receiver’s system or inbox) has succeeded, so each of the STAs – Receiving and Sending – have certain requirements that must be met

Notification in a dual-STA environment(each party using a different STA)

8

1. Must provide destination delivery notification messages upon request

2. Must notify Sending STA upon successful delivery to a destination by issuing a positive destination delivery notification message (i.e., a “successful delivery” message)

3. Must notify Sending STA upon failure to deliver to a destination by issuing a negative destination delivery notification message (i.e., a “failed delivery” message)

Notification requirements for Receiving STAs

9

1. Must request destination delivery notification messages from Receiving STA

2. Must notify the Sending system of failure to deliver to Receiving STA

3. Must notify the Sending system of failed or successful delivery to the destination based on any received positive or negative destination delivery notification messages

4. Must notify the Sending system of failed delivery to the destination if no processed MDN has been received from Receiving STA within a reasonable timeframe

5. Must notify the Sending system of failed delivery to the destination if no destination delivery notification messages have been received from Receiving STA within a reasonable timeframe

Notification requirements for Sending STAs

10

Notification in a dual-STA environment:Success Flow

11

• The need for destination delivery notifications is indicated within the Message Disposition Notification (MDN) request in the headers of the sent message– MDN request is as specified in RFC 3798, Section 2.1– MDN request contains a disposition notification options header per RFC 3798 Section 2.2

• Parameter named X-DIRECT-FINAL-DESTINATION-DELIVERY• Importance set to optional to prevent failure notifications from mail user agents –

however, HISPs and Direct gateways MUST honor the request despite the setting of optional

• Value set to true

• Positive destination delivery notification (i.e., “success”)– MDN disposition of dispatched– MDN extension-field of X-DIRECT-FINAL-DESTINATION-DELIVERY

• Negative destination delivery notification (i.e., “failure”)– MDN with a disposition of failed– Negative Delivery Status Notification (DSN)

Destination Delivery Notifications

12

Example Delivery Notification Request

MIME-Version: 1.0Date: Wed, 31 Jul 2013 19:24:25 +0000 (UTC)From: gm2552@direct.securehealthemail.comTo: gm2552@demo.sandboxcernerdirect.comMessage-ID: <13755908.0.1375298708291.JavaMail.Administrator@WIN-22T8SC15GKI>Subject: Test timely and reliable 3Content-Type: text/plain; charset=us-asciiContent-Transfer-Encoding: 7bitDisposition-Notification-Options: X-DIRECT-FINAL-DESTINATION-DELIVERY=optional,true

Just a test

04/11/2023 Office of the National Coordinator for Health Information Technology 13

Example Dispatched MDN

to: gm2552@direct.securehealthemail.comMIME-Version: 1.0content-type: multipart/report; report-type=disposition-notification; boundary="----=_Part_3681_1699588.1375298758189”Date: Wed, 31 Jul 2013 14:25:58 -0500 (CDT)message-id: b423edbe-bd70-4f0c-8998-e8e4c50755efsubject: Delivered: Test timely and reliable 3From: gm2552@demo.sandboxcernerdirect.comDelivered-To: gm2552@direct.securehealthemail.com

------=_Part_3681_1699588.1375298758189

Your message was delivered on Wednesday, July 24, 2013 9:21:55 AM CDT. If a read receipt was requested, you will get a separate email when the message is read.------=_Part_3681_1699588.1375298758189content-type: message/disposition-notification

Reporting-UA: demo.sandboxcernerdirect.com; CernerDirect Edge Protocol DeliveryFinal-Recipient: rfc822; gm2552@demo.sandboxcernerdirect.comOriginal-Message-ID: 13755908.0.1375298708291.JavaMail.Administrator@WIN-22T8SC15GKIX-DIRECT-FINAL-DESTINATION-DELIVERY: Disposition: automatic-action/MDN-sent-automatically;dispatched

------=_Part_3681_1699588.1375298758189--04/11/2023 Office of the National Coordinator for

Health Information Technology 14

1. What constitutes a “reasonable timeframe”?A: It’s use case dependent. In the context of lab reporting, a Sending STA serving a lab should wait for a destination delivery notification no longer than 1 hour before declaring the transmission a failure unless otherwise specified within an SLA with the lab.

2. Instead of these notifications, wouldn’t issuing “read receipts” suffice?A: No. There is no guarantee as to when a message will be read or if it will be read, thereby resulting in a receipt, and read receipts provide no mechanism for indicating delivery failure.

Delivery Notifications FAQ

15

3. Is there an implementation of this guide?A: Yes. Both the Java and .Net Direct Project reference implementations have full implementations of the guide.

4. Is there a way to test my implementation?A: ONC has a test guide that outlines 7 step by step test scenarios that covers 80%-90% of the “happy path” and “exception flows”. Only 2 test scenarios cover success; the rest focus on failure flows. Previously tests have been executed against a reference notification implementation.

Delivery Notifications FAQ

16

Useful Links

• Direct Project Wikihttp://wiki.directproject.org

• Applicability Statement for Secure Health Transport – the normative specification defining Direct transporthttp://wiki.directproject.org/Applicability+Statement+for+Secure+Health+Transport

• Implementation Guide for Delivery Notification in Direct – the guide defining positive and negative delivery notifications http://wiki.directproject.org/file/view/Implementation+Guide+for+Delivery+Notification+in+Direct+v1.0.pdf

• Direct Project Implementation Geographies Workgroup – regular meetings of communities and vendors that are implementing or have implemented Directhttp://wiki.directproject.org/Implementation+Geographies

• Direct Project Reference Implementation Workgroup – Java and .NET open source reference implementations of Direct Project specificationshttp://wiki.directproject.org/Reference+Implementation+Workgroup

17

Questions?