GAMP 5 describes a validation approach according to the V-model, in which each specification phase is compared to a verification phase. In addition, categories are defined for different software systems
But there are usually considerable differences between theory and practice. In most cases, the phases can not be so clearly contrasted or separated. In particular, OQ and PQ often merge in practice into a UAT (User Acceptance Tests) phase. Therefore, it must be ensured that the processes described in the V-Modell interact effectively with each other. Also, systems can not usually be uniformly assigned to a single category, since a computer system usually consists of several hardware and software components that have to be evaluated differently.
For a commercially available system with a configuration portion, as is the case with a CDS, the validation phases given below may result.
cromingo can support, advise or take over all phases with own documents. We can discuss the form of participation together.
Validation Plan ▼
User Requirement Specification (URS) ▼
- Reason and goal of the validation
- Project organization - planning and responsibilities
- Risk management: system selection and supplier evaluation, GxP relevance of the system, classification of the system in a GAMP5 category and determination of the resulting validation measures, functional risk analysis according to FMEA
- Description of the phases of the validation process and control measures during the operational phase
- Determining the deliverables
- Phase I: System selection document based on essential requirements for the intended business purpose (Supported Devices, Basic Functions, Regulatory Requirements, Manufacturer Support).
- Phase II: Validation Document: After system selection, knowledge of the system is required (training and own experience with the system, external expertise (manufacturer, independent consultant), detailed analysis of the customer requirements on which the overall validation is based one should pay attention to the fact that one differentiates between requirement and design. The formulation of a requirement should actually be able to be formulated independently of the knowledge of a product. Then this document is also well usable for software upgrades.
In the specification phase, referring to the list of requirements, it is documented how the requirements in the system are met or implemented in concrete terms, with three different phases:
Functional Specification (FS) ▼
Configuration Specification (CS) ▼
- For commercially available products, the product specification is the responsibility of the manufacturer and manufacturer documentation should be available. If there is no appropriate documentation because the specifications may consist of many individual documents (multiple software components, no accumulated capture of specifications on successive versions of the software), it may make sense to summarize them in a compact customer document, with reference to the individual documentation.
Design Specification (CS) ▼
- Here you define the configuration of the application required for your business purposes based on your requirements (for example, Audit Trail Settings, Electronic Signature, User Administration, Authorization Concept).
Design Review (DR) ▼
- Here you define the design of the technical infrastructure for your system, i.e. computer hardware, software, network, data backup concept, but also authorizations in the network. This phase is ultimately the basis and prescription for installing the system.
- This phase is completed by a Design Review, in which a list and comparison of all specifications is compiled and reviewed with the project team.
After completion of these phases, the system should be set up and the test cases developed (valley point in the V model). For the beginning of the test phase, a test plan should be drawn up, which shows the procedure and strategy of the test phase. Measures in the form of test cases, procedures, technical controls or staff training should be established based on a risk analysis taking into account the risk to humans, product and data. Most of the time you will take into account business-related risks. All test cases are already specified in the test plan.
Installation Qualification (IQ) ▼
Operational Qualification (OQ) ▼
- Check whether the technical infrastructure of the system has been set up in accordance with the plan. This phase thus forms the counterpart to the design specification.
- Checking the functions of the system. For a category 3 product, manufacturer tests can be incorporated or referenced here. The pure functionality is checked without considering the intended regulatory and business application purpose.
Note: The manufacturer often offers standardized and automated procedures for the IQ/OQ phase. It is the responsibility of the customer to evaluate and, if necessary, supplement it with appropriate in-house tests to verify the full scope of requirements and specifications. This is done in the next phase, often referred to as Performance Qualification. In the meantime, the term UAT is often used for user acceptance tests, as it is difficult to distinguish between individual phases
User Acceptance Tests/Performance Qualification (UAT/PQ) ▼
- Implementation / verification of the configuration specification as the first test case
Reviewing and / or controlling user requirements through appropriate measures, based on the identified risk to humans, product, data and economic aspects.
Conclusion and System Release
Traceability Matrix (TM) ▼
Validation Summary Report (VSR) ▼
- Follow-up of all URS points through the specification phase and verification phase. Ensuring that each URS was followed, evaluated, implemented and verified based on the risk rating during the validation process. Indication of measures or controls that have been taken.
- Summary and evaluation of the validation. Compilation of all deliverables. Information on deviations and measures taken in this regard. Indication of follow-up measures. Release of the system for operational use.