Preclinical Toxicology Study Software Problems: The 5 That Force a Repeat Study, and How to Avoid Them

Why does scoping every study design at once stall the build?

Organisations leave a packaged system because their study designs do not fit its model, and that produces a natural reaction when scoping a custom build: cover everything, so it never happens again. Dose escalation with interim decision points, satellite groups with staggered bleeds, recovery cohorts, juvenile and reproductive designs, device studies with implantation timepoints, three species and four analysers, all in release one.

That scope does not ship. Study design discovery turns out to be the slow part, because the real rules for a satellite group or a recovery cohort often exist only in a study director's practice rather than in any document. Eliciting that across six design families at once produces months of workshops, contradictory answers from different directors, and a specification nobody will sign.

Then validation lands on top. It is a real workstream with its own documentation and testing effort, and it scales with the surface area you built, so a wide first release means a wide validation package before anything can be used on a real study.

The sequencing that works: one study type you run repeatedly, one species, and the instruments already on your floor. Get that validated and running live studies, then extend. The extension is far cheaper because the audit trail design, the offline capture behaviour and the validation approach are already proven. Groups that arrive with documented standard designs and a current instrument inventory move noticeably faster.

What goes wrong between paper, keyboard and legacy studies?

Transcription is where audit trails actually fail, and it survives in most facilities because it is invisible until an inspection. A value written on a form and typed in later means the raw data is the form, the system holds a copy, and every reconciliation between them is a finding waiting to be made. The same applies wherever a technician reads a display and types the number, since a typed weight is a transcription whether or not paper was involved.

The second half is legacy migration, where the honest answer is usually less than people expect. Historical data was captured under a different system's rules, with a different audit trail and a different definition of raw. Importing it creates records that look native but cannot be reconstructed to the same standard.

What works: capture at the point of collection and never allow a second version to exist. Balances connected directly so the weight is read rather than typed, barcode identification of the animal at the moment of capture, and a record written once with the user, timestamp and instrument attached. Corrections are new records with a reason, never edits. Range checks fire while the technician is still standing at the cage, which is the only moment a re weigh is possible. For history, decide deliberately and in writing which studies need to be in the new system, migrate those with their provenance clearly marked as migrated, and leave the rest archived under their original controls.

Why do balance and analyser integrations break after launch?

Because each instrument is a separate product with its own vendor, its own update cycle and its own idea of an interface, and none of them is aware that a study depends on the connection.

A haematology analyser gets a software update during a service visit and the export format gains a column. A balance is replaced with a newer model that speaks a different serial protocol. Vendor middleware is upgraded and the file drop location changes. None of these is unusual and all of them can stop data reaching the study record, usually on the morning of a scheduled collection.

The defensive pattern is the same in every case. Treat each instrument model as its own versioned adapter, with the raw output retained exactly as produced alongside the parsed result so a format change is diagnosable rather than debatable. Validate values and units at the boundary and quarantine anything that fails. Include run metadata with every result so a later question about which analyser and which calibration produced a value has an answer. And ask any developer which balances and analysers they have connected, by named model and protocol, because serial, network and vendor middleware are three different problems.

What happens when deviations, peer review and SEND are not covered?

All three get deferred because they sit after the visible work of collecting data, and all three are where the study record either holds together or does not.

Deviations captured on a paper form and scanned later are the classic gap. The deviation happened at a moment, involved a specific animal and a specific task, and belongs linked to both. A folder of scans cannot answer the question an inspector asks, which is what happened to this animal on this day and what was decided about it.

Pathology peer review is the part most generic systems skip entirely. A second pathologist reviews a proportion of slides, disagreements are documented and resolved, and that whole process has record requirements of its own. Alongside it, findings recorded as free text rather than against a controlled vocabulary make incidence tables impossible to compute and impossible to compare across studies, which quietly removes the analytical value of your own historical control data.

The third is the format for exchanging nonclinical data with the FDA. It is straightforward when the underlying data was captured in a structured way from the start, and miserable when it is retrofitted from spreadsheets and a Word report. Generate the datasets from the same records that produced the report tables, so the two cannot disagree, and validate the output before submission rather than after.

What to build: deviation capture at the moment it happens, linked to animal, task and study; peer review as a workflow with recorded selection, independent grading, documented disagreement and attributed resolution against controlled terminology; and report tables plus submission datasets generated from the database, regenerating together when an amendment changes a number.

Should you build custom or configure what you already own?

Buy Instem Provantis or Xybion Pristima if your study designs are conventional, your volume is modest and your instrument stack is one those vendors already support. You will get a validated system faster and cheaper than anything a custom build produces. Both model study design, in life collection, pathology and report tables, and both have long regulatory track records. If you run a handful of studies a year on one standard design, that is the answer and we would say so on the first call.

LabWare is a strong laboratory information management system and covers analytical and clinical pathology work properly. If your problem is genuinely the analytical laboratory rather than the study record, configure that instead.

Build when two or more of these hold. Your study designs regularly fall outside the vendor's model and studies start before a configuration change request lands, so the data goes into Excel. You are a contract organisation whose sponsors each want different report formats and data deliverables. Your instrument and imaging stack has moved on and integration quotes keep arriving per interface. Licence cost scales with seats in a way that penalises growth. Or study data is an asset you want to query across a portfolio, which no per study export will give you.

The practical test is simple and uncomfortable: how many studies a year do you run in a spreadsheet because configuration was not ready in time.

How do hidden costs get into the quote?

Five items, and the first is the one people argue about until they have been through an inspection.

• Computer system validation. Requirements traceability, installation and operational qualification, executed test evidence and change control that survives go live. In our experience this typically adds twenty to thirty percent to a regulated build, and a quote that does not name it separately has not accounted for it.
• Instrument interfaces, priced individually. Each analyser model is its own protocol with its own quirks. Counting instruments predicts cost better than counting features.
• Species and site multiples. Different species mean genuinely different in life procedures, not a configuration flag, and multi site operation means a sponsor audit can land anywhere.
• Digital pathology. Whole slide imaging changes storage, transfer and viewing requirements substantially, and treating images as attachments will not survive a real study.
• Revalidation on change. Every meaningful change after go live carries an impact assessment and possibly re execution. Budgeting for it is what keeps the system current rather than frozen.

What separates a GLP study build that works from one that fails?

Four things, and the first is a conversation you can have before signing anything.

Ask a prospective developer what raw data means and listen carefully. If they cannot explain why a transcribed value is not raw data, and why corrections must be new records rather than edits, they do not understand what they are being asked to build. It is the fastest disqualifier available in this category.

The second is offline behaviour in the animal room. A barrier facility with poor wireless coverage is normal, and a system that stops working during a dosing round will be abandoned within a week and replaced by paper. Local storage with conflict aware synchronisation is the difference between adoption and a drawer full of forms, and it has to be designed rather than added.

The third is controlled terminology from the start. Findings recorded against a controlled vocabulary make incidence tables computable and studies comparable. Free text does not, and converting years of free text later is expensive and imperfect. Link findings to scanned slides where digital pathology exists, so a reviewer or an inspector sees what the pathologist saw.

The fourth is generating report tables and submission datasets from the same records, with regeneration when an amendment changes a number and a version history showing what changed. Numbers pasted between systems will eventually disagree, and the disagreement will be found by somebody outside your organisation.

Then settle ownership in writing before kickoff: the repository, the infrastructure accounts and the validation package. At Digital Heroes the client owns the code from the first commit. In a regulated build the validation evidence matters as much as the source, because recreating qualification documentation for a system you cannot modify is expensive and slow.