The PIMS Integration Problem Is Real. It’s Also Much Harder Than People Think.

Why everyone agrees veterinary software is broken—and why the people promising quick fixes are reading the wrong blueprint.

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

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

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

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.

---

---

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.⁴ 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.⁵ The human healthcare interoperability market alone is roughly ten times larger than the entire veterinary software market.⁶

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.⁷ 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.⁸

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

1. Based on IDEXX’s “Finding the Time” internally published practice efficiency survey data, widely cited in industry analysis.

2. Ayers, J; Wysocki, A. “Companion Animal Veterinary Software Guide (CAVSG) Parts 1–9”, citing Kynetec market share data. See also PMC/NIH analysis confirming combined IDEXX (Neo + ezyVet) and Covetrus (Pulse) control approximately 79% of the market.

3. Wysocki, A. “Fifteen Platforms. No Glue” and “Your Data. Their Terms.” Veterinary Software Insider, 2026.

4. GetLatka. Redox Revenue and Funding Data, 2024.

5. Wysocki, A. “Their Integration. Your Workaround” and “What Your PIMS Vendor’s Sales Rep Can’t Tell You.” Veterinary Software Insider, 2026. The $200–400M estimate aligns with broader market data from Grand View Research (global veterinary software at $1.43B in 2024, projected to $3.01B by 2030) and GlobeNewsWire/Wissen Research (~$883M in 2025, growing at 8% CAGR through 2030).

6. Grand View Research. Global healthcare interoperability market estimated at $3.4B (2023) to $8.57B by 2030.

7. viggoVet. “The Integration Imperative,” 2026.

8. ChatGPT Health adoption data, widely reported January 2026.

9. Anthropic. Model Context Protocol SDK download figures, 2025.

10. Wysocki, A. “The 120 Days Nobody Owns.” Veterinary Software Insider, 2026.

11. AVMA. “US Pet Insurance Industry Surpasses $4.7B in 2024.” Global figures: $21.8B (2025) to $79.6B by 2033.