Vivarium Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the census scope get underestimated so often?

Almost every vivarium project starts with a requirement that reads like inventory: track cages, track animals, show a count. That framing is the failure, because a box of screws does not breed, get weaned, get genotyped, get transferred to another protocol, or die overnight. The objects change identity while you are holding them, and three separate obligations attach to the same cage at the same moment: welfare and regulatory compliance, financial chargeback to a specific fund, and scientific traceability for the study.

The practical consequence is that a stored census can never be corrected honestly. A technician finds seven animals in a cage carded for five. Somebody edits the number. Now the count is right today and every past day is silently wrong, which matters because past census is exactly what defends a past invoice when a principal investigator queries it eight months later.

This is specific to animal facilities because your billing, your compliance reporting and your science all read the same record at different times and want different views of it. A per diem run wants cage days in a closed month. An annual report wants cumulative animals used. A veterinary review wants animals currently alive on a protocol. One stored number cannot serve three questions.

The fix is to make the event the durable object: birth, wean, transfer, import, death, cage change, each with a date and a person. Census on any date, past or present, becomes a query rather than a stored figure, and corrections are new events rather than overwrites. This single decision determines whether the system can defend an invoice or an inspection finding, and it is the thing most cheap builds get wrong.

What goes wrong when you migrate colony and pedigree data?

Data migration in this category is not a row copy, it is an audit. The three things that reliably break are strain nomenclature, protocol assignment and litter lineage, and all three break because they were never enforced in the system you are leaving.

Strain nomenclature drifts because it lives as free text in a colony spreadsheet, so the same line appears three ways within a year and nobody can tell whether two records are the same genotype. Protocol assignment is worse: a surprising number of live animals in most facilities have no recorded protocol at all, because they were held on a breeding protocol, moved, and the move was an email. Litter lineage breaks where weanings were recorded as a count rather than as animals, which means pedigree cannot be reconstructed backwards no matter how good the new system is.

The specific risk is billing history. If you migrate current census but not dated events, you cannot reproduce any invoice you sent before cutover, and the first investigator query after go live becomes an argument you cannot win.

The fix has three parts. Import dated events rather than current state wherever the source has them. Treat nomenclature cleanup as a funded workstream with a scientist involved, not as a developer task. And run both systems in parallel for one complete billing cycle, reconciling the invoice line by line before cutover.

Why do the integrations that matter here break after launch?

Four integrations decide whether the system is used, and they fail in different ways.

Cage card printing is the one your technicians touch every day, and it is the one most often treated as trivial. It is your printers, your card stock, your barcode symbology, your required fields, and a room where gloves have sanitiser on them. If cards print slowly, print wrong, or scan unreliably at the rack, the floor reverts to paper within a fortnight and everything downstream is stale again.

The general ledger export breaks because finance owns the format and finance changes it. A fund and account string that was correct in June is rejected in July after a chart of accounts change nobody told you about, and the journal entry bounces silently. That needs a validation step and a named owner in finance, not a nightly job that assumes success.

Protocol management integration breaks because approved numbers change through amendments, and amendment approval happens in a system with its own release cycle. If the interface is a one-time import, your live limits go stale the first time a protocol is amended.

Genotyping result files break because the core or vendor changes a column heading. Build the import with an explicit mapping the facility can edit and a rejection queue, rather than a parser that assumes a fixed layout.

What happens when the IACUC animal limit is not enforced live?

Exceeding an approved animal number is a reportable matter, and it almost never happens through a deliberate decision. It happens through breeding. A productive colony pushes the cumulative count past the ceiling weeks before anyone runs a report, and by the time it surfaces at a semiannual review or during annual report assembly, the animals exist. The conversation with the committee is then about a violation rather than an amendment, which is an entirely different conversation.

Systems that hold approved numbers as a document rather than a constraint cannot prevent this, and neither can a monthly report, because the overage happens between reports. The other half of the problem is definitional: different reporting contexts want different denominators, so a system that tracks only animals currently alive cannot answer a cumulative-use question, and one that tracks only cumulative use cannot tell a veterinarian who is on the protocol today.

The fix is to make the approved number a live counter that every event writes against as it happens, with warning thresholds set by you, commonly around eighty percent of approved, and with the warning going to the investigator and the veterinary staff at the same time so an amendment gets filed while it is still an amendment. The model has to handle animals held on a breeding protocol before study assignment, transfers between protocols, and both denominators separately. Regulatory obligations here sit under the Animal Welfare Act and the Public Health Service Policy, and your institutional official will define exactly what gets reported. The engineering obligation is simply that the number is never a surprise.

Should you build custom or configure what you already own?

If you run under roughly two thousand cages, one species, one building, and bill a small number of internal accounts, buy. RockStep Climb handles rodent colony structure, matings and genotypes well, and tick@lab covers census, ordering and health reporting across a multi species facility at genuine scale. Topaz Technologies has been in animal facilities a long time and knows the domain properly. At that size the annual licence is far cheaper than a build and none of the edges that justify building will hurt you yet.

The same answer applies if your finance office is content to receive a spreadsheet and upload it. The integration work that carries most of the return on a build has no payoff if nobody downstream wants the output.

Build when your per diem rate structure has exceptions no vendor billing module expresses and somebody spends days a month correcting invoices, when you run several species or several buildings under different governance, when you have already been cited or nearly cited on an animal number and know the census is not trustworthy, when genotype and pedigree data lives in a lab spreadsheet disconnected from census, or when your current vendor will not integrate with the protocol management platform your institution just bought. That last trigger is the most common one we see.

How do hidden costs get into the quote?

Species count is the first and largest. Non-human primates, large animals and aquatics are not rodents with a different label; they carry different husbandry records, different reporting and in some cases different identification. A proposal that prices multi species as a configuration flag has not read the reporting requirements.

Rate policy discovery is the second, and it is nearly always missing. Most facilities discover during requirements work that their per diem rules exist only as the billing coordinator's practice and have never been written down, so the analysis that should have taken a week takes three. Arriving with a documented rate table, a current cage card specification and a list of the reports you actually send today is the single best thing a facility can do for its own schedule.

Hardware is the third: cage card printers, rack readers, and any individual animal tagging by barcode or radio frequency identification. The fourth is multiple buildings or institutions on one system, since rate tables and committee governance then differ per site. The fifth is integration with an existing protocol management platform, which is a genuine interface project depending on a third party's calendar.

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

Ask the developer to draw the data model before you sign anything. A team that has done this separates cage, animal, protocol assignment and event, and explains without prompting why census must be derived from dated events rather than stored as a running number. A team that draws animals and locations has built an asset tracker and is about to learn animal science on your budget and your committee's timeline.

Ask specifically how per diem is computed and how a correction to a closed month is handled. If the answer does not include effective dated rates and a restatement path that leaves an audit trail, your finance office will reject the output in month two and you will be back on spreadsheets with extra steps.

Ask what they have integrated by name. A protocol management system, a general ledger, a genotyping vendor result file and a cage card printer are four different classes of problem, and only one of them is a web service. Ask what happened when the print job was slow, because everyone who has shipped this has that story.

Then settle ownership in writing before kickoff: the repository, the infrastructure accounts, and the unrestricted right to hire another firm to continue the work. At Digital Heroes the client owns the code from the first commit. This matters more than usual in a vivarium, because the system runs your billing and holds the record you will be asked about during an inspection, and neither of those should sit behind a supplier's cooperation.