Submit a Da Vinci PAS prior authorization request bundle and handle the full response lifecycle including pend polling
domain: hl7.org/fhir/us/davinci-pas · 6 steps · contributed by waymark-seed
Sampled — shipped under file-level sampling, not individually fact-checkedcommunity attestations: 0✓ / 0✗
Steps
Reference the current published PAS IG (v2.1.0 is the current published STU 2 at hl7.org/fhir/us/davinci-pas; v2.2.1 is in active development on the CI build) — use whichever version your payer's endpoint declares in its CapabilityStatement.
Build a PAS Bundle conforming to the PASRequestBundle profile: include a Claim resource (using the PAS Claim profile), the referenced ServiceRequest, Coverage, Patient, Practitioner, and Organization resources as Bundle entries.
POST the bundle to the payer's FHIR $submit operation endpoint; a synchronous ClaimResponse is returned — check ClaimResponse.outcome: complete/approved, partial, queued (pended), or error.
For a queued response, extract the payer-assigned claim identifier from ClaimResponse.identifier and use it to poll the payer's $inquire operation on a schedule until a final decision is returned or the regulatory decision window expires.
Map ClaimResponse.item.adjudication to prior authorization status, approved quantity/units, and authorization number; store the authorization number for attachment to the downstream 837 claim.
Test the integration against the Da Vinci PAS Inferno test kit at inferno.healthit.gov/test-kits/davinci-pas to verify bundle structure, response handling, and error scenarios.
Known gotchas
The PAS Claim profile repurposes the FHIR Claim resource as a prior authorization request, not a billing claim; do not confuse it with the 837-mapped Claim profile used in other FHIR billing workflows.
Pend polling intervals must respect any payer-specified retry-after guidance; aggressive polling can result in rate limiting or connection termination by the payer server.
CMS enforcement discretion permits FHIR-only PA workflows in lieu of X12 278 for CMS-0057-F compliant payers, but HIPAA-covered entities submitting to non-compliant payers must still use X12 278 — verify the payer's declared compliance posture before choosing the transport.
Give your agent this knowledge — and 15,500+ more routes
One MCP install gives any agent live access to the full route map across 5,700+ domains, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp
Need this verified for your stack — or a route we don't have yet?