The next generation of veterinary software will still need schedules, invoices, reminders, medical records, and reliable databases. But if AI is going to become part of clinical work, those words are no longer enough. The language needs to catch up.

“Stop calling it a PIMS” is not really a complaint about terminology.

It is a complaint about architecture.

Words like database, module, screen, interface, and integration are not neutral. They teach us how to divide the world. They tell builders where information belongs. They tell users where to go looking for it. They tell a product what kind of thing it is supposed to be.

There is a real intellectual history behind that point. The Sapir-Whorf hypothesis, or linguistic relativity, is often summarized as the idea that language shapes thought. I do not need the strongest version of that claim here. The weaker version is enough: the categories available in a language influence what distinctions people notice and what alternatives feel natural.1

Lakoff and Johnson made a related argument about metaphor. In Metaphors We Live By, they argue that metaphors are not just decorative language. They structure how people understand and act.2 In software, the effect is even more concrete. Vocabulary becomes schema, navigation, permissions, roadmaps, sales demos, implementation plans, and purchasing checklists.

If we call the product a “PIMS,” and describe it in terms of records, modules, screens, databases, interfaces, and integrations, we are not merely describing the software. We are constraining the architecture we can imagine.

That was fine when the main job of veterinary software was to digitize the artifacts of practice: appointment books, client files, patient records, invoices, reminders, inventory, and reports. Those were the categories that mattered when the profession was moving from paper to screens.

But AI-first software has a different job.

It cannot merely store information and wait for a human to remember where the meaning lives. It has to preserve context. It has to know what matters now. It has to distinguish draft from approved truth, suggestion from commitment, and stored fact from clinically relevant memory.

That is why the vocabulary matters.

If we keep describing the future as an “AI-powered PIMS,” we risk building the same architecture with a model pasted on top. The demo may look new. The underlying mental model may not be.

The problem with modules is not the word. It is the architecture.

A module is a useful software idea. It gives builders boundaries. It gives buyers a checklist. It gives users a place to go.

The schedule module holds appointments. The invoice module holds charges. The medical record holds notes. The communication tool holds messages. The reminder system holds preventive care. Each thing has a place.

But veterinary information does not live that way in the real world.

Take a simple fact: the owner cannot give ear drops.

Where does that belong?

It could belong in the medical record because it affects the treatment plan. It could belong in discharge instructions because the client needs a feasible alternative. It could belong in the estimate discussion because a different plan may cost more. It could belong in the technician’s intake because the next visit should not start from scratch. It could belong in future appointment preparation because the same constraint may matter again.

In a module-based system, we ask: where should this information go?

In a memory-based system, we ask: where will this information matter?

That is the difference.

The first question turns context into a filing problem. The second treats context as something that needs to travel.

A single fact can be clinical context, financial context, family context, communication context, and future-visit context at the same time. When software forces that fact into one module, the practice has to recreate its meaning everywhere else.

That is not just inefficient. It is unsafe in the ordinary, quiet way clinical systems become unsafe: not because one person failed, but because the system made continuity depend on human memory.

Databases still matter. They are just the wrong metaphor.

I am not arguing that practices no longer need databases. They absolutely do.

Veterinary hospitals still need authoritative records, invoices, permissions, audit trails, pricing, controlled-drug logs, scheduling integrity, billing integrity, and conflict handling. A future system that cannot preserve official truth is not futuristic. It is dangerous.

A recent paper from the Companion Animal Veterinary Software Guide makes this distinction clearly. It describes a PIMS as both a set of databases and an application layer.

Some databases are true systems of record: appointments, billing, client records, staff availability, and pricing. Others are better understood as contributory databases, including the evolving medical record, radiology, and client communications.

The authors argue that AI may reshape the application layer, but the need for governance around systems of record remains.3

That distinction matters.

The database remains essential infrastructure. But it should not be the product metaphor.

A database stores facts. Practice memory keeps context alive.

A database can store that a recommendation was declined. Practice memory can remember that it was declined because of cost, that the family wanted a staged approach, that the doctor wanted to revisit the decision after lab results, and that the next conversation should not treat the client as noncompliant.

A database can store a lab result. Practice memory can connect that result to a pending callback, a diagnostic plan, a client expectation, and a question that still needs a doctor’s interpretation.

A database can store a note. Practice memory can recognize that buried inside the note is the reason the next plan should be different.

This is the vocabulary shift I care about.

The product should not feel like a database with screens attached. It should feel like a practice memory with authoritative records underneath.

Memory is not a chatbot with a long context window.

It is tempting to hear “memory” and think of AI memory: a model remembering facts about a user, a long context window, or a chatbot that can recall prior conversations.

That is not what I mean.

By memory, I mean the product’s ability to preserve clinically relevant context and bring it forward when it matters.

Memory is structured, source-aware, reviewable, and governed. It remembers what happened, but also why it matters, where it came from, who said it, whether it was approved, what it affects, what remains unresolved, and who is allowed to act on it.

A patient’s memory is not just a timeline of visits. It includes recurring problems, prior recommendations, declined options, medication tolerance, communication preferences, family constraints, care plan state, open loops, and reported outcomes.

A practice’s memory is larger still. It includes operating patterns, policies, pending commitments, external exchanges, unresolved work, and the accumulated context that allows a team to pick up the thread without starting over.

This matters because veterinary care is not only the management of medical facts. It is the management of medical facts inside family life.

Tincher and Benson’s recent JAVMA viewpoint argues for integrating the pet’s medical needs with the family’s goals, values, resources, and lived circumstances.4 That is not a soft layer wrapped around the medicine. It is part of whether the care plan can actually happen.

A family that cannot give ear drops has not failed the plan. The plan failed to account for the family.

Software that treats that information as a miscellaneous note will never fully support clinical care. AI that ignores it will generate plans that look medically coherent and operationally unrealistic.

Context is what makes the same data mean different things.

A lab result is not just a lab result.

It may be routine screening. It may be the missing piece in a staged diagnostic plan. It may be the evidence that changes a treatment recommendation. It may create a callback. It may require a medical record addendum. It may affect an estimate. It may be the thing the client has been anxiously waiting to understand.

The data is the same. The context changes what it means.

This is where conventional software vocabulary starts to fail. A module tells us where data lives. A record tells us that something happened. An interface tells us where a user can enter or retrieve it.

But the harder question is different:

What does this information mean now?

Who needs to know?

What should it change?

Is it draft, client-stated, inferred, received from an outside system, reviewed, approved, or committed to the official record?

What action can safely be prepared?

Who must approve it?

What must not be lost?

Those are not database questions. They are context questions.

And AI makes them unavoidable.

A generic AI layer can summarize a record, draft a message, or suggest a next step. Some of that will help. AI scribes can reduce documentation burden. Summaries can make long records easier to navigate. Client communication drafts can save time.

But if the system underneath cannot represent source context, approval boundaries, unresolved work, family constraints, and accountable follow-through, the AI layer inherits the same fragmentation.

In my previous article on the PIMS integration problem, I argued that veterinary interoperability is not just about moving data. It is about whether systems preserve meaning across connection, structure, and semantics. This is the same problem inside the product. Even if AI can read the data, the system still needs to know what that data is allowed to become.

A model output is not automatically clinical truth. A draft is not an approval. A summary is not a decision. A generated client message is not the same thing as accountable communication from the practice.

The future system needs fluid context and governed commitments.

Both halves matter.

If context is not fluid, the practice keeps reconstructing meaning from scattered records. If commitments are not governed, AI becomes unsafe.

Screens belong to modules. Surfaces belong to moments.

This is where I find myself reaching for a different UI word: surface.

A screen belongs to a module. Open the invoice screen. Open the schedule. Open the medical record. Open the communication tab.

A surface belongs to a moment of work.

At checkout, the relevant surface may include charges, discharge instructions, declined recommendations, pending lab work, follow-up promises, and the family’s cost constraints. None of that belongs naturally to a single module. All of it belongs to the moment.

During intake, the relevant surface may include the reason for visit, prior unresolved concerns, medication issues, client communication preferences, known handling concerns, and questions the doctor wants answered before the exam.

During doctor review, the relevant surface may include patient memory, problem framing, diagnostic results, care options, family constraints, approvals, and open loops.

The point is not to make the interface unstable or magical. A dynamic surface should not improvise randomly. It should be shaped by stable memory, current context, role, permissions, visit state, source context, and unresolved work.

That is a different product architecture.

In a module-based system, the user moves from screen to screen, reconstructing meaning along the way.

In a memory-based system, the surface brings forward the context needed for the person, patient, role, and moment.

The same underlying truth can support different surfaces for the front desk, technician, doctor, practice manager, and covering user. That is not fragmentation. That is role-aware continuity.

The underlying memory should be shared. The surface should be contextual.

Open loops are memory with responsibility attached.

This is where the earlier idea of “work in motion” still matters, but it is not the whole argument.

Veterinary clinics do not just have tasks. They have open loops.

A task is a thing to do.

An open loop is unresolved work with memory: what caused it, who owns it, what evidence supports it, what approval boundary applies, what should happen next, and what would count as resolution.

“Call owner” is a task.

“Call owner after doctor reviews pending chemistry results from today’s sick visit, explain whether the staged diagnostic plan still makes sense, and document whether the family wants to proceed with imaging” is an open loop.

The second version carries context. It preserves why the work exists, what decision it supports, and what closure actually means.

In a real clinic, the dangerous work is often not the work nobody did. It is the work the system quietly allowed everyone to think someone else owned.

A lab result arrives after the appointment. A doctor intends to review it later. A technician believes the doctor already saw it. The client assumes someone will call if anything matters. The system has a result. It may even have a task.

But does it know the loop is still open?

This is why open loops belong in the center of an AI-first product. They are not a peripheral task list. They are how the system keeps continuity honest.

An assistant can notice patterns, prepare summaries, draft callbacks, or surface overdue work. But it needs the product model to distinguish routine reminders from unresolved commitments that still carry clinical, financial, or client-facing meaning.

A callback list is not enough. A reminder list is not enough. A task board is not enough.

The system needs to know what remains unresolved, why it matters, and who can close it.

Approval surfaces are how AI earns trust.

The safest AI system in a clinic is not the one that does nothing.

It is the one that knows the difference between preparing work and committing truth.

There are many things software can safely prepare: visit briefs, intake questions, discharge drafts, callback drafts, charge mismatch flags, follow-up tasks, estimate review prompts, missing-weight warnings, and reminders that a recheck is overdue.

But there are also things software should not silently commit on behalf of the practice.

It should not turn a draft into the official medical record without review. It should not send client-facing medical advice without approval. It should not convert a suggested plan into a financial estimate without accountability. It should not treat generated text as if it were examined, reasoned, and signed by a clinician.

That is why approval surfaces matter.

An approval surface should show the user what the system prepared, why it prepared it, what source context it used, what approval would commit, and what role is allowed to approve it.

This is different from generic automation.

Automation asks: can the software do the thing?

Bounded agency asks: what kind of action is this, under whose authority, with what evidence, with what audit trail, and with what ability to reverse or repair mistakes?

The major human healthcare EHR vendors are already moving, at least in their public language, from static documentation toward AI that participates in clinical, operational, revenue-cycle, administrative, and patient-facing workflows.5,6 Veterinary medicine will face the same broad question, but with fewer regulatory guardrails, thinner margins, more fragmented software, and less standardization.

So veterinary software needs to be especially precise.

AI should be allowed to prepare, suggest, queue, route, and in carefully bounded cases act under policy. But clinical truth, financial commitments, client-facing medical advice, and changes to the official record need accountable approval.

That is not anti-AI. It is what makes useful AI possible.

Integration is not enough. External systems need permissioned exchange.

“Integration” has become one of the most overworked words in veterinary software.

It can mean a PDF attachment. It can mean a nightly batch file. It can mean a one-way pull. It can mean a read-only API. It can mean a browser extension. It can mean real-time, bidirectional, field-level workflow support. It can mean “we can technically get the data if enough people agree to enough custom work.”

Those are not the same thing.

AI makes this distinction more important because an assistant needs to know not only that data moved, but where it came from, what it means, whether it is trusted, whether it is complete, and what should happen if the exchange fails.

The Companion Animal Veterinary Software Guide’s Part IV paper makes an important point here: applications that touch a true system of record need conflict-aware access, scoped permissions, idempotent writes, auditability, and practice-controlled consent.7 That framing is useful because the goal is not reckless openness. The goal is accountable exchange.

A connection should not just move data into another silo. It should participate in memory.

If a lab result arrives, does the system know it arrived? Does it know whether it has been reviewed? Does it know whether the client has been contacted? Does it know whether the result changed the plan?

If the transfer fails, is the failure visible to the team, or does it disappear into the gap between systems?

That is permissioned exchange. Not a logo wall. Not a vague integration claim. A visible, governed handoff that supports real work.

What practices should ask vendors next

If this vocabulary shift is right, practices should change the way they evaluate AI software.

The first question should not be, “Does it have AI?”

That is becoming too easy to answer with yes.

Better questions are:

• What does the system remember across visits?

• What context can move across modules, roles, visits, and time?

• Which parts of the system are authoritative systems of record, and which are contributory sources that AI may need to synthesize?

• Does information have to live in one module, or can it surface wherever it matters?

• How does the system distinguish stored fact, inferred context, draft text, approved truth, and official record?

• What surfaces change based on role, visit state, permission, and unresolved work?

• What actions require human approval?

• What happens when an external exchange fails?

• Can client communication update patient memory and care context?

• Can family constraints shape the care plan, or are they buried in notes?

• Who owns a pending result, recommendation, estimate, callback, or outcome check?

• What audit trail exists when AI prepares, changes, routes, or sends something?

These questions are less flashy than asking which model is underneath. They are also more important.

A better model inside a fragmented architecture will still produce fragmented work. A modest model inside a well-designed system of memory, context, and approval may be far more useful.

That is the point I keep coming back to: AI is not just a capability. It is a stress test of the software architecture underneath it.

If the architecture is organized around modules, AI will be forced into modules. If it is organized around memory, context, surfaces, open loops, and accountable action, AI has a chance to become something more useful.

Key Insights for Veterinary Practice

• 🔍 “AI-powered PIMS” is too vague to be useful. Practices should ask what the system remembers, what context it preserves, and what actions it can safely support.

• 🧠 The medical record is necessary, but it is not enough. Future systems need practice memory: clinically relevant context that can be brought forward when it matters.

• 🧩 Modules create silos. The problem with module language is that it asks where information belongs instead of asking where information will matter.

• 🖥️ Screens should become surfaces. A surface is a contextual working view shaped by patient memory, visit state, role, permissions, source context, and unresolved work.

• 🔄 Open loops are memory with responsibility attached. A pending lab review, staged diagnostic plan, or callback is not just a task. It is unresolved work with context, ownership, and a definition of closure.

• ⚖️ Safe AI requires bounded agency. The system can prepare, summarize, suggest, route, and queue work, but clinical, financial, client-facing, and official-record commitments require accountable approval.

• 🔗 Integration should mean permissioned exchange. The real question is not whether systems connect, but whether the exchange is visible, governed, complete enough for the work, and repairable when it fails.

The next generation of veterinary software will still need schedules, invoices, inventory, reminders, medical records, and reliable databases. None of that goes away.

But those are no longer enough to define the product.

If AI is going to become part of veterinary practice software, the system underneath it has to know more than where data is stored. It has to understand what should be remembered, what context matters now, what surface should appear, what remains unresolved, what has been approved, and who is allowed to act.

That is not just a better PIMS.

It is a different vocabulary for the work.

What do you think? Where does your current software trap context inside modules? What information does your team have to remember because the system does not? And when a vendor says “AI-powered,” what do you wish they would explain before showing the demo?

If you’ve been following the conversations around veterinary AI and practice technology lately, you’ve noticed the pattern. Someone announces an integration platform, a universal API, or a middleware solution for PIMS data. The response is universally enthusiastic. The comments are full of “This is exactly what we need!” and “Finally, someone who gets it!” And there’s always someone promising that a well-built open API layer is “just a matter of will” or that “if human healthcare can do it, so can vet med.”

I want to pour a little cold water on this—not because the problem isn’t real, but because underestimating it is how we get to exactly where we are now.

After 29 years in veterinary diagnostics and deep involvement in the data standardization space, I can tell you that the PIMS integration problem is one of the hardest problems in veterinary software. It’s not technically difficult in the way that building a compiler is technically difficult. It’s difficult in the way that coordinating 15 independent organizations to agree on anything is difficult—which is to say, it’s a problem of incentives, not engineering.

The people saying it can’t be done are wrong. But so are the people saying it’ll be done in eighteen months by a small team with a good API design.

Let me explain why.

Fifteen Platforms, No Glue

The numbers are worth examining, because they set the scope of what anyone proposing a solution is actually facing.

There are approximately 15 PIMS platforms with meaningful market share serving roughly 30,000 companion animal practices in the US. On top of these sit 140 or more point solutions—diagnostics, communications, payments, scheduling, telemedicine, controlled drug management, AI scribes, analytics, pharmacy, inventory—the list keeps growing. The theoretical integration surface area is 15 times 140, which gives us over 2,100 potential integration pairs.

How many of these work reliably in production today? A small fraction. IDEXX’s own research—the “Finding the Time” study, published by one of the largest PIMS vendors with no incentive to overstate the problem—found that 85% of practices say their PIMS is poorly integrated across platforms. Two-thirds say improving operational efficiency is a high or top priority. 1

The market structure comes from the Companion Animal Veterinary Software Guide (CAVSG) Parts 1–9, which cites Kynetec data on PIMS market share: AVImark (Covetrus) at 25.4%, IDEXX Cornerstone at 19.5%, ezyVet (IDEXX) at 16.5%, with the remaining twelve-plus platforms at roughly 38.6%. 2

The gap between “everyone agrees this is a problem” and “there are 2,100 integration pairs to address” is where the optimism meets reality. 3

The Three Layers, Revisited

In a previous post, I described the three layers of the veterinary interoperability problem, and the framework is essential for understanding why quick fixes don’t work:

Connection Layer: How systems talk. APIs exist but they are closed, undocumented, or fee-gated. This is the layer most integration platforms start with.

Structural Layer: Data format agreement. JSON and CSV files exist, but schemas don’t align between PIMS. A “patient birthdate” in one system isn’t structured the same way in another.

Semantic Layer: What data means. This is the unsolved one. “Kidney problem” and “CKD” and “chronic kidney disease stage 3 per IRIS classification, creatinine 3.2”—these aren’t just different words for the same thing. They represent different levels of clinical specificity being recorded at different stages of the diagnostic process. Simple synonym mapping doesn’t fix this.

Every integration claim I’ve seen publicly solves the connection layer, partially addresses the structural layer, and ignores the semantic layer entirely. Here’s why that matters: even if every PIMS had open APIs tomorrow—which they don’t—integration would still fail at the semantic layer. This is not an engineering problem. It’s an information theory problem.

I want to repeat that, because most people miss it: open APIs would not solve the veterinary integration problem. They would make it easier to move data between systems, yes. But they would not solve the problem of what that data means, how specific it is, or whether the receiving system can use it.

Subscribe now

The Redox Analogy—and Where It Breaks

The comparison everyone makes is Redox, the human healthcare interoperability company that connects over 8,200 healthcare organizations to 250+ technology customers, processes 15 billion plus clinical transactions per year, and has raised $147 million.4 Redox built the connective tissue API layer between EHR systems and third-party health-tech apps. The architectural pattern is exactly what people want for veterinary medicine.

There is no Redox for vet med. There is no self-service two-sided API marketplace. The platform layer does not exist.

Here’s the part the Redox enthusiasts leave out: Redox built their platform in a market with a $30 billion federal EHR incentive (HITECH, 2009), a federal interoperability mandate (Cures Act, 2016), a national exchange framework (TEFCA, 2023), a payer equivalent (Medicare/Medicaid plus commercial insurers) creating demand-side pressure, and a $10 to $13 billion EHR market to build on.

Veterinary medicine has none of these things. No federal mandate, no payer equivalent—pet insurance penetration sits around 4 percent—and a PIMS market estimated at $200 to $400 million per year.5 The human healthcare interoperability market alone is roughly ten times larger than the entire veterinary software market.6

This doesn’t mean a veterinary Redox is impossible. It means the analogy breaks precisely where the hard work begins. Redox didn’t just need good engineering. They needed federal policy, market pressure, and a buyer class with collective negotiating power. Vet med has to solve this organically, without a forcing function.

That’s not a reason to give up. It’s a reason to be honest about timeline and effort.

What’s Actually Being Built Today

Let me be fair and specific about the current landscape, because dismissing it doesn’t help anyone.

IDEXX DataPoint and VetConnect PLUS are technically sophisticated and operate at meaningful scale, connecting IDEXX PIMS platforms to IDEXX diagnostics and analytics. They work well. They are also disqualified from being the neutral layer because IDEXX competes with other PIMS vendors. You cannot have the fox building the chicken coop’s security system.

Covetrus Connect launched in August 2019, built on the VetData acquisition. They claim 250 plus connections for Pulse and are the only authorized integration platform for Covetrus PIMS platforms. Same structural problem as IDEXX: the neutrality gap.

Bitwerx is the most interesting player in the space. Based in Lexington, Kentucky, co-founded by people from the original Veterinary Data Services, they handle PIMS-to-PIMS data conversions, real-time API integration, write-back access, and standardized taxonomy work. They are trusted by thousands of practices and are the platform of choice for independent PIMS vendors doing migrations.

But Bitwerx is a B2B services and conversion business. It is not a two-sided network platform. It relies on human-in-the-loop mapping. It has no semantic translation layer. It has no self-service API for third-party developers. These are not criticisms—Bitwerx is doing important work that nobody else does. They are a different kind of business solving a different layer of the problem.

VetVerifi, the pet health data verification platform, has a strategic partnership with Bitwerx announced in 2025. They’re focused on health certificates, vaccination records, and health data verification. Useful, but narrow scope.

GreyWind operates as a “sanctioned integrator” for certain PIMS vendors—an integration platform that works with vendor consent rather than against it. Their scope is more limited than Bitwerx, working within the boundaries that PIMS vendors are willing to grant. But GreyWind is a signal worth noting: it shows that PIMS vendors are willing to work with third-party integrators when the commercial alignment is clear and they retain some control over who accesses their data.

VetXML and VetEnvoy in the UK are defining data schemas for PIMS interoperability, especially insurance claims. UK practices report a 40 percent reduction in administrative burden and settlement times from 10 days to under 3 days. This is genuinely impressive—and it hasn’t crossed the Atlantic because it’s tightly coupled to the UK insurance ecosystem.

What none of these platforms offer is a self-service two-sided marketplace where PIMS connect once, third-party developers build against a single API, practices can discover and authorize integrations, and semantic normalization happens automatically.

That platform simply does not exist yet.

What’s Changing—and Why It Gives Me Actual Optimism

Despite the gloom above, I think the timing is genuinely becoming favorable. Not because the problem has gotten easier, but because external forces are creating pressure that didn’t exist three years ago.

AI-native adoption is forcing open-API postures. AI scribes are the fastest-adopted category in veterinary software history. But here’s the critical detail: the time savings from AI scribes drop from about 40 percent to 10 or 15 percent when the API is read-only versus read-write.7 If a practice books 5,000 appointments per year, that’s roughly 200 staff hours saved annually with full integration versus partial integration. At those numbers, the economic incentive for open APIs shifts from “nice to have” to “competitive necessity.” The broader agentic AI healthcare market is estimated at $800M in 2025, growing to $32.76 billion by 2035—”Agentic AI Will Transform Veterinary Practice Software by 2030,” Veterinary Software Insider, 2026. With ChatGPT alone seeing over 5 percent of all global messages being healthcare-related, the pressure for open APIs is only accelerating.8

Corporate consolidators are demanding openness. The largest corporate veterinary groups can start demanding data access and standardized integration as a contract condition with PIMS vendors. If five of the ten largest groups coordinated, market-pressure standards would emerge without any federal mandate. This is how Plaid worked in fintech—large institutional demand forced bank API adoption before regulation caught up.

The MCP and agent ecosystem is creating de facto standardization. Model Context Protocol has reached 97 million monthly SDK downloads.9 Whatever you think about MCP specifically, the broader phenomenon is: AI agent infrastructure is standardizing integration formats whether PIMS vendors cooperate or not. This standardization pressure arrives first in human healthcare and dental (where it’s already happening), and crosses into veterinary medicine three to five years later. The standard formats will arrive whether the PIMS industry builds them or has to accept them.

Cloud PIMS migration is happening. Between 15,000 and 17,000 hospitals are projected to migrate to cloud PIMS over the next five to seven years.10 Each migration is a natural integration opportunity, and cloud PIMS are significantly more likely to have API capabilities than legacy on-premise systems. This is the migration window that makes the problem tractable, because you don’t have to retrofit APIs onto 30-year-old codebases.

Pet insurance is growing. US pet insurance hit $4.7 billion in 2024 and is projected to reach $18.9 billion by 2033 at a 15% CAGR.11 As penetration grows from 4 percent toward 15 or 20 percent, payer-driven demand for structured data exchange will create market pressure that currently doesn’t exist.

None of these solve the problem on their own. But together, they create a convergence that I think is real and that people underestimating this opportunity should pay attention to.

The Realistic Timeline

Let me be specific about what building this actually takes, because the “build an API platform in six months” narrative sells a product that doesn’t exist.

A realistic path looks like this:

Year one is the wedge phase. You build a semantic translation layer—the part that takes raw veterinary clinical text and maps it to standardized codes. You don’t build the full platform. You build the one thing that addresses a gap every existing player shares: connection and structure are partially solved, semantics are not. You get three to five pilot practices providing de-identified clinical text. You demonstrate the value to the fastest buyer segment: AI scribe companies that need structured data from PIMS outputs. This phase takes six to twelve months minimum.

Year two is the first adapter. You build read and write adapters for one cloud PIMS—probably one with relatively open APIs like ezyVet through IDEXX’s developer program, or a smaller platform more willing to work with you. You get your first paying customer. You validate that the semantic translation layer works on real production data, not just test cases. This is the phase where you learn that vendor relationships take twelve to eighteen months to build, not three.

Years three and four are platform building. You build three to five PIMS adapters, open a self-service developer portal, and get your first third-party app built on your API. This is where network effects begin—not because you planned them, but because having multiple PIMS connected to multiple apps creates a value proposition that compounds on itself.

Years four and five are when you have something that looks like a real platform. Ten or more PIMS adapters, fifty or more third-party apps, a semantic model that has been trained on enough real data to be genuinely useful, and revenue somewhere in the $1 to $5 million ARR range.

This is not a “move fast and break things” problem. You are asking to become the connective tissue of veterinary practice data. If you break things, you break patient records. The timeline is five years minimum, with meaningful revenue not arriving until year three or four. Anyone promising faster either doesn’t understand the problem or is selling something.

The Size of the Prize

Let’s talk about market size honestly, because this matters for understanding who should build it and how.

Redox, at human healthcare scale, has estimated ARR of around $181 million. The entire veterinary PIMS software market is $200 to $400 million per year. You are not going to build a $181 million ARR business in a $400 million market.

But here’s what you can build: at 6.7 percent market penetration—2,000 practices at $200 per month—you’re at $4.8 million ARR. At 33 percent—10,000 practices—you’re at $24 million ARR. At 67 percent dominance—20,000 practices—you’re at $48 million ARR.

This is a real, defensible, high-margin business with strong network effects and strategic moat value. It is not a venture-scale unicorn outcome. It’s a $10 to $50 million ARR business that could be the most important infrastructure layer in veterinary software, built by someone with the domain expertise to understand the semantic problem, the technical skills to build it, and the patience to survive the five-year timeline.

I mention this not to discourage, but to be honest about what kind of capital and what kind of founder this requires. If you need hockey-curve growth to satisfy venture capital expectations, this isn’t your business. If you have patient capital, bootstrapping resources, or the luxury of being a practitioner-entrepreneur who understands that five years to solve a hard problem is actually fast, then it becomes very interesting.

The Semantic Wedge

Here’s what I think is the right entry point, and it’s the one I’ve been building credibility around in these articles: the semantic translation layer.

Every existing player—Bitwerx, IDEXX DataPoint, Covetrus Connect—solves connection and structure. None of them solve semantics. If you can build a system that ingests veterinary clinical text from any PIMS, extracts concepts using veterinary-specific NLP, and maps those concepts to SNOMED-CT Veterinary Extension codes, you have a product that is immediately useful without requiring every PIMS vendor to agree to your platform.

This doesn’t require vendor consent. The data is already exportable from most PIMS in some form—it just comes out as “kidney problem” or “CKD” or “azotemia” instead of standardized concept IDs. You build the bridge between how veterinarians actually write and how machines need data to be structured. And the more clinical text you process, the better your models get, which creates a data moat that compounds over time.

This is why I’ve spent so much time writing about Blois’s hierarchy of medical description, about SNOMED-CT, about why “kidney problem” and “CKD” and “IRIS stage 3 chronic kidney disease” are not synonyms but different levels of clinical specificity. That framework isn’t academic exercise. It’s the foundation for the exact product that should exist and doesn’t.

Key Insights for Veterinary Practice

📊 Understand the three layers of the integration problem. If a vendor is only talking about APIs and connections, they’ve solved the easiest layer. The semantic layer—what data actually means—is where integration really fails, and it can’t be solved with better plumbing.

🔍 The Redox analogy is useful but incomplete. Human healthcare interoperability was built on federal mandates, market pressure, and a buyer class with negotiating power. Vet med has to solve this organically. That means the timeline is longer but the solution, once built, will be more resilient.

📋 Demand specificity from integration vendors. Ask: Which layer are you solving? What does your semantic normalization look like? How do you handle the same clinical concept expressed at different levels of specificity? If they can’t answer these questions, they haven’t solved the real problem.

🔄 AI scribes are the wedge that changes incentives. The drop from 40 percent time savings with full integration to 10-15 percent with read-only APIs means practices will start demanding write access. This economic pressure will open doors that relationship-building alone cannot.

⚖️ Be realistic about who should build this. A venture-backed startup needing hockey-curve growth will fail. A PIMS vendor can’t be neutral. The right builder is someone with deep veterinary domain expertise, technical capability, independence from existing platforms, and the patience for a five-year timeline.

🧠 The semantic translation layer is your starting point. Before building the full platform, prove you can take messy, real-world veterinary clinical text and normalize it into standardized codes. This is the gap every current player shares, and it’s the one that doesn’t require everyone to agree before you can start.

Conclusion

The PIMS integration problem is hard. But hard problems that everyone needs solved are exactly the ones worth pursuing. The danger isn’t that the problem is too big—it’s that people keep trying to solve it with solutions designed for smaller problems.

If someone is going to build the connective tissue layer for veterinary practice data, they need to start with the semantic wedge, plan for a five-year timeline, understand that vendor relationships take longer than engineering, and build something that compounds in value over time rather than promising a quick API fix.

The need is real. The timing is becoming favorable. But the effort is substantial. Anyone who tells you otherwise either hasn’t looked at the data or isn’t telling you the whole truth.

What’s your practice’s experience with PIMS integrations? Are you absorbing the integration tax in staff time, and if so, how? Have you noticed AI tools that claim to integrate but leave the hard work to your front desk? I’m curious whether practitioners feel the same urgency that the data suggests they should, or whether the daily workarounds have become so normalized that people don’t see the problem anymore.

Let me know in the comments.

In 1979, a computer system at Stanford University performed something remarkable. MYCIN, an artificial intelligence system designed to recommend antimicrobial therapy for bacterial infections, was evaluated against infectious disease experts. The results? MYCIN’s recommendations were rated as acceptable as or better than those of faculty specialists.

Let me put that in perspective. This AI system, running on 1970s hardware with a fraction of the computational power of your smartphone, matched human experts at one of medicine’s most complex diagnostic challenges—selecting appropriate antibiotics for critically ill patients when cultures take days to return and every hour counts.

MYCIN was rigorously evaluated. It could explain its reasoning. It worked.

And it was never used in clinical practice.

For those of us watching the explosion of AI tools entering veterinary medicine—most without any public validation data, many making bold claims about transforming practice—MYCIN’s story should be required reading. It’s a case study in how AI can succeed technically yet fail practically, and why the challenges we face today aren’t nearly as new as we think.

After 29 years in veterinary diagnostics, including extensive work with AI and machine learning, I’ve seen history repeat itself more times than I’d like to admit. The lessons MYCIN taught us in the 1970s and ‘80s are lessons veterinary medicine desperately needs to learn before we make the same expensive mistakes.

Subscribe now

What MYCIN Actually Was

MYCIN was an expert system—a type of AI that encodes human expertise into logical rules. The system contained approximately 600 production rules structured as IF-THEN statements, each capturing specific diagnostic or therapeutic knowledge from infectious disease experts. These rules operated on a backward-chaining inference engine that worked from a hypothesis (such as a suspected infection) back through the evidence needed to confirm or reject it.

What made MYCIN particularly sophisticated for its era was its certainty factor system: rather than requiring definitive yes/no answers, it could work with uncertainty, assigning numerical confidence values between -1 and 1 to both the evidence it gathered and the conclusions it drew.

Unlike today's machine learning systems that learn patterns from data, MYCIN's knowledge was explicitly coded by human experts—making its reasoning process completely transparent and explainable, a characteristic that still challenges modern deep learning approaches.

The system focused on a specific, high-stakes clinical problem: selecting antimicrobial therapy for patients with bacterial infections, particularly meningitis and bacteremia. When a patient presented with suspected infection, MYCIN would ask the physician questions about symptoms, lab results, and patient characteristics, then recommend specific antibiotics and dosages.

What made MYCIN different from the AI tools flooding veterinary medicine today? Three things:

It was narrowly focused. MYCIN didn’t try to do everything. It solved one well-defined problem where expert knowledge could be codified into rules.

It was transparent. MYCIN could explain its reasoning. Ask it why it recommended gentamicin, and it would show you the chain of rules and evidence that led to that conclusion.

It was evaluated. Extensively. Publicly. With methodology you could critique.

That last point is worth dwelling on.

The Validation That Should Shame Modern AI Companies

[This section will be strengthened by specific details from the evaluation chapters]

The Stanford team didn’t just build MYCIN and declare it worked. They designed rigorous evaluation studies comparing MYCIN’s recommendations to those of physicians at varying expertise levels—from residents to infectious disease faculty.

In their most comprehensive evaluation, published in 1979, the team assembled 10 actual meningitis cases and presented them to MYCIN and eight human experts: five Stanford infectious disease faculty members, one Stanford infectious disease fellow, one Stanford resident, and one community infectious disease expert practicing outside the academic setting. Each evaluator reviewed identical case information and recommended antimicrobial therapy independently.

The evaluation criteria were carefully defined: a panel of independent infectious disease experts (not involved in MYCIN’s development) reviewed all recommendations and rated them as “acceptable” or “not acceptable” based on whether the therapy would be considered appropriate given the clinical evidence. Acceptable therapy didn’t require perfection—it meant the recommendation fell within the range of clinically defensible approaches that wouldn’t harm the patient and had reasonable probability of treating the infection effectively.

The results were striking: MYCIN’s recommendations were judged acceptable in 65% of cases. The faculty experts averaged 42.5% to 62.5% acceptable recommendations, with only the most senior infectious disease specialists matching or slightly exceeding MYCIN’s performance. The resident and fellow performed substantially worse, with acceptance rates below 50%.

Perhaps most importantly, the Stanford team published their complete methodology, provided detailed case-by-case analysis, and openly discussed cases where MYCIN failed and why. They didn’t cherry-pick their best results or hide failures behind proprietary claims.

The results were published. The methodology was transparent. Other researchers could critique it, attempt to replicate it, and build on it.

Now compare this to the state of veterinary AI in 2025.

In previous posts, I’ve documented what I call the veterinary AI transparency crisis—most companies launching AI tools provide no public validation data whatsoever. No peer-reviewed studies. No methodology descriptions. Often just marketing claims and carefully selected testimonials.

We’re expected to evaluate AI tools based on demonstrations and promises, while MYCIN’s developers 50 years ago published detailed evaluation protocols and openly discussed their system’s limitations.

Think about that. A 1970s academic research project had higher validation standards than most commercial veterinary AI products today.

This isn’t because modern AI is harder to evaluate. It’s because we’ve collectively lowered our standards and accepted that AI tools should be treated differently from every other technology entering veterinary practice. We demand evidence for pharmaceuticals, diagnostics tests, and surgical techniques. Why not AI?

Why Integration Killed It: A 50-Year-Old Problem We Still Haven’t Solved

Here’s where MYCIN’s story becomes directly relevant to every veterinary practice evaluating AI tools today.

MYCIN worked. The validation proved it. But it couldn’t connect to anything else in the hospital.

In 1979, hospitals were beginning to digitize, but their systems existed in complete isolation. Clinical laboratories had their own computer systems for managing test results. Pharmacy systems tracked medication orders separately. Patient demographic information lived in administrative databases. Microbiology labs maintained their own culture and sensitivity data. Each system used different hardware, different programming languages, different data formats, and completely incompatible ways of identifying patients, medications, and test results.

MYCIN needed information from all of these sources: patient demographics, current medications, laboratory values, culture results, white blood cell counts, and more. But there was no way to automatically pull this data from existing hospital systems. Every piece of information had to be manually entered into MYCIN by a physician or researcher sitting at a terminal, answering dozens of questions in a text-based interview that could take 20-30 minutes per patient.

The technical barriers weren’t just inconvenient—they were fundamental. In the late 1970s, there were no network protocols for connecting disparate medical systems. There were no data standards defining how lab results should be formatted or how medications should be coded. HL7 wouldn’t be founded until 1987. DICOM for medical imaging wouldn’t exist until 1985. The concept of electronic health record integration was still a decade away.

Even if MYCIN’s developers had somehow built custom connections to Stanford Hospital’s specific systems, those integrations wouldn’t work at any other hospital. Every institution used different vendors, different systems, different workflows. Scaling MYCIN beyond Stanford would have required rebuilding all integrations from scratch at each new site—an economically impossible proposition.

So MYCIN remained a research demonstration: brilliant AI that physicians acknowledged was helpful, but that couldn’t fit into actual clinical workflows. The system that could match expert infectious disease specialists sat unused because asking busy physicians to spend 30 minutes manually entering data for a consultation they could get from a phone call to the ID service was never going to happen.

To use MYCIN, a physician had to:

• Gather patient information from the medical record

• Manually enter it into MYCIN through a terminal

• Answer MYCIN’s questions one by one

• Review MYCIN’s recommendations

• Manually incorporate those recommendations back into the patient’s care

Every piece of data was a manual transcription. Every recommendation required re-entering information into the hospital’s actual record-keeping systems. MYCIN existed as an island, isolated from the clinical workflow it was supposed to support.

Sound familiar?

In my recent post on the three layers of veterinary software interoperability, I described how veterinary medicine struggles with connecting systems even today. We have:

The Connection Layer - How systems communicate (APIs, file transfers, database access)

The Structural Layer - Agreeing on data formats

The Semantic Layer - Standardizing what things mean (the terminology chaos)

MYCIN failed at the Connection Layer. In the 1970s, there were no standardized APIs for hospital systems. Each system was proprietary. Building integrations between systems meant custom engineering for every combination. The technical and economic barriers were insurmountable for a research project.

But here’s the uncomfortable truth: We’re still building veterinary AI tools that fail at these same layers.

How many AI tools are being marketed to veterinary practices right now that require:

• Manual data entry from your PIMS into the AI system?

• Copy-pasting results back into your medical records?

• Maintaining parallel documentation in multiple systems?

• Custom integration projects that break every time software updates?

MYCIN taught us 50 years ago that isolated AI tools—no matter how accurate—won’t be adopted if they disrupt workflow. Yet we keep building them.

The technology has improved dramatically. We have APIs, cloud computing, and standardized protocols that didn’t exist in the 1970s. But the fundamental interoperability challenges remain, especially in veterinary medicine where we lack the standard terminologies that human medicine has developed.

The Workflow Problem: When “It Works” Isn’t Enough

Even if MYCIN had solved its integration problems, it faced another, more subtle barrier: workflow disruption.

MYCIN required physicians to step out of their normal clinical process, sit at a terminal, and have what amounted to a consultation with the computer system. Even when physicians believed MYCIN’s recommendations were valuable, the friction of using it was too high.

This is where the disconnect between “performance metrics” and “clinical utility” becomes stark.

MYCIN’s accuracy metrics looked great. Its recommendations were sound. But accuracy is meaningless if the tool doesn’t fit into how medicine is actually practiced.

I see this same trap in veterinary AI evaluation today. Companies focus obsessively on performance metrics—sensitivity, specificity, accuracy rates—while ignoring the more fundamental question: Does this tool make the veterinarian’s job easier or harder?

Consider the veterinarian’s actual workflow:

• Patient presents

• History taken while restraining/examining the animal

• Initial assessments made

• Tests ordered

• Results reviewed

• Treatment decisions made

• Documentation completed

• Client communication

• Next patient

Where in this workflow does your AI tool fit? Does it require stopping to enter data into a separate system? Does it provide insights at the moment of decision-making, or require coming back later? Does it create new documentation burdens?

MYCIN’s developers built a system that worked but didn’t fit. Many veterinary AI tools are making the same mistake.

The Three Lessons Veterinary Medicine Must Learn

Lesson 1: Validation Isn’t Optional—And Standards Haven’t Lowered

MYCIN set a validation bar that modern veterinary AI companies aren’t even attempting to clear. The excuse that “AI is different” or “validation is too expensive” doesn’t hold up when a 1970s academic project managed to do it thoroughly.

If you’re evaluating AI tools for your practice, demand:

• Published evaluation methodology

• Sample sizes and case selection criteria

• Performance metrics appropriate to the task

• Discussion of limitations and failure modes

• Independent validation, not just vendor claims

Don’t accept “our AI is too complex to explain” or “validation data is proprietary.” MYCIN could explain its reasoning and published its validation openly. Modern tools should do the same or better.

Lesson 2: Integration Is Make-or-Break

MYCIN failed because it couldn’t connect to hospital systems. We can’t afford to repeat that mistake.

Before adopting any AI tool, ask:

• How does this integrate with our existing PIMS?

• What data entry is required?

• Where does information flow break down?

• What happens when our software updates?

• Who maintains the integration?

If the answer involves significant manual data transfer, workflow interruption, or custom integration projects, approach with extreme caution. The tool might work brilliantly in isolation and still fail in practice.

As I discussed in my interoperability post, veterinary medicine has severe structural challenges here—proprietary systems, no standard terminologies, lack of industry coordination. But that makes integration planning more important, not less.

Lesson 3: Workflow Preservation Matters More Than Raw Accuracy

The most accurate AI tool is worthless if veterinarians won’t use it.

Evaluate new AI tools by asking:

• Does this fit naturally into our current workflow?

• Does it provide value at the point of decision-making?

• What new burdens does it create (documentation, data entry, review)?

• Would I actually use this on a busy Monday morning with a full schedule?

MYCIN’s developers learned that physician behavior doesn’t change just because a tool is technically superior. Veterinary professionals are the same way—and rightfully so. Your workflow evolved for good reasons. Any tool that disrupts it needs to provide overwhelming value to justify the friction.

What This Means for Veterinary AI Today

The veterinary AI market is exploding. Diagnostic imaging tools, clinical decision support systems, documentation assistants, practice management automation—new tools launch constantly, each promising to transform practice.

Most will fail. Not because the AI doesn’t work, but because they’ll repeat MYCIN’s mistakes:

• Insufficient validation before deployment

• Integration challenges that create workflow islands

• Disruption to clinical processes that outweighs benefits

The tragedy is that we don’t have to repeat these mistakes. MYCIN taught us these lessons 50 years ago. The Stanford team documented everything—what worked, what didn’t, and why deployment failed despite technical success.

Yet here we are, making the same mistakes again because we’ve collectively forgotten or ignored this history.

The good news? Veterinary professionals have the power to change this. By demanding validation, insisting on integration, and evaluating workflow impact, you can pressure the market toward better AI tools.

Every time you ask a vendor “Where’s your published validation data?” or “How does this integrate with my PIMS?” or “Show me how this fits my workflow,” you’re making the market a little bit better.

MYCIN failed not because expert systems were a bad idea, but because the infrastructure, interoperability, and workflow integration weren’t ready. Some of those problems still aren’t solved in veterinary medicine.

Before you invest in AI tools for your practice, make sure they’ve learned MYCIN’s lessons. Because accuracy metrics and impressive demos won’t help you if the tool sits unused because it’s too hard to integrate or too disruptive to workflow.

After all, you already apply evidence-based thinking to every other aspect of veterinary practice. Why should AI be any different?

Key Insights for Veterinary Practice

📊 Demand MYCIN-Level Validation: If a 1970s research project could publish detailed evaluation methodology and results, commercial AI companies in 2025 can too. Don’t accept “proprietary” as an excuse.

🔌 Evaluate Integration Before Purchase: Ask specifically how the AI tool connects to your PIMS. Manual data entry and parallel documentation systems are red flags. Integration failures killed MYCIN—don’t let them kill your productivity.

⚡ Test Workflow Impact Early: Request trial periods that let you evaluate the tool in your actual workflow during busy periods. A tool that works in a demo may fail when you’re managing six exam rooms.

❓ Ask About Failure Modes: MYCIN’s developers openly discussed limitations. Ask vendors: When does your AI fail? How will I know? What happens to my workflow when it’s wrong?

🎯 Start with Narrow, Specific Problems: MYCIN succeeded at a focused task. Be skeptical of AI tools that claim to “do everything.” The best tools solve specific problems exceptionally well.

⚖️ Consider Liability Questions: MYCIN raised questions about responsibility when AI-recommended therapy failed. These questions remain unanswered. Understand who’s liable when AI tools integrated into your practice make errors.

Have you encountered AI tools that repeat MYCIN’s mistakes—great demos but impossible to integrate into actual practice? Or tools that require so much workflow disruption they sit unused? Share your experiences in the comments. Understanding where modern AI is failing helps us demand better solutions.

A framework from the dawn of medical informatics explains why some veterinary AI works brilliantly while the rest struggles—and why your data challenges aren’t going away.

In 1984, a UCSF dermatologist and medical informaticist named Marsden Blois published a book that should be required reading for anyone trying to understand why AI in medicine is so hard. “Information and Medicine: The Nature of Medical Descriptions” was written before the current AI revolution, before machine learning as we know it, before anyone had heard of large language models. Yet its core insights explain with remarkable precision why veterinary AI succeeds in some domains and fails spectacularly in others—and why the data integration problems I’ve been writing about aren’t merely technical challenges but fundamental properties of how clinical information works.

After 29 years in veterinary diagnostics, I’ve come to believe that Blois’s framework provides the missing theoretical foundation for understanding the challenges we face. It explains why DICOM-based imaging integration works seamlessly while practice management systems can’t agree on what to call a diagnosis. It explains why point-of-care coding has failed everywhere it’s been tried. And it suggests that modern large language models might represent a genuine breakthrough—not because they’re more powerful, but because they operate at a different level of clinical description than anything we’ve built before.

Subscribe now

The Hierarchy of Medical Description

Blois’s central insight was deceptively simple: medical descriptions exist along a continuum from highly abstract and general to highly specific and concrete. He visualized this as a funnel or inverted pyramid, with vague descriptions at the wide top and precise measurements at the narrow bottom.

At the wide end, you have descriptions like “this patient isn’t doing well” or “something’s wrong with this cat.” At the narrow end, you have serum creatinine of 2.3 mg/dL, or a genetic mutation at a specific chromosomal location, or a radiographic finding with precise measurements.

The diagnostic process, Blois argued, is essentially a journey through this hierarchy—starting with vague, undifferentiated presentations at the wide end and progressively narrowing toward specific characterizations at the bottom.

Consider a typical veterinary case: A Golden Retriever presents with “lethargy and not eating.” That’s the wide end—a description that encompasses hundreds of possible conditions. Through history-taking, physical examination, and diagnostic testing, we progressively narrow: perhaps “geriatric large-breed dog with weight loss, polyuria, and mild azotemia” becomes “chronic kidney disease” becomes “CKD Stage 2 based on IRIS classification with specific creatinine and SDMA values.”

Each step down the funnel represents a more specific, more precise description of the patient’s condition. And critically for understanding AI, each level of the funnel requires fundamentally different kinds of reasoning.

Why This Matters for AI: The Two Zones

Blois was writing during the heyday of expert systems—rule-based AI programs like MYCIN (more on the lessons from MYCIN in my next post) that attempted to encode medical knowledge as “if-then” rules. He observed something that remains true today: these systems worked reasonably well at the narrow end of the funnel but struggled at the wide end.

The reason is straightforward. At the narrow end, you’re dealing with specific, well-defined data: laboratory values with numeric ranges, imaging measurements with standard protocols, genetic variants with definitive presence or absence. This kind of information is highly amenable to algorithmic processing. You can write rules for it. You can train classifiers on it. The boundaries are clear, the data is structured, and the relationships can be specified precisely.

At the wide end, everything is different. “Not eating” could mean the patient refused breakfast once or hasn’t eaten in three days. “Lethargy” is inherently subjective—does the owner mean the dog is sleeping more, or collapsed and unresponsive? The same clinical presentation might represent a minor upset or a life-threatening emergency, and distinguishing between them requires judgment that’s extraordinarily difficult to formalize.

Blois was skeptical that AI (yes, rules-based programs fall under the AI umbrella as you’ll remember from my previous post) would ever handle the wide end of the funnel effectively. He argued that the vagueness and ambiguity at this level weren’t bugs to be fixed but essential features of clinical reasoning. When a patient presents with undifferentiated symptoms, the clinician must work with incomplete, uncertain, and often conflicting information. This requires a kind of gestalt pattern recognition that seemed fundamentally different from what computers could achieve.

For decades, he was right.

The Veterinary Data Problem Through Blois’s Lens

Reading Blois’s framework, the veterinary data challenges I’ve been writing about suddenly snap into focus. They’re not random technical problems—they’re predictable consequences of how clinical information actually works.

Why DICOM Works

In my article on veterinary software interoperability, I noted that DICOM-based imaging integration is the one area where veterinary medicine has achieved genuine plug-and-play interoperability. Walk into almost any veterinary practice with digital radiography, and the X-ray machine from Vendor A talks seamlessly to the PACS system from Vendor B, which displays images perfectly in the practice management system from Vendor C.

Blois’s framework explains why. Imaging data lives at the narrow end of the funnel. Images have standardized formats. Acquisition parameters can be precisely specified. Anatomical regions have agreed-upon terminology. Even when interpretation is involved, it’s applied to well-defined visual data with consistent presentation.

DICOM succeeds because it operates entirely within the zone where algorithmic processing works—the domain of specific, structured, well-defined information.

Why Semantic Interoperability Fails

In that same article, I identified the semantic layer—agreeing on what things mean—as veterinary medicine’s greatest unsolved interoperability challenge. Every practice uses different terminology for the same conditions: “DM” versus “diabetes mellitus” versus “endocrine disorder.” This chaos makes multi-practice data analysis nearly impossible.

Blois’s framework reveals why this problem is so intractable: practices aren’t just using different words for the same thing. They’re recording information at different levels of the hierarchy.

When one veterinarian records “DM” and another records “endocrine disorder,” these aren’t synonyms that can be mapped to each other through simple translation. “Endocrine disorder” sits higher on the funnel—it’s more abstract, less specific, encompassing a broader range of conditions. “DM” is further down, more precise but still not as specific as “Type 1 diabetes mellitus with secondary ketoacidosis.”

The semantic chaos in veterinary data reflects the fundamental variability in where along the diagnostic funnel clinicians choose to record their observations. Some veterinarians record highly specific diagnoses when they’re confident. Others prefer broader categories that acknowledge uncertainty. Still others record the level of specificity that’s relevant for the clinical decision at hand.

This isn’t sloppy data entry—it’s the natural expression of clinical reasoning at different levels of certainty and different stages of the diagnostic process.

Why Point-of-Care Coding Fails

I’ve argued previously that forcing veterinarians to code diagnoses at the point of care is doomed to fail, and that the solution has to happen on the backend through intelligent translation systems. Blois’s framework provides the theoretical explanation for why this is true.

Clinical reasoning naturally starts at the wide end of the funnel and progressively refines. When a veterinarian first sees that lethargic Golden Retriever, they’re genuinely uncertain about the diagnosis. Forcing them to select a specific ICD or SNOMED code at that moment doesn’t just slow down workflow—it demands artificial precision that doesn’t match their actual clinical state.

Even worse, forcing early coding constrains clinical expressiveness. Consider a complex case: a 12-year-old Golden Retriever with lethargy, mild azotemia, and a heart murmur that wasn’t present six months ago. The veterinarian suspects early kidney disease but can’t rule out cardiac involvement, and the breed predisposition for both conditions makes the diagnostic picture unclear.

Standard coding systems force this nuanced clinical picture into rigid categories. Is this “chronic kidney disease” or “heart murmur” or “lethargy”? The coding system demands a choice, but the clinical reality is uncertainty and interconnected possibilities. The veterinarian ends up either oversimplifying the case to fit the codes or spending excessive time trying to find codes that capture the full clinical complexity.

This loss of expressiveness isn’t just inconvenient—it’s clinically dangerous. Rich clinical narratives that capture complexity and uncertainty get reduced to simplistic code combinations that miss the subtleties crucial for patient care.

The solution, as I’ve argued, is to preserve the full richness of clinical expression at whatever level the veterinarian naturally describes, then apply intelligent backend systems to map those descriptions to standardized codes for data sharing and analysis. Blois’s framework shows why this approach aligns with the fundamental nature of clinical information.

The LLM Revolution: Why This Time Might Be Different

Blois was skeptical that AI would ever handle the wide end of the diagnostic funnel. The rule-based expert systems of his era certainly couldn’t. They required precise inputs, explicit knowledge encoding, and clear decision boundaries—all characteristics of the narrow end.

But large language models represent something genuinely new: AI systems that operate natively in natural language at varying levels of specificity.

When you describe a case to ChatGPT or Claude—”I have a 12-year-old Golden Retriever with lethargy and decreased appetite, mild azotemia on bloodwork, and a new heart murmur”—the model doesn’t demand that you first encode this into structured categories. It can work with the same natural language that veterinarians use to reason about cases, at whatever level of specificity you provide.

This doesn’t mean LLMs have solved the problems Blois identified. As I discussed in my article on hallucinations, LLMs can generate confident-sounding but incorrect information, and they can’t reliably access real-time databases or verify facts against authoritative sources. The wide end of the funnel remains challenging precisely because the information is inherently uncertain and ambiguous.

But LLMs do offer something that previous AI approaches couldn’t: the ability to work with clinical information across the full range of Blois’s hierarchy. They can discuss vague presentations and specific diagnoses in the same conversation, moving up and down the funnel as the clinical picture develops. They can preserve the rich expressiveness of natural language that gets lost when we force everything into structured codes.

This capability has profound implications for the backend translation systems I’ve advocated. Instead of requiring explicit rules mapping every possible clinical term to standard codes, LLM-based systems can potentially understand clinical intent across terminology variations and levels of specificity. They might finally bridge the gap between how veterinarians naturally document cases and the structured data needed for interoperability and analysis.

Implications for Evaluating Veterinary AI

Blois’s framework also provides a practical lens for evaluating AI tools, complementing the evaluation frameworks I’ve previously discussed.

Ask: Where on the Hierarchy Does This AI Operate?

When evaluating any AI tool, the first question should be: what level of clinical description does this system work with?

Tools operating at the narrow end—imaging analysis, laboratory interpretation, specific diagnostic predictions—work with well-defined data at the bottom of Blois’s funnel. These are the domains where AI has historically succeeded, and we have established methodologies for evaluation: sensitivity, specificity, likelihood ratios, receiver operating characteristic curves.

Tools operating at the wide end—clinical decision support, differential diagnosis generators, natural language interfaces—face fundamentally different challenges. They must handle vague inputs, uncertain reasoning, and the full messiness of undifferentiated clinical presentations. Evaluation here is more complex: we need to assess not just accuracy on well-defined cases but robustness across the full range of clinical uncertainty.

Understand the Mismatch Problem

Many AI failures occur when systems designed for one level of the hierarchy encounter data from another level.

An imaging AI trained on clear pathological findings may fail when presented with subtle or ambiguous images. A rule-based diagnostic system expecting specific symptoms may produce nonsensical recommendations when given vague chief complaints. A documentation AI trained on well-structured notes may struggle with the shorthand and abbreviations that veterinarians actually use.

Before implementing any AI tool, verify that the validation data matches the level of clinical description you’ll actually provide. A system validated on clear-cut cases may not perform nearly as well in the ambiguous situations that constitute most real clinical practice.

Recognize the Translation Challenge

Any AI system that must translate between different levels of the hierarchy faces particular challenges. This includes:

• Backend coding systems that map narrative documentation to structured codes

• Clinical decision support that takes vague presentations and suggests specific diagnoses

• Data integration platforms that normalize terminology across practices

These systems are attempting to bridge levels of Blois’s hierarchy—inherently more challenging than operating within a single level. Evaluate them with particular attention to how they handle uncertainty and ambiguity rather than just their performance on clear-cut cases.

The Path Forward

Understanding Blois’s framework doesn’t solve our problems, but it does help us approach them more realistically.

First, we should stop treating data inconsistency as a problem to be eliminated and start treating it as a fundamental property of clinical information that must be accommodated. Practices will always record information at different levels of specificity because they’re capturing different stages of clinical reasoning. Our systems need to handle this variability rather than demanding artificial uniformity.

Second, we should invest in backend translation systems that can work across Blois’s hierarchy—systems that preserve rich clinical narratives while extracting standardized codes for data sharing. Large language models may finally provide the capability to build such systems effectively, though significant development work remains.

Third, we should evaluate AI tools against realistic clinical scenarios that include the full range of uncertainty and ambiguity found in practice—not just the clear-cut cases where AI has historically excelled.

Finally, we should maintain appropriate humility about what AI can accomplish in clinical medicine. Blois’s core insight—that different levels of clinical description require fundamentally different kinds of reasoning—remains valid. Even as AI capabilities advance, the wide end of the diagnostic funnel will likely remain the domain where human clinical judgment is most essential.

Key Insights for Veterinary Practice

📊 Recognize the hierarchy in your own documentation. Notice when you’re recording vague observations versus specific diagnoses. Both are valid and necessary—they represent different stages of clinical reasoning. Systems that force premature specificity are working against the natural diagnostic process.

🔍 Match AI tools to appropriate levels. Imaging AI, laboratory interpretation, and specific diagnostic predictions operate at the narrow end of Blois’s hierarchy and can be evaluated with traditional accuracy metrics. Decision support and natural language tools operate higher on the hierarchy and require different evaluation approaches.

📋 Demand validation at realistic specificity levels. When evaluating AI tools, ask whether the validation data matches your actual practice. A system that performs brilliantly on textbook cases may struggle with the vague presentations and clinical uncertainty that constitute most real-world practice.

🔄 Support backend translation approaches. Rather than demanding that your staff code everything at entry, look for systems that can accept natural language documentation and apply intelligent coding on the backend. This approach aligns with how clinical reasoning actually works.

📝 Preserve clinical expressiveness. Resist pressure to sacrifice the richness of clinical narrative for the convenience of structured data entry. The nuances captured in natural language—uncertainty, interconnected possibilities, clinical reasoning—are often exactly the information that matters most for patient care.

🧠 Understand why semantic chaos persists. The terminology variations across practices aren’t just different words for the same thing—they often represent recording at different levels of clinical specificity. This is why simple synonym mapping doesn’t solve interoperability, and why more sophisticated translation approaches are needed.

⚖️ Maintain appropriate expectations. Even as AI advances, the wide end of the diagnostic funnel—where presentations are vague, uncertainty is high, and clinical judgment is most critical—will likely remain the domain where human expertise is irreplaceable. AI tools are most valuable when they complement rather than attempt to replace this judgment.

Blois died in 1988, four years after publishing “Information and Medicine.” He didn’t live to see either the AI winter that followed or the remarkable renaissance we’re experiencing today. But his insights about the fundamental nature of clinical information—written when computers were room-sized and the internet didn’t exist—remain remarkably relevant for anyone trying to make AI work in veterinary medicine.

The book is out of print but available through used book sellers and some academic libraries for those wanting to explore further.

How do Blois’s concepts resonate with your own experience of clinical reasoning? Have you encountered AI tools that work well at one level of clinical description but struggle at another? I’d love to hear your observations—they help shape how I think about these frameworks and their practical applications.

Three shifts are converging that will fundamentally transform how veterinary software is built, sold, and used. If you’re building veterinary software, your business model is about to change. If you’re buying it, your evaluation criteria need to change first.

Shift 1: The Cost of Building Software Is Collapsing

Eighteen months ago, building a veterinary practice management system required a team of developers working for years. Today, AI coding agents—tools like Claude Code, Codex, Gemini and Cursor—are fundamentally changing that equation.

I’ve watched developers build functional applications in hours that would have taken weeks. Not toy demos—working software with databases, user interfaces, and business logic. The technology isn’t perfect, but it’s improving at a pace that should concern any software company whose primary value proposition is “we wrote a lot of code.”

What does this mean for veterinary software? The barrier to entry is dropping rapidly. A veterinarian with a specific workflow frustration and some technical inclination can now build a tool to solve it. A small startup can compete with established players on features, if not on scale.

This doesn’t mean established companies will disappear overnight. But it does mean that “we have more developers” is no longer a sustainable competitive advantage. The moat has to be somewhere else.

Subscribe now

Shift 2: The Hard-Coded Interface Is Dying

This idea came to me from Nate Jones in his video “Agents Will Kill Your UI by 2026—Unless You Build This Instead”, and it’s worth sitting with: the static user interface—buttons in fixed locations, menus you memorize, workflows you adapt to—is a temporary artifact of technological limitation, not an ideal end state.

Think about how you interact with your practice management system today. You’ve learned where things are. You’ve developed muscle memory. When the vendor updates the interface, you’re frustrated because everything moved. The software doesn’t adapt to you; you adapt to it.

Now imagine an interface that’s generated dynamically based on what you’re trying to accomplish, used once, and then discarded. You’re checking in a patient for a dental procedure? The interface shows you exactly what you need for that task—nothing more, nothing less. You’re reviewing lab results for a complex internal medicine case? Different interface, optimized for that specific context.

This isn’t science fiction. The underlying technology—large language models that can generate functional user interfaces from natural language descriptions—exists today. It’s clunky and unreliable for critical applications, but it’s improving monthly.

The implication is profound: learning a software system becomes obsolete. The cognitive load of remembering where things are disappears. The interface becomes invisible because it’s perfectly fitted to the task.

Shift 3: The Agent Becomes the Interface

Take the previous idea one step further. What if the primary interface isn’t visual at all?

Imagine a system that knows you’re Dr. Martinez, it’s Tuesday afternoon, you just finished a complicated GDV surgery, and now you need to review lab results for the diabetic cat in Room 3. You don’t navigate to a screen—you simply say what you need, and the system understands the context without you explaining it.

“What were Whiskers’ last three glucose curves?”

The system knows which patient you mean because it knows where you are and what you’re doing. It knows how you prefer to see glucose data displayed. It knows you’re about to have a conversation with the owner and anticipates you might want to see the treatment history too.

This is the natural language interface that’s context-aware and personalized. The “software” becomes an intelligent agent that understands veterinary medicine, understands your practice, and understands you.

What This Means If You’re Building Veterinary Software

Your code is becoming commoditized. Within a few years, the act of writing software will be dramatically cheaper and faster than it is today. If your competitive advantage is your codebase, you need a new strategy.

What remains valuable? Domain expertise that can’t be easily replicated. Deep understanding of veterinary workflows. High-quality, structured data that can train and ground AI systems. Relationships and trust built over years.

The companies that thrive will be those that can feed intelligent agents with accurate, veterinary-specific knowledge—not those that can write the most elegant code. If you’ve been investing in understanding how veterinarians actually work, that investment is about to pay off. If you’ve been coasting on a functional product without deepening your domain expertise, the window is closing.

What This Means If You’re Buying Veterinary Software

Stop evaluating software based on interface polish. That shiny, intuitive interface you’re paying premium prices for? It’s about to become table stakes, then commodity, then irrelevant.

Start asking different questions: How deep is this company’s understanding of veterinary medicine? What data do they have, and how is it structured? How well-positioned are they to support AI-powered workflows? What happens to my data if I want to leave?

The practices that document thoroughly—even in messy natural language—will be positioned to benefit most from intelligent agent interfaces. The practices that have been disciplined about data quality will have advantages over those that haven’t.

And perhaps most importantly: be prepared for the switching costs between systems to drop dramatically. If the interface is generated dynamically, the pain of “learning a new system” largely disappears. Your leverage as a buyer is about to increase significantly.

The Uncomfortable Questions

I don’t have all the answers here. These shifts raise questions that the veterinary industry hasn’t grappled with yet:

How do you validate AI-generated software for clinical use? When the interface changes dynamically, what does “training staff” even mean? How do regulatory frameworks adapt when the software is different every time it’s used? What happens to the specialized knowledge that practice managers have accumulated about making current systems work?

These are the conversations we need to be having now, before the technology forces them upon us.

The veterinary software industry has been relatively stable for decades. The same basic paradigm—buy a system, learn it, live with its limitations—has persisted through multiple technology generations. That paradigm is ending.

Whether you’re building or buying, the time to start thinking differently is now.

Leave a comment

Andrej Karpathy, OpenAI co-founder and one of the world’s most respected AI researchers, recently appeared on a podcast and made headlines with his prediction: useful AI agents are about a decade away. He described current AI agents as lacking memory, robustness, and reliability—concerns that resonate with anyone who’s actually tried to build production AI systems.

But here’s what caught my attention more than the prediction itself: the certainty. The timeline. The “decade away” framing that sounds so measured and reasonable, especially compared to the breathless “AGI by 2027” predictions we’re hearing elsewhere.

The problem? I’ve heard this story before. Many times. And if there’s one thing the history of AI teaches us, it’s that brilliant people are spectacularly, consistently, almost comically bad at predicting when their technologies will actually be ready.

Let me show you what I mean.

A Note on Sources: Before we dive into AI history, I strongly encourage you to listen to Andrej Karpathy’s full interview. It’s genuinely excellent—thoughtful, measured, and packed with insights from one of the world’s true experts in AI. His discussion of current AI capabilities, limitations, and the practical challenges of building AI systems is invaluable. If you’re short on time, Nate Jones has an excellent summary video highlighting key points.

My focus in this article is specifically on the timeline prediction, not the substance of Karpathy’s technical insights, which are spot-on. The irony is that his careful, detailed explanation of current AI limitations makes a compelling case for why his own timeline might be optimistic. But I’m using his prediction as a jumping-off point precisely because it’s measured and comes from someone credible—not because I think he’s wrong about the technology itself.

The Pattern of Optimism

Marvin Minsky, 1970: “In from three to eight years we will have a machine with the general intelligence of an average human being.” One of the founding fathers of AI, a brilliant mind who shaped the entire field, confidently predicted human-level AI would arrive between 1973 and 1978. We’re still waiting.

Elon Musk, 2015: Speaking at an Nvidia conference, Musk declared autonomous driving “a solved problem” and said Tesla would deliver it “in a few years.” He told the world: “I view it as a solved problem. We know exactly what to do and we will be there in a few years.”

That was ten years ago.

Since then, Musk has promised full self-driving capabilities would arrive “next year” in:

• 2014 (for 2016)

• 2015 (for 2017-2018)

• 2016 (for 2018, predicting you could summon your Tesla from across the country)

• 2017 (for 2019, saying you’d be able to sleep in your car)

• 2018 (for 2019)

• 2019 (for 2020, promising “feature complete” FSD)

• 2020 (for 2021, predicting Level 5 autonomy)

• 2021 (for 2022)

• 2022 (for 2023)

In a 2023 lawsuit, Tesla’s lawyers successfully argued that Musk’s statements about self-driving timelines constituted “corporate puffery”—essentially, marketing fluff not to be taken seriously. Yet he continues making the same predictions.

Herbert Simon, 1965: “Machines will be capable, within twenty years, of doing any work a man can do.” Nobel Prize winner, pioneer of AI research. His twenty-year prediction would have meant general AI by 1985.

Geoffrey Hinton, 2016: “I think that if you work as a radiologist you are like Wile E. Coyote in the cartoon. You’re already over the edge of the cliff, but you haven’t yet looked down. There’s no ground underneath.” He predicted that within five years, deep learning would surpass radiologists, advising young doctors against specializing in radiology.

That was nine years ago. Radiology as a specialty is thriving, AI-assisted radiology is valuable, but radiologists haven’t fallen off the cliff. Hinton was right about the capability—AI can analyze images remarkably well. He was completely wrong about the timeline and the replacement scenario.

Roger Schank and Marvin Minsky, 1984: At an AI conference, these two leaders who had survived the 1970s AI winter warned that enthusiasm for expert systems had “spiraled out of control” and disappointment would follow. They were right about the disappointment—but notably, they themselves had been the optimists a decade earlier. The expert systems boom that began around 1980 was built on predictions that these systems would revolutionize corporate decision-making and capture human expertise at scale. By 1985, the AI industry had grown to over a billion dollars. By 1987, it had collapsed.

The pattern is unmistakable: brilliant people, genuine breakthroughs, wildly optimistic timelines, eventual disappointment, followed by... the next generation of brilliant people making wildly optimistic timelines again.

A Brief History of AI: Cycles That Keep Repeating

Understanding where we are requires knowing where we’ve been. The history of AI isn’t just interesting—it’s instructive. Let me walk you through it.

Before AI Had a Name (1950): The Turing Test

Before the Dartmouth Conference formally launched AI as a field, Alan Turing laid the theoretical groundwork. In his 1950 paper “Computing Machinery and Intelligence,” he proposed what became known as the Turing Test and made a prediction: by the year 2000, machines would be able to fool an average interrogator at least 30% of the time. His 50-year timeline was notably longer than the predictions that would follow—and more accurate. By 2000, chatbots could indeed fool some people some of the time. But we still lack the general intelligence Turing envisioned. Even his measured prediction captures the persistent gap between narrow capability and true understanding.

The Beginning (1956): Summer Dreams

It started with breathtaking ambition. In the summer of 1956, John McCarthy, Marvin Minsky, Claude Shannon, and Nathaniel Rochester organized the Dartmouth Summer Research Project on Artificial Intelligence. This wasn’t just a conference—it was the birth certificate of AI as a field.

Their proposal was audacious: “We propose that a 2-month, 10-man study of artificial intelligence be carried out during the summer of 1956 at Dartmouth College... The study is to proceed on the basis of the conjecture that every aspect of learning or any other feature of intelligence can in principle be so precisely described that a machine can be made to simulate it.”

The goal? Solve human-level AI in a single summer.

This set the pattern for everything that followed: brilliant people, genuine insights, and wildly optimistic timelines. They believed that the hard problems of intelligence were just around the corner from being solved.

The Golden Years (1956-1974): Early Success Breeds Overconfidence

The next two decades seemed to validate the optimism. Progress came quickly in narrow domains:

Game Playing: Researchers demonstrated that computers could play tic-tac-toe, checkers, and increasingly sophisticated games. Arthur Samuel’s checker-playing program could beat most human players by 1962. This seemed like proof that machines could “think.”

Natural Language: Joseph Weizenbaum’s ELIZA (1966) could simulate a Rogerian psychotherapist well enough that some users became emotionally attached to it, sharing intimate details despite knowing it was a program. If a simple pattern-matching program could fool people into thinking it understood them, surely true language understanding was close.

Problem Solving: Allan Newell and Herbert Simon developed the General Problem Solver, which could solve a range of problems through search. They weren’t shy about their predictions. Simon famously declared in 1965 that “machines will be capable, within twenty years, of doing any work a man can do.”

Robotics: The Stanford Cart navigated obstacle courses. Programs could stack blocks in response to natural language commands. Shakey the Robot could navigate rooms and push objects. The dream of general-purpose robots seemed tantalizingly close.

Expert Systems (early versions): DENDRAL (1965) could identify chemical compounds from spectrometer data. These early successes suggested that capturing expert knowledge in computational form was tractable.

The progress was real. The error was assuming that these narrow successes would scale smoothly to general intelligence. Researchers consistently underestimated the difference between solving well-defined problems in constrained domains and handling the messy, open-ended complexity of the real world.

First AI Winter (1974-1980): Reality Bites

In 1973, British mathematician Sir James Lighthill published a devastating report on AI research, commissioned by the UK Parliament. His conclusion was brutal: AI had failed to deliver on its promises. The problems were much harder than anticipated. The techniques didn’t scale.

The report triggered funding cuts in the UK. In the US, DARPA (Defense Advanced Research Projects Agency) became increasingly frustrated with the lack of progress in speech recognition and other areas. The money dried up. AI research slowed to a crawl.

The first hard lesson: narrow success in toy problems doesn’t predict success in real-world complexity. The “commonsense knowledge problem” emerged as a seemingly insurmountable barrier. How do you teach a computer everything a five-year-old knows about how the world works?

What researchers got wrong: They thought intelligence was primarily about logical reasoning and search. They underestimated the importance of knowledge, learning, and dealing with uncertainty. They believed the path from simple demonstrations to general intelligence was shorter than it was.

The Boom Years (1980-1987): Expert Systems and New Hope

AI came roaring back in the 1980s with a different approach: expert systems. Instead of trying to create general intelligence, why not capture the specific knowledge of human experts in narrow domains?

The success stories were compelling:

MYCIN (developed in the 1970s, commercialized in the 1980s) diagnosed bacterial infections and recommended treatments, reportedly performing at the level of expert physicians in its narrow domain.

XCON, developed for Digital Equipment Corporation, configured computer systems and was estimated to save the company $40 million over six years.

The Cyc Project, started in 1984 by Doug Lenat, aimed to solve the commonsense knowledge problem by manually encoding all human common sense knowledge. The timeline? Ten years to encode everything humans know. (Spoiler: It’s 2025, and Cyc is still being developed.)

The AI industry exploded. By 1985, corporations were spending over a billion dollars on AI. Specialized LISP machines were created by companies like Symbolics and Lisp Machines Inc. AI consultancies went public. Universities expanded their AI departments.

Predictions of the era: Expert systems would revolutionize business decision-making. Knowledge could be captured and replicated at scale. AI was finally becoming practical.

Chess programs continued improving rapidly, adding to the sense that machine intelligence was inevitable and imminent.

Neural networks also experienced a resurgence during this period. The development of backpropagation in the mid-1980s by Rumelhart, Hinton, and Williams provided a way to train multilayer networks, reigniting interest in connectionist approaches to AI.

Second AI Winter (1987-1993): The Boom Becomes a Bust

Then it all came crashing down.

In 1987, the market for specialized LISP machines collapsed. Desktop computers from Apple and IBM had become powerful enough and cheap enough to make specialized AI hardware obsolete. Companies like Symbolics, which had been the darling of the AI boom, filed for bankruptcy in the 1990s.

More fundamentally, the limitations of expert systems became painfully apparent:

Brittleness: Expert systems made grotesque mistakes when given unusual inputs. They couldn’t handle cases outside their narrow training.

Maintenance nightmares: Systems like XCON became too expensive to maintain. Every time the business changed, the knowledge base needed extensive manual updates.

Knowledge acquisition bottleneck: It turned out that extracting knowledge from human experts and encoding it into rules was extraordinarily difficult. Experts often couldn’t articulate what they knew. Their knowledge was tacit, contextual, and nuanced in ways that rule-based systems couldn’t capture.

Scaling problems: The hope had been that adding more rules would make systems more capable. Instead, rule bases became unwieldy, contradictory, and impossible to manage.

The qualification problem: How do you specify all the conditions under which a rule applies? Every rule needed endless qualifications and exceptions.

The dream of capturing and replicating human expertise at scale foundered on the messy reality of how knowledge actually works.

Investment dried up. The term “AI winter” was coined. Companies avoided using “AI” in their marketing. Researchers rebranded their work as “informatics,” “knowledge systems,” or “computational intelligence” to avoid the stigma.

What they got wrong: They thought knowledge was the bottleneck and that capturing it in explicit rules would solve the problem. They underestimated how much human expertise relies on pattern recognition, intuition, and contextual understanding that can’t easily be reduced to logical rules. They didn’t anticipate the maintenance burden of keeping rule-based systems current.

The Rebirth (1993-2011): Quiet Progress and Practical Applications

Something interesting happened during the so-called “AI winter” of the early 1990s: AI quietly became useful.

Researchers shifted away from trying to build general intelligence and focused instead on specific, well-defined problems. They moved away from pure logical reasoning toward statistical methods and machine learning.

1997: Deep Blue defeats Kasparov: IBM’s chess program beat the world champion, making headlines worldwide. But here’s what’s important to note: Deep Blue was brilliant at chess and useless at everything else. It was the ultimate narrow AI. The lesson? Superhuman performance in a specific domain doesn’t translate to general intelligence.

Probabilistic reasoning: Judea Pearl’s work on Bayesian networks in the 1980s finally gained traction, providing a rigorous framework for reasoning under uncertainty. This turned out to be far more useful than the certainty-based logic of expert systems.

Machine learning emerges: Instead of hand-coding knowledge, systems learned patterns from data. Support Vector Machines, decision trees, and various statistical methods became the workhorses of practical AI.

AI goes mainstream (invisibly): Speech recognition improved. Spam filters worked. Recommendation systems suggested movies and products. Credit card fraud detection became practical. But these successes were rarely called “AI” because, as Rodney Brooks noted, “Once something becomes useful enough and common enough, it’s not labeled AI anymore.”

2011: Watson wins Jeopardy: IBM’s question-answering system defeated champion players Ken Jennings and Brad Rutter. Like Deep Blue, Watson demonstrated impressive capability in a specific domain, but it was a narrow system, not a path to general intelligence.

This era was characterized by steady, incremental progress on specific problems rather than grand promises about general AI. Researchers became more modest in their claims, perhaps having learned from the previous winters. The field delivered working solutions but largely stayed out of the hype cycle.

The Deep Learning Revolution (2012-2022): Suddenly, Neural Networks Work

Everything changed in 2012. Or more precisely, everything that had been slowly changing for years suddenly became visible.

2012: AlexNet and the ImageNet breakthrough: A deep convolutional neural network developed by Alex Krizhevsky, Ilya Sutskever, and Geoffrey Hinton won the ImageNet competition by a massive margin. Computer vision went from barely working to suddenly working remarkably well. Deep learning was back, and this time it was different.

Why did it work now? Three things converged:

1. Computational power: GPUs (graphics processing units) turned out to be perfect for training neural networks. What had taken weeks could now be done in hours.

2. Data: The internet had created massive datasets for training. ImageNet alone contained millions of labeled images.

3. Algorithmic improvements: Better training techniques, improved architectures, and refined methods made deep networks trainable at scale.

2016: AlphaGo defeats Lee Sedol: DeepMind’s system beat one of the world’s best Go players at a game long thought to be beyond computer capability. Unlike chess, Go’s complexity seemed to require intuition and creativity, not just brute-force search.

Practical applications explode: Speech recognition became genuinely useful. Machine translation improved dramatically. Image recognition worked well enough to deploy in products. Self-driving car research accelerated.

And with success came... renewed predictions of imminent general AI.

This era felt different: Unlike previous waves, deep learning systems seemed to capture something about how intelligence actually works—learning hierarchical representations from data. The successes were broader, more robust, more impressive.

But they were still narrow. AlphaGo was brilliant at Go and couldn’t do anything else. The best image recognition systems couldn’t explain what they saw. Self-driving systems, despite massive investment, remained stubbornly difficult.

The LLM Era (2022-Present): The Latest Wave

Then came November 2022 and ChatGPT. Suddenly, AI wasn’t just good at specific tasks—it could have conversations, write essays, help with coding, answer questions across domains.

Large Language Models (LLMs) like GPT-4, Claude, and others demonstrated capabilities that felt qualitatively different. They could handle multiple domains without being explicitly trained for each. They exhibited something that looked like reasoning. They could learn from examples in context. They understood and generated human language with startling fluency.

The public impact was immediate and dramatic. Within two months, ChatGPT had 100 million users. Every major tech company scrambled to deploy or develop LLMs. AI stopped being a niche technology concern and became a mainstream topic of conversation.

And with it came a new wave of predictions: “AGI by 2027,” “All white-collar jobs will be transformed within five years,” “Level 5 autonomous vehicles are just around the corner.” Or, from the more measured Andrej Karpathy: useful AI agents are “a decade away.”

But notice what’s actually happened. LLMs are remarkable tools. They’re genuinely useful for many tasks. They’re being deployed widely and creating real value. And yet they hallucinate—confidently stating false information. They struggle with mathematical reasoning. They can’t reliably follow complex multi-step procedures. They have no persistent memory across conversations without architectural additions. They require significant human guidance and oversight for most applications.

They’re incredibly valuable narrow AI systems. They’re not AGI. They’re not even close.

What We’re Still Getting Wrong

Geoffrey Hinton’s radiology prediction is instructive not because he was completely wrong—he was partially right. AI systems can analyze medical images with impressive accuracy. Radiology AI tools are being deployed and are valuable.

But let’s look at what actually happened instead of what he predicted:

What Hinton predicted (2016): Within five years, AI would surpass human radiologists. Training new radiologists would be pointless.

What actually happened (2025):

• AI radiology tools exist and work well in specific, well-defined tasks

• Radiologists use these tools to augment their work, not replace it

• Demand for radiologists remains strong

• The bottleneck turned out to be integration, workflow, validation, trust, regulation, and liability—not capability

• Radiologists spend significant time on tasks AI can’t handle: communicating with patients, integrating clinical context, making judgment calls in ambiguous cases, coordinating care

In veterinary medicine, we’ve seen the same pattern. Veterinary radiology AI tools exist and are valuable. They assist veterinarians. They haven’t replaced anyone.

The gap between “technically possible” and “practically deployed at scale” remains enormous.

Why Predictions Keep Failing

If brilliant people keep making the same mistake, maybe it’s not that they’re not smart enough. Maybe there’s something systematic going on.

They underestimate “last mile” problems: The final 10% of capability often takes 90% of the effort. Getting a self-driving car to work 90% of the time is impressive. Getting it to work 99.99% of the time—reliable enough that you’d trust your life to it in all conditions—is orders of magnitude harder.

They confuse narrow success with general capability: Every AI breakthrough has been in a specific domain. Chess, Go, image recognition, language modeling—these are all narrow capabilities, no matter how impressive. The jump from narrow to general intelligence might not be incremental progress; it might be a fundamentally different problem.

They miss the human, institutional, and regulatory factors: Technology doesn’t deploy itself. It requires workflow integration, user training, regulatory approval, liability frameworks, economic incentives, and cultural acceptance. These take time—often far more time than developing the technology itself.

They don’t account for the integration challenge: Making an AI system work in a demo is different from making it work in production. Production means handling edge cases, integrating with existing systems, providing explainability, ensuring reliability, managing failures gracefully, and maintaining the system over time.

They’re on the cutting edge, and that distorts perspective: When you’re building the technology, you see the rapid progress. Every week brings improvements. From that vantage point, the remaining challenges can seem solvable “in just a few more years.” But from the trenches of deployment, those challenges loom much larger.

They discount the difference between “works in the lab” and “works reliably enough to bet lives and businesses on”: The standard for deployment is far higher than the standard for publication.

A Personal Note: Living in the Tension

I need to acknowledge something that might seem contradictory. I was recently co-author on a whitepaper (”Artificial Intelligence in Companion Animal Veterinary Medicine: Transformation Ahead!”) that predicted significant changes in veterinary practice within 1-2 years. So am I contradicting myself by warning against short timelines?

Not quite. The key is distinguishing between predictions about deploying existing capabilities versus predictions about revolutionary new capabilities.

Our whitepaper focused on the first type. Scribing tools like CoVet and ScribbleVet exist today and work. LLMs like ChatGPT and Claude are already being used by pet owners. Price comparison is technically possible right now. These aren’t predictions about future breakthroughs—they’re predictions about adoption and market dynamics.

This article warns against the second type: predictions about AGI arriving on schedule, AI “agents” that reliably handle complex multi-step tasks autonomously, or AI systems that truly replace professionals rather than assist them.

Our whitepaper’s predictions—even the medium and long-term ones—assume only steady, incremental progress in AI capabilities. We’re not betting on breakthroughs. We’re betting on adoption curves, market dynamics, and natural evolution. When we predict “veterinary service price inflation will moderate” in 2-5 years, that doesn’t require new AI capabilities. It requires pet owners using tools that exist today to comparison shop.

Short timelines can be realistic when you’re predicting adoption of tools that work today, market responses to existing capabilities, and gradual evolution. Short timelines are consistently wrong when you’re predicting revolutionary new capabilities or fundamental technical breakthroughs.

So yes, adopt AI tools aggressively—but adopt what works today for its value today, not what’s promised for tomorrow.

What This Means for Veterinary Medicine

So what does all this history mean for you as a veterinary professional being pitched AI tools?

The Questions to Ask

When a vendor tells you their AI tool will “transform your practice in the next 2-3 years,” you need to dig deeper than the demo.

Start with evidence of actual deployment. Not demos. Not pilot studies. Actual sustained use at scale. How many practices are using it? For how long? With what outcomes? This is the difference between established tools like Radimal (processing tens of thousands of radiographs) and a startup showing you an impressive demo. Real-world deployment reveals the gap between “works in the lab” and “works reliably enough to bet your practice on.”

Focus relentlessly on current capability, not promised future. What does it do today, right now, that you could use? Ignore promises about what it will do next year. Evaluate what it actually does. If it’s valuable now, consider it. If its value depends on future development, be skeptical. The history of AI is littered with tools that would have been revolutionary “once we add the next feature.”

Examine the integration reality. Does it work with your PIMS? What training does it require? What happens when it’s wrong? Who is liable if something goes wrong? How much time does it actually save versus add? The last-mile problems of workflow integration consistently take far longer than vendors admit. A tool that saves time in a demo can add friction in daily practice if it doesn’t fit your actual workflow.

Demand a real evidence base. Has it been validated in peer-reviewed publications or through independent evaluation? On what population? In what settings? What are its failure modes? What are its limitations? Most veterinary AI tools exist at the bottom of the evidence pyramid—vendor claims and testimonials. A few are moving up to published case studies. Very few have rigorous independent evaluation with disclosed methodology. Adjust your confidence accordingly.

Identify the actual problem being solved. Not “what could it theoretically do,” but “what specific pain point in my practice does this address right now?” Is that problem worth the cost and integration effort? The most successful AI deployments solve a clear, immediate problem that the practice already recognizes. If you need the vendor to explain why you should want their tool, that’s a warning sign.

Learning from History

The history of AI teaches us several lessons that apply directly to veterinary practice:

Capability doesn’t equal replacement: Hinton was right that AI can analyze images very well. He was wrong that this would make radiologists obsolete. Why? Because radiology isn’t just image analysis—it’s clinical integration, communication, judgment under uncertainty, and liability. The same applies in veterinary medicine. AI might assist with diagnoses, but diagnosing is only one part of veterinary care.

Deployment is slower than capability development: Even when technology works, integrating it into complex professional workflows takes time. Much more time than developers think.

The most useful AI is often invisible: The AI that makes it into practice successfully often isn’t marketed as revolutionary. It’s the spam filter, not the general intelligence. In veterinary medicine, the most successful AI tools might be the ones that quietly improve your PIMS, optimize your schedule, or flag abnormal lab values—not the ones promising to transform everything.

Hype cycles are real: AI goes through boom and bust cycles. We’re in a boom now. History suggests we’ll hit limitations that seem obvious in retrospect but aren’t apparent from inside the hype cycle. That doesn’t mean AI isn’t valuable—it means the trajectory is bumpier than current predictions suggest.

The Practical Path Forward

None of this means you should ignore AI. It means you should be strategic:

Adopt what works now: If an AI tool solves a real problem you have today, and there’s evidence it works at scale, consider it. Don’t wait for the perfect tool that might arrive “next year.”

Prepare for gradual evolution, not revolution: Build AI literacy in your practice. Start with small implementations. Develop institutional knowledge. When better tools come along—and they will—you’ll be ready to evaluate and adopt them thoughtfully.

Invest in fundamentals, not promises: Rather than betting on a specific AI platform that promises to do everything in the future, invest in your team’s understanding of AI capabilities and limitations. Invest in data practices that will make any AI tool more effective. Invest in workflows that can accommodate AI assistance.

Apply the “10x timeline rule”: This is my personal heuristic after studying AI history: When someone predicts a capability will arrive in X years, mentally prepare for 10X years. If they say “two years,” think “twenty years.” If they say “a decade,” think “a century.” This isn’t because they’re lying—it’s because the history of AI shows that even brilliant people consistently underestimate how long it takes for capability to become reliable, deployable, integrated reality.

Continuity over rupture: One of the most valuable insights from Karpathy’s recent podcast—even as he predicted agents are a decade away—is his emphasis on continuity. Plan for steady, compounding progress. Don’t bet your practice on revolutionary transformation happening on a specific timeline. Build systems that work with gradual improvement.

Be the skeptical adopter: Enthusiasm without skepticism leads to disappointment and wasted resources. Skepticism without openness means you miss real opportunities. The sweet spot is being a thoughtful early adopter who demands evidence but remains open to genuine innovation.

Key Insights for Veterinary Practice

1. Apply the “10x timeline rule”: When AI vendors or experts predict capabilities in X years, mentally prepare for 10X years. History shows even brilliant people consistently underestimate timelines by an order of magnitude.

2. Evaluate on current capability, not promised future: Purchase and implement AI tools based on what they demonstrably do today, not what they promise to do next year. If the value proposition requires future development, approach with extreme caution.

3. Demand evidence of deployment at scale: Demos and pilot studies are not evidence. Look for: (a) number of sites using it in production, (b) duration of use, (c) published validation data, (d) post-market performance monitoring.

4. Distinguish capability from replacement: AI that can perform a task well doesn’t mean it will replace the professional doing that task. Hinton was right about radiology AI capability but completely wrong about radiologists becoming obsolete. The gap between “can analyze images” and “replaces a radiologist” includes clinical judgment, communication, integration with patient context, liability, and workflow complexity.

5. Investigate the last mile intensively: The gap between “works in a demo” and “works reliably in my practice every day” is enormous. Ask specifically about: PIMS integration, training requirements, failure handling, liability, time investment (setup and ongoing), edge case performance, and vendor support quality.

6. Plan for gradualism, not revolution: History shows AI progress is steady and incremental, punctuated by breakthroughs that still require years to mature into deployable systems. Build AI literacy in your team now. Start with modest implementations. Create institutional knowledge. Don’t wait for the perfect tool, but don’t bet the practice on revolutionary change arriving on schedule.

7. Follow the evidence pyramid:

   • Top: Independent evaluation or peer-reviewed validation studies with disclosed methodology

   • Middle: Published case studies from multiple practices

   • Bottom: Vendor claims and testimonials

   Most veterinary AI tools are at the bottom. A few are moving up. Adjust your confidence accordingly.

8. Recognize pattern recognition is not clinical reasoning: LLMs are impressive at pattern matching in text. But clinical reasoning involves causal thinking, understanding pathophysiology, integrating physical exam findings with history and diagnostics, considering patient-specific factors, and reasoning about uncertainty. These are different cognitive processes. An AI that can write plausible case notes isn’t necessarily doing the reasoning required for diagnosis and treatment planning.

9. Remember the capability plateau: Every AI approach hits limitations. Expert systems in the 1980s seemed revolutionary until they didn’t scale. Neural networks in the 1990s seemed limited until they weren’t. Current LLMs will hit walls we don’t yet see clearly. This doesn’t make them useless—it makes them tools with boundaries that will become apparent over time.

10. Develop your AI evaluation framework now: Create criteria for assessing AI tools before you need them. Include: evidence requirements, integration feasibility assessment, workflow impact analysis, liability considerations, cost-benefit analysis, and failure mode planning. Having this framework means you can evaluate new tools quickly and systematically rather than being swayed by impressive demos or aggressive sales tactics.

Conclusion

Are we a decade from AGI? Almost certainly not. History suggests we’re much further away than even measured predictions like Karpathy’s suggest. The gap between impressive demos and reliable, deployable, integrated systems is consistently larger than experts predict.

But here’s the surprising part: that’s actually good news for veterinary practitioners.

You have time. Time to learn about AI thoughtfully rather than being rushed into adoption. Time to watch the technology mature. Time to see which tools actually deliver value in practice rather than in demos. Time to develop your own evaluation criteria. Time to build the workflows and institutional knowledge that will make AI adoption successful when the right tools emerge.

The tools we have today—LLMs like Claude and ChatGPT, image analysis systems, diagnostic support tools—are already valuable. They can help with client communication, documentation, research, and specific diagnostic tasks. Use them. Learn from them. But use them knowing their current limitations, not their promised futures.

The veterinary profession has always been good at adopting technology thoughtfully. We’re evidence-based by training. We’re skeptical of unproven claims. We care deeply about patient outcomes. These instincts serve us well with AI.

Learn from the history. Every AI boom has promised that general intelligence is just a few years away. Every boom has been followed by a recognition that the problems were harder than they appeared. But every boom has also left behind practical tools that, while not revolutionary, are genuinely useful.

We’re not heading for AGI next decade. We’re heading for gradually better tools, slowly improving integration, steadily accumulating practical applications. That’s not the headline-grabbing narrative, but it’s the one history suggests we should prepare for.

And in that gradual evolution, there’s enormous opportunity—for the practitioners who prepare thoughtfully, adopt strategically, and maintain healthy skepticism about timeline predictions while remaining open to genuine innovation.

The future of AI in veterinary medicine will come. It will come gradually, then suddenly. But the “gradually” part will be longer than anyone is currently admitting.

What’s your experience with AI timeline predictions? Have you adopted AI tools in your practice? What questions do you wish you’d asked before implementation? How do you evaluate vendor promises against actual capability? For those building veterinary AI tools, how has your timeline of development compared to your initial predictions? I’d love to hear your experiences in the comments.

When ChatGPT was tested on veterinary curriculum questions in 2024, it correctly answered only 33% of questions consistently. Even GPT-4 managed just 69%. More concerning: when asked for sources, these systems fabricated references with nonsensical PubMed IDs that looked legitimate but led nowhere.

This isn’t hypothetical risk. The AVMA’s 2024 survey of 4,000 practitioners found that 70.3% cite reliability and accuracy as their primary AI concern. They’re right to worry—AI hallucinations in veterinary practice can mean wrong drug doses, fabricated drug interactions, or species-inappropriate treatments delivered with complete confidence.

But here’s what changed in 2024-2025: convergent research from major conferences and journals achieved what many thought impossible. We now have techniques that reduce hallucinations by 40-75%, detection methods that run in real-time, and practical protocols you can implement this week—no PhD in machine learning required.

This guide gives you the tools to use AI safely. Whether you’re already using ChatGPT for research, considering veterinary-specific AI tools, or just exploring the possibilities, you’ll learn how to detect hallucinations before they cause harm and reduce them systematically. You’ll get specific prompts to copy-paste, testing techniques to verify AI outputs, and a framework to stratify risk in your practice.

The research is solid. The techniques are proven. And most importantly, they’re practical.

The veterinary professionals who thrive won’t be those who avoid AI or blindly trust it. They’ll be those who understand how to use it correctly. Let’s get you there.

What’s in this guide: Part 1 focuses on the skills YOU need to use any AI system safely. Part 2 (coming next) will cover how to evaluate and choose AI tools for your practice. At the end of this article, you’ll find links to downloadable prompt templates, checklists, and testing tools you can use immediately.

Know Your Enemy: What Hallucinations Actually Look Like in Practice

Before you can detect hallucinations, you need to recognize them. AI doesn’t just make obvious mistakes—it hallucinates in specific, predictable patterns that can slip past even experienced practitioners.

The Six Types of Veterinary AI Hallucinations

1. Fabricated References

The AI cites sources that don’t exist. You’ll see PubMed IDs that return nothing, journal names that sound plausible but are invented, or author combinations that never published together.

Example: “According to Johnson et al., 2023 (PMID: 38471923), meloxicam can be safely combined with aspirin in cats for chronic pain management.” - The PMID doesn’t exist - The claim is dangerous - The formatting looks completely legitimate

2. Cross-Species Dosing Errors

The AI confidently applies canine protocols to cats, equine doses to small animals, or human medicine to veterinary patients.

Example: “Administer meloxicam at 0.2 mg/kg daily” without specifying this is dangerously high for cats, which require 0.05 mg/kg for chronic pain management (off-label oral use).

3. Invented Drug Interactions

The AI creates plausible-sounding but completely fabricated contraindications or warns against safe combinations.

Example: “Never combine amoxicillin with clavulanic acid in dogs with liver disease due to hepatotoxic synergy.” (No such interaction exists—this is literally how Clavamox works.)

4. Confident Wrongness

The AI states incorrect information with no hedging, uncertainty, or qualification. This is perhaps the most dangerous type because it bypasses your “that sounds wrong” instinct.

Example: “Xylitol toxicity in dogs requires a minimum ingestion of 0.5 g/kg to produce clinical signs.” (Actual threshold is 0.1 g/kg—this error could delay critical treatment.)

5. Inconsistent Answers

Ask the same question three different ways and get three different answers. This reveals the AI is generating responses rather than retrieving facts.

Example: - “What’s the toxic dose of acetaminophen in cats?” → “100 mg/kg” - “At what dose does acetaminophen become toxic to cats?” → “50-60 mg/kg” - “Acetaminophen toxicity threshold for felines?” → “Any dose is potentially toxic”

6. Plausible Nonsense

The AI weaves real facts with fabricated details so seamlessly that the entire response feels authoritative. These are the hardest to catch.

Example: “For canine parvovirus treatment, the standard protocol includes maropitant 1 mg/kg SQ q24h (correct), aggressive IV fluid therapy with potassium supplementation (correct), and prophylactic metronidazole 15 mg/kg IV to prevent secondary Clostridium perfringens proliferation (not standard care, though sometimes used). Recent studies show adding interferon-omega at 2.5 MU/kg on days 1, 3, and 5 reduces mortality by 23% (fabricated study, wrong dose if it were real).”

Read more

Recently, along with several other thoughtful, brilliant minds led by Jon Ayers, I co-authored “AI in Companion Animal Veterinary Medicine Report”, a whitepaper exploring AI’s transformative impact across veterinary medicine. If you haven’t read it yet, I highly encourage you to do so. While that paper surveyed the entire landscape—from clinical decision support to practice management disruption—this article dives deeper into one crucial piece: how AI coding tools are fundamentally changing software development itself, and why this matters for veterinary professionals.

After 30 years of writing software professionally, I’m experiencing the highest productivity of my career—coding faster while simultaneously playing every role in the software development lifecycle. AI agents help me write specifications, implement features, test functionality, and deploy applications, collapsing what used to require a team of specialists into a single workflow. I’m building prototypes, internal tools, and informational applications with unprecedented speed and scope.

This isn’t about me becoming superhuman or about replacing developers—it’s about AI agents handling the coordination work that previously required teams. The fundamental shift is that the bottleneck in software development is moving from implementation to imagination, and domain expertise is becoming more valuable than coding syntax. For veterinary professionals, this transformation means the gap between understanding a clinical problem and having working software to solve it is collapsing—changing who can build veterinary software and what becomes possible, even if you’ve never written a program in your life.

The rise of AI coding tools like OpenAI Codex, Google’s Gemini Code Assist, Claude Code, Cursor, and GitHub Copilot represents more than just another technological advance. It’s changing the very nature of software development from a craft focused on syntax and implementation details to one centered on problem-solving and system design. This shift has profound implications for how veterinary software gets built, who can build it, and what becomes possible when the barriers between ideas and implementation start to dissolve.

The Quiet Revolution in Every Developer’s Workflow

AI now generates 41% of all code, with 256 billion lines written in 2024 alone.¹ At companies like Google, over a quarter of all new code is generated by AI, freeing their 20,000+ engineers to focus on higher-level architecture and problem-solving rather than routine implementation. These aren’t isolated experiments—they’re production systems handling real-world software engineering at scale.

The numbers tell only part of the story. What’s happening is more fundamental: we’re witnessing the emergence of what I call “reasoning-first development”—where developers spend their time articulating what they want to accomplish rather than figuring out how to accomplish it.

The landscape of AI coding tools has evolved rapidly, with different approaches converging on the same goal: freeing developers from implementation details. OpenAI’s Codex, initially launched in 2021 as a code completion model, was completely reimagined in 2025 as a cloud-based autonomous agent. Powered by codex-1 (a version of OpenAI’s o3 model optimized for software engineering), today’s Codex works independently in isolated cloud sandboxes, handling multiple tasks in parallel—from building features to fixing bugs to creating pull requests.

Google’s Gemini Code Assist, powered by Gemini 2.5, takes a different approach with deep IDE integration and seamless Google Cloud connectivity. Available free to individual developers with a remarkably generous limit of up to 180,000 code completions per month, it features an agent mode that can tackle complex, multi-file tasks while maintaining full visibility into your codebase. The tool represents Google’s commitment to making enterprise-grade AI coding assistance accessible to everyone from hobbyists to startups.

Claude Code embeds Claude Opus 4.1 and Sonnet 4.5 directly in your terminal, with exceptional codebase awareness and the ability to edit files and run commands in your local environment. Cursor and GitHub Copilot offer seamless editor integration for real-time collaboration, bringing AI assistance directly into your existing workflow without context switching.

What unites these diverse tools is a fundamental shift from code completion to code generation—from helping you write faster to handling entire workflows while you focus on design and intent. These tools don’t just autocomplete your typing. You can describe what you want in plain English, and they create entire applications, write tests, fix bugs, and even commit changes to version control—all while you focus on the “what” and “why” rather than the “how.”

But here’s where it gets interesting for veterinary medicine: this same transformation is quietly reshaping how veterinary software gets developed, who can contribute to its development, and what becomes possible when domain experts can directly translate their clinical knowledge into working systems.

My Personal Experience: From Syntax to Strategy

Let me be concrete about what this looks like in practice. Two months ago, I was debugging Pythont frameworks, wrestling with API authentication, and spending hours on what I now realize were implementation details that added no real value.

Today, I describe what I want to build:

“Create a diagnostic probability calculator that takes patient signalment, clinical signs, and test results, then updates likelihood ratios using Bayes’ theorem. It should handle multiple simultaneous differentials and show how each new piece of information shifts the probability landscape.”

Within minutes, I have a working prototype. Within an hour, I have a polished application with proper error handling, responsive design, and comprehensive testing. The difference isn’t just speed—it’s cognitive bandwidth. Instead of getting lost in implementation details, I stay focused on the clinical logic, user experience, and statistical validity.

The landscape offers compelling options: Codex handling complex refactoring in cloud sandboxes, Gemini Code Assist providing deep IDE integration with generous free tiers, Cursor enabling seamless editor collaboration. I’ve chosen to work exclusively with Claude Code—I believe it’s the best tool available and is evolving the fastest. Its integration of Claude Sonnet 4.5 directly in my terminal, with exceptional codebase awareness and ability to understand veterinary-specific patterns, fits my workflow perfectly. Others will make different choices for their own reasons, but what unites all these tools is the fundamental shift they enable: from wrestling with syntax to articulating intent.

This shift from implementation to intention has allowed me to build prototypes and proofs of concept that would have taken weeks or months in the traditional development cycle. More importantly, it’s allowed me to iterate rapidly on ideas, testing different approaches to presenting information, exploring interface designs, and experimenting with workflows without getting bogged down in technical debt. I can focus on questions like: Is this interface intuitive? Does this visualization make sense? Is the technical implementation sound? Then I can put prototypes in front of actual veterinarians to get their feedback on whether it’s clinically useful.

When I encounter a bug or need to add a feature, I describe the problem in functional terms: “The probability calculations don’t properly handle dependent test results” or “Add support for different reference ranges based on species.” The AI handles the translation from requirements to working code, while I verify that the technical implementation works as intended. The clinical validation comes from actual veterinarians.

This is the future of veterinary software development: domain experts staying in their domain while AI handles the translation to implementation.

The Veterinary Software Implications

This transformation has three profound implications for veterinary medicine:

1. Domain Experts Can Build Their Own Solutions

At Anthropic, lawyers built phone tree systems. Marketers generated hundreds of ad variations in seconds. Data scientists created complex visualizations without knowing JavaScript. The pattern is clear: AI coding tools are dissolving the boundary between technical and non-technical work.

For veterinary medicine, this means clinical experts can directly translate their domain knowledge into software solutions. A veterinary nutritionist who understands the complexities of formulating diets for different life stages, breeds, and medical conditions could build dietary management tools that capture that expertise—without needing to learn programming languages or hire development teams.

For instance, a nutritionist could create a tool that calculates appropriate caloric intake based on body condition score and activity level, flags potential nutrient deficiencies for specific conditions, adjusts recommendations for multiple concurrent diseases, and generates client-friendly feeding plans—all by describing the nutritional logic rather than coding the algorithms. A practice manager frustrated with appointment scheduling could build a custom system that accounts for exam room constraints, doctor preferences, and procedure durations without waiting months for a vendor enhancement.

This isn’t theoretical. One corporate veterinary group developed a brand-new PIMS in nine months using AI-enabled coding²—a timeline that would have been impossible with traditional development approaches. When a complete practice management system can be built in under a year, the economics of custom veterinary software development fundamentally change.

Imagine practice management software designed by actual practice managers, or diagnostic protocols built by the specialists who use them daily. When domain experts can directly implement their knowledge as software, we get tools that actually solve real problems rather than what programmers think the problems are.

2. Rapid Prototyping of Clinical Workflows

Traditional software development follows a waterfall model: requirements gathering, design, implementation, testing, deployment. This cycle often takes months, by which time clinical needs have evolved or the original requirements have been forgotten.

AI coding tools enable what I call “conversational development”—where clinical workflows can be prototyped, tested, and refined in real-time conversations between clinicians and AI systems. A veterinary practice can experiment with different approaches to appointment scheduling, inventory management, or patient communication without massive upfront investments in custom development.

This rapid iteration capability is particularly valuable for veterinary medicine, where practice workflows vary significantly between specialties, regions, and individual preferences. Instead of one-size-fits-all solutions, we can develop tools that adapt to specific practice needs.

The impact extends beyond individual practices. Venture capital firm Tidemark has analyzed this transformation through what they call the race to become the “System of Action”—where software moves from helping businesses run to actually doing the work itself.³ For veterinary medicine, this means tools that don’t just document care but actively support clinical decision-making and workflow automation. As Tidemark’s analysis shows, the battle lines are being drawn between legacy Practice Information Management Systems (PIMS) built for administrative tasks and AI-native applications designed around the actual work veterinarians do.

3. Integration Challenges Become Solvable

In my previous article about veterinary software interoperability, I explored how the lack of standardized terminologies and proprietary integration approaches create expensive, fragmented solutions. AI coding tools change this equation fundamentally.

The veterinary PIMS market exemplifies this fragmentation challenge. With over 30 different PIMS offerings and the largest vendor holding less than 20-25% market share,⁴ practices face a bewildering array of choices—and integration nightmares when they want to use best-of-breed solutions from different vendors. Historically, this fragmentation made custom integrations prohibitively expensive.

When integration work that previously required months of custom development can be accomplished in days, the economic barriers to interoperability start to dissolve. Custom integrations that connect a practice’s PIMS with specialty diagnostic equipment, imaging systems, inventory tools, or client communication platforms—integrations that once cost upwards of triple digits and took 6-12 months—can now be built in days for a fraction of the cost, maintaining real-time synchronization and handling terminology translation automatically.

Practices can afford custom integrations between their favorite tools. Vendors can more easily adapt to different practice management systems. Most importantly, the translation between different veterinary terminologies—the semantic layer problem I discussed—becomes a tractable engineering challenge rather than an insurmountable economic barrier.

Consider PetDesk, an add-on application that has achieved integration with over 30 PIMS vendors and now serves 8,200 North American practice locations—roughly 25% market share.⁵ Their success demonstrates both the demand for cross-platform integration and the complexity of achieving it. With AI coding tools, similar integration breadth becomes achievable for smaller vendors and even individual practices at a fraction of the traditional cost.

Real-World Adoption and Results

The proof of these tools’ effectiveness isn’t in research studies—it’s in adoption rates. GitHub reports that over 77% of developers now use AI coding assistants regularly. At Google, AI generates more than 25% of new code, with human engineers reviewing and accepting these contributions. Startups are building entire products with teams of 2-3 developers doing work that previously required 10-15 engineers.

For veterinary software specifically, we’re seeing early adopters build custom integrations, diagnostic tools, and practice management extensions in days rather than months. The economic equation has fundamentally changed: what cost $50,000 in custom development now costs $5,000. What took 6 months now takes 6 weeks.

The adoption of AI tools by veterinarians themselves is already underway. An estimated 30% of veterinarians now use AI-powered scribe tools to automate clinical documentation—up from essentially zero just two years ago. Over 30 veterinary scribe startups have emerged to serve this demand, many with significant venture funding.⁶ According to industry insiders, a competent AI engineer can build a functional veterinary scribe in a week’s work—a development timeline that would have seemed absurd in the pre-AI era.

But effectiveness depends on context. AI tools excel at translating clear specifications into working code. They struggle when requirements are vague, domain knowledge is specialized, or the problem requires genuine innovation rather than pattern matching. The most successful implementations pair AI code generation with strong domain expertise—exactly the combination veterinary professionals can offer.

What This Means for Veterinary Professionals

The implications of this software development transformation extend far beyond programmers and technology companies:

1. Evaluate Vendor Development Approaches

When choosing veterinary software vendors, consider how they develop and maintain their products. Vendors leveraging AI development tools can potentially:

• Respond more quickly to feature requests

• Customize solutions for specific practice needs

• Integrate with other systems more economically

• Iterate on user feedback more rapidly

When evaluating vendors, ask specific questions:

• “How long does it typically take to implement a feature request?”

• “Can you customize the system for our specific workflow without a massive upfront cost?”

• “What’s your process for integrating with other systems we use?”

• “How do you incorporate user feedback into development?”

Vendors using AI-assisted development should be able to demonstrate faster iteration cycles and more flexible customization options. If a vendor quotes 6-month timelines for simple integrations, they may not be leveraging modern development tools effectively.

Large corporate veterinary groups have particular leverage here. With their market power and significant practice counts, they can pressure PIMS vendors toward open systems strategies, welcoming innovative startups through sanctioned APIs.⁷ They also have an increasingly viable option to build their own systems as AI-enabled development costs continue to fall.

2. Consider Internal Tool Development

Practices with specific workflow needs that aren’t well-served by commercial solutions might consider developing simple internal tools. With AI coding assistants, practice managers or veterinarians with basic technical skills can create custom solutions for:

• Specialized reporting needs

• Unique inventory tracking requirements

• Custom client communication workflows

• Practice-specific diagnostic calculators

This doesn’t mean every practice should become a software company, but the barrier to creating simple, targeted solutions has dropped dramatically.

3. Participate in Software Design Processes

The most successful veterinary software emerges from close collaboration between clinical experts and technical teams. AI coding tools make this collaboration more productive by reducing the cost of iteration and experimentation.

When software vendors involve you in design processes, your clinical input becomes more valuable because changes can be implemented and tested more quickly. Consider participating in beta testing programs, user advisory boards, and feedback sessions with vendors who demonstrate responsive development practices.

This collaboration becomes even more critical as the industry shifts from “systems of record” to what Tidemark calls “systems of action.”³ The veterinary PIMS of the future won’t just store data—they’ll actively support the work veterinarians do in exam rooms, surgery suites, and beyond. Domain expertise becomes essential to ensure these systems support clinical workflows rather than imposing technological constraints.

4. Understand the Limitations

AI tools aren’t magic, and their effectiveness varies by context and task complexity. When evaluating AI-powered tools—whether for software development or clinical applications—maintain healthy skepticism about broad productivity claims and demand concrete evidence of effectiveness in contexts similar to your own. Ask vendors for specific metrics: How much faster are feature implementations? What’s the error rate? How do customization costs compare to traditional development?

More importantly for veterinary applications: AI tools trained primarily on general software codebases may not understand veterinary-specific requirements like controlled substance tracking, VCPR compliance, or species-specific medical protocols. When evaluating AI-generated code for clinical applications, veterinary domain expertise remains essential for validating that implementations meet medical and regulatory standards. AI can write the code, but only veterinarians can confirm it’s clinically appropriate.

The Broader Pattern: From Implementation to Intention

The transformation in software development is part of a broader shift happening across knowledge work: AI tools are moving us from implementation-focused tasks to intention-focused work.

In software development, this means shifting from writing code to articulating requirements and system design. In veterinary medicine, similar shifts are emerging:

• From data entry to clinical reasoning: AI can handle routine documentation while veterinarians focus on diagnostic thinking

• From protocol memorization to clinical judgment: AI can provide reference information while veterinarians apply clinical experience to patient-specific situations

• From administrative work to patient care: AI can automate scheduling, billing, and compliance tasks while practices focus on medicine

The pattern is consistent: AI handles the routine, implementational aspects of knowledge work while humans focus on the creative, strategic, and judgment-intensive components.

As software development costs plummet and capabilities expand, the competitive advantage shifts from who can build software to who serves users best. As Kjerstin Erickson of Arising Ventures observes in her analysis of the AI-enabled coding revolution: “When product becomes commodity, what will determine the winners? Being relentlessly on the user’s side in every possible way. From price to transparency to ownership.”⁸ She calls this “Radical Pro-Usership”—rethinking the subscriptions, lock-ins, high markups, and hidden fees that have characterized traditional SaaS business models.

For veterinary software, this principle suggests a future where user-centric design and transparent pricing matter more than proprietary features and vendor lock-in. The practices and software vendors that embrace this shift will be best positioned for the AI era.

Looking Forward: The Integration Imperative

As AI tools become more prevalent in software development, the integration challenges I’ve written about in veterinary medicine become both more urgent and more solvable.

The urgency comes from AI systems needing comprehensive, standardized data to function effectively. The veterinary AI tools of tomorrow will require seamless access to patient records, laboratory results, imaging studies, and clinical notes from multiple sources. Our current fragmented, proprietary integration landscape limits what’s possible.

The opportunity comes from AI-assisted development making integration work more economical. Custom connectors between systems, terminology translation services, and data standardization tools become buildable by smaller teams with tighter budgets.

Interestingly, AI-native architectures may fundamentally challenge the need for single systems of record. Why does one need a single medical system of record with entries for each pet, when an AI agent can assemble a context-sensitive medical profile from multiple sources on the fly and at the point of need?⁹ A context-sensitive profile could pull from the legacy PIMS, separate radiograph archives, client communication histories, and any variety of other sources to create the exact information needed for a particular clinical situation. This approach could obviate the traditional vendor control over systems of record, enabling more flexible and practice-specific software architectures.

The veterinary practices and software vendors that invest in interoperability now—through standards adoption, API development, and collaborative data initiatives—will be best positioned to leverage the AI tools that require comprehensive data access.

Conclusion: The Transformation is Just Beginning

The shift from lines of code to lines of reasoning represents more than a productivity improvement—it’s a fundamental change in how we solve problems with technology. For veterinary medicine, this transformation opens possibilities that seemed impossible just a few years ago.

Domain experts can build their own solutions. Rapid prototyping makes experimentation affordable. Integration challenges become economically tractable. Most importantly, the focus shifts from what technology can do to what problems need solving.

These tools aren’t universally superior to traditional development—they’re contextually powerful, working best when applied to the right problems with proper domain expertise guiding their use. Understanding when and how to use them effectively becomes a crucial skill for anyone working at the intersection of technology and veterinary medicine.

The veterinary professionals who thrive in this evolving landscape will be those who understand both the possibilities and limitations of AI-assisted development, who can articulate their domain expertise clearly enough for AI tools to implement, and who focus on problems that matter rather than solutions that are merely possible.

After three decades of building software—from the early days of desktop applications through the web revolution to today’s AI transformation—I’m more excited about the next decade than I’ve ever been. Not because AI can write code, but because it frees us to focus on the problems worth solving. In veterinary medicine, those problems matter more than most.

What aspects of your veterinary workflow could benefit from custom software solutions? Have you experimented with AI tools in your practice, and what has your experience been? As the barrier between clinical expertise and technical implementation continues to fall, I’m curious about what possibilities you see emerging in veterinary medicine.

Footnotes

1. Jon Ayers, Jane Brunt, DVM, David Kincaid, Adam Little, DVM, Aaron Massecar, PhD, Robert Sanchez, “Artificial Intelligence in Companion Animal Veterinary Medicine: Transformation Ahead!” (September 22, 2025), https://3959545110398.gumroad.com/l/ipplb, p. 51. ↩

2. Ibid., p. 51. This refers to MVP (before their merger with SVP). ↩

3. Ibid., pp. 54-60. Analysis by Dave Yuan, founder and partner of Tidemark, “The Race to Become the System of Action,” https://www.tidemarkcap.com/post/the-race-to-become-the-system-of-action. ↩ ↩²

4. Ibid., pp. 63-64. ↩

5. Ibid., pp. 63-64. ↩

6. Ibid., pp. 55, 62. ↩

7. Ibid., pp. 61-62. ↩

8. Ibid., p. 65. Quote from Kjerstin Erickson, CEO of Arising Ventures. ↩

9. Ibid., pp. 64-65. ↩

Apologies for the amount of time since my last article. Our son got married the weekend before last, so the last couple of weeks have been quite busy. Besides this article posted today, there will be a deep dive later this week diving into LLM hallucinations and how to detect and prevent them for paid subscribers.

I have to thank Jon Ayers for the great idea for this article. Keep your eyes out for more from Jon very soon.

Large language models like ChatGPT, Claude, and Gemini have become ubiquitous in professional workflows across industries. Despite valid concerns about privacy, accuracy, and appropriateness for medical contexts, the reality is that these tools are already being used in veterinary practices—often without clear guidelines on how to use them effectively and safely.

Rather than ignore this reality, I want to provide veterinary professionals with a practical framework for getting the most value from LLMs while minimizing risks. This isn't about replacing clinical judgment or encouraging inappropriate use—it's about helping you use these tools responsibly for the tasks where they can genuinely add value.

After watching colleagues struggle with inconsistent results, privacy concerns, and occasional dangerous outputs, I've developed this guide to help veterinary professionals navigate the LLM landscape more effectively. Whether you're using these tools for client communication, practice management, or continuing education, the principles I'll share can dramatically improve your results while keeping you on the right side of safety and ethics.

This article provides prompting guidance for using general purpose LLM’s like ChatGPT, Claude, Gemini, Grok, etc. through their publicly available web interfaces. Prompting techniques will differ if you are using another interface to the LLM. For a good introduction to the differences see my previous article The Model vs The Interface: What Veterinary Professionals Need to Know About Large Language Models.

Critical Privacy and Security Warning: What Never Goes In

Before we discuss how to use these tools effectively, let's be absolutely clear about what should never be entered into public LLMs like ChatGPT, Claude, or Gemini:

Absolutely Prohibited Information

• Client names, addresses, or contact information

• Pet names combined with owner information

• Specific case details that could identify patients

• Financial information or billing details

• Staff personal information

• Practice-specific protocols or proprietary information

The De-identification Rule

If you must reference clinical scenarios, use completely generic descriptions: "a 7-year-old Golden Retriever with vomiting" rather than "Mrs. Smith's dog Buddy who has been vomiting." Even better, create hypothetical scenarios that capture the clinical essence without any real case details.

Platform Data Policies Vary

Different LLM platforms have different data retention and training policies:

• ChatGPT: Conversations may be used for training unless you opt out

• Claude: Anthropic states they don't train on your conversations, but data may be stored temporarily

• Gemini: Google may use conversations to improve their services

• Grok: X's policies are evolving

• Perplexity: Focuses on search but may retain query data

The safest approach: Assume anything you type could potentially be seen by others or used for training, regardless of stated policies.

A Veterinary-Specific Solution: LifeLearn's Sofie AI

Before diving into general LLM usage, I strongly recommend veterinary professionals consider a tool like LifeLearn's Sofie AI for medical and clinical questions. Here's why:

Why Sofie AI is Different

• Veterinary-specific training: Built specifically for veterinary medicine with species-specific knowledge

• Licensed content foundation: Grounded in tens of thousands of pages of veterinary medical content

• Reduced hallucination risk: The retrieval-augmented generation approach and carefully designed prompts and guardrails significantly reduce false information

• Privacy protection: Designed with veterinary practice privacy requirements in mind

• Current medical knowledge: Regularly updated with current veterinary medical information

When to Use Sofie AI vs. General LLMs

• Use Sofie AI for: Diagnostic information, treatment protocols, drug interactions, species-specific medical questions, clinical decision support

• Use general LLMs for: Client communication drafts, practice management workflows, general business questions, continuing education planning

Full disclosure: I was involved in developing Sofie AI during my time working with LifeLearn, so I know how it was built and what’s powering it. I recommend it because it solves the specific problems that make general LLMs inappropriate for veterinary medical questions.

The Foundation: Six Principles of Effective LLM Prompting

1. Be Specific About Context and Role

Instead of: "Help me with a difficult client" Try: "I'm a veterinary practice manager dealing with a client who is upset about an unexpected bill increase. I need help drafting a professional response that acknowledges their concern, explains the situation clearly, and maintains a positive relationship."

2. Provide Constraints and Guidelines

Instead of: "Write a discharge instruction" Try: "Write discharge instructions for routine spay surgery. Keep it under 200 words, use 8th-grade reading level, include bullet points for easy scanning, and emphasize the most critical first 24-hour care items."

3. Ask for Multiple Options

Instead of: "What should I do about staff scheduling conflicts?" Try: "Give me 5 different approaches for handling scheduling conflicts between veterinary staff, ranging from immediate fixes to longer-term policy changes. For each approach, include pros, cons, and implementation difficulty."

4. Request Reasoning and Sources

Instead of: "Is this a good idea?" Try: "Evaluate this practice management idea and explain your reasoning. What assumptions are you making, what potential problems do you see, and what additional information would help make this decision?"

5. Iterate and Refine

Don't expect perfect results on the first try. Follow up with:

• "Make this more formal/casual"

• "Focus more on the financial aspects"

• "Rewrite this for a client with limited English proficiency"

• "What did I miss in my initial request?"

6. Test Understanding

Ask the LLM to summarize what you've requested before it provides the answer: "Before you respond, please confirm your understanding of what I'm asking for."

Understanding Advanced LLM Features: Getting Better Results from Whatever Tool You're Using

Modern LLMs offer powerful specialized features that can dramatically improve your results when used appropriately. Rather than switching between platforms, learn to recognize and leverage these capabilities within your preferred tool.

Deep Research and Analysis Features

What This Feature Does: Conducts thorough research across multiple sources, synthesizes information, and provides comprehensive analysis with citations and source verification.

Available As:

• Claude: Research Mode

• Perplexity: Academic Focus or All Sources modes

• ChatGPT: Advanced search capabilities (with plugins/browsing enabled)

• Gemini: Research with real-time search integration

When to Use for Veterinary Applications:

• Investigating new diagnostic technologies before making purchase decisions

• Analyzing market trends in veterinary services

• Researching regulatory changes affecting your practice

• Comparing treatment protocols or equipment options

• Understanding industry developments that might impact your practice

Example Veterinary Prompt: "I need comprehensive research on the current state of veterinary telemedicine regulations and adoption rates. Include recent regulatory changes, reimbursement policies, technology platforms, and adoption barriers. Provide sources for verification."

Extended Reasoning and Complex Problem-Solving

What This Feature Does: Works through complex problems step-by-step, showing detailed reasoning chains and considering multiple factors before reaching conclusions.

Available As:

• Claude: Extended Thinking mode

• ChatGPT: Chain-of-thought prompting (request step-by-step reasoning)

• Gemini: Detailed analysis requests with reasoning steps

• Perplexity: Copilot mode for multi-step analysis

When to Use for Veterinary Applications:

• Practice expansion or major business decisions

• Complex staff scheduling or workflow optimization

• Equipment purchase cost-benefit analysis

• Emergency protocol development

• Strategic planning for new service offerings

Example Veterinary Prompt: "I need to decide whether to add emergency services to my small animal practice. Work through this decision step-by-step, considering: current staffing capacity, required equipment investment, facility modifications needed, financial projections, impact on existing services, staff training requirements, and local market demand. Show your reasoning at each step."

Creative and Content Generation Features

What This Feature Does: Focuses on generating engaging, creative content with varied approaches and innovative solutions.

Available As:

• All platforms: Creative writing modes or style selections

• ChatGPT: Creative settings, Canvas mode for iterative content development

• Gemini: Creative mode

• Claude: Creative style selection

When to Use for Veterinary Applications:

• Marketing materials and social media content

• Client education materials that need to be engaging

• Newsletter content and practice communications

• Creative problem-solving for practice challenges

• Staff training materials that need to maintain attention

Example Veterinary Prompt: "Create engaging social media content that educates pet owners about the importance of dental care for senior dogs. Make it informative but approachable, include a clear call-to-action, and suggest accompanying visuals. Provide three different approaches: emotional storytelling, factual education, and interactive engagement."

Collaborative Editing and Iteration Features

What This Feature Does: Allows real-time editing, revision, and collaborative development of documents with version control and change tracking.

Available As:

• ChatGPT: Canvas mode

• Claude: Artifact system for document creation and editing

• Some platforms: Document sharing and collaborative features

When to Use for Veterinary Applications:

• Developing practice policies that need multiple revisions

• Creating comprehensive staff manuals or training materials

• Building client education resources that require ongoing updates

• Collaborative development of clinical protocols

• Creating documents that multiple staff members will contribute to

Example Veterinary Prompt: "Help me create a comprehensive client onboarding packet for new puppy owners. Start with a basic structure, then we'll iteratively add sections for vaccination schedules, training recommendations, nutrition guidelines, and emergency contact information. I want to be able to edit and refine each section as we go."

Precision and Fact-Checking Features

What This Feature Does: Prioritizes accuracy over creativity, provides careful fact-checking, and gives conservative responses with appropriate disclaimers.

Available As:

• Gemini: Precise mode

• Perplexity: Academic focus with source citations

• All platforms: Precision-focused prompting techniques

When to Use for Veterinary Applications:

• Verifying industry statistics or research findings

• Checking technical specifications for equipment

• Confirming regulatory requirements or compliance issues

• Validating information before including in client materials

• Double-checking important practice communications

Example Veterinary Prompt: "I need to verify the accuracy of these statistics about heartworm disease prevalence I want to include in a client newsletter. Please fact-check each claim and provide current sources. If any information is outdated or unclear, flag it for me to research further."

Feature Selection Strategy: Matching Capabilities to Veterinary Tasks

For Strategic Business Decisions

Use: Extended reasoning features Why: Complex decisions require systematic analysis of multiple factors Access: Request step-by-step analysis, explicitly ask for reasoning chains

For Client-Facing Communications

Use: Creative and collaborative features Why: Content needs to be engaging and may require multiple revisions Access: Select creative modes, use iterative editing features

For Research and Information Gathering

Use: Deep research features Why: Decisions should be based on comprehensive, current information Access: Enable research modes, request source citations

For Policy and Procedure Development

Use: Collaborative editing combined with extended reasoning Why: Policies need thorough analysis and iterative refinement Access: Use document editing features with analytical prompting

For Fact-Checking and Verification

Use: Precision-focused features Why: Accuracy is critical for professional communications Access: Request conservative analysis, ask for source verification

Activating These Features: Universal Prompting Techniques

Be sure to check how your favorite platform enables these features. Usually it’s a button or dropdown selection.

Since features are accessed differently across platforms, here are universal prompting techniques that work regardless of which tool you're using:

To Trigger Deep Research Mode

• "Research this topic thoroughly and provide multiple sources"

• "I need comprehensive analysis with citations"

• "Give me a detailed overview with source verification"

To Activate Extended Reasoning

• "Work through this step-by-step and show your reasoning"

• "Analyze this decision systematically, considering all factors"

• "Think through this problem methodically before giving recommendations"

To Access Creative Features

• "Generate multiple creative approaches to this challenge"

• "Help me brainstorm engaging ways to present this information"

• "Create content that's both informative and compelling"

To Enable Collaborative Editing

• "Help me develop this document iteratively, starting with a basic structure"

• "I want to refine this content through multiple rounds of editing"

• "Let's build this piece by piece, with opportunities for revision"

To Use Precision Mode

• "Please be very conservative and accurate in your response"

• "Fact-check this information and flag any uncertainties"

• "Give me precise, well-sourced information rather than speculation"

Advanced Prompting Techniques

The Chain-of-Thought Method

For complex problems, ask the LLM to work through its reasoning step by step:

"I need to decide whether to hire a new veterinarian or increase current staff hours. Walk me through your decision-making process step by step: 1) What information do I need to gather? 2) What factors should I consider? 3) How should I weight different priorities? 4) What decision framework would you recommend?"

The Multiple Perspective Technique

"Analyze this practice management decision from three perspectives: financial impact, staff satisfaction, and client service quality. For each perspective, what are the key considerations and potential outcomes?"

The Devil's Advocate Approach

"I'm considering implementing this new technology in my practice. First, give me the best arguments for why this is a good idea. Then, play devil's advocate and tell me why this might be a poor decision. Finally, suggest questions I should ask the vendor."

The Scenario Planning Method

"Help me plan for three scenarios: best case, worst case, and most likely case for implementing extended hours. For each scenario, what should I prepare for and what decisions might I need to make?"

Red Flags: When LLM Output Requires Extra Scrutiny

Watch Out For:

• Overly confident medical statements (remember, use Sofie AI for medical questions)

• Specific dosage recommendations (always verify with veterinary references)

• Legal advice (consult actual lawyers for legal questions)

• Specific financial projections (use as starting points, not final decisions)

• Outdated information (especially relevant for rapidly changing technology topics)

Always Verify When:

• The response includes specific numbers or statistics

• The advice could have legal implications

• The suggestion involves significant financial investment

• The recommendation affects patient care protocols

• The information seems surprisingly definitive about complex topics

Key Insights for Veterinary Practice

🔒 Privacy First: Never compromise client privacy for convenience. When in doubt, don't include it. Create hypothetical scenarios instead of using real case details.

🏥 Use Veterinary-Specific Tools for Medical Questions: LifeLearn's Sofie AI and similar veterinary-specific tools are safer and more accurate for medical queries than general LLMs.

🎯 Be Specific in Your Requests: Vague prompts yield vague results. Include your role, constraints, desired format, and success criteria in every prompt.

🔄 Iterate for Better Results: Your first prompt rarely yields the perfect result. Plan to refine and adjust based on initial outputs.

📊 Request Multiple Options: Ask for several approaches, alternatives, or versions to choose from rather than accepting the first suggestion.

🧐 Verify Important Information: Always fact-check information that affects patient care, legal compliance, or significant business decisions.

🎭 Use Role-Specific Context: Tell the LLM your role (veterinarian, practice manager, veterinary technician) to get more contextually appropriate responses.

⚠️ Recognize Limitations: LLMs can hallucinate false information, may provide outdated data, and can be overly confident in uncertain areas. Always verify critical information, especially specific dosages, statistics, legal requirements, or financial projections. Use them as thinking partners, not as replacements for your professional judgment.

🎓 Invest in Learning: Effective prompting is a skill that improves with practice. Start with simple tasks and gradually tackle more complex applications.

🔍 Choose the Right Feature: Different LLM features have different strengths. Match your task to the capability that handles it best.

📋 Create Reusable Templates: Once you find prompting patterns that work, save them as templates for similar future tasks.

🤝 Combine with Human Judgment: Use LLMs as thinking partners and draft generators, not as replacement for your professional expertise and judgment.

Conclusion

Large language models are powerful tools that can genuinely improve efficiency in veterinary practices when used appropriately and safely. The key is understanding what these tools do well, where they fall short, and how to structure requests to get reliable, useful results.

Remember that effective prompting is a skill that improves with practice. Start with low-stakes applications like email drafts and simple summaries. As you become more comfortable with the tools and develop better prompting techniques, you can gradually expand to more complex applications.

Most importantly, always prioritize client privacy, patient safety, and professional standards. These tools should enhance your professional capabilities, not replace your expertise or compromise your ethical obligations.

The veterinary professionals who learn to use these tools effectively—while respecting their limitations—will find themselves with more time to focus on what matters most: providing exceptional patient care and client service.

What LLM applications have you found most helpful in your veterinary work? What challenges have you encountered with prompting or results quality? I'd love to hear about your experiences and any specific use cases where you'd like more detailed guidance.

You see a 12-year-old Golden Retriever walk into your exam room with a subtle head tilt and mild ataxia. Before running a single test, before even completing your physical exam, something in your clinical experience whispers: "This could be vestibular disease."

That whisper? It's your brain calculating pre-test probability.

Now watch what happens when you see the exact same presentation in a 6-month-old puppy. That whisper changes completely: "Check for toxin exposure, maybe an ear infection." Same clinical signs, completely different suspicion levels for different diseases.

This is pre-test probability in action, and you do it hundreds of times every day without thinking about it numerically.

If you're building AI tools for veterinary medicine, keep reading—because understanding this invisible probability calculation that happens in every clinical decision is the difference between creating tools that veterinarians actually use and expensive technology that sits abandoned. The veterinarian's brain is running sophisticated probability math whether they realize it or not, and if your tool doesn't respect that process, it will fail.

After 29 years working with veterinary diagnostic data, I've observed something fascinating: the best diagnosticians aren't necessarily the ones who order the most tests or know the most obscure diseases. They're the ones whose clinical intuition most accurately estimates pre-test probability—even if they've never heard the term.

As a data scientist, I work in a world of concrete numbers and explicit probabilities. You work in a world where experience, pattern recognition, and clinical judgment blend into what we call the "art of medicine." But here's what I've learned: that art is actually sophisticated probability assessment happening at a subconscious level.

Today, I want to make that invisible process visible—not to replace your clinical judgment, but to give you a framework for understanding why your intuition works, when it might mislead you, and how to communicate your reasoning more effectively to colleagues, clients, and increasingly, to AI systems that need this context to function properly. And for those building those AI systems: understanding this framework isn't optional—it's essential for creating tools that actually work in clinical practice.

The Hidden Foundation of Every Diagnosis

In my previous article on likelihood ratios, I explained why positive predictive value (PPV) is dangerously misleading—the same test with identical accuracy can have wildly different PPV depending on disease prevalence. But there's a critical piece I only touched on briefly: prevalence in a general population is almost never the right number to use.

The relevant probability isn't how common a disease is in all dogs. It's how likely this specific patient, with their specific signalment, history, and presentation, is to have this disease. That's pre-test probability, and it's exponentially more nuanced than population prevalence.

Consider lymphoma in dogs:

• General canine population prevalence: ~0.3%

• Middle-aged Golden Retrievers: ~2%

• Middle-aged Golden Retriever with enlarged lymph nodes: ~15%

• Middle-aged Golden Retriever with enlarged lymph nodes and weight loss: ~40%

• Same dog, but the owner mentions "he's been really thirsty lately": ~60%

Each piece of information reshapes the probability landscape before you run a single diagnostic test.

This is where AI tools could serve as powerful probability checkers. Imagine an AI system that could instantly surface: "Based on 10,000 similar cases in our database, dogs with this signalment and presentation had lymphoma 43% of the time, chronic enteropathy 22% of the time, and infectious causes 15% of the time." Not to replace your judgment, but to calibrate it against broader patterns you might not have personally encountered.

The Mathematics Your Brain Is Already Doing

When you examine a patient, your brain is running something like this calculation (though certainly not in these explicit terms):

Pre-test Probability = Base Rate × Signalment Modifier × Clinical Sign Modifier × History Modifier × Environmental Modifier

Take a vomiting cat. Your brain instantly integrates:

• Is it a 2-year-old (less likely serious) or 14-year-old (more concerning)?

• Acute single episode (×0.3 probability) or chronic progressive (×4.0)?

• Did they change food yesterday (×0.2) or no obvious trigger (×1.5)?

• Is there blood present (×2.5)?

That 14-year-old cat with chronic bloody vomiting? Your brain calculates high probability for serious disease. The 2-year-old who got into new food? Near zero. You don't consciously do this math—but this is exactly the kind of integration your clinical experience performs instinctively.

What's fascinating is that next-generation AI clinical decision support tools are attempting to make these calculations explicit. They can process thousands of similar cases to suggest: "Your estimated 60% probability aligns with our analysis, but did you consider that this breed has a 3x higher rate of IBD than average?" These tools aren't replacing your thinking—they're serving as a sophisticated second opinion that might catch factors your experience hasn't encountered.

Why This Invisible Number Drives Everything

Pre-test probability isn't just an academic concept—it fundamentally determines:

Which Tests Make Sense: If your pre-test probability for hypothyroidism is 1%, even a highly specific test will generate mostly false positives. Your clinical experience tells you not to randomly screen young, healthy dogs for thyroid disease—now you know why the math supports that intuition. AI could flag when test ordering seems misaligned: "The requested thyroid panel has a positive predictive value of only 15% given this patient's low pre-test probability."

How to Interpret Results: A positive heartworm test in a dog from Minnesota in January (pre-test probability <1%) is likely a false positive. The same test in a dog from Louisiana who hasn't been on prevention (pre-test probability >30%) is almost certainly real.

When to Stop Testing: Once your post-test probability exceeds your treatment threshold, additional testing adds cost without changing management. If you're 85% sure it's pancreatitis and you're going to treat for pancreatitis at that confidence level, the spec cPL might not change anything. Future AI tools could track your testing patterns and suggest: "In similar cases with this pre-test probability, additional testing changed management only 5% of the time."

How to Explain Decisions: "Based on Fluffy's age, symptoms, and what we're seeing in the area, I'd estimate about a 70% chance this is kennel cough. The test would help confirm, but given how likely it is, we could start treatment and test only if she doesn't respond as expected."

The Art-Science Interface: Where AI Becomes Your Probability Partner

Here's where I deeply respect what veterinarians do that pure data science cannot: you integrate unmeasurable factors that dramatically affect pre-test probability.

The owner who says, "He's just not himself"—how do you quantify that? Yet experienced veterinarians know this can be the most important piece of information in the room. The cat who "looks like a renal cat"—what equation captures that gestalt?

This is the art of medicine, and it's real. But here's where AI can become fascinating: it can help you recognize patterns in your own assessments. An AI system tracking your cases might notice: "When you document 'owner reports not himself,' your suspected diagnoses are confirmed 73% of the time versus 45% baseline. Your intuition about owner concern is highly predictive."

Why Every AI Tool Builder Needs to Understand This

If you're building veterinary clinical tools—especially AI tools—this section is for you.

Here's the uncomfortable truth: Most veterinary AI tools fail not because the technology is weak, but because they don't understand or respect the sophisticated probability calculations that veterinarians perform intuitively. We build tools that operate in isolation, ignoring the clinical reasoning process that determines whether our outputs are meaningful or noise.

When we build an AI diagnostic tool that reports findings without considering pre-test probability, we're essentially creating a system that shouts "FIRE!" with equal volume whether there's smoke in a burning building or someone just lit a birthday candle. Both involve combustion, but the context—the pre-test probability of a serious fire—completely changes the appropriate response.

Every veterinary AI tool is inserted into a probability chain:

1. Veterinarian estimates pre-test probability (usually unconsciously)

2. AI tool provides information

3. Veterinarian updates probability based on that information

4. Clinical decision follows from updated probability

If our tools don't understand step 1, they can't meaningfully contribute to step 2, and they actually disrupt rather than enhance the clinical reasoning process.

The most successful veterinary AI tools will be those that:

• Explicitly incorporate pre-test probability into their algorithms

• Allow veterinarians to input their clinical suspicion level

• Adjust outputs based on prevalence and context

• Help veterinarians recognize when their probability estimates might be biased

• Enhance rather than replace the intuitive probability calculations that define expert clinical reasoning

Understanding pre-test probability isn't just about building better tools—it's about building tools that veterinarians will actually use. The AI companies that grasp this concept will create products that feel like natural extensions of clinical thinking. Those that ignore it will build sophisticated technology that sits unused because it doesn't fit how veterinary medicine actually works.

Cognitive Biases That Distort Pre-Test Probability (And How AI Can Help)

Even experienced clinicians fall into probability traps:

Availability Bias: Just saw three cases of leptospirosis? Your brain might overestimate pre-test probability for the next ADR dog. AI could provide gentle calibration: "While you've seen 3 lepto cases this week, regional prevalence remains at baseline (0.5%)."

Anchoring Bias: The referring vet says "probable Addison's." Now you're anchored to a higher pre-test probability than the clinical picture might warrant. AI as neutral second opinion: "Referral mentioned Addison's disease. Independent analysis suggests: Addison's 15%, GI foreign body 25%, pancreatitis 20%."

Base Rate Neglect: Fascinating presentation that could be pemphigus foliaceus! But if the pre-test probability is 0.01%, even "classic" signs don't make it likely. AI reminds: "Clinical signs consistent with pemphigus foliaceus, but given 0.01% incidence, consider allergic dermatitis (15% probability) first."

Confirmation Bias: Once you've estimated high pre-test probability, you might unconsciously weight confirming evidence more heavily. Advanced AI systems could track: "You've documented 4 findings supporting pancreatitis but may not have fully explored the normal appetite reported by owner, which reduces probability by approximately 20%."

Understanding these biases doesn't eliminate them, but AI tools that explicitly track and question our probability estimates can serve as powerful cognitive guardrails.

The AI Blind Spot Becomes a Two-Way Street

Current veterinary AI tools have a critical limitation: most have no mechanism for incorporating pre-test probability. When an AI imaging tool analyzes a radiograph, it typically doesn't know why the image was taken, the patient's signalment, or what clinical signs prompted the imaging.

The AI sees the image in isolation and might flag a slightly prominent pulmonary pattern in a young dog who came in for a broken nail (pre-test probability for respiratory disease: near zero) with the same confidence as in a coughing senior dog (pre-test probability: significant).

But here's the evolution happening now: Next-generation AI tools are beginning to ask for context. They prompt: "Why was this image taken?" "What clinical signs are present?" "What's your suspected diagnosis?"

This creates a powerful feedback loop:

1. You provide clinical context (establishing pre-test probability)

2. AI adjusts its interpretation thresholds based on that probability

3. AI provides findings weighted by clinical relevance

4. You refine your assessment based on AI-flagged findings you might have missed

The future isn't AI replacing clinical judgment—it's AI amplifying it by making pre-test probability explicit and actionable.

Building Your Probability Framework

You don't need to calculate exact percentages, but developing a mental framework helps sharpen clinical reasoning. Think in categories:

• Extremely unlikely (<1%): Would be shocked if this were the diagnosis

• Unlikely (1-10%): Would be surprised but not shocked

• Possible (10-30%): Definitely considering it

• Probable (30-70%): Leading differential

• Highly probable (>70%): Would be surprised if it's NOT this

Mentally arrange your differentials by pre-test probability. Know your action thresholds: below which probability you won't test (too many false positives), above which you'll treat empirically, and the zone between where testing adds value.

AI can enhance this framework by learning your probability language: "You marked this as 'possible' (10-30%). Based on similar cases, probability is likely closer to 45%. Key factors: breed predisposition (+15%) and elevated ALT (+10%)."

When Pre-Test Probability Gets Complex

Real cases rarely involve single diseases with independent probabilities. Consider a senior dog with PU/PD where diabetes (15%), Cushing's (20%), and renal disease (25%) are all possible, potentially simultaneously. Each test result reshapes all probabilities.

This is where the art truly meets the science. Your clinical experience integrates these complex, interrelated probabilities in ways that no current AI system can match. But AI can help track the complexity: "After negative urine glucose, updated probabilities: Diabetes <1%, Cushing's 28%, Renal disease 33%."

Key Insights for Veterinary Practice

🎯 Start with signalment-specific baselines: A limping Greyhound has vastly different pre-test probabilities than a limping Labrador. AI tools can provide breed-specific disease prevalence to calibrate your estimates.

🔍 Let pre-test probability guide test selection: Low pre-test probability? Need highly specific tests to avoid false positives. High pre-test probability? Even moderate sensitivity confirms your suspicion.

📊 Use the 10-30% testing zone: Below 10% pre-test probability, positive tests are often false. Above 30%, negative tests might be false. The sweet spot for testing is often in between.

🧮 Communicate probabilities to clients: "Based on everything we're seeing, I'd estimate about a 70% chance this is..." helps clients understand uncertainty and the value of testing.

⚠️ Use AI as a bias detector: Let AI flag when recent cases might be skewing your probability estimates or when you might be anchoring on initial impressions.

🤖 Provide context to AI tools: When using AI diagnostics, always consider whether the tool knows the clinical context that shapes pre-test probability. Better AI tools will explicitly ask for this context.

💭 Trust your gestalt, but verify: That "feeling" about a case is often your brain processing probability modifiers you can't articulate. AI can help identify what patterns you might be recognizing subconsciously.

🛠️ For tool builders: Design with probability in mind: If you're building veterinary AI, your tool must understand and respect the probability-based reasoning that drives clinical decisions.

Conclusion

Pre-test probability isn't some abstract statistical concept—it's the foundation of every clinical decision you make. The difference between a data scientist's approach and a clinician's isn't that one uses probability and the other doesn't. It's that I make it explicit with numbers while you integrate it intuitively through experience.

Your clinical experience has taught your brain to be a sophisticated probability calculator, integrating dozens of variables instantly to generate that "gut feeling" about a case. That's not unscientific—it's probability theory at work, refined by thousands of cases into pattern recognition that no AI currently matches.

The magic happens when we understand both approaches. The future of veterinary diagnostics isn't AI replacing your judgment; it's AI helping you understand, refine, and communicate the sophisticated probability calculations your brain is already performing. For those building these AI tools, understanding pre-test probability isn't optional—it's the difference between creating technology that enhances veterinary medicine and creating expensive distractions.

The next time you walk into an exam room and instantly start forming diagnostic suspicions, remember: you're not just guessing. You're running sophisticated probability calculations based on years of experience. Understanding that process explicitly doesn't diminish the art of medicine—it reveals the elegant mathematics underneath what we call clinical intuition.

This article scratches the surface of how probability theory underlies clinical decision-making. In an upcoming deep-dive post for paid subscribers, I'll explore the full Bayesian framework that drives diagnostic reasoning—including how to calculate exact post-test probabilities, the concept of diagnostic thresholds, how to handle multiple simultaneous conditions, and more practical ways to apply these concepts.

If you’d like an even deeper dive into these topics including extensions to testing and treatment decision making I have found this book: Medical Decision Making by Sox, Higgings, Owens and Schmidler a great resource.

How do you estimate pre-test probability in challenging cases? Have you used any AI tools that seem to understand clinical context better than others? For those building veterinary AI tools, how are you incorporating pre-test probability into your designs? I'd love to hear how understanding the probability framework—with or without AI assistance—has influenced your diagnostic approach or tool development.

After 29 years in the veterinary industry, I've witnessed countless attempts to make veterinary software systems work together. The results are mixed: we've achieved impressive integration in some areas while completely failing in others. But as AI tools proliferate across veterinary medicine—from diagnostic imaging systems to practice management software to laboratory analyzers—understanding what works, what doesn't, and why has never been more critical.

Here's why: Every AI system in your practice is only as good as the data it can access. When your diagnostic imaging AI can't share findings with your practice management system, when your laboratory results require manual re-entry into patient records, when client communications exist in isolated silos, you're not just losing efficiency—you're limiting the potential of every intelligent system you adopt.

The challenge isn't technological sophistication. We've proven we can build complex AI systems that analyze radiographs, interpret bloodwork, and even generate clinical notes. We've also proven we can connect different veterinary software systems—your practice management system receives lab results automatically, imaging systems integrate with PACS, and various third-party tools can access patient data.

The problem is more fundamental: while we've solved the technical challenges of making systems communicate, we've done it through expensive, proprietary solutions that don't scale, and we've completely failed to agree on what veterinary data actually means.

This fragmentation has broader implications beyond just technical inconvenience. As Jason DeFrancesco of VistaVet recently argued in "Veterinary Medicine Needs a Nervous System," the lack of interoperability prevents veterinary medicine from functioning as a coordinated system capable of learning from collective experience and responding to emerging challenges. When our practice management systems, diagnostic labs, and clinical tools can't share information meaningfully, we lose the ability to identify trends, improve outcomes systematically, and leverage the full potential of our collective clinical knowledge.

But there's hope. By understanding how interoperability actually works—and learning from both the partial successes and remaining failures in veterinary medicine—we can build the foundation for truly integrated veterinary practice management that leverages AI across all systems seamlessly.

The Three Layers of Interoperability: From Connections to Meaning

When most people think about making software systems work together, they imagine it's primarily a technical challenge—getting System A to send data to System B. But successful interoperability requires coordination across three distinct layers, each building on the previous one.

Layer 1: The Connection Layer - How Systems Talk

At the foundation, systems need to establish basic communication. This is like deciding whether to send information by email, fax, or carrier pigeon—the method matters, but it's just the transport mechanism.

In veterinary practice, you see this variety constantly:

• File dumps: Your lab analyzer exports results to a CSV file that someone manually imports into your practice management system

• Direct database access: Client communication system writes directly to your PIMS database

• Push APIs: Your diagnostic lab pushes results to your practice management system when they're ready

• Pull APIs: Your practice management system periodically checks for new results from various sources

Each approach has trade-offs. File dumps are simple but require manual intervention. APIs are elegant but require both systems to support them. Direct database access is fast but risky.

The key insight: the connection method isn't what determines success or failure. Plenty of veterinary integration projects have failed even with sophisticated API connections. The real challenges lie in the upper layers.

Layer 2: The Structural Layer - Agreeing on Data Format

Once systems can exchange information, they need to agree on how that information is organized. This is like deciding whether to write a letter in paragraph form, bullet points, or a formal business letter template—everyone needs to understand the structure to interpret the content correctly.

Veterinary software uses numerous structural formats:

• CSV files: Simple but limited—difficult to represent complex hierarchical data

• JSON: Flexible and widely supported, but requires careful schema design

• XML: Powerful for complex data structures but verbose and harder to work with

• HL7: The healthcare standard for clinical data exchange (rarely used in veterinary medicine)

• DICOM: The imaging standard that actually works across veterinary systems

The structural layer is where many veterinary interoperability projects stumble. Two systems might both export "patient data," but if one uses separate fields for "patient_name_first" and "patient_name_last" while the other uses "patient_full_name," automated integration becomes impossible.

Layer 3: The Semantic Layer - What Things Actually Mean

The most complex layer involves agreeing on what things are called and how they're coded. Even if two systems can exchange data in the same format, they need to agree on terminology and meaning.

This is where veterinary medicine faces its biggest challenge. Consider how many ways practices might record the same condition:

• "Vomiting" vs. "Emesis" vs. "V+" vs. "Gastric emptying disorder"

• "IMHA" vs. "Immune-mediated hemolytic anemia" vs. "Autoimmune hemolytic anemia"

• "Heartworm positive" vs. "HW+" vs. "Dirofilaria immitis infection"

Human medicine solved this through standard terminologies like SNOMED-CT and ICD-10. When a human hospital system records a diagnosis, it uses standardized codes that any other system can interpret correctly. Veterinary medicine has no widely adopted equivalent. [I explored how SNOMED-CT's veterinary extension could solve this problem in detail in a previous post about standardized terminology.]"

This semantic chaos means that even when systems can exchange data successfully, that data often can't be meaningfully integrated or analyzed across systems.

The Partial Success Stories: Connection and Structure Without Standards

Before examining the complete failures, let's understand what partial success looks like. Veterinary medicine has actually achieved limited interoperability in several areas—but always through expensive, proprietary solutions that create new problems even as they solve old ones.

DICOM: The One True Standard

In veterinary diagnostic imaging, we have genuine interoperability success: DICOM (Digital Imaging and Communications in Medicine). Walk into almost any veterinary practice with digital radiography, and you'll find something remarkable: the X-ray machine from Vendor A talks seamlessly to the PACS system from Vendor B, which displays images perfectly in the practice management system from Vendor C. This just works, across species, practice types, and vendor combinations.

DICOM succeeds because it addresses all three interoperability layers comprehensively:

Connection Layer: DICOM defines exactly how imaging devices connect and authenticate with receiving systems.

Structural Layer: DICOM specifies precise data formats for images, metadata, and associated clinical information.

Semantic Layer: DICOM includes standardized terminology for anatomical regions, imaging procedures, and equipment specifications.

The result? True plug-and-play interoperability that just works.

PIMS-LIMS Integration: Working, But at What Cost?

The integration between Practice Information Management Systems (PIMS) and Laboratory Information Management Systems (LIMS) represents veterinary medicine's other partial interoperability success. Your practice management system automatically receives results from IDEXX, Antech, Zoetis, and possibly other diagnostic laboratories without manual data entry.

But here's the critical insight: this interoperability comes at enormous hidden costs.

Every laboratory connection is completely proprietary:

• Connecting to IDEXX lab data works differently than connecting to Antech

• Antech integration differs from Zoetis integration

• Each requires separate development efforts, different APIs, distinct data formats

• When labs upgrade systems, integrations often break and require redevelopment

Additionally, limited interoperability exists with some PIMS systems, but these suffer from the same challenges. The same pattern exists within PIMS vendors themselves. Even single companies use different integration methods across their products:

• IDEXX ezyVet integration differs from IDEXX Neo integration

• Both differ from IDEXX Cornerstone integration

• Each requires separate development and maintenance efforts

These integrations work at the connection and structural layers—labs successfully push results to practice management systems. But the absence of standards means that every integration is a custom engineering project.

The Hidden Costs of Proprietary Integration

Perfect addition! This is a crucial piece of the current landscape that shows both the demand for integration solutions and the limitations of approaches that don't address all three layers. Let me integrate this into the "Hidden Costs of Proprietary Integration" section:

The Hidden Costs of Proprietary Integration

Consider what this means for a third-party developer trying to build an AI clinical decision support tool:

• To integrate with the top 5 PIMS systems, they need to build 5 completely different integrations

• To connect with the top 3 diagnostic labs, that's 3 more unique integrations

• Each integration requires different authentication, data formats, and update mechanisms

• When any vendor updates their system, integrations may break

• Supporting 8 systems means maintaining 8 separate codebases

The development effort doesn't scale linearly—it multiplies exponentially. This is why most veterinary AI tools remain isolated applications rather than integrated practice solutions.

The Integration-as-a-Service Band-Aid

Recognizing these challenges, several companies have emerged to act as integration intermediaries: VetData, Datapoint (acquired by IDEXX in 2017), and Bitwerx are examples of this approach. These services promise to solve the integration complexity by providing a single API that connects to multiple PIMS systems.

The value proposition is appealing: Instead of building separate integrations to ezyVet, Cornerstone, Neo, AVImark, and others, developers can integrate once with the intermediary service and gain access to all connected PIMS.

But these solutions face the same fundamental challenges, just centralized:

• They still must build and maintain separate proprietary connections to each PIMS

• Each PIMS system change still requires custom adaptation and testing

• They create their own proprietary API layer, adding another integration dependency

• When they add new PIMS support, existing integrations may need updates

• They each only integrate with a small subset of PIMS systems

• If the service provider goes out of business or changes focus, all dependent applications break

Most critically, these services operate only at the connection and structural layers. They can deliver patient demographic data and basic clinical information in a consistent format, but they don't solve the semantic layer problems. A diagnosis of "DM" in one practice still comes through as "DM" while "diabetes mellitus" in another practice remains "diabetes mellitus"—the terminology chaos persists.

The New Dependencies and Risks

Integration-as-a-service creates new categories of risk:

Single Point of Failure: Your application's connection to dozens of practices now depends on one intermediary service's uptime and performance.

Vendor Lock-In: Switching integration providers requires rebuilding connections, similar to switching PIMS vendors.

Cost Scaling: As these services grow and gain market power, they can increase pricing or change terms, affecting all dependent applications.

Feature Limitations: You're constrained by whatever data fields and capabilities the intermediary chooses to support across all connected PIMS.

The development effort doesn't disappear—it just gets centralized and creates new dependencies. While this approach can accelerate initial development, it doesn't solve the underlying interoperability problems and may actually make long-term solutions more difficult by entrenching proprietary approaches.

The Complete Failure: The Semantic Layer Problem

Even when we successfully connect systems and exchange data, we face veterinary medicine's greatest interoperability challenge: no two practices use the same terminology for anything.

The Tower of Babel Reality

Imagine you're building an AI system that needs to analyze treatment outcomes across practices. You successfully integrate with five different PIMS systems and can extract diagnostic and treatment data from all of them. But when you try to analyze the data, you discover that the same medical condition appears as:

• Practice A: "DM" or "ENDO-01" (custom code)

• Practice B: "Diabetes" or "Type 1 diabetes"

• Practice C: "Endocrine disorder" or whatever the veterinarian feels like typing that day

All three practices are recording the same medical condition, but your AI system sees them as completely different diseases. Even sophisticated natural language processing struggles with this variability, especially when veterinarians use abbreviations, clinical shorthand, or practice-specific terminology.

The Multi-Practice Data Challenge

This semantic inconsistency makes several critical applications impossible:

Population Health Analytics: You can't track disease prevalence across practices when the same disease is recorded differently in each system.

AI Training Data: Machine learning models trained on Practice A's "DM" data won't recognize Practice B's "diabetes mellitus" as the same condition.

Quality Improvement: Comparing treatment outcomes requires first solving a massive terminology translation problem.

Research Collaboration: Multi-practice studies spend enormous effort harmonizing terminology before any actual analysis can begin.

The False Hope of Point-of-Care Coding

The obvious solution seems simple: just make everyone use standard codes like SNOMED-CT when entering data. This approach has failed everywhere it's been tried.

Veterinarians don't want to become medical coders. They're focused on patient care, not database management. Forcing structured data entry at the point of care slows down clinical workflows and increases cognitive burden. Even human medicine, with massive regulatory incentives and dedicated coding staff, struggles with coding accuracy and consistency.

But there's a deeper problem: forcing coding at the point of care fundamentally constrains clinical expressiveness.

Consider a complex case: a 12-year-old Golden Retriever with lethargy, mild azotemia, and a heart murmur that wasn't present six months ago. The veterinarian suspects early kidney disease but can't rule out cardiac involvement, and the breed predisposition for both conditions makes the diagnostic picture unclear.

Standard coding systems force this nuanced clinical picture into rigid categories. Is this "chronic kidney disease" or "heart murmur" or "lethargy"? The coding system demands a choice, but the clinical reality is uncertainty and interconnected possibilities. The veterinarian ends up either oversimplifying the case to fit the codes or spending excessive time trying to find codes that capture the full clinical complexity.

This loss of expressiveness isn't just inconvenient—it's clinically dangerous. When systems force artificial precision where uncertainty exists, they lose critical information about the veterinarian's clinical reasoning, differential considerations, and diagnostic confidence levels. Rich clinical narratives that capture the complexity and uncertainty of real cases get reduced to simplistic code combinations that miss the subtleties crucial for patient care.

The solution has to happen on the backend, not at the point of care. We need systems that preserve the full richness of clinical expression while providing standardized coding for data sharing and analysis.

Why This Matters More Than Ever: The AI Integration Imperative

The interoperability challenges that seemed merely inconvenient in the era of standalone software become critical as AI proliferates across veterinary practice.

AI Systems Need Comprehensive Data

Modern AI tools perform best when they can access complete patient information. An AI system analyzing radiographs benefits from knowing the patient's clinical history, laboratory results, and previous imaging studies. But when that information exists in incompatible formats with inconsistent terminology across multiple systems, the AI operates with incomplete understanding.

The Training Data Crisis

Large language models and machine learning systems require vast amounts of structured, consistent data for training. When veterinary data exists in semantic chaos across thousands of isolated systems, it becomes extremely difficult to aggregate for AI training purposes. This fragmentation may be limiting the development of powerful veterinary-specific AI tools.

Clinical Decision Support Failures

The most valuable AI applications provide real-time clinical decision support—suggesting differential diagnoses, flagging drug interactions, recommending diagnostic tests. These systems only work when they can access comprehensive, consistently coded patient data from all relevant sources.

Without semantic consistency, an AI system might miss that "DM" in the PIMS, "diabetes" in the lab results, and "high glucose" in the clinical notes all refer to the same condition requiring coordinated treatment.

The Path Forward: Backend Coding and Translation

The solution to veterinary interoperability lies not in forcing point-of-care standardization, but in intelligent backend processing that preserves clinical workflow while enabling data integration.

The Translation Layer Approach

Instead of making veterinarians code their entries, we need systems that:

1. Capture rich clinical narratives in whatever terminology veterinarians naturally use

2. Apply intelligent coding using natural language processing and veterinary-specific models

3. Map to standard terminologies like SNOMED-CT Veterinary Extension for data sharing

4. Maintain bidirectional translation so data can be shared in standard formats but displayed in familiar terminology

Learning from Human Healthcare

Human medicine is moving toward this approach with systems that:

• Use natural language processing to extract coded concepts from clinical notes

• Apply standard terminologies for data sharing while preserving original documentation

• Leverage large language models to improve coding accuracy and consistency

• Enable semantic interoperability without disrupting clinical workflows

Veterinary medicine needs equivalent systems adapted for multi-species complexity and veterinary-specific terminology.

The Technology Foundation Exists

The tools for solving veterinary semantic interoperability are available:

SNOMED-CT Veterinary Extension: Provides standardized codes for veterinary diagnoses, procedures, and clinical findings across species. [For a detailed exploration of how SNOMED-CT can be implemented in veterinary practice without disrupting clinical workflows, see my previous article on veterinary terminology standardization.]

Veterinary Natural Language Processing: Emerging models trained specifically on veterinary clinical text can identify and code medical concepts automatically.

Translation Mapping Services: Systems that can map between different terminology systems and learn from usage patterns across practices.

Modern APIs and Data Standards: HL7 FHIR provides the structural foundation for healthcare data exchange and can be adapted for veterinary use.

Key Insights for Veterinary Practice

🔍 Understand the Hidden Integration Costs: When evaluating software, ask about integration capabilities and ongoing maintenance costs. Proprietary integrations may work initially but create long-term dependency and upgrade risks.

📋 Document Your Terminology Patterns: Start cataloging how your practice names conditions, procedures, and findings. This prepares you for backend coding systems and reveals opportunities for internal consistency improvements.

🔄 Evaluate Integration Scalability: Choose software vendors that are moving toward standards-based approaches rather than purely proprietary solutions. Ask specifically about FHIR support and standard terminology adoption plans.

🤝 Support Backend Coding Initiatives: Look for AI tools and practice management systems that offer intelligent coding services rather than forcing manual standardization at data entry.

📊 Prepare for Semantic Integration: Understand that the most powerful AI applications will require consistent terminology across systems. Practices that invest in backend translation capabilities will have significant advantages.

🏗️ Think Long-Term: Make technology decisions with semantic interoperability in mind. Systems that can export and import standard-coded data provide more flexibility as translation services become available.

💡 Demand Transparency: Ask vendors specifically about their semantic layer capabilities. How do they handle terminology variation? What standard codes do they support? How do they plan to enable data sharing across practices?

Conclusion

Veterinary medicine has achieved partial interoperability through enormous investment in proprietary solutions. We can exchange data between PIMS and LIMS, integrate third-party applications, and build functional software ecosystems. But we've done it the expensive, non-scalable way.

The proliferation of AI tools makes this approach unsustainable. Every new integration requires custom development. Every vendor change breaks existing connections. Most critically, the semantic chaos prevents us from building the intelligent, data-driven practice management systems that could transform patient care.

The solution isn't forcing veterinarians to become medical coders. It's building intelligent backend systems that can translate between veterinary terminology and standard codes, enabling semantic interoperability without disrupting clinical workflows.

The economic incentives are aligning as AI companies need consistent training data, practice management vendors need competitive differentiation, and veterinary practices need systems that actually work together. The foundation exists through DICOM's success, emerging veterinary terminology standards, and advancing natural language processing capabilities.

The choice is clear: continue with expensive proprietary solutions that don't scale, or coordinate industry-wide on comprehensive standards that enable the AI-powered, integrated veterinary practices of the future.

What integration challenges frustrate you most in daily practice? Have you experienced the hidden costs of proprietary integrations when systems get upgraded or vendors change? Share your experiences—understanding real-world integration pain points helps identify where standardization efforts should focus first.

When you document that a patient is "vomiting," an AI might generate "experiencing emesis" in your SOAP note. Both are correct. But how do we teach a computer to know when "ADR" means "adverse drug reaction" in one context and "ain't doing right" in another?

The answer reveals why evaluating veterinary AI is surprisingly complex—and why the metrics most vendors cite might be dangerously misleading.

In my previous post about LLM hallucinations, I explained why these systems inevitably generate plausible-sounding but incorrect information. Today, we're tackling the flip side: how do we actually measure whether an LLM is performing well in veterinary practice?

After nearly three decades in veterinary diagnostics and extensive work with LLMs, I've learned that the evaluation metrics that sound most impressive are often the least meaningful for clinical practice. Just as positive predictive value (PPV) misleads us about diagnostic tests, traditional NLP metrics can make dangerous AI look deceptively good.

Why Traditional Metrics Fail Spectacularly

Imagine grading a student's essay by counting how many words match the answer key. That's essentially what traditional AI metrics do—and it's about as useful as you'd expect for evaluating clinical documentation.

The Dangerous Flip That Proves the Point

Let me show you why this matters with a real example. Consider an AI reviewing this case: "Labrador with elevated ALT levels indicating possible liver disease."

Three AI responses:

1. "Dog shows increased ALT suggesting hepatic dysfunction"

2. "Patient has high liver enzymes indicating potential liver pathology"

3. "Dog's ALT levels are significantly low, indicating healthy liver function"

The third response is clinically opposite—it could lead to missing serious liver disease. Yet when we score these with traditional metrics, something shocking happens:

The dangerous error scores almost twice as high as the correct answers! This isn't a quirk—it's a fundamental flaw in how these metrics work.

Understanding the Metrics (And Why They Mislead)

BLEU and ROUGE are traditional NLP metrics that have been used for decades to evaluate text generation in machine translation and summarization. While most veterinary AI vendors don't cite any metrics at all (red flag!), if they did use standard NLP evaluation, these would likely be the ones. They literally count matching words and phrases between AI output and reference examples. If the reference says "gave subcutaneous fluids" and the AI writes "administered SQ fluids," these metrics score it as wrong—even though any veterinarian knows they're identical. Research shows these metrics correlate with human medical judgment very poorly.1

BERTScore represents an improvement—it understands that "puppy" and "young dog" mean similar things, achieving about 62-80% correlation with human experts. But it still can't tell if a drug dose is appropriate for a cat versus a dog. It sees semantic similarity but misses clinical significance.2

The Benchmark Trap: Many AI companies tout high scores on multiple-choice veterinary exams. But real clinical work isn't multiple choice. A system that aces the NAVLE might still generate dangerous free-text recommendations. We need evaluation that matches how AI is actually used, not how it performs on standardized tests.

Fortunately, three evaluation approaches have emerged that actually catch these dangerous errors before they reach your patients—and knowing which one fits your practice could be the difference between AI that saves time and AI that creates liability.

Read more

A recent LinkedIn post by Dr. Aaron Smiley about SNOMED-CT in veterinary medicine sparked a discussion that gets to the heart of one of our industry's most persistent challenges: how do we create interoperable clinical data without forcing veterinarians to change how they practice?

Dr. Smiley's post highlighted how SNOMED-CT represents a foundational step toward making clinical knowledge computable and shareable across the veterinary profession. As he noted, the combination of SNOMED-CT with modern AI capabilities like large language models presents an opportunity to transform how we capture and utilize clinical data. The ensuing discussion in the comments revealed something I've observed repeatedly over my 29 years in veterinary diagnostics: there's widespread confusion about what clinical terminology standards are, how they work, and most importantly, how they can be implemented without disrupting clinical workflows.

After watching numerous attempts to force coding systems into veterinary practice management software—all of which have failed—I've come to believe that the solution isn't making veterinarians code at the point of care. It's applying standardized terminology intelligently to the rich clinical data they're already creating.

Today, I want to demystify SNOMED-CT, explain why it represents a promising path forward for veterinary clinical terminology, and most importantly, show how modern approaches can deliver the benefits of standardization without the workflow disruption that has doomed previous efforts.

The Standardization Imperative: Why We Can't Build the Future on Babel

Before diving into solutions, let's be clear about the problem. Every veterinary practice, every practice management system, and often every individual veterinarian uses slightly different terminology to describe the same clinical concepts:

• "Vomiting" vs. "Emesis" vs. "Throwing up" vs. "Gastric emptying"

• "IMHA" vs. "Immune-mediated hemolytic anemia" vs. "Autoimmune hemolytic anemia"

• "Heartworm positive" vs. "HW+" vs. "Dirofilaria immitis infection" vs. "Canine heartworm disease"

This Tower of Babel creates cascading problems that become more critical as we advance toward AI-enabled veterinary medicine:

The Interoperability Crisis

When a patient transfers between clinics, their medical history becomes a translation exercise. Specialists struggle to aggregate referral data. Emergency clinics can't quickly parse historical records. Multi-site practices can't analyze data across locations. Each translation introduces potential for error and lost information.

The Research Roadblock

Multi-center clinical studies require enormous manual effort to harmonize data. Epidemiological surveillance becomes nearly impossible at scale. Outcomes research lacks the standardized endpoints needed for meaningful analysis. We're essentially unable to learn systematically from the millions of cases seen annually.

The AI Training Bottleneck

Here's where the stakes become existential for veterinary AI advancement: Machine learning models require consistently labeled training data. Without standardization, every dataset requires extensive manual curation. Models trained on one clinic's terminology won't generalize to others. We're forced to solve the same problems repeatedly instead of building on previous work.

As commenters on Dr. Smiley's post noted, the lack of standardization limits our ability to leverage the full potential of our clinical data for improving patient care and advancing the profession.

What Exactly Is a Clinical Terminology Standard?

A clinical terminology standard isn't just a dictionary—it's a comprehensive system for representing medical concepts in a computationally useful way. Think of it as a universal translator that allows different systems to understand they're talking about the same thing, even when using different words.

Core Components of a Terminology Standard

Concepts: Unique identifiers for distinct medical ideas. "Canine parvovirus infection" gets one ID regardless of how it's expressed.

Descriptions: Multiple ways to express the same concept. The concept for "vomiting" includes synonyms like "emesis," "throwing up," and "gastric emptying."

Relationships: How concepts connect to each other. "Canine parvovirus infection" IS-A "viral disease" which IS-A "infectious disease" which IS-A "disease."

Hierarchies: Organization from general to specific. This enables reasoning at different levels of granularity—crucial for both clinical decision support and research applications.

Enter SNOMED-CT: An International Standard Worth Considering

While veterinary medicine lacks any widely adopted terminology standard—with practices using everything from VeNOM to proprietary systems to no coding at all—SNOMED Clinical Terms (SNOMED-CT) offers unique advantages worth understanding. Here's what makes it different from the various veterinary-specific standards that have been attempted:

The Architecture of SNOMED-CT

SNOMED-CT is built on description logic, a formal system that allows computers to reason about medical concepts. Each concept has:

• A unique numerical identifier (SCTID)

• A fully specified name (FSN) that uniquely describes it

• Multiple synonyms and descriptions

• Formal relationships to other concepts

For example:

• Concept: 84114007

• FSN: Canine distemper (disorder)

• Synonyms: Distemper in dogs, Canine distemper virus infection

• Parent: Viral disease

• Finding site: Entire body system

The Veterinary Extension: VTSL's Critical Contribution

The Veterinary Terminology Services Laboratory (VTSL) at Virginia Tech maintains the veterinary extension to SNOMED-CT (VetSCT). While SNOMED-CT's international release includes some animal-related content, it lacks much of what's needed for comprehensive veterinary records. The veterinary extension fills these gaps with over 30,000 veterinary-specific concepts including:

• Species-specific anatomical terms

• Breed specifications

• Veterinary procedures and diagnostics

• Drug formulations specific to veterinary use

Importantly, VTSL places the veterinary extension in the public domain (consistent with SNOMED-CT licensing) and maintains it in alignment with SNOMED-CT's regular release cycles. The extension is also incorporated into the Unified Medical Language System (UMLS), making it accessible for both commercial and non-commercial applications. (Learn more at vtsl.vetmed.vt.edu/extension/)

This extension makes SNOMED-CT truly capable of representing the full scope of veterinary medicine, from exotic animal practice to equine surgery to small animal internal medicine.

The SA-PDT: Making SNOMED-CT Practical for Small Animal Practice

The Small Animal Problem and Diagnosis Terms (SA-PDT)—which many practitioners still know by its former name, "AAHA Diagnostic Terms"—represents a pragmatic approach to SNOMED-CT adoption for veterinary practices. It's a curated subset of SNOMED-CT that covers general, specialty, and emergency small animal practices, actively maintained by the Veterinary Terminology Services Laboratory (VTSL) at Virginia Tech. (For those interested in its evolution and history, visit the VTSL website at vtsl.vetmed.vt.edu/sa/)

Think of it this way: SNOMED-CT is like the Oxford English Dictionary—comprehensive but overwhelming. The SA-PDT is like a practical medical dictionary for daily use—containing the terms you actually need without the complexity you don't.

Many practitioners don't realize that when they see diagnostic terms in their practice management system, they might be using SNOMED-CT concepts through the SA-PDT, just in a more accessible package—though many systems still use other coding approaches or proprietary terms. The SA-PDT is actively maintained and regularly updated to align with international SNOMED-CT releases, ensuring it stays current with evolving medical knowledge.

Why SNOMED-CT Beats Veterinary-Specific Alternatives

Over the years, several veterinary-specific coding systems have been developed, including VeNOM (Veterinary Nomenclature) and various proprietary systems. None have achieved widespread adoption. Here's why SNOMED-CT is different:

International Infrastructure

SNOMED International maintains the core terminology with resources no veterinary-specific organization could match. There are established governance processes, regular updates, and quality assurance mechanisms. The infrastructure for translation, distribution, and implementation already exists.

Human Medicine Integration

As One Health initiatives expand, having veterinary data in the same framework as human medical data becomes invaluable. Zoonotic disease surveillance can leverage both datasets. Comparative medicine research becomes computationally feasible. Drug safety signals can be detected across species.

Active Maintenance and Evolution

Unlike static coding systems, SNOMED-CT evolves continuously. New diseases, procedures, and concepts are added regularly. The veterinary extension is updated to reflect advances in veterinary medicine. Relationships are refined based on new medical knowledge.

Tooling and Ecosystem

Because SNOMED-CT is an international standard, there's a rich ecosystem of tools for implementation, including browsers, validators, mapping tools, and integration engines. You're not starting from scratch.

The Frontend Coding Fallacy: Why Point-of-Care Coding Has Failed

Here's where I need to address the elephant in the room: every attempt to make veterinarians code diagnoses at the point of care has failed. I've watched this movie repeatedly over three decades, and it always ends the same way.

The Veterinary Workflow Reality

Veterinarians are focused on patient care, not data entry. Clinical reasoning is fluid and iterative, not categorical. Definitive diagnoses are often elusive in veterinary medicine. Time pressure makes additional documentation burdensome. The EMR should adapt to clinical workflow, not vice versa.

Lessons from Human Medicine's Struggles

Human medicine, despite having financial incentives through insurance billing, still struggles with diagnostic coding accuracy:

Studies show 20-30% error rates in ICD-10 coding even with dedicated coding staff. Physicians report coding requirements as a major contributor to burnout. Gaming of codes for reimbursement optimization corrupts data quality. "Upcoding" and "downcoding" based on payment incentives distort clinical reality.

If human medicine can't get frontend coding right with billions in billing at stake, why would we expect veterinary medicine to succeed without those incentives?

The Premature Lock-in Problem

Forcing coding at the point of care creates a fundamental problem: it locks data into yesterday's technology and processes forever. Once you've coded everything as ICD-9, migrating to ICD-10 becomes a massive undertaking. If you've committed to VeNOM, switching to SNOMED-CT requires recoding everything. You're trapped by decisions made before you understood your ultimate needs.

But if you preserve the raw clinical data—the actual words veterinarians use—you can apply whatever coding system makes sense for your current use case, using the best available technology.

The Modern Solution: Intelligent Backend Processing

Instead of forcing veterinarians to code, modern approaches apply SNOMED-CT through intelligent backend processing. Here's how this works in practice—and as Dr. Smiley's post suggested, this is where AI and LLMs can transform the landscape:

Natural Language Processing (NLP) and LLM Pipelines

Modern NLP and large language models can extract medical concepts from free-text clinical notes with increasing accuracy. Veterinary-trained models understand context and clinical language variations. Systems can recognize that "ADR" in context means "Ain't Doing Right," not "Adverse Drug Reaction." Confidence scores indicate when human review is needed.

Flexible Mapping Strategies

Different use cases require different granularity levels. Research might need specific diagnoses while population health needs broader categories. Quality metrics might focus on procedures while billing needs diagnostic codes. By maintaining raw data and applying mappings as needed, you can serve all use cases without compromising any.

Human-in-the-Loop Validation

For high-stakes applications, automated coding can be reviewed and refined by experts. Machine learning models improve based on corrections. Edge cases and ambiguities are flagged for human judgment. The system gets smarter over time while maintaining quality.

Real-Time and Batch Processing Options

Some applications need immediate coding (clinical decision support), while others can wait (research databases, quality metrics). The same infrastructure can support both models, applying the appropriate level of processing for each use case.

UMLS: The Rosetta Stone of Medical Terminology

The Unified Medical Language System (UMLS) deserves mention as the meta-terminology that connects different coding systems. Maintained by the National Library of Medicine, UMLS:

• Maps between different terminologies (SNOMED-CT, ICD-10, LOINC, RxNorm)

• Provides tools for terminology services and natural language processing

• Enables semantic interoperability across different coding systems

• Includes veterinary terminology through the SNOMED-CT veterinary extension

For organizations building terminology services, UMLS provides crucial infrastructure for managing the complexity of medical language.

The Persistent Challenges

Despite these advances, significant challenges remain in achieving true clinical data standardization:

The Definitive Diagnosis Problem

Veterinary medicine often deals with probable rather than confirmed diagnoses. "Suspected pancreatitis" vs. "Confirmed pancreatitis" vs. "Clinical pancreatitis" all represent different levels of diagnostic certainty. Economic constraints limit diagnostic workups, leaving many cases unconfirmed. Post-mortem confirmation is rare, eliminating the feedback loop that validates diagnoses.

The Granularity Dilemma

Too specific, and you fragment data into unusably small buckets. Too general, and you lose clinically important distinctions. Finding the right level for each use case requires careful consideration and often multiple simultaneous representations.

The Temporal Evolution Challenge

Clinical understanding evolves during case management. What starts as "vomiting" might become "foreign body obstruction" then "intestinal foreign body requiring surgical removal." Capturing this evolution while maintaining queryable data requires sophisticated temporal modeling.

The Variation in Practice Standards

Different specialties use different terminology. Geographic regions have naming variations. Academic vs. private practice language differs. Creating a system that works for everyone while maintaining precision is enormously complex.

Building Tomorrow's Infrastructure Today

The path forward isn't choosing between standardization and clinical workflow—it's building systems that achieve both. Here's what that looks like:

For Practice Management System Vendors

• Capture rich clinical narratives without forcing structured entry

• Build backend services that can apply SNOMED-CT mappings

• Provide APIs that expose both raw and coded data

• Support gradual adoption rather than all-or-nothing implementation

For Veterinary Practices

• Focus on complete, accurate clinical documentation in natural language

• Participate in pilot programs testing new terminology services

• Provide feedback on automated coding accuracy

• Understand that standardization enables, not replaces, clinical judgment

For the Research Community

• Develop and validate veterinary-specific NLP models

• Create open-source tools for SNOMED-CT implementation

• Publish mapping algorithms and validation studies

• Build consensus on standard representations for common scenarios

Key Insights for Veterinary Practice

🎯 Document naturally, code intelligently: Focus on complete clinical documentation in your own words. Let backend systems handle the standardization—that's a technology problem, not a clinical one.

📝 Understand your coding exposure: Know which systems in your practice use diagnostic codes and for what purposes. This helps you evaluate whether standardization efforts will benefit your specific needs.

🔄 Preserve raw data: Ensure your practice management system maintains original clinical notes, not just coded summaries. Raw data can be recoded as standards evolve.

🤝 Participate in standardization efforts: When opportunities arise to provide feedback on terminology standards or participate in validation studies, your input shapes tools that will serve the profession.

⚡ Prepare for AI advantages: Practices with standardized, queryable clinical data will have significant advantages in adopting AI tools for decision support, quality improvement, and operational efficiency.

🔍 Ask vendors the right questions: When evaluating new systems, ask: "How do you handle clinical terminology?" "Can you map to SNOMED-CT?" "How do you preserve clinical narrative while enabling analytics?"

📊 Think about data utility: Consider how standardized terminology could help you: analyze treatment outcomes across your practice, participate in multi-center research, benchmark against other practices, or identify population health trends.

🚫 Resist frontend coding mandates: If vendors push point-of-care coding requirements, push back. The technology should adapt to your workflow, not the reverse.

🌐 Embrace interoperability: As practices increasingly share patients and data, those using standardized terminology will integrate more seamlessly with referral networks and emergency clinics.

📈 Start small, think big: Begin with simple use cases like problem lists or vaccination records. Build comfort with standardized terminology before tackling complex diagnostic coding.

Conclusion

The discussion sparked by Dr. Smiley's LinkedIn post highlights a critical inflection point for veterinary medicine. As we build AI systems that can truly augment veterinary decision-making, standardized clinical terminology isn't optional—it's fundamental.

But standardization doesn't mean forcing veterinarians to become medical coders. The failures of frontend coding attempts over the past 30 years have taught us that technology must adapt to clinical workflow, not the other way around.

SNOMED-CT, particularly with the veterinary extension maintained by VTSL and practical subsets like the SA-PDT, provides the foundation for semantic interoperability. Combined with modern NLP and intelligent backend processing—especially the new capabilities of large language models that Dr. Smiley highlighted—we can achieve standardization without workflow disruption.

The path forward requires collaboration between technology vendors, veterinary practices, researchers, and standards organizations. It requires investment in infrastructure that might not show immediate returns but will enable transformative advances in veterinary AI, clinical research, and population health.

Most importantly, it requires understanding that standardization serves clinical medicine, not the reverse. The goal isn't perfect coding—it's better patient care through better data.

The veterinary profession stands at a crossroads. We can continue with our Tower of Babel, limiting our ability to learn from collective experience and leverage advancing AI technologies. Or we can embrace thoughtful standardization that preserves clinical narrative while enabling computational analysis.

The choice we make today determines whether veterinary medicine can fully participate in the AI revolution. With SNOMED-CT and intelligent implementation strategies, we have the tools. Now we need the will.

Ready to explore how standardized terminology can transform your practice's data? Have experience with coding systems in veterinary medicine? Join the conversation—I'd love to hear your thoughts on building a future where technology amplifies, not complicates, veterinary care.

This week's headlines about DeepSeek and data security concerns have brought a familiar question back to the forefront: "Is it safe to use this AI tool for practice-related tasks?" The recent reports suggesting potential data collection by Chinese AI services have reignited veterinary professionals' concerns about AI security—but much of the confusion stems from not understanding the fundamental difference between the model (the AI engine) and the implementation (how you access and use it).

When DeepSeek's large language model first emerged from China earlier this year around the time of VMX, I watched colleagues grapple with this same question. The confusion wasn't about the technology itself—it was about mixing up these two distinct components. This distinction isn't academic. It directly impacts data security, compliance decisions, and how you evaluate AI tools for your practice.

Understanding the Core Components

Think of a large language model like a sophisticated reference book, while implementations are different ways to access and use that book.

The Model: Your AI "Reference Book"

The model is the trained artificial intelligence system—essentially a massive set of mathematical weights and parameters that have learned patterns from text data. It's static once trained, generates responses through probabilistic sampling (which means slight variations in output even with identical inputs), contains no stored conversations, and is fundamentally just mathematics. Popular models include GPT-4 from OpenAI, Claude from Anthropic, Gemini from Google, DeepSeek from DeepSeek AI, and Llama from Meta.

The Implementation: How You Access the "Book"

The implementation is how the model is packaged and delivered to users. This is where your data security and privacy concerns actually live. Implementations range from direct API access (raw, programmatic connection with minimal data logging) to consumer applications like ChatGPT and Claude.ai (polished interfaces that store conversation history and may use data for training) to enterprise solutions (business-focused implementations with enhanced security controls) to self-hosted deployments (running the model on your own infrastructure with complete data control).

The DeepSeek Example: Separating Model from Access

The recent news coverage about DeepSeek and data security perfectly illustrates why this distinction matters. When evaluating DeepSeek—or any AI tool—there are legitimate concerns about certain implementations: data sent to Chinese servers if using their hosted service, potential compliance issues with client data, unknown data retention policies, and geopolitical considerations.

However, there are also misunderstandings about the DeepSeek model itself. The model doesn't "phone home" with your data, open-source versions can run locally without internet connectivity, the model weights themselves don't pose inherent security risks, and Chinese origin doesn't make the mathematics dangerous.

The key insight: Your security risk comes from where you send your data, not from which model processes it.

Practical Security Framework for Veterinary Practices

When evaluating any AI tool, focus on the implementation, not just the model. Avoid consumer chatbots with unclear data policies, free services that may use conversations for training, international services without clear data residency, and platforms without established veterinary industry presence for any client data.

Use caution with business APIs with standard data protection, services with clear deletion policies, and established providers with transparent terms for non-sensitive practice tasks. Consider enterprise solutions with veterinary-specific compliance, self-hosted deployments with local processing, and services with explicit no-training guarantees for sensitive use cases.

Real-World Applications in Veterinary Practice

Understanding this distinction helps you make better decisions about AI tools across different use cases.

For client communications and sensitive practice data, use enterprise implementations with clear data policies or consider self-hosted solutions. Avoid consumer applications for client-related communications entirely.

For educational content and general learning, consumer applications may be acceptable since you're focusing on output quality over implementation security. You can safely use various models to compare responses when working with non-sensitive information.

For practice operations, match implementation security to data sensitivity. Financial data requires enterprise-grade solutions, while general workflow assistance may use standard business APIs.

The Veterinary Vendor Layer: Where Your Data Actually Goes

Here's where things get more complex for veterinary practices: most AI-powered veterinary software doesn't give you direct access to models. Instead, vendors of practice management systems, scribe services, and diagnostic tools integrate LLMs into their platforms—and each vendor makes different choices about how to handle your data.

When you use an AI-powered veterinary tool, your practice data typically follows one of these paths:

Third-Party API Services: Many vendors use services like OpenAI's API, Anthropic's Claude API, or Google's Gemini API. Your data gets sent from the vendor's software to these external services for processing. The data handling depends on the vendor's specific API contract—some have no-training guarantees, others don't.

Cloud Provider Hosted Models: Some vendors use models hosted on platforms like AWS Bedrock, Microsoft Azure AI, or Google Cloud AI. These typically offer stronger data residency and privacy controls than consumer APIs, but the specifics depend on how the vendor configured their service.

Self-Hosted Solutions: A few vendors run LLMs on their own infrastructure, giving them complete control over data handling. This can offer the strongest privacy protections but requires more technical expertise and resources from the vendor.

Hybrid Approaches: Some vendors combine multiple approaches, using different models or hosting options for different features within the same platform.

The critical question: Most veterinary software vendors don't clearly communicate which approach they're using. When you're entering client notes into an AI-powered scribe system or running diagnostic content through an AI assistant, do you know whether that data is being sent to OpenAI, processed on AWS, or handled entirely within the vendor's infrastructure?

What to Ask Your Veterinary Software Vendors

Before implementing any AI-powered veterinary tool, demand transparency about their LLM integration:

Which LLM service or model are they using? Are they using OpenAI's API, a cloud provider's hosted model, or running models themselves?

Where does your practice data go for processing? Does it stay within the vendor's infrastructure, get sent to third-party AI services, or travel to cloud providers?

What are the data handling guarantees? Does the vendor have explicit agreements that practice data won't be used for training other models? How long is data retained during processing?

What happens to data in transit and at rest? Is your practice data encrypted when sent for AI processing? Are there logs of your data being processed?

Do they have compliance certifications? Are their AI integrations covered under their HIPAA, SOC 2, or other compliance certifications?

Many vendors can't or won't answer these questions clearly, which should raise immediate red flags about using their AI features with sensitive practice data.

The Technical Reality: Why Models Are Relatively Safe

The mathematical nature of LLMs creates inherent limitations on data extraction. Models don't store your conversations—they process input and generate output without retention. Training data is generally not retrievable; while models learn from massive datasets and may occasionally reproduce memorized content under specific conditions, you can't systematically extract training examples. There's no persistent memory unless the implementation adds memory features, and while processing typically involves randomness in generation, your data influences output without being stored within the model weights.

This means the model itself poses minimal data security risk. The risk lies in how implementations handle your input and output data.

Key Insights for Veterinary Practice

🔍 Focus your security assessment on implementations, not models. Evaluate where data goes, how it's stored, and who has access rather than worrying about which AI engine processes your text.

📋 Develop clear implementation policies for your practice. Create guidelines for which types of AI services are appropriate for different types of practice data, understanding that administrative tasks may not need the same security level as client medical records.

🌐 Understand the hosting and compliance implications. Know whether your data stays local, goes to U.S. servers, or travels internationally. Read implementation terms of service carefully, as these policies matter more than model capabilities for data security.

🏥 Consider enterprise solutions for sensitive veterinary data. Business-grade implementations often provide the security controls and compliance features necessary for healthcare applications.

🔬 Separate experimentation from production use. Use consumer applications for learning and testing AI capabilities, but rely on enterprise solutions for actual practice workflows involving sensitive information.

Looking Forward

As AI becomes more prevalent in veterinary medicine, this model-versus-implementation distinction will become increasingly important. New models will continue emerging from various countries and companies, but your security and compliance decisions should focus on the implementation characteristics that actually affect your data.

The recent DeepSeek security discussions highlight exactly why this framework matters. Rather than avoiding all AI tools or making decisions based on model origins, you can make informed choices by understanding where your real risks and opportunities lie.

The goal isn't to avoid all AI tools—it's to use them intelligently. Whether you're considering AI for client communications, diagnostic assistance, or practice management, remember: the model processes your data, but the implementation controls it. Choose accordingly.

Questions about specific AI implementations for your practice? The security landscape is evolving rapidly, and I'd be happy to explore specific tools and their implementation characteristics in future posts.

Several astute readers reached out after my recent post about diagnostic metrics to raise an important point I had simplified for clarity: the stability of sensitivity and specificity across populations. I appreciate these thoughtful responses—they highlight exactly the kind of nuanced thinking we need when evaluating diagnostic tools. Let me address this more completely.

The Pedagogical Simplification

In my original post, I stated that sensitivity and specificity are "inherent properties of the test" that remain constant across populations. This was indeed a simplification made for pedagogical purposes. The complete picture is more nuanced.

Spectrum Bias: When Test Performance Varies

Sensitivity and specificity can vary based on what epidemiologists call "spectrum bias" or "spectrum effects." This well-documented phenomenon occurs when test performance changes across different disease severities, clinical presentations, patient populations, and even prevalence itself through complex mechanisms including threshold adjustments and verification bias.

Veterinary Examples

An AI tool for detecting cardiomegaly on radiographs might show 95% sensitivity in dogs with severe DCM and marked enlargement, but only 75% sensitivity in dogs with early DCM and mild changes. Specificity can vary too, depending on whether the comparison group includes dogs with non-cardiac causes of apparent enlargement like obesity, respiratory disease, or positioning artifacts.

Similarly, a test for canine hypothyroidism might perform differently in young dogs with congenital disease (classic presentation) versus geriatric dogs with concurrent illness (confounding factors), or across different breeds with varying baseline thyroid hormone levels.

Why My Original Argument Remains Sound

Despite this oversimplification, the core message about PPV's unreliability stands even stronger when we consider spectrum bias.

The Scale of Variation Differs Dramatically

Spectrum effects typically cause sensitivity and specificity to vary by 10-30%, while PPV can swing by 700-800% with prevalence changes alone. The magnitude difference is what matters for clinical decision-making.

Predictability and Clinical Intuition

Spectrum effects follow understandable patterns—tests work better on obvious disease—and experienced clinicians intuitively adjust for these patterns. In contrast, PPV variations with prevalence often run counter to clinical intuition. A test that seems "highly predictive" in one setting can be nearly useless in another, which catches many practitioners off guard.

Likelihood Ratios: More Stable, Not Perfect

While likelihood ratios can also vary with spectrum effects, they show much smaller variations than PPV and change in predictable ways that align with clinical thinking. They remain more useful for clinical decision-making across settings and can be stratified by disease severity when needed, as I demonstrated with AI scoring ranges in the original post.

The Framework Still Works

Even accounting for spectrum bias, the diagnostic approach I outlined—estimating pre-test probability based on your specific patient, applying likelihood ratios (adjusted for severity if available), and calculating post-test probability—remains the most robust framework for diagnostic decision-making.

Implications for AI Validation in Veterinary Medicine

This nuance actually reinforces several key points about AI validation.

What We Need from AI Companies

Transparent reporting of validation populations is essential, including disease severity distribution, clinical settings (emergency, specialty, general practice), and the species, breeds, and age ranges included. We need stratified performance metrics showing how the tool performs across different stages of disease, various clinical presentations, and multiple practice types. Companies should provide confidence intervals, not just point estimates, and implement real-world performance monitoring to detect spectrum effects in practice.

Red Flags in AI Validation

Be wary of studies using only textbook cases or severe disease, validation in single institutions or practice types, mixing screening and diagnostic populations without stratification, or reporting single sensitivity/specificity values without context. These are signs of inadequate validation that doesn't account for real-world performance variation.

The Clinical Bottom Line

Understanding spectrum bias strengthens rather than weakens the case for careful diagnostic test interpretation:

1. No diagnostic test has truly fixed performance—all vary based on population and disease characteristics

2. PPV remains the least stable metric, varying both with prevalence AND spectrum effects

3. Likelihood ratios provide more stable guidance, though they too can vary

4. Clinical context matters more than any single metric

5. Validation transparency is essential for understanding when and how to use AI tools

A More Sophisticated Framework

Rather than viewing test characteristics as either "fixed" or "variable," we should think in terms of relative stability. Some metrics like likelihood ratios are more stable than others like PPV. Performance changes follow predictable patterns that we can understand and account for. The best metrics align with clinical reasoning, and all metrics require consideration of the specific clinical scenario.

Closing Thoughts

I simplified the concept of "fixed" sensitivity and specificity to make a pedagogical point about PPV's extreme variability. But as this discussion shows, the reality provides even more reason to demand comprehensive validation data from AI companies, reject simplistic accuracy claims, embrace likelihood ratios as more stable (though not perfect) metrics, and always integrate test results with clinical judgment.

Thank you to the readers who prompted this clarification. In the complex world of diagnostic testing, these nuanced discussions help us all develop more sophisticated frameworks for evaluating and using emerging technologies. The goal isn't perfect metrics—it's better clinical decisions.

Subscribe now

For those interested in diving deeper into spectrum bias, I recommend:

• Ransohoff DF, Feinstein AR. "Problems of spectrum and bias in evaluating the efficacy of diagnostic tests." NEJM 1978

• Mulherin SA, Miller WC. "Spectrum bias or spectrum effect? Subgroup variation in diagnostic test evaluation." Ann Intern Med 2002

• Willis BH, Hyde CJ. "What is the test's accuracy in my practice population? Tailored meta-analysis provides a plausible estimate." J Clin Epidemiol 2015

As artificial intelligence and machine learning models increasingly enter veterinary practice, clinicians face a familiar challenge in a new form: how do we interpret these tools' performance metrics in ways that actually help our patients?

In previous posts, we've explored the transparency crisis in veterinary AI validation and established frameworks for evaluating different types of AI systems. We saw how clinical prediction models, language generation tools, and imaging AI each require distinct evaluation approaches. Today, we're focusing specifically on clinical prediction models—those AI systems that provide diagnostic classifications or disease probability scores—because they raise unique challenges in translating validation metrics to clinical utility.

While sensitivity and specificity provide valuable insights into test performance, there's one metric that's actively misleading in clinical practice: positive predictive value (PPV).

After nearly three decades working with veterinary diagnostics data, I've seen how the same AI diagnostic tool can be transformative in one practice and nearly useless in another. An AI model that correctly identifies 95% of lymphoma cases in a specialty oncology center might flag so many false positives in general practice that it becomes more hindrance than help. This isn't a failure of the technology—it's the predictable result of how disease prevalence affects positive predictive value (PPV), and why this commonly cited metric is so misleading for clinical decision-making.

The key lies in understanding how prevalence shapes predictive values and why likelihood ratios offer a more stable, practical framework that works alongside sensitivity and specificity for clinical decisions.

This builds on our earlier discussion about the decision-action framework—remember, every AI system exists to influence human decisions. Today, we're diving deep into the mathematical tools that help us make those decisions wisely when using clinical prediction models.

Subscribe now

Listen to an AI generated podcast generated from this post

The Sensitivity and Specificity Foundation

Let's start with what works well. Sensitivity and specificity are fundamental performance characteristics that tell us important things about any diagnostic test:

Sensitivity: The proportion of truly diseased animals that test positive (true positive rate)

• Answers: "How good is this test at detecting disease when it's present?"

• High sensitivity = fewer false negatives = fewer missed cases

Specificity: The proportion of truly healthy animals that test negative (true negative rate)

• Answers: "How good is this test at ruling out disease when it's absent?"

• High specificity = fewer false positives = fewer unnecessary treatments

These metrics are inherent properties of the test itself. A test that's 90% sensitive and 85% specific will maintain those characteristics whether it's used in a specialty referral hospital or a rural mixed practice. They provide crucial information for understanding what a test can and cannot do.

For example, when evaluating an AI tool for radiographic screening:

• High sensitivity tells you it won't miss many cases (good for screening)

• High specificity tells you it won't generate excessive false alarms (good for confirmatory testing)

• The combination helps you understand the test's fundamental performance envelope

The Fatal Flaw: Why PPV is a Misleading Metric

Here's where things go wrong. Positive predictive value seems like it should be the most clinically relevant metric:

PPV: The proportion of positive tests that are truly positive

• Seems to answer: "When this test is positive, what's the probability my patient actually has the disease?"

The problem? PPV isn't a property of the test—it's a property of the test applied to a specific population. And in veterinary medicine, populations vary dramatically.

The Prevalence Trap: Same Test, Wildly Different Results

Consider an AI model for detecting canine dilated cardiomyopathy (DCM) with excellent performance characteristics:

• Sensitivity: 90%

• Specificity: 85%

Now watch what happens to PPV in different clinical contexts:

At a cardiology referral center (DCM prevalence ~40%):

• PPV: 75%

• "When positive, 75% chance of actual DCM"

In general practice (DCM prevalence ~2%):

• PPV: 11%

• "When positive, only 11% chance of actual DCM"

At a breed-specific screening clinic for Dobermans (DCM prevalence ~60%):

• PPV: 87%

• "When positive, 87% chance of actual DCM"

Same AI model, same sensitivity, same specificity—but PPV varies from 11% to 87%. This makes PPV essentially meaningless as a reported metric because it only applies to the specific population where it was measured.

The Prevalence Complexity: Why "Population" Isn't Simple

When you're evaluating a patient, what exactly is "the prevalence"? It's not a single number—it's a complex intersection of factors that create increasingly specific sub-populations:

Geographic and Practice Factors

• Urban vs. rural (vector-borne disease exposure)

• Climate zone (heartworm, fungal diseases)

• Practice type (first opinion vs. referral vs. emergency)

Patient Demographics

• Age (juvenile vs. geriatric disease patterns)

• Breed (Cavaliers with 50%+ mitral valve disease vs. mixed breeds)

• Body condition, sex, neuter status

Clinical Presentation

• Chief complaint (coughing dog vs. wellness exam)

• Duration and progression of signs

• Previous medical history

The Diagnostic Cascade Effect Once you've run initial diagnostics, your patient moves into increasingly specific populations. Consider a 10-year-old Labrador with polyuria/polydipsia:

• Initial population: "10-year-old Labrador" (Cushing's prevalence ~5-10%)

• After finding elevated ALP: "10-year-old Labrador with PU/PD and elevated ALP" (Cushing's prevalence ~30-40%)

• After finding poor dexamethasone suppression: "10-year-old Labrador with PU/PD, elevated ALP, and poor dex suppression" (Cushing's prevalence ~70-80%)

Each test result creates a new, more specific population with its own prevalence. Any PPV reported in validation studies becomes irrelevant because your patient is now in a completely different population than the one where PPV was measured.

Why This Makes Reported PPV Dangerous

When an AI company reports "85% PPV," what exactly does that mean for your patient? Without knowing:

• The exact validation population characteristics

• All the selection factors used

• The clinical context of tested animals

• Prior test results in those animals

...that number is not just meaningless—it's actively misleading. It creates false confidence or false dismissal based on irrelevant data.

This is why experienced clinicians often ignore reported PPVs entirely and rely on their clinical judgment to estimate disease probability. That clinical intuition accounts for all the prevalence factors that make reported PPV unreliable.

Enter the Likelihood Ratio: The Stable Alternative

Likelihood ratios (LRs) solve this problem by providing prevalence-independent measures of how much a test result changes disease probability:

Positive Likelihood Ratio (LR+): How much more likely is a positive test in a diseased animal versus a healthy one?

• LR+ = Sensitivity / (1 - Specificity)

Negative Likelihood Ratio (LR-): How much more likely is a negative test in a healthy animal versus a diseased one?

• LR- = (1 - Sensitivity) / Specificity

For our DCM example:

• LR+ = 0.90 / (1 - 0.85) = 6.0

• LR- = (1 - 0.90) / 0.85 = 0.12

These values remain constant regardless of where you practice or what type of cases you see. They're true properties of the test, just like sensitivity and specificity.

The Clinical Framework: From Test Result to Decision

Here's how likelihood ratios work in practice:

1. Start with your pre-test probability (clinical suspicion based on signalment, history, exam)

2. Apply the likelihood ratio from your test result

3. Calculate post-test probability to guide decisions

Practical LR interpretation:

For positive results (LR+):

• LR+ > 10: Strong evidence for disease

• LR+ 5-10: Moderate evidence for disease

• LR+ 2-5: Weak evidence for disease

• LR+ 1-2: Minimal evidence

For negative results (LR-):

• LR- < 0.1: Strong evidence against disease

• LR- 0.1-0.2: Moderate evidence against disease

• LR- 0.2-0.5: Weak evidence against disease

• LR- 0.5-1: Minimal evidence

Why This Framework Complements Sensitivity and Specificity

Rather than replacing sensitivity and specificity, likelihood ratios work with them to provide a complete picture:

Sensitivity and specificity tell you about fundamental test performance:

• Can this test detect disease when present?

• Can this test rule out disease when absent?

• What are the inherent limitations?

Likelihood ratios tell you about clinical utility:

• How much does a positive result increase disease probability?

• How much does a negative result decrease disease probability?

• How useful is this test for decision-making?

Together, they provide both the foundation for understanding test performance and the tools for applying that performance in clinical decisions.

Real-World Application: Multi-Level AI Scoring

Modern AI tools often provide probability scores rather than binary results. Likelihood ratios can be stratified by score ranges:

Example: AI-based radiographic screening for hip dysplasia

• Score >0.8: LR+ = 15 (strong evidence for dysplasia)

• Score 0.6-0.8: LR+ = 4 (moderate evidence)

• Score 0.4-0.6: LR ≈ 1 (uninformative)

• Score 0.2-0.4: LR- = 0.3 (moderate evidence against)

• Score <0.2: LR- = 0.05 (strong evidence against)

This stratification allows nuanced clinical decisions while avoiding the prevalence trap that makes PPV unreliable.

Case Example: Putting It All Together

A 7-year-old Golden Retriever presents with decreased appetite and mild lethargy. You're considering several differentials, including lymphoma.

Step 1: Estimate your pre-test probability Based on signalment and vague clinical signs:

• Your clinical suspicion for lymphoma: ~10% (or 1 in 10 chance)

Step 2: Run an AI-assisted diagnostic test You use an AI tool that analyzes peripheral blood smears for atypical lymphocytes:

• The tool has LR+ = 8.0 and LR- = 0.15

• Your patient's result: Positive (atypical cells detected)

Step 3: Calculate post-test probability Using the positive result and LR+ = 8.0:

• Pre-test odds = 0.10 / (1 - 0.10) = 0.11

• Post-test odds = 0.11 × 8.0 = 0.88

• Post-test probability = 0.88 / (1 + 0.88) = 47%

Clinical interpretation: The positive test moved your suspicion from 10% to 47%. This moderate probability warrants further investigation—perhaps lymph node aspirates or advanced imaging—but isn't definitive enough for immediate chemotherapy.

Alternative scenario: If the test had been negative Using LR- = 0.15:

• Post-test odds = 0.11 × 0.15 = 0.017

• Post-test probability = 0.017 / (1 + 0.017) = 1.7%

The negative result would have reduced your suspicion from 10% to 1.7%, likely redirecting your diagnostic efforts toward other differentials.

The key insight: The same test provides different levels of certainty depending on your starting point. If you had started with 50% suspicion (perhaps after finding enlarged lymph nodes), that same positive test would have moved you to 89% certainty—potentially high enough to discuss treatment options with the owner.

Key Insights for Veterinary Practice

🚫 Reject PPV as a decision-making metric: It's only valid in populations identical to the validation study, which virtually never matches your specific clinical context.

📊 Request likelihood ratios from diagnostic companies: They provide stable, clinically useful information that works across different practice settings and patient populations.

🔍 Use sensitivity and specificity to understand test capabilities: They tell you what the test can and cannot do in fundamental terms.

⚖️ Apply likelihood ratios for clinical decisions: They tell you how much test results should change your thinking about specific patients.

📈 Understand your local prevalence patterns: Knowing disease prevalence in your practice helps calibrate all diagnostic interpretations.

🎯 Think in probability shifts: Every test moves you from one probability to another—likelihood ratios quantify that movement.

🔄 Remember the diagnostic cascade: Each result refines which population your patient belongs to, changing the context for subsequent tests.

Conclusion

As AI and machine learning tools proliferate in veterinary medicine, the challenge isn't learning entirely new ways to interpret diagnostics—it's applying the same probabilistic reasoning that underlies all medical decision-making, but with better tools.

Sensitivity and specificity remain valuable for understanding what a test can do. Likelihood ratios provide the missing piece: understanding how much test results should influence your clinical decisions. Together, they create a robust framework for evaluating any diagnostic tool.

The metric to abandon is PPV. It's not that PPV is theoretically wrong—it's that reported PPV values are clinically useless because they apply only to the specific population where they were measured. In the diverse world of veterinary medicine, that population almost certainly doesn't match your patient.

The diagnostic process veterinarians follow every day is already sophisticated probabilistic reasoning. By making these concepts more explicit and providing tools like likelihood ratios that align with clinical thinking, we can help ensure that new diagnostic technologies enhance rather than complicate clinical decision-making.

Whether evaluating an AI algorithm for radiographic interpretation or an ALT elevation on a chemistry panel, the fundamental question remains the same: how does this result change what I know about my patient? Likelihood ratios, working alongside sensitivity and specificity, provide the most reliable framework for answering that question.

This is precisely why my evaluation framework emphasized understanding how AI changes clinical decisions rather than just reporting accuracy metrics. When vendors provide likelihood ratios instead of PPV, they're giving you tools that actually work in your practice, not just in their validation studies.

Technical Appendix: The Math Behind the Magic

For those interested in the calculations:

Converting to post-test probability:

1. Pre-test odds = Pre-test probability / (1 - Pre-test probability)

2. Post-test odds = Pre-test odds × Likelihood ratio

3. Post-test probability = Post-test odds / (1 + Post-test odds)

Why PPV fails mathematically:

Notice that prevalence appears twice in this equation. Change prevalence, and PPV changes dramatically, even with identical sensitivity and specificity.

Why likelihood ratios remain stable:

No prevalence term appears in either equation. The values remain constant regardless of the population being tested.

As large language models (LLMs) like ChatGPT, Claude, and Bard become increasingly integrated into veterinary workflows—from client communication to clinical decision support—one concern dominates conversations: hallucinations. These AI systems sometimes generate confident-sounding but factually incorrect information, and the veterinary community is rightfully cautious.

But here's what might surprise you: LLM hallucinations aren't a bug to be fixed—they're an inevitable feature of how these systems fundamentally work. Understanding why can help us use these tools more effectively and set appropriate expectations for their role in veterinary practice.

Subscribe now

The Closed-Book Exam Analogy

Imagine asking a veterinary student to take a comprehensive exam under these conditions:

• No textbooks, notes, or reference materials allowed

• No internet access

• No ability to look up drug dosages, normal lab values, or disease prevalence data

• Must answer every question with confidence, even on topics they've never studied

When that student occasionally gets facts wrong or fills in gaps with plausible-sounding but incorrect information, would you be surprised? Of course not. Yet this is essentially how most LLMs operate.

LLMs are trained on massive datasets and then deployed as "closed-book" systems. They can't:

• Access real-time information

• Look up current drug databases

• Verify facts against authoritative sources

• Check their work against reference materials

• Update their knowledge after training

They're working entirely from "memory"—patterns learned during training—without the ability to fact-check or research their responses.

The Human Citation Challenge

Consider this question: "What is the capital of France?"

You probably answered "Paris" instantly. But can you cite your source? Can you remember exactly where and when you learned this fact? Likely not—it's become integrated knowledge.

This is how humans typically store and retrieve basic information. We rarely walk around with mental footnotes for fundamental facts. We've synthesized information from multiple sources over time into confident knowledge, even though we can't always trace the provenance.

LLMs exhibit a similar pattern. They've "learned" that certain relationships exist (breed predispositions, drug interactions, anatomical facts) from training data, but they can't point back to specific sources any more than you can cite where you first learned that dogs have four legs.

The Difference: Humans Can Look Things Up

The crucial difference is that when accuracy matters, humans can:

• Consult reference materials

• Verify facts against authoritative sources

• Cross-check information

• Acknowledge uncertainty ("Let me look that up")

Most deployed LLMs can't do this—they're operating from trained patterns without external verification mechanisms.

The Mathematical Reality of Language Generation

Here's the fundamental technical reason why hallucinations are inevitable:

LLMs work by predicting the most statistically likely next word (or token) based on the preceding context. At each step, they're making probability calculations:

Given the words "The normal heart rate for a healthy adult dog is approximately..." what word should come next?

The model might assign probabilities like:

• "60" (15% probability)

• "70" (25% probability)

• "80" (30% probability)

• "90" (20% probability)

• "100" (10% probability)

The system then samples from this probability distribution. Sometimes it will choose the most likely option, sometimes a less likely one. This sampling process introduces inherent randomness.

Why This Matters for Veterinary Applications

Even if the LLM has learned correct patterns from training data, the probabilistic nature of generation means:

1. Correct information can be slightly corrupted during generation

2. Multiple plausible options might exist, and the model might choose incorrectly

3. Novel combinations of familiar concepts might create plausible-sounding but wrong information

For example, if an LLM has learned:

• "Acepromazine is used for sedation"

• "Typical doses are weight-based"

• "Canine sedation protocols vary by procedure"

It might generate: "Acepromazine is typically dosed at 0.1-0.3 mg/kg for routine procedures"—which sounds authoritative but might not reflect current best practices or might conflate different protocols.

The Veterinary-Specific Risks

This inherent uncertainty creates particular challenges in veterinary medicine:

Clinical Decision-Making: Wrong drug dosages, contraindications, or diagnostic interpretations can directly harm patients.

Client Communication: Confident-sounding but incorrect information about prognosis, treatment options, or costs can damage trust and lead to poor decisions.

Regulatory Compliance: Incorrect information about drug withdrawal times, prescription requirements, or documentation standards creates legal risks.

Species-Specific Variations: LLMs might conflate information between species ("This works in dogs, so it probably works in cats") in ways that veterinarians would never do.

Implications for Veterinary AI Applications

Understanding why hallucinations occur helps us develop better strategies for using LLMs in practice:

What LLMs Do Well

• Pattern recognition in complex data

• Synthesis of information from multiple sources

• Communication and explanation of concepts

• Workflow automation for routine tasks

What Requires Extreme Caution

• Specific medical recommendations without verification

• Drug dosages and administration protocols

• Diagnostic interpretations requiring current knowledge

• Species-specific treatment advice

The Verification Imperative

Because hallucinations are inevitable, any LLM-generated medical information must be verified against authoritative sources. This isn't a limitation to overcome—it's a fundamental requirement for safe use.

Think of LLMs as extremely knowledgeable but occasionally unreliable research assistants. They can:

• Help you brainstorm differential diagnoses

• Draft client communications for you to review and edit

• Suggest areas to investigate further

• Explain complex concepts in accessible language

But they cannot:

• Replace your clinical judgment

• Provide definitive medical recommendations

• Be trusted for critical dosing or safety information

• Substitute for current reference materials

Current Solutions: Hybrid Approaches in Practice

The solution isn't to avoid LLMs—it's to integrate them thoughtfully with verification systems. These approaches are being deployed today:

Retrieval-Augmented Generation (RAG): LLMs connected to current databases that can look up facts rather than relying solely on training memory. In my experience implementing these systems, they significantly reduce hallucinations while maintaining the conversational capabilities that make LLMs valuable.

Multi-Step Verification: Systems that check LLM outputs against authoritative databases before presenting information. In my experience building these verification pipelines, they're essential for any application where accuracy is critical.

Confidence Scoring: Models that indicate their uncertainty level about specific statements, allowing users to understand when additional verification is most critical.

Citation Integration: Systems that can point to specific sources for factual claims are already being implemented in enterprise applications.

These approaches acknowledge that hallucinations are inherent to the technology while providing practical solutions that organizations are using today to mitigate risks.

Proven Veterinary Implementation

The theoretical solutions I've described aren't just academic concepts—they're already working in veterinary practice. During my involvement in developing LifeLearn's Sofie AI, we implemented exactly this type of advanced RAG system, grounding LLM responses in tens of thousands of pages of licensed veterinary medical content. The result demonstrates how proper implementation can dramatically reduce hallucinations while maintaining the conversational capabilities that make LLMs valuable for clinical decision support.

This real-world example shows that the hybrid approaches needed for safe veterinary AI aren't just possible—they're available today when built with appropriate veterinary expertise and content infrastructure.

Key Insights for Veterinary Practice

🧠 Understand the fundamental limitation: LLMs are "closed-book" systems working from trained patterns, not live databases. Occasional errors are mathematically inevitable.

✅ Always verify medical information: Any drug dosages, treatment protocols, or diagnostic recommendations from LLMs must be checked against current veterinary references.

🎯 Use LLMs for their strengths: Pattern recognition, communication drafting, concept explanation, and workflow automation—not for definitive medical advice.

📚 Maintain your reference standards: LLMs supplement but never replace current veterinary literature, drug formularies, and clinical guidelines.

🚨 Recognize high-risk scenarios: Be especially cautious with species-specific information, new drugs or procedures, and any recommendations that seem "surprising" or novel.

👥 Educate your team: Ensure all staff understand that LLM outputs require verification, especially for any client-facing communications about medical topics.

🔄 Treat LLMs as research assistants: Valuable for generating ideas and drafts, but everything needs professional review before implementation.

📊 Stay updated on AI developments: As retrieval-augmented and citation-capable systems emerge, the landscape will evolve—but verification will always be necessary.

Conclusion

LLM hallucinations aren't a temporary glitch to be solved—they're an intrinsic characteristic of how these systems work. Understanding this helps us use them appropriately: as powerful tools for pattern recognition, communication assistance, and workflow support, but never as authoritative sources for medical information.

The goal isn't to eliminate hallucinations (which is mathematically impossible) but to build workflows that harness LLM capabilities while maintaining the rigorous verification standards that veterinary medicine demands.

Just as we've learned to use diagnostic tests by understanding their sensitivity, specificity, and limitations, we can effectively integrate LLMs by understanding their probabilistic nature and inherent uncertainty. The key is treating them as sophisticated assistants rather than infallible oracles.

In veterinary practice, where patient safety and client trust are paramount, this understanding isn't just academic—it's essential for responsible AI adoption.

Still experimenting with this AI generated podcast summary of this article. Try it out:

What's your experience with AI hallucinations in practice? Have you encountered confident-sounding but incorrect information from AI tools? I'd love to hear about both the challenges you've faced and any solutions you've found effective.

Reply to this post or reach out directly - your real-world experiences help shape the practical insights that make these analyses valuable for the veterinary community.

In my previous post, I outlined the veterinary AI transparency crisis—how most companies make bold performance claims without providing the validation data to support them. Demanding evidence is step one, but what should that validation actually look like?

The challenge isn't just getting validation data—it's understanding what kind of validation is appropriate for different AI systems. A diagnostic imaging AI requires entirely different evaluation approaches than an automated appointment scheduling system or a transcription tool. Yet most discussions about "AI accuracy" treat all AI systems as if they're identical.

After nearly three decades in veterinary diagnostics, I've learned that we need to fundamentally categorize AI systems based on their role in veterinary practice before we can properly evaluate them.

Here's a practical framework for evaluating any AI tool entering your practice, tailored to how these systems actually work and how you'll actually use them.

Subscribe now

The Decision-Action Framework: Two Fundamentally Different AI Types

Before diving into evaluation frameworks, we need to distinguish between two fundamentally different types of AI systems.

Decision Support AI provides information to help humans make better decisions. Think diagnostic imaging analysis, risk prediction models, or differential diagnosis generators. The key question becomes: "How will this AI change my clinical decisions?" Evaluation must focus on clinical utility, decision impact, and integration with human judgment.

Automation AI performs tasks with minimal human oversight. Examples include automated transcription, appointment scheduling, inventory management, and routine data entry. Here the key question shifts to: "How reliably does this AI perform the intended task?" Evaluation focuses on task completion accuracy, efficiency gains, error rates, and workflow integration.

These categories require completely different evaluation approaches. Decision support AI must be evaluated based on how it influences clinical thinking, while automation AI must be evaluated based on task performance and reliability.

Why This Distinction Matters

The same "95% accuracy" claim means entirely different things for these two categories. For decision support AI, you need to know how that accuracy translates to better clinical decisions. For automation AI, you need to know how reliably it completes its designated tasks without human intervention.

Consider a hypothetical AI tool that detects heart murmurs with "90% accuracy." That number means completely different things depending on whether you're using it for wellness screening (deciding whether to pursue further cardiac workup), pre-anesthetic evaluation (assessing surgical risk), or emergency triage (prioritizing patient urgency). The evaluation framework must match the decision context where you'll actually use the tool.

Clinical Prediction Models: Decision Support AI Evaluation

For AI tools that help with diagnosis, prognosis, or treatment decisions, traditional accuracy metrics are insufficient and sometimes misleading.

The Prevalence Problem

Positive predictive value (PPV) changes dramatically with disease prevalence—a fundamental statistical reality that makes reported PPV nearly meaningless for clinical decision-making. An AI tool with "95% PPV" in a referral hospital might have 20% PPV in general practice—same tool, same accuracy, completely different clinical utility.

What to Demand Instead

Instead of relying on misleading PPV claims, focus on metrics that remain stable across populations. Sensitivity and specificity are inherent properties of the test itself and don't change based on where you practice. Likelihood ratios tell you how much a test result should change your clinical thinking, regardless of your patient population. Population validity ensures the validation study actually matches your practice setting. Clinical utility studies demonstrate that the AI changes decisions appropriately, not just that it produces accurate outputs. Finally, failure mode analysis reveals what happens when the system is wrong—critical information for managing clinical risk.

Given the critical importance of understanding how prevalence affects diagnostic interpretation and why likelihood ratios provide a more reliable framework for clinical decision-making, I'll be dedicating an entire upcoming post to this topic.

Validation Requirements

The validation study should match your intended use. If you're considering an AI tool for routine screening, the validation should include routine cases, not just referred patients with obvious disease. Ask vendors: "What was the disease prevalence in your validation population, and how does that compare to my practice?"

Language Generation Models: Bridging Decision Support and Automation

Language generation AI can function as either decision support or automation, depending on the application.

Decision Support Applications include generating differential diagnoses, explaining complex conditions to clients, or summarizing case information. These should be evaluated like other decision support tools, focusing on clinical accuracy, appropriateness, and impact on decisions.

Automation Applications encompass generating routine discharge instructions, appointment confirmations, or basic client communications. These should be evaluated like other automation tools, emphasizing task completion accuracy, consistency, and reliability.

What Actually Matters for Both Categories

Traditional natural language processing metrics like BLEU or ROUGE scores are essentially useless for veterinary applications. These metrics were designed for translation tasks and measure similarity to reference texts—but there are multiple correct ways to express the same clinical information.

Instead, focus on clinical accuracy (are the medical facts correct?), appropriateness (is the tone and content suitable for the intended audience?), safety (risk of harmful or misleading information), workflow integration (does it actually save time and improve quality?), and consistency (reproducible quality across different inputs).

Validation Requirements

Effective validation requires human expert evaluation protocols rather than automated metrics, fact-checking against veterinary literature, A/B testing in real practice settings, and long-term monitoring for drift and degradation.

Given the complexity and unique challenges of evaluating language models—especially the hallucination issues I discussed previously—I'll be dedicating an entire post to LLM evaluation frameworks in the coming weeks.

Imaging Models: Three Distinct Categories

Imaging AI falls into three distinct categories requiring different evaluation approaches.

Diagnostic imaging AI provides clinical predictions such as fracture detection or mass identification. These should be evaluated like clinical prediction models, focusing on sensitivity, specificity, and likelihood ratios. They require reader studies showing human-AI versus human-alone performance.

Image enhancement AI highlights regions of interest or improves image quality. Evaluation should focus on workflow integration and user acceptance, measuring time savings and diagnostic confidence while assessing consistency and reliability.

AI-Only imaging Systems provide fully automated diagnostic analysis without human radiologist review. These should be evaluated like clinical prediction models, using sensitivity, specificity, and likelihood ratios. They require extensive validation across diverse patient populations and image conditions, need clear protocols for when results should trigger human review, and must demonstrate performance equivalent to or better than human interpretation.

Key Questions

Critical considerations include whether the AI enhances or disrupts radiologist workflow, how combined human-AI performance compares to either approach alone, whether AI-only systems match human diagnostic accuracy, and what happens when the AI highlights irrelevant findings or misses critical ones.

Automation AI: Task Performance and Reliability

For AI systems designed to perform tasks with minimal human oversight—transcription, scheduling, data entry, routine communications—the evaluation framework shifts dramatically.

Key Evaluation Metrics

Focus on task completion accuracy (how often does the system successfully complete the intended task?), error detection (when the system fails, is it obvious to users?), reliability (consistent performance across different conditions and inputs), speed and efficiency (does it actually improve workflow?), and graceful failure handling (how does the system behave when it encounters unexpected situations?).

Examples by Category

Transcription Systems should be evaluated on Word Error Rate weighted for medical significance, medical terminology accuracy, handling of unclear audio or multiple speakers, and integration with existing documentation systems.

Practice Management Systems require assessment of scheduling accuracy and conflict resolution, inventory prediction accuracy, billing automation error rates, and client communication delivery and formatting.

Validation Requirements

Effective validation demands real-world testing in actual practice environments, long-term reliability monitoring, user acceptance and adoption rates, comparison to manual processes for speed and accuracy, and recovery protocols when automation fails.

The Universal Evaluation Framework: Five Critical Questions

Regardless of AI system type, always ask these five questions:

1. Decision Impact: How will this change what actions I take?

2. Context Validity: Was this validated in settings like mine?

3. Failure Modes: What happens when this system is wrong?

4. Monitoring: How will I know if performance degrades?

5. Integration: How does this fit into my existing workflow?

Red Flags for ALL AI Systems

• Validation only in ideal conditions

• No discussion of failure modes or edge cases

• Lack of ongoing performance monitoring plans

• Performance metrics that don't match intended use

• Refusal to provide validation methodology

For AI Companies: The Path Forward

If you're developing veterinary AI tools, rigorous validation isn't just ethical—it's a competitive advantage. In a crowded market where most companies provide no validation data, transparent evidence immediately sets you apart.

Validation Best Practices

• Multi-site validation: Test across different practice types and populations

• Report appropriate metrics: Likelihood ratios for clinical tools, workflow metrics for operational tools

• Document limitations: Be clear about when and where your tool should not be used

• Plan post-market surveillance: Performance can degrade over time

• Seek independent validation: Third-party studies carry more weight than internal testing

  

Key Insights for Veterinary Practice

🎯 Match evaluation to intended use: Screening tools need different validation than diagnostic confirmation tools—demand evaluation data that matches how you'll actually use the AI.

📊 Demand context-appropriate metrics: For clinical tools, insist on sensitivity, specificity, and likelihood ratios. For practice management tools, focus on workflow and business metrics.

🏥 Verify population validity: Ask whether the validation population matches your patient demographics, case mix, and practice setting.

⚠️ Understand failure modes: Every AI system fails sometimes—demand clear documentation of when and how failures occur.

🔍 Establish monitoring protocols: Set up systems to track AI performance in your practice over time—performance can degrade without obvious warning signs.

📋 Create evaluation checklists: Develop standardized evaluation processes for different AI tool categories to ensure consistent vendor assessment.

💼 Calculate true ROI: Factor validation quality into purchasing decisions—well-validated tools are more likely to deliver promised benefits.

🔄 Plan for integration: Consider how each AI tool fits into existing workflows and what training will be required for successful adoption.

📚 Document AI-assisted decisions: Establish protocols for documenting when and how AI tools influence clinical decisions for both medical records and quality improvement.

🚨 Start with pilot programs: When validation data is limited, implement AI tools on a trial basis with careful monitoring of real-world performance before full deployment.

Conclusion

The key insight driving this framework is understanding that different AI systems serve fundamentally different roles in veterinary practice. Decision-support AI exists to influence human judgment, while automation AI exists to perform tasks directly. These different roles require completely different evaluation approaches.

For decision-support AI, the critical question is "How will this change what I decide or do?" You need to understand how AI information fits into your clinical reasoning process and whether it improves decision-making quality.

For automation AI, the critical question is "Should this task be automated, and how will I monitor the automation?" You need to assess whether the task is appropriate for automation and establish proper oversight mechanisms.

Both types require rigorous validation, but the validation criteria, performance metrics, and monitoring approaches are fundamentally different. A diagnostic imaging AI needs sensitivity, specificity, and likelihood ratios. An automated scheduling system needs task completion rates, error handling protocols, and exception management procedures.

The common thread is understanding how each AI system fits into your existing workflows and whether it genuinely improves outcomes for your patients and practice. No AI tool—regardless of how sophisticated—should be deployed without clear evidence that it enhances rather than complicates veterinary care.

In upcoming posts, I'll be diving deep into two critical areas that deserve their own detailed analysis: likelihood ratios as the foundation for interpreting diagnostic AI (including practical frameworks for moving from pre-test to post-test probability), and comprehensive evaluation methodologies for language generation models.

After all, you already apply evidence-based thinking to every other aspect of veterinary practice. Why should AI be any different?

What AI tools are you currently evaluating for your practice? Reply and let me know what challenges you're facing with vendor validation claims—I'd love to hear about your experiences and may feature your questions in future deep-dive posts.

I’m trying something out here. Listen to a short AI generated podcast based on this post. If you listen, please let me know what you think about it. Does it add anything?

Here's an uncomfortable truth about veterinary AI: we're flying blind.

The veterinary AI market operates in a transparency vacuum. Companies routinely make bold performance claims—"95% accuracy!" "Clinically validated!"—while providing zero published evidence to support these assertions.

I've spent 29 years in veterinary diagnostics, 26 of them at IDEXX, and I can tell you this: the absence of published validation data in veterinary AI isn't an oversight—it's become the industry standard. And it's putting both practices and patients at risk.

This isn't about being anti-innovation. I am very much pro-innovation and pride myself on being on the leading edge. Many veterinary AI tools are genuinely useful and well-designed. But without transparent evaluation data, we have no way to distinguish legitimate breakthroughs from sophisticated marketing campaigns. Even worse, we're deploying AI systems in clinical settings without understanding their true capabilities, limitations, or appropriate use cases.

The solution isn't to avoid AI—it's to demand the same evidence-based standards that guide every other aspect of veterinary medicine.

The Veterinary AI Transparency Crisis

Let me illustrate the problem with a thought experiment. Imagine if pharmaceutical companies operated the same way as current AI vendors:

"Our new antibiotic is 95% effective! Veterinarians love it! FDA approval pending, but don't worry—we've done internal testing. Sorry, we can't share the study details due to proprietary concerns. Trust us, it works great!"

You'd never accept this for a new drug. Yet this is exactly how most veterinary AI tools enter the market.

The Evidence Desert

Recent comprehensive analysis of the veterinary AI validation landscape reveals a stark transparency crisis. While some companies have conducted validation studies, the vast majority provide no public information about their evaluation methods—whether in peer-reviewed publications, white papers, conference presentations, or any other format.

The Rare Exceptions: A handful of companies do provide validation transparency. SignalPET has published methodology and performance data for processing 50,000 radiographs weekly across 2,300 clinics, achieving 94.4% specificity versus 88.3% for human radiologists. Zoetis openly shares validation approaches for their Vetscan Imagyst platform, reporting performance comparisons with expert pathologists. ImpriMed provides clinical outcome data showing 3x longer survival and 4x higher drug response rates for dogs with relapsed B-cell lymphoma. Mars Petcare's RenalTech shares validation methodology for predicting chronic kidney disease up to two years early.

The Overwhelming Majority: Most veterinary AI tools provide zero public validation information:

• No description of how they evaluated their systems

• No performance metrics beyond marketing claims

• No information about study design, datasets, or methodology

• No discussion of limitations or failure modes

• No post-market performance monitoring data

When Marketing Claims Replace Evidence

Without published validation data, veterinary AI marketing has become a creative writing exercise. Companies routinely make assertions without evidence:

"95% accuracy" (compared to what? measured how? on which cases?)
"Clinically validated" (by whom? using what criteria? where is the data?)
"Trusted by veterinarians" (how many? for how long? with what outcomes?)

The American College of Veterinary Radiology and European College of Veterinary Diagnostic Imaging's 2024 position statement declared "no commercially available AI products for veterinary diagnostic imaging meet the required standards for transparency, validation, or safety." This professional assessment highlights that even when companies have conducted internal validation, they're not sharing enough information for practitioners to assess the quality or applicability of that validation.

Unlike other veterinary technologies where companies routinely share technical specifications and performance data, AI tools are marketed primarily on promise rather than evidence. Practitioners are expected to make purchasing and implementation decisions based on demonstrations, testimonials, and marketing claims rather than transparent validation data.

Why Evidence-Based AI Evaluation Is Critical

The current approach isn't just bad for veterinarians—it's ultimately bad for the AI companies themselves and dangerous for patients.

The Professional Standard We're Abandoning

Evidence-based medicine is the cornerstone of veterinary practice. When we accept AI tools without validation data, we're abandoning the same standards we apply to every other clinical decision.

We demand evidence for:

• New pharmaceuticals before prescribing

• Diagnostic tests before interpreting results

• Surgical techniques before implementation

• Nutritional recommendations before counseling clients

We should demand evidence for AI tools before:

• Incorporating them into diagnostic workflows

• Basing clinical decisions on their outputs

• Billing clients for AI-assisted services

• Training staff to rely on their recommendations

The Patient Safety Imperative

Unvalidated AI tools pose real risks to patient care:

Diagnostic Errors: AI systems might miss subtle findings or generate false positives that lead to inappropriate treatment.

False Confidence: Practitioners might over-rely on AI recommendations without appropriate clinical skepticism.

Workflow Disruption: Poorly performing AI can slow down rather than accelerate clinical processes.

Resource Misallocation: Investing in ineffective AI tools diverts resources from proven diagnostic approaches.

The Economic Reality

AI tools represent significant practice investments—often requiring substantial upfront licensing fees, ongoing subscription costs, staff training time, workflow modification, and technical support. Without validation data, practices are making these investments blind. This isn't just poor financial stewardship—it's incompatible with responsible practice management.

The Expanding Transparency Gap

The validation crisis extends beyond traditional diagnostic AI to rapidly proliferating practice management tools powered by large language models. Veterinary practices are increasingly adopting AI systems for documentation, client communication, and administrative tasks—all without published evaluation data.

These tools may not directly impact patient diagnosis, but they affect medical records, client communications, and practice workflows. Without validation studies, practices don't know the accuracy rates, error patterns, or appropriate use cases for these systems. We're implementing tools that handle sensitive medical information and client interactions based entirely on vendor promises.

Whether we're discussing diagnostic AI or practice management tools, the fundamental principle remains the same: veterinary practices deserve evidence-based information about the tools they're implementing.

Why Transparency Benefits Everyone

Companies that publish rigorous validation studies gain significant competitive advantages:

Market Differentiation: In a sea of unsubstantiated claims, published evidence makes products stand out immediately.

Professional Credibility: Evidence-based practitioners adopt validated tools more quickly than unproven alternatives.

Premium Pricing: Practitioners will pay more for tools with demonstrated effectiveness versus those with only marketing claims.

Industry Standards: Transparency leaders set the standards that competitors must eventually match.

The responsibility isn't solely on companies—customers must actively demand validation data. When practitioners consistently ask "Where can I read the validation study?" vendors will respond with evidence rather than marketing materials.

Addressing the Challenges of Veterinary AI Validation

Acknowledging the need for transparency doesn't ignore the real challenges of veterinary AI validation. These tools face unique obstacles that human medical AI often doesn't encounter:

Multi-Species Performance: AI tools must work across dogs, cats, and exotic species with different anatomy and disease patterns.

Data Scarcity: Smaller patient populations and fragmented practice data make large-scale studies challenging.

Economic Constraints: The veterinary market may not support the same validation investment levels as human medicine.

Ground Truth Complexity: Veterinary diagnosis often lacks the definitive outcomes data that human medical AI can access.

These challenges are real but not insurmountable. They explain why veterinary AI validation is difficult—they don't excuse the absence of any validation data. Companies serious about veterinary medicine find ways to conduct rigorous studies within these constraints, as demonstrated by the transparent leaders in the field.

What's Coming Next

Understanding that we need validation data is only the first step. In upcoming posts, I'll dive deep into how AI tools should be evaluated—the methodologies, metrics, and study designs that separate rigorous validation from sophisticated marketing. Whether companies are reporting sensitivity and specificity for diagnostic tools or accuracy rates for documentation systems, you'll know what questions to ask and what standards to expect. The goal is to arm you with the knowledge to evaluate AI validation studies just as critically as you would evaluate any other clinical research.

Key Insights for Veterinary Practice

🚫 Reject unsubstantiated marketing claims: No matter how impressive the promises, don't deploy AI tools without published validation evidence from independent sources.

📊 Demand transparency from vendors: Before purchasing AI tools, require detailed validation data including methodology, performance metrics, limitations, and failure modes.

🔍 Look for independent evidence: Studies performed by independent groups provide more reliable information than company white papers or marketing materials.

⚖️ Understand validation limitations: Even published studies may have limitations—assess whether study populations and settings match your practice reality.

🎯 Start with pilot programs: When validation data is limited, implement AI tools on a trial basis with careful monitoring of real-world performance.

🔄 Monitor ongoing performance: Track AI tool performance in your practice to detect degradation or inappropriate use patterns.

👥 Share experiences professionally: Contribute to the professional knowledge base by sharing both positive and negative experiences with AI tools.

📚 Support industry standards: Advocate for professional organizations to establish validation requirements and accreditation programs.

💼 Calculate true ROI: Factor validation quality into purchasing decisions—well-validated tools are more likely to deliver promised benefits.

🔬 Ask the critical question: When vendors demo their AI tools, ask: "Where can I read the validation study?" Their response will tell you everything you need to know.

Conclusion

The veterinary AI transparency crisis isn't sustainable. As these tools become integral to practice workflows, the absence of validation data becomes increasingly dangerous for patients, practitioners, and the profession.

But this crisis also represents an opportunity. Companies that embrace transparency and rigorous validation will gain competitive advantages in an increasingly crowded market. Practitioners who demand evidence will make better purchasing decisions and achieve better patient outcomes.

The path forward requires collaboration between companies, practitioners, academic institutions, and professional organizations. We need validation standards appropriate for veterinary medicine's unique challenges and a professional culture that demands evidence-based AI adoption.

This isn't about creating barriers to innovation—it's about ensuring that innovation actually improves veterinary care. The same evidence-based principles that have advanced veterinary medicine for decades must guide our adoption of AI technologies.

We have a choice: continue accepting unvalidated AI tools and hope for the best, or demand the transparency and evidence that will ensure AI truly serves veterinary medicine's mission. The decision is ours, but our patients and clients deserve better than hope and marketing promises.

They deserve evidence.

What validation questions have you asked AI vendors? What responses did you get? Reply to this post and share your experiences—building a database of vendor transparency (or lack thereof) helps the entire profession make better decisions.

After 29 years in the veterinary diagnostics industry, I've watched AI evolve from academic curiosity to practice-changing reality. Now, as artificial intelligence reshapes how we approach veterinary medicine, I'm here to cut through the hype and help find out what's actually working.

Who I Am (And Who I'm Not)

I'm a data scientist, not a veterinarian, vet tech or practice manager. I won't tell veterinarians how to practice medicine or practice managers how to run their practice—that's your expertise. But I do bring something unique to the conversation: nearly three decades of experience translating complex technology into practical veterinary solutions.

I've seen first hand how the best innovations succeed not because they're the most sophisticated, but because they solve real problems in ways that fit naturally into practice workflows. I've also seen promising technologies fail because they ignored the realities of how veterinary medicine actually works.

The AI Revolution in Veterinary Medicine

We're at an inflection point. AI is moving beyond the laboratory and into every aspect of veterinary practice:

Diagnostic Applications: From radiographic analysis to laboratory interpretation, AI tools are becoming standard equipment rather than exotic add-ons.

Practice Management: AI-powered scheduling, inventory management, and client communication systems are streamlining operations.

Clinical Decision Support: Tools that help with differential diagnosis, treatment planning, and prognostic assessment are emerging rapidly.

Client Experience: From chatbots answering basic questions to AI-generated educational materials, technology is transforming how practices interact with pet owners.

Business Intelligence: Advanced analytics are helping practices understand their patient populations, optimize workflows, and improve outcomes.

The challenge isn't keeping up with every new tool—it's knowing which ones deserve your attention and how to implement them successfully.

What You'll Find Here

I'll explore how AI and data science principles apply to real veterinary challenges:

Tool Evaluations: Honest assessments of new AI applications—what works, what doesn't, and what questions to ask vendors before making decisions.

Implementation Strategies: How to successfully integrate AI tools into existing workflows without disrupting patient care or overwhelming staff.

Industry Analysis: Understanding market trends, regulatory developments, and emerging technologies that will shape veterinary practice.

Statistical Insights: The probability and data science concepts that can enhance clinical decision-making (without requiring a statistics degree).

Practical Frameworks: Actionable approaches for evaluating AI claims, managing technology adoption, and measuring success.

The Human Element

Here's what I've learned after nearly three decades in veterinary technology: the best tools amplify human expertise rather than replacing it. The most successful AI implementations enhance what veterinarians already do well rather than trying to fundamentally change how medicine is practiced.

Your clinical judgment, built through years of training and experience, remains irreplaceable. AI tools should make that judgment more informed and efficient, not substitute for it.

Free vs. Paid Content

Free posts will cover new AI tools, technology trends, and high-level industry insights—keeping you informed about what's happening in the rapidly evolving world of veterinary AI.

Paid subscriber posts will be the deep analytical dives—detailed evaluations of specific technologies, statistical concepts that impact daily practice, comprehensive implementation guides, and actionable frameworks you can use immediately. These posts will include detailed "Key Insights for Veterinary Practice" sections with concrete takeaways.

My Promise to You

Every post will include practical insights you can apply immediately. I'll respect your clinical expertise while sharing perspectives from the technology side of veterinary medicine. No buzzwords, no vendor marketing—just honest analysis from someone who's spent nearly three decades helping veterinary professionals navigate complex technology decisions.

What's Coming Next

My first deep-dive post will explore a critical but often misunderstood topic: "Beyond PPV: Why Likelihood Ratios Matter for AI-Driven Veterinary Diagnostics." It's a preview of the statistical insights that will help you evaluate diagnostic AI tools more effectively—content that will become exclusive to paid subscribers as we grow.

But that's just the beginning. We'll also dive into practice management AI, client communication tools, regulatory trends, and the business side of AI adoption.

Thanks for joining me on this journey. Let's make AI work for veterinary medicine, not the other way around.

Have questions about AI in veterinary practice? What challenges are you facing with technology adoption? I'd love to hear from you—reply to this post or reach out directly.