Picture a national health insurer with around 8 million members, $15 billion in annual premium, and a prior-authorization unit processing roughly 40,000 requests a week across Medicare Advantage, commercial, and Medicaid lines. The company has already done the hard infrastructure work: claims, Electronic Medical Records (EMR) feeds, pharmacy data, and member records are integrated, cataloged, and sitting in a modern cloud warehouse. Eighteen months ago, the company deployed an LLM-based assistant to help its 200-person utilization management team triage prior-auth requests faster. The assistant reads the request, pulls relevant members and claims history, and recommends approve, deny, or escalate-to-clinical-review.

The pilot looked strong. In production, the assistant’s recommendation disagreed with the human reviewer’s final decision often enough that the health plan’s compliance team flagged it during a routine audit; not because the assistant was reasoning badly, but because it was confidently merging records that didn’t actually belong to the same clinical episode. That’s not a model problem. It’s an architecture problem, and it’s worth being precise about the distinction, because the fix is different.

How can AI-powered prior authorization address this problem? Let’s discuss.

Where a traditional prior authorization platform  architecture falls short

This insurer’s prior-authorization, claims adjudication, and care management workflows all sit on top of five source systems built independently, by different vendors, over roughly fifteen years: a claims platform, a clinical/EMR data feed from network providers, a pharmacy benefit manager feed, a member enrollment system, and a utilization-management case tool. Each encodes “member,” “claim status,” and “accumulator” slightly differently. The claims platform tracks a procedure by Current Procedural Terminology (CPT) code and authorization status. The EMR feed tracks the same clinical event by encounter and diagnosis. The pharmacy feed tracks it by NDC code and fill date. None of these systems were designed to agree with each other, because for fifteen years a human analyst did the reconciliation by hand before any decision got made.

Generative AI removes the human from that loop, which is exactly the problem. An LLM connected directly to these systems via Retrieval-Augmented Generation (RAG)  will retrieve documents and generate an answer regardless of whether the underlying entities actually resolve to the same thing. Ask it whether a member is due for a covered procedure, and it can confidently merge a claims record for one encounter with an EMR record for a different one, because nothing in the architecture told it these were different events. The output reads fine. It’s wrong. And because there’s no entity resolution layer underneath the model, there’s no way to trace why.

This is the core technical failure mode behind traditional, hallucinated AI-enabled prior authorization tools , misapplied benefit rules, and inconsistent KPI reporting across business units; not a model limitation, an absence of a governed semantic layer between the data and the AI consuming it.

What the fix actually requires

Solving this is not a prompt engineering exercise. It requires four distinct technical components, each solving a different part of the problem:

Entity resolution across heterogeneous schemas. Before any AI system can reason about a “member” or a “claim,” every source system’s representation of that entity needs to be mapped to a canonical model. This is graph construction work, not data cleaning. It requires identifying relationships (a claim belongs to an encounter, an encounter belongs to a member, a member has a set of active benefits at a point in time) and encoding them as traversable structure, not flat tables.

A governed business vocabulary. Once entities resolve, the organization needs one definition of what each term means. “Active member” cannot mean one thing in the claims system and another in the member portal. This sounds like a glossary exercise; in practice it’s a taxonomy and ontology problem, because most disputed terms (accumulator, episode of care, prior auth status) carry implicit business rules that need to be modeled explicitly, not just defined in a document nobody reads.

Lineage and validation on every derived fact. An AI-generated answer about benefit eligibility is only auditable if you can trace it back through the entity resolution and the governed definition to the original source record, with a timestamp. Without this, compliance review of any AI-assisted decision becomes a manual forensic exercise, which defeats the purpose of automating the decision in the first place.

Persistent context across multiple agents. This insurer isn’t running one AI use case; it’s running three (prior auth, care gap detection, a member-facing benefits chatbot) built by three different teams over two years. Without a shared knowledge layer, each one rebuilt its own partial understanding of the same entities, and they’ve drifted from each other ever since. A multi-agent environment without shared memory is just multiple inconsistent answers running in parallel.

Next, let’s discuss how Agentic AI can automate prior authorization for healthcare providers.

How Wingspan’s Semantic Twin addresses each layer

This is precisely the architecture that Onix’s Agentic AI platform, Wingspan is built to provide, mapped directly to the four problems above.

Eagle performs the entity resolution work automatically. It scans EMR, claims, pharmacy, and member systems, identifies how entities relate across schemas, and constructs the knowledge graph without a manual mapping exercise. For a domain like clinical entity resolution, this is typically a multi-month effort when done by hand; Eagle compresses it into weeks because it’s discovering structure from the data itself rather than waiting on a team to document it.

Enterprise Context Layer (ECL) becomes the governed vocabulary layer, holding the canonical definitions and the taxonomy that encodes the business rules underneath terms like “active member” or “prior auth approved.” Every system and every agent reads from the same definition, so the same question produces the same answer regardless of which application asked it.

Enterprise Knowledge Engine (EKE) maintains the knowledge graph as a living structure, not a one-time export. It auto-refreshes as new claims and clinical events arrive, keeps lineage on every entity and relationship, and acts as the persistent memory layer multiple agents can share. A care-gap agent and a prior-auth agent both draw from the same underlying graph instead of building their own.

Pelican sits on top of all of it doing validation, producing the lineage trail that turns an AI-generated answer into something a compliance reviewer can actually audit back to source, which is the difference between explainable AI and a black box that happens to be usually right.

Agentic AI in healthcare – what this looks like in practice

Apply this Wingspan stack to the prior-authorization assistant itself, and the requirements get specific fast: day-one accuracy above 85% against the human reviewer’s decision, sub-minute response latency so the utilization-management team isn’t waiting on the tool, and a cost structure that survives 200 reviewers running queries all day without turning into an LLM token bill nobody wants to defend.

In a comparable conversational-analytics deployment over claims and clinical data, with those same three constraints, putting a Semantic Twin under the model moved accuracy from 85% to roughly 95%, cut latency from around three minutes to under one, and brought per-query cost down from $0.53 to $0.08. None of that came from a better model. It came from giving the model a governed structure to reason against instead of raw, ungoverned documents.

That’s the pattern worth generalizing: the bottleneck in enterprise AI accuracy is rarely the model. It’s almost always the absence of a semantic layer between the model and the data it’s reasoning over.

If this is the architecture problem you’re actually solving

If your prior-auth AI is accurate in testing and inconsistent in production, or your care-gap and member-chat agents quietly disagree with each other about the same member, the underlying issue is structural, not a tuning problem. Designed for delivering AI applications in healthcare, Wingspan’s Semantic Twin builds the entity resolution, governed vocabulary, lineage, and shared memory layer this requires, in weeks rather than the multi-quarter ontology programs most insurers assume this takes.

Looking for the right AI-powered prior authorization automation platform in the healthcare domain? Learn more about Wingspan or book a demo to see how the Semantic Twin maps to your existing systems.