§170.315(d)(9) Trusted connection
§ 170.315 (d)(9) Trusted connection—
Establish a trusted connection using one of the following methods:
- Message-level. Encrypt and integrity protect message contents in accordance with the standards specified in § 170.210(a)(2) and (c)(2).
- Transport-level. Use a trusted connection in accordance with the standards specified in § 170.210(a)(2) and (c)(2).
Applies to entire criterion
§ 170.210(a)(2) General. Any encryption algorithm identified by the National Institute of Standards and Technology (NIST) as an approved security function in Annex A of the Federal Information Processing Standards (FIPS) Publication 140-2, Security Requirements for Cryptographic Modules, October 8, 2014
§ 170.210(c)(2) A hashing algorithm with a security strength equal to or greater than SHA-2 as specified by NIST in FIPS Publication 180-4, Secure Hash Standard, 180-4 (August 2015)
Design and performance: Quality management system (§ 170.315(g)(4)) and accessibility-centered design (§ 170.315(g)(5)) must be certified as part of the overall scope of the certificate issued to the product.
- Quality management system (§ 170.315(g)(4)): 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.
- Accessibility-centered design (§ 170.315(g)(5)): 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.
This certification criterion at § 170.315(d)(9) is required as part of the privacy & security approach for the certification criteria at § 170.315(e)(1), (e)(2), (e)(3), (g)(7), (g)(8), and (g)(9). This certification criterion at § 170.315(d)(9) must be explicitly demonstrated with § 170.315(e)(1) and (e)(2) because of the specific capabilities for secure electronic transmission and secure electronic messaging included in each of these two criteria, respectively. For the other certification criteria (§ 170.315(e)(3), (g)(7), (g)(8), and (g)(9)), this criterion at § 170.315(d)(9) only needs to be demonstrated once as part of the overall scope of the certificate sought.
| Version # | Description of Change | Version Date |
|---|---|---|
| 1.0 |
Initial publication |
03-11-2024
|
- Regulation Text
-
Regulation Text
§ 170.315 (d)(9) Trusted connection—
Establish a trusted connection using one of the following methods:
- Message-level. Encrypt and integrity protect message contents in accordance with the standards specified in § 170.210(a)(2) and (c)(2).
- Transport-level. Use a trusted connection in accordance with the standards specified in § 170.210(a)(2) and (c)(2).
- Standard(s) Referenced
-
Applies to entire criterion
§ 170.210(a)(2) General. Any encryption algorithm identified by the National Institute of Standards and Technology (NIST) as an approved security function in Annex A of the Federal Information Processing Standards (FIPS) Publication 140-2, Security Requirements for Cryptographic Modules, October 8, 2014
§ 170.210(c)(2) A hashing algorithm with a security strength equal to or greater than SHA-2 as specified by NIST in FIPS Publication 180-4, Secure Hash Standard, 180-4 (August 2015)
- Certification Dependencies
-
Design and performance: Quality management system (§ 170.315(g)(4)) and accessibility-centered design (§ 170.315(g)(5)) must be certified as part of the overall scope of the certificate issued to the product.
- Quality management system (§ 170.315(g)(4)): 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.
- Accessibility-centered design (§ 170.315(g)(5)): 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 & Security Requirements
-
This certification criterion at § 170.315(d)(9) is required as part of the privacy & security approach for the certification criteria at § 170.315(e)(1), (e)(2), (e)(3), (g)(7), (g)(8), and (g)(9). This certification criterion at § 170.315(d)(9) must be explicitly demonstrated with § 170.315(e)(1) and (e)(2) because of the specific capabilities for secure electronic transmission and secure electronic messaging included in each of these two criteria, respectively. For the other certification criteria (§ 170.315(e)(3), (g)(7), (g)(8), and (g)(9)), this criterion at § 170.315(d)(9) only needs to be demonstrated once as part of the overall scope of the certificate sought.
- Revision History
-
Version # Description of Change Version Date 1.0 Initial publication
03-11-2024
Testing components
Attestation: As of September 21, 2017, the testing approach for this criterion is satisfied by attestation.
The archived version of the Test Procedure is attached below for reference.
System Under Test | ONC-ACB Verification |
|---|---|
The health IT developer will attest directly to the ONC-ACB to conformance with the § 170.315(d)(9) Trusted connection requirements. | The ONC-ACB verifies the health IT developer attests conformance to the § 170.315(d)(9) Trusted connection requirements. |
§ 170.315 (d)(9) Trusted connection—
Establish a trusted connection using one of the following methods:
- Message-level. Encrypt and integrity protect message contents in accordance with the standards specified in § 170.210(a)(2) and (c)(2).
- Transport-level. Use a trusted connection in accordance with the standards specified in § 170.210(a)(2) and (c)(2).
Applies to entire criterion
§ 170.210(a)(2) General. Any encryption algorithm identified by the National Institute of Standards and Technology (NIST) as an approved security function in Annex A of the Federal Information Processing Standards (FIPS) Publication 140-2, Security Requirements for Cryptographic Modules, October 8, 2014
§ 170.210(c)(2) A hashing algorithm with a security strength equal to or greater than SHA-2 as specified by NIST in FIPS Publication 180-4, Secure Hash Standard, 180-4 (August 2015)
Design and performance: Quality management system (§ 170.315(g)(4)) and accessibility-centered design (§ 170.315(g)(5)) must be certified as part of the overall scope of the certificate issued to the product.
- Quality management system (§ 170.315(g)(4)): 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.
- Accessibility-centered design (§ 170.315(g)(5)): 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.
This certification criterion at § 170.315(d)(9) is required as part of the privacy & security approach for the certification criteria at § 170.315(e)(1), (e)(2), (e)(3), (g)(7), (g)(8), and (g)(9). This certification criterion at § 170.315(d)(9) must be explicitly demonstrated with § 170.315(e)(1) and (e)(2) because of the specific capabilities for secure electronic transmission and secure electronic messaging included in each of these two criteria, respectively. For the other certification criteria (§ 170.315(e)(3), (g)(7), (g)(8), and (g)(9)), this criterion at § 170.315(d)(9) only needs to be demonstrated once as part of the overall scope of the certificate sought.
| Version # | Description of Change | Version Date |
|---|---|---|
| 1.0 |
Initial publication |
03-11-2024
|
- Regulation Text
-
Regulation Text
§ 170.315 (d)(9) Trusted connection—
Establish a trusted connection using one of the following methods:
- Message-level. Encrypt and integrity protect message contents in accordance with the standards specified in § 170.210(a)(2) and (c)(2).
- Transport-level. Use a trusted connection in accordance with the standards specified in § 170.210(a)(2) and (c)(2).
- Standard(s) Referenced
-
Applies to entire criterion
§ 170.210(a)(2) General. Any encryption algorithm identified by the National Institute of Standards and Technology (NIST) as an approved security function in Annex A of the Federal Information Processing Standards (FIPS) Publication 140-2, Security Requirements for Cryptographic Modules, October 8, 2014
§ 170.210(c)(2) A hashing algorithm with a security strength equal to or greater than SHA-2 as specified by NIST in FIPS Publication 180-4, Secure Hash Standard, 180-4 (August 2015)
- Certification Dependencies
-
Design and performance: Quality management system (§ 170.315(g)(4)) and accessibility-centered design (§ 170.315(g)(5)) must be certified as part of the overall scope of the certificate issued to the product.
- Quality management system (§ 170.315(g)(4)): 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.
- Accessibility-centered design (§ 170.315(g)(5)): 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 & Security Requirements
-
This certification criterion at § 170.315(d)(9) is required as part of the privacy & security approach for the certification criteria at § 170.315(e)(1), (e)(2), (e)(3), (g)(7), (g)(8), and (g)(9). This certification criterion at § 170.315(d)(9) must be explicitly demonstrated with § 170.315(e)(1) and (e)(2) because of the specific capabilities for secure electronic transmission and secure electronic messaging included in each of these two criteria, respectively. For the other certification criteria (§ 170.315(e)(3), (g)(7), (g)(8), and (g)(9)), this criterion at § 170.315(d)(9) only needs to be demonstrated once as part of the overall scope of the certificate sought.
- Revision History
-
Version # Description of Change Version Date 1.0 Initial publication
03-11-2024
Certification Companion Guide: Trusted connection
This Certification Companion Guide (CCG) is an informative document designed to assist with health IT product certification. The CCG is not a substitute for the requirements outlined in regulation and related ONC final rules. It extracts key portions of ONC final rules’ preambles and includes subsequent clarifying interpretations. To access the full context of regulatory intent please consult the Certification Regulations page for links to all ONC final rules or consult other regulatory references as noted. The CCG is for public use and should not be sold or redistributed.
The below table outlines whether this criterion has additional Maintenance of Certification dependencies, update requirements and/or eligibility for standards updates via SVAP. Review the Certification Dependencies and Required Update Deadline drop-downs above if this table indicates “yes” for any field.
| Base EHR Definition | Real World Testing | Insights Condition | SVAP | Requires Updates |
|---|---|---|---|---|
| Not Included | No | No | No | No |
Applies to entire criterion
Clarifications:
- Health IT needs to provide a level of trusted connection using either 1) encrypted and integrity message protection or 2) a trusted connection for transport. Either of these methods must be demonstrated in accordance with the following standards: Annex A: FIPS Publication 140-2, Security Requirements for Cryptographic Modules and FIPS PUB 180-4, Secure Hash Standard, 180-4.
- A “trusted connection” means the link is encrypted/integrity protected according to § 170.210(a)(2) or (c)(2). As such, ONC does not believe it is necessary to specifically name HTTPS and/or SSL/TLS as this standard already covers encryption and integrity protection for data in motion. [see also 80 FR 62676]
|
Clarifications:
|
Paragraph (d)(9)(i) Message-level
Technical outcome – The health IT offers a user encrypted and integrity message protection.
Clarifications
- No additional clarifications.
|
Technical outcome – The health IT offers a user encrypted and integrity message protection. Clarifications
|
Paragraph (d)(9)(ii) Transport-level
Technical outcome – The health IT provides the user a trusted connection for transport.
Clarifications
- The tester is required to view the encryption handshake to ensure that the digital certificates, where used, are being invoked during the connection. Developers have freedom to demonstrate the encryption handshake based on the technology they are using. For example, if a developer has a browser-based module that uses HTTPS, the developer could demonstrate the "lock" icon in the browser that indicates that HTTPS is present and working properly.
- The verification step is verifying that the transport is conducted using a trusted connection configured to conform to the required level of encryption and hashing standard. The communication content is not examined, only the configuration and the handshake, and where used, the digital certificates. The messages are not examined as with alternative 1. The lab does not need to verify the messages, only the trusted connection.
|
Technical outcome – The health IT provides the user a trusted connection for transport. Clarifications
|