§170.315(h)(2) Direct Project, Edge Protocol, and XDR/XDM
| Version # | Description of Change | Version Date |
|---|---|---|
| 1.0 |
Final Test Procedure |
01-29-2016
|
| 1.1 |
(h)(2)(ii) – Receive – XDR: Failure Notification in Test Lab Verification step 6 the test case was updated from 43 to 44. (h)(2)(i)(C) – Send Using Edge Protocol for SMTP – Added TLV step related MU Tracking Step 17. (h)(2)(i)(C) – Receive Using Edge Protocol for SMTP – Updated language and removed email addresses. (h)(2)(ii) – Receive – Removed SMTP/IMAP MT Test 41 (No Dispatched MDN) & SMTP/IMAP MT Test 42. (h)(2)(ii) Send – Removed negative test SMTP/IMAP/POP MT Test 22. |
03-29-2016
|
| 1.2 |
Removed Applicability Statement text from criteria paragraph header language for (h)(2)(ii). |
04-14-2016
|
| 1.3 |
Changed Transport Testing Tool (TTT) references to Edge Testing Tool (ETT) due to the retirement of the TTT tool. The following tests were impacted:
Updated Edge Testing Tool link from ttpedge.sitenv.org to www.healthit.gov/ett. Updated test case numbering for ETT revisions. |
11-07-2016
|
| 1.4 |
Updated the test procedure to use the automated tests in the Edge Testing Tool (ETT):
|
01-17-2017
|
| 1.5 |
Corrected the XDR Test 15 to match the tests in the Edge Testing Tool. The test was broken into two tests; the test procedure now reflects this:
Corrected the tests in paragraph (h)(2)(i)(C) – Send Using Edge Protocol for SMTP:
Corrected tests on pages 3 and 7:
Reformatted the test procedure for readability. The System Under Test aligns closer to the Test Lab section:
|
03-08-2017
|
| 1.6 |
Removed the link to the independent Direct Certificate Discovery Tool (DCDT). Added navigation to the 2015 DCDT within ETT. Changed the sub-titles for paragraph (h)(2)(i)(B) Send/Receive using SOAP+XDR to Send/Receive conversion using XDR to better reflect the action of the translation which occurs through the HISP. Moved the C-CDA Samples to the Documents tab. Addition of alternative SUT Connection – Systems may not be connected using TLS and SASL or a “secure network”. Additional updates were made to indicate which tests were required only for the TLS and SASL alternative throughout the test procedure (see updated test case decoupling below). As part of this update, the ordering of the test steps were altered to make them consistent throughout the test procedure. Updated the test procedure to reflect decoupling of the TLS and SASL from the send/receive test cases corresponding to the changes made in the Edge Testing Tool (ETT). This includes the following changes:
Removed the following test cases to reduce the burden of Edge Testing: IMAP Test 12, POP Test 12, SMTP Test 17, and SMTP test for unique message ID’s. |
05-26-2017
|
| 1.7 |
Removed the use of an explicit cipher suite (TLS_RSA_WITH_RC4_128_MD5, TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA) to account for updates in the Standards which include: RFC 2246, NIST Special Publication 800-52 Rev 1, and RFC 7465. Removed explicit authentication mechanism as this is intrinsic to the test. Removed test (XDR Test 17) to align with the removal of test (SMTP Test 17). |
07-07-2017
|
| 1.8 |
Clarified the behavior of the HISP in the case of an invalid certificate when initiating a TLS Session for paragraph (h)(2)(i)(C) – Send Using Edge Protocol for IHE XDR profile for Limited Metadata Document Sources (step 2). |
08-25-2017
|
| 1.9 |
Removed step requiring the validation of message tracking using processed MDNs in paragraph (h)(2)(i)(C) IHE XDR and SMTP Send as redundant. Corrected typo. |
09-29-2017
|
| 2.0 |
Updated to include Standards Version Advancement Process (SVAP) Approved Standards for 2022. |
01-23-2023
|
§ 170.315 (h)(2) Direct Project, Edge Protocol, and XDR/XDM—
- 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;
- The standard specified in § 170.202(b), including support for both limited and full XDS metadata profiles; and
- Both edge protocol methods specified by the standard in § 170.202(d).
- Delivery Notification in Direct. Able to send and receive health information in accordance with the standard specified in § 170.202(e)(1).
Paragraph (h)(2)(i)(A)
§ 170.202(a)(2) Direct Project: ONC Applicability Statement for Secure Health Transport, Version 1.2, August 2015
Paragraph (h)(2)(i)(B)
§ 170.202(b) ONC XDR and XDM for Direct Messaging Specification
Paragraph (h)(2)(i)(C)
§ 170.202(d) ONC Implementation Guide for Direct Edge Protocols, Version 1.1, June 25, 2014
Paragraph (h)(2)(ii)
§ 170.202(e)(1) Delivery Notification - Implementation Guide for Delivery Notification in Direct v1.0
Standard Version Advancement Process (SVAP) Version(s) Approved
§ 170.202(a)(2) Direct Project: ONC Applicability Statement for Secure Health Transport, Version 1.3, May 2021 (Direct)
For more information, please visit the Standards Version Advancement Process (SVAP) Version(s) page.
- Resource Documents
- Revision History
-
Version # Description of Change Version Date 1.0 Final Test Procedure
01-29-20161.1 (h)(2)(ii) – Receive – XDR: Failure Notification in Test Lab Verification step 6 the test case was updated from 43 to 44.
(h)(2)(i)(C) – Send Using Edge Protocol for SMTP – Added TLV step related MU Tracking Step 17.
(h)(2)(i)(C) – Receive Using Edge Protocol for SMTP – Updated language and removed email addresses.
(h)(2)(ii) – Receive – Removed SMTP/IMAP MT Test 41 (No Dispatched MDN) & SMTP/IMAP MT Test 42.
(h)(2)(ii) Send – Removed negative test SMTP/IMAP/POP MT Test 22.
03-29-20161.2 Removed Applicability Statement text from criteria paragraph header language for (h)(2)(ii).
04-14-20161.3 Changed Transport Testing Tool (TTT) references to Edge Testing Tool (ETT) due to the retirement of the TTT tool. The following tests were impacted:
- (h)(2)(i)(B) - The standard specified in § 170.202(b), including support for both limited and full XDS metadata profiles
- Send using Direct + XDM
- Send using SOAP + XDR
- Receive using Direct + XDM
- Receive using SOAP + XDR
Updated Edge Testing Tool link from ttpedge.sitenv.org to www.healthit.gov/ett.
Updated test case numbering for ETT revisions.
11-07-20161.4 Updated the test procedure to use the automated tests in the Edge Testing Tool (ETT):
- (h)(2)(i)(B) – Send using SOAP + XDR
- Replace manual tests with XDR Tests 10, 11, and 12
- (h)(2)(i)(B) – Receive using SOAP + XDR
- Replace manual tests with XDR Tests 13 and 14
01-17-20171.5 Corrected the XDR Test 15 to match the tests in the Edge Testing Tool. The test was broken into two tests; the test procedure now reflects this:
- (h)(2)(i)(C) Incorrect XDR Message Receive
- XDR Test 15a
- XDR Test 15b
Corrected the tests in paragraph (h)(2)(i)(C) – Send Using Edge Protocol for SMTP:
- SMTP Test 18 was listed in the test procedure by mistake. The test was removed to correct the error.
Corrected tests on pages 3 and 7:
- Removed Invalid Trust Anchor from the list of tests. This is considered a duplicate of Invalid Trust Relationship (Different Trust Anchor).
Reformatted the test procedure for readability. The System Under Test aligns closer to the Test Lab section:
- Several numbering and narrative formatting changes.
03-08-20171.6 Removed the link to the independent Direct Certificate Discovery Tool (DCDT). Added navigation to the 2015 DCDT within ETT.
Changed the sub-titles for paragraph (h)(2)(i)(B) Send/Receive using SOAP+XDR to Send/Receive conversion using XDR to better reflect the action of the translation which occurs through the HISP.
Moved the C-CDA Samples to the Documents tab.
Addition of alternative SUT Connection – Systems may not be connected using TLS and SASL or a “secure network”. Additional updates were made to indicate which tests were required only for the TLS and SASL alternative throughout the test procedure (see updated test case decoupling below). As part of this update, the ordering of the test steps were altered to make them consistent throughout the test procedure.
Updated the test procedure to reflect decoupling of the TLS and SASL from the send/receive test cases corresponding to the changes made in the Edge Testing Tool (ETT). This includes the following changes:
- SMTP Test (1-8, 14) included TLS and SMTP Send. The new test cases are SMTP Test 8 StartTLS, and SMTP Test 14 SMTP Send.
- IMAP Test (4-8, 11, 15) included TLS, SASL, and IMAP Receive. The new test cases are IMAP Test (8, 11, 15). Reorganized the test steps so that the TLS test steps are all under the SUT Connection for SUT using TLS.
- POP Test (3-5, 11, 15) included TLS, SASL, and IMAP Receive. The new test cases are POP 5, 11, 15). Reorganized the test steps so that the TLS test steps are all under the SUT Connection for SUT using TLS.
- SMTP Test (9, 16, 20) included TLS, SASL, and SMTP Receive. The new test cases are SMTP Test 9 StartTLS, SMTP Test 16 SASL and SMTP Test 20 SMTP Receive.
- Re-ordered test steps (IMAP Test 17) and (IMAP Test 32) so negative testing is done last.
- Re-ordered test steps (POP Test 17) and (POP Test 32) so negative testing is done last.
Removed the following test cases to reduce the burden of Edge Testing: IMAP Test 12, POP Test 12, SMTP Test 17, and SMTP test for unique message ID’s.
05-26-20171.7 Removed the use of an explicit cipher suite (TLS_RSA_WITH_RC4_128_MD5, TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA) to account for updates in the Standards which include: RFC 2246, NIST Special Publication 800-52 Rev 1, and RFC 7465.
Removed explicit authentication mechanism as this is intrinsic to the test.
Removed test (XDR Test 17) to align with the removal of test (SMTP Test 17).
07-07-20171.8 Clarified the behavior of the HISP in the case of an invalid certificate when initiating a TLS Session for paragraph (h)(2)(i)(C) – Send Using Edge Protocol for IHE XDR profile for Limited Metadata Document Sources (step 2).
08-25-20171.9 Removed step requiring the validation of message tracking using processed MDNs in paragraph (h)(2)(i)(C) IHE XDR and SMTP Send as redundant.
Corrected typo.
09-29-20172.0 Updated to include Standards Version Advancement Process (SVAP) Approved Standards for 2022.
01-23-2023 - (h)(2)(i)(B) - The standard specified in § 170.202(b), including support for both limited and full XDS metadata profiles
- Regulation Text
-
Regulation Text
§ 170.315 (h)(2) Direct Project, Edge Protocol, and XDR/XDM—
- 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;
- The standard specified in § 170.202(b), including support for both limited and full XDS metadata profiles; and
- Both edge protocol methods specified by the standard in § 170.202(d).
- Delivery Notification in Direct. Able to send and receive health information in accordance with the standard specified in § 170.202(e)(1).
- Able to send and receive health information in accordance with:
- Standard(s) Referenced
-
Paragraph (h)(2)(i)(A)
§ 170.202(a)(2) Direct Project: ONC Applicability Statement for Secure Health Transport, Version 1.2, August 2015
Paragraph (h)(2)(i)(B)
§ 170.202(b) ONC XDR and XDM for Direct Messaging Specification
Paragraph (h)(2)(i)(C)
§ 170.202(d) ONC Implementation Guide for Direct Edge Protocols, Version 1.1, June 25, 2014
Paragraph (h)(2)(ii)
§ 170.202(e)(1) Delivery Notification - Implementation Guide for Delivery Notification in Direct v1.0
Standard Version Advancement Process (SVAP) Version(s) Approved
§ 170.202(a)(2) Direct Project: ONC Applicability Statement for Secure Health Transport, Version 1.3, May 2021 (Direct)
For more information, please visit the Standards Version Advancement Process (SVAP) Version(s) page.
- Testing
-
Testing Tool
Approved SVAP Version(s)
Edge Testing Tool (ETT): Direct Testing
2015 Direct Certificate Discovery Tool (DCDT)
Testing must be conducted for one of the Sending Alternatives outlined on the Test Procedure tab to satisfy the requirements for this criterion.
Testing must also be conducted for one of the alternative connection requirements within each of the Sending Alternatives on the Test Procedure tab.Note: The “Secure Network” alternative only needs to be verified once for the Testing Procedure. (Where applicable the TLS required should be unchecked in the ETT Profile).
Testing must be conducted for one of the Receiving Alternatives outlined on the Test Procedure tab to satisfy the requirements for this criterion: IHE XDR, SMTP, IMAP, or POP3.
Test Tool Documentation
Criterion Subparagraph Test Data (h)(2) Refer to the Edge Testing Tool (ETT)
Please consult the Final Rule entitled: 2015 Edition Health Information Technology (Health IT) Certification Criteria, 2015 Edition Base Electronic Health Record (EHR) Definition, and ONC Health IT Certification Program Modifications for a detailed description of the certification criterion with which these testing steps are associated. We also encourage developers to consult the Certification Companion Guide in tandem with the test procedure as they provide clarifications that may be useful for product development and testing.
Note: The order in which the test steps are listed reflects the sequence of the certification criterion and does not necessarily prescribe the order in which the test should take place.
Testing components
Paragraph (h)(2)(i)(A) – Send
Discover Certificates
- The user performs setup tasks to discover 2015 Direct Certificate Discovery Tool (DCDT) certificates (by downloading the DCDT Trust Anchor from the Edge Testing Tool (ETT): Direct, “Cert Discovery 2015 DCDT,” uploading it into the Health IT Module’s Direct instance, and mapping the Direct address to a non-Direct email address for receiving results) so that the user can discover and use address-bound and domain-bound certificates hosted in both DNS and LDAP in DCDT using identified health IT function(s).
Discover Certificates (Approved SVAP Version)
- Perform this step using DCDT SVAP 2022 and ETT Direct 1.3.
Register Direct Address
- The user selects “Register Direct” within the ETT: Direct Testing and registers a Direct address within the ETT and corresponding Contact Email address for receipt of the ETT validation report.
Send Health Information Using Direct
- The user identifies the payload for sending to the ETT via Direct. ONC-supplied payloads are available for download from the ETT-Documents page.
- The user sends encrypted and signed health information to a third party (ETT) using Direct in accordance with the standard specified at § 170.202(a)(2) Direct Project: ONC Applicability Statement for Secure Health Transport, v1.2 using identified health IT function(s).
- Based upon the types of Direct messages the Health IT Module supports for sending of information (“wrapped” RFC-5751 messages required), the user sends health information to a third party using Direct in accordance with the standard specified at § 170.202(a)(2) Direct Project: ONC Applicability Statement for Secure Health Transport, v1.2.
Register Direct Address and Send Health Information Using Direct (Approved SVAP Version)
- Complete these steps using ETT in accordance with the standards specified in ONC Applicability Statement for Secure Health Transport, v1.3, May, 2022 (Direct.)
Discover Certificates
- The tester verifies the Health IT Module can discover and use address-bound and domain-bound certificates hosted in both DNS and LDAP in order to create and store a listing of Direct recipients using the Direct Certificate Discovery Tool. All certificates listed in both DNS and LDAP must be tested corresponding to the standard specified at § 170.202(a)(2).
Register Direct Address
- The tester verifies the Health IT Module can register a Direct email address using the ETT and has supplied a corresponding Contact Email address for receipt of the ETT validation report.
Send Health Information Using Direct
- Using the ETT validation report, the tester verifies the payload sent to the ETT is encrypted using the ETT’s Public Key and signed using the Health IT Module’s Private Key.
- Using the ETT validation report, the tester 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), using the RFC-5751 “wrapped” message format.
- Using the validation report, the tester verifies the payload was successfully received by the ETT and that the ETT was able to successfully decrypt the message.
All Steps (Approved SVAP Version)
- Complete above verification steps using the Validation Report SVAP 2022 to verify in accordance with the standards specified in ONC Applicability Statement for Secure Health Transport, v1.3, May, 2022 (Direct.)
| System Under Test | Test Lab Verification |
|---|---|
|
Discover Certificates
Discover Certificates (Approved SVAP Version)
Register Direct Address
Send Health Information Using Direct
Register Direct Address and Send Health Information Using Direct (Approved SVAP Version)
|
Discover Certificates
Register Direct Address
Send Health Information Using Direct
All Steps (Approved SVAP Version)
|
Paragraph (h)(2)(i)(A) – Receive
Hosting Certificates
- The user performs setup tasks to test hosting of certificates (by entering the Health IT Module’s Direct address within the Edge Testing Tool: Direct, “Cert Discovery 2015 DCDT”) and executes test cases based upon whether the Health IT Module is able to host either address-bound or domain-bound certificates in either DNS or LDAP servers using the DCDT.
Hosting Certificates (Approved SVAP Versions)
- Use DCDT SVAP 2022 and ETT Direct 1.3 to complete this step.
SUT Connection
- The user selects the “Send Direct Message” within the ETT-Direct Testing and performs setup tasks to enable the receipt of Direct Messages including:
- Completion of the required information, identifying the Direct Address for testing receipt and digital signing of health information in accordance with the standard specified at § 170.202(a)(2) Direct Project: ONC Applicability Statement for Secure Health Transport, v1.2.
- Installation of the ETT’s Valid Trust Anchor within the Health IT Module.
- Identification and upload of the Health IT Module’s Public Key for encryption of messages to be sent by ETT to the Health IT Module.
Receive Direct Message
- The user receives RFC-5751, “wrapped” health information sent from ETT using Direct in accordance with the standard specified at § 170.202(a)(2) Direct Project: ONC Applicability Statement for Secure Health Transport, v1.2 and sends corresponding MDNs.
Reject Receipt of Direct Message (Negative Testing)
- The user rejects health information that is not in accordance with the standard specified at § 170.202(a)(2) Direct Project: ONC Applicability Statement for Secure Health Transport, v1.2 sent from the ETT to the Health IT Module using the following tool option: Invalid Certificate.
- The user rejects health information that is not in accordance with the standard specified at § 170.202(a)(2) Direct Project: ONC Applicability Statement for Secure Health Transport, v1.2 sent from the ETT to the Health IT Module using the following tool option: Expired Certificate.
- The user rejects health information that is not in accordance with the standard specified at § 170.202(a)(2) Direct Project: ONC Applicability Statement for Secure Health Transport, v1.2 sent from the ETT to the Health IT Module using the following tool option: Invalid Trust Relationship (Different Trust Anchor).
- The user rejects health information that is not in accordance with the standard specified at § 170.202(a)(2) Direct Project: ONC Applicability Statement for Secure Health Transport, v1.2 sent from the ETT to the Health IT Module using the following tool option: No Authority Information Access (AIA) Extension.
- The user rejects health information that is not in accordance with the standard specified at § 170.202(a)(2) Direct Project: ONC Applicability Statement for Secure Health Transport, v1.2 sent from the ETT to the Health IT Module using the following tool option: Invalid Message Digest.
SUT Connection, Receive Direct Message and Reject Receipt (Approved SVAP Version)
- Use ETT Direct 1.3 to complete these steps using the standards specified in ONC Applicability Statement for Secure Health Transport, v1.3, May, 2022 (Direct) instead of § 170.202(a)(2).
Hosting Certificates
- The tester verifies the Health IT Module’s hosted certificates are discoverable as displayed on screen for the DCDT test cases executed.
Hosting Certificates (Approved SVAP Version)
- For this step, the tester verifies certificate discovery for the DCDT SVAP 2022 test cases executed.
SUT Connection
- No action required.
Receive Direct Message
- The tester verifies that:
- The health information can be successfully received by the Health IT Module from the ETT in accordance with the standard specified at § 170.202(a)(2) using “wrapped” RFC-575,1 messages.
- An MDN from the Health IT Module was received from the ETT for all messages in Step 3 of the SUT.
Reject Receipt of Direct Message (Negative Testing)
- Invalid Certificate: The tester verifies the Health IT Module rejects Direct messages received with an Invalid Certificate and no corresponding MDN was received by the ETT from the Health IT Module.
- Expired Certificate: The tester verifies the Health IT Module rejects Direct messages received with an Expired Certificate and no corresponding MDN was received by the ETT from the Health IT Module.
- Invalid Trust Relationship (Different Trust Anchor): The tester verifies the Health IT Module rejects Direct messages received with an Invalid Trust Relationship (Different Trust Anchor) and no corresponding MDN was received by the ETT from the Health IT Module.
- No Authority Information Access (AIA) extension: The tester verifies the Health IT Module rejects Direct messages received with an Invalid Certificate and no corresponding MDN was received by the ETT from the Health IT Module.
- Invalid Message Digest: The tester verifies the Health IT Module rejects Direct messages received with an Invalid Message Digest and no corresponding MDN was received by the ETT from the Health IT Module.
SUT Connection, Receive Direct Message and Reject Receipt (Approved SVAP Version)
- Complete all verification steps against the testing outcomes of using ETT Direct 1.3 in accordance with the standards specified in ONC Applicability Statement for Secure Health Transport, v1.3, May, 2022 (Direct).
| System Under Test | Test Lab Verification |
|---|---|
|
Hosting Certificates
Hosting Certificates (Approved SVAP Versions)
SUT Connection
Receive Direct Message
Reject Receipt of Direct Message (Negative Testing)
SUT Connection, Receive Direct Message and Reject Receipt (Approved SVAP Version)
|
Hosting Certificates
Hosting Certificates (Approved SVAP Version)
SUT Connection
Receive Direct Message
Reject Receipt of Direct Message (Negative Testing)
SUT Connection, Receive Direct Message and Reject Receipt (Approved SVAP Version)
|
Paragraph (h)(2)(i)(B) – Send using Direct + XDM
Discover Certificates
- The user performs setup tasks to discover Direct Certificate Discovery Tool (DCDT) certificates (by downloading the DCDT Trust Anchor from the ETT: Direct, “Cert Discovery 2015 DCDT”, uploading it into the Health IT Module’s Direct instance and mapping the Direct address to a non-Direct email address for receiving results) so that the user can discover and use address-bound and domain-bound certificates hosted in both DNS and LDAP in DCDT using developer-identified health IT function(s).
Discover Certificates (Approved SVAP Version)
- Perform this step using DCDT SVAP 2022 and ETT Direct 1.3.
Register Direct Address
- The user selects “Register Direct” within the ETT-Direct Testing and registers a Direct address within the ETT and optionally a corresponding Contact Email address for receipt of the ETT validation report.
Send Health Information Using Direct with XDR/XDM
- The user identifies the payload for sending to the ETT via Direct with XDM Validation. ONC-supplied payloads are available for download from the Edge Testing Tool - Documents Home Page of the ETT, 2015 Certification C-CDA Test Data.
- The user sends encrypted and signed health information to a third party in accordance with the standard specified at § 170.202(b) ONC XDR and XDM for Direct Messaging Specification using limited metadata, using RFC-5751, “wrapped” messages.
- The user sends encrypted and signed health information to a third party, in accordance with the standard specified at § 170.202(b) ONC XDR and XDM for Direct Messaging Specification using full metadata, using RFC-5751, “wrapped” messages.
- The XDM package sent by the Health IT Module is able to be successfully validated using the ETT: Direct “Message Validator.”
Register Direct Address and Send Health Information Using Direct with XDR/XDM (Approved SVAP Version)
- Complete these steps with ETT in accordance with the standards specified in ONC Applicability Statement for Secure Health Transport, v1.3, May, 2022 (Direct) instead of § 170.202(a)(2).
Discover Certificates
- The tester verifies the Health IT Module can discover and use address-bound and domain-bound certificates hosted in both DNS and LDAP in order to create and store a listing of Direct recipients using the Direct Certificate Discovery Tool. All certificates listed in both DNS and LDAP must be tested corresponding to the § 170.202(a)(2) Direct Project: ONC Applicability Statement for Secure Health Transport, v1.2.
Discover Certificates (Approved SVAP Version)
- For this step, all certificates must be tested corresponding to the ONC Applicability Statement for Secure Health Transport v1.3, May, 2022 (Direct).
Register Direct Address
- The tester verifies the Health IT Module can register a Direct email address using the ETT and if supplied a corresponding Contact Email address for receipt of the ETT validation report.
Send Health Information Using Direct with XDR/XDM
- Using the ETT validation report, the tester verifies the payload sent to the ETT is encrypted using the ETT’s Public Key and signed using the Health IT Module’s Private Key.
- Using the ETT validation report, the tester verifies the identified health information is successfully transmitted to a third party using Direct with XDR/XDM, in accordance with the standard specified at § 170.202(b), using RFC-5751, ”wrapped” messages.
- Using the validation report, the tester verifies the payload using limited XDS metadata was successfully received by the ETT and that the ETT was able to successfully decrypt the message.
- Using the XDM payload available for download within the validation report, the tester uploads the XDM payloads (sent using both limited and full metadata) to the ETT’s XDM Message Validator. The tester reviews the ETT validation report to verify the XDM package is valid.
Register Direct Address and Send Health Information Using Direct with XDR/XDM (Approved SVAP Version)
- Use ETT Direct 1.3 Validator to perform these verification steps.
| System Under Test | Test Lab Verification |
|---|---|
|
Discover Certificates
Discover Certificates (Approved SVAP Version)
Register Direct Address
Send Health Information Using Direct with XDR/XDM
Register Direct Address and Send Health Information Using Direct with XDR/XDM (Approved SVAP Version)
|
Discover Certificates
Discover Certificates (Approved SVAP Version)
Register Direct Address
Send Health Information Using Direct with XDR/XDM
Register Direct Address and Send Health Information Using Direct with XDR/XDM (Approved SVAP Version)
|
Paragraph (h)(2)(i)(B) – Send conversion using XDR
- Using the ETT: HISP Testing & Delivery Notification, "XDR Test Cases" with “Your System as: Sender,” the Health IT Module receives a Direct message from the ETT (as Sending HISP), translates it to an XDR message, and sends it to the ETT (as Edge) (XDR Test 10).
- The Health IT Module receives a Direct + XDM message from the ETT (as Sending HISP), translates it to an XDR message with Limited Metadata, and sends it to the ETT (as Edge) (XDR Test 11).
- The Health IT Module receives a Direct + XDM message from the ETT (as Sending HISP), translates it to an XDR message with Full Metadata sent to the ETT (as Edge) (XDR Test 12).
(Approved SVAP Version)
- Use the ETT Direct 1.3 to perform these steps for XRD Test 10, 11, and 12.
- Using the visual inspection, the tester verifies the Direct Message was received, translated, and transmitted as an XDR to the ETT (as Edge) (XDR Test 10).
- Using the visual inspection, the tester verifies the Direct + XDM message was received, translated, and transmitted as an XDR to the ETT (as Edge) using Limited Metadata (XDR Test 11).
- Using the visual inspection, the tester verifies the Direct + XDM message received, translated, and transmitted as an XDR to the ETT (as Edge) using Full Metadata (XDR Test 12).
(Approved SVAP Version)
- Using the visual inspection, the tester verifies the Direct Message was received, translated, and transmitted as an XDR to the ETT Direct 1.3 (as Edge) for XDR Test, 10, 11(using Limited Metadata), and 12 (using Full Metadata.)
| System Under Test | Test Lab Verification |
|---|---|
(Approved SVAP Version)
|
(Approved SVAP Version)
|
Paragraph (h)(2)(i)(B) – Receive using Direct + XDM
Hosting Certificates
- The user performs setup tasks to test hosting of certificates (by entering the Health IT Module’s Direct address within the ETT: Direct, “Cert Discovery 2015 DCDT”) and executes test cases based upon whether the Health IT Module is able to host either address-bound or domain-bound certificates in either DNS or LDAP servers using the DCDT.
Hosting Certificates (Approved SVAP Versions)
- Use DCDT SVAP 2022 and ETT Direct 1.3 to complete certification discovery step(s).
SUT Connection
- The user selects “Send Direct Message” within the ETT: Direct Testing and performs setup tasks to enable the receipt of Direct with XDR/XDM Messages including:
- Completion of the required information, identifying the Direct Address for testing receipt and digital signing of health information in accordance with the standard specified at § 170.202(b) ONC XDR and XDM for Direct Messaging Specification.
- Installation of the ETT’s Valid Trust Anchor within the Health IT Module.
- Identification and upload of the Health IT Module’s Public Key for encryption of messages to be sent by ETT to the Health IT Module.
Receive Direct + XDR/XDM Message
- The user receives health information sent from ETT using Direct in accordance with the standard specified at § 170.202(b) ONC XDR and XDM for Direct Messaging Specification with limited metadata and sends corresponding MDNs, using RFC-5751 “wrapped” messages.
- The user receives health information sent from ETT using Direct in accordance with the standard specified at § 170.202(b) ONC XDR and XDM for Direct Messaging Specification with full metadata and sends corresponding MDNs.
Validate XDM Package
- The user uploads the XDM payload received from the ETT to the ETT: Message Validators “XDM Validator” to perform validation of the XDM package.
Reject Receive of Direct Message (Negative Testing)
- The user rejects health information not in accordance with the standard specified at § 170.202(b) ONC XDR and XDM for Direct Messaging Specification sent from the ETT to the Health IT Module using the following tool option: Invalid Certificate.
- The user rejects health information not in accordance with the standard specified at § 170.202(b) ONC XDR and XDM for Direct Messaging Specification sent from the ETT to the Health IT Module using the following tool option: Expired Certificate.
- The user rejects health information not in accordance with the standard specified at § 170.202(b) ONC XDR and XDM for Direct Messaging Specification sent from the ETT to the Health IT Module using the following tool option: Invalid Trust Relationship (Different Trust Anchor).
- The user rejects health information not in accordance with the standard specified at § 170.202(b) ONC XDR and XDM for Direct Messaging Specification sent from the ETT to the Health IT Module using the following tool option: No Authority Information Access (AIA) Extension.
- The user rejects health information not in accordance with the standard specified at § 170.202(b) ONC XDR and XDM for Direct Messaging Specification sent from the ETT to the Health IT Module using the following tool option: Invalid Message Digest.
SUT Connection, Receive Direct + XDR/XDM Message, Validate XDM Package, Reject Receive of Direct Message (Approved SVAP Version)
- Use Direct 1.3 to complete these steps in accordance with the standards specified in ONC Applicability Statement for Secure Health Transport, v1.3, May, 2022 (Direct).
Hosting Certificates
- The tester verifies the Health IT Module’s hosted certificates are discoverable as displayed on screen for the DCDT test cases executed.
Hosting Certificates (Approved SVAP Version)
- Use DCDT SVAP 2022 to complete this verification step.
SUT Connection
- No Action Required.
Receive Direct + XDR/XDM Message
- The tester verifies health information can be successfully received by the Health IT Module from the ETT in accordance with the standard specified at § 170.202(b) using the limited XDS metadata profile, using RFC-5751, “wrapped” messages and that an MDN from the Health IT Module was received by the ETT for all messages.
- The tester verifies health information can be successfully received by the Health IT Module from the ETT in accordance with the standard specified at § 170.202(b), using the full XDS metadata profile and using RFC-5751, “wrapped” messages and that an MDN from the Health IT Module was received by the ETT for all messages.
Receive Direct + XDR/XDM Message (Approved SVAP Version)
- Health information is in accordance with the standards specified in ONC Applicability Statement for Secure Health Transport, v1.3, May, 2022 (Direct).
Validate XDM Package
- Using the ETT validation report, the tester verifies the XDM payload received by the Health IT Module and uploaded to the ETT Validator successfully passes XDM validation.
Validate XDM Package (Approved SVAP Version)
- Use ETT Direct 1.3 to perform verification/validation.
Reject Receive of Direct Message (Negative Testing)
- Invalid Certificate: The tester verifies the Health IT Module rejects Direct messages received with an Invalid Certificate and that no corresponding MDN was received by the ETT from the Health IT Module.
- Expired Certificate: The tester verifies the Health IT Module rejects Direct messages received with an Expired Certificate and that no corresponding MDN was received by the ETT from the Health IT Module.
- Invalid Trust Relationship (Different Trust Anchor): The tester verifies the Health IT Module rejects Direct messages received with an Invalid Trust Relationship (Different Trust Anchor) and that no corresponding MDN was received by the ETT from the Health IT Module.
- No Authority Information Access (AIA) extension: The tester verifies the Health IT Module rejects Direct messages received with No Authority Information Access (AIA) extension and that no corresponding MDN was received by the ETT from the Health IT Module.
- Invalid Message Digest: The tester verifies the Health IT Module rejects Direct messages received with an Invalid Message Digest and that no corresponding MDN was received by the ETT from the Health IT Module.
Reject Receive of Direct Message (Approved SVAP Version)
- Use ETT Direct 1.3 to receive MDN message for verification.
| System Under Test | Test Lab Verification |
|---|---|
|
Hosting Certificates
Hosting Certificates (Approved SVAP Versions)
SUT Connection
Receive Direct + XDR/XDM Message
Validate XDM Package
Reject Receive of Direct Message (Negative Testing)
SUT Connection, Receive Direct + XDR/XDM Message, Validate XDM Package, Reject Receive of Direct Message (Approved SVAP Version)
|
Hosting Certificates
Hosting Certificates (Approved SVAP Version)
SUT Connection
Receive Direct + XDR/XDM Message
Receive Direct + XDR/XDM Message (Approved SVAP Version)
Validate XDM Package
Validate XDM Package (Approved SVAP Version)
Reject Receive of Direct Message (Negative Testing)
Reject Receive of Direct Message (Approved SVAP Version)
|
Paragraph (h)(2)(i)(B) – Receive conversion using XDR
- Using the ETT: HISP Testing & Delivery Notification "XDR Test Cases", with “Your System as: Receiver” the Health IT Module receives a properly formatted XDR message with limited metadata from the ETT (as Edge), and translates it to a Direct message, and sends it to the ETT (as Destination HISP) (XDR Test 13).
- The Health IT Module receives a properly formatted XDR message with full metadata from the ETT (as Edge), translates it to a Direct message, and sends it to the ETT (as Destination HISP) (XDR Test 14).
(Approved SVAP Version)
- Use the ETT Direct 1.3 to complete above steps.
- The tester verifies the message received by the Health IT Module was converted to a Direct Message, with Limited Metadata, and returned to the ETT, in accordance with the standard § 170.202(b) ONC XDR and XDM for Direct Messaging Specification, using the ETT validation report, sent to the contact’s registered email address, and the ETT logs (XDR Test 13).
- The tester verifies the message received by the Health IT Module was converted to a Direct Message with Full Metadata, and returned to the ETT, in accordance with the standard § 170.202(b), using the ETT validation report, sent to the contact’s registered email address, and the ETT logs (XDR Test 14).
(Approved SVAP Version)
- Use ETT Direct 1.3 to perform above verifications in accordance with ONC Applicability Statement for Secure Health Transport, v1.3, May, 2022 (Direct).
| System Under Test | Test Lab Verification |
|---|---|
(Approved SVAP Version)
|
(Approved SVAP Version)
|
Paragraph (h)(2)(i)(C) – Send Using Edge Protocol for IHE XDR profile for Limited Metadata Document Sources
SUT Connection – Using TLS and SASL
- Using the ETT: HISP & Delivery Notification “XDR Cases” with “System as Sender”, the user establishes a Mutual TLS session for the Health IT Module to authenticate to the ETT (XDR Test 16).
- The Health IT Module provides documentation of the Health IT Module’s ability to reject the connection for a TLS session initiated with an Edge due to an invalid certificate.
SUT Connection – Secure Network If Not Using TLS
- The user demonstrates the ability to provide a secure connection to the SUT by providing evidence and demonstration that the system uses a “secure network” as described at § 170.202(d) ONC Implementation Guide for Direct Edge Protocols, v1.1.
Send Payload
- The user configures the ETT’s endpoints within the Health IT Module and provides the Health IT Module’s Direct “To” address to generate endpoints. Acting as a HISP, the Health IT Module receives and translates a Direct message to an XDR message, and sends the translated message to the ETT (acting as an Edge) for the following types of messages:
- Direct to send to Edge as an XDR message (XDR Test 10);
- Direct + XDM to send to Edge as an XDR message with Limited Metadata (XDR Test 11); and
- Direct + XDM to send to Edge as an XDR message with Full Metadata (XDR Test 12).
Message Tracking Using Processed MDNs (Negative Tests)
- Using the ETT: HISP & Delivery Notification “XDR Cases” with “System as Receiver”, the ETT (as Edge) sends a message to the Health IT Module using a bad address (non-existent), such that the Health IT Module is unable to deliver the message. The Health IT Module delivers a failure message to the ETT (as Edge) using the XDR profile due to a bad address (non-existent) (XDR MT Test 13).
- The ETT (as Edge) sends a message to the Health IT Module using a valid address, but the ETT (as Destination HISP) is not trusted. The Health IT Module delivers a failure message to the ETT (as Edge) using the XDR profile due to an untrusted HISP (ETT as Destination HISP) (XDR MT Test 14).
- The ETT (as Edge) sends a message to the Health IT Module using a valid address, but the ETT’s (as Destination HISP) certificates are not published. The Health IT Module delivers a failure message to the ETT (as Edge) using the XDR profile due to an unpublished HISP certificate (ETT as Destination HISP) (XDR MT Test 15).
- The ETT (as Edge) sends a message to the Health IT Module using a valid address, but the ETT (as Destination HISP) does not respond with a processed MDN. The Health IT Module delivers a failure message to the ETT (as Edge) using the XDR profile, due to exceeded wait period for receiving a processed MDN from the ETT (as Destination HISP) (XDR MT Test 16).
Message Tracking Using Processed MDNs (Negative Tests) (Approved SVAP Version)
- Use the ETT Direct 1.3 to complete above steps.
SUT Connection– Using TLS and SASL
- Using the ETT, the tester verifies the Health IT Module initiates a Mutual TLS session with the ETT (XDR Test 16).
- The tester verifies evidence of the Health IT Module’s capability to initiate a TLS session but reject the connection with an Edge due to an invalid certificate.
SUT Connection– Secure Network If Not Using TLS
- The tester verifies through evidence that the system provides a “secure network” as described at § 170.202(d).
Send Payload
- Using the ETT validation report, the tester verifies the Health IT Module can translate the following using § 170.202(d):
- Direct Message to Health IT Module to XDR message (XDR Test 10);
- Direct + XDM Message to Health IT Module to XDR message with Limited Metadata (XDR Test 11); and
- Direct + XDM Message to Health IT Module to XDR message with Full Metadata (XDR Test 12).
Message Tracking Using Processed MDNs (Negative Tests)
- Using visual inspection of the ETT logs, the tester verifies the Health IT Module has sent failure messages to the ETT (as Edge) using the XDR profile due to bad address (non-existent) (XDR MT Test 13).
- Using visual inspection of the logs, the tester verifies the Health IT Module has sent failure messages to the ETT (as Edge) using the XDR profile due to Untrusted Destination HISP (XDR MT Test 14).
- Using visual inspection of the ETT logs, the tester verifies the Health IT Module has sent failure messages to the ETT (as Edge) using the XDR profile due to Unpublished Certificate for Destination HISP (XDR MT Test 15).
- Using visual inspection of the ETT logs, the tester verifies the Health IT Module has sent failure messages to the ETT (as Edge) using the XDR profile due to Delivery Failure Timeout (XDR MT Test 16).
Message Tracking Using Processed MDNs (Negative Tests) (Approved SVAP Version)
- Use ETT Direct 1.3 to perform above verifications in accordance with ONC Applicability Statement for Secure Health Transport, v1.3, May, 2022 (Direct).
| System Under Test | Test Lab Verification |
|---|---|
|
SUT Connection – Using TLS and SASL
SUT Connection – Secure Network If Not Using TLS
Send Payload
Message Tracking Using Processed MDNs (Negative Tests)
Message Tracking Using Processed MDNs (Negative Tests) (Approved SVAP Version)
|
SUT Connection– Using TLS and SASL
SUT Connection– Secure Network If Not Using TLS
Send Payload
Message Tracking Using Processed MDNs (Negative Tests)
Message Tracking Using Processed MDNs (Negative Tests) (Approved SVAP Version)
|
Paragraph (h)(2)(i)(C) – Send Using Edge Protocol for SMTP
SUT Connection – Using TLS and SASL
- Using the ETT: HISP & Delivery Notification “SMTP Tests” with “System as Sender”, the user initiates a TLS session for the Health IT Module with the ETT (SMTP Test 8).
- The Health IT Module provides documentation of the Heath IT Module’s ability to reject the connection for a TLS session initiated with an Edge due to an invalid certificate.
SUT Connection – Secure Network If Not Using TLS
- The user demonstrates the ability to provide a secure connection to the SUT by providing evidence and demonstration that the system uses a “secure network” as described at § 170.202(d) ONC Implementation Guide for Direct Edge Protocols, v1.1.
Send Payload
- The user sends a document to the ETT (SMTP Test 14).
Message Tracking Using Processed MDNs (Negative Tests)
- Using the ETT: HISP & Delivery Notification “Message Tracking” with “System as Sender”, the ETT (as Edge) sends a message to the Health IT Module using a bad address (non-existent), such that the Health IT Module is unable to deliver the message. The Health IT Module delivers a failure message to the ETT (as Edge) using the following edge protocol due to a bad address (non-existent):
- SMTP MT Test 1 or alternatively;
- SMTP/IMAP MT Test 5 (Alternative);
- SMTP/POP MT Test 9 (Alternative).
- The ETT (as Edge) sends a message to the Health IT Module using a valid address, but the ETT (as Destination HISP) is not trusted. The Health IT Module delivers a failure message to the ETT (as Edge) using the following edge protocol due to an untrusted HISP (ETT as Destination HISP):
- SMTP MT Test 2 or alternatively;
- SMTP/IMAP MT Test 6 (Alternative);
- SMTP/POP MT Test 10 (Alternative).
- The ETT (as Edge) sends a message to the Health IT Module using a valid address, but the ETT’s (as Destination HISP) certificates are not published. The Health IT Module delivers a failure message to the ETT (as Edge) using the following edge protocol due to an unpublished HISP certificate (ETT as Destination HISP):
- SMTP MT Test 3 or alternatively;
- SMTP/IMAP MT Test 7 (Alternative);
- SMTP/POP MT Test 11 (Alternative).
- The ETT (as Edge) sends a message to the Health IT Module using a valid address, but the ETT (as Destination HISP) does not respond with a processed MDN. The Health IT Module delivers a failure message to the ETT (as Edge) using the following edge protocol due to exceeded wait period for receiving a processed MDN from the ETT (as Destination HISP), delivery time-out:
- SMTP MT Test 4 or alternatively;
- SMTP/IMAP MT Test 8 (Alternative);
- SMTP/POP MT Test 12 (Alternative).
All Steps (Approved SVAP Version)
- Use the ETT Direct 1.3 to complete above steps.
SUT Connection – Using TLS and SASL
- Using the ETT, the tester verifies the Health IT Module initiates a TLS session (SMTP Test 8).
- The tester verifies evidence of the Health IT Module’s capability to initiate a TLS session, but reject the connection with an Edge due to an invalid certificate.
SUT Connection – Secure Network If Not Using TLS
- The tester verifies through evidence that the system provides a “secure network” as described at § 170.202(d).
Send Payload
- The tester verifies the Health IT Module can send an SMTP Message using the SMTP Edge Protocol (SMTP Test 14).
Message Tracking Using Processed MDNs (Negative Tests)
- Using visual inspection of the ETT logs to confirm the receipt of the negative delivery status notification message, the tester verifies the Health IT Module has sent a delivery failure message due to a bad address (non-existent) to the ETT (as Edge) for the following tests:
- SMTP MT Test 1 or alternatively;
- SMTP/IMAP MT Test 5 (Alternative);
- SMTP/POP MT Test 9 (Alternative).
- Using the ETT, the tester verifies the Health IT Module successfully performs message tracking using processed MDNs. Using visual inspection of the ETT logs to confirm the receipt of the negative delivery status notification message, the tester verifies the Health IT Module has sent a delivery failure messages due to an untrusted HISP to the ETT (as Edge) for the following tests:
- SMTP MT Test 2 or alternatively;
- SMTP/IMAP MT Test 6 (Alternative);
- SMTP/POP MT Test 10 (Alternative).
- Using visual inspection of the ETT logs to confirm the receipt of the negative delivery status notification message, the tester verifies the Health IT Module has sent a delivery failure messages due to an unpublished HISP certificate to the ETT (as Edge) for the following tests:
- SMTP MT Test 3 or alternatively;
- SMTP/IMAP MT Test 7 (Alternative);
- SMTP/POP MT Test 11 (Alternative).
- Using visual inspection of the ETT logs to confirm the receipt of the negative delivery status notification message, the tester verifies the Health IT Module has sent a delivery failure messages due to exceeded wait period for receiving a processed MDN to the ETT (as Edge) for the following tests:
- SMTP MT Test 4 or alternatively;
- SMTP/IMAP MT Test 8 (Alternative);
- SMTP/POP MT Test 12 (Alternative).
All Steps (Approved SVAP Version)
- Use ETT Direct 1.3 to perform above verifications.
| System Under Test | Test Lab Verification |
|---|---|
|
SUT Connection – Using TLS and SASL
SUT Connection – Secure Network If Not Using TLS
Send Payload
Message Tracking Using Processed MDNs (Negative Tests)
All Steps (Approved SVAP Version)
|
SUT Connection – Using TLS and SASL
SUT Connection – Secure Network If Not Using TLS
Send Payload
Message Tracking Using Processed MDNs (Negative Tests)
All Steps (Approved SVAP Version)
|
Paragraph (h)(2)(i)(C) – Send Using Edge Protocol for IMAP (SMTP Alternative)
SUT Connection – Using TLS and SASL
- Using the ETT: HISP & Delivery Notification “IMAP Tests” with the ETT for “System as Sender”, the user initiates an IMAP session to the Health IT Module with STARTTLS (STARTTLS command) and PLAIN SSL authentication (AUTHENTICATE command) (IMAP Test 8, 11, 15).
- The Health IT Module provides documentation of the Heath IT Module’s ability to processes connection requests initiated using STARTTLS with valid cipher suite(s) in accordance with RFC 3501 and the subsequently updated standards: RFC 2246, NIST Special Publication 800-52 Revision 1, RFC 7465, and is in accordance with the security standards specified in the § 170.202(a)(2) Direct Project: ONC Applicability Statement for Secure Health Transport, v1.2 (IMAP Test 8, 11, 15).
- The Health IT Module provides documentation of the ability to accept a valid authentication mechanism and authenticates the Edge.
- Negative Test: The Health IT Module provides documentation of the ability to reject an authentication request from an Edge.
SUT Connection – Secure Network If Not Using TLS
- The user demonstrates the ability to provide a secure connection to the SUT by providing evidence and demonstration that the system uses a “secure network” as described at § 170.202(d) ONC Implementation Guide for Direct Edge Protocols, v1.1.
Execute IMAP4 Commands
- Using the ETT: HISP & Delivery Notification “IMAP Tests” with the ETT for “System as Sender”, the user initiates an IMAP session to the Health IT Module using the IMAP4 CAPABILITIES command, NOOP command, and LOGOUT command (or equivalent for a secure network) (IMAP Tests 1, 2, 3).
- Using the ETT, the user initiates an IMAP session to the Health IT Module using the STARTTLS and AUTHENTICATE commands (or equivalent for a secure network), LOGIN command, SELECT command, and FETCH command (IMAP Tests 8, 11, 15).
Reject IMAP4 Connection (Negative Tests)
- Negative Test: The user demonstrates the Health IT Module rejects an IMAP4 connection with a bad command syntax by terminating the connection from the ETT (IMAP Test 9).
- Negative Test: The user demonstrates the Health IT Module rejects an IMAP4 connections with bad commands using the right syntax based upon the specific state of the connection by terminating the connection from the ETT (IMAP Test 10).
Message Processing
- The ETT (as Edge) is able to fetch attachments from the Health IT Module using an IMAP4 connection (IMAP Test 32).
- Negative Test: The Health IT Module rejects authentication requests from the ETT due to an invalid username/password (IMAP Test 17).
All Steps (Approved SVAP Version)
- Use the ETT Direct 1.3 to complete above steps.
SUT Connection – Using TLS and SASL
- Using the ETT, the tester verifies the Health IT Module is able to successfully initiate an IMAP4 session with the Health IT Module (IMAP Test 8, 11, 15).
- The tester verifies evidence of the Health IT Module’s capability to process connection requests initiated using STARTTLS with one or more valid cipher suite (IMAP Test 8, 11, 15).
- The tester verifies evidence of the Health IT Module’s capability to accept authentication requests.
- Negative Test: The tester verifies evidence of the Health IT Module’s capability to reject authentication requests.
SUT Connection – Secure Network If Not Using TLS
- The user demonstrates the ability to provide a secure connection to the SUT by providing evidence and demonstration that the system uses a “secure network” as described at § 170.202(d).
Execute IMAP4 Commands
- Using the ETT logs, the tester verifies the Health IT Module is has successfully implemented the following commands IMAP4 CAPABILITY, NOOP, and LOGOUT (or equivalent for a secure network) (IMAP Test 1, 2, 3).
- Using the ETT logs, the tester verifies the Health IT Module is has successfully implemented the following commands IMAP4 STARTTLS and AUTHENTICATE (or equivalent for a secure network), LOGIN, SELECT, and FETCH (IMAP Test 8, 11, 15).
Reject IMAP4 Connection (Negative Tests)
- Negative Tests: Using the ETT logs, the tester verifies the Health IT Module rejects a bad command syntax with the appropriate response and terminates connection with the ETT (IMAP Tests 9).
- Negative Tests: Using the ETT logs, the tester verifies the Health IT Module rejects a bad command with correct syntax with the appropriate response and terminates connection with the ETT (IMAP Tests 10).
Message Processing
- Using the ETT logs, the tester verifies the Health IT Module is able to host attachments and make them available for fetching using IMAP (IMAP Test 32).
- Negative Test: Using the ETT logs, the tester verifies the Health IT Module rejects authentication requests due to invalid username/password (IMAP Test 17).
All Steps (Approved SVAP Version)
- Use the ETT Direct 1.3 to perform above verifications.
| System Under Test | Test Lab Verification |
|---|---|
|
SUT Connection – Using TLS and SASL
SUT Connection – Secure Network If Not Using TLS
Execute IMAP4 Commands
Reject IMAP4 Connection (Negative Tests)
Message Processing
All Steps (Approved SVAP Version)
|
SUT Connection – Using TLS and SASL
SUT Connection – Secure Network If Not Using TLS
Execute IMAP4 Commands
Reject IMAP4 Connection (Negative Tests)
Message Processing
All Steps (Approved SVAP Version)
|
Paragraph (h)(2)(i)(C) – Send Using Edge Protocol for POP3 (SMTP Alternative)
SUT Connection – Using TLS and SASL
- Using the ETT: HISP & Delivery Notification “POP Tests” with the ETT for “System as Sender”, the user initiates a POP session to the Health IT Module with STARTTLS (STARTTLS command) (POP Test 5, 11, 15).
- The Health IT Module provides documentation of the Heath IT Module’s ability to processes connection requests initiated using STARTTLS with a valid cipher suite(s) in accordance with RFC 3501, and the subsequently updated standards: RFC 2246, NIST Special Publication 800-52, Revision 1, RFC 7465, and is in accordance with the security standards specified in the § 170.202(a)(2) Direct Project: ONC Applicability Statement for Secure Health Transport, v1.2 (POP Test 5, 11, 15).
SUT Connection – Secure Network If Not Using TLS
- The user demonstrates the ability to provide a secure connection to the SUT by providing evidence and demonstration that the system uses a “secure network” as described at § 170.202(d) ONC Implementation Guide for Direct Edge Protocols, v1.1.
Execute POP3 Commands
- Using the ETT: HISP & Delivery Notification “POP Tests” with the ETT for “System as Sender”, the user initiates a POP session to the Health IT Module using the POP3 CAPA command, NOOP command, and QUIT command (or equivalent for a secure network) (POP Test 1, 2).
- Using the ETT, the user initiates a POP session to the Health IT Module using the POP3 STAT command, STARTTLS command (or equivalent for a secure network), RETR command, LIST command, and RSET command (POP Test 5, 11, 15).
Reject POP3 Connection (Negative Tests)
- Negative Test: The user demonstrates the Health IT Module rejects a POP3 connection with a bad command syntax by terminating the connection from the ETT (POP Test 9).
- Negative Test: The user demonstrates the Health IT Module rejects a POP3 connection with bad commands using the right syntax based upon the specific state of the connection by terminating the connection from the ETT (POP Test 10).
Message Processing
- The ETT (as Edge) is able to fetch attachments from the Health IT Module using an IMAP4 connection (POP Test 32).
- Negative Test: The Health IT Module rejects authentication requests from the ETT due to an invalid username/password (POP Test 17).
All Steps (Approved SVAP Version)
- Use the ETT Direct 1.3 to complete above steps.
SUT Connection – Using TLS and SASL
- Using the ETT, the tester verifies the Health IT Module is able to successfully initiate a POP session with the Health IT Module (POP Test 5, 11, 15).
- The tester verifies evidence of the Health IT Module’s capability to process connection requests initiated using STARTTLS with one or more valid cipher suite (POP Test 3-5, 11, 15).
SUT Connection – Secure Network If Not Using TLS
- The user demonstrates the ability to provide a secure connection to the SUT by providing evidence and demonstration that the system uses a “secure network” as described at § 170.202(d).
Execute POP3 Commands
- Using the ETT logs, the tester verifies the Health IT Module has successfully implemented the following commands: POP3 CAPA, NOOP, and QUIT (or equivalent for a secure network) (POP Test 1, 2).
- Using the ETT logs, the tester verifies the Health IT Module has successfully implemented the following commands POP3 STAT, STARTTLS (or equivalent for a secure network), RETR, LIST, and RSET (POP Test 5, 11, 15).
Reject POP3 Connection (Negative Tests)
- Negative Tests: Using the ETT logs, the tester verifies the Health IT Module rejects bad command syntax commands with the appropriate response and terminates connection with the ETT (POP Test 9).
- Negative Tests: Using the ETT logs, the tester verifies the Health IT Module rejects bad commands using the right syntax commands with the appropriate response and terminates connection with the ETT (POP Test 10).
Message Processing
- Using the ETT logs, the tester verifies the Health IT Module is able to host attachments and make them available for fetching using POP (POP Test 32).
- Negative Test: Using the ETT logs, the tester verifies the Health IT Module rejects authentication requests due to invalid username/password (POP Test 17).
All Steps (SMTP Alternative) (Approved SVAP Version)
- Use the ETT Direct 1.3 to perform above verifications.
| System Under Test | Test Lab Verification |
|---|---|
|
SUT Connection – Using TLS and SASL
SUT Connection – Secure Network If Not Using TLS
Execute POP3 Commands
Reject POP3 Connection (Negative Tests)
Message Processing
All Steps (Approved SVAP Version)
|
SUT Connection – Using TLS and SASL
SUT Connection – Secure Network If Not Using TLS
Execute POP3 Commands
Reject POP3 Connection (Negative Tests)
Message Processing
All Steps (SMTP Alternative) (Approved SVAP Version)
|
Paragraph (h)(2)(i)(C) – Receive Using Edge Protocol for IHE XDR profile for Limited Metadata Document Sources
SUT Connection– Using TLS and SASL
- Using the ETT: HISP & Delivery Notification “XDR Tests” with the ETT for “System as Receiver”, the user establishes authentication from the ETT to the Health IT Module using Mutual TLS correctly (XDR Test 18).
- Using the ETT, the user establishes authentication from the ETT to the Health IT Module using bad certificates (incorrect Mutual TLS configuration) (XDR Test 19).
SUT Connection – Secure Network If Not Using TLS
- The user demonstrates the ability to provide a secure connection to the SUT by providing evidence and demonstration that the system uses a “secure network” as described at § 170.202(d) ONC Implementation Guide for Direct Edge Protocols, v1.1.
Receive Payload
- The user enters the Health IT Module’s endpoints for receiving an XDR message from the ETT (as Edge) for Limited Metadata (XDR Test 13) and the Health IT Module receives a properly formatted XDR message with limited metadata from the ETT (as Edge) and translates it to a Direct message sent to the ETT (as Destination HISP) (XDR Test 13).
- The user enters the Health IT Module’s endpoints for receiving an XDR message from the ETT (as Edge) for Full Metadata (XDR Test 14) and the Health IT Module receives a properly formatted XDR message with full metadata from the ETT (as Edge) and translates it to a Direct message sent to the ETT (as Destination HISP) (XDR Test 14).
Incorrect XDR Message Receive
- The Health IT Module returns errors when the following incorrect messages are received from the ETT with Invalid SOAP envelope details (XDR Test 15a).
- The Health IT Module returns errors when the following incorrect messages are received from the ETT with Invalid SOAP body details (XDR Test 15b), including:
- Missing metadata elements;
- Missing associations between ebRIM constructs;
- Missing Direct Address block.
All Steps (Approved SVAP Version)
- Use the ETT Direct 1.3 to complete above steps.
SUT Connection– Using TLS and SASL
- Using the ETT, the tester verifies the Health IT Module is capable of accepting and validating a Mutual TLS session when authenticating to the ETT. Using visual inspection of the logs, the tester verifies the Health IT Module does not accept connections due to incorrect Mutual TLS configuration (XDR Test 18).
- Using visual inspection of the logs, the tester verifies the Health IT Module does not accept connections due to an invalid certificate published by the ETT (XDR Test 19).
SUT Connection – Secure Network If Not Using TLS
- The tester verifies through evidence that the system provides a “secure network” as described at § 170.202(d).
Receive Payload
- Using visual inspection of the logs, the tester verifies the Health IT Module is capable of receiving and processing a valid XDR message with limited metadata and the Health IT Module does not accept invalid messages sent from the ETT (XDR Test 13).
- Using visual inspection of the logs, the tester verifies the Health IT Module is capable of receiving and processing a valid XDR message with full metadata and the Health IT Module does not accept invalid messages sent from the ETT (XDR Test 14).
Incorrect XDR Message Receive
- Using logs, the tester verifies the Health IT Module recognizes that the messages sent from the ETT are Invalid messages (XDR Test 15a).
- Using logs, the tester verifies the Health IT Module rejects the bad messages (XDR Test 15b).
All Steps (Approved SVAP Version)
- Use ETT Direct 1.3 to perform above verifications.
| System Under Test | Test Lab Verification |
|---|---|
|
SUT Connection– Using TLS and SASL
SUT Connection – Secure Network If Not Using TLS
Receive Payload
Incorrect XDR Message Receive
All Steps (Approved SVAP Version)
|
SUT Connection– Using TLS and SASL
SUT Connection – Secure Network If Not Using TLS
Receive Payload
Incorrect XDR Message Receive
All Steps (Approved SVAP Version)
|
Paragraph (h)(2)(i)(C) – Receive Using Edge Protocol for SMTP
SUT Connection – Using TLS and SASL
- Using the ETT: HISP & Delivery Notification “SMTP Tests” using the ETT for “System as Receiver”, the user initiates a valid TLS session for the Health IT Module with the ETT sent from the username supplied by the Health IT Module email account being authenticated to the Health IT Module SMTP email address (SMTP Test 9).
- The user authenticates the ETT with the Health IT Module using PLAIN SASL as an SMTP server from the username supplied by the Health IT Module email account being authenticated to the Health IT Module SMTP email address (SMTP Test 16).
- The Health IT Module provides documentation of the ability to authenticate to an Edge using SASL as an SMTP server.
- The Health IT Module receives an authentication from the ETT using an Invalid SASL username/password as an SMTP server from the username supplied by the Health IT Module email account being authenticated (SMTP Test 22).
SUT Connection – Secure Network If Not Using TLS
- The user demonstrates the ability to provide a secure connection to the SUT by providing evidence and demonstration that the system uses a "secure network" as described at § 170.202(d) ONC Implementation Guide for Direct Edge Protocols, v1.1.
Receive Payload
- The user receives a document from the ETT using valid SMTP commands from the username supplied by the Health IT Module email account being authenticated and establishes a connection with the ETT (SMTP Test 20).
- The user receives a document from the ETT using invalid data as part of the DATA command from the username supplied by the Health IT Module email account being authenticated to the Health IT Module SMTP email address (SMTP Test 10).
- The user receives a document from the ETT using invalid SMTP commands as part of the DATA command from the username supplied by the Health IT Module email account being authenticated to the Health IT Module SMTP email address (SMTP Test 11).
- The user receives a document from the ETT from the username supplied by the Health IT Module email account being authenticated to the Health IT Module SMTP email address beyond the allowable time period (SMTP Test 13).
All Steps (Approved SVAP Version)
- Use the ETT Direct 1.3 to complete above steps.
SUT Connection – Using TLS and SASL
- Using the ETT, the tester verifies a secure session was established with the Health IT Module based upon TLS initiation using correct syntax (SMTP Test 9).
- Using the ETT with a predetermined username and password, the tester verifies a secure session was established with the Health IT Module with PLAIN SASL authentication (SMTP Test 16).
- The tester verifies evidence of the capability to establish a secure session with the Health IT Module based upon successful authentication (SMTP Test 16).
- The tester verifies evidence of the capability to reject an authentication (SMTP Test 22).
SUT Connection – Secure Network If Not Using TLS
- The tester verifies through evidence that the system provides a “secure network” as described at § 170.202(d).
Receive Payload
- Using the ETT, the tester verifies the Health IT Module can receive an SMTP Message using § 170.202(d) and the Validation Report indicates the successful sequence of commands for SMTP protocols (SMTP Test 20).
- Using the ETT Logs, the tester verifies a secure connection cannot be established based upon invalid data provided and does not accept the data by using appropriate responses to an invalid DATA command (SMTP Test 10).
- Using the ETT Logs, the tester verifies a secure connection cannot be established based upon invalid data provided and does not accept the data by using appropriate responses to invalid SMTP commands or invalid size limits of SMTP commands (SMTP Test 11).
- Using the ETT, the tester verifies the Health IT Module has kept the transaction open for beyond the specified time constraints found with RFC 2821, Section 4.5.3.2, and therefore cannot accept the incoming message (SMTP Test 13).
All Steps (Approved SVAP Version)
- Use ETT Direct 1.3 to perform above verifications.
| System Under Test | Test Lab Verification |
|---|---|
|
SUT Connection – Using TLS and SASL
SUT Connection – Secure Network If Not Using TLS
Receive Payload
All Steps (Approved SVAP Version)
|
SUT Connection – Using TLS and SASL
SUT Connection – Secure Network If Not Using TLS
Receive Payload
All Steps (Approved SVAP Version)
|
Paragraph (h)(2)(ii) – Send
Disposition-Notification-Options Header
- Using the ETT: HISP & Delivery Notification “Message Tracking” using “Your System as Sender”, the Health IT Module is able to successfully process the Disposition-Notifications-Options-Header received from the ETT (as Sending Edge) and include it in the message to the destination (ETT as Destination HISP):
- SMTP MT Test 21(a) or alternatively;
- IMAP: SMTP/IMAP MT Test 21(b) (Alternative);
- POP3: SMTP/POP MT Test 21(c) (Alternative).
Delivery Failure Due to Bad Destination Address
- The Health IT Module is able to successfully process a message from the ETT (as Sending Edge) with a bad address (non-existent) for the destination, send the message to the ETT (as Destination HISP), which will return an error as it will be unable to deliver the message to the address. The Health IT Module sends the ETT (as Sending Edge) a negative delivery status notification message via:
- SMTP MT Test 23(a) or alternatively;
- SMTP/IMAP MT Test 23(b) (Alternative);
- SMTP/POP MT Test 23(c) (Alternative).
Delivery Failure Due to Untrusted Destination HISP
- The Health IT Module is able to successfully process a message from the ETT (as Sending Edge) with a valid address for the destination, send the message to the ETT (as an untrusted Destination HISP). The Health IT Module sends the ETT (as Sending Edge) a negative delivery status notification message via:
- SMTP MT Test 24(a) or alternatively;
- SMTP/IMAP MT Test 24(b) (Alternative);
- SMTP/POP MT Test 24(c) (Alternative).
Delivery Failure Due to Unpublished Certificate for Destination HISP
- The Health IT Module is able to successfully process a message from the ETT (as Sending Edge) with a valid address for the destination, send the message to the ETT (as Destination HISP). Due to the unpublished certificate, security and trust processing fails. The Health IT Module sends the ETT (as Sending Edge) a negative delivery status notification message via:
- SMTP MT Test 25(a) or alternatively;
- SMTP/IMAP MT Test 25(b) (Alternative);
- SMTP/POP MT Test 25(c) (Alternative).
Delivery Failure Timeout for Processed MDN
- The Health IT Module is able to successfully process a message from the ETT (as Sending Edge) with a valid address for the destination, send the message to the ETT (as Destination HISP). The wait time for the Health IT Module to receive a Processed MDN from the Destination HISP is exceeded. The Health IT Module sends the ETT (as Sending Edge) a negative delivery status notification message via:
- SMTP MT Test 26(a) or alternatively;
- SMTP/IMAP MT Test 26(b) (Alternative);
- SMTP/POP MT Test 26(c) (Alternative).
Delivery Failure for Dispatched MDN
- The Health IT Module is able to successfully process a message from the ETT (as Sending Edge) with a valid address for the destination, send the message to the ETT (as Destination HISP) which provides a Processed MDN but does not provide a Dispatched MDN to the Health IT Module. The Health IT Module sends the ETT (as Sending Edge) a negative delivery status notification message via:
- SMTP MT Test 27(a) or alternatively;
- SMTP/IMAP MT Test 27(b) (Alternative);
- SMTP/POP MT Test 27(c) (Alternative).
Delivery Failure Timeout for Dispatched MDN
- The Health IT Module is able to successfully process a message from the ETT (as Sending Edge) with a valid address for the destination, send the message to the ETT (as Destination HISP) which provides a Processed MDN to the Health IT Module. The Health IT Module receives a Dispatched MDN after the expected wait time is exceeded. The Health IT Module sends the ETT (as Sending Edge) a negative delivery status notification and does not forward the dispatched MDN to the ETT (as Sending Edge) message via:
- SMTP MT Test 28(a) or alternatively;
- SMTP/IMAP MT Test 28(b) (Alternative);
- SMTP/POP MT Test 28(c) (Alternative).
Positive Delivery Notification
- The Health IT Module is able to successfully process a message from the ETT (as Sending Edge) with a valid address for the destination, send the message to the ETT (as Destination HISP) which provides a Processed MDN and Dispatched MDN to the Health IT Module. The Health IT Module only sends the ETT (as Sending Edge) a positive delivery status notification (dispatched MDN) message via:
- SMTP MT Test 29(a) or alternatively;
- SMTP/IMAP MT Test 29(b) (Alternative),
- SMTP/POP MT Test 29(c) (Alternative).
Requesting Delivery Notification for XDR Edge HISP
- The Health IT Module is able to successfully process a message from the ETT (as Sending Edge), using the ETT: HISP & Delivery Notification “XDR Cases” with “System as Receiver”, that includes a valid Direct address block header and valid destination. The Health IT Module includes the header in the message to the ETT (as Destination HISP) within SMTP headers (XDR MT Test 30).
- The Health IT Module is able to successfully process a message from the ETT (as Sending Edge) that includes a valid Direct address block, header, and invalid destination. The Health IT Module is able to process the header handle an invalid delivery notification request (XDR MT Test 31).
XDR Delivery Failure: Bad Address
- The Health IT Module is able to successfully process a message from the ETT (as Sending Edge) that includes an invalid (non-existent) address. The Health IT Module sends a negative delivery status notification message to the ETT (as Sending Edge) using XDR profile (XDR MT Test 32).
XDR Delivery Failure: Untrusted Destination HISP
- The Health IT Module is able to successfully process a message from the ETT (as Sending Edge) to a valid address. The ETT (as Destination HISP) is not trusted and the Health IT Module sends a negative delivery status notification message to the ETT (as Sending Edge) using XDR profile (XDR MT Test 33).
XDR Delivery Failure: Unpublished Destination HISP Certificate
- The Health IT Module is able to successfully process a message from the ETT (as Sending Edge) to a valid address. The ETT (as Destination HISP) does not have published certificates, and security and trust processing fails. The Health IT Module sends a negative delivery status notification message to the ETT (as Sending Edge) using XDR profile (XDR MT Test 34).
XDR Delivery Failure: No Processed MDN
- The Health IT Module is able to successfully process a message from the ETT (as Sending Edge) to a valid address. The ETT (as Destination HISP) does not respond with a Processed MDN. The Health IT Module sends a negative delivery status notification message to the ETT (as Sending Edge) using XDR profile (XDR MT Test 35).
XDR Delivery Failure: No Dispatched MDN
- The Health IT Module is able to successfully process a message from the ETT (as Sending Edge) to a valid address. The ETT (as Destination HISP) responds with a Processed MDN, but no Dispatched MDN. The Health IT Module sends a negative delivery status notification message to the ETT (as Sending Edge) using XDR profile (XDR MT Test 36).
XDR Delivery Failure: Timeout for Dispatched MDN
- The Health IT Module is able to successfully process a message from the ETT (as Sending Edge) to a valid address. The ETT (as Destination HISP) responds with a Processed MDN, but the Dispatched MDN is received after the expected wait time has exceeded. The Health IT Module sends a negative delivery status notification message to the ETT (as Sending Edge) using XDR profile (XDR MT Test 37).
XDR Positive Delivery Notification
- The Health IT Module is able to successfully process a message from the ETT (as Sending Edge) to a valid address. The ETT (as Destination HISP) responds with a Processed MDN and Dispatched MDN within the expected time period. The Health IT Module sends only one positive delivery status notification message to the ETT (as Sending Edge) using XDR profile (XDR MT Test 38).
All Steps (Approved SVAP Version)
- Use the ETT Direct 1.3 to complete above steps.
Disposition-Notification-Options Header
- The ETT test results for the following tests are successful:
- SMTP MT Test 21(a) or alternatively;
- SMTP/IMAP MT Test 21(b) (Alternative);
- SMTP/POP MT Test 21(c) (Alternative).
Delivery Failure Due to Bad Destination Address
- The ETT test results for the following tests are successful:
- SMTP MT Test 23(a) or alternatively;
- SMTP/IMAP MT Test 23(b) (Alternative);
- SMTP/POP MT Test 23(c) (Alternative).
Delivery Failure Due to Untrusted Destination HISP
- The ETT test results for the following tests are successful:
- SMTP MT Test 24(a) or alternatively;
- SMTP/IMAP MT Test 24(b) (Alternative);
- SMTP/POP MT Test 24(c) (Alternative).
Delivery Failure Due to Unpublished Certificate for Destination HISP
- The ETT test results for the following tests are successful:
- SMTP MT Test 25(a) or alternatively;
- SMTP/IMAP MT Test 25(b) (Alternative);
- SMTP/POP MT Test 25(c) (Alternative).
Delivery Failure Timeout for Processed MDN
- The ETT test results for the following tests are successful:
- SMTP MT Test 26(a) or alternatively;
- SMTP/IMAP MT Test 26(b) (Alternative);
- SMTP/POP MT Test 26(c) (Alternative).
Delivery Failure for Dispatched MDN
- The ETT test results for the following tests are successful:
- SMTP MT Test 27(a) or alternatively;
- SMTP/IMAP MT Test 27(b) (Alternative);
- SMTP/POP MT Test 27(c) (Alternative).
Delivery Failure Timeout for Dispatched MDN
- The ETT test results for the following tests are successful:
- SMTP MT Test 28(a) or alternatively;
- SMTP/IMAP MT Test 28(b) (Alternative);
- SMTP/POP MT Test 28(c) (Alternative).
Positive Delivery Notification
- The ETT test results for the following tests are successful:
- SMTP MT Test 29(a) or alternatively;
- SMTP/IMAP MT Test 29(b) (Alternative);
- SMTP/POP MT Test 29(c) (Alternative).
Requesting Delivery Notification for XDR Edge HISP
- The ETT test results for XDR MT Test 30 are successful.
- The ETT test results for XDR MT Test 31 are successful.
XDR Delivery Failure: Bad Address
- The ETT test results for XDR MT Test 32 are successful.
XDR Delivery Failure: Untrusted Destination HISP
- The ETT test results for XDR MT Test 33 are successful.
XDR Delivery Failure: Unpublished Destination HISP Certificate
- The ETT test results for XDR MT Test 34 are successful.
XDR Delivery Failure: No Processed MDN
- The ETT test results for XDR MT Test 35 are successful.
XDR Delivery Failure: No Dispatched MDN
- The ETT test results for XDR MT Test 36 are successful.
XDR Delivery Failure: Timeout for Dispatched MDN
- The ETT test results for XDR MT Test 37 are successful.
XDR Positive Delivery Notification
- The ETT test results for XDR MT Test 38 are successful.
All Steps (Approved SVAP Version)
- Use the ETT Direct 1.3 to perform above verifications.
| System Under Test | Test Lab Verification |
|---|---|
|
Disposition-Notification-Options Header
Delivery Failure Due to Bad Destination Address
Delivery Failure Due to Untrusted Destination HISP
Delivery Failure Due to Unpublished Certificate for Destination HISP
Delivery Failure Timeout for Processed MDN
Delivery Failure for Dispatched MDN
Delivery Failure Timeout for Dispatched MDN
Positive Delivery Notification
Requesting Delivery Notification for XDR Edge HISP
XDR Delivery Failure: Bad Address
XDR Delivery Failure: Untrusted Destination HISP
XDR Delivery Failure: Unpublished Destination HISP Certificate
XDR Delivery Failure: No Processed MDN
XDR Delivery Failure: No Dispatched MDN
XDR Delivery Failure: Timeout for Dispatched MDN
XDR Positive Delivery Notification
All Steps (Approved SVAP Version)
|
Disposition-Notification-Options Header
Delivery Failure Due to Bad Destination Address
Delivery Failure Due to Untrusted Destination HISP
Delivery Failure Due to Unpublished Certificate for Destination HISP
Delivery Failure Timeout for Processed MDN
Delivery Failure for Dispatched MDN
Delivery Failure Timeout for Dispatched MDN
Positive Delivery Notification
Requesting Delivery Notification for XDR Edge HISP
XDR Delivery Failure: Bad Address
XDR Delivery Failure: Untrusted Destination HISP
XDR Delivery Failure: Unpublished Destination HISP Certificate
XDR Delivery Failure: No Processed MDN
XDR Delivery Failure: No Dispatched MDN
XDR Delivery Failure: Timeout for Dispatched MDN
XDR Positive Delivery Notification
All Steps (Approved SVAP Version)
|
Paragraph (h)(2)(ii) – Receive
SMTP: Disposition-Notification-Options Header
- Using the ETT: HISP & Delivery Notification “Message Tracking” using “Your System as Receiver”, the Health IT Module is able to receive and successfully process a message from the ETT (as Sending HISP) that contains a valid Disposition-Notification-Options Header and include it in the message to the destination (SMTP MT Test 39).
- Negative Test: The Health IT Module is able to receive and successfully process a message from the ETT (as Sending HISP) that contains an invalid Disposition-Notification-Options Header and include it in the message to the destination (SMTP MT Test 40).
XDR: Failure Notification (Configurable Wait Time Exceeded)
- The Health IT Module receives a message from the ETT (as Sending HISP), using the ETT: HISP & Delivery Notification “XDR Cases” with “System as Receiver”, and is unable to deliver the message to its final destination (ETT as Destination Edge). The Health IT Module delivers a Processed MDN to the ETT (as Sending HISP) followed by a delivery failure message to the ETT (as Sending HISP) after the wait time has exceeded for delivering the message to its final destination (XDR MT Test 43).
XDR: Failure Notification
- The Health IT Module receives a message from the ETT (as Sending HISP), and is unable to deliver the message to its final destination (ETT as Destination Edge) due to a bad address (non-existent). The Health IT Module delivers a Processed MDN to the ETT (as Sending HISP) followed by a delivery failure message to the ETT (as Sending HISP) due to the bad address (non-existent) (XDR MT Test 44).
All Steps (Approved SVAP Version)
- Use the ETT Direct 1.3 to complete above steps.
SMTP: Disposition-Notification-Options Header
- The ETT test results for SMTP MT Test 39 are successful.
- The ETT test results for SMTP MT Test 40 are successful.
XDR: Failure Notification (Configurable Wait Time Exceeded)
- The ETT test results for XDR MT Test 43 are successful.
XDR: Failure Notification
- The ETT test results for XDR MT Test 44 are successful.
All Steps (Approved SVAP Version)
- Use the ETT Direct 1.3 to perform above verifications.
| System Under Test | Test Lab Verification |
|---|---|
|
SMTP: Disposition-Notification-Options Header
XDR: Failure Notification (Configurable Wait Time Exceeded)
XDR: Failure Notification
All Steps (Approved SVAP Version)
|
SMTP: Disposition-Notification-Options Header
XDR: Failure Notification (Configurable Wait Time Exceeded)
XDR: Failure Notification
All Steps (Approved SVAP Version)
|
Required Enhanced Testing: Direct v1.2
The Health IT Module submits evidence of multi-partner testing with three different and unrelated partner HISPs using Direct v1.2 (in accordance with the standard specified at § 170.202(a)(2) Direct Project: ONC Applicability Statement for Secure Health Transport, v1.2), formatted only as a “wrapped” message.
(Approved SVAP Version)
The Health IT Module submits evidence of multi-partner testing with three different and unrelated partner HISPs using Direct v1.3 (in accordance with the standard specified at ONC Applicability Statement for Secure Health Transport, v1.3, May, 2022 (Direct).
Paragraph (h)(2)(i)(A) – Send
The Health IT Module provides evidence of and demonstrates successful send of encrypted and signed health information from the Health IT Module to three partners (e.g., other vendor Health IT Modules (HISPs) that have implemented (h)(1) or (h)(2) capabilities) using Direct v1.2, in accordance with the standard specified at § 170.202(a)(2) Direct Project: ONC Applicability Statement for Secure Health Transport, v1.2, which includes:
- Documentation of the Health IT Module sending “Wrapped” RFC-5751, messages to three partner HISPs.
- Documentation of the Health IT Module receiving processed Message Disposition Notifications (MDNs) from each of the three partner HISPs generated by the partner HISPs upon receiving the Direct message from the Health IT Module.
(Approved SVAP Version)
- Use the ETT Direct 1.3 to complete this test.
The tester verifies the Health IT Module has successfully sent encrypted and signed health information to three partner HISPs using Direct v1.2, in accordance with the standard specified at § 170.202(a)(2). The verification includes:
- Indication through documentation that the Health IT Module sent “Wrapped” RFC-5751, messages to three separate and unrelated HISP partners.
- Indication through documentation of the Health IT Module receiving processed Message Disposition Notifications (MDNs) from each of the three partner HISPs generated upon receiving the Direct message from the Health IT Module.
(Approved SVAP Version)
- Use the ETT Direct 1.3 to perform above verifications in accordance with the standards specified in ONC Applicability Statement for Secure Health Transport, v1.3, May, 2022 (Direct).
| System Under Test | Test Lab Verification |
|---|---|
|
The Health IT Module provides evidence of and demonstrates successful send of encrypted and signed health information from the Health IT Module to three partners (e.g., other vendor Health IT Modules (HISPs) that have implemented (h)(1) or (h)(2) capabilities) using Direct v1.2, in accordance with the standard specified at § 170.202(a)(2) Direct Project: ONC Applicability Statement for Secure Health Transport, v1.2, which includes:
(Approved SVAP Version)
|
The tester verifies the Health IT Module has successfully sent encrypted and signed health information to three partner HISPs using Direct v1.2, in accordance with the standard specified at § 170.202(a)(2). The verification includes:
(Approved SVAP Version)
|
Paragraph (h)(2)(i)(A) – Required Enhanced1 Testing, Receive
1 Partners the Health IT Module chooses to test with do not have to be certified at the time of testing as long as the testing uses the Direct v1.2, (in accordance with the standard specified at § 170.202(a)(2) Direct Project: ONC Applicability Statement for Secure Health Transport, v1.2), formatted only as a “wrapped” message.
(Approved SVAP Version)
- 1 Partners who the Health IT Module chooses to test with do not have to be certified at the time of testing as long as the testing uses the Direct v1.3, in accordance with the standard specified at ONC Applicability Statement for Secure Health Transport, v1.3, May, 2022 (Direct), formatted only as a “wrapped” message.
The user provides evidence of successful receipt of encrypted and signed health information from three partners (e.g., other vendor Health IT Modules (HISPs) that have implemented (h)(2) capabilities) using Direct v1.2 in accordance with the standard specified at § 170.202(a)(2) Direct Project: ONC Applicability Statement for Secure Health Transport, v1.2. The evidence includes:
- Documentation of the Health IT Module receiving “Wrapped” RFC-5751 messages from three partner HISPs.
- Documentation of the Health IT Module generates and sends processed Message Disposition Notifications (MDNs) that are transmitted to each of the three partner HISPs generated upon successfully receiving a Direct message from the Health IT Module.
(Approved SVAP Version)
- Use the ETT Direct 1.3 to complete this test in accordance with the standards specified in ONC Applicability Statement for Secure Health Transport, v1.3, May, 2022 (Direct).
The tester verifies that the Health IT Module has received encrypted and signed health information from three partner HISPs using Direct v1.2, in accordance with the standard specified at § 170.202(a)(2). The documentation includes:
- Indication that the Health IT Module successfully received “Wrapped” RFC-5751 messages from three separate and unrelated HISP partners.
- Indication of the Health IT Module generating and transmitting processed Message Disposition Notification (MDNs) to each of the three partner HISPs generated upon receiving the Direct message from each partner HISP.
(Approved SVAP Version)
- Use the ETT Direct 1.3 to perform above verifications in accordance with the standards specified in ONC Applicability Statement for Secure Health Transport, v1.3, May, 2022 (Direct).
| System Under Test | Test Lab Verification |
|---|---|
|
The user provides evidence of successful receipt of encrypted and signed health information from three partners (e.g., other vendor Health IT Modules (HISPs) that have implemented (h)(2) capabilities) using Direct v1.2 in accordance with the standard specified at § 170.202(a)(2) Direct Project: ONC Applicability Statement for Secure Health Transport, v1.2. The evidence includes:
(Approved SVAP Version)
|
The tester verifies that the Health IT Module has received encrypted and signed health information from three partner HISPs using Direct v1.2, in accordance with the standard specified at § 170.202(a)(2). The documentation includes:
(Approved SVAP Version)
|
Required Enhanced Testing: ONC XDR and XDM for Direct
The Health IT Module submits evidence of multi-partner testing with three different and unrelated partner HISPs using Direct v1.2, (in accordance with the standard specified at § 170.202(b) ONC XDR and XDM for Direct Messaging Specification (incorporated by reference in § 170.299)), including support for both limited and full XDS metadata profiles, formatted only as a “wrapped” message.
Paragraph (h)(2)(i)(B) – Send
The Health IT Module provides evidence and demonstrates of successful send of encrypted and signed health information from the Health IT Module to three partners (e.g., other vendor Health IT Modules (HISPs) that have implemented (h)(1) or (h)(2) capabilities) using Direct v1.2 in accordance with the standard specified at § 170.202(b) ONC XDR and XDM for Direct Messaging Specification which includes:
- Documentation of the Health IT Module sending “Wrapped” RFC-5751, messages to three partner HISPs.
- Documentation of the Health IT Module receiving processed Message Disposition Notifications (MDNs) from each of the three partner HISPs generated by the partner HISPs upon receiving the Direct message from the Health IT Module.
(Approved SVAP Version)
- Use the ETT Direct 1.3 to complete this test.
The tester verifies that the Health IT Module has successfully sent encrypted and signed health information to three partner HISPs using Direct v1.2, in accordance with the standard specified at § 170.202(b). The verification includes:
- Indication through documentation that the Health IT Module sent “Wrapped” RFC-5751, messages to three separate and unrelated HISP partners.
- Indication through documentation of the Health IT Module receiving processed Message Disposition Notifications (MDNs) from each of the three partner HISPs generated upon receiving the Direct message from the Health IT Module.
(Approved SVAP Version)
- Use the ETT Direct 1.3 to perform above verifications.
| System Under Test | Test Lab Verification |
|---|---|
|
The Health IT Module provides evidence and demonstrates of successful send of encrypted and signed health information from the Health IT Module to three partners (e.g., other vendor Health IT Modules (HISPs) that have implemented (h)(1) or (h)(2) capabilities) using Direct v1.2 in accordance with the standard specified at § 170.202(b) ONC XDR and XDM for Direct Messaging Specification which includes:
(Approved SVAP Version)
|
The tester verifies that the Health IT Module has successfully sent encrypted and signed health information to three partner HISPs using Direct v1.2, in accordance with the standard specified at § 170.202(b). The verification includes:
(Approved SVAP Version)
|
Paragraph (h)(2)(i)(B) – Required Enhanced1 Testing, Receive
1 Partners who the Health IT Module chooses to test with do not have to be certified at the time of testing as long as the testing uses the Direct v1.2, (in accordance with the standard specified at § 170.202(b) ONC XDR and XDM for Direct Messaging Specification), formatted only as a “wrapped” message.
The user provides evidence of successful receipt of encrypted and signed health information from three partners (e.g., other vendor Health IT Modules (HISPs) that have implemented (h)(2) capabilities) using Direct v1.2, in accordance with the standard specified § 170.202(b) ONC XDR and XDM for Direct Messaging Specification. The evidence includes:
- Documentation of the Health IT Module receiving “Wrapped” RFC-5751, messages from three partner HISPs.
- Documentation of the Health IT Module generates and sends processed Message Disposition Notifications (MDNs) that are transmitted to each of the three partner HISPs generated upon successfully receiving a Direct message from the Health IT Module.
(Approved SVAP Version)
- Use the ETT Direct 1.3 to complete this test.
The tester verifies that the Health IT Module has received encrypted and signed health information from three partner HISPs using Direct v1.2, in accordance with the standard specified at § 170.202(b). The documentation includes:
- Indication that the Health IT Module successfully received “Wrapped” RFC-5751, messages from three separate and unrelated HISP partners.
- Indication of the Health IT Module generating and transmitting processed Message Disposition Notification (MDNs) to each of the three partner HISPs generated upon receiving the Direct message from each partner HISP.
(Approved SVAP Version)
- Use the ETT Direct 1.3 to perform above verifications.
| System Under Test | Test Lab Verification |
|---|---|
|
The user provides evidence of successful receipt of encrypted and signed health information from three partners (e.g., other vendor Health IT Modules (HISPs) that have implemented (h)(2) capabilities) using Direct v1.2, in accordance with the standard specified § 170.202(b) ONC XDR and XDM for Direct Messaging Specification. The evidence includes:
(Approved SVAP Version)
|
The tester verifies that the Health IT Module has received encrypted and signed health information from three partner HISPs using Direct v1.2, in accordance with the standard specified at § 170.202(b). The documentation includes:
(Approved SVAP Version)
|
| Version # | Description of Change | Version Date |
|---|---|---|
| 1.0 |
Initial Publication |
10-30-2015
|
| 1.1 |
Removed email protocol clarification that’s not applicable for 2015 Edition certification. Added update reference for Delivery Notification in Direct. Added clarification on SMTP and XDR standards for HISP getting certified to (h)(2). |
03-24-2016
|
| 1.2 |
Added clarification to note that certification to this criterion is the only option for “transport-only” focused Health Information Services Providers (HISPs), but certification would also allow the HISP technology to electronically exchange with any health IT certified to § 170.315(b)(1) and may be used to meet the 2015 Edition Base EHR definition with any other health IT certified to § 170.315(b)(1) without the need for joint certification. |
07-06-2016
|
| 1.3 |
Added HISP guidance in regards to sending dispatched MDNs in production. |
10-07-2016
|
| 1.4 |
Added definition of a secure network. Clarification of the cipher suite requirements due to updated standards. |
07-07-2017
|
| 1.5 |
Revised the location of the Edge Testing Tool training videos in the section “applies to entire criterion". Clarified that Direct, the Edge protocols (SMTP & XDR) and XDM processing are required by this criterion, consistent with interpretative guidance provided in the 2015 Edition Final Rule in the section “applies to entire criterion”. |
11-29-2017
|
| 1.6 |
Updated the Security requirements per 21st Century Cures Act. |
06-15-2020
|
§ 170.315 (h)(2) Direct Project, Edge Protocol, and XDR/XDM—
- 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;
- The standard specified in § 170.202(b), including support for both limited and full XDS metadata profiles; and
- Both edge protocol methods specified by the standard in § 170.202(d).
- Delivery Notification in Direct. Able to send and receive health information in accordance with the standard specified in § 170.202(e)(1).
Paragraph (h)(2)(i)(A)
§ 170.202(a)(2) Direct Project: ONC Applicability Statement for Secure Health Transport, Version 1.2, August 2015
Paragraph (h)(2)(i)(B)
§ 170.202(b) ONC XDR and XDM for Direct Messaging Specification
Paragraph (h)(2)(i)(C)
§ 170.202(d) ONC Implementation Guide for Direct Edge Protocols, Version 1.1, June 25, 2014
Paragraph (h)(2)(ii)
§ 170.202(e)(1) Delivery Notification - Implementation Guide for Delivery Notification in Direct v1.0
Standard Version Advancement Process (SVAP) Version(s) Approved
§ 170.202(a)(2) Direct Project: ONC Applicability Statement for Secure Health Transport, Version 1.3, May 2021 (Direct)
For more information, please visit the Standards Version Advancement Process (SVAP) Version(s) page.
- Resource Documents
- Revision History
-
Version # Description of Change Version Date 1.0 Initial Publication
10-30-20151.1 Removed email protocol clarification that’s not applicable for 2015 Edition certification.
Added update reference for Delivery Notification in Direct.
Added clarification on SMTP and XDR standards for HISP getting certified to (h)(2).
03-24-20161.2 Added clarification to note that certification to this criterion is the only option for “transport-only” focused Health Information Services Providers (HISPs), but certification would also allow the HISP technology to electronically exchange with any health IT certified to § 170.315(b)(1) and may be used to meet the 2015 Edition Base EHR definition with any other health IT certified to § 170.315(b)(1) without the need for joint certification.
07-06-20161.3 Added HISP guidance in regards to sending dispatched MDNs in production.
10-07-20161.4 Added definition of a secure network.
Clarification of the cipher suite requirements due to updated standards.
07-07-20171.5 Revised the location of the Edge Testing Tool training videos in the section “applies to entire criterion".
Clarified that Direct, the Edge protocols (SMTP & XDR) and XDM processing are required by this criterion, consistent with interpretative guidance provided in the 2015 Edition Final Rule in the section “applies to entire criterion”.
11-29-20171.6 Updated the Security requirements per 21st Century Cures Act.
06-15-2020 - Regulation Text
-
Regulation Text
§ 170.315 (h)(2) Direct Project, Edge Protocol, and XDR/XDM—
- 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;
- The standard specified in § 170.202(b), including support for both limited and full XDS metadata profiles; and
- Both edge protocol methods specified by the standard in § 170.202(d).
- Delivery Notification in Direct. Able to send and receive health information in accordance with the standard specified in § 170.202(e)(1).
- Able to send and receive health information in accordance with:
- Standard(s) Referenced
-
Paragraph (h)(2)(i)(A)
§ 170.202(a)(2) Direct Project: ONC Applicability Statement for Secure Health Transport, Version 1.2, August 2015
Paragraph (h)(2)(i)(B)
§ 170.202(b) ONC XDR and XDM for Direct Messaging Specification
Paragraph (h)(2)(i)(C)
§ 170.202(d) ONC Implementation Guide for Direct Edge Protocols, Version 1.1, June 25, 2014
Paragraph (h)(2)(ii)
§ 170.202(e)(1) Delivery Notification - Implementation Guide for Delivery Notification in Direct v1.0
Standard Version Advancement Process (SVAP) Version(s) Approved
§ 170.202(a)(2) Direct Project: ONC Applicability Statement for Secure Health Transport, Version 1.3, May 2021 (Direct)
For more information, please visit the Standards Version Advancement Process (SVAP) Version(s) page.
- Testing
-
Testing Tool
Approved SVAP Version(s)
Edge Testing Tool (ETT): Direct Testing
2015 Direct Certificate Discovery Tool (DCDT)
Testing must be conducted for one of the Sending Alternatives outlined on the Test Procedure tab to satisfy the requirements for this criterion.
Testing must also be conducted for one of the alternative connection requirements within each of the Sending Alternatives on the Test Procedure tab.Note: The “Secure Network” alternative only needs to be verified once for the Testing Procedure. (Where applicable the TLS required should be unchecked in the ETT Profile).
Testing must be conducted for one of the Receiving Alternatives outlined on the Test Procedure tab to satisfy the requirements for this criterion: IHE XDR, SMTP, IMAP, or POP3.
Test Tool Documentation
Criterion Subparagraph Test Data (h)(2) Refer to the Edge Testing Tool (ETT)
Certification Companion Guide: Direct Project, Edge Protocol, and XDR/XDM
This Certification Companion Guide (CCG) is an informative document designed to assist with health IT product development. The CCG is not a substitute for the 2015 Edition final regulation. It extracts key portions of the rule’s preamble and includes subsequent clarifying interpretations. To access the full context of regulatory intent please consult the 2015 Edition final rule or other included regulatory reference. The CCG is for public use and should not be sold or redistributed.
| Base EHR Definition | In Scope for CEHRT Definition | Real World Testing | USCDI | SVAP |
|---|---|---|---|---|
| Included | Yes | No | No | Yes |
Privacy and Security: This certification criterion was adopted at § 170.315(h)(2). As a result, an ONC Authorized Certification Body (ONC-ACB) must ensure that a product presented for certification to a § 170.315(h) criterion includes the privacy and security criteria (adopted in § 170.315(d)) within the overall scope of the certificate issued to the product.
- The privacy and security criteria (adopted in § 170.315(d)) do not need to be explicitly tested with this specific paragraph (h) criterion unless it is the only criterion for which certification is requested.
- As a general rule, a product presented for certification only needs to be tested once to each applicable privacy and security criterion (adopted in § 170.315(d)) so long as the health IT developer attests that such privacy and security capabilities apply to the full scope of capabilities included in the requested certification. However, exceptions exist for § 170.315(e)(1) “View, download, and transmit to 3rd party (VDT)” and (e)(2) “Secure messaging,” which are explicitly stated.
- § 170.315(d)(2)(i)(C) is not required if the scope of the Health IT Module does not have end-user device encryption features.
- If choosing Approach 1:
- If choosing Approach 2:
- For each applicable privacy and security certification criterion not certified using Approach 1, the health IT developer may certify using system documentation which is sufficiently detailed to enable integration such that the Health IT Module has implemented service interfaces to access external services necessary to meet the requirements of the privacy and security certification criterion. Please see the ONC Cures Act Final Rule at 85 FR 25710 for additional clarification.
Design and Performance: The following design and performance certification criteria (adopted in § 170.315(g)) must also be certified in order for the product to be certified.
- When a single quality management system (QMS) is used, the QMS only needs to be identified once. Otherwise, the QMS’ need to be identified for every capability to which it was applied.
- When a single accessibility-centered design standard is used, the standard only needs to be identified once. Otherwise, the accessibility-centered design standards need to be identified for every capability to which they were applied; or, alternatively, the developer must state that no accessibility-centered design was used.
Privacy and Security: This certification criterion was adopted at § 170.315(h)(2). As a result, an ONC Authorized Certification Body (ONC-ACB) must ensure that a product presented for certification to a § 170.315(h) criterion includes the privacy and security criteria (adopted in § 170.315(d)) within the overall scope of the certificate issued to the product.
- The privacy and security criteria (adopted in § 170.315(d)) do not need to be explicitly tested with this specific paragraph (h) criterion unless it is the only criterion for which certification is requested.
- As a general rule, a product presented for certification only needs to be tested once to each applicable privacy and security criterion (adopted in § 170.315(d)) so long as the health IT developer attests that such privacy and security capabilities apply to the full scope of capabilities included in the requested certification. However, exceptions exist for § 170.315(e)(1) “View, download, and transmit to 3rd party (VDT)” and (e)(2) “Secure messaging,” which are explicitly stated.
- § 170.315(d)(2)(i)(C) is not required if the scope of the Health IT Module does not have end-user device encryption features.
Design and Performance: The following design and performance certification criteria (adopted in § 170.315(g)) must also be certified in order for the product to be certified.
- When a single quality management system (QMS) is used, the QMS only needs to be identified once. Otherwise, the QMS’ need to be identified for every capability to which it was applied.
- When a single accessibility-centered design standard is used, the standard only needs to be identified once. Otherwise, the accessibility-centered design standards need to be identified for every capability to which they were applied; or, alternatively, the developer must state that no accessibility-centered design was used.
- If choosing Approach 1:
- If choosing Approach 2:
- For each applicable privacy and security certification criterion not certified using Approach 1, the health IT developer may certify using system documentation which is sufficiently detailed to enable integration such that the Health IT Module has implemented service interfaces to access external services necessary to meet the requirements of the privacy and security certification criterion. Please see the ONC Cures Act Final Rule at 85 FR 25710 for additional clarification.
Applies to entire criterion
Clarifications:
- In order to meet the Base EHR Definition, a provider would need to possess technology that has been certified to either this criterion at § 170.315(h)(2) or the “Direct Project” criterion at § 170.315(h)(1).
- Several training/demo videos of the Edge Testing Tool (ETT) used for the testing and certification of health IT are available on GitHub.
- Please address any ETT technical questions through the ETT Google Group.
- This certification criterion uses the Applicability Statement for Secure Health Transport, Version 1.2 standard. This new version of the specification includes updates that improve interoperability through the clarification of requirements that have been subject to varying interpretations, particularly requirements around message delivery notifications. This version also clarifies pertinent requirements in the standards underlying the Applicability Statement for Secure Health Transport. Refer to the standard for more details about the improvements it includes. [see also 80 FR 62679]
- Testing for this criterion will require the processing of invalid test cases that frequently occur in real-world situations so that Security/Trust Agents (STAs) can demonstrate error handling abilities, including handling XDM packages and message disposition.
- Direct, the Edge protocols (SMTP, XDR) and XDM processing are the required standards for health IT certifying to (h)(2). IMAP and POP3 are optional SMTP standards. [see also 80 FR 62680]
- Certification to this criterion is the only option for “transport-only” focused health information services providers (HISPs). However, HISP technology certified to this criterion would be able to electronically exchange with any health IT certified to § 170.315(b)(1). Further, HISP technology certified to this criterion may also be used to meet the 2015 Edition Base EHR definition with any other health IT certified to § 170.315(b)(1) without the need for joint certification of the products.
- Consistent with the IG for Delivery Notification in Direct, ONC's policy intent is that the receiving HISP must provide delivery notification messages either when it is also the sending HISP, or when it is specifically requested to do so by the sending HISP. A HISP is not compelled to request delivery notifications, but a certified HISP is required to produce them if requested.
- A secure network is generally recognized as one where all of the nodes (endpoints) are known, uniquely identified, access controlled, with strong end-to-end encryption. For example, a virtual private network (VPN) or a network physically isolated from any other with specialized equipment using endpoint encryption.
Applies to entire criterion
|
Clarifications:
|
Paragraph (h)(2)(i)
Technical outcome – The Health IT Module can electronically transmit (send and receive) health information to and from a third party using each of:
- Applicability Statement for Secure Health Transport, Version 1.2 (the “Direct Project” specification);
- The ONC XDR and XDM for Direct Messaging Specification, Version 1, including support for both limited and full XDS metadata profiles;
- And both of the protocols in the ONC Implementation Guide for Direct Edge Protocols, Version 1.1.
Clarifications:
- This criterion requires the three capabilities specified (Direct Project specification, Edge Protocol compliance, and XDR/XDM processing) because it must support interoperability and all potential certified exchange options. A provider could use an “independent” HISP to meet the Base EHR definition. In such a case, the HISP would need to be certified to this criterion in order for the provider to use it to meet the Base EHR definition, which is part of the CEHRT definition under the Promoting Interoperability Programs. [see also 80 FR 62681]
- For developers implementing the ONC XDR/XDM for Direct Messaging Specification, when converting an SMTP message into XDR (with limited metadata), UUID URNs formatted as OIDs should be used for DocumentEntry.uniqueId, SubmissionSet.sourceId, and SubmissionSet.uniqueId ONC expects testing to this specification to reflect this clarification. [Health IT Certification Program Overview]
- Even though the IG for Edge Protocols requires support for XDS limited metadata, XDR/XDM supports capability to transform messages using full metadata wherever appropriate. Therefore, ONC requires that a Health IT Module must support both the XDS Metadata profiles (limited and full), as specified in the underlying IHE specifications, to ensure that the transformation between messages packaged using XDR/XDM are done with as much appropriate metadata as possible. [see also 80 FR 62681]
- For certification to this criterion, ONC has made it a requirement to send and receive messages in only “wrapped” format even though the specification (IG) allows use of “unwrapped” messages. This requirement will further improve interoperability among Security/Trust Agents (STAs) while having minor development impact on health IT developers. [see also 80 FR 62679]
- The protocols listed in the IG, section 1.3.1 explicitly list conformance to RFC 3501. The RFC, then originally published, mandated using the TLS_RSA_WITH_RC4_128_MD5 cipher suite within the TLS 1.0 bundle. RFC 3501 has had subsequent updates making the listed cipher suite obsolete and rescinded within the TLS 1.0 bundle. Current industry practice is to implement cipher suites that are compliant with TLS 1.1(shall), TLS 1.2 (should), and TLS 1.0 (may).
Paragraph (h)(2)(i)
|
Technical outcome – The Health IT Module can electronically transmit (send and receive) health information to and from a third party using each of:
|
Paragraph (h)(2)(ii)
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.
Clarifications:
- The IG for Delivery Notification in Direct, Version 1.0, June 29, 2012 functionality supports interoperability and exchange, particularly for both sending and receiving parties, guidance enabling HISPs to provide a high level of assurance to senders that a message has arrived at its destination, a necessary component to interoperability. The IG also outlines the various exception flows that result in compromised message delivery and the mitigation actions that should be taken by STAs to provide success and failure notifications to the sending system. [see also 80 FR 62729]
- For Delivery Notification in Direct, the capability to send and receive health information must be in accordance with the standard specified in § 170.202(e)(1).
Paragraph (h)(2)(ii)
|
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. Clarifications:
|