§170.315(e)(2) Secure messaging
§ 170.315 (e)(2) Secure messaging—
Enable a user to send messages to, and receive messages from, a patient in a secure manner.
Please refer to the standards required for the 2015 Edition Trusted connection certification criterion.
| Version # | Description of Change | Version Date |
|---|---|---|
| 1.0 |
Final Test Procedure |
01-20-2016
|
| 1.1 |
As of September 21, 2017, Test Procedure has been moved to Attestation/Developer self-declaration only. |
09-21-2017
|
| 1.2 |
Changed language from self-declaration to attestation. |
10-12-2021
|
- Regulation Text
-
Regulation Text
§ 170.315 (e)(2) Secure messaging—
Enable a user to send messages to, and receive messages from, a patient in a secure manner.
- Standard(s) Referenced
-
Please refer to the standards required for the 2015 Edition Trusted connection certification criterion.
- Revision History
-
Version # Description of Change Version Date 1.0 Final Test Procedure
01-20-20161.1 As of September 21, 2017, Test Procedure has been moved to Attestation/Developer self-declaration only.
09-21-20171.2 Changed language from self-declaration to attestation.
10-12-2021
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 (e)(2) Secure messaging requirements. |
The ONC-ACB verifies the health IT developer attests conformance to the §170.315 (e)(2) Secure messaging requirements. |
§ 170.315 (e)(2) Secure messaging—
Enable a user to send messages to, and receive messages from, a patient in a secure manner.
Please refer to the standards required for the 2015 Edition Trusted connection certification criterion.
| Version # | Description of Change | Version Date |
|---|---|---|
| 1.0 |
Final Test Procedure |
01-20-2016
|
| 1.1 |
As of September 21, 2017, Test Procedure has been moved to Attestation/Developer self-declaration only. |
09-21-2017
|
| 1.2 |
Changed language from self-declaration to attestation. |
10-12-2021
|
- Regulation Text
-
Regulation Text
§ 170.315 (e)(2) Secure messaging—
Enable a user to send messages to, and receive messages from, a patient in a secure manner.
- Standard(s) Referenced
-
Please refer to the standards required for the 2015 Edition Trusted connection certification criterion.
- Revision History
-
Version # Description of Change Version Date 1.0 Initial Publication
10-22-20151.1 Revised to indicate this certification criterion is in scope for the Certified EHR Definition.
01-05-20161.2 Added clarification for time-limited certification to this criterion per the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program Final Rule.
06-15-20201.3 Corrected information in the Privacy & Security section.
08-03-2020
Certification Companion Guide: Secure messaging
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 |
|---|---|
| Not Included | Yes |
Privacy and Security: This certification criterion was adopted at § 170.315(e)(2). As a result, an ONC Authorized Certification Body (ONC-ACB) must ensure that a product presented for certification to a § 170.315(e) 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 (e) 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 presented 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.
- If choosing Approach 1:
- Authentication, access control, and authorization (§ 170.315(d)(1))
- Auditable events and tamper-resistance (§ 170.315(d)(2))
- Audit reports (§ 170.315(d)(3))
- Automatic access time-out (§ 170.315(d)(5))
- Trusted Connection (§ 170.315(d)(9)) must be explicitly demonstrated with this criterion.
- Encrypt authentication credentials (§ 170.315(d)(12))
- Multi-factor authentication (§ 170.315(d)(13))
- If choosing Approach 2:
- For each applicable privacy and security certification criterion not certified for approach 1, the health IT developer may certify for the criterion (with the exception of (§ 170.315(d)(9)) using system documentation which provides a clear description of how the external services necessary to meet the privacy and security criteria would be deployed and used. 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(e)(2). As a result, an ONC Authorized Certification Body (ONC-ACB) must ensure that a product presented for certification to a § 170.315(e) 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 (e) 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 presented 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.
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:
- Authentication, access control, and authorization (§ 170.315(d)(1))
- Auditable events and tamper-resistance (§ 170.315(d)(2))
- Audit reports (§ 170.315(d)(3))
- Automatic access time-out (§ 170.315(d)(5))
- Trusted Connection (§ 170.315(d)(9)) must be explicitly demonstrated with this criterion.
- Encrypt authentication credentials (§ 170.315(d)(12))
- Multi-factor authentication (§ 170.315(d)(13))
- If choosing Approach 2:
- For each applicable privacy and security certification criterion not certified for approach 1, the health IT developer may certify for the criterion (with the exception of (§ 170.315(d)(9)) using system documentation which provides a clear description of how the external services necessary to meet the privacy and security criteria would be deployed and used. Please see the ONC Cures Act Final Rule at 85 FR 25710 for additional clarification.
Applies to entire criterion
Technical outcome – A user can send messages to and receive messages from a patient in a secure manner.
Clarifications:
- There is no standard required for this certification criterion.
- A Health IT Module presented for certification to this criterion must be separately tested to the privacy and security criterion for “trusted connection” at § 170.315(d)(9). [see also 80 FR 62707]
- A health IT developer can choose between message-level or transport-level “trusted connection” certification in accordance with § 170.315(d)(9). [see also 80 FR 62661]
- The encryption requirements of this certification criterion only apply to the message content and not to the patient’s device(s). [see also 80 FR 62661]
- This criterion is not eligible for gap certification as the new hashing standard (a hashing algorithm with a security strength equal to or greater than SHA-2) applies to this criterion per the standard required at § 170.210(c)(2). [see also 80 FR 62661]
- Secure email, a secure portal, or even some type of mobile application could all be examples for secure messaging methods that could potentially meet this certification criterion. [see also 77 FR 54193]
- ONC-ATLs will test that the health IT has the capability as a whole to send and receive secure messages for certification in order for providers to have assurance that health IT can enable bidirectional communication. [see also 77 FR 54194]
- As noted in Annex A: FIPS 140-2, only encryption and hashing algorithms are in scope for this certification criterion. Random number generator standards are not in scope. [see also 77 FR 54194]
- ONC-ACBs will be permitted to issue certificates for this criterion up until January 1, 2022 to align with the requirements of the CMS Medicaid Promoting Interoperability Program. [see also 84 FR 42592] ONC has included a provision in § 170.550(m)(1) to only allow ONC-ACBs to issue certificates for this criterion until January 1, 2022. Limiting certificates to this criterion for this period will help spur further innovations in patient engagement while helping to reduce regulatory burdens and costs for health IT developers and healthcare providers. Other 2015 Edition criteria better support interoperability and innovation in patient engagement. [see also 80 FR 25622]
|
Technical outcome – A user can send messages to and receive messages from a patient in a secure manner. Clarifications:
|