Inspiration
A physician in the United States spends more than 10 hours every week on prior authorizations. Not treating patients. Filling out forms. Waiting on hold. Getting denied. We built AuthPilot to give that time back.
What it does
AuthPilot is a FHIR-native MCP server and A2A agent that handles prior authorization end to end inside the Prompt Opinion clinical workspace.
Four intelligent tools run in sequence:
get_patient_clinical_context — fetches the patient's complete clinical record from any FHIR R4 server concurrently — conditions, medications, labs, allergies, and coverage.
check_prior_auth_required — evaluates whether prior authorization is required and returns the exact payer criteria that must be satisfied, Da Vinci CRD-compatible.
build_clinical_justification — Gemini 2.5 Flash reads the patient's clinical story, maps each piece of evidence to each payer criterion, generates a medical necessity letter, assigns a confidence score, and flags every gap with a specific recommendation. This is what rule-based systems cannot do.
submit_prior_auth_request — constructs a FHIR Da Vinci PAS-compliant Claim bundle and submits it. Writes a DocumentReference and Provenance resource back to the patient record. Nothing stored outside FHIR. Nothing proprietary.
One gate separates Tools 3 and 4 — clinician confirmation. AuthPilot requires explicit human approval before any PA is submitted. AI handles the reasoning. The physician decides.
How we built it
The backend is a Rust + Axum MCP server deployed on Render. We chose Rust for type safety and performance — our FHIR client fetches 6 resource types concurrently using tokio::join! without blocking.
The MCP protocol handler was implemented from scratch, exposing all 4 tools with full JSON Schema input definitions that Prompt Opinion discovers, validates, and invokes natively.
FHIR R4 throughout — Da Vinci CRD, DTR, and PAS implementation guides. Every resource follows the correct profile: Claim with PAS IG extension, DocumentReference with LOINC code 57016-8, Provenance with agent attribution.
Gemini 2.5 Flash via Google AI Studio free tier. The prompt is engineered to cite specific FHIR resource IDs, map clinical findings to named payer criteria, and produce structured output that flows directly into the FHIR submission layer.
SHARP context propagation through Prompt Opinion means patient ID and FHIR token are injected automatically from the EHR session — zero manual input from the clinician.
Next.js 14 on the frontend, deployed on Vercel. Total infrastructure cost: $0/month.
Challenges we ran into
The biggest challenge was a conflict between Gemini's responseMimeType JSON generation config and Prompt Opinion's function-calling layer. When both were active simultaneously, the platform threw a schema conflict error. The fix was removing the MIME type constraint and relying on prompt engineering alone to produce structured JSON output.
Concurrent FHIR fetching introduced subtle race conditions in our Rust async runtime. tokio::join! handles the concurrency correctly but error propagation required careful handling — a single 404 from HAPI FHIR needed to fail gracefully rather than crashing the entire context fetch.
Building the MCP protocol handler from scratch in Rust meant reading the spec carefully — the JSON-RPC 2.0 envelope, tools/list and tools/call method dispatch, the initialize handshake — all implemented without a mature Rust MCP framework.
Accomplishments that we're proud of
AuthPilot passed Prompt Opinion's MCP tool discovery test on the first attempt — all 4 tools returned with green status.
We built a production-grade Rust MCP server at zero infrastructure cost. The human-in-the-loop gate is a first-class protocol feature — Tool 4 rejects any submission where clinician_confirmed is not explicitly true.
The gap detection in Tool 3 is what we're most proud of. When a patient's record shows 3 weeks of conservative therapy and the payer requires 6, AuthPilot tells the physician exactly what's missing and exactly what to do about it.
What we learned
FHIR is deceptively deep. Implementing it correctly — with the right profiles, the right codings, the right reference patterns — requires genuinely understanding the clinical intent behind each resource.
MCP is a genuinely elegant protocol. The simplicity of tools/list and tools/call belies how powerful the composition model is. AuthPilot's 4 tools can be assembled into any workflow any agent needs.
What's next for AuthPilot
Real payer CRD endpoint integration — connecting to live payer criteria databases replaces our rule engine with ground truth.
SMART on FHIR EHR launch context — an Epic or Cerner app that launches AuthPilot with the current patient pre-loaded.
A denial appeal agent — when a PA is denied, a second agent reads the denial reason and constructs the appeal.
Submission to Epic App Orchard and Cerner App Market.
Log in or sign up for Devpost to join the conversation.