Computerized System Validation CSV

Authorities and notified bodies increasingly address the Computerized System Validation (CSV) in audits. This article introduces regulations regarding "Computer System Validation" and provides guidance on how you can best meet these requirements.

a) Definition and Purpose of CSV

Computer System Validation (CSV) is a documented process of assuring that a computerized system does exactly what it is designed to do.

b) What does Validation mean in this Context?

In general, validation is the "confirmation, through the provision of objective evidence, that the requirements for a specific intended use or application have been fulfilled" [ISO 9001:2015].

As for medical devices, this involves an "assessment by objective means of whether the specified users are enabled to achieve the specified goals (intended purpose) within the specified context of use". 

This may sound as if only the finished product, here the installed computer system, must be validated.

However, many regulations go beyond such an understanding. Such as the FDA's requirements: they require the whole development process to be validated; not just its last phase or final product. More on this later.

c) Computer System Validation vs. DQ, IQ, OQ and PQ

DQ, IQ, OQ and PQ - we come across these acronyms in the context of CSV. They stand for:

• DQ: Design Qualification
• IQ: Installation Qualification
• OQ: Operation Qualification
• PQ: Performance Qualification

These qualifications are particularly required in the pharmaceutical environment, e.g. by GMP-directives, and rank among equipment validations, just as CSV. IQ, OQ and PQ comprise certain aspects of validation / qualification:

• IQ: when installing, first inspections at the site of the customer shall ensure: the device was delivered, installed and installed according to the specifications. The documentation is available.
• OQ: checks ideally shortly after IQ shall confirm that the device operates according to specifications - even when reaching the specification limits.
• PQ: These tests address, inter alia, measurement accuracy (incl. calibration and adjustment).

d) Computer System Validation vs. Software Validation

Computer System Validation generally comprises both computer hardware as well as computer software. Particularly for standard hardware such as PC based systems, Computer System Validation substantially equates to software validation. In case of specific hardware, it should for example be examined if:

• the software can be installed on the respective hardware
• the overall system operates at a satisfactory pace
• the interplay with neighbor systems (other devices or IT systems) functions as specified

a) Overview

Requirements for validation of computer systems can be found in:

• FDA 21 CFR part 820.70
• FDA 21 CFR part 11.10
• FDA 21 CFR part 11
• FDA Guidance Document regarding Software Validation (also addressing process software)
• ISO 13485, inter alia in chapter 4.1.6, 7.5.2.1 and 8.2.3 
• GMP directives
• GAMP 5, e.g. regarding the "risk-based approach of testing GxP systems"

b) FDA 21 CFR part 820.70

In 21 CFR part 820.70, the FDA writes:

"When computers or automated data processing systems are used as part of production or the quality system, the manufacturer shall validate computer software for its intended use according to an established protocol. All software changes shall be validated before approval and issuance. These validation activities and results shall be documented. “

c) FDA 21 CFR part 11

21 CFR stipulates in part 11.10:

"Persons who use systems to create, modify, maintain, or transmit electronic records shall employ procedures and controls designed to ensure the authenticity, integrity, and, when appropriate, the confidentiality of electronic records. Such procedures and controls shall include validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records.”

This demand for validation corresponds with what is required under 21 CFR part 820.70.

d) ISO 13485:2016

In its latest version, ISO 13485:2016 states the requirements for validation of computer systems more clearly:

In chapter 4.1.6, it is stipulated that manufacturers shall validate their computer software pursuant to documented procedures. This affects every software used in a process which controls the QM system. Validation shall not only take place before the first use, but also after modifications to the software.

To put it even stronger: in Europe, CSV used to be mandatory only for manufacturing and service processes. Since ISO 13485:2016, this requirement also applies to all computerized systems being used in any of the processes regulated by the QM system. In the context of FDA, this has always been the case.

e) GAMP 5

GAMP 5 applies to medical device manufacturers as well. The authors write:

The scope has been widened [compared to Gamp 4] to include related industries and their suppliers, including biotechnology and systems used in medical device manufacturing (excluding software embedded within the medical devices).

At first, you should understand: which requirements for computer system validation do you want to or must meet?

1. Minimal requirements: either way, you must validate your finished computer system.
2. Additional requirements: if you develop the system yourself or have it developed, you must at least document the whole development process.

Both variants are addressed in the following.

The actual validation

If you intend to validate the "finished" (possibly already installed) computer system, you must know the requirements for the computer system. If these requirements are lacking, you must deduce them in retrospect.

Unfortunately, many firms and, in part, even authorities, lump different types of requirements together.

1. Stakeholder requirements and purpose: those are the truly important objectives and requirements different stakeholders such as users, operators and legislation have to be able to reach their respective aims. If you have, for example, a laboratory information system, one requirement would be: the user must be able to recognize at the system whether the patient has hepatitis.
2. System requirements specification: this requirement describes what the system must be able to do to fulfill the stakeholder requirements. Ideally, those system or software requirements are specified as black box requirements. In the case of laboratory information system, such a requirement would be that the system shell display all patients with at least one positive hepatitis value in red and bold font.

Strictly speaking, validation is an examination of whether the first type of requirements is met. However, it can be observed that in practice, the fulfillment of rather system or software requirements is examined during validations. However, technically speaking, this is actually a verification.

In the chapter "Step-by-Step Instructions" you can read about how to conduct this type of validation.

The complete development process

When "validating" according to the FDA Software Validation Guidance Documents, you will document the complete development process such as

• Software requirements
• Verification of software requirements including traceability to stakeholder requirements
• Software architecture and detailed design
• Verification of software architecture and detailed design including traceability to software requirements
• Software code, code reviews and unit tests including traceability to software architecture and detailed design respectively
• Integration and system tests including traceability to software architecture and software requirements respectively

IEC 62304 and IEC 82304 as well as the aforementioned FDA documents provide you with valuable information on how to define and implement such a development process.

To validate a computer system, proceed as follows:

0. Decide whether the system must be validated

Describe the intended use of the system. Evaluate whether it is supposed to be used in one of the processes that is regulated by your QM systems. If this is the case the system must be validated.

1. Document requirements

If the requirements for your software and computer system are not or not completely documented, catch up on this retroactively.

1. Graphical User Interfaces
1. Display: Describe the appearance of your graphical user interface (GUI) and what must be displayed.
2. Algorithms: If this display depends on calculations, then state them.
3. Input: Describe which data the user can enter in which formats. Also, how the system shall react in the case of a wrong entry.
4. Navigation: Specify the navigation through the system, i.e. which "screens" the system shall display when certain selections are made, e.g. by clicking.
5. Access right: An aspect of the aforementioned requirement is the specification of role concepts, authorization and authentication.
2. Data Interface
1. System context: Describe with which adjacent systems your system will interact with.
2. Interoperability: Specify how they are proceeded. Name the standard (e.g. TCP/IP, HTTP, bus systems), formats, classification systems, authorizations etc. Do not forget to determine how your system shall react if data is transmitted in a wrong format or volume, in an unexpected frequency etc.
3. Authorizations: Describe how adjacent systems shall authenticate and authorize on your system.
4. Performance: Specify how fast your system must be able to react to data transfers. This requirement will probably depend on the number of transactions, data volumes or the like.
3. Runtime Environment
1. Hardware: Specify the minimum requirements for hardware such as CPU, RAM, hard drive, screen size, screen resolution etc.
2. Operating System: Also determine the operating system which is required at least.
3. Other Software: Do you allow for other software such as anti-virus programs? Do you even suppose this, e.g. in form of a database? Do not forget to specify these requirements.

2. Specify test cases

The next step is to specify test cases, i.e. to determine

1. Which data the user or the adjacent system shall enter or transfer.
2. Which prerequisites must be met, e.g. regarding the software version or existing data.
3. The procedure, e.g. the sequences in which to proceed i.e. to use the system, to input test data, to record results.
4. Pass/fail criteria: which values do you expect? Which outcomes meet the requirements?
5. Test documentation is also part of the specification.

3. Execute and document tests

Finally, you must execute, document and evaluate the tests according to the test specifications.

The following thoughts may help you with your Computer System Validation:

• Systematic derivation of test data: you should not just come up with test data but systematically derive them using black box test methods such as testing methods based on equivalence classes, boundary values, decision tables, errors or conditions. Software testers can do that.
• Not just the happy path: not only examine if your system reacts as specified but also if it deals properly with wrong or incomplete entries.
• Risk-based approach: if you are overwhelmed with the tests' scope, focus on the most critical functionality sections, i.e. those leading to the highest risks in cases of errors.
• Regression: Computer System Validation is not a one-time thing but has to be repeated each time you make changes to the system or software. Thus, automating the tests is recommended. There are tools with which you can semi automatically record and play back user interface tests as well.

Click here to also read the article on AAMI TIR 36 and IEC 80002-2. Both articles offer specific assistance to validation of "Computerized Systems".