§170.315(g)(31) Provider prior authorization API - coverage requirements discovery
§ 170.315(g)(31) Provider prior authorization API – coverage requirements discovery.
Support the following capabilities to enable users to request and receive coverage requirements.
- Coverage discovery. Support the capability to initiate and exchange information as a “CRD Client” to enable the identification of coverage requirements according to at least one of the implementation specifications in § 170.215(j)(1), including the following:
- Registration. Support registration capabilities applicable to “CRD Clients”.
- CDS Hooks support. Support the capabilities in paragraph (j)(20) of this section to enable workflow triggers to call decision support services including support for the “order-sign” CDS Hook.
- CRD Client capabilities. Support all requirements and required capabilities applicable to a “CRD Client”.
- Documentation. Supported API server capabilities of “CRD Clients” from an implementation specification adopted in § 170.215(j)(1) must include complete accompanying technical documentation.
Paragraph (g)(31)(i)
§ 170.215(j)(1)(i) HL7 FHIR® Da Vinci—Coverage Requirements Discovery (CRD) Implementation Guide: Version 2.0.1 – STU 2
See standards referenced at § 170.315(j)(20)
Paragraph (g)(31)(ii)
§ 170.215(j)(1)(i) HL7 FHIR® Da Vinci—Coverage Requirements Discovery (CRD) Implementation Guide: Version 2.0.1 – STU 2
Dependent Criteria
Products presented for certification to the “Provider prior authorization API—coverage requirements discovery” certification criterion in 45 CFR 170.315(g)(31) will demonstrate conformance with and be certified to the “Workflow triggers for decision support interventions—clients” criterion in 45 CFR 170.315(j)(20) as part of certification to 45 CFR 170.315(g)(31).
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)(31).
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)(31) Provider prior authorization API – coverage requirements discovery.
Support the following capabilities to enable users to request and receive coverage requirements.
- Coverage discovery. Support the capability to initiate and exchange information as a “CRD Client” to enable the identification of coverage requirements according to at least one of the implementation specifications in § 170.215(j)(1), including the following:
- Registration. Support registration capabilities applicable to “CRD Clients”.
- CDS Hooks support. Support the capabilities in paragraph (j)(20) of this section to enable workflow triggers to call decision support services including support for the “order-sign” CDS Hook.
- CRD Client capabilities. Support all requirements and required capabilities applicable to a “CRD Client”.
- Documentation. Supported API server capabilities of “CRD Clients” from an implementation specification adopted in § 170.215(j)(1) must include complete accompanying technical documentation.
- Coverage discovery. Support the capability to initiate and exchange information as a “CRD Client” to enable the identification of coverage requirements according to at least one of the implementation specifications in § 170.215(j)(1), including the following:
- Standard(s) Referenced
-
Paragraph (g)(31)(i)
§ 170.215(j)(1)(i) HL7 FHIR® Da Vinci—Coverage Requirements Discovery (CRD) Implementation Guide: Version 2.0.1 – STU 2
See standards referenced at § 170.315(j)(20)
Paragraph (g)(31)(ii)
§ 170.215(j)(1)(i) HL7 FHIR® Da Vinci—Coverage Requirements Discovery (CRD) Implementation Guide: Version 2.0.1 – STU 2
- Certification Dependencies
-
Dependent Criteria
Products presented for certification to the “Provider prior authorization API—coverage requirements discovery” certification criterion in 45 CFR 170.315(g)(31) will demonstrate conformance with and be certified to the “Workflow triggers for decision support interventions—clients” criterion in 45 CFR 170.315(j)(20) as part of certification to 45 CFR 170.315(g)(31).
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)(31).
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)(31)(i) Coverage discovery
The health IT developer demonstrates the Health IT Module supports the following capabilities as a “CRD Client” in accordance with an implementation specification at § 170.215(j)(1) and the criterion requirements at § 170.315(j)(20):
- CRD-1: Registration with a “CRD Server” including all configuration necessary to enable required CDS Hooks.
- CRD-2: Discovery of supported capabilities by a “CRD Server” using a “CRD Client Capability Statement.”
- CRD-3: The “order-sign” CDS Hook, including support for receiving and processing “Coverage Information” system actions from a “CRD Server”.
- CRD-4: Triggering required CDS Hooks at the appropriate points in a clinical workflow.
- CRD-5: Authentication as a client with a “CRD Server” using JSON web tokens (JWT).
- CRD-6: Authorization of a “CRD Server” to have FHIR Resource access to enable required CDS Hooks, including provisioning an access token.
- CRD-7: FHIR resource access to enable required CDS Hooks, including “read” and “search” support for FHIR resources as profiled for required CDS Hooks.
- CRD-8: Processing of “Coverage Information” system actions received from a “CRD Server” including updating applicable FHIR resources in the Health IT Module. This may also include display of relevant decision support to a user.
The tester verifies the Health IT Module supports the following capabilities as a “CRD Client” in accordance with an implementation specification at § 170.215(j)(1) and the criterion requirements at § 170.315(j)(20):
- CRD-1: Registration with a “CRD Server” including all configuration necessary to enable required CDS Hooks.
- CRD-2: Discovery of supported capabilities by a “CRD Server” using a “CRD Client Capability Statement.”
- CRD-3: The “order-sign” CDS Hook, including support for receiving and processing “Coverage Information” system actions from a “CRD Server”.
- CRD-4: Triggering required CDS Hooks at the appropriate points in a clinical workflow.
- CRD-5: Authentication as a client with a “CRD Server” using JSON web tokens (JWT).
- CRD-6: Authorization of a “CRD Server” to have FHIR Resource access to enable required CDS Hooks, including provisioning an access token.
- CRD-7: FHIR resource access to enable required CDS Hooks, including “read” and “search” support for FHIR resources as profiled for required CDS Hooks.
- CRD-8: Processing of “Coverage Information” system actions received from a “CRD Server” including updating applicable FHIR resources in the Health IT Module. This may also include display of relevant decision support to a user.
| System Under Test |
Test Lab Verification
|
|---|---|
|
The health IT developer demonstrates the Health IT Module supports the following capabilities as a “CRD Client” in accordance with an implementation specification at § 170.215(j)(1) and the criterion requirements at § 170.315(j)(20):
|
The tester verifies the Health IT Module supports the following capabilities as a “CRD Client” in accordance with an implementation specification at § 170.215(j)(1) and the criterion requirements at § 170.315(j)(20):
|
Paragraph (g)(31)(ii) Documentation
- API-DOC-1: The health IT developer supplies complete accompanying technical documentation for supported API server capabilities of “CRD Clients” from an implementation specification adopted in § 170.215(j)(1). Such documentation should include as applicable:
- API syntax;
- Function names;
- Required and optional parameters supported and their data types;
- Return variables and their types/structures;
- Exceptions and exception handling methods and their returns;
- Mandatory software components;
- Mandatory software configurations; and
- All technical requirements and attributes necessary for registration.
- API-DOC-2: The health IT developer demonstrates that the documentation described in step API-DOC-1 is available via a publicly accessible hyperlink that does not require preconditions nor additional steps to access.
- API-DOC-1: The tester verifies the documentation supplied by the health IT developer completely describes the supported API server capabilities of “CRD Clients” from an implementation specification adopted in § 170.215(j)(1) and includes the following as applicable:
- API syntax;
- Function names;
- Required and optional parameters supported and their data types;
- Return variables and their types/structures;
- Exceptions and exception handling methods and their returns;
- Mandatory software components;
- Mandatory software configurations; and
- All technical requirements and attributes necessary for registration.
- API-DOC-2: The tester verifies the documentation described in step API-DOC-1 is available via a publicly accessible hyperlink that does not require preconditions nor additional steps to access.
| System Under Test | Test Lab Verification |
|---|---|
|
|
§ 170.315(g)(31) Provider prior authorization API – coverage requirements discovery.
Support the following capabilities to enable users to request and receive coverage requirements.
- Coverage discovery. Support the capability to initiate and exchange information as a “CRD Client” to enable the identification of coverage requirements according to at least one of the implementation specifications in § 170.215(j)(1), including the following:
- Registration. Support registration capabilities applicable to “CRD Clients”.
- CDS Hooks support. Support the capabilities in paragraph (j)(20) of this section to enable workflow triggers to call decision support services including support for the “order-sign” CDS Hook.
- CRD Client capabilities. Support all requirements and required capabilities applicable to a “CRD Client”.
- Documentation. Supported API server capabilities of “CRD Clients” from an implementation specification adopted in § 170.215(j)(1) must include complete accompanying technical documentation.
Paragraph (g)(31)(i)
§ 170.215(j)(1)(i) HL7 FHIR® Da Vinci—Coverage Requirements Discovery (CRD) Implementation Guide: Version 2.0.1 – STU 2
See standards referenced at § 170.315(j)(20)
Paragraph (g)(31)(ii)
§ 170.215(j)(1)(i) HL7 FHIR® Da Vinci—Coverage Requirements Discovery (CRD) Implementation Guide: Version 2.0.1 – STU 2
Dependent Criteria
Products presented for certification to the “Provider prior authorization API—coverage requirements discovery” certification criterion in 45 CFR 170.315(g)(31) will demonstrate conformance with and be certified to the “Workflow triggers for decision support interventions—clients” criterion in 45 CFR 170.315(j)(20) as part of certification to 45 CFR 170.315(g)(31).
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)(31).
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)(31) Provider prior authorization API – coverage requirements discovery.
Support the following capabilities to enable users to request and receive coverage requirements.
- Coverage discovery. Support the capability to initiate and exchange information as a “CRD Client” to enable the identification of coverage requirements according to at least one of the implementation specifications in § 170.215(j)(1), including the following:
- Registration. Support registration capabilities applicable to “CRD Clients”.
- CDS Hooks support. Support the capabilities in paragraph (j)(20) of this section to enable workflow triggers to call decision support services including support for the “order-sign” CDS Hook.
- CRD Client capabilities. Support all requirements and required capabilities applicable to a “CRD Client”.
- Documentation. Supported API server capabilities of “CRD Clients” from an implementation specification adopted in § 170.215(j)(1) must include complete accompanying technical documentation.
- Coverage discovery. Support the capability to initiate and exchange information as a “CRD Client” to enable the identification of coverage requirements according to at least one of the implementation specifications in § 170.215(j)(1), including the following:
- Standard(s) Referenced
-
Paragraph (g)(31)(i)
§ 170.215(j)(1)(i) HL7 FHIR® Da Vinci—Coverage Requirements Discovery (CRD) Implementation Guide: Version 2.0.1 – STU 2
See standards referenced at § 170.315(j)(20)
Paragraph (g)(31)(ii)
§ 170.215(j)(1)(i) HL7 FHIR® Da Vinci—Coverage Requirements Discovery (CRD) Implementation Guide: Version 2.0.1 – STU 2
- Certification Dependencies
-
Dependent Criteria
Products presented for certification to the “Provider prior authorization API—coverage requirements discovery” certification criterion in 45 CFR 170.315(g)(31) will demonstrate conformance with and be certified to the “Workflow triggers for decision support interventions—clients” criterion in 45 CFR 170.315(j)(20) as part of certification to 45 CFR 170.315(g)(31).
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)(31).
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 - coverage requirements discovery
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:
|
Technical outcome – The Health IT Module supports registration capabilities applicable to “CRD Clients” to enable the identification of coverage requirements according to the HL7 FHIR® Da Vinci—Coverage Requirements Discovery (CRD) Implementation Guide.
Clarifications:
- For the purposes of this requirement, “registration” includes registration and configuration necessary to exchange data for the purposes of coverage requirements discovery using workflows in accordance with CDS Hooks and CRD IGs, respectively. See the section “Security and Safety” in the CDS Hooks IG and the section “Enabling a CRD Server” in the CRD IG for additional details about the registration processes described in those IGs. (see also 90 FR 37131)
|
Technical outcome – The Health IT Module supports registration capabilities applicable to “CRD Clients” to enable the identification of coverage requirements according to the HL7 FHIR® Da Vinci—Coverage Requirements Discovery (CRD) Implementation Guide. Clarifications:
|
Paragraph (g)(31)(i)(B) CDS Hooks Support
Technical outcome – The Health IT Module supports the capabilities from the criterion at 45 CFR 170.315(j)(20) to enable workflow triggers to call decision support services including support for the “order-sign” CDS Hook according to the HL7 FHIR® Da Vinci—Coverage Requirements Discovery (CRD) Implementation Guide.
Clarifications:
- The CDS Hook of “order-sign” must be supported. Other CDS Hooks included in referenced standards and implementation guides are optional. (see also 90 FR 37170)
- Health IT Modules must support the requirements included at 45 CFR 170.315(j)(20) to support the workflow trigger capabilities of this criterion.
|
Technical outcome – The Health IT Module supports the capabilities from the criterion at 45 CFR 170.315(j)(20) to enable workflow triggers to call decision support services including support for the “order-sign” CDS Hook according to the HL7 FHIR® Da Vinci—Coverage Requirements Discovery (CRD) Implementation Guide. Clarifications:
|
Paragraph (g)(31)(i)(C) CRD Client capabilities
Technical outcome – The Health IT Module supports all requirements and required capabilities applicable to a “CRD Client” to enable the identification of coverage requirements according to the HL7 FHIR® Da Vinci—Coverage Requirements Discovery (CRD) Implementation Guide, including CRD Client capabilities.
Clarifications:
- Health IT Modules are required to support the “CRD Client CapabilityStatement” as part of supporting all required capabilities applicable to “CRD Clients,” according to theHL7 FHIR® Da Vinci—Coverage Requirements Discovery (CRD) Implementation Guide outlined in the specification. (see also 90 FR 37171)
|
Technical outcome – The Health IT Module supports all requirements and required capabilities applicable to a “CRD Client” to enable the identification of coverage requirements according to the HL7 FHIR® Da Vinci—Coverage Requirements Discovery (CRD) Implementation Guide, including CRD Client capabilities. Clarifications:
|
Technical outcome – The Health IT Module must include complete accompanying technical documentation for supported API server capabilities of “CRD Clients” from the HL7 FHIR® Da Vinci—Coverage Requirements Discovery (CRD) Implementation Guide.
Clarifications:
The following is expected to be included as part of complete accompanying technical documentation as applicable:
(1) API syntax, function names, required and optional parameters supported and their data types, return variables and their types/structures, exceptions and exception handling methods and their returns;
(2) the software components and configurations that would be necessary for an application to implement in order to be able to successfully interact with the API and process its response(s); and
(3) all applicable technical requirements and attributes necessary for an application to be registered with a Health IT Module's authorization server.
- Pursuant to the API Condition and Maintenance of Certification requirements at 45 CFR 170.404, the complete accompanying technical documentation required by 45 CFR 170.315(g)(31)(ii) must be publicly published as part of the Certified API Developer’s complete business and technical documentation. (see also 90 FR 37171)
|
Technical outcome – The Health IT Module must include complete accompanying technical documentation for supported API server capabilities of “CRD Clients” from the HL7 FHIR® Da Vinci—Coverage Requirements Discovery (CRD) Implementation Guide. Clarifications:
|