# Da Vinci CRD, DTR and PAS: FHIR prior authorization under CMS-0057-F

> CMS-0057-F points impacted payers at Da Vinci CRD, DTR and PAS. Operational prior-auth rules generally 2026; FHIR APIs generally 1 January 2027. Pin live STU versions. Not a payer certification.

Author: Ala Ben Aicha

Canonical page: https://alabenaicha.me/insights/da-vinci-prior-authorization-fhir

Updated: 2026-09-19

## Direct answer

CMS-0057-F points impacted payers at Da Vinci CRD, DTR and PAS. Operational prior-auth rules apply generally in 2026; the FHIR Prior Authorization API is generally 1 January 2027. This is not a payer certification.

## CRD vs DTR vs PAS

Pin the **live published STU** on write day (19 September 2026), not the older versions the [CMS-0057-F fact sheet](https://www.cms.gov/newsroom/fact-sheets/cms-interoperability-and-prior-authorization-final-rule-cms-0057-f) *recommended* in January 2024. The fact sheet still names CRD STU 2.0.1, DTR STU 2.0.0 and PAS STU 2.0.1 as recommended IGs; it also lets impacted payers use an updated ONC-approved standard when that does not disrupt API access. Current published homes:

| IG                                          | Live STU (write day)            | Package                                                                                                   | Question it answers                                                       | FHIR surface                                                                                    | What it is not                               |
| ------------------------------------------- | ------------------------------- | --------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | -------------------------------------------- |
| **CRD** — Coverage Requirements Discovery   | **2.2.1** (STU 2.2, March 2026) | `hl7.fhir.us.davinci-crd#2.2.1` — [hl7.org/fhir/us/davinci-crd](https://www.hl7.org/fhir/us/davinci-crd/) | Is prior authorization required? What coverage rules apply at order time? | CDS Hooks against the payer CRD service                                                         | Not the PA request, not a documentation form |
| **DTR** — Documentation Templates and Rules | **2.2.0** (STU 2.2, March 2026) | `hl7.fhir.us.davinci-dtr#2.2.0` — [hl7.org/fhir/us/davinci-dtr](https://www.hl7.org/fhir/us/davinci-dtr/) | What documentation does this PA need?                                     | Questionnaire / QuestionnaireResponse, CQL, `$questionnaire-package`; SMART app or EHR-embedded | Not the coverage decision                    |
| **PAS** — Prior Authorization Support       | **2.2.1** (STU 2, March 2026)   | `hl7.fhir.us.davinci-pas#2.2.1` — [hl7.org/fhir/us/davinci-pas](https://www.hl7.org/fhir/us/davinci-pas/) | Submit the request and receive the decision                               | Profiled Claim (request) and ClaimResponse (decision), often with Task for updates              | Not a CMS or payer certification             |

Primary sources: the [CMS-0057-F fact sheet](https://www.cms.gov/newsroom/fact-sheets/cms-interoperability-and-prior-authorization-final-rule-cms-0057-f) and the three published IG homes above. US Core remains the patient/clinical profile layer — see [US Core and TEFCA](https://alabenaicha.me/insights/fhir-us-core-tefca-implementation). DTR’s SMART launch is the [SMART App Launch](https://alabenaicha.me/insights/smart-on-fhir-app-launch) handshake, not a second PA protocol.

The fact sheet’s **Prior Authorization API** must be populated with the payer’s list of covered items and services, identify documentation requirements, support a request and a response, and communicate approve (with an end date or circumstance), deny (with a specific reason), or request more information. **Drugs are excluded.**

## The rule and the impacted payer list

CMS-0057-F is the *CMS Interoperability and Prior Authorization* final rule. The fact sheet’s **impacted payers** are Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan issuers on the Federally Facilitated Exchanges. That is **not** every commercial plan.

Dates from the fact sheet — do not invent others:

* **Operational / process PA rules** (decision timeframes, denial reason, public metrics): generally beginning **1 January 2026**. Expedited decisions in 72 hours and standard decisions in seven calendar days apply to impacted payers **excluding QHP issuers on the FFEs**. Initial metrics must be reported by **31 March 2026**.
* **API development and enhancement**, including the Prior Authorization API: generally beginning **1 January 2027**. Exact compliance dates vary by payer type.

HHS announced **enforcement discretion** for the HIPAA X12 278 prior-authorization transaction when a covered entity implements an all-FHIR Prior Authorization API under this rule. FHIR-only, FHIR+X12, or X12-only remain options; PAS still documents the X12 mapping. That discretion is not a waiver of CMS-0057-F.

The identifier on the PAS request is the profiled **Claim.identifier** (the prior-authorization request id the payer and provider share). Member identity stays on Coverage / US Core Patient; do not mint a second medical-record number to satisfy PAS.

## What to implement first

1. Name the **buyer’s role**. Payer: CRD service, DTR Questionnaire package, PAS ClaimResponse. Provider / EHR: CRD CDS Hooks client, DTR form fill (SMART or embedded), PAS Claim submit. App vendor: usually DTR + SMART, not a private “PA JSON”.
2. Pin **CRD 2.2.1, DTR 2.2.0, PAS 2.2.1** (or the versions the trading partner names) in the package lock. Record that the fact sheet still cites 2.0.x.
3. Walk **one** order-to-decision path in a test environment: CRD hook at order time → DTR QuestionnaireResponse when documentation is required → PAS Claim / ClaimResponse. Keep drugs out of that fixture; the rule excludes them.
4. Treat sandbox vs production as a test matrix, the same way [SMART launch](https://alabenaicha.me/insights/smart-on-fhir-app-launch) does. A green Inferno run is not CMS certification.

## What this is not

This page is not a CMS certification, not a payer go-live letter, not legal advice, and not a substitute for the buyer’s named IG versions. Implementing CRD/DTR/PAS in a lab does not make a product “CMS-0057-F compliant”. I do not certify payers or EHRs. Nothing here is clinical advice.

## Related reading

* [US Core and TEFCA](https://alabenaicha.me/insights/fhir-us-core-tefca-implementation)
* [SMART on FHIR app launch](https://alabenaicha.me/insights/smart-on-fhir-app-launch)
* [HL7 FHIR R4 integration](https://alabenaicha.me/insights/hl7-fhir-integration-guide)

For mapping CRD, DTR and PAS onto an existing EHR or payer stack, use [HL7 FHIR integration](https://alabenaicha.me/services/hl7-fhir-integration) or [start a project](https://alabenaicha.me/contact?intent=project).