PAS (Prior Authorization Support)

One-sentence definition: PAS (Prior Authorization Support) is a Da Vinci FHIR Implementation Guide that replaces the fax-and-phone prior authorization process with a structured FHIR Claim exchange — a provider submits a preauthorization Claim to the payer’s PAS endpoint and receives a real-time or pended ClaimResponse with the authorization decision, entirely within the EHR workflow.

Full Definition

Prior authorization has historically required providers to submit requests through fax, phone, or payer-specific portals — workflows that are separate from the EHR, manually intensive, and slow. PAS brings the PA submission into the FHIR API layer, making the exchange machine-to-machine, structured, and EHR-integrated.

PAS is the third and final component of the three-IG Da Vinci prior authorization stack, published by HL7. It is the submission layer: by the time a provider reaches the PAS step, CRD has already identified that PA is required and DTR has collected the supporting documentation. PAS defines how that documentation and the authorization request are packaged as a FHIR Claim resource — specifically, a Claim with use: preauthorization — and submitted to the payer, and how the payer returns the authorization decision as a ClaimResponse.

PAS is the only component of the Da Vinci PA stack individually mandated by regulation. CMS-0057-F (Interoperability and Prior Authorization Final Rule, 2024) requires affected payers — Medicare Advantage organizations, state Medicaid FFS programs, CHIP, and QHP issuers on the Exchanges — to implement an electronic PA API meeting the rule’s functional requirements by January 1, 2026. The PAS IG is the designated standard for that API requirement. CRD and DTR are best practice but not individually mandated.

The term “PAS” refers both to the IG specification and, informally, to the electronic PA submission workflow it enables. A payer that has “implemented PAS” has a FHIR endpoint that accepts preauthorization Claims and returns ClaimResponses with structured authorization decisions, including structured denial reasons for all denied requests — a specific CMS-0057-F requirement.

For the complete PAS technical workflow — Claim structure, synchronous vs pended responses, ClaimResponse decision codes, preAuthRef propagation, X12 278 translation, and CMS-0057-F compliance requirements — see Prior Authorization Workflow.

Context and Usage

Where This Term Appears

• Da Vinci IG documentation and HL7 project materials
• CMS-0057-F compliance planning and regulatory guidance documents
• Payer developer portals listing PA API endpoints
• EHR vendor documentation for PA submission workflows
• Clearinghouse and intermediary product documentation (many payers route FHIR PAS through clearinghouses that translate to X12 278)
• Healthcare interoperability procurement requirements

Common Usage Examples

In conversation: “We’re connected to four payer PAS endpoints. Two return synchronous approvals for most requests; the other two pend everything and notify us via subscription.”

In technical contexts: “The PAS endpoint rejected the submission because the Claim was missing use: preauthorization — it was being sent as a standard billing claim.”

In regulatory contexts: “CMS-0057-F mandates PAS-compatible PA APIs by January 1, 2026. CRD and DTR aren’t in scope for the mandate but we’re recommending the full stack.”

In documentation: “A denied PAS ClaimResponse must include structured denial reason codes — a free-text processNote alone does not satisfy CMS-0057-F requirements.”

Relationship to Other Terms

PAS is the downstream step in the Da Vinci PA stack:

• CRD — Coverage Requirements Discovery; the first step, which identifies whether PA is needed; PAS is only reached after CRD has signalled a PA requirement
• DTR — Documentation Templates and Rules; the second step, which collects clinical documentation; the QuestionnaireResponse from DTR is included in the PAS Claim submission as supporting information
• Claim — the FHIR resource used in a PAS submission; a preauthorization Claim differs from a billing Claim in the use field value (preauthorization vs claim)
• ClaimResponse — the FHIR resource carrying the payer’s PA decision; includes the authorization number (preAuthRef) for approved requests and structured denial reasons for denied requests
• CMS-0057-F — the federal regulation that individually mandates an electronic PA API meeting PAS functional requirements for affected payers
• X12 278 — the EDI transaction PAS replaces at the provider-facing interface; many payer backends still process PA internally as X12 278, with clearinghouse intermediaries translating between FHIR and X12

Common Misconceptions

“PAS requires implementing CRD and DTR first.” PAS is a standalone IG. A provider system can submit a PAS Claim without having implemented CRD or DTR — the upstream workflow just has to be handled by other means. CMS-0057-F mandates the PAS submission layer; CRD and DTR are recommended but not required prerequisites.

“PAS responses are always real-time.” PAS supports both synchronous responses (the ClaimResponse arrives in the HTTP response to the Claim POST) and pended responses (the ClaimResponse returns outcome: queued immediately, with the final decision delivered later). Payers processing complex clinical cases or routing through X12 backends often pend requests. Provider systems must handle both patterns.

“A FHIR response from an intermediary is equivalent to a native PAS response.” Many payers route FHIR PAS through clearinghouse intermediaries that translate to X12 278 on the backend. The translation can introduce semantic gaps — structured data in the FHIR model may not survive the round-trip intact. Responses from intermediary-fronted payers may use processNote text where structured fields are expected.

---

Last reviewed: February 16, 2026 Definition authority: HL7 International Content status: Canonical reference