In brief: Prior Authorization Support is the Da Vinci guide that carries the request. A FHIR Claim bundle goes to Claim/$submit; the payer answers quickly with approved, denied or pended, then pushes the final decision back through a FHIR subscription. Updates, cancels and $inquire cover the rest of the lifecycle. The HIPAA X12 278 standard still applies unless the parties use the FHIR API under HHS's enforcement discretion; CMS-0062-P proposes to replace the 278 with FHIR, but that is still a proposal.
Prior Authorization Support is the third Da Vinci guide in the CMS-0057-F Prior Authorization API and the one that carries the actual request. CRD said an approval is needed. DTR collected the documentation. PAS packages the order, the coverage, the clinical evidence and the completed questionnaire into one FHIR bundle, sends it to the payer, and brings the decision back.
PAS is also where the rule meets HIPAA. The transaction standard for prior authorization is still the X12 278, and a payer that receives a FHIR bundle from a provider has to reconcile that with the 278 adoption standard. The guide's answer was an intermediary that translates; HHS's answer in February 2024 was enforcement discretion; the proposed CMS-0062-P's answer is to replace the 278 with FHIR outright. Our earlier posts on building the CMS-mandated FHIR prior authorization API and what electronic prior authorization is give the overview; this one goes through the bundle, the submit operation and its timing, subscriptions, updates and cancels, inquiry, the intermediary, and testing. Identifiers such as §spec-8 are the PAS guide's own (version 2.2.1 is current; CMS names 2.1.0 for 2027).
The bundle
A PAS request is a Claim resource with use = preauthorization, wrapped in a Bundle with everything it references.
- Claim: the requested items with procedure and diagnosis codes, service dates, place of service, quantities, and the requesting provider. PAS profiles the Claim heavily; the 278's loops map onto its fields.
- Patient, Coverage, Organization (insurer): who, under which plan.
- Practitioner and PractitionerRole: the requester and, where different, the servicing provider, with NPIs.
- Supporting information: the DTR QuestionnaireResponse, relevant Conditions, Observations, Procedures, DocumentReferences for attachments. Supporting resources are referenced from
Claim.supportingInfo.
The guide's bundle rules (§spec-11 to §spec-24) fix the mechanics: the Bundle is of type collection; the Claim is the first entry; every referenced resource is in the bundle; identifiers are used the way the 278 expects them. Attachments travel inline as base64 in DocumentReference or, through an intermediary, as an X12 275. The single most common validation failure in test kits is a reference that points outside the bundle.
Claim/$submit and the fifteen seconds
The request goes to the payer's Claim/$submit operation. The response is a ClaimResponse bundle carrying one of three outcomes per line item: approved, denied, or pended for review, with an authorization number, a validity period, and the reason where denied.
Timing is explicit. The guide sets a fifteen-second expectation for the $submit response, even if the response only says the request is pended, and §spec-9 adds that clients "SHALL NOT" poll while pended. Check the exact conformance wording in the version you build to. Fifteen seconds is plenty to validate the bundle, run auto-adjudication rules, and either decide or queue for a reviewer. It is not enough to call a legacy utilization-management system that takes minutes to accept a case, which is why the workflow engine in front of that system has to own the acknowledgement and hand off asynchronously.
Two clarifications from CMS's own FAQ are worth repeating to any buyer who has heard otherwise: real-time decisions are not required by the rule; the decision timeframes are seventy-two hours for expedited and seven calendar days for standard requests, running from receipt. The fifteen seconds is about the acknowledgement and any immediate decision the payer's rules allow. Where the rules do allow it, vendor-reported pilots describe a large share of eligible requests auto-approved, which shortens the durations that feed the plan's public average and median decision-time metrics.
Denials must carry a specific reason. The rule requires it from January 2026 for all methods; PAS carries it in ClaimResponse.item.adjudication with a reason code, and the Provider Access and Patient Access APIs surface the same reason to the practice and the member.
Subscriptions, not polling
Because most requests are pended, the provider needs to learn when the decision lands. The guide's answer is FHIR Subscriptions, using the R5 backport.
- Payers "SHALL" support subscriptions (§spec-8 and §spec-51), and the only channel required is
rest-hook(§spec-56). The provider's system registers an endpoint; the payer POSTs to it when the ClaimResponse changes. - The topic filters by organization identifier, so a large provider organization gets only its own decisions (§spec-58).
- Notifications carry the full resource, not just an id (§spec-61 and §spec-62), which avoids a second round trip.
- The client "SHALL NOT" poll
$inquirefor a pended request (§spec-9). Inquiry exists for recovery and for requests submitted by other channels, not as a substitute for subscriptions. - Payers "SHALL" retain requests and decisions for at least six months so
$inquirecan find them (§spec-73).
Subscriptions are the part of PAS most payers have never run. FHIR R4 Subscription implementations are uneven, the R5 backport is a distinct specification, and rest-hook delivery needs an allow-listed provider endpoint with its own security. Plan for a subscription service as a component, not a feature flag on the FHIR server.
A recorded payer update triggers notification delivery to the provider. Failed delivery needs retry and recovery; successful receipt lets the provider workflow reflect the new status.
Updates, cancels, and inquiry
A prior authorization is rarely submitted once and left alone. The provider adds information the reviewer asked for, changes a date, or cancels because the patient chose a different treatment.
- An update is a new
$submitwhose Claim carries the original request identifier inClaim.relatedwith the update relationship, plus the changed items or added supporting information (§spec-65 and §spec-66). - A cancel is a
$submitwith the cancel relationship (§spec-67 and §spec-68). The payer records the cancellation and responds with a ClaimResponse that says so. Claim/$inquiretakes a subset of the Claim (patient, provider, dates, optionally the authorization number) and returns the current state of matching requests. It is the recovery path when a subscription notification was missed, and the way a provider that submitted by fax or portal can check status electronically.- A payer that pends a request and needs more information indicates it in the ClaimResponse with a
CommunicationRequestfor the specific attachment or questionnaire, and the provider answers with an update.
All three carry the same fifteen-second acknowledgement rule.
Submission can lead to review and a request for more information. The provider update returns to review before the final decision; this is a conceptual lifecycle rather than a wire-format specification.
The X12 278 bridge and enforcement discretion
Here the guide meets the transaction rule.
Under HIPAA, a covered entity that conducts a prior-authorization transaction electronically must use the adopted standard, the X12 278. The PAS guide was designed around that: the provider sends FHIR to an intermediary, typically a clearinghouse, which translates to a 278 for the payer and translates the 278 response back. The guide fixes how that works: the intermediary "SHALL" pass the full FHIR bundle through unchanged where the payer accepts FHIR (§spec-26), and where translation is needed, attachments go as an X12 275 with base64 or HL7 CDA payloads (§spec-28). The PAS Claim profile carries X12-licensed code systems, and implementers need an X12 license to use them.
On 28 February 2024, HHS announced enforcement discretion: it will not enforce the 278 requirement against covered entities that use the Da Vinci PAS FHIR API for prior authorization, so a payer and a provider can exchange FHIR end to end without an intermediary. CMS's FAQ adds the other half: using the 278 alone "cannot meet the other requirements" of the API, because the 278 carries neither the coverage-discovery nor the documentation-rules capabilities.
CMS-0062-P, proposed on 14 April 2026, would make this permanent by adopting FHIR as the HIPAA standard for prior authorization, retiring the 278 for that use about twenty-four months after a final rule, with a thirty-six-month path for some entities. That is the reason the "commercial payers are not impacted" line is only half true: a HIPAA transaction standard applies to every covered entity, not just the CMS-regulated plans.
What this means for a clearinghouse: the translator has a defined life, and the durable role is the hub that gives one endpoint to thousands of providers and handles routing, identity and subscriptions on their behalf. What it means for a payer: build PAS to accept FHIR natively, and keep the 278 path as an adapter behind the same workflow engine.
How to test PAS before you meet a real provider
- The HL7 Foundry Burden Reduction bundle. The prior-auth reference server accepts
$submit, returns approved, denied or pended by rule, and drives subscriptions. Send bundles from the reference DTR app or from Postman. - The Inferno PAS test kit. Its server suites (2.0.1 and 2.2.1 at the time of writing) validate bundle rules,
$submit,$inquire, update and cancel semantics, and the subscription topic, for the requirements the kit documents. - The Acentra Health sandbox. Exposes
$submitand$inquireon synthetic data with a 10 MB request cap, and issues a real pended-then-decided flow; use it for end-to-end timing. - CMS's PCG-FHIR pilot. Medicare fee-for-service review contractors run a FHIR prior-auth pilot over esMD; contact is published by the pilot team. Useful to see how a government reviewer consumes PAS bundles.
- A subscription harness. Stand up a rest-hook receiver, register it, submit a pended request, and prove the notification arrives with the full ClaimResponse and the right organization filter. No published kit tests delivery to your endpoint; you need your own.
- A clearinghouse round trip. If your providers submit through Availity or another hub, test the intermediary path with a real 278 translation and a 275 attachment before go-live. The failures at connectathons are field-mapping and identifier mismatches, not FHIR syntax.
A worked example (illustrative): the life of one request
Follow the lumbar MRI request from the CRD and DTR examples through PAS. Timings, sizes and outcomes here are illustrative, and the policy is invented.
- 4:58 pm, day 0. The EHR posts a bundle to
Claim/$submit: the Claim with one item coded 72148, the Patient, the Coverage, the requesting neurologist, the imaging center as servicing provider, the Condition, and the completed QuestionnaireResponse. Eleven resources, forty kilobytes. - 4:58 pm plus two seconds. The facade validates the bundle rules, the workflow engine records the request, routes it to the imaging category, and runs the adjudication rules. The DTR answers satisfy the policy. The engine returns a ClaimResponse with the item approved, an authorization number, and a validity period of sixty days. That two-second duration becomes one observation in the dataset behind the plan's public average and median decision-time metrics.
- Alternative, 4:58 pm plus two seconds. The answers do not satisfy the policy because conservative therapy was five weeks, not six. The engine returns pended, creates a case in the utilization-management system through the adapter, and records a subscription notification target.
- Day 1, 10:15 am. The reviewer requests a physiotherapy note. The engine updates the ClaimResponse with a CommunicationRequest and sends a rest-hook notification to the practice's endpoint.
- Day 1, 2:40 pm. The practice submits an update, a
$submitwith the original identifier and a DocumentReference carrying the note. - Day 2, 9:05 am. The reviewer approves. The ClaimResponse changes to approved, the subscription fires, the practice's system shows the authorization number on the order, and the same decision appears in Patient Access and Provider Access within the business day. The request is retained for six months and counted in the public metrics.
The clocks in the rule ran from 4:58 pm on day 0, and the decision came in about forty hours, inside the seven-day standard window and, had it been marked expedited, inside the seventy-two-hour one.
The metrics PAS feeds
Every path through PAS lands in the plan's public numbers. The metrics the rule requires each plan to post annually, first due by 31 March 2026 for 2025, are percentages and timings rather than raw counts: the list of items and services subject to prior authorization; the percentages of standard requests approved, denied, and approved after appeal; the percentage of standard requests whose timeframe was extended and then approved; the percentages of expedited requests approved and denied; and the average and median time to decision for standard and for expedited requests. The counts behind those percentages are the denominators the plan must keep, and the workflow engine is where they come from. Requests that arrive by fax or portal have to be entered into the same engine, or the metrics understate volume and overstate speed. CMS-0062-P proposes six further prior-authorization measures and fifteen for drugs; all of them are queries over the same store.
What a payer needs behind $submit
The operation is small; what sits behind it is not. Five capabilities have to exist before the first real bundle arrives.
- Bundle validation against the PAS profiles, with the X12-licensed code systems loaded, returning an OperationOutcome that names the failing element. Providers fix what they can see.
- Auto-adjudication rules keyed by the same policy identifiers CRD and DTR use, so a request whose questionnaire answers satisfy the policy approves in the acknowledgement window. This is where the median-time metric is won.
- A case bridge to the utilization-management system that creates the case asynchronously, keeps the request identifier on both sides, and pulls decisions back into the ClaimResponse. The UM system was never built to answer in fifteen seconds; the bridge takes it out of the critical path.
- A subscription service with the R5 backport topic, organization filtering, full-resource payloads, retry and an allow-list of provider endpoints.
- A retention and audit store holding every request, update, cancel, inquiry and notification for at least six months, and feeding the metrics mart.
A delegated vendor needs only the second of these. The plan needs all five, which is why the composition rule in this series puts the workflow engine at the plan and lets vendors decide inside it.
If you need a PAS endpoint with subscriptions, an X12 278 bridge behind it, or a review of an existing implementation against the guide version you are targeting, see our X12 EDI integration services and CMS-0057-F interoperability suite pages, or talk to our team.
Explore the CMS-0057-F series
- CMS-0057-F Explained: Requirements and 2027 API Deadlines
- Da Vinci CRD Explained: Coverage Requirements Discovery
- Da Vinci DTR Explained: Questionnaires, CQL and Prior Authorization
- Da Vinci PAS Explained: FHIR Prior Authorization and X12 278 (this article)
- CMS-0057-F Payer Architecture for Delegated Vendors
- CMS-0057-F API Testing: Inferno, Sandboxes and Evidence
Sources
- HL7 Da Vinci PAS 2.2.1 (current) and 2.1.0
- PAS subscription topic
- HL7 Subscriptions R5 Backport
- CMS FAQs on the HIPAA transaction enforcement discretion
- CMS Prior Authorization API FAQs
- CMS-0062-P proposed rule, Federal Register 2026-07205 (14 April 2026)
- X12 licensing and transaction sets
- Acentra Health FHIR sandbox
- Inferno test kits
- HL7 Foundry
- Burden Reduction reference implementations (HL7 Confluence)
- HL7-DaVinci GitHub: br-payer, br-provider, test-ehr, crd-request-generator, dtr, CDS-Library
- Health Samurai: CMS FHIR Connectathon 2026 results
- Medblocks, CMS-0057-F Explained (Sidharth Ramesh, YouTube)
- HHS announcement of enforcement discretion for the X12 278 prior authorization transaction, 28 February 2024 (linked from the CMS FAQ above).
