AuthBridge

Prior authorization creates dangerous delays and endless paperwork. AuthBridge reads the FHIR record, matches payer criteria, and writes the clinical letter - in 30 seconds, not 5 days.

Comment

Inspiration

I've watched clinicians spend hours on prior authorization paperwork while patients wait days for medications they need right now. The numbers make it worse: $31 billion in annual administrative waste, 13 physician hours lost every week to PA forms, and 1 in 4 patients abandoning treatment because the approval never came in time. 40% of physicians say a patient has suffered serious harm from a PA delay. That's not a paperwork problem. That's a patient safety problem.

When I saw the Agents Assemble challenge, one thing became clear: MCP, A2A, and FHIR are finally mature enough to actually fix this, not just demo well at a conference. AuthBridge is my answer to that.

What it does

AuthBridge takes hours of manual chart review and generates a complete, evidence-grounded PA justification letter in under 30 seconds.

A clinician enters a patient ID and a drug name. AuthBridge pulls the patient's full FHIR clinical record, matches it against the payer's PA criteria, scores the clinical evidence, and writes a complete, payer-ready justification letter grounded in verifiable FHIR data. Every claim in the letter traces back to a specific FHIR resource ID, so the physician can trust what they're signing.

If the PA gets denied, AuthBridge generates a formal appeal letter that rebuts the denial point by point, cites published clinical guidelines, and demands peer-to-peer physician review.

Two additional tools round out the system: a self-audit agent that reads the generated letter and flags any claim that isn't traceable to the patient's actual record, and a plain-language patient summary for the portal so patients understand what's happening while they wait.

How I built it

The core is a FastMCP server written in Python, deployed on Render, and published to the Prompt Opinion Marketplace. Five foundational MCP tools handle the full PA lifecycle: fetch_patient_context, lookup_pa_criteria, score_clinical_match, draft_pa_letter, and draft_appeal_letter. Two unified workflow tools wrap them into single-call automations for production use.

For FHIR integration, I used httpx against the HAPI FHIR R4 public sandbox with asyncio.gather to fetch seven resource types in parallel, cutting data retrieval time by over 60%. All LLM calls go through the AsyncOpenAI client to keep the event loop responsive. Tenacity handles retries with exponential backoff so transient failures don't kill the workflow.

The generation layer uses an adversarial multi-agent debate loop: a Clinician Agent drafts the letter, a Payer Denial Agent attacks it for clinical loopholes, and the drafter has to neutralize every objection before the output reaches the clinician. No rule-based system can do that.

For security: strict regex sanitization on all patient IDs, slowapi rate limiting, and a simulated SMART on FHIR OAuth2 handshake that enforces patient/*.read scopes before any data is fetched.

The frontend is a single-page application with a four-step workflow: Request, Analysis, Clinician Review, Submission. Judges can run a live scenario and see the letter appear with evidence badges and urgency flags.

Note: SMART on FHIR OAuth2 integration was updated after the demo recording. Live Render deployment logs showing token acquisition and FHIR endpoint calls are available at: https://authbridge-eooi.onrender.com/health

Challenges I ran into

The biggest issue was rate limits on both sides. When I ran batch scenarios, the LLM would return 429s and the server would stall. I solved it with Tenacity retries and a semaphore to throttle concurrent LLM calls in the batch tool.

A subtler bug: my FHIR helper was swallowing all exceptions and returning empty arrays. That made Tenacity invisible because there was nothing to retry. Removing that catch-all was a two-line fix that unlocked the entire retry system.

The LLM also sometimes returned JSON wrapped in markdown code fences, which crashed my parser. I added a regex cleaner and a fallback dict to keep the pipeline alive regardless.

Accomplishments I’m proud of

The self-audit tool is the thing I keep coming back to. It reads the letter, reads the FHIR evidence trail, and flags any clinical claim that isn't directly traceable to a patient resource. That's the gap between an AI assistant and a tool a physician can actually trust in a clinical environment.

The CMS-0057-F urgency detection also matters: the system automatically identifies oncology and high-acuity biologic cases and adds the 72-hour expedited review header, aligned with the federal mandate that kicks in for payers by January 2027.

The load test runs 15 concurrent requests without crashing. The frontend is responsive. This is a system that could go into a real hospital today.

What I learned

Healthcare AI lives or dies on grounding. The model is only as useful as the structured data you feed it. Getting FHIR parsing right, handling missing fields without silent failures, and building an evidence trail that ties every clinical claim to a real resource ID was harder and more important than any prompt engineering.

I also learned that open standards actually work. MCP, A2A, and FHIR let me build something that isn't tied to a single EHR vendor or payer, which means any compliant system can pick it up and run it.

What’s next for AuthBridge

Real payer API integration via CoverMyMeds and the FHIR-based PA endpoints CMS is mandating. SMART on FHIR launch context so AuthBridge can be embedded directly inside Epic or Cerner. A clinic-facing dashboard to track PA turnaround times and approval rates. And a real-world pilot, because the system is ready for one.

Built With

Share this project:

Updates