ClearPath — Prior Authorization Autopilot

Inspiration

Picture this: A 70-year-old patient is living with chronic back pain so severe she can't sit for more than 20 minutes. Her physician has tried everything physical therapy, chiropractic care, opioid pain management. The next logical step is an MRI to rule out a herniated disc or spinal stenosis. Her physician knows it. The patient knows it. But before that scan can happen, an insurance company needs to agree.

So the physician stops treating patients and starts filling out forms.

The American Medical Association estimates physicians spend an average of 14 hours per week on prior authorization paperwork alone. 94% of physicians report that PA delays in care. 33% say those delays have led to serious patient harm. And when a PA is denied which happens to roughly 1 in 10 requests the appeal process is entirely manual: a physician writing a letter, citing clinical guidelines, arguing against a faceless algorithm, and waiting again.

This is not a niche problem. It is one of the most universal, costly, and preventable sources of harm in American healthcare. And it has remained unsolved because the solution requires something rule-based software cannot do: clinical reasoning.

We built ClearPath because we believe generative AI, multi-agent coordination, and open health data standards have finally made a real solution possible not a form-filler, not a template engine, but a system that reads a patient's clinical history, understands what a payer actually requires, and produces the right document the first time.

What It Does

ClearPath is a four-agent A2A prior authorization automation system built on FHIR R4, MCP, and Prompt Opinion's agent platform.

A clinician submits a single natural language prompt patient ID, payer name, and requested procedure. Four AI agents coordinate automatically to:

Retrieve the patient's full clinical record from a FHIR R4 server
Evaluate that record against the specific payer's authorization criteria
Reason — producing a transparent clinical justification for the decision
Generate the appropriate document: a PA request, an appeal letter, or a targeted information request to the ordering physician

To validate the system end-to-end, we put ClearPath through three distinct prior authorization scenarios, each designed to represent a different outcome a real PA workflow must handle:

Scenario	Patient	Payer	Outcome
MRI Lumbar Spine	James Morrison	Aetna PPO	✅ Approved — PA letter generated
Humira for Rheumatoid Arthritis	Maria Santos	UnitedHealthcare Choice Plus	🧠 AI overrides denial — contraindication exception identified
Nuclear Stress Test	Tomás Casares	Humana Medicare Advantage	⚠️ Incomplete — physician info request drafted

The AI Factor — Why This Isn't a Rule Engine

The most important thing ClearPath does is the thing that is hardest to explain with a bullet point: it reasons.

Consider Maria Santos. She has Rheumatoid Arthritis. Her payer — UnitedHealthcare — requires a second DMARD trial before approving a biologic like Humira. A rule-based system would evaluate the record, find no Leflunomide or Sulfasalazine in the medication history, and deny the request.

ClearPath does something different.

It reads the full clinical record. It finds elevated liver enzymes (ALT 58 U/L) that contraindicate Leflunomide — a fact buried in an observation resource, not a condition code. It finds a documented sulfa allergy that rules out Sulfasalazine. And it produces this reasoning:

"While payer guidelines generally necessitate a second DMARD trial before initiating biologic therapy, the clinical record clearly documents contraindications that preclude this: elevated ALT makes Leflunomide hepatotoxic, and a documented sulfa allergy prevents the use of Sulfasalazine. The clinical evidence supports immediate escalation to biologic therapy."

The system approved the request correctly because it understood why the step therapy protocol couldn't be completed, not just that it hadn't been. That is clinical judgment. That is what 14 hours of physician paperwork per week is currently paying for. And that is what ClearPath automates.

Architecture

ClearPath is a four-agent A2A system deployed on Prompt Opinion, backed by three Python MCP servers.

Agent Layer (A2A)

┌─────────────────────────────────────────────────────┐
│              CLEARPATH ORCHESTRATOR AGENT           │
└────────────────────┬────────────────────────────────┘
                     │ A2A coordination
         ┌───────────┼───────────┐
         ▼           ▼           ▼
  ┌─────────────┐ ┌───────────┐ ┌──────────────────┐
  │   Patient   │ │   Payer   │ │    Document      │
  │   Records   │ │   Rules   │ │   Generation     │
  │    Agent    │ │   Agent   │ │     Agent        │
  └──────┬──────┘ └─────┬─────┘ └────────┬─────────┘
         │              │                │
   FHIR R4 Server  Criteria Engine   Gemini Flash
   (conditions,    (payer rules,      (appeal letters,
    meds, labs,     step therapy,      PA requests,
    encounters)     confidence score)  info requests)

ClearPath Orchestrator is the clinical reasoning engine. It delegates retrieval, evaluation, and documentation to specialist agents but it synthesizes their outputs with genuine medical reasoning, identifying nuances and exceptions that structured data alone cannot surface. Every response includes an explicit Clinical Reasoning section that makes its decision-making transparent and auditable.

Patient Records Agent retrieves and normalizes FHIR R4 clinical data. Its flagship tool get_prior_auth_summary assembles a complete clinical package across six resource types (Patient, Condition, MedicationRequest, Procedure, Observation, Encounter) in a single parallel call using asyncio.gather.

Payer Rules Agent is intentionally deterministic no LLM. It evaluates structured patient data against a payer criteria database using keyword matching across FHIR fields, returning a precise breakdown of met, unmet, and unverifiable criteria with a confidence score. Determinism here is a feature: in a regulated healthcare workflow, every authorization decision must be reproducible and explainable.

Document Generation Agent turns structured clinical data into finished documents. Appeal letters are written by Gemini Flash with a clinician-voiced prompt that addresses the denial reason directly, cites the patient's treatment history, and references applicable clinical guidelines. A template fallback ensures the workflow never blocks if the LLM is unavailable.

MCP Server Layer

Three FastMCP servers deployed on Render, each owning a distinct layer:

MCP Server	Key Tools	Backend
Patient Records	`get_prior_auth_summary`, `get_patient_conditions`, `get_patient_medications`, `get_patient_observations`	HAPI FHIR R4
Payer Rules	`evaluate_criteria`, `get_auth_criteria`, `check_auth_requirements`	Structured rules database
Document Generation	`draft_prior_auth_request`, `draft_appeal_letter`, `draft_info_request`	Gemini Flash + template fallback

Data Flow

Natural language prompt
        │
        ▼
Orchestrator → Patient Records Agent → FHIR Server
                      │
                      ▼ (structured clinical summary)
Orchestrator → Payer Rules Agent → Criteria Engine
                      │
                      ▼ (approve / deny / incomplete + reasoning)
Orchestrator → Document Generation Agent → Gemini Flash
                      │
                      ▼
Clinical Reasoning + Decision + Submission-Ready Document

How We Built It

FHIR Backend

We deployed a HAPI FHIR R4 server in Docker and populated it with 198 synthetic patients generated by Synthea. From that pool, we handpicked three patients whose clinical profiles were a natural fit for each PA scenario the right diagnoses, the right medication history, the right edge cases. We then uploaded those patient records directly to Prompt Opinion, where they became the foundation for all three end-to-end demo runs.

The MCP Servers

All three servers are built with FastMCP in Python and deployed on Render. The Patient Records MCP resolves its FHIR server URL dynamically from SHARP context headers (X-FHIR-Server-URL, X-Patient-ID, X-FHIR-Access-Token), making it deployable against any FHIR-compliant backend without code changes.

The Payer Rules MCP was designed to be deliberately non-generative. Authorization decisions in healthcare need to be auditable and reproducible. An LLM-based evaluator would introduce non-determinism into a compliance-sensitive decision. Keyword matching against structured FHIR fields gives us exactly what we need: consistent, explainable, challengeable outputs.

Prompt Engineering as Engineering

The hardest bugs we fixed weren't in the Python code. They were in the prompts. Getting the Orchestrator to delegate reliably rather than answer from its own knowledge required discovering that A2A routing on Prompt Opinion is name-triggered agents must be explicitly named in the system prompt and consultation prompt for calls to fire. Getting the Payer Rules evaluation to correctly handle the encounters field required fixing a subtle bug where encounter count was being stored as a string rather than searchable text causing every physician visit check to silently fail.

Challenges We Ran Into

. Getting A2A calls to fire reliably The Orchestrator would sometimes answer from its own knowledge rather than delegating to specialist agents. The fix was to explicitly name each agent in the system prompt and in the consultation prompt A2A routing on Prompt Opinion is name-triggered, not intent-inferred. This was a subtle but critical prompt engineering discovery.

. Patient ID reassignment on import Prompt Opinion reassigns patient IDs when FHIR bundles are imported. Any hardcoded ID in a prompt or test script became invalid after each import. We built a strict tracking discipline — always noting the new platform-assigned ID immediately after import — to keep all three demo scenarios reliably in sync.

The Scenario 2 Outcome Surprised Us

Maria Santos's case was originally intended to end in a denial followed by a Gemini-generated appeal letter.

Instead, the Orchestrator analyzed the patient's clinical record, identified documented contraindications to alternative DMARD therapies, and approved the request correctly on the first pass.

We intentionally kept this result.

It became the strongest demonstration of ClearPath's core insight:

A rule engine can verify whether a protocol was completed.
An AI reasoning system can understand why it could not be completed.

That distinction is the difference between automation and clinical judgment.

What We Learned

Treat agent prompts like API contracts. The reliability of a multi-agent system lives or dies in its system prompts. Every ambiguity in a prompt becomes unpredictable behavior at runtime. The discipline we developed was simple: define exactly what each agent does, define exactly what it doesn't do, and never let those boundaries overlap. That precision is what made A2A delegation consistent and trustworthy across all three demo scenarios.

For compliance-sensitive decisions, determinism is a feature, not a limitation. The temptation in an AI hackathon is to use an LLM everywhere. We made a deliberate choice not to — the Payer Rules Agent uses structured keyword matching, not a generative model, for the authorization decision. In a healthcare workflow, every denial and every approval needs to be explainable to a physician, a payer, and potentially a regulator. Reproducibility isn't a constraint we worked around; it's a design requirement we embraced.

In healthcare AI, the fallback is part of the product. Gemini going down is not a hypothetical. We treated every AI-dependent step as a potential failure point and built a non-generative fallback behind each one. A system that fails gracefully in production is more valuable than one that performs brilliantly in a demo and breaks when it matters.

The real value of AI in this workflow is synthesis, not retrieval. Pulling FHIR data is a solved problem. Matching keywords against a criteria list is a solved problem. What remained unsolved — and what ClearPath addresses — is the layer between those two steps: reading a patient's complete clinical story, connecting evidence across disparate resource types, and producing reasoning that a clinician can actually stand behind. That's where generative AI earns its place in this stack.

What's Next

SMART on FHIR OAuth integration for live EHR connectivity
Expanded payer and procedure coverage — the current MCP covers 3 payers and 10 procedures; production requires hundreds
Full audit trail and compliance logging — every decision logged with the complete evidence chain that produced it
Denial pattern analytics — aggregate unmet criteria across patients to surface systemic payer policy issues and inform proactive documentation practices
Real-time payer portal integration — submit PA requests directly to payer APIs, eliminating the final manual step