GLP Preclinical Toxicology Study Software: Why In-Life Data, Pathology and the Final Report Never Line Up

Why the study record fractures before the report is written

A 90 day repeat dose study in rats generates body weights twice a week, food consumption, twice daily clinical observations, dosing records, clinical pathology from two bleeds, organ weights, macroscopic findings at necropsy and histopathology across forty tissues per animal. On a badly organised study, those arrive in six different places: a validated system for in-life, a haematology analyser export, a clinical chemistry export, a pathologist's own scoring spreadsheet, a Word document of the protocol with three amendments appended, and a shared drive folder of scanned deviation forms.

The Study Director signs a statement that the report reflects the raw data. That signature is the product. Everything the software does exists to make that signature defensible when a monitoring authority arrives and asks to reconstruct one animal's history from dosing to slide. Under 21 CFR Part 58 and the OECD principles of good laboratory practice, a study that cannot be reconstructed has to be repeated, and repeating a chronic study is not a software cost, it is a year and a large fraction of a programme budget.

The fracture is almost never in one system. It is in the joins between them, and the joins are people with spreadsheets.

What Provantis, Pristima and LabWare actually leave uncovered

Instem Provantis and Xybion Pristima are the two products that genuinely own this space, and they earned it. Both model study design, in-life collection, pathology and report tables, and both have long regulatory track records. LabWare is a strong LIMS and covers analytical and clinical pathology work properly. If your studies fit their study design model, buying is the correct decision and we will tell you so.

Three things reliably push organisations off them. The first is study design variety. Dose escalation with interim decision points, satellite toxicokinetic groups with staggered bleed schedules, recovery groups, juvenile and reproductive designs, large animal studies with individual handling, and device studies with implantation timepoints all stretch a fixed design model. Configuring an unusual design becomes a vendor change request with a quotation and a lead time, and the study starts before the configuration lands, so the data goes into Excel.

The second is instrument and imaging integration on a modern stack. A digital pathology scanner, a telemetry system, an ophthalmology imaging device or a plate reader that arrived after your legacy system was configured is an integration project priced per interface. Contract organisations feel this hardest because each sponsor brings a different expectation.

The third is cost shape. Licensing that made sense for a large pharmaceutical toxicology department is punishing for a mid size contract research organisation running many small studies, and it scales with seats rather than with the value of the study.

Paper to keyboard is where audit trails actually fail

The finding that hurts is rarely a wrong result. It is an untraceable one. A technician records body weights on a paper form at the balance, and the form is transcribed at a workstation an hour later. Now there are two records, and only one of them is raw data. If the paper says 312 and the system says 342, the study has a problem that no amount of downstream statistics fixes.

A custom build closes this by capturing at the point of collection and never allowing a second version to exist. In practice that means tablets or fixed terminals in the animal room that work when the network does not, balances connected directly so the weight is read rather than typed, barcode identification of the animal at the moment of capture, and a record that is 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.

The engineering that matters here is offline behaviour. A barrier room with poor wireless coverage is normal, and a system that stops working during a dosing round will be abandoned within a week. Local storage with conflict aware synchronisation is not a nice to have in this domain, it is the difference between adoption and a drawer full of paper forms.

Pathology and peer review are their own problem

Macroscopic and microscopic findings are graded observations, and grading is a judgement that has to be traceable to the pathologist who made it. The peer review process, where a second pathologist reviews a proportion of slides and any disagreement is documented and resolved, is a workflow with its own record requirements, and it is the part most generic systems skip entirely. Terminology matters too: findings should be recorded against a controlled vocabulary rather than free text, because free text makes incidence tables impossible to compute and impossible to compare across studies.

Digital pathology changes the shape of this. When slides are scanned, the finding should link to the image and ideally to the region of interest, so that a reviewer or an inspector can see what the pathologist saw. Legacy toxicology systems predate whole slide imaging and treat images as attachments if they handle them at all.

SEND and report assembly are the deadline you actually miss

Nonclinical study data submitted to the FDA has to arrive in the Standard for Exchange of Nonclinical Data format, and producing that from a study that was assembled across six sources is where programmes lose weeks. The honest position is that SEND is not hard when the underlying data was captured in a structured way from the start, and it is miserable when it is retrofitted from spreadsheets and a Word report.

A custom build should generate the datasets from the same records that produced the report tables, so the two cannot disagree. Report assembly follows the same principle: tables, figures and listings are produced from the database with the statistical methods declared in the protocol, and the narrative is written around them rather than the numbers being pasted in. When an amendment or a reissued table changes a number, everything downstream regenerates, and the version history shows what changed and why.

What a custom build must include

• Study design as data: groups, doses, routes, schedules, satellites, recovery and interim timepoints, with a protocol amendment history that reissues the schedule.
• Point of collection capture that works offline, with balance and instrument connections and barcode animal identification.
• Write once records with reason coded corrections, full user and timestamp attribution, and electronic signature under 21 CFR Part 11.
• Deviation capture at the moment it happens, linked to the animal, the task and the study, rather than a form scanned later.
• Clinical pathology and analytical results imported directly from analysers with instrument run metadata.
• Pathology with controlled terminology, severity grading, peer review workflow and links to scanned slides.
• Statistics and report tables generated from the database, with regeneration on data change.
• SEND dataset generation from the same source records, with validation before submission.
• Quality assurance unit views: inspection scheduling, findings, and the audit trail they will actually read.

What it costs and how long it takes

Across the projects Digital Heroes has delivered in regulated study capture, a first release covering study design, in-life scheduling and observation capture with a compliant audit trail runs $90,000 to $180,000 and ships in 16 to 22 weeks. A full platform through pathology, peer review, statistics, report assembly and SEND runs $250,000 to $600,000 phased over 10 to 18 months.

What drives the number up here specifically: computer system validation, which is a real workstream with its own documentation and testing effort and typically adds twenty to thirty percent to a regulated build rather than being absorbed into it. The number of instrument interfaces, because each analyser model is its own protocol and its own quirks. Multiple species with genuinely different in-life procedures. Multi site operation where a sponsor audit can land at any one of them. Digital pathology integration. And legacy migration, which in this domain means deciding honestly which historical studies need to be in the new system and which stay archived where they are.

What keeps it down: a first release scoped to one study type you run repeatedly, one species, and the instruments already on your floor.

Build versus buy, stated plainly

Buy Provantis or 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 we can build, and pretending otherwise would be dishonest.

Build when two or more of these are true. Your study designs regularly fall outside the vendor's model and you are waiting on configuration change requests while studies run in Excel. You are a contract organisation whose sponsors each want different report formats and different data deliverables. Your instrument and imaging stack has moved on and integration quotes keep arriving. Your licence cost scales with headcount in a way that penalises growth. Or you have made the strategic decision that study data is an asset you want to own and query across a portfolio, which no per study export will ever give you.

How to choose a developer for GLP study software

Ask them 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. This is the single fastest disqualifier.

Ask how they handle validation. A credible answer covers requirements traceability, installation and operational qualification, test evidence, and a change control process that survives after go live. A developer who treats validation as paperwork you can do later has never been through an inspection.

Ask about offline capture in an animal room, and about which balances and analysers they have actually connected. Named models, named protocols. Serial, network and vendor middleware are three different problems.

Ask who owns the code and get it in writing before kickoff. You should hold the repository, the infrastructure accounts and the right to hire anyone else to continue the work. At Digital Heroes the code is yours from the first commit, and in a validated environment that ownership also means you own the validation evidence, which is the part that is expensive to recreate.