Computerised system validation for monitoring and mapping software

EU GMP Annex 11 requires computerised systems to be validated and IT infrastructure qualified, with the extent of validation based on a documented risk assessment. For environmental monitoring and mapping software, the critical functions are data capture, calculation, alarm generation, review workflow and record retention.

What a validation package covers

• User requirements and a functional risk assessment.
• Supplier assessment for purchased software.
• Installation and configuration records.
• Testing of critical functions: correct statistics on known datasets, alarm behaviour, audit-trail capture, access control.
• Data migration and retention approach.
• Change control and periodic review.

Deterministic calculation engines are easier to validate than opaque ones: the same inputs must always give the same outputs, and those outputs can be checked against independent calculations. ValiTrac's engineering engine is designed to be tested exactly that way.

Risk decides the extent, and the categories help

Annex 11 bases the extent of validation on a documented risk assessment, and the GAMP software categories are the usual shorthand for what that implies. The point is not the category number; it is that a configured commercial monitoring platform and a bespoke analysis script need different evidence.

Spreadsheets fall in the last row and are treated as if they were in the second, which is where most of the exposure sits. A spreadsheet computing mapping statistics is custom software with its logic scattered across cells, no version control unless someone imposes it, and a range that can silently stop one row short of the data.

Testing the functions that decide something

The functions worth testing are the ones whose output a decision rests on: the statistics, the excursion detection, the alarm logic and the report. Test them with datasets whose right answer you worked out by hand — a clean baseline, a single excursion of known duration, a reading sitting exactly on the limit, a gap, a flatline, duplicated timestamps, a file in °F, a daylight-saving jump. Each has one correct outcome, which is what makes a re-run after a change meaningful.

The controls underneath

• Individual user accounts and defined roles. A shared login makes the audit trail worthless, and it is the most common Annex 11 finding.
• An audit trail that cannot be disabled, covering creation, amendment and review, with the previous value retained.
• Time synchronisation to a single source, so a sensor reading and an alarm record can be placed in the same order.
• Backups that have been restored at least once. An untested backup is an assumption.
• Change control on the software itself, including its calculations. A corrected bug in an excursion calculation immediately raises a question about every report produced by the previous version.
• A supplier assessment on file for anything purchased, proportionate to what the software decides.

Deterministic engines are cheaper to validate than opaque ones, for a structural reason: the same input always gives the same output, so the verification set can be re-run automatically on every change and the evidence is a build log rather than a fortnight of manual retesting.