The veterinary app, from the clinic's side of the counter.
A veterinary app means five different things depending on who is searching, and this page is about the one a clinic ships to its own clients: the app that lets a pet owner book a visit, get reminded before it, and see the records afterwards. Underneath, it is the same shape as anything you would make with a booking and scheduling app builder, with three complications a salon never has: the patient is not the person holding the phone, the reminders come out of a medical protocol, and the records are regulated.
So this page stays on the clinic's side of the counter: bookings, reminders and records access, the fields behind each, the state rules that shape them, and the one rule that decides whether a video visit can be offered at all. The owner's own tracker, the record that follows an animal from clinic to clinic, is a different app and gets its own page.
See the three jobsThe short version
Three jobs, each with a rule behind it.
On the clinic side a veterinary app does three things. It takes bookings, which only count if they land in the practice management system as a real appointment for a specific patient. It sends reminders, whose due dates come from the clinic's own protocol and the patient's record, never from the app. And it gives clients access to records, which are the practice's records, kept and released under the state veterinary practice act.
Telemedicine, if you add it, brings a fourth rule: the veterinarian-client-patient relationship, which under the federal definition cannot be started over video. The rest of this page is the detail, with the regulation text wherever there is one.
Five meanings
What people mean by "veterinary app".
The search term covers a clinic's client app, a professional network, a drug reference, a video-visit tool and a study aid. Only two of the five are something a clinic would ever build, and only one of them is what this page is about.
| What is searched | Who wants it | What it actually is | A clinic would build it |
|---|---|---|---|
| Veterinary app | A clinic, and the clients it serves | Bookings, reminders, messaging, refill requests and records access for the clinic's own clients. The PetOne veterinary app that National Veterinary Associates ships for the hospitals in its network is the clearest example: book a visit, message the care team, request a refill, download a vaccine record. | Yes |
| Veterinary information network app | Veterinarians, students, academics | VIN, the members-only online community for veterinarians: message boards, consultants, a disease and diagnostics reference and a drug handbook with its own mobile app. A membership, not a clinic tool. | No |
| Veterinary medicine app | The clinical team | Drug and dose references, formularies and calculators the veterinarian and technicians use at the table. Reference material for the people treating the animal, not for the client. | No |
| Veterinary telemedicine app | Clinics, and owners who want a video visit | Video or photo consults. Lawful only inside an existing veterinarian-client-patient relationship in most states, which is the section below. | Yes |
| Veterinary anatomy app | Students | 3D anatomy study tools such as EasyAnatomy: spin a model, fade layers, quiz yourself. Bought, not built, and nothing a clinic ships to clients. | No |
The first row has a mirror image: the owner-side pet care app, where one record per animal follows it across clinics, sitters and groomers, and the owner is the one who writes to it. The clinic-side app runs the other way. The practice writes; the client reads, books and replies. Mixing the two in one product is the most common way a veterinary app ends up doing neither job well.
Try it
Which veterinary app are you actually looking for?
Tick what applies. The answer decides whether this page is the right one, and what to settle first if it is.
Verdict
Tick at least one line to see a verdict.
Job one
Bookings that become real appointments.
A salon booking is one person, one chair, one slot. A veterinary booking has a patient who is not the account holder, an appointment type that decides how long it takes, and a clinician or a room that has to be free at the same time. Get those fields right and the rest is a calendar.
The fields a veterinary booking needs
- The client, and which of their pets the visit is for: one account, several patients
- Appointment type, with the duration and the clinician, room or technician it needs
- Reason for the visit in the client's own words, plus anything the front desk needs to triage it
- New or existing client, because a first visit takes longer and may carry a deposit
- Preferred clinician, if the clinic allows the client to choose
- Confirmation status, and who confirmed it: an unconfirmed booking is the one that becomes a no-show
- Any preparation instructions the clinic attaches to that appointment type, sent with the confirmation
Request form, or a real slot
Two models exist. A request form takes the client's preferred time and the front desk calls back to confirm: cheap, no integration, and every booking is two touches. Real-time booking shows actual availability and writes the appointment straight into the practice management system, the PIMS: better for the client and for the desk, and only possible with an integration. That is why the online booking products in this market lead with the list of systems they sync with. Vetstoria, which is the name PetDesk trades under outside the United States, names IDEXX Cornerstone and Neo, Covetrus AVImark and OpenVPMS among others on its pricing page, because the integration is the product.
It is the same shape as an auto repair shop app: the booked thing is the vehicle, not the driver, the job type sets the bay time, and a booking that never reaches the shop's own system is just an email with a logo on it.
Job two
Reminders that come from the record, not the app.
Reminders are the reason most clinics buy a client app in the first place. There are four kinds, and the design mistake is treating them as one: each has a different source, a different sense of when, and a different thing the client should be able to do about it.
| Reminder | Where the date comes from | When it goes out | What the client can do |
|---|---|---|---|
| Appointment reminder | The booking itself | Whatever the clinic chooses, commonly a day or two before and again on the day | Confirm, reschedule, or cancel, and the reply has to update the booking |
| Preventive care due date | The clinic's own protocol applied to the patient's record | The due date on the record. The app carries it; it does not decide it | Book the visit, or dismiss with a reason the clinic can see |
| Refill reminder | The prescription as dispensed: quantity and days of supply | Before the supply runs out, by the clinic's margin | Request a refill, which the clinic approves or declines |
| Recheck or follow-up | The visit, set by the veterinarian | The date the clinician entered | Book, or message the clinic |
The rules around them
Four settings turn a reminder feature from a nuisance into a service. A channel per client, since some want a push, some a text and some an email, and the choice is theirs. Quiet hours, set by the clinic. A snooze that the client can use without cancelling the reminder. And a log of what was sent, to whom, when and through which channel, because "we did remind you" only holds if the clinic can show it. One rule sits above all of these: nothing about a patient goes to a number or an address the client did not put on their own account.
Getting those reminders onto a phone is its own subject: permissions, device tokens, what happens when a client turns notifications off and never notices, and where the scheduled send actually runs. That is beyond the scope of this page.
Push notifications for appointment remindersJob three
Records access, on the practice's terms.
The medical record belongs to the practice and is regulated by the state, not by the app. California's veterinary board rule is a useful reference because it spells out both what the record must contain and what the client is entitled to. The left column below is what 16 CCR 2032.3 requires the record to hold; the right column is what a client app usually surfaces from it.
| What the rule requires the record to contain | What the client app usually shows |
|---|---|
| Client name, address and phone number | The account, editable by the client |
| Animal name, age, sex, breed, species and color | The patient profile, one per pet on the account |
| Dates of custody, history, exam findings, diagnosis before treatment | Visit summaries, released per item by the practice |
| Treatment plan with medications and dosages; medications prescribed and dispensed | Current medications, refill status and a refill request |
| Surgical and anesthetic detail, daily progress, who made each entry | Usually not shown; stays in the practice management system |
| The whole record: kept at least three years after the last visit | Vaccination history with a shareable certificate, and a way to request the full record |
The same rule sets the two moments a records feature has to serve. Records are kept for at least three years after the animal's last visit, a summary must be made available to the client within five days of a request, and an emergency clinic has to hand over a legible copy when the patient is released. So there is the routine moment, where a boarding kennel wants proof of vaccination and the client wants to tap and share, and the formal one, where a client asks for the record and a clock starts. Other states have their own versions of the rule; check your board's before you promise anything in the app.
What the client should not see
Internal notes, the clinician's working assessment, and anything about another client's animal. Release is a decision the practice makes item by item, so the app needs a per-record "shared with client" flag rather than a single switch, and a record of who flipped it. That is a permissions model, not a clinical one, and it is the part most off-the-shelf client apps get least wrong and most custom builds forget.
The fourth rule
A veterinary telemedicine app starts with the VCPR.
A video button is easy to add and hard to add lawfully. Federal regulation defines a valid veterinarian-client-patient relationship in 21 CFR 530.3(i): the veterinarian has taken responsibility for medical judgments and the client has agreed to follow instructions, the veterinarian knows the animal well enough to make at least a preliminary diagnosis and is available for follow-up, and the relationship "can exist only when the veterinarian has recently seen and is personally acquainted with the keeping and care of the animal(s) by virtue of examination of the animal(s)" or timely visits to the premises.
The AVMA's position, on its telehealth and the VCPR page, is that telemedicine should only be conducted within an existing VCPR, and that a VCPR "cannot be established solely by telephonic or other electronic means." State law is where it gets specific. By the AVMA's count in November 2023, twenty-two states explicitly require an in-person examination or a visit to the premises to establish the relationship, while a handful, Arizona and California among them, changed their practice acts to allow a virtual VCPR with limits on what can be prescribed and for how long.
For the app that translates into three fields and one rule. The fields: the date of this patient's last in-person exam, the state the animal is in, and whether the clinician is licensed there. The rule: given those, is the video visit a consult inside an existing VCPR, general advice with no diagnosis or treatment, or not available. None of that is clinical judgement. It is the app knowing what the clinic is allowed to offer before it offers it.
Buy or build
Off-the-shelf veterinary apps against building your own.
Four ways to get a client app, and what each one does with the three jobs. Prices are what the vendors publish, checked in September 2026; where a vendor publishes nothing, the table says so rather than guessing.
| Approach | Bookings write to the PIMS | Reminders from your protocol | Records access | Whose brand, whose rules | Published price |
|---|---|---|---|---|---|
| Hospital group's own appPetOne Veterinary, built by NVA for its own hospitals | Yes, for the group's systems | Yes, the group's | Yes | The group's | Not sold to outside clinics |
| PIMS-connected client platformPetDesk in the US, Vetstoria elsewhere | Yes, for the systems it supports | Vendor templates, configured for you | Yes | The vendor's app, set up for your clinic | Vetstoria UK: from £199 a month for up to 2 clinicians, ex tax (Sep 2026). PetDesk: not published |
| Generic booking toolAny salon-style scheduler | No | Appointment reminders only | No | Yours, but there is no patient | Varies; usually per seat |
| Custom-built veterinary appYour booking rules, your reminder table, your release flags | Whatever integration you build | Yes, exactly yours | Yes | Yours | Platform from $25 a month, plus the integration work |
Vetstoria's UK online booking plans, monthly billing, excluding tax: £199 for up to 2 practicing clinicians, £299 for up to 4, £399 for up to 7, from its pricing page on 21 September 2026, which also states that in the United States Vetstoria operates as PetDesk. PetDesk's own pricing page, checked the same day, publishes no prices and offers a demo instead.
A hospital group can justify its own app; a single practice historically could not, which is why the PIMS-connected platforms exist and why they charge by the clinician. They are the right answer for a clinic whose process matches the vendor's templates. The honest reason to build instead is fit: a booking rule the vendor does not support, a reminder that should trigger something other than a text, a release flag per record type, a VCPR check before the video button. Teams whose process does not fit an off-the-shelf tool end up building their own, and that is what Newly is for: describe the appointment types, the booking rules, the reminder table and what the client sees, and it builds a real native app around your process instead of the vendor's.
Its boundaries are worth knowing before you describe anything. It costs $25 a month with no free plan. iOS builds are submitted to App Store Connect, where you test through TestFlight, finish the listing and submit for review yourself, with a paid Apple Developer Program membership of your own. The current version produces no Android release builds, which matters for a clinic whose clients carry both kinds of phone. And the integration with your practice management system is your work either way: no builder knows what your PIMS exposes until you find out.
Scoping it
Seven steps before anyone builds a screen.
Six of these are a document, and documents are cheap to change. The seventh is the release, and it is the same for any app that needs an account to work.
- 1
List the appointment types
Each with its duration and the resource it needs: a clinician, an exam room, a technician. This is the grammar of the schedule, and the booking screen cannot be designed without it.
- 2
Pick the booking model
Request form, where the front desk confirms by phone, or real-time slots that write straight into the practice management system. Decide whether new clients pay a deposit and what the cancellation window is.
- 3
Confirm the integration path
Find out what your practice management system exposes for patients, appointments and reminders, and on what terms. If the answer is nothing, you are building a request form and should say so.
- 4
Write the reminder table
One row per reminder: the event that triggers it, the offset, the channel, what a reply does and who can snooze it. Keep a log of every send, because a reminder only counts if you can show it went out.
- 5
Decide what the client sees, per record type
Vaccination history, medications, visit summaries, invoices: a release flag on each, set by the practice. Then write down how a formal records request is fulfilled inside your state's deadline.
- 6
Decide on telemedicine, or leave it out
If it is in, define the VCPR check: last in-person exam date, the state the animal is in, the clinician's license there, and what the app offers when the check fails.
- 7
Plan the release
A paid Apple Developer Program membership, an App Store Connect listing with screenshots for each device size, a privacy policy and a demo login for review, since the app requires an account.
Steps one to six are also, word for word, what you would describe to Newly: the appointment types and their durations, the booking model, the reminder table, the release flag on each record type and the VCPR check. Write them as a table each, agree them with the front desk and the clinicians, and only then decide whether to buy the vendor's version or build yours.
Sources
Where the specifics came from.
Four things on this page come from a primary source rather than from industry habit. Nothing here is clinical advice; the protocol behind any reminder is the clinic's own.
FAQ
Veterinary apps, answered.
On the clinic side, a veterinary app lets a client book an appointment for a specific pet, get reminders before it, message the clinic, request prescription refills and see records such as vaccination history and visit summaries. The practice management system stays the system of record for the schedule, the medical record and billing; the app is the client's window onto it, reading from it and writing bookings and messages back.
Start with the booking rules, not the app icon.
A veterinary app is three jobs and the rules underneath them. Write the rules down, agree them with the front desk, then build the app around them in Newly.