WellAuth - Prior Authorization for Agents

WellAuth is prior authorization for the agent era: AI can gather evidence and move the case forward, but FHIR stays read-only and submission does not exist until a human approves it.

Comment

Inspiration

AI is splitting into two models: headless agents that work through APIs, and app-specific copilots built separately into every interface. WebMCP suggests a third model — a user can bring the same agent across applications, while each application still controls the capabilities it exposes.

I wanted to pressure-test that model somewhere the constraints actually matter. Healthcare was an obvious choice: clinical truth has authoritative sources, disclosure is sensitive, protocols are well established, and human responsibility cannot simply be delegated to a model.

Prior authorization brings all of those tensions together in one workflow. The clinical decision has already been made, but moving care forward still requires evidence from the record, payer-specific requirements, bounded disclosure, human approval, and coordination with an external payer.

WellAuth grew out of one question: can cross-application AI remove that friction without collapsing the boundaries healthcare depends on?

What it does

WellAuth uses WebMCP to let a browser agent work through a prior-authorization case while the application controls what actions are available at each stage.

1. Find the evidence without inventing it

Structured clinical data satisfies four of five payer requirements. The fifth cannot initially be proven, so WellAuth leaves it unresolved rather than turning a retrieval failure into a clinical fact.

GPT Work can then use another authorized evidence path, find the missing support in an existing cardiology note, and bind that exact evidence to the exact payer requirement.

2. Complete does not mean allowed to send

Once all requirements are satisfied, WellAuth prepares a purpose-limited packet containing only the evidence needed for the authorization.

Submission still is not available. A workforce user must approve the exact prepared packet before the WebMCP submission capability appears.

3. Let new external state change what the agent can do

The simulated payer approves the authorization through September 12, but the MRI is scheduled for September 18.

The authorization succeeded. The care still isn’t administratively ready.

Only then does WellAuth expose a remediation capability. The agent prepares an administrative extension without changing the ordered service, clinical evidence, or clinical intent, stops for a second human approval, and then submits the approved remediation.

The simulated payer extends the window through October 3, covering the scheduled date.

How WebMCP powers WellAuth

Point WebMCP role Product consequence
Structured tools across the prior-auth lifecycle WellAuth exposes actions such as discovering requirements, finding evidence, preparing a packet, submitting, checking status, and resolving an authorization window as structured tools—not as DOM clicks tied to one screen. GPT Work can reason across the whole job, including actions that would otherwise live on different views or at different moments in the UI, without being scripted through a fixed click path.
Tool access follows workflow state and human approval WellAuth dynamically registers and removes tools as the case changes. In particular, payer-submission tools are absent until the application records approval of the exact packet. Human approval changes what the agent can actually do. Submission is not merely hidden behind a warning or prompt instruction; the tool is unavailable until approval exists.
The application publishes the capability contract WellAuth defines the tool names, schemas, allowed lifecycle, and backend validation; GPT Work discovers and chooses among those capabilities from natural-language intent. The intelligence can come from outside the healthcare application while WellAuth keeps control of its workflow vocabulary and boundaries—the pattern that makes a user-selected agent viable across WebMCP-enabled applications.
Fit into regulated workflows without adding a new trust problem WellAuth keeps FHIR as the authoritative clinical-data path and uses WebMCP for bounded agent actions around that existing stack. In regulated industries, productivity gains are not worth it if adopting an agent creates a new compliance or control surface. This pattern lets WebMCP work with established protocols and boundaries instead of asking teams to weaken them.

How we built it

WellAuth is built as a bounded prior-authorization pipeline where each layer owns a different kind of truth or responsibility.

1. Read the clinical record

WellAuth reads FHIR R4 data from Google Cloud Healthcare API to locate evidence already present in the chart. That path is read-only, so the agent can search farther but cannot create or alter clinical facts.

2. Build and govern the case

A Cloud Run provider service maintains the authoritative authorization state: payer requirements, evidence bindings, packet revisions, approvals, submission status, and remediation.

Exact evidence is attached to exact requirements, and every mutation is validated against the current workflow revision.

3. Expose the right agent actions

That workflow state drives the WebMCP capability surface. GPT Work discovers 11 structured tools and can chain them from natural-language intent, but the available set changes as the case progresses.

Preparation can appear after evidence is complete; submission remains absent until human approval; remediation appears only after the payer creates a new mismatch.

4. Cross the payer boundary

Human approval is recorded separately from transmission and bound to the exact packet being reviewed. Only then can WellAuth send to the separate simulated payer.

The payer’s response is not treated as a frontend success flag—it becomes external state that can reopen the workflow.

The result is a simple architecture rule: FHIR owns clinical truth, WellAuth owns workflow state, WebMCP exposes current agent capability, and humans retain the consequential decisions.

Challenges we ran into

  • Making WebMCP behavior predictable — Dynamic registration, withdrawal, and invocation had to be validated in native Chrome. We built a browser acceptance harness and treated tool lifecycle as runtime state.

  • Fitting agents into healthcare’s existing trust model — FHIR needed to remain the clinical source of truth. We used Google Cloud Healthcare API for read-only FHIR access and kept prior-authorization workflow state separately authoritative.

  • Making “not available yet” real — Submission tools had to stay unavailable until human approval. We synchronized browser capabilities, workflow revisions, and backend validation so tool access reflects the case’s current state.

Accomplishments that we’re proud of

  • Making dynamic WebMCP part of the product — WellAuth changes which tools are exposed as the case progresses, and we validated that behavior in GPT Work and native Chrome.

  • Completing a full prior-authorization loop — The workflow goes from evidence discovery through human-reviewed submission, payer response, authorization-window mismatch, and remediation.

  • Keeping regulated-data boundaries intact — FHIR clinical data, workflow state, human review, and payer interaction remain separate while the agent still gets meaningful work done.

What we learned

  • Learning prior authorization from scratch — I had never worked in prior auth before. Building WellAuth taught me how much of the difficulty comes from evidence, payer requirements, timing, and administrative coordination rather than the clinical decision itself.

  • Learning a new protocol and a new agent surface — WebMCP was new to me, and so was GPT Work. Using both together changed my understanding of what it means for an application to expose capabilities to an agent rather than build its own embedded copilot.

  • A new UX lens for agentic products — I started thinking less about “what buttons should the user click?” and more about what capabilities should exist at this moment, what should disappear, and when the human needs to take over.

What’s next

  • Connect to real payer workflows — Replace the simulated payer with production-grade integrations and validate the same boundaries against real prior-authorization endpoints and operational constraints.

  • Expand beyond one authorization scenario — Support more services, payer requirement sets, evidence patterns, and remediation paths without turning the workflow into a generic healthcare copilot.

  • Test the WebMCP interaction model across more regulated workflows — Apply the same pattern to other healthcare and regulated processes where agents need useful freedom while applications keep control of data, workflow state, and human review.

Entirely synthetic demo data. Designed around HIPAA-regulated workflow boundaries; no claim of HIPAA compliance.

Built With

Share this project:

Updates

Submission history