Computer system validation documents, from intended use to validation report
Which documents a GxP system's validation needs, how they depend on each other, and how to keep them consistent without writing each one from scratch.
The documents and what they answer
Computer system validation shows, with documented evidence, that a computerized system is fit for its intended use and stays so. The evidence is a chain of documents, each answering one question an inspector may ask.
- GxP assessment: is the system relevant to GxP at all, what is its software category, how critical is it?
- Validation plan: what will be done, by whom, and which deliverables are needed for this system?
- User requirements specification (URS): what must the system do, and which requirements are GxP-critical?
- Risk assessment: what can go wrong with each requirement, how badly, how likely, and how would we notice?
- Test plan and test report: how is each requirement verified, and what was the result?
- Traceability matrix: which test covers which requirement, and which risk does each control answer?
- Validation report: was everything planned done, were deviations resolved, and is the system released for use?
Where it usually goes wrong
The same facts are copied into several word-processor files and drift apart: a requirement is renamed in the URS but not in the test plan, a test is added without a requirement, a risk is lowered without a reason. An inspector reading the documents side by side notices first.
Validation is also more than the initial release. The system has to stay in a validated state: changes under control, incidents recorded, access reviewed, the system evaluated periodically, backups tested. Their records belong to the same system and should refer to the same requirements.
Scaled to the risk
Not every system needs every document at full depth. The software category and the system's criticality decide how detailed the specification and testing have to be. A standard product used as supplied with low criticality gets a lean specification and risk-based tests; a custom application that supports batch release gets the full set.
With the GxP Validation Assistant
How the assistant keeps them consistent
Recorded once
Requirements, risks and tests are records, not paragraphs. Every document reads the same records, so a change shows everywhere.
Traceability computed
The matrix follows from the links between requirements, risks and tests; a requirement without a test is shown as a gap.
Approved as versions
Documents are generated as PDF and Word, numbered and versioned, marked DRAFT until released, and shown as out of date when their data changes.
The whole life cycle
Changes, incidents, periodic and access reviews, training and retirement produce their records from the same system.
The assistant drafts; documents are signed on paper, in your document system or, switched on, in the assistant itself. Your company remains responsible for its validation.
See it with your own systems.
Watch the webinar, or install the assistant and try it for 14 days.