Stop Calling It a PIMS

AI-first veterinary software needs to organize around memory, context, and surfaces, not modules.

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.¹

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.² 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.³

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.⁴ 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.⁵,⁶ 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.⁷ 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?

1. For an overview of linguistic relativity and the Sapir-Whorf hypothesis, see “Linguistic relativity,” Wikipedia. https://en.wikipedia.org/wiki/Linguistic_relativity

2. George Lakoff and Mark Johnson, *Metaphors We Live By*, University of Chicago Press, 1980. Publisher page: https://press.uchicago.edu/ucp/books/book/chicago/M/bo3637992.html

3. Jon Ayers, Jeff Dixon, Adam Little, Adam Wysocki, with Robert Sanchez, “Companion Animal Veterinary Software Part IV: PIMS in the Age of AI: Weather the Storm or Wither?” Companion Animal Veterinary Software Guide, February 10, 2026. https://www.vetsoftwarehub.com/papers/companion-animal-veterinary-software-ai-paper-part-4.pdf.

4. Emily M. Tincher and Jules Benson, “How can embracing pet family–centered care forge a path to more accessible and sustainable veterinary medicine?” Journal of the American Veterinary Medical Association, published online October 13, 2025. DOI: https://doi.org/10.2460/javma.25.05.0353.

5. Epic, “Real Results Right Now: How Epic AI Is Reducing Costs, Improving Care, and Helping Patients.” https://www.epic.com/epic/post/real-results-right-now-how-epic-ai-is-reducing-costs-improving-care-and-helping-patients/

6. Oracle Health, “Clinical AI Agent.” https://www.oracle.com/health/clinical-suite/clinical-ai-agent/

7. Jon Ayers, Jeff Dixon, Adam Little, Adam Wysocki, with Robert Sanchez, “Companion Animal Veterinary Software Part IV: PIMS in the Age of AI: Weather the Storm or Wither?” Companion Animal Veterinary Software Guide, February 10, 2026. https://www.vetsoftwarehub.com/papers/companion-animal-veterinary-software-ai-paper-part-4.pdf.