§170.315(a)(3) Computerized provider order entry (CPOE) – diagnostic imaging
| Version # | Description of Change | Version Date |
|---|---|---|
| 1.0 |
Final Test Procedure |
01-08-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 |
08-25-2021
|
§ 170.315 (a)(3) Computerized provider order entry—diagnostic imaging—
- Enable a user to record, change, and access diagnostic imaging orders.
- Optional. Include a “reason for order” field.
None
- Resource Documents
- Revision History
-
Version # Description of Change Version Date 1.0 Final Test Procedure
01-08-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
08-25-2021 - Regulation Text
-
Regulation Text
§ 170.315 (a)(3) Computerized provider order entry—diagnostic imaging—
- Enable a user to record, change, and access diagnostic imaging orders.
- Optional. Include a “reason for order” field.
- Standard(s) Referenced
-
None
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 to the §170.315(a)(3) Computerized provider order entry (CPOE) – diagnostic imaging requirements. |
The ONC-ACB verifies the health IT developer attests conformance to the §170.315(a)(3) Computerized provider order entry (CPOE) – diagnostic imaging requirements. |
| Version # | Description of Change | Version Date |
|---|---|---|
| 1.0 |
Initial Publication |
10-22-2015
|
| 1.1 |
Updated the Security requirements per 21st Century Cures Act. |
06-15-2020
|
§ 170.315 (a)(3) Computerized provider order entry—diagnostic imaging—
- Enable a user to record, change, and access diagnostic imaging orders.
- Optional. Include a “reason for order” field.
None
- Resource Documents
- Revision History
-
Version # Description of Change Version Date 1.0 Initial Publication
10-22-20151.1 Updated the Security requirements per 21st Century Cures Act.
06-15-2020 - Regulation Text
-
Regulation Text
§ 170.315 (a)(3) Computerized provider order entry—diagnostic imaging—
- Enable a user to record, change, and access diagnostic imaging orders.
- Optional. Include a “reason for order” field.
- Standard(s) Referenced
-
None
Certification Companion Guide: Computerized provider order entry (CPOE) – diagnostic imaging
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 | No |
Privacy and Security: This certification criterion was adopted at § 170.315(a)(3). As a result, an ONC Authorized Certification Body (ONC-ACB) must ensure that a product presented for certification to a § 170.315(a) 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 (a) 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.
- § 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:
- Authentication, access control, and authorization (§ 170.315(d)(1))
- Auditable events and tamper-resistance (§ 170.315(d)(2))
- Audit reports (§ 170.315(d)(3))
- Amendments (§ 170.315(d)(4))
- Automatic access time-out (§ 170.315(d)(5))
- Emergency access (§ 170.315(d)(6))
- End-user device encryption (§ 170.315(d)(7))
- Encrypt authentication credentials (§ 170.315(d)(12))
- Multi-factor authentication (MFA) (§ 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 using system documentation which is sufficiently detailed to enable integration such that the Health IT Module has implemented service interfaces the Health IT Module to access external services necessary to meet the requirements of the privacy and security certification criterion. Please see the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program 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.
- Safety-enhanced design (§ 170.315(g)(3)) must be explicitly demonstrated for this criterion.
- 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(a)(3). As a result, an ONC Authorized Certification Body (ONC-ACB) must ensure that a product presented for certification to a § 170.315(a) 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 (a) 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.
- § 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.
- Safety-enhanced design (§ 170.315(g)(3)) must be explicitly demonstrated for this criterion.
- 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))
- Amendments (§ 170.315(d)(4))
- Automatic access time-out (§ 170.315(d)(5))
- Emergency access (§ 170.315(d)(6))
- End-user device encryption (§ 170.315(d)(7))
- Encrypt authentication credentials (§ 170.315(d)(12))
- Multi-factor authentication (MFA) (§ 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 using system documentation which is sufficiently detailed to enable integration such that the Health IT Module has implemented service interfaces the Health IT Module to access external services necessary to meet the requirements of the privacy and security certification criterion. Please see the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program Final Rule at 85 FR 25710 for additional clarification.
Applies to entire criterion
Clarifications:
- There is no standard required for this certification criterion.
- To meet the 2015 Edition Base electronic health record (EHR) definition, providers must possess technology that has been certified to at least one of the following: § 170.315(a)(1) Computerized provider order entry (CPOE) – medications, § 170.315(a)(2) Computerized provider order entry (CPOE) – laboratory, or § 170.315(a)(3) Computerized provider order entry (CPOE) – diagnostic imaging.
Applies to entire criterion
|
Clarifications:
|
Paragraph (a)(3)(i)
Technical outcome – The health IT permits a user to record, change, and access diagnostic imaging orders.
Clarifications:
- No standard is required for demonstrating the ability to allow a user to record, change, and access diagnostic imaging orders.
- This provision does not focus on the transmission of diagnostic imaging orders, only on the ability of a user to record, change, and access the diagnostic imaging order. [see also 77 FR 54248]
Paragraph (a)(3)(i)
|
Technical outcome – The health IT permits a user to record, change, and access diagnostic imaging orders. Clarifications:
|
Paragraph (a)(3)(ii) Optional
Technical outcome – The health IT allows for the user to include a “reason for order.”
Clarifications:
- It is not mandatory that the health IT allow a user to include a “reason for order” field. However, it is optional. The developer has the discretion to determine how to implement this optional provision (e.g., free text field or drop-down menu of pre-determined entries).
Paragraph (a)(3)(ii) Optional
|
Technical outcome – The health IT allows for the user to include a “reason for order.” Clarifications:
|