Annex 11 1, 4, 11
Validation lifecycle, risk and release verification
What it says
Validate the system across its lifecycle, with documentation and test methods justified by risk. Keep an inventory and a description of the system, and user requirements traceable through to testing. Make changes only under a defined procedure, and evaluate the system periodically to confirm it is still valid and compliant.
What it means on site
A cloud platform changes far more often than software on a PC, so a one-off validation goes stale quickly. Sematics runs a continuous lifecycle instead. Risk is assessed function by function, following ICH Q9(R1) and the risk-based approach of GAMP 5, so testing concentrates on what protects your records: alarms, notifications, the audit trail, access and the readings themselves. Each requirement traces through the functional design and the platform specification to its tests. Each release is assessed and verified according to its risk, and Sematics is introducing an automated release validation pipeline that runs the tests on an environment built from the release and seals the results so any later change would show. Sematics's validation programme includes a verification report for each release, reviewed by people who didn't produce the work, a validation summary, and a periodic review at least once a year that asks whether the validated state still holds; ask us for the current status and the latest approved documents under the quality and technical agreement.
How to evidence it
- The platform validation package: methodology, requirements, risk assessment and traceability
- The release verification evidence for the version you run, and the current status of the validation summary
- Your URS, DQ and PQ, approved by your QA
- Periodic review records, yours and the supplier's


