Da Vinci PAS Explained: FHIR Prior Authorization and X12 278

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 the CMS prior authorization API requirement 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.

For how PAS sits after CRD and the SMART DTR launch, see the end-to-end FHIR prior authorization workflow.

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 $inquire for 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 $inquire can 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 $submit whose Claim carries the original request identifier in Claim.related with the update relationship, plus the changed items or added supporting information (§spec-65 and §spec-66).
• A cancel is a $submit with the cancel relationship (§spec-67 and §spec-68). The payer records the cancellation and responds with a ClaimResponse that says so.
• Claim/$inquire takes 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 CommunicationRequest for 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 updated that FAQ on 21 September 2026 and the enforcement discretion still stands.

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

1. 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.
2. 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.
3. The Acentra Health sandbox. Exposes $submit and $inquire on synthetic data with a 10 MB request cap, and issues a real pended-then-decided flow; use it for end-to-end timing.
4. 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.
5. 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.
6. 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.

An open-source PAS server, tested with Inferno

A working PAS server is the fastest way to see the bundle rules, the decision codes and the subscription flow in one place. Nirmitee publishes the open-source Da Vinci PAS server (Inferno results in the README) under the Apache 2.0 licence, written in Go and in .NET 10 with identical behaviour, serving PAS 2.2.1 and STU 2.0.1 side by side. Both implementations pass every test in the Inferno PAS server suites, including the approval, denial, pended and subscription-notification workflows.

The runs were on the public inferno.healthit.gov instance over HTTPS on 12 September 2026, and the README links each session. Inferno results are conformance evidence; CMS runs no certification program. The adjudication rules are synthetic: the server implements the FHIR surface a payer exposes, and in a payer rollout it sits in front of the payer's utilization-management system.

This is an approved line from a Claim/$submit response, taken from the repository's examples and trimmed to the item and its adjudication. All identifiers are synthetic.

{
  "resourceType": "ClaimResponse",
  "status": "active",
  "use": "preauthorization",
  "outcome": "complete",
  "preAuthPeriod": {
    "start": "2026-09-12",
    "end": "2026-12-11"
  },
  "item": [
    {
      "extension": [
        {
          "url": "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-itemPreAuthIssueDate",
          "valueDate": "2026-09-12"
        },
        {
          "url": "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-itemPreAuthPeriod",
          "valuePeriod": {
            "start": "2026-09-12",
            "end": "2026-12-11"
          }
        },
        {
          "url": "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-administrationReferenceNumber",
          "valueString": "ADMREF-PA-2026-0001-1"
        }
      ],
      "itemSequence": 1,
      "adjudication": [
        {
          "extension": [
            {
              "url": "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-reviewAction",
              "extension": [
                {
                  "url": "number",
                  "valueString": "AUTH-PA-2026-0001-1"
                },
                {
                  "url": "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-reviewActionCode",
                  "valueCodeableConcept": {
                    "coding": [
                      {
                        "system": "https://codesystem.x12.org/005010/306",
                        "code": "A1",
                        "display": "Certified in total"
                      }
                    ]
                  }
                }
              ]
            }
          ],
          "category": {
            "coding": [
              {
                "system": "http://terminology.hl7.org/CodeSystem/adjudication",
                "code": "submitted"
              }
            ]
          }
        }
      ]
    }
  ]
}

The decision is the X12 306 review action code the 278 already uses, carried in reviewAction on the item's adjudication: A1 is certified in total, A3 not certified (with a reason code), A4 pended and A6 modified. The authorization number sits next to the code, and itemPreAuthPeriod gives the window the approval is valid for. A pended line carries A4 instead, and the final decision reaches the provider through the subscription notification: a full-resource notification in 2.2.1, an id-only one in 2.0.1 followed by $inquire.

Which version to build to. CMS-0057-F recommends the Da Vinci guides rather than requiring a version, but the EHR side has already moved. The FY 2027 IPPS/LTCH final rule (published 4 August 2026, effective 1 October 2026) replaced the versions ONC certifies EHR modules against with CRD 2.2.1, DTR 2.2.0 and PAS 2.2.1, with no transition period. From October, an EHR certified for PAS speaks PAS 2.2.1, so a payer endpoint that serves only 2.0.1 will meet newer clients it cannot fully answer. The proposed CMS-0062-P would require payers to use the 2.2 guides as well. Serving both versions side by side, as the server above does, is the practical answer while clients upgrade.

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 $submit with 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.

The provider side: what a PAS client has to build

A PAS client, whether an EHR, a practice-management system or a prior-authorization vendor acting for providers, has a different problem from the payer. Every payer reads the guide a little differently, and the client has to absorb that variation so the clinician sees one workflow. Six components carry that load.

• A claim builder. It turns the order into a PAS Claim. use is always preauthorization and type is professional or institutional to match the setting; both are required. Each item points at the diagnoses that justify it through diagnosisSequence, which is what a reviewer reads for medical necessity, and every service code names its system: CPT for professional services, HCPCS for equipment and supplies, ICD-10-PCS for inpatient procedures.
• Validation before sending. A Claim that is valid FHIR R4 is not necessarily a valid PAS Claim. Validate the request bundle against the PAS profiles before it leaves, so a missing extension or an out-of-bundle reference shows up in your own logs instead of as a 400 from the payer.
• An attachment manager. Supporting documents travel in Claim.supportingInfo as DocumentReferences, inline or by reference. Payers differ on format (PDF, C-CDA or both) and on size limits, so the client needs rules for which documents to send per service and diagnosis. Too few invites a request for more information; too many slows the reviewer. The CRD response and the DTR QuestionnaireResponse are the best guide to what is actually wanted.
• A status tracker driven by subscriptions. It stores every submitted and pended request, registers the rest-hook subscription, updates the order when a notification lands, and uses $inquire only to recover a missed notification. Scheduled polling of a pended request is exactly what the guide forbids.
• A payer registry. For each payer: the CRD and PAS endpoints, OAuth client credentials, accepted attachment formats and limits, whether the payer takes FHIR end to end or through an intermediary, and known quirks. Every other component reads from it.
• A 278 route for payers outside the rule. CMS-0057-F binds Medicare Advantage organizations, state Medicaid and CHIP programs and their managed care plans, and qualified health plan issuers on the federally facilitated exchanges. Other lines of business may not offer PAS at all. Keep the X12 278 submission behind the same interface and let the registry pick the route, so the clinician's workflow does not change with the payer.

Test the client in layers: fixture bundles in unit tests, the Da Vinci reference implementation and the Inferno PAS client suites for structure and workflow, then each payer's sandbox for the behaviour no reference implementation can simulate.

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 our CMS-0057-F implementation services, 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 Implementation: 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).