veTriage—Safety-First Vet Phone Triage PWA Built in a Week

Built by a veterinarian & practice owner with no coding experience, this app turns clinical triage expertise into a structured safety net for vet clinic staff. Live now, screening all sick-pet calls.

Comment

veTriage—Safety-First Vet Phone Triage PWA Built in a Week

Elevator pitch: Built by a veterinarian and practice owner with zero coding experience, veTriage turns decades of clinical and operational judgment into a deterministic, capacity-aware workflow for sick-pet calls. It is now in routine pilot use by receptionists, technicians, and a veterinarian in a real hospital.

Inspiration

Every sick-pet call begins with a pet and a worried person.

The first person to hear the story is usually not a veterinarian. It is a receptionist.

At Paoli Vetcare, our receptionists answer those calls while other phones are ringing, clients are checking in and out, and the schedule is already full. They have to listen through fear and incomplete descriptions, ask the question that changes the route, and decide what should happen next.

That has always been difficult. It became much harder when our hospital lost two veterinarians.

Before the pandemic, a sick pet could usually be seen within a day or two. Now our next open appointment may be a week or more away. But a pet's medical need does not become less urgent because the calendar is full.

My husband, Dr. Jay Rowan, has spent his career taking care of our clients when they call with a sick pet. In the past, they would usually receive a same-day call from him. As his caseload became overwhelming, we began using our veterinary technicians as a delegation layer. They gather information, consult with him, communicate plans he has approved, and handle the parts of the case that are appropriate for them to handle.

That helps him reach more patients, but only if the information reaching the medical team is complete enough to act on.

Otherwise, Dr. Rowan still has to begin every callback by reconstructing the entire history from the owner. He is incredibly efficient and capable, but one person should not have to carry every case from the beginning simply because he believes that if something is going to be done right, he should do it himself.

I tend to see the problem differently. My instinct is to organize, triage, delegate, and build a system around the people doing the work. If I were physically working beside the team every day, that is what I would naturally be doing myself.

veTriage is partly a way to place that helping hand into the workflow when I am not standing at the front desk.

It is not an app as a gimmick. It is an app as a helping hand.

The recurring complaint for years was that receptionists needed to "triage better." But receptionists often have little or no veterinary medical training. They cannot be expected to recognize what a veterinarian recognizes after decades of clinical practice.

That was the foundational insight:

We cannot expect them to do what a veterinarian can do.

The problem was not the receptionists. The hospital had never converted decades of veterinary judgment into a support system that non-clinicians could reliably use.

Because I cannot clone my most experienced people, my approach to practice-management problems has always been to build systems. The goal was never to turn receptionists into veterinarians. It was to give them enough structure to recognize risk, gather useful information, and know when to involve the medical team.

We tried the conventional solutions first: verbal coaching, written protocols, and a detailed reception triage flowchart. They preserved important knowledge, but they did not work well during a live telephone call. A worried owner rarely gives information in a neat order, and a static document cannot change its next question based on the answer just given.

I then created Custom GPT assistants that could ask follow-up questions and apply our four-color system interactively. That demonstrated that clinical reasoning could be translated into a process instead of remaining only in one veterinarian's head.

A real call showed the potential.

Our lead receptionist, Courtney Price, took a call involving a panting dog. The Custom GPT produced a RED alert and told her to interrupt the veterinarian. Dr. Rowan recognized signs of heat-related illness and referred the dog to an emergency hospital. The report on his desk the next morning confirmed that the dog had been treated for life-threatening heatstroke and was recovering.

I would never claim that AI saved that dog. What I can say is that the system recognized urgency at a moment when recognizing urgency mattered.

That case also raised the stakes. A tool used during a sick-pet call had to be consistent, fast, auditable, and safe. Conversational AI was useful for developing the reasoning, but its variability made it the wrong final decision-maker for a live clinical workflow.

The cost of testing an unproven idea

In an early planning conversation, GPT-5.6 outlined the conventional professional-development path: prototype design, a custom progressive web app, and later integration with our practice software.

Its planning estimate was approximately $32,000–$91,000 upfront, followed by roughly $3,600–$18,000 per year for hosting, maintenance, and support.

For a small independent veterinary hospital, that was not simply expensive. It was too much money to risk on an idea that had not been tested with the people who would actually use it.

I would not have made that gamble.

GPT-5.6 and Codex changed the economics of experimentation. They did more than reduce the eventual cost. They made the initial risk small enough for the project to be attempted at all. I could build a working version, put it in front of Courtney and Chelsie, watch where it failed, and improve it before committing substantial capital.

The value was not only money saved. AI made it possible to find out whether the idea was worth building.

So I asked the question that changed the project:

Couldn't we build it together without an app developer?

I did not know about OpenAI Build Week when the week began. I found the email on Friday night, five days into Build Week, after a working version of veTriage had already been built and people were already using it.

I did not build veTriage because there was a competition. I entered the competition because I had already built veTriage.

What it does

veTriage is a deterministic, safety-first progressive web application for veterinary staff handling sick-pet telephone calls.

The four colors are more than colors. They begin the next human action.

  • RED means a credible immediate threat to life or risk of major irreversible harm. The routine workflow stops. Staff collect a focused emergency history, interrupt an authorized decision-maker, or direct the client to emergency care if no authorized person is available.
  • ORANGE means stable but time-sensitive, generally within two days. The case enters the technician review queue ahead of YELLOW cases. Dr. Rowan may call, authorize an interim plan, or have a technician communicate the plan.
  • YELLOW means a stable problem that generally should be evaluated within three to seven days. The case still enters medical review even when the appointment schedule cannot meet that timeframe.
  • GREEN means mild, stable, or non-progressive. Reception may schedule the next actual opening unless a staff member or veterinarian chooses to escalate.

This is the central product decision:

Clinical urgency and hospital capacity are separate.

A full schedule does not make a patient less urgent. The absence of a same-day appointment does not turn a stable patient into an emergency. Capacity may change the route, but it cannot change the clinical truth.

That separation allows the hospital to do more than say, "We do not have an appointment."

A GREEN case can be scheduled into the next actual opening under the protocol. An ORANGE or YELLOW case can still receive medical review. A technician can discuss the case with Dr. Rowan. A veterinarian may decide that a current patient with an established relationship and recent examination is eligible for an interim plan. The technician may then explain the veterinarian's tentative assessment and treatment, with follow-up scheduled when the pet can be examined.

No callback or medication is promised. Human review remains visible. But the pet and owner do not receive a cold shoulder simply because the schedule is full.

The complete chain of care

The workflow begins and ends with the pet:

sick pet → worried owner → receptionist → scheduling or medical review → technician and/or veterinarian → plan → owner follows the plan → follow-up → pet receives care

Every link matters.

A missed observation, an incomplete handoff, or unclear instructions can affect everyone who comes next. veTriage gives the receptionist observable questions to ask, the technician a useful history to review, the veterinarian a concise handoff, and the owner language that reflects the medical team's actual plan.

The app does not replace any person in that chain. It helps each person contribute what they do best.

What the staff member experiences

The application guides the user through four main steps:

  1. screen for a credible emergency;
  2. choose the closest complaint pathway;
  3. collect observable, decision-relevant history; and
  4. produce a clinical category, authorized next steps, client wording, worsening precautions, and an IDEXX Cornerstone-ready note.

Cornerstone is our practice-management and medical-record system.

The current version includes ten common sick-visit pathways:

  • vomiting;
  • diarrhea;
  • young puppy or kitten;
  • ADR/lethargy;
  • urinary;
  • cough/respiratory;
  • eye;
  • ear;
  • skin/wound/itching; and
  • lump/mass.

The questions focus on observable function instead of vague labels. Rather than accepting that a pet is "lethargic," the app asks whether the pet can be roused, stand, walk, respond normally, breathe comfortably, retain water, or pass urine.

When a client cannot answer a critical question, the app does not automatically turn uncertainty into RED. It opens a clarification workflow, suggests more observable wording, and preserves human escalation.

The RED emergency workflow

A simple triage tool might identify a possible emergency and immediately tell reception to interrupt the veterinarian. That can create another problem: the medical team is interrupted with only a color and not enough information to make a decision.

veTriage keeps the caller on the line and gathers a short, focused emergency history:

  • the exact RED trigger;
  • whether the sign is happening now;
  • when the pet was last normal or the problem was first noticed;
  • whether the condition is worsening, stable, intermittent, or improving; and
  • one complaint-specific factual detail.

If the pet is actively deteriorating, staff can stop the questions and act immediately.

Otherwise, the app produces a decision-ready handoff and records the actual veterinarian or ER decision. Only an authorized veterinarian can move a RED result downward, and the original trigger remains visible for audit and learning.

Documentation and safety

Every completed route can generate a structured note ready to paste into IDEXX Cornerstone. The note records the category, history, route, client response, review status, human override when applicable, staff initials, rule version, and case identifier.

The live app intentionally does not ask an LLM to interpret each case.

At runtime it applies versioned, deterministic rules. The same answers produce the same result every time. GPT-5.6 and Codex helped us design and build those rules; they are not the live clinician.

The app also:

  • requires no client or patient name to complete the workflow;
  • stores no client or patient record;
  • keeps information only for the active session unless staff copy the note into the correct medical record;
  • allows staff to escalate upward with a documented reason;
  • allows only an authorized veterinarian to lower the category;
  • never invents appointment availability or assumes a squeeze-in;
  • includes an installable manifest and service worker; and
  • works well on desktop, tablet, and mobile, with offline tolerance for the application shell.

AI helped build the system. The veterinary team remains responsible for the patient.

How we built it

What existed before July 13

The clinical problem, written protocols, four-color framework, reception flowchart, Custom GPT experiments, and early proof-of-concept work existed before the submission period.

Those earlier efforts established the domain knowledge. They did not produce the current application.

What changed during Build Week

The core qualifying build occurred during Build Week beginning July 13, 2026. Testing, documentation, public deployment, and submission preparation continued through July 21.

During that period, the product grew from a small set of pathways and a basic interface into a complete staff workflow with:

  • ten complaint pathways;
  • a universal danger screen;
  • observable-function wording;
  • clarification instead of automatic RED for unresolved information;
  • relationship and examination-status questions;
  • technician review queues;
  • capacity-aware no-slot routes;
  • focused RED history and veterinarian handoffs;
  • approved client language and worsening precautions;
  • human override and audit visibility;
  • Cornerstone-ready documentation;
  • mobile-responsive PWA behavior and offline tolerance;
  • a versioned routing contract;
  • branding and a coherent product experience; and
  • automated clinical, UI, PWA, handoff, and documentation tests.

The original deployed staging export contained 41 human-readable source, configuration, test, and documentation files, plus 17 application assets. The public judging repository now also includes deployment documentation, staff-feedback evidence, and the dated screenshot timeline. Its standard test command runs 79 automated checks covering deterministic clinical routes, emergency handling, technician review, interim-plan eligibility, client language, UI controls, PWA behavior, handoffs, and Cornerstone notes.

Using veterinary S.O.A.P. to build software

I approached the hospital-wide problem using the same S.O.A.P. structure veterinarians use to work through a patient:

  • Subjective: What were staff and clients experiencing?
  • Objective: What observable facts changed urgency or action?
  • Assessment: What was the actual system failure?
  • Plan: What structured workflow could help the right person act at the right time?

The decisive shift came when I stopped asking software to behave like a veterinarian. Instead, I defined the sequence an experienced veterinary team follows:

  1. rule out a credible emergency;
  2. describe observable function rather than rely on vague labels;
  3. identify the main complaint;
  4. assign clinical urgency independently of appointment availability;
  5. define what reception is authorized to do;
  6. protect veterinarian time without withholding escalation;
  7. use approved client language and worsening precautions;
  8. produce a useful medical note; and
  9. preserve human review and override.

How GPT-5.6 contributed

GPT-5.6 helped me work at the level where I had expertise:

  • veterinary medicine;
  • patient safety;
  • staff workflow;
  • delegation;
  • client communication;
  • callback policy;
  • scheduling constraints; and
  • medical-record documentation.

It helped organize years of scattered knowledge, ask the questions I had not thought to ask, challenge unsafe assumptions, compare possible workflows, interpret screenshots and staff feedback, and turn tacit judgment into a product specification.

I made the clinical, operational, and safety decisions. I rejected suggestions that did not fit our hospital. The better I explained the real problem, the better the product became.

How Codex contributed

Codex translated the specification into working software.

It created and revised the application files, implemented branching logic and state transitions, built the responsive interface, added handoff and note generation, created automated tests, inspected the code for defects, preserved rollback points, and deployed new private staging versions for the staff to test.

Codex was not incidental or decorative. It performed the core engineering work that turned the clinical and product decisions into a non-trivial working application.

I built it by talking

I was born in 1964. I had zero coding experience and had never built even a structured online form.

Most of this project was not built while I sat at a desktop computer. Most of my interactions with AI were dictated on my iPhone. I only began working consistently at a computer near the end, when the submission itself required more file handling.

I did not sit down to learn prompt engineering or craft one perfect prompt. I talked.

When the transcription was wrong, I corrected it. When I disliked a workflow, I explained why. When the staff found a problem, I sent a screenshot and talked it through. When I did not know what to do next, I asked.

At one point I realized that the experience felt like collaborating with a software developer.

There is an even stranger fact: I have never seen the Codex interface.

I used Codex through the ChatGPT and Sites workflow, but I never opened an IDE or looked at the development environment while we were building. Codex was modifying files, running tests, and deploying updates underneath the conversation. My view of the project was the discussion, the live application, the staff's experience, and the results.

I did not stop being a veterinarian in order to become a programmer. The software-development process met me where I already was.

Why Sites mattered

Codex made it possible to build the app. ChatGPT Sites made it possible for the staff to use it.

That distinction is easy for a nontechnical person to miss until deployment becomes a problem. Writing code is not the final step. The application still needs hosting, access controls, a URL, deployment, and a way to update it.

Sites handled that private deployment from the same workspace. With almost no infrastructure knowledge from me, Sites gave the project a live URL that Courtney, Chelsie, and Dr. Rowan could open and use.

Without Sites, veTriage could easily have remained an idea or a collection of code on a computer. Deployment was another link that could have broken the chain.

When the contest required a public judging link, my workspace would not allow me to make the Site public. I then had to export the source, adapt it for Netlify, create a GitHub repository, and learn deployment steps I had never seen before. That experience made the value of Sites even clearer: it had quietly removed an entire layer of technical work from the original hospital deployment.

Staff became product partners

The people who would use veTriage were not brought in at the end to approve a finished product. They helped shape it while it was still being built.

Courtney, my lead receptionist, and Chelsie, my practice manager, tested it at the reception desk, where interruptions, incomplete information, worried owners, and limited appointment capacity determine whether a workflow succeeds.

They identified questions clients could not realistically answer, missing options, unclear navigation, unnecessary steps, terminology problems, and routing behavior that did not reflect meaningful differences among responses.

My husband, Dr. Jay Rowan, reviewed the clinical thresholds, callback rules, escalation behavior, and the information he needed in a handoff.

Their feedback did not slow the project down. It made the product safer and more useful.

Challenges we ran into

Translating experience that usually feels intuitive

Much of what an experienced veterinarian recognizes happens so quickly that it feels like instinct. Building veTriage required me to slow that reasoning down, identify the observation that truly changes a decision, define exceptions, and convert tacit knowledge into rules that could be tested.

Making the history useful without asking reception to diagnose

The system had to gather clinically meaningful information without turning receptionists into diagnosticians.

That is why the questions focus on what the owner can observe. Can the pet wake? Stand? Walk? Breathe comfortably? Keep water down? Pass urine? The app gathers the history. The veterinarian retains diagnosis and treatment authority.

Separating clinical urgency from capacity

This may have been the most important and difficult design problem.

A patient can need care within two days when no appointment exists for a week. The app had to preserve that ORANGE result without inventing a slot, forcing an unsafe squeeze-in, or abandoning the patient.

The solution was a second routing layer: technician review, veterinarian review, narrow callback rules, potential interim plans for eligible current patients, outside urgent-care options, cancellation-list handling, and explicit worsening precautions.

Supporting Dr. Rowan without making him the starting point for every case

The app only works if it helps the entire team, including the veterinarian.

Receptionists need to know that the history they collect is useful. Technicians need a case they can review efficiently. Dr. Rowan needs enough information to decide whether he should call, authorize a plan, delegate communication, or direct emergency care.

If he did not adopt the workflow, reception would eventually abandon it. His use of the generated ORANGE notes and callback summaries is therefore not a side effect. It is essential product validation.

Keeping RED meaningful

Chelsie discovered one of the most consequential defects when several meaningfully different answers produced the same RED result.

It would have been easy to treat that as a small bug. It was not.

A system that classifies too many patients as RED may look conservative, but it is not harmless. It can overwhelm the medical team, send stable patients to costly emergency hospitals, train staff to distrust the warning, and allow a true emergency to disappear into noise.

Her screenshot led to a broader redesign:

  • RED was narrowed to explicit signs of immediate danger;
  • uncertainty received a separate clarification path;
  • vague labels alone no longer created automatic emergencies;
  • focused urgent history was added before interruption; and
  • only an authorized veterinarian could move a RED result downward.

Staff testing did not simply validate the application. It became part of the clinical and product-design process.

Earning a place in a real workflow

Building software is one challenge. Earning a place in a busy hospital's routine may be even harder.

Dr. Rowan and I have spent thirty years trying to improve some hospital workflows. People may follow a new process for a day and then return to the familiar one. Busy staff have many competing demands, and even a good idea can feel like extra work.

veTriage had to be useful enough that it did not feel like another protocol to remember. It had to guide the work, help the next person in the chain, and produce something the medical team actually used.

Accomplishments that we're proud of

From a required pilot to routine use in one day

On Monday, July 13, I told the staff that I was "pulling my boss card" and asked them to use the prototype for every sick call so we could learn from it.

Exactly one day later, I did not have to ask.

By Tuesday, July 14, the team had begun using veTriage as part of the routine pilot sick-call workflow without another reminder. That was not the end of the build. The application continued to improve throughout Build Week as staff used it, identified problems, and helped refine the clinical and operational workflow.

By Monday, July 20—one week after the required pilot began—our hospital was using veTriage throughout the day. This included other receptionists who had been with the hospital for less than two weeks, experienced veterinary technicians, and Dr. Rowan, who used the generated information to review callbacks. Reception passed the Cornerstone-ready note to the technicians, who reviewed and prioritized it before bringing it to Dr. Rowan. He made the medical and treatment decisions and decided which callbacks could be delegated. When he authorized an interim plan, some owners could begin treatment while their pet awaited a follow-up appointment.

I kept asking for feedback and additional changes that Monday. After a full day of routine pilot use, there were no significant new requests.

That does not prove the application is perfect or that long-term adoption is guaranteed. It does show something that anyone who has supervised people will recognize as encouraging: the workflow moved very quickly from something I required the team to try into something they were using without being reminded.

On July 21, Chelsie asked one of our recently hired receptionists—about two months into her first job in veterinary medicine—how veTriage was working for her.

She said it was “more efficient” and that it gave her “more targeted questions,” which was especially helpful because she had no previous veterinary experience. She also valued the continuity created when the generated note was placed in the record: if a client called back, staff could see that the earlier concern had already been documented instead of starting again with no context.

When Chelsie asked whether the tool might help receptionists elsewhere, she pointed specifically to “the learning curve of learning all kinds of questions to ask.” Her conclusion was simple: “I definitely think it’s helpful.”

That feedback mattered to me because it came from someone encountering both veterinary medicine and veTriage with fresh eyes. The app was not only helping her complete a call. It was beginning to show her which questions matter during a sick-pet call.

For our reception staff, veTriage is becoming more than a routing tool. Early feedback suggests that it may also serve as a training tool.

The full interview transcript is included in the repository's evidence folder.

A real product, not a static demonstration

veTriage is not a slide deck, a mockup, or a chatbot transcript. It is a functioning PWA with a complete path from safety screen to clinical route, authorized action, client language, human review, and medical-record documentation.

It is already in routine pilot use by the people for whom it was designed: receptionists, technicians, a practice manager, and a veterinarian.

A mobile product built largely from a mobile phone

The finished application works naturally on phones, tablets, and desktops.

That is meaningful to me because I remember how difficult it was to make our hospital website mobile-friendly only a few years ago. This is a more complex interactive application, yet it became responsive as part of the same build.

It is also fitting that much of veTriage was conceived, refined, reviewed, and managed from the same type of device on which it works so well.

A deterministic safety architecture

AI accelerated the build, but the live clinical logic remains explicit, versioned, reviewable, testable, and subject to human authority.

That decision makes the system less flashy than an AI symptom checker. It also makes it more appropriate for the job we needed it to do.

A staff-created safety improvement

Courtney and Chelsie were not decorative users added to a story after the app was built. They found real problems and changed the product.

The redesigned RED workflow is safer because Chelsie was willing to say, "This does not make sense," and because the application was still flexible enough to change immediately.

A better way to use limited veterinary attention

The app helps reception identify GREEN cases that can be booked further out, relieving schedule pressure. It sends YELLOW and ORANGE cases into ordered medical review and gives Dr. Rowan the information he needs without making him begin every callback from zero. Decision-ready RED handoffs give him a concise history when emergency referral may be necessary, while clearer thresholds reduce false alarms for cases he determines can wait a day or two. In this way, veTriage helps protect pets' health and owners' resources.

It does not create more hours in his day. It helps his judgment reach more patients within the hours he has.

What we learned

I began this project thinking the main challenge was veterinary triage.

It was not.

The deeper challenge was turning expert judgment into a system that other people could use safely, consistently, and with confidence.

That required more than clinical rules. It required understanding how people communicate under stress, how a full hospital actually operates, what the next person needs, where authority begins and ends, and how a process can fail even when everyone is trying to do the right thing.

Ideas were not the scarce resource

I have always had ideas. The difficulty has been implementing them.

There is something painful about watching an idea die on the vine because you do not have the time, money, or expertise to build it. Having the idea is not nearly as rewarding as seeing it become something real and useful.

AI did not suddenly make me more creative. It changed the probability that an idea could survive long enough to be tested.

The conventional cost estimate mattered for that reason. It was not only a bill I avoided. It was a risk I would never have taken. GPT-5.6, Codex, and Sites lowered the cost of failure enough that I could experiment.

Another barrier fell: I did not have to know what came next

Whenever I reached the edge of my knowledge, I asked what to do next.

I did not need to understand the entire roadmap before beginning. I did not need to learn programming, deployment, testing, version control, and architecture in advance. I learned the concepts when the project needed them, while working on a problem I understood deeply.

Looking back, this was not a situation where I researched and crafted the correct prompts. It was a conversation.

I felt like I was collaborating with a software developer.

The domain expert could remain the domain expert

I did not become the person writing React components. I still don't know what they are! I remained the veterinarian and practice owner deciding what the system should do, what it must never do, and how it should fit the people and patients in our hospital.

Codex handled the implementation. GPT-5.6 helped me reason through the product. Sites handled the private deployment. Courtney, Chelsie, Dr. Rowan, and the staff supplied the reality that no design document could provide.

Everyone contributed a different link.

I recognized the process was repeatable on the first day

This was not a realization I invented after the project succeeded.

On the first day of Build Week, as the app began to work, I told Chelsie that the same process might help us with another problem we have carried for years: hundreds of written hospital protocols that people do not consistently read, find, or consult.

For years I had asked our web developers about a private, searchable part of paolivet.com where staff could find those documents. The project sounded difficult, so the idea was discussed, revisited, and eventually dropped.

While building veTriage, that old idea stopped feeling distant.

With every successful output, I could see other ideas becoming real in the not-too-distant future.

The first product was the app. Another output was confidence.

The project changed what I think may still be possible

For years, Dr. Rowan and I have sometimes reached the same point after another failed attempt to change a hospital workflow: this is why we have to retire. After thirty years, it can be hard to imagine that a stubborn problem will ever move.

veTriage did not solve every problem of hospital management. But it showed me a path to progress that I had not seen before.

Instead of thinking only about retiring, I am thinking about what I may still be able to contribute.

A week ago, I was building a triage app. Now I am reflecting on what it taught me about implementation, expertise, and optimism.

That may be the most important result of Build Week.

A beautiful chain

The image that kept returning to me was a beautiful chain. At first, I thought it described only the chain of care:

sick pet → worried owner → receptionist → scheduling or medical review → technician and/or veterinarian → plan → owner follows the plan → follow-up → pet receives care

As the week unfolded, I began to see another chain:

An idea became a conversation. The conversation became a specification. Codex turned it into software. Sites gave it a place to live. Staff use produced feedback. Feedback produced a safer product. The working product made the next idea feel possible.

The end of one link became the beginning of another.

The software is not the hero of either chain. The people are.

The purpose is not to remove human judgment. It is to make sure no one in the chain has to carry the whole burden alone.

What's next for veTriage

veTriage is still a newborn application.

The next phase is continued use, disciplined reassessment, and clinical validation. The team will continue identifying confusing wording, missing choices, unnecessary steps, false RED results, missed urgency, and routes that create more burden than they remove.

The development cycle will remain deliberate:

  1. staff use the application in real workflows;
  2. feedback and safety concerns are documented;
  3. I review what should change and why;
  4. clinical, operational, and design rules are revised;
  5. Codex implements and tests the update; and
  6. the new version returns to staff for reassessment.

Future product work may include:

  • additional complaint pathways where evidence and workflow justify them;
  • a larger clinical test library;
  • formal change control and audit reporting;
  • improved integration with IDEXX Cornerstone and telephone workflows;
  • configurable hospital-specific rules; and
  • a version that other veterinary hospitals can evaluate and adapt.

Every veterinary hospital receives calls from worried owners whose pets may or may not be able to wait. Each hospital has different capacity, authority, and callback rules, but the underlying problem is universal: collect the right information, preserve the medical urgency, involve the right person, communicate clearly, and document what happened.

I also intend to explore the searchable protocol and training platform I discussed with Chelsie on the first day. Paoli Vetcare has spent years writing excellent protocols. The next challenge is making that knowledge easy to find and use at the moment someone needs it.

The early receptionist feedback also suggests that veTriage may have value as an onboarding and training tool for people who are new to veterinary medicine, something we plan to evaluate deliberately as use continues.

What will not change is the central safety principle: generative AI may help us improve the product, but live clinical routing will remain deterministic, versioned, reviewable, and subject to veterinarian authority.

I did not build veTriage for a competition. I built it because our hospital needed help.

The competition happened to give me a reason to stop, document the week, and share what happened.

What I hope other people see is not simply that a veterinarian built an app. I hope they see what may now be possible when the people who understand a problem best can help build the solution themselves.

Look what's possible.

Built at Paoli Vetcare, with gratitude

veTriage was conceived, designed, tested, and refined inside Paoli Vetcare, the AAHA-accredited veterinary hospital where the problem it addresses is part of daily life.

I led the project by drawing on decades of veterinary medicine, hospital operations, staff training, workflow design, and practice management. But veTriage could not have become this application without the people who strengthened every link in the chain.

  • Dr. Jay Rowan, VMD, my husband and partner in this life and work, for decades of compassionate care for pets and the people who love them; and for contributing the clinical judgment, escalation thresholds, callback expectations, delegation rules, and practical constraints that shaped the system. One of my deepest motivations was to help place a more complete history in his hands so he could act safely and quickly without having to reconstruct every case from the beginning.

  • Chelsie Reeves, our practice manager, for consistently going above and beyond; for operational review, safety feedback, and determined testing; and especially for identifying the all-RED defect that led us to redesign one of the most important parts of the application.

  • Courtney Price, our lead receptionist, for handling the pressure of a busy veterinary hospital with poise and warmth; for testing the application during real reception work; and for showing us where questions, navigation, and handoffs needed to become clearer and more useful.

  • The entire Paoli Vetcare team, receptionists, veterinary assistants, technicians, kennel assistants, and veterinarians—for helping to make Paoli Vetcare what it is today; for the care, dedication, and professionalism they bring every day; for being willing to use a new tool that was still evolving; and for documenting problems honestly enough that we could make it better.

  • The veterinary practice manager, who generously shared a reception triage flowchart with the Veterinary Hospital Managers Association (VHMA) community, which I first encountered on May 15, 2026: Your willingness to share your work openly sparked the conversations that ultimately led to veTriage. Chelsie immediately recognized its potential, and together we began adapting the concept to fit our hospital. Over time, that initial inspiration evolved into our four-color triage system, a Custom GPT, and ultimately veTriage. One day, I hope to identify you so I can thank you by name.

  • My sons, Keefer Rowan, PhD, and Conor Rowan, PhD candidate, have also inspired me through their curiosity, intellect, and willingness to pursue difficult problems. Following their work and interests helped draw me more deeply into developments in mathematics, artificial intelligence, engineering, music, and scientific research—and helped me remain curious enough to ask whether an idea that once seemed impossible might now be possible.

The AI and technical collaboration included:

  • GPT-5.6, for helping me organize clinical knowledge, challenge assumptions, reason through safety and workflow, interpret staff feedback, develop the product specification, and guide me whenever I did not know what to do next;

  • OpenAI Codex, for translating those clinical and product decisions into working software, automated tests, source-code revisions, and deployable updates;

  • ChatGPT Sites, for removing the separate hosting and deployment barrier and giving the staff a live application they could begin using immediately; and

  • GPT-3.5 and the generations that followed, which I began using as soon as they became publicly available, for the longer arc of work that prepared me to attempt this project—from documentation for our 2023 AAHA inspection to medical research, human resources, operations, and eventually software development.

I am especially grateful to the staff members who were willing to say when something did not make sense. Their feedback did not slow the project down. It made the application safer, more useful, and more worthy of their trust.

Built With

Share this project:

Updates

posted an update —

Post-submission update: Expanded the acknowledgments to recognize the entire Paoli Vetcare team—including our kennel assistants and veterinary assistants—whose feedback and willingness to test an evolving application helped make veTriage safer and more useful. No project functionality, technical implementation, or submission content was changed.

Log in or sign up for Devpost to join the conversation.