Why Patient Navigation Needs a Different Kind of LLM.

Your health system is already using general-purpose AI models to create clinical summaries and guide patient intake conversations. So, layering the same models on top of your scheduling infrastructure is the logical next step, right?

Not so fast.

Frontier large language models (LLMs) perform well for document extraction and tasks where a human reviews the output before anything happens. But patient navigation isn’t that type of task. It requires models that can evaluate each patient’s acuity, urgency, location, and insurance, then select the right provider and care setting based on real-time availability. The models powering these high-stakes decisions must be able to do one thing reliably, every time, in less than half a second.

General-purpose LLMs, built for breadth, aren’t designed for that kind of narrow, repeatable, high-stakes execution. But purpose-built small language models (SLMs), each trained on one navigation task and running within your health system’s own infrastructure, can deliver it. Let’s see why.

LLMs can’t ‘guess’ their way through a decision tree

Most health systems’ scheduling infrastructure includes thousands of decision trees embedded within the EMR. Each one includes dozens of rules governing which conditions get routed to which specialty, which specialties have sub-specialty constraints, and which locations accept which insurance panels.

When a general-purpose LLM is unleashed inside a decision tree, it reasons the rules rather than executing them. In other words, it makes the best guess. Each wrong “guess” leads to a missed appointment or a delayed diagnosis. Patient schedulers have to call patients back and offer to reschedule with the right provider, assuming they’re willing to reschedule with the health system at all.

LLMs create real-world navigation failures

In our work with health systems at DexCare, we’ve seen the negative consequences that happen when organizations attempt to layer general-purpose LLMs onto their patient access infrastructure. The failures cluster in three patterns.

1.) Consistency. LLMs return different slot recommendations for identical clinical inputs. Health systems often learn this the hard way, after a pilot that looked great and broke in production.

2.) Latency. A general model’s first token may arrive quickly, but a complete, reasoned answer is another matter — and when you ask a frontier model to reason through routing rules rather than execute them, response times climb into seconds and vary from one call to the next. Multiply that across every decision point in an interaction, and waiting for LLMs to respond will cause call center wait times to grow, rather than shrink.

3.) Unit economics. A large health system handling 1 million scheduling-related interactions annually, each with an average of 8 to 10 API calls per interaction, runs 8 to 10 million API calls per year. At current frontier model pricing, that adds up to between $50,000 and $200,000 annually in inference alone, not including workflow integration, fine-tuning, compliance overhead, or support costs. Most vendors won’t tell you this in the pilot. Instead, the sticker shock hits just as your health system is ready to scale. A purpose-built SLM running on-premises, however, has low marginal inference cost once it’s deployed — the spend shifts from per-call API fees to fixed infrastructure you control.

SLMs aren’t just tiny LLMs

Purpose-built SLMs can solve the common failures associated with patient navigation because they’re built with an entirely different architecture.

Navigation SLMs are powered by 1-7 billion parameters, a fraction of the size of frontier LLMs and small enough to run on a single GPU server within your own data center. They’re fine-tuned using a technique called Low-Rank Adaptation (LoRA), which adds a thin adapter layer accounting for less than 1% of the model’s total parameters. That adapter is trained exclusively on one task with one constrained output schema. Multiple navigation tasks can share the same foundation, with each executing its own specialized logic.

While LLMs produce free text, a navigation SLM for slot matching produces a concrete answer — a structured JSON object with a ranked list of slots and confidence scores, with the routing rule applied. Outputs can be validated programmatically before they enter a workflow.

SLMs are easier to govern than LLMs

Another primary advantage of SLMs is that their smaller scope creates stronger governance.

General-purpose LLMs are difficult to audit. Their reasoning is opaque, their outputs are variable, and constraining them to specific behaviors requires significant prompt engineering and ongoing oversight.

SLMs, in contrast, perform one task, making their behavior easier to validate thoroughly prior to production. Because SLMs run on-premises, patient data never leaves your network. And because the output is structured, every routing decision can be logged with the specific rule it applied, creating a defensible audit trail.

When does building your own model make sense?

Here’s the part most SLM vendors won’t say out loud: for a lot of workloads, you shouldn’t build anything. General-purpose LLMs are getting better, faster, and dramatically cheaper (e.g., inference cost for a given level of performance has been falling by roughly 10x a year). If you can ride that curve, ride it. The default answer for most AI workloads should be to get maximum value out of frontier models for as long as they’ll carry you.

So when does that stop being the right answer?

Two forces, often mistaken for one. The first is economics. Volume is what turns into cost, and the same decision made a few times a day is cheap to rent from a frontier model. But made millions of times a year, the marginal cost of a model you run yourself changes the math decisively. The second is performance. When a task demands accuracy or consistency that prompt-steering a general model can’t reliably hit, a model trained on that one task closes a gap cheaper.

And then there’s a force that isn’t a threshold you cross at all, rather, it’s a requirement you start with. PHI that can’t leave your network, latency you have to guarantee, and routing decisions you have to be able to audit aren’t line items you trade off against cost. For many health systems, those constraints justify a model running inside your own walls long before the economics say so.

Two things keep this approach honest. First, “ride LLMs until you cross a threshold” answers what you run inference on today, but not when you start building the asset that makes a purpose-built model good. That asset is your data and the labeled outcomes from every routing decision you make. Wait until cost forces your hand, and you’ll have spent years generating the exact training signal you needed, and captured none of it. The data flywheel has to start earlier than the inference switch. Second, the same pace of improvement that makes riding LLMs smart is also a warning as a capability you build today can be commoditized by the frontier tomorrow. The durable reasons to build aren’t the ones a bigger general model will eventually match, but the ones it structurally can’t give you (e.g., your proprietary data, your on-premises compliance posture, and sub-half-second decisions that come out the same way every time).

Patient navigation clears every one of these bars at once. The volume is millions of decisions a year, the accuracy and consistency demands are unforgiving, and the compliance and latency constraints are non-negotiable from day one. That’s the calculus behind how we think about it at DexCare — and why we’re building toward purpose-built models rather than asking each health system to cross those thresholds alone. The precision and governance of purpose-built SLMs shouldn’t require every health system to become a model-building shop.

Patient navigation needs more than one SLM

Patient access is a complex process comprising multiple separate workflows. That’s why a one-size-fits-all LLM is a liability.

DexCare’s approach is different: using fine-tuned, purpose-built SLMs to connect patients with the right provider consistently. In our architecture, SLMs form the backbone of:

• PDM+, an AI-powered data layer that consolidates all the provider information throughout your health system and structures it for how care flows.
• Optimize AI, a human-verified knowledge base of scheduling logic that works everywhere your patients schedule – website, call center, digital front door, or AI agents.

To create the most accurate patient navigation system possible, we think the right architecture breaks the process into four separate SLMs:

1.) Slot-to-need matching to find the best available appointment across the network, calibrated to your health system’s specific rules.

2.) Provider attribution to catch the gaps between what the EMR says and what the provider does, before it becomes a routing error.

3.) Access rule interpretation to execute rules consistently and quickly, in less than 500 milliseconds, with a constrained output that maps each routing decision back to the specific rule applied.

4.) No-show and fill prediction to predict appointment-fill probability and sequence the waitlist based on a specific appointment slot, a patient profile, and historical data.

With this architecture, provider attribution validated by PDM+ generates a signal. Every routing decision Optimize makes results in a labeled outcome. And higher-quality data yields compounding returns as SLMs improve with each use.

Use the right model to solve the right problem

General-purpose AI may be the right solution for some workflows, but patient navigation isn’t one of them. What’s been missing is an AI architecture precise enough to execute it consistently, quickly, and inside your own walls. That’s what purpose-built SLMs deliver, and why we’re building DexCare’s next generation of Optimize and PDM+ around them.

---

By Rakshay Jain, chief product officer, DexCare

By Chris Carruthers, chief innovation officer, DexCare