AuthArmor

• 

  Agent chat showing the appeal response

• 

  MCP pipeline terminal logs

• 

  Citations view with FHIR references

• 

  Architecture diagram

Inspiration

Prior Authorization costs American healthcare $35 billion annually. Every time a doctor prescribes a medication or procedure, insurance may deny it — requiring a detailed appeal letter proving "medical necessity." Each appeal takes an average of 17 minutes of physician time, and the AMA reports it is the #1 cause of physician burnout. 34% of physicians say PA delays have led to serious adverse events for their patients.

We saw an opportunity: payer criteria are unstructured and vary by plan, making them a perfect target for Generative AI. But standard AI approaches hallucinate clinical evidence — producing appeals that are factually wrong and can't survive scrutiny. We built AuthArmor to solve this with a citation-driven approach where every claim is traceable to a real medical record.

What it does

AuthArmor is an MCP server that gives any AI agent in the Prompt Opinion ecosystem the superpower to handle prior authorization appeals. It exposes three tools:

The workflow:

1. Read — Via SHARP context propagation, AuthArmor reads the patient's FHIR record: medication history, diagnoses, lab results, and prior procedures.
2. Search — The engine searches payer policy documents to find the exact coverage criteria for the denied procedure or medication.
3. Cite — Gemini AI drafts a formal appeal letter where every clinical claim is cited to a specific FHIR resource ID. If the appeal states "Patient failed methotrexate therapy," it cites MedicationStatement/88492 with the exact dates and dosage from the medical record.

This citation-driven approach makes AuthArmor hallucination-proof — every statement traces back to a real medical record entry, and missing evidence is explicitly flagged rather than fabricated.

How I built it

AuthArmor is built as a TypeScript MCP server on Express.js, following the Streamable HTTP transport spec. It integrates with the Prompt Opinion platform using SHARP Extension Specs for FHIR context propagation — receiving the patient's FHIR server URL, access token, and patient ID via HTTP headers.

The appeal generation pipeline uses Google Gemini AI with a carefully crafted system prompt that constrains the LLM to only cite evidence found in the patient's actual FHIR bundle. The server processes FHIR R4 resources (MedicationRequest, ClaimResponse, MedicationStatement, Condition, Observation) and formats them into structured clinical evidence for the LLM.

The entire project uses synthetic FHIR data to ensure full HIPAA compliance — no real patient data is ever used or stored.

Key stack:

• TypeScript + Express — MCP server with Streamable HTTP transport
• SHARP Extension Specs — Patient context propagation from Prompt Opinion
• Google Gemini AI — Citation-constrained appeal generation
• FHIR R4 — Standardized clinical data model
• Docker — Containerized deployment
• Jest — 102 tests, 100% statement/function/line coverage

Challenges I ran into

The hardest challenge was designing the citation constraint system. Getting the LLM to only reference actual FHIR resources — and to explicitly admit when evidence is missing rather than making something up — required careful prompt engineering and structured output formatting. We iterated through multiple prompt versions before landing on an approach that reliably produces auditable, citation-backed appeals.

Another challenge was implementing the SHARP-on-MCP pattern correctly. The SHARP Extension Specs are relatively new, and integrating FHIR context propagation through HTTP headers while maintaining the MCP protocol's tool-calling semantics required careful coordination between the transport layer and the business logic.

Accomplishments that I'm proud of

• Zero hallucination by design — Every clinical claim in the appeal letter maps to a specific FHIR resource ID. The LLM cannot fabricate evidence because the system prompt constrains it to only cite resources present in the patient's bundle.
• 102 unit tests with 100% coverage — The entire server, including the FHIR client, appeal generator, and MCP transport layer, is fully tested.
• Production-ready architecture — Dockerized, environment-configurable, with proper error handling and logging. This isn't a prototype — it's built to deploy.

What I learned

• The SHARP Extension Specs unlock a powerful pattern for healthcare AI: agents don't need hardcoded patient APIs — they receive context through standardized headers, making tools composable and reusable across different EHR systems.
• Citation-constrained LLM generation is more reliable than post-hoc fact-checking. By structuring the evidence before the LLM sees it, we can guarantee traceability rather than hoping for it.
• The MCP + Prompt Opinion marketplace model makes healthcare AI tools genuinely composable — any agent can pick up AuthArmor without custom integration work.

What's next for AuthArmor

• RAG engine — Semantic search over large payer policy PDFs using pgvector, so AuthArmor can handle any insurer's criteria, not just pre-loaded policies.
• Multi-scenario support — Expand beyond the current RA/Humira scenario to cover oncology, cardiology, and mental health prior authorizations.
• Real-time appeal tracking — Status dashboard showing appeal submission, payer response, and outcome analytics.
• FHIR write-back — Post the completed appeal as a DocumentReference back to the patient's chart for audit trails.

Built With

• docker
• express.js
• fhir
• gemini-ai
• mcp
• node.js
• sharp
• supabase
• typescript