Prior Authorization Support implementation guide

Editorial approval scope: The team checked current source fidelity, scope boundaries, dates, arithmetic, reader usefulness, practical workflow, and general-information limitations.

PAS structures a request and response workflow

The current Da Vinci PAS guide defines constrained FHIR resources and bundles for prior-authorization interactions. It includes request, response, inquiry, and update patterns plus patient, coverage, practitioner, organization, service, and supporting-information profiles.

An implementation uses the named guide version, profiles, terminology, operations, and conformance rules. “FHIR supported” does not establish PAS conformance.

The guide remains trial use

Version 2.2.1 is designated STU 2.2 and maturity level 4. Standard for Trial Use means implementer feedback can shape later releases. Record the package version, official canonical URL, dependencies, change history, and partner-supported release.

Maintain older versions while open requests, appeals, corrections, and trading partners still depend on them. A silent profile upgrade can break a valid workflow.

FHIR and X12 have distinct roles

The PAS guide is intended to support mapping between FHIR and X12 prior-authorization transactions. The guide explains that X12-specific mapping and terminology are published under X12 rules and may require membership or payment. Do not copy restricted content into public documentation or software without the appropriate rights.

The FHIR-facing application may communicate with an intermediary that handles the applicable HIPAA transaction requirements and payer connection. Record which party validates FHIR, performs mapping, submits X12, receives the payer response, and returns the FHIR result.

PAS works beside CRD and DTR

Coverage Requirements Discovery can surface whether prior authorization applies and what process may be needed. Documentation Templates and Rules can retrieve computable documentation requirements and questionnaires. PAS carries the prior-authorization request and response workflow. Implementations may combine them, but each guide has its own version, profiles, operations, and failure states.

Record which guide supports each step and what happens when one endpoint is unavailable. A successful CRD response does not establish authorization. A completed DTR questionnaire does not prove medical necessity. A valid PAS bundle does not establish payer approval. Test supported version combinations, preserve the payer's authoritative response, and keep clinical content and submission decisions under qualified human review.

Build a route-specific contract

For each payer, product, service, and route, record:

• PAS and FHIR versions, endpoint, intermediary, and trading partners
• supported request, inquiry, update, cancel, and response operations
• identifiers, provider and location roles, coverage, service, dates, and units
• required supporting information, attachments, terminology, and signatures
• authentication, authorization, consent or disclosure route, and security
• acknowledgement, error, retry, duplicate, timeout, and reconciliation behavior
• human clinical review, submission authority, appeal, and fallback

Avoid one universal payer configuration. Companion guides, contracts, plan documents, and operational instructions can narrow the route.

Keep clinical content under qualified control

Software can assemble sourced information and flag missing elements. A qualified clinician decides whether clinical evidence, goals, dosage, risk, or rationale should change. Administrative staff and software should not rewrite clinical content merely to satisfy a technical rule.

Give the authorized submitter a reviewable package with provenance. Preserve source records, transformations, submission artifact, control identifiers, response, corrections, and final disposition.

A fictional PAS test cohort

Jade's practice locks 12 fictional PAS cases across supported routes. Nine pass profile validation, identity, coverage, service, supporting-information, human-approval, response, and reconciliation checks: 9 of 12, or 75%.

One uses an unsupported profile version. One loses an attachment reference. One response enters no work queue. All three remain held with owners. The ratio measures this test cohort, not payer coverage, production readiness, authorization, or payment.

CMS rules have a defined payer scope

The CMS-0057-F fact sheet identifies Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on Federally-facilitated Exchanges as impacted payers. The Prior Authorization API covers medical items and services excluding drugs and generally begins January 1, 2027.

Other commercial and employer plans fall outside that mandatory payer scope. The rule does not prove a PAS endpoint is live, complete, current, or configured for ABA. Verify every payer, product, route, date, and request.

Test every state transition

Include new, pended, approved, partially approved, denied, updated, duplicate, corrected, cancelled, timed-out, and unavailable cases where the route supports them. Confirm user-visible meaning and downstream ownership.

Measure complete workflows divided by cases due for review. Report technical validation, intermediary acceptance, payer receipt, request status, final coverage action, and operational completion separately. Authorization remains distinct from a later claim's adjudication and payment.

The base HL7 FHIR specification supplies general resources and API patterns. PAS adds use-case constraints. Neither supplies a universal clinical, privacy, payer, or legal decision.