Implementing the CMS Prior Authorization API With Da Vinci CRD, DTR, and PAS

Read the requirement as capabilities, not an endpoint

CMS describes the Prior Authorization API in the singular, which understates the work. Its published workflow requires that providers be able to determine whether a prior authorization is required, identify what documentation the payer needs, submit the request electronically, and receive the payer's decision. Each of those is a distinct interaction with distinct data dependencies inside your utilization management stack.

Treating the requirement as four capabilities changes the delivery plan. Requirement checks depend on published coverage rules. Documentation discovery depends on machine-readable rule authoring. Submission and decisions depend on integrating with the adjudication path that already exists for X12 278 transactions.

How the Da Vinci guides line up with the four capabilities

Most payer programs implement this through the HL7 Da Vinci Burden Reduction guides rather than inventing a proprietary interface, because provider EHRs are building against those same guides.

• CRD (Coverage Requirements Discovery): CDS Hooks calls from the provider workflow that answer whether prior authorization is required.
• DTR (Documentation Templates and Rules): delivers payer rules to the provider so documentation is gathered in-workflow rather than by fax or portal.
• PAS (Prior Authorization Support): carries the request and the decision, mapping FHIR content to and from the X12 278 transaction where that remains the transactional standard.
• Patient Access API: prior authorization information must also be surfaced to members, which is a separate obligation on an existing API.

A build order that reduces rework

The dependency runs backwards from how teams usually plan it. PAS submission is meaningless without a rules source, and CRD answers are only trustworthy if the coverage rules behind them are governed and versioned. Start with the rules asset, then the transaction path, then the in-workflow hooks.

• Inventory the services subject to prior authorization and the current rule source of truth for each.
• Establish rule authoring, versioning, and approval before exposing any rule through an API.
• Prove the PAS path end to end against a single service category and a single provider partner under production-like conditions.
• Add CRD and DTR once rules are stable, then expand service categories on the proven pattern.

Do not let the API plan hide the operational obligations

The operational provisions of CMS-0057-F carry earlier dates than the API provisions. Impacted payers, excluding QHP issuers on the federally facilitated exchanges, must send decisions within 72 hours for expedited requests and seven calendar days for standard requests, provide specific denial reasons, and publicly report prior authorization metrics annually. Those obligations are process and reporting work owned by utilization management, and they do not become easier because an API project is underway.