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

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 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:

Primary sources: the CMS-0057-F fact sheet and the three published IG homes above. US Core remains the patient/clinical profile layer — see US Core and TEFCA. DTR’s SMART launch is the SMART 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 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
• SMART on FHIR app launch
• HL7 FHIR R4 integration

For mapping CRD, DTR and PAS onto an existing EHR or payer stack, use HL7 FHIR integration or start a project.