Implement a FHIR-based prior authorization workflow end-to-end using Da Vinci PAS: submit the prior authorization request bundle, handle real-time pend responses, poll for final determination, and process approve and deny outcomes
Construct the PAS prior authorization request bundle containing a Claim resource (with use=preauthorization), referenced supporting resources (Patient, Coverage, Practitioner, Organization, ServiceRequest or DeviceRequest), and any required documentation attachments as DocumentReference resources
POST the bundle to the payer's FHIR $submit operation endpoint and handle the three possible immediate responses: approved (ClaimResponse with outcome=complete), denied (ClaimResponse with outcome=error), or pended (ClaimResponse with outcome=queued and a pending trace ID)
For pended responses, store the prior authorization trace ID from the ClaimResponse and implement a polling loop using the $inquire operation with the trace ID to check for final determination
Process the final ClaimResponse: extract the adjudication elements for approved services and quantities, denied line items with denial reason codes, and any partial approvals where only some requested services were authorized
Surface the determination to the clinical workflow: communicate approved auth numbers to downstream scheduling and claims systems, route denials to the appeals queue with reason codes, and alert clinicians to partial approvals requiring clinical review
Known gotchas
PAS requires the payer to have implemented the Da Vinci PAS server-side; as of current adoption, many payers route PAS requests to legacy X12 278 translation layers, so the FHIR response structure may reflect 278-to-FHIR conversion artifacts
The Claim resource in PAS uses insurance-specific extensions and claim type codes that differ from the standard Claim resource used in financial workflows; do not reuse a standard claims Claim resource for PAS without applying the PAS-specific profile
Polling intervals for pended PAS requests must respect payer SLAs; excessive polling may result in rate limiting, while insufficient polling delays clinical workflow; implement adaptive backoff based on payer-published response time guidelines
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp