88% of practices want your app to read their records. Here is what they mean by it

Survey respondents rarely write essays. When 1,111 veterinary practices were asked whether it mattered that third-party software could read from and write to their practice records, 982 of them said yes for at least one direction, and 979 of those 982 wrote an explanation in their own words.

That near-total willingness to explain is the most useful part of the data for anyone building veterinary software. Practices are not only telling you that integration matters. They are telling you what goes wrong without it, and that is close to a product specification.

The data is from Part VI of the Companion Animal Veterinary Software Guide (CAVSG), "The Customer Speaks," built on the Ayers Software in Practice Survey run by Kynetec across 1,273 North American practices between January and March 2026. The series' authors take an openly pro-integration position, which is worth knowing. The numbers themselves come from practices.

The headline numbers

Eighty percent rated read access as important and 75% rated write-back as important. Combined, 88.4% (982 of 1,111) rated at least one as important. Fewer than 4% said both were unimportant. The researchers found strong demand in every subgroup they measured, including corporate practices.

Write-back is the figure to notice. Many developers treat it as a later phase, something to add once read access is working. Three quarters of practices already consider it important, which means a read-only product is solving three quarters of the problem at best.

What practices say goes wrong

Kynetec coded the written answers into categories. For write-back, the top reasons were workflow and process efficiency (20%), complete and accurate medical records (16%), smooth interoperability between systems (14%), and reduced administrative workload (13%).

The researchers grouped the written answers into themes, and three of them carry direct lessons for how you build.

Integration is a purchase condition. "Automation is integral to our workflow. If automation is not a function, then we typically will not bring in that new software," wrote one US practice. Another: "2 way integration is critical and a non negotiable for us." If your product does not connect, you are losing deals you never hear about.

A missing integration is a clinical risk. One veterinarian explained that integration is necessary "to be certain that all medical information on a pet can be accessed at once, preventing a situation where a test result for example may not show up and I may believe the test was never performed." The CAVSG authors called this a patient safety argument rather than an efficiency one. For a developer, it means data completeness is not a nice-to-have. A record that silently lacks your data is worse than one that clearly never had it.

Without write-back, your product creates work. "I do not want my staff to spend time copy and pasting info between platforms, this wastes time and can cause errors," one practice wrote. Another: "Otherwise we have to manually add it, which is so time consuming it likely eats up any time made by the software that we are using." And from a practice where a booking tool was not syncing in real time: the schedule was "double booked."

That last example shows exactly how an integration fails from the practice's side. The failure was not missing data. It was stale data treated as current.

Turning the survey into a build checklist

1. Decide field ownership early. If your product and the PIMS can both change an appointment, a medication or a note, write down which system is the source of truth for each field. Most integration bugs that damage records are ownership bugs.
2. Make writes idempotent and logged. Practices care about "complete and accurate medical records." Duplicated entries from retries are exactly the kind of error that erodes trust in a clinical record. Log every write with enough detail to trace and reverse it.
3. Treat real-time as a requirement for schedules and results. The double-booking complaint came from sync lag. Where timing matters, use events or webhooks if the PIMS offers them, and poll aggressively if it does not.
4. Show sync state in your interface. When data is stale or a write failed, say so. A clinician who can see "last synced 40 minutes ago" can act safely. One who cannot see it will assume the data is current.
5. Design the failure path. Integrations break. Credentials expire, rate limits trip, the PIMS changes an endpoint. Decide what your user sees in each case before it happens in a clinic at 6pm.
6. Ask for consent explicitly. Practices own their data. Show which data you read, which you write, and why, and let them revoke access. The CAVSG series argues throughout that consent-governed access is what makes openness safe, and practices are increasingly aware of what third parties can see.

Why this is good news for developers

It is easy to read veterinary integration as a list of obstacles, and the fees and access barriers are real. This survey points the other way. The customers want what you are trying to build, strongly enough to write it down, and in the researchers' framing they increasingly see restricted access as a choice their software vendor made against them.

It also gives you leverage. A developer who builds integration well, with write-back, clear ownership and visible sync state, is building what practices are already asking for, in their own words.