Validating the software that analyses your monitoring and mapping data
Calculations that decide whether a space passed must themselves be verified — with known datasets, expected results and a record of the software version.
Whether the analysis runs in a spreadsheet, a monitoring platform or a dedicated engine, it produces GxP records and falls under Annex 11. Verification asks a simple question: given this dataset, does the software produce the right minimum, maximum, mean, hot spot, cold spot and excursion list?
A verification set
- A clean dataset with hand-verifiable statistics.
- Datasets with a single excursion of known duration and magnitude.
- Datasets with gaps, duplicated timestamps and a flat-lined sensor, to confirm they are detected and reported.
- A dataset in °F to confirm unit handling is explicit, not inferred.
- Datasets at the acceptance limit to confirm boundary behaviour.
Deterministic engines make this straightforward: the same input yields the same output, so a verification set can be re-run automatically after every change. ValiTrac's engine ships with such tests and records the code version alongside every result.
A verification set with expected answers
The value of a verification set is that every case has one right answer, worked out by hand before the software sees it. That is what makes a re-run after a change meaningful.
| Dataset | Content | Expected result |
|---|---|---|
| Clean baseline | 4 sensors × 24 h at 5 min, values computed from a known function | Min, max, mean and per-sensor statistics match the hand calculation exactly |
| Single excursion | One sensor 0.4 °C above the limit for exactly 35 min | One excursion, duration 35 min, correct sensor and start time |
| Boundary | A sensor sitting exactly on the limit for 20 min | Documented and consistent behaviour — the engine must state whether at the limit is inside or outside, and do it the same way every time |
| Gap | 90 min missing from one sensor | Gap detected, duration reported, statistics either exclude it or flag the limitation |
| Flatline | One sensor repeating an identical value for 6 h | Flagged as a suspected stalled logger, not silently averaged |
| Duplicate timestamps | One sensor with 12 duplicated rows | Detected and reported, not double-counted |
| Fahrenheit file | The clean baseline exported in °F | Either converted after an explicit declaration, or refused — never inferred from the magnitude of the numbers |
| Clock shift | A daylight-saving jump of exactly one hour | Detected; readings not silently reordered |
Spreadsheets are in scope, and they are the hard case
Most mapping analysis in the industry happens in a spreadsheet, and a spreadsheet producing GxP records is a computerised system under Annex 11 like any other. The difficulty is that its logic is scattered across cells rather than written down, a formula can be overwritten without any record, and a range that silently stopped one row short of the data will produce a confident, wrong mean. If the analysis stays in a spreadsheet, it needs cell protection, a controlled master template with a version number, formula verification against the test set above, and a check that the ranges cover the actual data every time.
What to record with every result
- The software name and exact version, stored with the result rather than in a separate log — otherwise a result cannot be tied to the code that produced it.
- The input file, hashed or archived unchanged, so the run can be reproduced.
- Any configuration that affects the answer: limits, unit declaration, excluded ranges, the boundary convention.
- The verification-set run for that version, showing it passed before the version was used on real data.
- Change control on the analysis itself. A fixed bug in an excursion calculation raises an immediate question about every report produced by the previous version.
Determinism is what makes this cheap. If the same input always yields the same output, the verification set can be re-run automatically on every change, and the record of it is a build log rather than a fortnight of manual re-testing.
Frequently asked questions
- Do spreadsheets need validation?
- Yes, if they produce GxP decisions. Locked templates, version control and verification against known data are the usual controls.
References
- [1]EudraLex Volume 4, Annex 11: Computerised Systems
- [2]EudraLex Volume 4, Annex 15: Qualification and Validation (2015)
General technical guidance written against the cited sources. It is not regulatory or legal advice and does not replace the applicable standard, guideline or a qualified reviewer's judgement.
Have a question on this topic?
Ask ValiTrac AI and see the evidence and calculation behind the answer.
Ask ValiTrac AIFree calculator: Protocol builder
Build a draft IQ, OQ and PQ protocol for a cold room, chamber, autoclave or vehicle — document control, the test list that suits that equipment, record tables and approval blocks. It will not write your acceptance criteria, and says so.
Open the calculatorRelated articles
Computerised system validation for monitoring and mapping software
Software that produces GxP records must be validated for its intended use: requirements, risk assessment, testing, audit trails, access and change control.
Data-quality checks before analysing mapping data
Statistics computed on bad data are precise and wrong. Check the data first.