What is meant by Computer System Validation?

These sectors use computer systems to operate and record a range of processes and activities from clinical trials, manufacturing, product testing, distribution, storage, logistics, etc so it’s critical that these systems can be relied upon to:

• produce data accurately and consistently
• create an indelible electronic data trail that is transparent, traceable and tamper-proof
• store those electronic data records in a way that is safe, secure and can stand the test of time

And that the standard operating procedures (SOPs) and processes are put in place to manage these systems.

In addition, the CSV process is used when replacing paper records and handwritten signatures with electronic data records and electronic signatures in highly regulated environments that impact public health and safety such as the pharmaceutical and medical device industries.

Go rapidly from a beginner to an advanced level Computer System Validation expert. Extend your or your team’s role into CSV projects or charge higher hourly rates. Check out our 10-week online Computer System Validation Training Course

Computer System Validation (CSV) is applied to GxP computerized system applications used at any point in the research, clinical testing, manufacturing, distribution and storage processes. Examples might include:

• Process Control Software
  • PLC for Controlled Packaging Equipment
  • Supervisory Control and Data Acquisition (SCADA)
  • Distributed Control System (DCS)
• Commercial off-the-shelf (CTOS) or Software as a service (SasS) Software
  • Laboratory Information Management System (LIMS)
  • Clinical Trial Monitoring Systems
  • Chromatography Data System (CDS)
  • Enterprise Resource Planning (ERP) Systems
  • Manufacturing Execution System (MES)
  • Batch Record System
  • Building Management Systems (BMS)
  • Cloud base software services
  • Spreadsheets

The pharmaceutical and medical device industries are regulated, meaning that what goes on inside the factory walls is subject to the law of the land. We have to be confident that the computer system generates and stores data accurately and reliably and doesn’t do anything that could harm the patient. In addition, in the 90s, the regulatory authorities for these industries took the decision to replace paper records and handwritten signatures with electronic records.

CSV is a process that creates an indelible electronic data trail that allows us to treat the regulated data and electronic signatures captured in drug discovery, drug trials, manufacturing, distribution and storage as the legal equivalent of paper records and handwritten signatures and have the equivalent level of confidence in their accuracy, reliability and data integrity.

The Food and Drug Administration (FDA) considers computer systems as equipment 21 CFR 211.68 and thus needs to be validated. It also provides detailed controls for electronic records and electronic signatures in the Code of Federal Regulations (CFR) under FDA 21 CFR 11. Part 11 mandates the requirements for electronic records and signatures to be accurate, reliable, readily retrievable, and secure and to be able to legally replace paper records and handwritten signatures. This code applies to (bio)pharmaceutical and medical device manufacturers, biotechnology companies and other FDA-regulated industries. Some examples of the controls required are:

1. Data should be stored in electronic format and can be archived. Electronic records should be as trustworthy as paper records.
2. The system must ensure that electronic signatures are as trustworthy and secure as handwritten signatures. Controls on electronic signatures should include:
   1. the name of the singing user
   2. the day/time the signature was executed
   3. and the meaning of the signature
3. Signed records cannot be altered by users. The system can determine when a record was created, altered, or deleted by a user of the system.
4. Password masking facility should be available in the system.
5. Password complexity should be required i.e. password should be of minimum character length, etc.  Previous passwords can’t be re-used.
6. Screen lock should trigger after a defined period of time.
7. Only authorised people can use the system.
8. The system should have different access levels based on the criticality of the system.
9. The system must be able to generate an audit trail. i.e. every activity should be stored in the system such as who, when, what, etc should be captured.

For medical device makers, the FDA requires them to validate the software and systems used in manufacturing medical devices using 21 CFR 820.

Within the EU, EudraLex – Volume 4 – Good Manufacturing Practice (GMP) provides guidance on the validation of Computerised Systems under Annex 11: Computerised Systems.

The Pharmaceutical Inspection Co-Operation Scheme (PICs) provides guidance with its document on Good Practices for Computerised Systems in Regulated GxP Environments.

Computer System Validation is also required in ISO 13485 standard 2016 – For Medical Devices.

In late 2022, the FDA released a draft guidance document on Computer Software Assurance for Production and Software Systems. This document states that it is  “Not for implementation. Contains non-binding recommendations”  so it is unclear what impact it will have on the approach to software validation. So we have not referred to it throughout this post.

Good Automated Manufacturing Practice (GAMP) is a set of guidelines and procedures that pharmaceutical manufacturers and users of automated systems use to validate the computer systems and achieve compliance with the above regulations such as FDA 21 CFR 11

Think of the controls outlined in FDA 21 CFR 11 as what the regulators want to see the computer system be able to do. Think of GAMP as the approach taken to achieve those controls.

GAMP has enjoyed the support of numerous regulatory authorities and is now a recognized good practice worldwide.

However, GAMP is not regulation. You don’t comply with GAMP

This is a widespread misconception but GAMP is not a regulation or law that pharmaceutical and medical device companies are legally bound to comply with.

In the pharmaceutical and medical device sector, the most widely used method is to follow the GAMP® 5 guidelines and break the process down into its life cycle phases. According to GAMP, there are four life cycle phases in a computer system and each phase contains a number of individual activities. (See diagram below)

In order, these phases are:

1. Concept – a high-level overview of the system and design considerations
2. Project – detailed description of the system and objectives
3. Operation – how the system will be managed during operations
4. Retirement – how to retire the system

In addition, there are a lot of supporting processes or activities that take place across the phases of the life cycle such as risk management, document management, repair activity, security management, etc and you should include them when visualizing the CSV process. You will often use various suppliers across different phases of the lifecycle and you should leverage their expertise as much as possible.

Now, let’s take a look at the individual activities in each of the four phases as well as the relevant supporting processes of each phase viewed through the project life cycle.

The concept phase is where the idea for a system is conceived. At this point, there is a general idea of what the system should do. This phase would include data gathering (i.e. vendors, costs, high-level project plan, resources, timelines, benefits, restrictions and justification of the requirement for the system). The first risk assessment should take place at this point and should ask questions such as, what are the risks to the business of implementing or not implementing this system? Where will further risk assessment be required?

This phase contains the following specific activities:

1.1 Planning
1.2 System Software Categorization
1.3 Risk Assessment
1.4 Supplier Assessment

1.1 Planning

In this activity, you typically define the following:

• the overall requirements of the system
• the critical functions it will be controlling
• the available options for hardware and software platforms
• the overall regulatory impact of the proposed system
• the novelty of the system and its complexity
• the requirement for document control
• the testing that is required (what are the considerations for operating and maintaining the system?)
• what data and records will be generated that will subsequently need to be retained

1.2 System Software Categorization

The range of activities required to validate a computerized system varies greatly depending on the type of software you are using.

The GAMP 5 guidelines now categorize software into 4 types. The category your software falls into will determine the validation approach, the amount of time the project takes and the deliverables.

The 4 categories are 1, 3, 4 and 5 (note: Category 2 was discontinued):

Software Category 1 –  Infrastructure software

This is software that applications are built on and used to manage the operating environment.

Examples: Operating Systems (Windows, Mac OS, Android, Linux etc), Database engines, Middleware, Programming languages, Statistical packages, Network monitoring tools, Scheduling tools, Version control tools

Software Category-3 – Non-Configured Software 

Software in this category allows parameters to be entered and stored in the system, but the software cannot be configured to suit the business process.

Examples: Setting the time (i.e. entering a parameter) on the alarm on your smartphone, Firmware-based applications, Configured Off-The-Shelf (COTS) software, Instruments (i.e. for measuring temperature, pressure, flow volume).

Instruments (i.e. for measuring temperature, pressure, flow volume)

Software Category-4 – Configured Software 

This software is often very complex. It can be configured by the user to meet the specific needs of their business process but the software code itself is not altered. Much of the software you come across in the Pharma/Medtech sector is category-4

Examples: Laboratory Information Management System (LIMS), Enterprise Resource Planning (ERP), Clinical Trial Monitoring, Distributed Control System (DCS),  Chromatography Data System (CDS), Building Management Systems (BMS), Spreadsheets

Software Category-5 – Custom Software 

This software is custom designed and coded to suit the specific business process.

Examples Internally and externally developed IT applications, Internally and externally developed process control applications, Custom firmware, Spreadsheets (macro) 

1.3 Risk Assessment 

Think of a risk assessment as a way of visualising catastrophe before it happens (by trying to think up of as many failure modes as possible) and coming up with methods to mitigate those risks. A quality risk assessment is carried out to determine if the computer system has the potential to impact product quality, patient safety or data integrity in a way that could ultimately harm the patient.

1.4 Supplier Assessment

Part of the concept phase will also be narrowing down the vendor options and getting an idea of the cost to include in the business case. This typically involves sending out a Request for Services document with some general details of system requirements to several vendors. The response from the vendors will detail how their system can meet those requirements, alongside an estimated cost. Where the response looks promising a request for a demonstration of the system will be made before an in-depth supplier assessment is carried out.

In this phase you finalise the planning; develop the user requirement specifications, functional specifications and design specifications; have the project built; and have it commissioned and qualified. Finally, you hand over the completed project to the end-user or client.

Specific activities in this phase include:

2.1 Planning
2.2 Utilising the CSV Process V model
2.3 Risk assessment
2.4 Writing Standard Operating Procedures
2.5 Training
2.6 Handover

2.1  Planning

This stage defines what will be validated and what approach you will use. It also defines individual roles and responsibilities, and the acceptance criteria. It is typically completed by the end-user or client. The planning step of the project phase will contain activities that may overlap with the concept phase – there is not always a sharp delineation between the tasks of both phases.

Documentation completed within this stage includes:

2.1.1 Validation Master Plan (VMP)

Every regulated pharma organisation should have a validation master plan in place to govern its approach to validation. A subsection of this is “computerized system quality and compliance”. Depending on the size of an organisation there may be several sub validation plans within the validation master plan (e.g. site, departmental or system-specific) or there may be multiple validation master plans, one for each business unit.

2.1.2 System Overview

In order to satisfy the regulatory inspectors, you need to give a brief description of the system

It’s best to take a top-down approach and start with its operating environment. This would include other networked or standalone computerised systems, other systems, media (how you store your electronic records), people, equipment and procedures.

In addition, you need to describe:

• Hardware /Firmware
• Software
• Computer System (Controlling System)
• Operating procedures and people
• Data managed by the system
• Equipment controlling function or process

During this phase, you take the V-model approach (see diagram below) to determine the specifications and the verification and testing deliverables.

2.2 Computer System Validation Process V-Model

In pharmaceutical manufacturing, most companies and organisations follow the Good Automated Manufacturing Practice (GAMP®5) V-Model to validate their systems as it meets the requirements of the industry regulators. The model is used to visualize the relationship between user requirements and specifications, and the verification and testing performed on them (see diagram below).

You start at the top left (planning), proceed down ( through to configure and/or coding), and then back up to the right, ending at (reporting). The left-hand side of the V represents what the computer system does (i.e. what you use the software for), along with how the computer system works. The right-hand side of the V represents how you test the system to confirm that the system is fit-for-purpose (i.e. will make safe medicines for patients).

2.2.1 User Requirements Specification (URS)

The user requirements specification maps out what the user needs from the software and how they will use it. It also contains any constraints such as regulations, safety requirements or operational requirements. The specifications must be agreed between the end-user/customer and supplier. The URS will have input from the process owners, system owners, technical subject matter experts (SMEs), quality and the supplier where required.

2.2.2 Functional Specification 

The functional specification contains a detailed description of how the system will meet each of the requirements outlined in the URS such as:

• how the software works
• what data needs to be captured
• user interfaces

2.2.3 Design Specification 

The design specification describes in detail how each function is to be designed or configured. It is a more technical follow-on document from the functional specification and may contain configuration specifications or code – its intended audience is the system developer.

2.2.4 Configuration and/or Coding

In this step you build, develop or purchase the software (depending on the software category) and then configure it to meet the criteria laid out in the previous specification documents. This is typically completed by the vendor.

2.2.5 Installation Qualification (IQ) 

Installation qualification (also referred to as “configuration or integration testing”) confirms that the software or system is installed and set up according to the design specification.

2.2.6 Operational Qualification (OQ)

Operational qualification (also referred to as “functional testing”) confirms that all functionality defined in the functional specification is present and working correctly. In the case of bespoke software, it confirms that there are no software bugs.

2.2.7 Performance Qualification (PQ) 

Performance qualification (also referred to as “user requirement testing”) confirms that the software will meet the user’s needs and is suitable for their intended use, as defined in the user requirements specification.

2.2.8 Final Report

The last step in this validation method is to write the summary report declaring that the system is fit for its intended use and that every deliverable that was planned has been delivered.

In the V-model, you’ll notice a link between the two sides of the V. For example, the reporting stage verifies the planning stage, the performance qualification stage verifies the user requirement specification stage and ensures that the specifications have been achieved.

2.3 Risk Assessment

Risk assessment may be utilised at various stages of the validation lifecycle. Within the project phase, the risk assessment will review the same document at each stage of the V model to ensure the risk classification and controls are accounted for in the validation actions that are carried out.

2.4 Standard Operating Procedures 

Standard Operating Procedures (SOPs) are a key part of CSV documentation. They outline how the computer system should be used. Any staff using a particular system will be thoroughly trained on the relevant SOPs to ensure they are using the system correctly, in the way it was intended

2.5 Training 

You need to train key users of the system on how to use the system software, applications and procedures.

2.6 Handover 

You need to write a handover plan to define when the application will move into the operation phase and how any disruption will be managed, making sure that the system can be used and supported in a controlled manner.

The handover process must verify the following:

1. The system is fit for purpose.
2. Roles and responsibilities are defined e.g. process owner/s, system owner.
3. All personnel are appropriately trained e.g. standard user, system admin.
4. Operational and support procedures/personnel are in place.
5. Supporting quality controls and personnel are in place to maintain compliance.
6. Any residual risks have been accepted.

The following processes must be in place before the system goes live, and be observed throughout operation:

3.01 Change Management
3.02 Configuration Management
3.03 Patch and Update Management
3.04 Security Management
3.05 Business Continuity Management
3.06 Disaster Recovery Planning
3.07 Service Level Agreement
3.08 Backup and Restore
3.09 Incident Management
3.10 Periodic Review
3.11 On-Going Projects
3.12 Electronic Data Archiving
3.13 Documented Control

3.01 Change Management

You must implement procedures and processes to document, evaluate and approve any changes to the system once it’s live.

3.02 Configuration Management

You must identify and document the functional and physical attributes of the system and controls on their status e.g. live, retired, under amendment.

3.03 Patch and Update Management

Similar to Microsoft Windows or Apple OS, you may need to install updates on the system on both a regular and ad-hoc basis. This will be done on the advice of the supplier but the customer will be included in the planning.

3.04 Security Management 

You need to define the controls required for securing a computerized system in its operational environment. This typically involves authentication controls and access levels controls so the system data can’t be tampered with . In addition, you must provide technical security (such as antivirus software) and a company firewall to protect against spyware and malware.

3.05 Business Continuity Management 

You need to develop a detailed plan to regain access to the system and its data following a disaster such as a power outage, fire damage, water damage or a virus attack. The plan must outline how you will restore critical business processes following a disruption while continuing to provide products or services.

3.06 Disaster Recovery Planning

This is a subset of Business Continuity Management (BCM). It contains the steps to follow to regain access to the hardware, software and data following a disastrous event

3.07 Service Level Agreement 

This is an agreement with both the system supplier and a data centre provider for escalation of issues that includes agreed response and resolution times depending on the issues categorisation.

3.08 Backup and Restore 

Backup and restore is a mechanism to protect electronic information and records against loss of original data. Copies of the system configuration and data are made on a regular basis (e.g. daily) so that it is retrievable in the event of a disaster. To do this, you must copy the software, data and electronic records to a separate, safe and secure area where it is available and protected so you will be able to restore it in its original format if required.

3.09 Incident Management

This will involve recording issues encountered by the system. End users will be able to raise these issues using an electronic IT helpdesk system.

3.10 Periodic Review 

You need to conduct periodic reviews to ensure a computerized system remains compliant with regulatory requirements throughout its operational life, remains fit for intended use, and continually satisfies company policies and procedures. For example, the validation team (in conjunction with relevant stakeholders) might conduct a periodic review every 2 years.

3.11 On-Going Projects

In the operation phase of the life cycle, you might discover that certain aspects of the system need to be updated or changed. For example, the user interface might be causing problems with users not being able to input data accurately. Or you might want to expand the reach of the system or update and improve its processes. You would manage these changes like mini-projects using the V-model approach (as outlined above).

3.12 Electronic Data Archiving 

You need to develop a suitable data archiving strategy that moves data that is no longer actively used in the environment it was created, to a separate data storage area for long-term retention. You would also complete data archiving in the retirement phase of the validation life cycle.

3.13 Documented Control

The computer system is now in operation. You must keep all aspects of the system and the operating environment in a state of documented control to maintain its validated status.

In the retirement phase, the system might be shut down completely or upgraded to a new system. Either way, you need to assess what data needs to be migrated from the existing computerised system, what data needs to be retained and what data needs to be destroyed.

Specific activities in this phase include:

4.1 Data Migration
4.2 Electronic Data Archiving
4.3 Data Destruction

4.1  Data Migration 

Data migration involves moving data from one platform to another. To do this you need to create a data migration plan. The following considerations should be taken into account:

1. That all required data has been moved.
2. The context of the data, its attributes and metadata have been preserved.
3. Any requested transformation has yielded the expected result.
4. No unexpected transformation has been introduced.

Similarly to implementation, you need to take a risk-based approach to migration. You need to perform a data flow analysis exercise to identify points of weakness in the transition from the old to the new system. And you’ll need to provide documented evidence of these actions.

4.2 Electronic Data Archiving

Data archiving is the process of moving data that is no longer actively used to a separate data storage device for long-term retention. You need to develop a suitable data archiving strategy for moving data in this way The considerations for data archiving are essentially the same as for data migration, as you are moving data from one platform to another. The archiving platform may be the same as the live system but with slower and less costly storage for data that is still required to be readily available for trending or updating.

4.3 Data Destruction

Where data is no longer required you may completely remove it from the live system, the archiving solution and any back-ups. You must ensure that the method of destruction completely removes all the data, particularly where it pertains to personal data governed by data integrity regulations (e.g. overwriting or destroying hard disks, shredding or burning rendered off paper records).

Finally, let’s take a look at the supporting processes or activities that take place across different phases of the life cycle such as risk management, document management, repair activity and traceability matrix.

Specific activities in this phase include:

1. Risk Management
2. Traceability Matrix
3. Repair Activity
4. Document Management

1. Risk Management

You need to apply risk management throughout the lifecycle of a computerized system and decide how to manage the process for various categories of systems. You should also look at an approach to conducting risk assessments on computerized systems based on their impact on product quality, patient safety and data integrity.

2. Traceability Matrix

You need to develop a traceability matrix – this is an important project document for tracing all user requirements to design specifications and appropriate verification tests.

3. Repair Activity

You need to develop a process by which non-functional systems (i.e. systems which have stopped working)  are returned to a functional state under the control of a repair activity procedure.

4. Document Management

The documentation associated with CSV is extremely detailed. Someone reading through it should be able to repeat the process simply by following the steps outlined in the document. As a result, the language used must be clear and concise.

Before any computer system is used, documents will outline specifics such as:

• Defining the purpose of the computer system in question
• The features it needs
• The hardware it needs
• When it will be used
• The requirements that it is expected to meet

The specifications defined here will then be used throughout the CSV process – continuing throughout the life of the computer system.

In addition to this, the system will continue to be tested throughout its lifecycle. Rigorous routine testing will be used to show that the system continues to meet the predefined requirements that were laid out in the design phase.

All CSV documentation can be called for review and audit at any point of the system life cycle. It would be expected that the documentation meets appropriate standards at all points.

Even after a company has stopped using a particular computer system, you will need to keep the documentation showing that it was correctly validated while in use in the event that the regulatory authorities need to retrospectively check the data integrity of a past event.

As you can see, the computer system validation process is time-consuming and expensive but necessary in order to keep data quality safe, accurate and secure.

Check out this video from INTERPHEX 2015 for a great introductory conversation about CSV and how it’s implemented within the pharma industry:

As manufacturing processes become increasingly automated, the need for CSV professionals is growing. This trend is only expected to continue.

There is also an acute shortage of trained CSV professionals in certain geographic areas, including Ireland. For this reason, salaries for these roles are extremely competitive .

One of the single biggest misconceptions of the CSV role is that you need to be able to code. This is usually not the case. However, we do sometimes see a requirement for the ability to code in some roles where the job description overlaps with automation engineering. And you will always need a solid understanding of the computer process you will be validating.

If you have the relevant skills, as well as the experience of pharmaceutical or medical device manufacturing, you might be closer than you think to be a great candidate for CSV roles within pharmaceutical companies.

If you want to learn computer system validation, check out our 10-week online Computer System Validation training course.