The document discusses delivery notifications in Direct, which allow for timely and predictable acknowledgement of whether a Direct message was successfully delivered. It notes that while the Direct specification allows for acknowledgements, it does not require them. The workgroup identified this as a concern for laboratories required to confirm delivery under CLIA. The document then presents an implementation guide detailing how sending and receiving systems can implement delivery notifications in both single-STA and dual-STA environments to indicate success or failure. It provides examples and answers common questions about delivery notifications in Direct.

1. Delivery Notifications in Direct
Background & Implementation Guidance
John Hall
Principal, Krysora
Coordinator, Direct Project
Greg Meyer
Director, Distinguished Engineer, Cerner Corporation
Leader, Direct Project Reference Implementation
Workgroup

2. • 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 issues
3. 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

3. • 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 WG
Identified Concerns
3

4. • 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

5. 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.

6. • 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

7. Notification in a single-STA environment:
Success Flow
7

8. • 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

9. 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

10. 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

11. Notification in a dual-STA environment:
Success Flow
11

12. • 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

13. Example Delivery Notification Request
MIME-Version: 1.0
Date: Wed, 31 Jul 2013 19:24:25 +0000 (UTC)
From: gm2552@direct.securehealthemail.com
To: gm2552@demo.sandboxcernerdirect.com
Message-ID: <13755908.0.1375298708291.JavaMail.Administrator@WIN-22T8SC15GKI>
Subject: Test timely and reliable 3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Disposition-Notification-Options: X-DIRECT-FINAL-DESTINATION-DELIVERY=optional,true
Just a test
8/14/2013
Office of the National Coordinator for
Health Information Technology
13

14. Example Dispatched MDN
to: gm2552@direct.securehealthemail.com
MIME-Version: 1.0
content-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-e8e4c50755ef
subject: Delivered: Test timely and reliable 3
From: gm2552@demo.sandboxcernerdirect.com
Delivered-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.1375298758189
content-type: message/disposition-notification
Reporting-UA: demo.sandboxcernerdirect.com; CernerDirect Edge Protocol Delivery
Final-Recipient: rfc822; gm2552@demo.sandboxcernerdirect.com
Original-Message-ID: 13755908.0.1375298708291.JavaMail.Administrator@WIN-22T8SC15GKI
X-DIRECT-FINAL-DESTINATION-DELIVERY:
Disposition: automatic-action/MDN-sent-automatically;dispatched
------=_Part_3681_1699588.1375298758189--
8/14/2013
Office of the National Coordinator for
Health Information Technology
14

15. 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

16. 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

17. Useful Links
• Direct Project Wiki
http://wiki.directproject.org
• Applicability Statement for Secure Health Transport – the normative specification
defining Direct transport
http://wiki.directproject.org/Applicability+Statement+for+Secure+Health+Transpor
t
• 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+Notifi
cation+in+Direct+v1.0.pdf
• Direct Project Implementation Geographies Workgroup – regular meetings of
communities and vendors that are implementing or have implemented Direct
http://wiki.directproject.org/Implementation+Geographies
• Direct Project Reference Implementation Workgroup – Java and .NET open source
reference implementations of Direct Project specifications
http://wiki.directproject.org/Reference+Implementation+Workgroup
17

18. Questions?