§170.315(g)(32) Provider prior authorization API - documentation templates and rules
§ 170.315(g)(32) Provider prior authorization API – documentation templates and rules
Support the capability for users to request and populate prior authorization documentation using templates and rules as a “Full DTR EHR” according to at least one of the versions of the implementation specification adopted in § 170.215(j)(2), including:
- Registration. Support registration capabilities applicable to a “Full DTR EHR.”
- Authentication and authorization. Support system authentication and authorization as a client in accordance with the “Backend Services” section of at least one of the versions of the implementation specification adopted in § 170.215(c).
- Full DTR EHR capabilities. Support all requirements and required capabilities applicable to a “Full DTR EHR.”
Entire criterion
§ 170.215(j)(2)(i) HL7 FHIR® Da Vinci—Documentation Templates and Rules (DTR) Implementation Guide: Version 2.0.1—STU 2
Paragraph (g)(32)(ii)
§ 170.215(c)(1) HL7 FHIR® SMART Application Launch Framework Implementation Guide Release 1.0.0
§ 170.215(c)(2) HL7 FHIR® IG: SMART Application Launch Framework, v2.0.0
Conditions and Maintenance of Certification
API: The API Condition and Maintenance of Certification requirements at 45 CFR 170.404 apply to developers of Health IT Modules certified to 45 CFR 170.315(g)(32).
Real World Testing: Products certified to this criterion must complete requirements outlined for the Real World Testing Conditions and Maintenance of Certification.
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.
- 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.
| Version # | Description of Change | Version Date |
|---|---|---|
| 1.0 |
Initial publication |
10-01-2025
|
- Regulation Text
-
Regulation Text
§ 170.315(g)(32) Provider prior authorization API – documentation templates and rules
Support the capability for users to request and populate prior authorization documentation using templates and rules as a “Full DTR EHR” according to at least one of the versions of the implementation specification adopted in § 170.215(j)(2), including:
- Registration. Support registration capabilities applicable to a “Full DTR EHR.”
- Authentication and authorization. Support system authentication and authorization as a client in accordance with the “Backend Services” section of at least one of the versions of the implementation specification adopted in § 170.215(c).
- Full DTR EHR capabilities. Support all requirements and required capabilities applicable to a “Full DTR EHR.”
- Standard(s) Referenced
-
Entire criterion
§ 170.215(j)(2)(i) HL7 FHIR® Da Vinci—Documentation Templates and Rules (DTR) Implementation Guide: Version 2.0.1—STU 2
Paragraph (g)(32)(ii)
§ 170.215(c)(1) HL7 FHIR® SMART Application Launch Framework Implementation Guide Release 1.0.0
§ 170.215(c)(2) HL7 FHIR® IG: SMART Application Launch Framework, v2.0.0
- Certification Dependencies
-
Conditions and Maintenance of Certification
API: The API Condition and Maintenance of Certification requirements at 45 CFR 170.404 apply to developers of Health IT Modules certified to 45 CFR 170.315(g)(32).
Real World Testing: Products certified to this criterion must complete requirements outlined for the Real World Testing Conditions and Maintenance of Certification.
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.
- 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.
- Testing
-
Testing Tool
Inferno Framework (A link will be provided once the testing tool is available.)
Test Tool Documentation (A link will be provided once the testing tool is available.)
- Revision History
-
Version # Description of Change Version Date 1.0 Initial publication
10-01-2025
This Test Procedure illustrates the test steps required to certify a Health IT Module to this criterion. Please consult the most recent ASTP/ONC Final Rule on the Certification Regulations pagefor a detailed description of the certification criterion with which these testing steps are associated. ASTP/ONC also encourages developers to consult the Certification Companion Guide in tandem with the test procedure as it provides clarifications that may be useful for product development and testing.
Note: The tests step order does not necessarily prescribe the order in which the tests should take place.
Testing components
Paragraph (g)(32)
The health IT developer demonstrates the Health IT Module supports the following capabilities as a “Full DTR EHR” in accordance with an implementation specification at § 170.215(j)(2):
- DTR-1: Registration with a “DTR Payer Service” to enable the required client capabilities with the “DTR Payer Service” including authentication, authorization, and FHIR operations as described in the “Full DTR EHR Capability Statement.”
- DTR-2: Authentication and authorization as a client with a “DTR Payer Service” using “Backend Services” in accordance with an implementation specification at § 170.215(c).
- DTR-3: Population of “Standard Questionnaires” received from a “DTR Payer Service” including support for the “$questionnaire-package” operation.
- DTR-4: Population of “Adaptive Questionnaires” received from a “DTR Payer Service” including support for the ”$questionnaire-package” and “$next-question” operations.
- DTR-5: Value set expansion for questionnaires in accordance with the “$expand” operation.
- DTR-6: Execution of Clinical Quality Language (CQL) to support pre-population of questionnaires.
- DTR-7: Display of pre-populated questionnaires to the user for review and completion.
- DTR-8: Storage of completed questionnaires in the Health IT Module.
The tester verifies the Health IT Module supports the following capabilities as a “Full DTR EHR” in accordance with an implementation specification at § 170.215(j)(2):
- DTR-1: Registration with a “DTR Payer Service” to enable the required client capabilities with the “DTR Payer Service” including authentication, authorization, and FHIR operations as described in the “Full DTR EHR Capability Statement.”
- DTR-2: Authentication and authorization as a client with a “DTR Payer Service” using “Backend Services” in accordance with an implementation specification at § 170.215(c).
- DTR-3: Population of “Standard Questionnaires” received from a “DTR Payer Service” including support for the “$questionnaire-package” operation.
- DTR-4: Population of “Adaptive Questionnaires” received from a “DTR Payer Service” including support for the ”$questionnaire-package” and “$next-question” operations.
- DTR-5: Value set expansion for questionnaires in accordance with the “$expand” operation.
- DTR-6: Execution of Clinical Quality Language (CQL) to support pre-population of questionnaires.
- DTR-7: Display of pre-populated questionnaires to the user for review and completion.
- DTR-8: Storage of completed questionnaires in the Health IT Module.
| System Under Test | Test Lab Verification |
|---|---|
|
The health IT developer demonstrates the Health IT Module supports the following capabilities as a “Full DTR EHR” in accordance with an implementation specification at § 170.215(j)(2):
|
The tester verifies the Health IT Module supports the following capabilities as a “Full DTR EHR” in accordance with an implementation specification at § 170.215(j)(2):
|
§ 170.315(g)(32) Provider prior authorization API – documentation templates and rules
Support the capability for users to request and populate prior authorization documentation using templates and rules as a “Full DTR EHR” according to at least one of the versions of the implementation specification adopted in § 170.215(j)(2), including:
- Registration. Support registration capabilities applicable to a “Full DTR EHR.”
- Authentication and authorization. Support system authentication and authorization as a client in accordance with the “Backend Services” section of at least one of the versions of the implementation specification adopted in § 170.215(c).
- Full DTR EHR capabilities. Support all requirements and required capabilities applicable to a “Full DTR EHR.”
Entire criterion
§ 170.215(j)(2)(i) HL7 FHIR® Da Vinci—Documentation Templates and Rules (DTR) Implementation Guide: Version 2.0.1—STU 2
Paragraph (g)(32)(ii)
§ 170.215(c)(1) HL7 FHIR® SMART Application Launch Framework Implementation Guide Release 1.0.0
§ 170.215(c)(2) HL7 FHIR® IG: SMART Application Launch Framework, v2.0.0
Conditions and Maintenance of Certification
API: The API Condition and Maintenance of Certification requirements at 45 CFR 170.404 apply to developers of Health IT Modules certified to 45 CFR 170.315(g)(32).
Real World Testing: Products certified to this criterion must complete requirements outlined for the Real World Testing Conditions and Maintenance of Certification.
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.
- 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.
| Version # | Description of Change | Version Date |
|---|---|---|
| 1.0 |
Initial publication |
10-01-2025
|
- Regulation Text
-
Regulation Text
§ 170.315(g)(32) Provider prior authorization API – documentation templates and rules
Support the capability for users to request and populate prior authorization documentation using templates and rules as a “Full DTR EHR” according to at least one of the versions of the implementation specification adopted in § 170.215(j)(2), including:
- Registration. Support registration capabilities applicable to a “Full DTR EHR.”
- Authentication and authorization. Support system authentication and authorization as a client in accordance with the “Backend Services” section of at least one of the versions of the implementation specification adopted in § 170.215(c).
- Full DTR EHR capabilities. Support all requirements and required capabilities applicable to a “Full DTR EHR.”
- Standard(s) Referenced
-
Entire criterion
§ 170.215(j)(2)(i) HL7 FHIR® Da Vinci—Documentation Templates and Rules (DTR) Implementation Guide: Version 2.0.1—STU 2
Paragraph (g)(32)(ii)
§ 170.215(c)(1) HL7 FHIR® SMART Application Launch Framework Implementation Guide Release 1.0.0
§ 170.215(c)(2) HL7 FHIR® IG: SMART Application Launch Framework, v2.0.0
- Certification Dependencies
-
Conditions and Maintenance of Certification
API: The API Condition and Maintenance of Certification requirements at 45 CFR 170.404 apply to developers of Health IT Modules certified to 45 CFR 170.315(g)(32).
Real World Testing: Products certified to this criterion must complete requirements outlined for the Real World Testing Conditions and Maintenance of Certification.
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.
- 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.
- Revision History
-
Version # Description of Change Version Date 1.0 Initial publication
09-30-2025 - Testing
-
Testing Tool
Inferno Framework (A link will be provided once the testing tool is available.)
Test Tool Documentation (A link will be provided once the testing tool is available.)
Certification Companion Guide: Provider prior authorization API - documentation templates and rules
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 ASTP/ONC final rules. It extracts key portions of ASTP/ONC final rules’ preambles and includes subsequent clarifying interpretations. To access the full context of regulatory intent please consult the Certification Program Regulations page for links to all 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 | Yes | No | No | No |
Applies to entire criterion
Clarifications:
- All conformance requirements (e.g., “SHALL” or “Must Support” requirements) expressed by referenced standards and implementation guides are required to be supported for the purposes of certification unless otherwise specified.
|
Clarifications:
|
Paragraph (g)(32)(i) Registration
Technical outcome – The Health IT Module supports registration capabilities applicable to a “Full DTR EHR” as described in the HL7 FHIR® Da Vinci—Documentation Templates and Rules (DTR) Implementation Guide (IG).
Clarifications:
- Registration requirements for a “Full DTR EHR” are specified in the DTR IG. See section “Configuring App/EHR to Payer Connectivity” in the DTR IG for additional details about registration requirements for a “Full DTR EHR.” (see also 90 FR 37173)
|
Technical outcome – The Health IT Module supports registration capabilities applicable to a “Full DTR EHR” as described in the HL7 FHIR® Da Vinci—Documentation Templates and Rules (DTR) Implementation Guide (IG). Clarifications:
|
Paragraph (g)(32)(ii) Authentication and authorization
Technical outcome – The Health IT Module supports system authentication and authorization as a client in accordance with the “Backend Services” section of the HL7 FHIR® SMART Application Launch Implementation Guide.
Clarifications:
- No additional clarifications.
|
Technical outcome – The Health IT Module supports system authentication and authorization as a client in accordance with the “Backend Services” section of the HL7 FHIR® SMART Application Launch Implementation Guide. Clarifications:
|
Paragraph (g)(32)(iii) Full DTR EHR capabilities
Technical outcome – The Health IT Module supports all requirements and required capabilities applicable to a “Full DTR EHR” outlined in the HL7 FHIR® Da Vinci—Documentation Templates and Rules (DTR) Implementation Guide.
Clarifications:
- Support for all requirements and required capabilities applicable to a “Full DTR EHR” includes support for the capabilities required by the “Full DTR EHR” CapabilityStatement artifact. (see also 90 FR 37172)
|
Technical outcome – The Health IT Module supports all requirements and required capabilities applicable to a “Full DTR EHR” outlined in the HL7 FHIR® Da Vinci—Documentation Templates and Rules (DTR) Implementation Guide. Clarifications:
|