In short: a program used for GMP records is not certified, it is validated at the plant that uses it. Validation shows, with documents, that the system does what it should for your processes and keeps doing so. Its extent is set by risk, following the GAMP 5 guide, and the supplier should give you a good part of the starting documents.
Why software is validated
EU GMP Annex 11 requires computerised systems used in GMP activities to be validated, and 21 CFR Part 11 requires the same for electronic records on the US market. The idea is simple: if a batch record, a laboratory result or a release decision lives in a program, you must be able to show that the program records them correctly, completely and without untracked changes.
Validation is not a certificate that comes with the program. The same software can be validated in one plant and not in another, depending on how it is configured and used.
The risk-based approach: GAMP 5
GAMP 5, the guide published by ISPE, is the industry’s reference for validating computerised systems. Its principle: the validation effort depends on the risk to the patient, to product quality and to data integrity, and on how much the system is configured or custom-built.
GAMP 5 sorts software into categories:
- Category 1, infrastructure: operating systems, databases, network. They are qualified, but not functionally validated.
- Category 3, non-configured products: used as they come. Validation is lighter and focuses on how they are used.
- Category 4, configured products: the same base, adapted to the plant’s processes through settings. The configuration is what gets checked most.
- Category 5, custom applications: they need the most detailed verification, including how the code was written and tested.
Many real systems have parts in several categories, and the categorisation is justified in the risk assessment.
The validation documents, one by one
- Validation plan: what is validated, who is responsible, which documents result and the acceptance criteria.
- User requirements (URS): what the system must do, written by the plant in terms of its own processes. Each requirement has a number, so it can be traced to a test.
- Risk assessment: for each function, what can happen if it fails and how serious it would be. This decides how much each part is tested.
- Functional and configuration specifications: how the system meets the requirements. Usually written by the supplier.
- Traceability matrix: the link between each requirement, the specification that covers it and the test that verifies it. Inspectors often ask for it, because it shows at a glance whether any requirement was left untested.
- IQ, installation qualification: the system is installed correctly, in the right environment, with the right versions.
- OQ, operational qualification: each function works according to specification, including edge cases: values out of tolerance, rejected signatures, denied access.
- PQ, performance qualification: the system works in real production, with the plant’s people, procedures and data, on real batches.
- Validation report: the results, the deviations found and how they were handled, plus the conclusion that the system can be used.
What the supplier does and what the plant does
| The supplier | The plant |
|---|---|
| functional and configuration specifications | user requirements (URS) |
| documentation of its own development and testing | risk assessment on its processes |
| IQ, OQ, PQ templates and the traceability matrix | executing the qualifications and signing them |
| its position on Annex 11 and 21 CFR Part 11 | operating procedures and training |
| support while tests are executed | the decision that the system can be used |
Responsibility for validation stays with the plant. A good supplier shortens the road, but cannot sign on the plant’s behalf.
How the system stays validated
Validation does not end at go-live. The validated state is maintained through:
- change control: any change of version, configuration or process goes through impact assessment and, where needed, retesting;
- periodic review of the system: users, permissions, incidents, changes, backup;
- review of the audit trail for critical records;
- testing restore from backup, not just that a backup exists;
- training new users before they get access.
Common mistakes
- A URS copied from the supplier: requirements must describe your process, not the program’s feature list.
- Everything tested the same way: without a risk assessment, a display setting gets as much testing as a release signature.
- Documents written after the fact: validation done after the system is already used in production.
- Uncontrolled changes: a new version installed without assessment quietly invalidates everything that was done.
- Paper and system in parallel, forever: the transition period needs an end date.
Frequently asked questions
Who signs the validation?
The plant: the process owner, quality assurance and, where relevant, the system owner. The supplier signs the documents it produced.
Are cloud-hosted systems validated too?
Yes, on the same principles. In addition, the supplier and the hosting are assessed, and the contract sets out who is responsible for backup, security and availability.
Does the system have to be revalidated at every update?
Not fully. Change control assesses what the update affects, and only those parts are retested, in proportion to the risk.
What is CSA?
Computer Software Assurance, the approach promoted by the FDA, which emphasises critical thinking and testing proportional to risk instead of exhaustive documentation. It goes in the same direction as the second edition of GAMP 5.
For DataFlows Pharma we deliver the package validation starts from: URS with a traceability matrix, risk assessment, the position on Annex 11 and 21 CFR Part 11, the data integrity statement and IQ, OQ and PQ templates. For the bigger picture, see what production software for the pharmaceutical industry has to cover.
