§170.315(g)(33) Provider prior authorization API - prior authorization support
(g)(33) Provider prior authorization API – prior authorization support.
Support the following capabilities to enable users to submit prior authorization requests.
- Prior authorization submission. Support submitting a prior authorization request as a client in accordance with at least one of the versions of the implementation specifications in § 170.215(j)(3) including the following:
- Registration. Support registration capabilities applicable to a client system.
- 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).
- Prior authorization transactions. Support the ability to submit a prior authorization request as a client system including the following:
- Support the capabilities in the “EHR PAS Capabilities” Capability Statement.
- Support the ability to consume and process a “ClaimResponse.”
- Support subscriptions as a client according to the requirements in paragraph (j)(21) of this section in order to support “pended authorization responses.”
- Documentation. Supported subscriptions client endpoint capabilities for the “REST‑Hook” channel from implementation specifications adopted in § 170.215(j)(3) must include complete accompanying technical documentation.
Paragraph (g)(33)(i)
§ 170.215(j)(3)(i) HL7 FHIR® Da Vinci Prior Authorization Support (PAS) FHIR Implementation Guide: Version 2.0.1—STU 2
§ 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, v2.0.0
See standards referenced at § 170.315(j)(21)
Paragraph (g)(33)(ii)
§ 170.215(j)(3)(i) HL7 FHIR® Da Vinci Prior Authorization Support (PAS) FHIR Implementation Guide: Version 2.0.1—STU 2
Dependent Criteria
Products presented for certification to the “Provider prior authorization API—prior authorization support” certification criterion in 45 CFR 170.315(g)(33) will demonstrate conformance with and be certified to the “Subscriptions—client” criterion in 45 CFR 170.315(j)(21) as part of certification to 45 CFR 170.315(g)(33).
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)(33).
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
(g)(33) Provider prior authorization API – prior authorization support.
Support the following capabilities to enable users to submit prior authorization requests.
- Prior authorization submission. Support submitting a prior authorization request as a client in accordance with at least one of the versions of the implementation specifications in § 170.215(j)(3) including the following:
- Registration. Support registration capabilities applicable to a client system.
- 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).
- Prior authorization transactions. Support the ability to submit a prior authorization request as a client system including the following:
- Support the capabilities in the “EHR PAS Capabilities” Capability Statement.
- Support the ability to consume and process a “ClaimResponse.”
- Support subscriptions as a client according to the requirements in paragraph (j)(21) of this section in order to support “pended authorization responses.”
- Documentation. Supported subscriptions client endpoint capabilities for the “REST‑Hook” channel from implementation specifications adopted in § 170.215(j)(3) must include complete accompanying technical documentation.
- Prior authorization submission. Support submitting a prior authorization request as a client in accordance with at least one of the versions of the implementation specifications in § 170.215(j)(3) including the following:
- Standard(s) Referenced
-
Paragraph (g)(33)(i)
§ 170.215(j)(3)(i) HL7 FHIR® Da Vinci Prior Authorization Support (PAS) FHIR Implementation Guide: Version 2.0.1—STU 2
§ 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, v2.0.0
See standards referenced at § 170.315(j)(21)
Paragraph (g)(33)(ii)
§ 170.215(j)(3)(i) HL7 FHIR® Da Vinci Prior Authorization Support (PAS) FHIR Implementation Guide: Version 2.0.1—STU 2
- Certification Dependencies
-
Dependent Criteria
Products presented for certification to the “Provider prior authorization API—prior authorization support” certification criterion in 45 CFR 170.315(g)(33) will demonstrate conformance with and be certified to the “Subscriptions—client” criterion in 45 CFR 170.315(j)(21) as part of certification to 45 CFR 170.315(g)(33).
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)(33).
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)(33)(i) Prior authorization submission
The health IT developer demonstrates the Health IT Module supports the following capabilities as a client system in accordance with an implementation specification at § 170.215(j)(3) and the requirements in the § 170.315(j)(21) criterion:
- PAS-1: Registration with a server system (e.g., payer system) to enable authentication, authorization, and FHIR operations as described in the “EHR PAS Capabilities Capability Statement.”
- PAS-2: Authentication and authorization as a client with a server system using “Backend Services” in accordance with an implementation specification at § 170.215(c).
- PAS-3: Submit a new prior authorization claim request to a server system using the “$submit” operation.
- PAS-4: Support the following using the “$submit” operation for a claim request previously submitted to a server system:
- Cancel an entire claim request.
- Cancel an item within a claim request.
- Revise an item within a claim request.
- Add an additional item or supporting documentation to a claim request.
- PAS-5: Manage claim request subscriptions to a server system including the ability to create, update, and delete subscriptions.
- PAS-6: Consume claim request subscription notifications from a server system.
- PAS-7: Check the status of a claim request previously submitted to a server system using the “$inquire” operation.
The tester verifies the Health IT Module supports the following capabilities as a client system in accordance with an implementation specification at § 170.215(j)(3) and the requirements in the § 170.315(j)(21) criterion:
- PAS-1: Registration with a server system (e.g., payer system) to enable authentication, authorization, and FHIR operations as described in the “EHR PAS Capabilities Capability Statement.”
- PAS-2: Authentication and authorization as a client with a server system using “Backend Services” in accordance with an implementation specification at § 170.215(c).
- PAS-3: Submit a new prior authorization claim request to a server system using the “$submit” operation.
- PAS-4: Support the following using the “$submit” operation for a claim request previously submitted to a server system:
- Cancel an entire claim request.
- Cancel an item within a claim request.
- Revise an item within a claim request.
- Add an additional item or supporting documentation to a claim request.
- PAS-5: Manage claim request subscriptions to a server system including the ability to create, update, and delete subscriptions.
- PAS-6: Consume claim request subscription notifications from a server system.
- PAS-7: Check the status of a claim request previously submitted to a server system using the “$inquire” operation.
| System Under Test | Test Lab Verification |
|---|---|
|
The health IT developer demonstrates the Health IT Module supports the following capabilities as a client system in accordance with an implementation specification at § 170.215(j)(3) and the requirements in the § 170.315(j)(21) criterion:
|
The tester verifies the Health IT Module supports the following capabilities as a client system in accordance with an implementation specification at § 170.215(j)(3) and the requirements in the § 170.315(j)(21) criterion:
|
Paragraph (g)(33)(ii) Documentation
- API-DOC-1: The health IT developer supplies complete accompanying technical documentation for supported API server capabilities of client systems from an implementation specification adopted in § 170.215(j)(3). 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 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 API server capabilities of client systems from an implementation specification adopted in § 170.215(j)(3) 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 |
|---|---|
|
|
(g)(33) Provider prior authorization API – prior authorization support.
Support the following capabilities to enable users to submit prior authorization requests.
- Prior authorization submission. Support submitting a prior authorization request as a client in accordance with at least one of the versions of the implementation specifications in § 170.215(j)(3) including the following:
- Registration. Support registration capabilities applicable to a client system.
- 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).
- Prior authorization transactions. Support the ability to submit a prior authorization request as a client system including the following:
- Support the capabilities in the “EHR PAS Capabilities” Capability Statement.
- Support the ability to consume and process a “ClaimResponse.”
- Support subscriptions as a client according to the requirements in paragraph (j)(21) of this section in order to support “pended authorization responses.”
- Documentation. Supported subscriptions client endpoint capabilities for the “REST‑Hook” channel from implementation specifications adopted in § 170.215(j)(3) must include complete accompanying technical documentation.
Paragraph (g)(33)(i)
§ 170.215(j)(3)(i) HL7 FHIR® Da Vinci Prior Authorization Support (PAS) FHIR Implementation Guide: Version 2.0.1—STU 2
§ 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, v2.0.0
See standards referenced at § 170.315(j)(21)
Paragraph (g)(33)(ii)
§ 170.215(j)(3)(i) HL7 FHIR® Da Vinci Prior Authorization Support (PAS) FHIR Implementation Guide: Version 2.0.1—STU 2
Dependent Criteria
Products presented for certification to the “Provider prior authorization API—prior authorization support” certification criterion in 45 CFR 170.315(g)(33) will demonstrate conformance with and be certified to the “Subscriptions—client” criterion in 45 CFR 170.315(j)(21) as part of certification to 45 CFR 170.315(g)(33).
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)(33).
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
(g)(33) Provider prior authorization API – prior authorization support.
Support the following capabilities to enable users to submit prior authorization requests.
- Prior authorization submission. Support submitting a prior authorization request as a client in accordance with at least one of the versions of the implementation specifications in § 170.215(j)(3) including the following:
- Registration. Support registration capabilities applicable to a client system.
- 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).
- Prior authorization transactions. Support the ability to submit a prior authorization request as a client system including the following:
- Support the capabilities in the “EHR PAS Capabilities” Capability Statement.
- Support the ability to consume and process a “ClaimResponse.”
- Support subscriptions as a client according to the requirements in paragraph (j)(21) of this section in order to support “pended authorization responses.”
- Documentation. Supported subscriptions client endpoint capabilities for the “REST‑Hook” channel from implementation specifications adopted in § 170.215(j)(3) must include complete accompanying technical documentation.
- Prior authorization submission. Support submitting a prior authorization request as a client in accordance with at least one of the versions of the implementation specifications in § 170.215(j)(3) including the following:
- Standard(s) Referenced
-
Paragraph (g)(33)(i)
§ 170.215(j)(3)(i) HL7 FHIR® Da Vinci Prior Authorization Support (PAS) FHIR Implementation Guide: Version 2.0.1—STU 2
§ 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, v2.0.0
See standards referenced at § 170.315(j)(21)
Paragraph (g)(33)(ii)
§ 170.215(j)(3)(i) HL7 FHIR® Da Vinci Prior Authorization Support (PAS) FHIR Implementation Guide: Version 2.0.1—STU 2
- Certification Dependencies
-
Dependent Criteria
Products presented for certification to the “Provider prior authorization API—prior authorization support” certification criterion in 45 CFR 170.315(g)(33) will demonstrate conformance with and be certified to the “Subscriptions—client” criterion in 45 CFR 170.315(j)(21) as part of certification to 45 CFR 170.315(g)(33).
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)(33).
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 - prior authorization support
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)(33)(i) Prior authorization submission
Technical outcome – A Health IT Module supports submitting a prior authorization request as a client in accordance with at the HL7 FHIR® Da Vinci Prior Authorization Support (PAS) FHIR Implementation Guide, including registration, authentication and authentication, and prior authorization transactions support.
Clarifications:
- For purposes of certification, the Health IT Module must support system authentication and authorization as a client in accordance with the “Backend Services” section of one of the versions of the HL7 FHIR® SMART Application Launch Implementation Guide adopted in § 170.215(c). [see also 90 FR 37174]
|
Technical outcome – A Health IT Module supports submitting a prior authorization request as a client in accordance with at the HL7 FHIR® Da Vinci Prior Authorization Support (PAS) FHIR Implementation Guide, including registration, authentication and authentication, and prior authorization transactions support. Clarifications:
|
Paragraph (g)(33)(ii) Documentation
Technical outcome – A Health IT Module must include complete accompanying documentation for supported subscriptions client endpoint capabilities for the “REST-Hook” channel from the HL7 FHIR® Da Vinci Prior Authorization Support (PAS) FHIR Implementation Guide.
Clarifications:
- These requirements complement existing requirements in the “Transparency conditions” at 45 CFR 170.404(a)(2). [see also 90 FR 37174]
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. [see also 90 FR 37174]
- Pursuant to the API Condition and Maintenance of Certification requirements at 45 CFR 170.404, the documentation required by 45 CFR 170.315(g)(33)(ii) must be publicly published as part of the Certified API Developer’s complete business and technical documentation.
|
Technical outcome – A Health IT Module must include complete accompanying documentation for supported subscriptions client endpoint capabilities for the “REST-Hook” channel from the HL7 FHIR® Da Vinci Prior Authorization Support (PAS) FHIR Implementation Guide. Clarifications:
|