Ontology in AI: does your skilled nursing system need one?

A hospital social worker blasts a referral to five facilities at once. The first facility that says "yes, we can take this patient" usually wins. The window is about fifteen minutes. Miss it, and the patient (and the revenue) go to the competitor down the road.

We recently built an AI system for exactly this race, for a residential care operator. It watches the referral inbox. The moment a packet lands, it reads the PDFs, pulls out what matters, runs the facility's own acceptance rules, and pushes a one-screen summary to staff with a recommendation: Accept, Hold, or Deny, with reasons and the evidence linked. A human makes the call. The reading and sorting that used to eat the whole window now takes about three minutes.

The build took roughly forty hours of engineering. It is live in production today, catching real referrals.

Here is the interesting part: there is no ontology anywhere in that system.

So when people ask me whether their facility's AI needs an ontology, I have a genuinely annoying answer: we just shipped something real without one, and I still think you might want one. It depends on the question you need your system to answer. Let me show you both sides and let you decide.

What forty hours buys you

The referral system is a pipeline. Sketched honestly, it looks like this:

Notice what carries the weight. The LLM only does the reading: it turns a messy 40-page packet into a fixed set of fields. The decision comes from plain, exact rules, written with the operator and versioned like code. (Our rule of the build: rules decide, the LLM only normalizes.) Every event lands in an append-only log.

This shape is fast to build, cheap to run, and honest about risk: no consequential decision ever rides on a model's mood. For a single bounded mission, winning the fifteen-minute clock, it is close to the right amount of engineering. A skateboard is a legitimate vehicle. It is cheap, it is nimble, you can carry it upstairs, and for a two-mile commute it beats a sports car stuck in traffic.

And the workflow kept teaching us. The week we went live, the operator's referral team turned out to be twice the size anyone mentioned. Days later came new needs: upload more documents to a case after intake, name the staff member working each referral. None of that was in the original ask. Real workflows only reveal themselves when real cases run through them. Hold that thought, because it cuts both ways.

The confession

I said there is no ontology in that system. That is technically true and spiritually false.

Look at what the build actually contains: a typed extraction schema (what a referral is, in fields), an externalized decision policy (what the organization believes, in rules), statuses a case moves through, and an append-only event log (what happened, in order). We wrote down the organization's knowledge. We encoded its behavior.

That is an ontology in street clothes. We just never formalized it, never made it queryable, and never gave each concept an owner. The knowledge lives scattered across a prompt, a policy file, and a database schema. It works. But it can only answer the questions we thought to wire in.

Which raises the real question: what would formalizing it actually buy?

What an ontology actually is (no seminar required)

Strip the jargon and an ontology is four things:

• Objects. The nouns that matter: Resident, Referral, Care Need, Facility Capability, Bed, Staff Skill, Authorization.
• Links. How they relate: a Resident has Care Needs; a Care Need must be satisfied by a Facility Capability.
• Actions. What people are allowed to do to them, with preconditions and audit: Accept Referral, Reserve Bed, Request Missing Records.
• Governance. Every fact carries its source, author, time, and verification status. Every concept has an owner.

The map is the point. The LLM stops guessing about your operation and starts navigating a model of it.

Here is a version-zero sketch for a skilled nursing facility, abstracted from real multi-facility work:

One consequence of drawing it this way deserves its own sentence. In this model, a facility does not simply "have an empty bed." Its real capability is conditional: licensed service, and trained staff on that shift, and available equipment, and current census, and policy, all intersecting at a point in time. An empty bed is not serviceable capacity. Every SNF administrator knows this in their bones. Most software does not.

The questions each system can answer

This is where the tradeoff stops being philosophy and becomes operations.

The forty-hour build answers the questions we wired in, quickly and reliably: What arrived today? What is this referral waiting on? What did we decide, and on what evidence?

Now try these on it:

• Which beds are actually suitable for this resident at 4 p.m., given staffing, equipment, and infection control?
• Which acceptance conditions correlate with unplanned hospital transfers?
• What did the hospital assert versus what did our nurses verify, and where do they disagree?
• When the arrival unit loses its qualified nurse at 2 p.m., which accepted residents are affected?

The pipeline cannot answer those. Not because the data is missing, but because the relationships were never modeled. Each answer would be a small bespoke project. The ontology-backed system answers them as queries, with sources attached, because needs, capabilities, staff, and time are first-class objects that connect.

That certainty compounds. Cross-cutting questions, audit trails, capacity matching, care-plan orchestration, process mining: they all fall out of the same structure. The map keeps paying.

The part the ontology vendors skip

The overhead is not small. I want to say that plainly, because I have watched the delay eat quarters.

Before an ontology earns its keep, someone has to observe the real workflow (not the policy manual; the manual describes the intended workflow, and rarely the actual one), catalog every consequential decision, get clinical and compliance owners to agree on definitions, model it, map the source systems into it, and stand up governance so the model does not rot. That is weeks to months before the first user feels value (versus value in week one for the skateboard). And there is a rabbit hole waiting: modeling for its own sake, every field an object, every noun a debate.

The boundary principle that keeps you out of the hole: the ontology should be complete enough to run the target workflow, not complete enough to describe the entire business. Stop modeling when the system can state the current case, show its evidence, name the responsible person, and expose the next permitted action. Everything else stays in the source systems until a concrete use case promotes it. (The promotion test is one question: does this field change a decision or an action? No? Leave it where it lives.)

So which one do you build?

Wrong question, slightly. Here is the decision surface as I actually use it:

Your situation	Lean
One bounded mission, a clock to win, budget measured in weeks	Pipeline. Ship it. (This was our referral build, and it was the right call.)
A handful of workflows that share the same nouns (referrals, staffing, meds, care plans)	The shadow ontology starts costing you. Formalize the shared core.
Cross-cutting questions with money on them, audit and compliance exposure, multi-facility scale	The ontology stops being overhead and becomes the asset.
Not sure yet	Read on. There is a third option.

The skateboard-versus-sports-car frame holds up. Nobody buys a sports car for a two-mile commute; nobody skateboards a family across the country. Scope and constraints pick the vehicle. The only wrong move is pretending one answer fits every trip. (The industry does love a stance war. Ontology-always versus ontology-never has the same energy as Windows versus Mac, and roughly the same usefulness to your operation.)

The third option: the parallel track

Forced to give one recommendation for a complex operation like a SNF, here is mine, and it is neither "ontology first" nor "workflow first":

Start with one operational mission. Study the real workflow around it. Build the ontology in parallel, as an executable model of what you observe, not a committee's guess. Overhead, yes; but you pay it while the thin workflow is already delivering, and every shipped case makes the model more true. Remember the referral team that turned out to be twice its stated size: real cases correct the model faster than any workshop.

The forty-hour build proved the fast lane works. The map is how the fast lane becomes a road network.

The invariant

Tools will churn. Models will leapfrog each other by Thursday. This division of labor is the part I would bet stays true:

Get that division right and the vehicle choice, skateboard, sports car, or both in parallel, becomes what it should have been all along: a scoping decision, not a religion.