Laboratory Animal Facility Software Problems: The 7 That Cost You a Defensible Census, and How to Avoid Them

Why does the whole facility in one release keep failing?

The scoping meeting includes the facility director, the attending veterinarian, the institutional animal care and use committee office and finance, and every one of them has a genuine pain. So release one is scoped to cover census, breeding colonies, genotyping, health surveillance, quarantine, treatment records, cage cards, per diem billing and United States Department of Agriculture reporting, across rodents and the aquatics facility. Nine months later there is a demonstration environment and the technicians are still writing on cage cards.

What makes this specific to a vivarium is that species classes are effectively different systems. An aquatic facility running zebrafish has a tank and system based housing model, different density rules and different husbandry events. A rodent facility has cages, racks and a breeding pedigree. A build that does both properly is two builds sharing a login, and pretending otherwise is the single most common reason these projects overrun.

Sequence by the data problem rather than by the department. Release one is event based census with barcode scanning at the rack, protocol allocation tracking with threshold warnings, and per diem charge generation with account validation, for one species class. That single foundation resolves billing disputes, allocation warnings and the containment query at the same time, because all three are the same underlying data problem. Colonies, health surveillance, treatment records and reporting build on top of it.

What goes wrong when you migrate census, colony and billing history?

Census migration fails on the same assumption every time: that the current cage list is accurate. It is a snapshot maintained under time pressure by people whose priority is animal welfare, not data entry. Cages have been weaned out without the record catching up, animals have been transferred between protocols verbally, and occupancy is an estimate on any rack that has not been walked recently.

Load it as is and the first month of per diem charges is wrong in a way that is impossible to defend, because you have no event history to explain any of it. That is the worst possible first impression to make on principal investigators whose grant accounts are being charged, and it is very hard to recover from.

Do a counted opening census instead. Walk the rooms, scan or record every cage, and treat that count as the founding event of the system with a date attached. It is a few days of technician time and it makes every subsequent charge traceable to a starting point everybody agreed.

Pedigree migration is the second trap. Breeding records in a colony tool carry generations of relationships, and partial imports break the lineage in ways that surface later when a lab cannot trace a line back to its founder. Import complete lines or leave them where they are. Historic per diem charges are the third and should generally not migrate at all, because recomputing past charges under new rules invites disputes about periods that were already settled. Keep them as a read only archive.

Why do the protocol, finance and hardware integrations break after launch?

The protocol system integration matters most because approved animal numbers must come from there rather than being retyped. It breaks when a protocol is amended and the approved number changes without the facility system hearing about it, which means allocation warnings fire against a stale limit. Sometimes that means unnecessary alarm. Sometimes it means silence when there should be a warning, which is the bad direction.

Finance breaks on account periods. A per diem charge landing on an expired award becomes a cost transfer, and cost transfers on federal awards attract attention nobody wants. The integration therefore has to validate the account's period and status before posting rather than after, and it has to handle the case where an account closes mid month.

Hardware is the third and it is underestimated with remarkable consistency. Cage card printers, label stock and scanners are a real integration, not an accessory. Labels have to survive cage wash and humidity, layouts vary by protocol, and printers have to sit where technicians actually work rather than where there happens to be a network point.

Fix the first two with scheduled reconciliation and named exception owners: any protocol whose approved number differs between systems, any account that fails validation. Fix the third by specifying existing printers, label stock and scanner models during discovery, and by testing a printed card through an actual cage wash cycle before go live rather than after.

What happens when counting policy and movement history are not covered?

Two gaps produce regulatory consequences rather than inconvenience. The first is the counting policy against approved numbers. A protocol approves a number of animals, sometimes broken down by species, strain and pain category. The facility operates in cages. Whether breeders count against the same allocation, whether weanlings count when produced or when used, and how animals transferred between protocols are counted are all decisions with more than one defensible answer, and they are your committee's decisions rather than a software default.

Systems that leave this implicit produce a total that is an accident of how the code adds things up. When that total is wrong in the permissive direction, the first sign is a technician counting a rack and finding six hundred animals on a protocol approved for four hundred. That is a deviation, it goes to the committee, it appears in the semiannual programme review, and during an accreditation visit it becomes a finding about institutional oversight rather than about one laboratory's arithmetic.

The second gap is movement history, which is the failure named at the top of this page. Every cage and animal needs an append only movement record so a containment query returns the exposure set with dates in seconds. Health status has to be an attribute of a room and a rack with an effective period, so the system can answer what the status was in March rather than only what it is now.

Both belong in the first release. The counting policy must be explicit, versioned configuration with the rationale recorded, and it should warn at a threshold you set, such as eighty percent of an allocation, so a protocol amendment can be filed while there is still time. Movement history cannot be retrofitted, because history you did not record does not exist.

Should you build custom or configure what you already own?

Do not build if you are under roughly fifteen hundred 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. We say that on first calls regularly.

SoftMouse and RockStep Climb are also genuinely good at the colony and pedigree side, which is where the enterprise facility systems are weakest. If your only real pain is colony management, adding a colony tool beside your existing facility system is cheaper than replacing anything. a-tune tick@lab and Topaz Elements do real work on census and billing, and if your rate structure and cage cards fit what they already do, keep them.

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

How do hidden costs get into the quote?

Species classes are the largest multiplier and the most frequently glossed over. Ask explicitly whether aquatics are in the quoted number, and what the housing model is for them, because tanks and recirculating systems are not cages with a different label.

Second, cage cards and barcode hardware, which sounds trivial and is not once you have per protocol layouts, label stock constraints and printers positioned around a wash cycle. Third, the counting policy itself, which is not engineering at all: if your institution has not written it down, agreeing it is a governance exercise involving your committee and it takes weeks of calendar time regardless of how fast anyone codes.

Fourth, integration with the protocol system, and fifth, integration with the finance system for per diem posting. Ask what is included per additional species class and per additional integration, and ask whether the quote assumes your counting policy already exists in writing.

What separates a build that works from one that fails here?

Ask how they model an animal, a cage and a location over time. If they draw a cage record with a current room field, both containment queries and per diem disputes will be unanswerable, because both need history rather than current state. That single question predicts more about the outcome than anything else in the proposal.

Then ask how the counting policy 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 against an approved number has not spoken to two committees.

The builds that work make capture fast enough to survive a real vivarium. A technician scanning a cage card during a room walk creates a verified census event in about two seconds, and anything slower gets skipped on a busy morning. They generate charges from the event stream rather than from a nightly snapshot, so a disputed charge is answered by showing events rather than by arguing. The builds that fail are careful, complete and slow to use, so the technicians keep a paper list, the paper list becomes the real record, and the facility ends up paying for a system that documents a process nobody follows.