Computer System Validation – CSV

Computer System Validation refers to a documented process that ensures a computerized system does exactly what it was designed to do, in a consistent and reproducible manner.

The validation process provides documented evidence that the system consistently meets its predefined requirements and is suitable for its intended use. Validations can be used in various types of GxP-regulated environments:

  • Sterility
  • Cleaning
  • Method
  • Process validation

 

Why is Computer System Validation important?

Particularly for pharmaceutical companies and medical device manufacturers, Computer System Validation is relevant as it assesses the transparency, quality, and patient safety of the system. It always applies:

  • Avoiding dangers and risks to human health and life
  • Avoiding product defects and their impact on human health and life
  • Ensuring high-quality products through extensive testing and a controlled IT operation
  • Minimizing the risk of malfunctions and failures through controlled IT operations and transparent IT processes

 

By implementing Computer System Validation, you also ensure compliance with national and international regulations and can cover the following critical guidelines:

  • ISO 13485, FDA 21 CFR 820, FDA 21 CFR Part 11, SFDA, etc.
  • Reliable and safe (manufacturing) processes
  • Proof of activities to comply with GxP-critical processes

 

In the long term, Computer System Validation also helps reduce costs:

  • Low maintenance effort through the use of quality and project management standards
  • Low maintenance effort and costs in change management through transparency and reliable system documentation
  • Low costs in the development and manufacturing of products through the use of reliable software and processes

IQ, OQ, and PQ in the context of Computer System Validation

The acronyms stand for:

  • IQ: Installation Qualification
  • OQ: Operational Qualification
  • PQ: Performance Qualification.

These qualifications encompass aspects of software validation and qualification

  • IQ:

    • Hardware Installation Qualification: The documented evidence that
      • the system is designed and built according to its specifications,
      • the system is properly installed,
      • the system fulfills its defined purpose,
      • the installation is transparent,
      • the installation is repeatable/reproducible

       

    • Software Installation Qualification:
      • is the installation guideline for the computer system with company-specific settings
        and parameters
      • is used as a checklist and documentation for correct installation,
      • should be reused for each installation of the computer system (clients, etc.),
      • provides standardization of the CS and is suitable for repeated use of validation documentation in multiple systems,
      • each installation of the CS is identical, transparent, and repeatable/reproducible.

  • OQ:

    • Operational Qualification (OQ) is conducted after each IQ protocol is completed. The purpose of the OQ is to verify that the equipment’s performance meets the user requirements specification within the operating ranges specified by the manufacturer. In practice, this means identifying and testing equipment features that can affect the quality of the final product.
    • During the OQ, all elements of the test plan are tested and their performance is thoroughly documented. As this is a prerequisite for equipment and system acceptance, it can only be performed after the IQ has been completed.
    • In general, the OQ serves as a detailed review of hardware or software commissioning, operation, maintenance, cleaning, and safety procedures (if and where applicable). Each unit of hardware and software must be demonstrated to operate within specified limits.

  • PQ:

    • The final step in equipment qualification is PQ. In this phase, the qualification and validation team verifies and documents that the equipment operates with reproducible results within a specified working range under simulated real-world conditions. Instead of testing components and equipment individually, they are tested in the PQ as part ofa whole process.
    • However, before the qualification begins, the team must create a detailed test plan based on the process description. It is important to know that the quality of the qualification largely depends on the quality of the test plan. This is an area where an external specialist can (and often should) be brought in to ensure thoroughness and accuracy.
    • The Process Performance Qualification (PPQ) protocol is a fundamental part of process validation and qualification. The purpose is to ensure continuous product quality by documenting performance over a specified period for certain processes.

 

Our Service Portfolio

  • Risk-based validation
  • Validation of SAP software components and self-developed SAP applications
  • Validation according to ISO 13485
  • Risk assessment
  • Test script creation, test execution
  • Execution of validation
  • IQ/OQ/PQ

Computer System Validation according to the V-Model

The V-Model was designed for software development to align testing phases with development phases. Thus, the approach to quality assurance through testing is defined. On the left side, a functional/technical specification begins, which is increasingly detailed into a technical specification and implementation basis. Visually, this creates the namesake ‘V’, which aligns the different development levels with their respective testing levels.

  • High Level Risk Assessment (HLRA)
    • identifies whether the system (or part of the system) is subject to validation. These assessments are based on a questionnaire that determines whether the system has a potential impact on production and/or quality-related processes (GxP-criticality)
    • identifies the GAMP software category to redefine the validation activity and characteristics, level of the V-Model (GAMP 5, page 127, appendix M4)
  • Validation Plan (VP)
    • plans validation activities to ensure compliance and activities to ensure the system is suitable for its intended use. The validation plan defines: project scope/validation, validation strategy, required activities and outcomes, project organization and responsibilities, acceptance criteria, system management activities (incident management, problem management, change management) to maintain the validated state
  • User Requirements Specifications (URS)
    • must be created by the Business Application Owner
    • clearly and precisely defines the intended use, desired functionalities, behavior, supported business processes: functions, data, interfaces, roles, non-functional attributes
    • should be as detailed as possible
    • does not describe the solution of the system
    • is the basis for system development and should be understood by the ITAO/developer
  • Functional Specification (FS)
    • describes the implementation and functionalities of the user requirements in the system simply and self-explanatorily
    • the functional specification is the translation of the requirement into functionalityand specifies what the proposed system is to do
  • Functional Risk Assessment (FRA)
    • is used to identify functions that have an impact on patient safety, product quality, and data integrity
    • the FRA defines measures to mitigate risks. Risk mitigation can be: SOP
    • additional control within the system (mandatory fields, cross-checking, plausibility check, etc.)
    • a system review is not risk mitigation
  • Design Specification (DS)
    • describes how the system is built to meet the functional specification
    • is the information on the design status with targeted input (usually design diagrams and specifications created by developers) and output
    • reference to IEEE Working Group P1016 -> System Design Spec. Standard
  • (Software) Installation Qualification (IQ)
    • is the installation guideline for the computer system including company-specific settings and parameters
    • is used as a checklist and documentation for correct installation
    • should be reused for each installation of the computer system (clients). Each CS installation is identical, transparent, and repeatable/reproducible
    • provides standardization of CS and is suitable for repeated use of validation documentation in multiple systems
  • Technical Test (TT/ OQ)
    • plans test activities, acceptance criteria, quantity, environment, strategy, error handling, etc.
    • the quantity, complexity, and types of tests are based on risk (see FRA output)
    • technical tests include: module/unit, integration, configuration, function test
  • User Acceptance Test (UAT/ PQ)
    • plans test activities, acceptance criteria, quantity, environment, strategy, error handling, etc.
    • the quantity, complexity, and types of tests are based on risk (see FRA output)
    • the test results should be documented compared to the predefined acceptance criteria against the specifications
  • Traceability Matrix (TM)
    • it must be possible to trace each part from the user requirement to the specification to the verification activities and vice versa
    • traceability is established by creating an explicit traceability matrix
  • Validation Summary Report (VSR)
    • writes the history of the validation project

 

Risk Management in Computer System Validation

Risk management is an essential part of CSV and ensures the quality and transparency of the system with regard to potential risks. As part of the functional risk assessment (FRA), the risks related to patient safety, product quality, and data integrity of each function are assessed.

  • Different risk scenarios are examined in this risk assessment and appropriate measures to mitigate risks are defined.
  • Risk mitigation measures should especially be defined if the probability of occurrence and the impact of the risk on patient safety, product quality, and data integrity are high and the risk cannot be immediately identified in the use case.
  • Based on these factors, the potential risk can be calculated and prioritized.

Appropriate measures to mitigate risks can be defined on two levels:

  • Organizational:
    • Application of standard operating procedures (SOP)
    • Training & workshops for safe handling of the software
  • Technical:
    • Checking data validity (mandatory fields, business rules)
    • Checking data integrity (cross-checking)

 

 

If you would like to learn more about Computer System Validation, please feel free to contact us for an individual appointment.

 

Nehmen Sie Kontakt mit uns auf

 

SAP Add-On with Plugins for EUDAMED, FDA, SFDA, TGA, NMPA, and Other Authorities:

Our validated SAP UDI Add-On with plugins meets all requirements of global authorities and represents an effective solution for UDI implementation.

 

SAP Add-On