Delivery Notifications in Direct Background & Implementation Guidance
Upcoming SlideShare
Loading in...5
×
 

Delivery Notifications in Direct Background & Implementation Guidance

on

  • 2,836 views

Direct Boot Camp 2.0

Direct Boot Camp 2.0

Statistics

Views

Total Views
2,836
Views on SlideShare
1,258
Embed Views
1,578

Actions

Likes
1
Downloads
12
Comments
0

12 Embeds 1,578

http://www.ahier.net 1477
http://8852684919029181544_72bbacf1329e217dafa25c3e01ab7d6ba8675714.blogspot.com 58
http://www.newsblur.com 12
https://twitter.com 11
http://newsblur.com 11
http://conversation.ecairn.com 2
http://www.inoreader.com 2
https://www.google.com 1
http://www.yatedo.com 1
http://www.wellsphere.com 1
http://cloud.feedly.com 1
http://reitbok4.rssing.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-ShareAlike LicenseCC Attribution-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Note: all MDNs are not delivery notifications, and all delivery notifications are not MDNs!
  • Note that both the Java and .NET free open-source software reference implementations support the Implementation Guide. If your solution is uses one of those, then it may already have support, or you can upgrade to get it. Even if your product uses a “clean-room” implementation of Direct, you can review the code for these software packages to see how they approach implementation of the Guide.

Delivery Notifications in Direct Background & Implementation Guidance Delivery Notifications in Direct Background & Implementation Guidance Presentation Transcript

  • 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
  • • 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
  • • 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
  • • 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.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
  • 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
  • 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 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
  • Questions?