Inspiration
Prior authorization is the most hated administrative process in US healthcare. Physicians and their staff spend nearly two business days every week preparing prior auth requests — hunting through clinical notes, navigating payer portals, and assembling documentation packages. In 2026, CMS mandates are tightening response timelines to 72 hours for urgent requests and 7 days for standard ones, making the need for streamlined submissions even more critical. I saw an opportunity to build an AI agent that doesn't just summarize data — it reasons about medical necessity, maps clinical evidence to specific payer requirements, identifies documentation gaps, and produces a complete, reviewable authorization packet. This is exactly the kind of complex, multi-step clinical workflow where generative AI shines and rule-based software falls short.
What it does
PriorAuth Pilot is a healthcare AI solution built on the Prompt Opinion platform that automates the prior authorization preparation workflow end-to-end. It combines: An MCP Server ("PriorAuth Toolkit") exposing 4 specialized healthcare tools:
GetPatientSummary — Pulls demographics, insurance, conditions, medications, and allergies from FHIR ExtractClinicalEvidence — Gathers clinical notes, observations, diagnostic reports, and procedure history relevant to the requested procedure CheckPayerRequirements — Returns the specific documentation checklist for a procedure/payer combination, including required evidence items and turnaround expectations AssembleAuthPacket — Combines all gathered information into a structured, submission-ready prior authorization packet
An A2A Agent ("PriorAuth Pilot") configured within Prompt Opinion that orchestrates the full workflow:
Retrieves the patient's clinical picture via FHIR Checks what documentation the payer requires for the specific procedure Extracts relevant clinical evidence from the patient's records Analyzes evidence against each payer requirement (MET / NOT MET) Generates a medical necessity assessment citing specific clinical findings Produces a complete authorization packet with a clinician review checklist
Demonstrated across two clinical scenarios:
Spinal Surgery — Lumbar laminectomy (CPT 63047) for a 46-year-old with severe L4-L5 stenosis, 14 months of failed conservative treatment including physical therapy and epidural injections GI Endoscopy — Upper GI endoscopy with biopsy (CPT 43239) for a 32-year-old with refractory GERD, alarm symptoms (dysphagia + weight loss), and family history of Barrett's esophagus
How we built it
MCP Server (TypeScript): Built on top of the po-community-mcp reference repository from Prompt Opinion. Used the existing FHIR client, SHARP header utilities, and tool registration pattern. Added 4 new tools that query FHIR resources (Patient, Condition, Coverage, MedicationRequest, AllergyIntolerance, DocumentReference, Observation, DiagnosticReport, Procedure) and a payer rules knowledge base covering 5 procedure types. SHARP Compliance: The MCP server declares fhir_context_required: true in its capabilities. When Prompt Opinion passes the SHARP headers (X-FHIR-Server-URL, X-FHIR-Access-Token, X-Patient-ID), the tools use these to authenticate FHIR queries back to the workspace's FHIR server. A2A Agent: Configured directly within the Prompt Opinion platform (no-code) with a custom system prompt that orchestrates the 4 MCP tools in sequence, a defined A2A skill for "Prior Authorization Preparation," and FHIR context extension enabled. Clinical Data: Created realistic synthetic clinical documents (office visit notes, radiology reports, physical therapy records, pain management notes, lab results) and uploaded them to patient records in the workspace. Deployment: MCP server deployed to Render for a persistent URL, registered in the Prompt Opinion workspace with FHIR context passthrough enabled. Tech Stack:
TypeScript, Node.js MCP SDK (@modelcontextprotocol/sdk) FHIR R4 (@smile-cdr/fhirts) Express.js with Streamable HTTP transport Prompt Opinion Platform (agent configuration, A2A, FHIR server) Render (cloud deployment) SHARP on MCP specification
Challenges we ran into
Port conflicts: macOS AirPlay Receiver uses port 5000, which conflicted with the MCP server. Switched to port 3001 during development. ngrok host restrictions: The reference MCP server has an allowedHosts whitelist that blocked ngrok connections. Removed the restriction for development and deployed to Render for production. FHIR data modeling: Understanding which FHIR resources to query and how clinical documents are stored (DocumentReference with base64-encoded content) required careful exploration of the workspace's FHIR server. Cross-specialty generalization: Building payer requirement rules that work across different medical specialties (spine surgery, gastroenterology, orthopedics, cardiology, radiology) while remaining clinically accurate.
Accomplishments that we're proud of
The agent correctly extracts specific clinical findings from unstructured notes — citing exact measurements (7.2mm canal diameter), scores (ODI 56%), and treatment timelines (14 months of failed conservative treatment) Works across completely different clinical domains without any code changes — the same tools handle spine surgery and GI endoscopy The evidence checklist shows MET/NOT MET status for each payer requirement with supporting clinical details — exactly what a clinician needs to review before signing Built both an MCP server (Superpower) AND an A2A agent (Superhero), demonstrating the full interoperability vision of the platform
What we learned
The SHARP on MCP specification elegantly solves the healthcare context propagation problem — passing FHIR credentials through HTTP headers means tools can query patient data without managing authentication themselves Building on open standards (MCP + A2A + FHIR) creates genuine composability — any agent on the platform can use these tools without custom integration The Prompt Opinion platform's no-code agent configuration significantly reduces the barrier to building healthcare AI workflows Prior authorization is an even bigger problem than I initially understood — the combination of clinical complexity, payer variability, and administrative burden makes it a perfect target for AI-assisted workflows
What's next for PriorAuth Pilot
Payer-specific rules: Expand the requirements knowledge base with real payer-specific documentation requirements and auto-approval criteria Appeal support: When a prior auth is denied, the agent could analyze the denial reason, identify additional evidence, and draft an appeal letter Multi-agent collaboration: Connect with other MCP tools on the Prompt Opinion marketplace (e.g., clinical coding tools, scheduling tools) to create a complete end-to-end authorization-to-scheduling workflow Real-time status tracking: Add tools that check authorization status and alert clinicians when action is needed
Built With
- express.js
- fhir-r4
- google-gemini
- mcp-sdk
- node.js
- prompt-opinion-platform
- render
- sharp-on-mcp
- typescript
Log in or sign up for Devpost to join the conversation.