In a pharmaceutical project, a control system is not finished when it works. It is finished when it has been shown to work — in a documented, traceable way, against approved requirements.
GAMP 5 provides the framework: a risk-based approach to computerised system validation, built around specifications and the tests that verify them. The challenge is to apply it without turning every test session into a slow, paper-heavy debugging exercise. This is how we approach it on DeltaV and Siemens projects.
1. Start from the URS, write the FS and DS with traceability in mind
The user requirement specification (URS) states what the system must do. We review it early: ambiguous or untestable requirements are cheapest to fix before design starts. The functional specification (FS) and the design specification (DS) are then written so that each requirement can be followed through:
- each URS requirement is covered by identified sections of the FS;
- the DS describes how the configuration implements them: modules, sequences, alarms, interlocks;
- identifiers are stable, so that a test can refer to a requirement without ambiguity.
Traceability is much easier to build while writing than to reconstruct afterwards. The risk-based approach also shapes the effort: functions with an impact on product quality and patient safety receive the most detailed specifications and tests.
2. Test protocols written against the specifications
Each requirement needs a test that demonstrates it. Protocols are written against the FS and DS, with:
- a clear objective and a reference to the requirement or requirements covered;
- preconditions and step-by-step instructions;
- expected results that are objective and observable — “XV-101 opens and its open feedback is displayed”, not “the system works”;
- room for actual results, evidence and signatures, as required by the client's quality system.
A well-written protocol can be executed by someone who did not write it. That is a good test of the protocol itself.
3. Dry runs on the virtual machine
This is where we save the most time. Before formal execution, every protocol is run informally — a dry run — on the virtual machine, with the real configuration, the real graphics and a simulated process. The dry run finds two kinds of problems:
- configuration defects, which are corrected and re-checked before formal testing starts;
- protocol defects: a wrong expected result, a missing precondition, a step that cannot be executed as written.
Without dry runs, formal testing often turns into debugging: deviations are raised for problems that a simple rehearsal would have caught, and each one has to be documented, investigated and closed. With dry runs, formal execution confirms a system that is already known to work.
4. IQ and OQ with a complete traceability matrix
Formal qualification then follows the client's validation plan. Installation qualification (IQ) verifies that the system is installed as specified: hardware, software and configuration. Operational qualification (OQ) verifies that it operates as specified, function by function. Throughout, the traceability matrix links each requirement to its specification sections, its test protocols and their results.
At the end, the matrix answers the question every auditor asks: has every requirement been tested, and did every test pass — or is the deviation documented and closed?
5. Keep the system in a validated state
Validation does not stop at OQ. Every later modification goes through change control: impact assessment, updated specifications, targeted re-testing and documented approval. The virtual machine remains useful here too: modifications can be rehearsed offline before they are implemented on the validated system. On DeltaV, configuration exports taken before and after a change document exactly what was modified (see our article on FHX exports).
In short
Specifications written with traceability in mind, protocols written against them, dry runs on the virtual machine, then IQ and OQ with a complete traceability matrix. The result: fewer deviations, cleaner test records and a validation team that trusts the system. We bring GMP experience with DeltaV in vaccine production (GSK, Wavre). See our GAMP 5 validation services.
A pharma automation project coming up?
Tell us about the scope and the validation approach: answer within 48 hours.