Direct Project (MU3))

Direct Project (MU3))

Status

• Ready for testing

Regulation Text

§ 170.315 (h)(1) Direct Project— Applicability Statement for Secure Health Transport. Able to send and receive health information in accordance with the standard specified in § 170.202(a)(2), including formatted only as a “wrapped” message.

Delivery Notification in Direct. Able to send and receive health information in accordance with the standard specified in § 170.202(e)(1). (Source https://www.healthit.gov/test-method/direct-project)

(h)(1)(i) - Send

Technical outcome – The health IT can electronically transmit (send and receive) health information to a 3rd party which must be formatted only as a “wrapped” message using the Applicability Statement for Secure Health Transport, Version 1.2.

• DNS discovery of address-bound and domain-bound certificates
• LDAP discovery of address-bound and domain-bound certificates
• Registration of Direct email address using the ETT (Edge Testing Tool)
• Send payload to ETT is encrypted using the ETT’s Public Key and signed using OpenEMR’s Private Key.
• verifies the identified health information is successfully transmitted to a third party using Direct, in accordance with the standard specified at § 170.202(a)(2), and using the RFC-5751 “wrapped” message format.
• Must meet 170.202(a)(2) standard which is the applicability statement for secure health transport which can be found here: https://wiki.directproject.org/w/images/e/e6/Applicability_Statement_for_Secure_Health_Transport_v1.2.pdf

(h)(1)(ii) - Receive

Technical outcome – The health IT can electronically transmit (send and receive) health information to a 3rd party using Direct in accordance with the Implementation Guide (IG) for Delivery Notification in Direct, Version 1.0.

Additional Testing Criteria

Required Enhanced Testing

• We have to certify sending and receiving from three unrelated HISPs.
• Requires certification of (b)(1) Transitions of Care

Resources

• Direct - The documentation for the Direct service that was originally built and certified for MU2.
• Contact EMRDirect for up to date certification walkthrough guide that is extremely helpful for passing certification. This document is proprietary and can't be uploaded here to the wiki.

GAP Analysis

• Fix Mime Type Exclusion - Direct Receive requirements fail due to mime type rejection for xml and ccda zip files. Currently if an unknown mime type is sent to OpenEMR via Direct it is rejected if the Mime Type is not found in the File types white list.
  • Need to change the Document parsing to accept a document if it comes from a Direct validated address.
• Embed EMRDirect public certificate into OpenEMR for both testing and production to simplify EMRDirect installation for users.

Terminology

XDM - Standard can be found here: https://profiles.ihe.net/ITI/TF/Volume1/ch-16.html

• XDM description from above link: Cross-Enterprise Document Media Interchange (XDM) provides document interchange using a common file and directory structure over several standard media types.
• XDM is document format agnostic, supporting the same document content as XDS and XDR. Document content is described in Document Content Profiles. Examples are XDS-MS, XPHR, XDS-SD, and XD-LAB.

XDS provides a registry for querying which patient records are in an EHR repository and methods for retrieving the documents.

• https://en.wikipedia.org/wiki/Cross_Enterprise_Document_Sharing
• The XDS system of registry and repository is termed an integration profile and was created by Integrating the Healthcare Enterprise. XDS uses structured EHR standards such as Continuity of Care Record (CCR) and Clinical Data Architecture (CDA) to facilitate data exchange.

Miscellaneous

Testing Notes

Addresses

• For testing Looks like we do have to use two different usernames for testing.

• b(1) testing uses openemr-edge2015@directtest.interopengine.com the where h(1) requires us to use openemr@test.directproject.net sandbox username.

Trust Certificate

Note in the Direct setup with EMR Direct that if you don't put in the intermediary trust certificate you have to use http:// instead of https:// for the Direct connection string.

Custom Email Domain with google

Note that custom domain name emails with google for the report recipient with the Edge Testing Tool (ETT) don't work, but regular gmail email addresses work. ie yourname@mycustomgoogledomain.com won't receive ETT test results whereas yourname@gmail.com will work. EMRDirect has a message about that:

• IMPORTANT: The DCDT sends .crt (X509 certificate) attachments in the results that it emails back to you. Many mail antivirus systems will actively block messages with these attachments, so if you are not receiving the reports, try a different email domain. For example, accounts ending in gmail.com have received these reports reliably in the past for customers whose corporate email servers block these messages. Prior to your certification test, you should confirm that you are receiving the reports from the DCDT at the regular email address you plan to use on your test date.

ollowing testing criteria:

ONC Certification Testing Requirements

- EMR Direct for (h)(1)(i) Receive on the ETT tool for address bound certificate test cases choose H2: Domain-bound certificate search in DNS as the other options are not supported. - You will need to download the EMR Direct Developer X.509 certificate from the EMR Direct page at https://www.emrdirect.com/phimail/accountmanagement.php under Developer Resources #2. - The CCDA_AMB_XDM SLI test case should use the ETT CCDA_AMB.ZIP file which is an XDM file in a zip. The instructions say to choose the C-CDA_Ambulatory_in_XDM but as far as I can tell this is actually the CCDA_AMB.ZIP. - Note that the CCDA Invalid/Expired Certs test cases can be found in the phiMail web interface under the Untrusted section if needed to show them to the test proctor. - Make sure to setup the MT3940 and MT41 EMRDirect test profiles for testing and to use the correct profile for the right test.