§170.315(h)(1) Direct Project
| Version # | Description of Change | Version Date |
|---|---|---|
| 1.0 |
Final Test Procedure |
01-29-2016
|
| 1.1 |
Updated documentation icon. Corrected reference to TTT to ETT for section (h)(1)(i) – Receive System Under Test step 6. Removed all the XDR related delivery notification tests. (h)(1)(ii) – Send – removed negative test SMTP/IMAP/POP MT Test 22. |
03-21-2016
|
| 1.2 |
Removed XDR notification test cases. Updated XDR MT test cases to reflect correct SMTP MT test cases. Removed Applicability Statement text from criteria paragraph header language for paragraph (h)(1)(ii). |
04-12-2016
|
| 1.3 |
Removed message tracking tests that require Edge protocols. |
05-17-2016
|
| 1.4 |
Corrected Reject Receive of Direct Messages in paragraph (h)(1)(i):
Reformatted the test procedures for readability. The System Under Test aligns closer to the to the Test Lab section.
Removed the link for DCDT; provided navigation instructions instead. |
05-26-2017
|
| 1.5 |
Updated to include the Standards Version Advancement Process (SVAP) Approved Standards for 2022. |
01-23-2023
|
§ 170.315 (h)(1) Direct Project—
- Applicability Statement for Secure Health Transport. Able to send and receive health information in accordance with the standard specified in § 170.202(a)(2), including formatted only as a “wrapped” message.
- Delivery Notification in Direct. Able to send and receive health information in accordance with the standard specified in § 170.202(e)(1).
Paragraph (h)(1)(i)
§ 170.202(a)(2) Direct Project: ONC Applicability Statement for Secure Health Transport, Version 1.2, August 2015
Paragraph (h)(1)(ii)
§ 170.202(e)(1) Delivery Notification - Implementation Guide for Delivery Notification in Direct v1.0
Standard Version Advancement Process (SVAP) Version(s) Approved
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 Updated documentation icon.
Corrected reference to TTT to ETT for section (h)(1)(i) – Receive System Under Test step 6.
Removed all the XDR related delivery notification tests.
(h)(1)(ii) – Send – removed negative test SMTP/IMAP/POP MT Test 22.
03-21-20161.2 Removed XDR notification test cases.
Updated XDR MT test cases to reflect correct SMTP MT test cases.
Removed Applicability Statement text from criteria paragraph header language for paragraph (h)(1)(ii).
04-12-20161.3 Removed message tracking tests that require Edge protocols.
05-17-20161.4 Corrected Reject Receive of Direct Messages in paragraph (h)(1)(i):
- Removed Invalid Trust Anchor from the list of tests. This is considered a duplicate of Invalid Trust Relationship (Different Trust Anchor).
Reformatted the test procedures for readability. The System Under Test aligns closer to the to the Test Lab section.
- Several numbering and narrative formatting changes.
Removed the link for DCDT; provided navigation instructions instead.
05-26-20171.5 Updated to include the Standards Version Advancement Process (SVAP) Approved Standards for 2022.
01-23-2023 - Regulation Text
-
Regulation Text
§ 170.315 (h)(1) Direct Project—
- Applicability Statement for Secure Health Transport. Able to send and receive health information in accordance with the standard specified in § 170.202(a)(2), including formatted only as a “wrapped” message.
- Delivery Notification in Direct. Able to send and receive health information in accordance with the standard specified in § 170.202(e)(1).
- Standard(s) Referenced
-
Paragraph (h)(1)(i)
§ 170.202(a)(2) Direct Project: ONC Applicability Statement for Secure Health Transport, Version 1.2, August 2015
Paragraph (h)(1)(ii)
§ 170.202(e)(1) Delivery Notification - Implementation Guide for Delivery Notification in Direct v1.0
Standard Version Advancement Process (SVAP) Version(s) Approved
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
Edge Testing Tool (ETT): Direct Testing
2015 Direct Certificate Discovery Tool (DCDT)
Approved SVAP Version(s)
Edge Testing Tool - Direct
Test Tool Documentation
Criterion Subparagraph Test Data (h)(1) 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)(1)(i) - Send
Discover Certificates
- The user performs setup tasks to discover 2015 Direct Certificate Discovery Tool (DCDT) certificates by downloading the DCDT Trust Anchor, 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).
Register Direct Address
- The user selects “Register Direct” within the Edge Testing Tool (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. ONC-supplied payloads are available for download from the ETT-Direct home 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 only), 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.
Send Health Information Using Direct (Approved SVAP Version)
- For the above steps 3-4, use the ONC Applicability Statement for Secure Health Transport, Version 1.3, May 2021 (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 listed certificates listed in both DNS and LDAP must be tested corresponding to the standard 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), and using the RFC-5751, “wrapped” message format.
- Using the validation report, the tester verifies that the payload was successfully received by the ETT, and that the ETT was able to successfully decrypt the message.
Send Health Information Using Direct (Approved SVAP Version)
- Use the Validation Report SVAP 2022 to verify the above steps.
| System Under Test | Test Lab Verification |
|---|---|
|
Discover Certificates
Register Direct Address
Send Health Information Using Direct
Based upon the types of Direct messages the Health IT Module supports for sending of information (“wrapped” RFC-5751, messages only), 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.
Send Health Information Using Direct (Approved SVAP Version)
|
Discover Certificates
Register Direct Address
Send Health Information Using Direct
Send Health Information Using Direct (Approved SVAP Version)
|
Paragraph (h)(1)(i) - Receive
Hosting Certificates
- The user performs setup tasks to test hosting of certificates (by entering the Health IT Module’s Direct address within 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.
SUT Connection
- The user selects “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 of the Health IT Module’s Public Key for encryption of messages to be sent by ETT to the Health IT Module.
SUT Connection (Approved SVAP Version)
- For step 2, the user selects “Send Direct Message – Direct v1.3”.
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 Message Delivery Notifications (MDNs).
Receive Direct Message (Approved SVAP Version)
Complete the following additional steps:
- The user receives messages using certificates with 3072 bits sent from ETT using Direct in accordance with ONC Applicability Statement for Secure Health Transport, Version 1.3, May 2021 (Direct) adopted via the SVAP 2022, and sends corresponding Message Delivery Notifications (MDNs).
- The user receives messages using certificates with 4096 bits sent from ETT using Direct in accordance with ONC Applicability Statement for Secure Health Transport, Version 1.3, May 2021 (Direct) adopted via the SVAP 2022, and sends corresponding Message Delivery Notifications (MDNs).
- The user receives messages created using different signature algorithms specified in the ETT using Direct in accordance with ONC Applicability Statement for Secure Health Transport, Version 1.3, May 2021 (Direct) adopted via the SVAP 2022, and sends corresponding Message Delivery Notifications (MDNs).
Reject Receipt of Direct Message (Negative Testing)
- The user rejects health information 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 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 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 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 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.
Reject Receipt of Direct Message (Approved SVAP Version)
Complete the following additional steps:
- The user rejects health information not in accordance with the ONC Applicability Statement for Secure Health Transport, Version 1.3, May 2021 (Direct) adopted via the SVAP 2022 sent from the ETT to the Health IT Module using the following tool option: WILD_CARD_DOMAIN_CERT.
- The user rejects health information not in accordance with the ONC Applicability Statement for Secure Health Transport, Version 1.3, May 2021 (Direct) adopted via the SVAP 2022 sent from the ETT to the Health IT Module using the following tool option: CERT_WITH_EMAIL_ADDRESS
- The user rejects health information not in accordance with the ONC Applicability Statement for Secure Health Transport, Version 1.3, May 2021 (Direct) adopted via the SVAP 2022 sent from the ETT to the Health IT Module using the following tool option: CERT_LESS_THAN_2048_BITS
- The user rejects health information not in accordance with the ONC Applicability Statement for Secure Health Transport, Version 1.3, May 2021 (Direct) adopted via the SVAP 2022 sent from the ETT to the Health IT Module using the following tool option: CERT_WITH_NO_CRL
- The user rejects health information not in accordance with the ONC Applicability Statement for Secure Health Transport, Version 1.3, May 2021 (Direct) adopted via the SVAP 2022 sent from the ETT to the Health IT Module using the following tool option: CERT_WITH_NO_NOTBEFORE_ATTR.
- The user rejects health information not in accordance with the ONC Applicability Statement for Secure Health Transport, Version 1.3, May 2021 (Direct) adopted via the SVAP 2022 sent from the ETT to the Health IT Module using the following tool option: CERT_WITH_NO_NOTAFTER_ATTR
Hosting Certificates
- The tester verifies the Health IT Module’s hosted certificates are discoverable as displayed on screen for the DCDT test cases executed.
SUT Connection
- No action required.
Receive Direct 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(a)(2), using “wrapped” RFC-5751, messages and that a MDN from the Health IT Module was received in the ETT for all messages the ETT sent.
Receive Direct Message (Approved SVAP Version)
The tester verifies the following additional steps:
- 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(a)(2), and a MDN from the Health IT Module was received in the ETT for all messages the ETT sent. NOTE: This is an optional requirement, so not receiving a MDN amounts to only a WARNING and not a failure.
- 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(a)(2), and a MDN from the Health IT Module was received in the ETT for all messages the ETT sent.
- NOTE: This is an optional requirement, so not receiving a MDN amounts to only a WARNING and not a failure.
- 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(a)(2), and a MDN from the Health IT Module was received in the ETT for all messages the ETT sent.
- NOTE: ECDSA based signature algorithms are optional requirement, so not receiving a MDN amounts to only a WARNING and not a failure.
Reject Receipt of Direct Message (Negative Testing)
- Invalid Certificate: The tester verifies the Health IT Module rejects a Direct message received with an invalid Trust Anchor and no corresponding MDN was received by the ETT from the Health IT Module.
- Expired Certificate: The tester verifies the Health IT Module rejects a Direct message 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 a Direct message received with an invalid Trust Relationship. The tester verifies 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 a Direct message received without an Authority Information Access (AIA) extension 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 a Direct message received with an invalid message digest that no corresponding MDN was received by the ETT from the Health IT Module.
Reject Receipt of Direct Message (Approved SVAP Version)
The tester verifies the following additional steps:
- WILD_CARD_DOMAIN_CERT: The tester verifies the Health IT Module rejects a Direct message received with an invalid message digest that no corresponding MDN was received by the ETT from the Health IT Module.
- CERT_WITH_EMAIL_ADDRESS: The tester verifies the Health IT Module rejects a Direct message received with an invalid message digest that no corresponding MDN was received by the ETT from the Health IT Module.
- CERT_LESS_THAN_2048_BITS: The tester verifies the Health IT Module rejects a Direct message received with an invalid message digest that no corresponding MDN was received by the ETT from the Health IT Module.
- CERT_WITH_NO_CRL: The tester verifies the Health IT Module rejects a Direct message received with an invalid message digest that no corresponding MDN was received by the ETT from the Health IT Module.
- CERT_WITH_NO_NOTBEFORE_ATTR: The tester verifies the Health IT Module rejects a Direct message received with an invalid message digest that no corresponding MDN was received by the ETT from the Health IT Module.
- CERT_WITH_NO_NOTAFTER_ATTR: The tester verifies the Health IT Module rejects a Direct message received with an invalid message digest that no corresponding MDN was received by the ETT from the Health IT Module.
| System Under Test | Test Lab Verification |
|---|---|
|
Hosting Certificates
SUT Connection
SUT Connection (Approved SVAP Version)
Receive Direct Message
Receive Direct Message (Approved SVAP Version) Complete the following additional steps:
Reject Receipt of Direct Message (Negative Testing)
Reject Receipt of Direct Message (Approved SVAP Version) Complete the following additional steps:
|
Hosting Certificates
SUT Connection
Receive Direct Message
Receive Direct Message (Approved SVAP Version) The tester verifies the following additional steps:
Reject Receipt of Direct Message (Negative Testing)
Reject Receipt of Direct Message (Approved SVAP Version) The tester verifies the following additional steps:
|
Paragraph (h)(1)(ii) – Message Disposition Notification: Processed
Disposition-Notification-Options Header
- Using the ETT: HISP Testing & 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 includes it in the message to the destination via SMTP MT Test 39.
- Negative Testing: 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 includes it in the message to the destination via SMTP MT Test 40.
(Approved SVAP Version)
- Use ETT Direct 1.3 to complete above steps.
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.
(Approved SVAP Version)
- The ETT Direct 1.3 test results for SMTP MT Test 40 are successful.
| System Under Test | Test Lab Verification |
|---|---|
|
Disposition-Notification-Options Header
(Approved SVAP Version)
|
Disposition-Notification-Options Header
(Approved SVAP Version)
|
Paragraph (h)(1)(ii) – Message Disposition Notification: Failed
Failure Notification
- Using the ETT: HISP Testing & Delivery Notification “Message Tracking” using “Your system as “Receiver”, the Health IT Module successfully validates security and trust returning a Processed MDN, but cannot deliver the message to its final destination (mailbox full, unavailable, mailbox does not exist) - generating a MDN failed or a failure Delivery Status Notification via SMTP MT Test 41.
(Approved SVAP Version)
- Use ETT Direct 1.3 to complete this test.
Failure Notification
1. The ETT test results for SMTP MT Test 41 are successful.
(Approved SVAP Version)
- The ETT Direct 1.3 test results for SMTP MT Test 41 are successful.
| System Under Test | Test Lab Verification |
|---|---|
|
Failure Notification
(Approved SVAP Version)
|
Failure Notification 1. The ETT test results for SMTP MT Test 41 are successful.
(Approved SVAP Version)
|
Required Enhanced Testing
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, Version 1.3, May 2021 (Direct,) formatted only as a “wrapped” message.
Paragraph (h)(1)(i) – Required Enhanced Testing, Send
The Health IT Module provides evidence and demonstration 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(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; and
- Documentation of the Health IT Module receiving processed 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)
- Complete this test using Direct 1.3 in accordance with the standards specified in ONC Applicability Statement for Secure Health Transport, v1.3, May 2021 (Direct).
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 MDNs from each of the three partner HISPs, generated upon receiving the Direct message from the Health IT Module.
(Approved SVAP Version)
- Perform above verification against the test outcome by Direct 1.3 in accordance with the standards specified in ONC Applicability Statement for Secure Health Transport, v1.3, May 2021 (Direct).
| System Under Test | Test Lab Verification |
|---|---|
|
The Health IT Module provides evidence and demonstration 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(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)(1)(i) – 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, Version 1.3, May 2021 (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; and
- Documentation that the Health IT Module generates and sends processed 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)
- Complete this test using Direct 1.3 in accordance with the standards specified in ONC Applicability Statement for Secure Health Transport, v1.3, May 2021 (Direct).
The tester verifies 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; and
- Indication of the Health IT Module generating and transmitting processed MDNs to each of the three partner HISPs, generated upon receiving the Direct message from each partner HISP.
(Approved SVAP Version)
- Perform above verification against the test outcome by Direct 1.3 in accordance with the standards specified in ONC Applicability Statement for Secure Health Transport, v1.3, May 2021 (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 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)
|
| 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. |
03-26-2016
|
| 1.2 |
Corrected the title for paragraph (h)(1)(ii) in regulation text to read “Delivery Notification in Direct” per the 2015 Edition final rule correction notice. |
04-14-2016
|
| 1.3 |
Reference to § 170.550(j) requirement added, which clarifies that an ONC-ACB can only issue a certification to a Health IT Module for § 170.315(h)(1) if the Health IT Module's certification also includes § 170.315(b)(1). Examples of certification options provided. |
06-30-2016
|
| 1.4 |
Added HISP guidance in regards to sending dispatched MDNs in production. |
10-07-2016
|
| 1.5 |
Updated the Security requirements per 21st Century Cures Act. |
06-15-2020
|
§ 170.315 (h)(1) Direct Project—
- Applicability Statement for Secure Health Transport. Able to send and receive health information in accordance with the standard specified in § 170.202(a)(2), including formatted only as a “wrapped” message.
- Delivery Notification in Direct. Able to send and receive health information in accordance with the standard specified in § 170.202(e)(1).
Paragraph (h)(1)(i)
§ 170.202(a)(2) Direct Project: ONC Applicability Statement for Secure Health Transport, Version 1.2, August 2015
Paragraph (h)(1)(ii)
§ 170.202(e)(1) Delivery Notification - Implementation Guide for Delivery Notification in Direct v1.0
Standard Version Advancement Process (SVAP) Version(s) Approved
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.
03-26-20161.2 Corrected the title for paragraph (h)(1)(ii) in regulation text to read “Delivery Notification in Direct” per the 2015 Edition final rule correction notice.
04-14-20161.3 Reference to § 170.550(j) requirement added, which clarifies that an ONC-ACB can only issue a certification to a Health IT Module for § 170.315(h)(1) if the Health IT Module's certification also includes § 170.315(b)(1). Examples of certification options provided.
06-30-20161.4 Added HISP guidance in regards to sending dispatched MDNs in production.
10-07-20161.5 Updated the Security requirements per 21st Century Cures Act.
06-15-2020 - Regulation Text
-
Regulation Text
§ 170.315 (h)(1) Direct Project—
- Applicability Statement for Secure Health Transport. Able to send and receive health information in accordance with the standard specified in § 170.202(a)(2), including formatted only as a “wrapped” message.
- Delivery Notification in Direct. Able to send and receive health information in accordance with the standard specified in § 170.202(e)(1).
- Standard(s) Referenced
-
Paragraph (h)(1)(i)
§ 170.202(a)(2) Direct Project: ONC Applicability Statement for Secure Health Transport, Version 1.2, August 2015
Paragraph (h)(1)(ii)
§ 170.202(e)(1) Delivery Notification - Implementation Guide for Delivery Notification in Direct v1.0
Standard Version Advancement Process (SVAP) Version(s) Approved
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
Edge Testing Tool (ETT): Direct Testing
2015 Direct Certificate Discovery Tool (DCDT)
Approved SVAP Version(s)
Edge Testing Tool - Direct
Test Tool Documentation
Criterion Subparagraph Test Data (h)(1) Refer to the Edge Testing Tool (ETT)
Certification Companion Guide: Direct Project
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)(1). 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.
- An ONC-ACB can only issue a certification to a Health IT Module for this criterion at § 170.315(h)(1) if the Health IT Module’s certification also includes § 170.315(b)(1) “Transitions of care.”
Privacy and Security: This certification criterion was adopted at § 170.315(h)(1). 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.
- An ONC-ACB can only issue a certification to a Health IT Module for this criterion at § 170.315(h)(1) if the Health IT Module’s certification also includes § 170.315(b)(1) “Transitions of care.”
- 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)(1) or the “Direct Project, Edge Protocol, and XDR/XDM” criterion at § 170.315(h)(2).
- Use of the Applicability Statement for Secure Health Transport (“Direct”) is required to meet this certification criterion. There is no exemption or additional possible transport standard for certification to this criterion.
- 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.
- As specified in § 170.550(j), an ONC-ACB can only issue a certification to a Health IT Module for § 170.315(h)(1) if the Health IT Module's certification also includes § 170.315(b)(1). For example, if Developer X seeks certification to (b)(1) and (h)(1) with its homegrown integrated HISP solution, then their ONC-ACB can issue a certificate with (h)(1) included. Likewise, if Developer X seeks certification to (b)(1) and partners with/integrates a 3rd party health information service provider (HISP) for (h)(1) consistent with the “relied upon software” paradigm, then their ONC-ACB can issue a certificate with (h)(1) included. To note, in this instance, the certification would be specific to Developer X and the 3rd party HISP. Each developer that would want to work with the 3rd party HISP in a similar manner would need to seek the same type of relied upon software certification. Thus, HISPs may want to consider certifying to § 170.315(h)(2), which would not require separate testing/certifications with each developer certified to § 170.315(b)(1).
- Consistent with the Implementation Guide 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.
Applies to entire criterion
|
Clarifications:
|
Paragraph (h)(1)(i)
Technical outcome – The health IT can electronically transmit (send and receive) health information to a 3rd party which must be formatted only as a “wrapped” message using the Applicability Statement for Secure Health Transport, Version 1.2.
Clarifications:
- For certification to this criterion, ONC has made it a requirement to send and receive messages in only “wrapped” format even though the specification 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]
Paragraph (h)(1)(i)
|
Technical outcome – The health IT can electronically transmit (send and receive) health information to a 3rd party which must be formatted only as a “wrapped” message using the Applicability Statement for Secure Health Transport, Version 1.2. Clarifications:
|
Paragraph (h)(1)(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. It provides guidance for 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)(1)(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:
|