Laboratory Animal Facility Software: Census, Breeding Colonies and Per Diem Billing That Match the Approved Protocol

Why a vivarium census number is a compliance statement, not an inventory count

A veterinary technician is doing a Tuesday walk through a mouse room and notices a rack that does not look right. The protocol on the cage cards was approved for 400 animals. She counts the cages, multiplies by average occupancy, and gets something close to 600. The lab has been breeding productively and nobody was watching the total. That is a protocol deviation. It has to be reported to the IACUC, it will be in the semiannual program review, and if the facility is preparing for an AAALAC site visit it becomes a finding about the adequacy of the institution's oversight rather than about one lab's arithmetic.

This is the defining property of vivarium software. In almost every other operation, an inventory number that is slightly off is an accounting nuisance. Here the number is a regulatory statement. Approved animal numbers on an IACUC protocol are a limit, USDA reporting under the Animal Welfare Act is done by pain category with counts, and the Guide sets expectations about housing density that turn a cage count into a welfare question.

The products in this space are a-tune tick@lab, Topaz Elements, RockStep Climb and SoftMouse. tick@lab and Topaz are the enterprise options and both do real work on census and billing. Climb is strong on the colony and research data side. SoftMouse serves individual labs well. What none of them arrive knowing is your institution: your per diem rate structure and how it maps to your chart of accounts, your cage card format and the barcode hardware you already bought, your housing standards by species and strain, and the specific way your IACUC counts animals against approved numbers, which is a question with more than one defensible answer.

Problem 1: the protocol counts animals, the facility counts cages, and nothing reconciles them

An IACUC protocol approves a number of animals for a period, sometimes broken down by species, strain and pain category. The facility operates in cages. A cage holds a variable number of animals. Weanlings become experimental animals. Breeders may or may not count against the same allocation depending on your institution's policy. Animals transferred between protocols have to be counted somewhere and not twice.

What a custom build does: make animals and cages separate objects with a housing relationship over time, so a cage record is a container with an occupancy history rather than a number. Then make the counting policy explicit configuration rather than an implicit consequence of how the software adds things up, with the policy documented in the system and versioned when your IACUC revises it. The running total against approved numbers appears on the protocol, on the PI's dashboard and on the facility director's, and it warns at a threshold you set rather than at the moment of breach. Approaching 80 percent of an approved allocation should generate a conversation about a protocol amendment while there is still time to file one.

Problem 2: breeding colonies produce animals faster than anyone plans for them

A transgenic colony is not a fixed population. It is a pedigree with breeding pairs, litters, weaning events, genotyping results that determine which animals are useful, and a steady stream of animals that are the wrong genotype and need a disposition decision. A lab maintaining several lines can produce hundreds of animals a month, most of which never enter an experiment.

This is where SoftMouse and Climb are genuinely good, and where the enterprise facility systems are weaker, because facility systems are built around the room and the cage while colony management is built around the pedigree. Most institutions end up with both, which means the colony data and the census data live in different places and the facility does not know what is coming.

What a custom build does: hold the pedigree and the census in one model, so a litter recorded at birth becomes projected census with a weaning date attached, and the facility can see demand three weeks out instead of discovering it at cage wash. Genotyping results attach to animals and drive disposition workflows, and the animals that are the wrong genotype get an explicit path rather than accumulating. Colony health metrics such as productivity per pair and time to weaning become visible, which is the data that lets a veterinary director have an evidence based conversation with a lab about whether a colony needs to be that large. That conversation is worth more than any efficiency the software delivers.

Problem 3: per diem billing is disputed because the record and the rack disagree

Per diem charges are generated per cage per day at a rate that varies by species, housing type and sometimes by service level. Those charges land on grant accounts. The disputes are always the same: a PI says cages were weaned out on the 3rd and the charge runs to the 15th, or a cage was transferred to another protocol and both were billed, or a census correction after a physical count moved the number retroactively and now a month of charges is wrong.

What a custom build does: make every census change an event with a timestamp, an actor and a reason, and generate charges from the event stream rather than from a nightly snapshot. Then a disputed charge is answered by showing the events, not by arguing. Barcode scanning at the rack is the operational half of this: a technician scanning a cage card during a room walk creates a verified census event in about two seconds, which is the only workload that survives contact with a real vivarium. Physical count reconciliation becomes a scheduled process that produces an adjustment with an audit trail rather than a silent correction. And critically, charges validate against the grant account's period and balance before posting, because a per diem charge landing on an expired award becomes a cost transfer, and cost transfers on federal awards attract audit attention.

Problem 4: health surveillance, quarantine and treatment are three record sets that must agree

Sentinel monitoring on a schedule, results that may trigger a room level response, incoming shipments held in quarantine with a defined release process, and veterinary treatment records for individual animals or cages. When a sentinel comes back positive for a pathogen, the question is immediate: which rooms, which racks, which animals moved between them in the last 90 days, and which labs need to be told today.

What a custom build does: keep an append only movement history for every cage and animal, so a containment query runs in seconds and returns the exposure set with dates. Health status becomes an attribute of a room and a rack with an effective period, so the system can answer what the status was in March, not just what it is now. Quarantine is a workflow with a defined release gate rather than a note on a cage card. Treatment records attach to the animal and roll up to the protocol, which matters because unexpected morbidity is reportable and the veterinary record is where the pattern shows first.

Problem 5: the USDA annual report is assembled by hand from records never built for it

The annual report to USDA APHIS requires counts of covered species by pain category, including animals used in procedures involving pain or distress where relieving drugs were withheld, with an explanation. Most facilities produce this by exporting procedure records, sorting them, and having the attending veterinarian and the IACUC office reconcile the totals against protocol approvals over several days.

What a custom build does: capture the pain category at the point the protocol is approved and at the point the procedure is recorded, so the report is a query rather than a reconstruction. Where an animal was used in procedures across categories, the counting rule is explicit and applied consistently rather than decided each year. The report generates with a drill down to the underlying records, which is what makes it defensible when an inspector asks how a number was derived. The same structured procedure data supports the semiannual program review and the IACUC's own reporting, which is the second largest manual reporting burden in the facility.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this is the honest shape for a vivarium platform. A first release covering cage and animal census with event based history, barcode scanning at the rack, protocol allocation tracking with threshold warnings and per diem charge generation with account validation runs $70,000 to $150,000 and ships in 12 to 18 weeks. A full platform adding breeding colony and pedigree management, genotyping workflows, health surveillance and quarantine, veterinary treatment and procedure logs, cage card printing and USDA reporting runs $180,000 to $420,000 phased over 7 to 12 months.

What drives price up specifically: the number of species, because aquatic facilities running zebrafish are a genuinely different model from rodent housing and a system that does both well is two systems. Barcode and RFID hardware decisions, plus cage card printing, which sounds trivial and is not once you have per protocol layouts and label stock constraints. Integration with the IACUC protocol system, since the approved numbers must come from there rather than being retyped. Integration with the finance ERP (Enterprise Resource Planning) for per diem posting. And whether your institution's animal counting policy is written down, because if it is not, agreeing it is a governance exercise involving your IACUC and it takes weeks of calendar time.

Build versus buy, and when buying is the right call

Buy, and do not call us, if you are under roughly 1,500 cages, single species, with no breeding colonies and per diem billed to a small number of accounts. SoftMouse or a modest Climb deployment will serve you, and a custom build would cost more than the problem.

Build when two or more of these are true. First, your census and your protocol approved numbers are reconciled by a person rather than computed. Second, per diem billing generates regular disputes you cannot settle from records. Third, you run breeding colonies large enough that projected census matters to cage wash and space planning. Fourth, a sentinel positive would require reconstructing movement history from paper. Fifth, you run more than one species class, particularly aquatics alongside rodents, where a single packaged product tends to serve one well and the other poorly.

Our position: the compliance value and the operational value point in the same direction here, which is unusual. Event based census with scanning at the rack fixes the billing disputes, the protocol allocation warnings and the containment query at the same time, because all three are the same underlying data problem. If a vendor demonstration does not show you movement history as a first class feature, the containment answer will be paper.

How to choose a developer for vivarium and animal facility software

Ask them how they model an animal, a cage and a location over time. If they draw a cage record with a current room field, containment queries and per diem disputes will both be unanswerable, because both need history rather than current state.

Ask how the counting policy against IACUC approved numbers will be configured, and whether it can be versioned when your committee revises it. A developer who assumes there is one obvious way to count animals has not spoken to two IACUCs.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the infrastructure accounts and the right to hire anyone else. At Digital Heroes the code is yours from the first commit. Animal welfare records support USDA inspection and AAALAC accreditation over many years, and that history should never be inside a system you cannot access on your own authority.