Bioprocess Development Data Management: How Do You Prove a 2,000 Litre Run Matches Your Scale Down Model?

Why bioprocess development data breaks at exactly the wrong moment

A process development scientist is preparing the comparability section of a tech transfer package. She needs to show that the 200 litre engineering run behaves like the ambr250 scale down model that supported process characterisation. The continuous data for the 200 litre run is a SCADA export with timestamps in local time, including a daylight saving change. The ambr data is in the system's own export with elapsed time from inoculation. Offline titer came off an HPLC three days after each run and lives in a lab spreadsheet keyed by a sample ID that only partly matches the run ID. Viable cell density came off a Vi-CELL with its own naming. She is aligning four sources by hand in Excel, and she will do it again next month for a different comparison.

The tooling around this is usually a mix: Benchling or an ELN for the experiment write up, Sartorius Umetrics for multivariate analysis and design of experiments, a historian or SCADA export for continuous data, IDBS Polar or Genedata Bioprocess if the organisation has invested, and a very large number of spreadsheets. Those products are real and some are excellent at their slice. The gap is that none of them holds a run as a single object that knows its process definition and version, its scale, its inoculum lineage, its full continuous trace on a common clock, every offline result keyed to the correct sample time, the deviations that occurred, and the design point it was executed to satisfy.

Across bioprocess projects we have delivered, the pattern is consistent. Scientists spend a third to a half of their analysis time assembling data rather than interpreting it, and the assembly is redone from scratch for every new question. The commercial exposure is not the wasted hours. It is that comparability evidence supporting a filing is reconstructed by hand, from files whose provenance depends on a folder naming convention, and the person who understands the convention is one resignation away.

Problem 1: every instrument has its own clock, its own file, and its own idea of identity

A single upstream run touches a bioreactor controller, a gas mixing system, a cell counter, a metabolite analyser, a titer method, and possibly an at line Raman or capacitance probe. Sartorius, Eppendorf, Applikon, and Thermo controllers all export differently. Analysers from Nova Biomedical, Roche, and Beckman each name samples their own way. The bioreactor logs in wall clock time. The scientist thinks in elapsed process time from inoculation. Feed initiation, temperature shift, and induction are the events everything should actually be indexed against.

Umetrics and Genedata both do serious analysis once the data is in a coherent shape. Getting it into that shape is the part that is assumed away, and it is where the hours go. Benchling holds the narrative and the sample registry well, but it was not built to carry a hundred thousand points of continuous trace per run and let you overlay twelve runs on elapsed time in under a second.

What a custom build does: define a run as the anchor object with a canonical event timeline. Ingestion connectors normalise each instrument export into typed time series bound to that run, converted to elapsed process time with the wall clock preserved underneath. Sample identity is resolved at ingestion using the mapping rules your labs actually use, and anything that does not resolve enters an exception queue rather than being silently dropped. This is unglamorous plumbing and it is the entire value of the system. Every downstream capability depends on it.

Problem 2: a run is meaningless without the design that produced it

Process characterisation is a designed experiment. Each ambr run is a design point with target setpoints for pH, dissolved oxygen, temperature, feed rate, and seed density. What actually happened deviates from the target, sometimes significantly, and the analysis has to use the achieved values, not the intended ones. If your design lives in a Umetrics worksheet and your achieved values live in a different export, the join is manual and the risk of using target values by mistake is real.

What a custom build does: hold the design in the same system as the execution. A design of experiments object generates run definitions, each run knows which design point it belongs to, and achieved values are computed from the aligned time series against the definition your scientists agree on, such as mean pH between twenty four hours and harvest rather than a single reading. Model fitting can still happen in Umetrics or in a Python environment, and it should, but the data handed to it is generated by the system rather than copied by a person. When a run is excluded from a model, the exclusion and its justification live with the run permanently, which is precisely the question a reviewer asks two years later.

Problem 3: the scale down model is only credible if you can show alignment

A qualified scale down model is the argument that lets you characterise at 250 millilitres and file for 2,000 litres. That argument has to be made with data: matched profiles for the parameters you claim are equivalent, and honest treatment of the ones that are not, such as mixing time, oxygen transfer, and shear. Under ICH Q5E, comparability between pre change and post change material is a structured demonstration, not an assertion.

Off the shelf tools give you the plots. What they do not give you is a repeatable, defined comparison that anyone can rerun. The comparison exists as a scientist's Excel file with named ranges, and when the reviewer asks for it with two additional runs included, it is rebuilt.

What a custom build does: make the comparison a saved, versioned object. It names the runs on each side, the parameters compared, the alignment basis, the statistical treatment, and the acceptance criteria. Rerunning it with new runs is a click, and the output carries the definition with it. When a regulator asks how comparability was assessed, the answer is a document generated from the definition rather than a scientist's recollection of what she did in a spreadsheet in 2024.

Problem 4: offline analytics arrive days later and never come back to the run

Titer, glycan profile, charge variants, aggregate levels, and host cell protein all arrive from analytical labs on their own timelines, often after the run is long finished and the scientist has moved on. They arrive as instrument exports or as a result in a LIMS, keyed by sample ID. Reconnecting them to the correct sample time within the correct run is manual, and partly why quality attribute trends across a campaign are usually assembled once, for a report, and never maintained.

What a custom build does: treat every sample as a first class object created at the moment it is drawn, with its run, its elapsed time, and its intended assays already attached. Results flow back against the sample, from a LIMS integration where one exists and from parsed instrument exports where one does not. Once that link is automatic, quality attribute trending across scales and campaigns becomes a standing view rather than a project, and a shift in a glycan profile between runs becomes visible in days instead of at report writing time.

Problem 5: the tech transfer package is rebuilt by hand and the filing rests on it

When a process moves to manufacturing or to a contract manufacturer, the package includes the process description, parameter ranges with their classification, the characterisation data supporting each range, the control strategy, and the comparability evidence. In most organisations this is assembled by a senior scientist over several weeks, from sources of varying reliability, under deadline.

What a custom build does: generate the package from the system of record. Each critical process parameter carries its proven acceptable range, the design that established it, and the runs that support it, as links rather than as retyped numbers. The document is produced, reviewed, and versioned, and when a range changes, the system knows every document that cited it. Companies that do this stop treating tech transfer as an event and start treating it as an export.

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, this is the shape for bioprocess data platforms. A first release covering the run object with canonical event timeline, ingestion for your three or four most used instrument families, time aligned overlay and comparison, and a design of experiments layer runs $90,000 to $190,000 and ships in 14 to 20 weeks. A full platform adding scale comparability objects, critical parameter and quality attribute registers, electronic run records with review workflow, LIMS integration, and generated tech transfer packages runs $250,000 to $600,000 phased over 9 to 18 months.

• Number of instrument families and whether their exports are documented. An undocumented binary export from an older controller is weeks, not days.
• Modality count. A company running monoclonal antibodies, a cell therapy, and a viral vector needs three different run models, not one with a flag.
• Whether the system must be validated for GxP use. If run records support a filing, expect validation to add materially to both cost and timeline, and plan the requirements and traceability from the start rather than retrofitting.
• Data volume and probe sampling rate. One second Raman spectra across a campaign is a different storage and query problem from one minute process values.

Build versus buy, and when buying is right

Buy if you are a single programme company on one platform process running a modest number of runs a year. Benchling for registry and narrative plus Umetrics for the statistics is a sensible stack and a custom platform would outrun your data. Buy if your problem is genuinely multivariate modelling rather than data assembly, because Umetrics and Genedata do that well and rebuilding it is a poor use of budget.

Build when two or more of these are true. You run several modalities whose run structures genuinely differ. You have more than one development site and comparisons cross them. Your scale down model qualification and comparability arguments are rebuilt by hand each time they are questioned. You are approaching a filing and the provenance of your characterisation data depends on a folder convention. Or your scientists spend more time assembling than interpreting, which at development salaries is a straightforward business case.

How to choose a developer for bioprocess data software

Ask them to model a run before you sign anything. A developer who has done this asks about elapsed time versus wall clock, about feed and induction events as the real index, about sample draw as an object separate from result, and about how you exclude a run from a model without deleting it. A developer who proposes a table of experiments with columns for titer has built a laboratory notebook and will fail on the first overlay.

Ask specifically how they handle instrument exports that change format when a vendor updates firmware, because they will. The answer should involve versioned parsers and an exception queue, not a promise that it will not happen.

Ask whether they have worked in a validated environment and what they think computer software assurance means for a development system. A team that has never faced GxP scrutiny will build something scientists like and quality cannot accept.

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 to continue the work. At Digital Heroes the client owns the code from the first commit. Characterisation data supporting a biologics filing must never sit behind a vendor relationship you cannot exit.