Home » Pharma Blog » What is Computer System Validation (CSV) in the Pharmaceutical Industry?
What is Computer System Validation (CSV) in the Pharmaceutical Industry?
What is meant by Computer System Validation?
Computer Systems Validation (CSV) – is a process used to test, validate and formally document that a regulated computer-based system does exactly what it is designed to do in a consistent and accurate manner that is secure, reliable and traceable.
The process is used to replace paper and/or handwritten signatures with electronic data in highly regulated environments that impact public health and safety such as pharmaceutical and medical device manufacturing. These industries use computer systems to operate and record a range of processes and activities from manufacturing, product testing, 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.
Computer System Validation Course
Go rapidly from a beginner to an advanced level Computer System Validation expert. Extend you or your team’s role into CSV projects or charge higher hourly rates. Check out our 10-week online Computer System Validation Training Course
SALARY RANGE of US$40,000 – 85,000 based on US job data.
Where is Computer System Validation Used?
Computer System Validation (CSV) is applied to GxP computerized system applications used at any point in the research, clinical testing, manufacturing and distribution process. Examples might include:
Laboratory Information Management System (LIMS)
Laboratory Instrument Systems (LIS)
Clinical Trial Monitoring Systems
PLC for Controlled Packaging Equipment
Supervisory Control and Data Acquisition (SCADA)
Distributed Control System (DCS)
Chromatography Data System (CDS)
Enterprise Resource Planning (ERP) Systems
Manufacturing Execution System (MES)
Batch Record System
Building Management Systems (BMS)
Why Do We Need CSV?
The pharmaceutical manufacturing and medical device manufacturing industries are regulated, meaning that what goes on inside the factory walls are subject to the law of the land. In the 90s, the regulatory authorities for these industries took the decision to replace paper records and handwritten signatures with electronic records.
And CSV is a process that creates an indelible electronic data trail that allows us to treat regulated data and electronic signatures captured in manufacturing (or other processes) as the legal equivalent of paper records and handwritten signatures and have the equivalent level of confidence in their accuracy, reliability and data integrity.
What Are Examples of Computer System Validation Regulation?
The Food and Drug Administration (FDA)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 replace paper records and handwritten signatures legally. This code applies to (bio)pharmaceutical and medical device manufacturers, biotechnology companies and other FDA-regulated industries. Some examples of the controls required are:
Data should be stored in electronic format and can be archived. Electronic records should be as trustworthy as paper records.
The system must ensure that electronic signatures are as trustworthy and secure as handwritten signatures.
Password masking facility should be available in the system.
Password complexity should be required i.e. password should be of minimum character length, etc. Previous passwords can’t be re-used.
Screen lock should trigger after a defined period of time.
Only authorised people can use the system.
The system should have different access levels based on the criticality of the system.
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.
The FDA also requires medical device makers to validate the software and systems used in manufacturing medical devices as part of 21 CFR 820.
Within the EU, medical device makers are required to validate their software and systems. This is regulated under EudraLex Volume 4 Annex 11 on Computerized Systems.
Think of the controls outlined in FDA 21 CFR 11 as what the regulators want to see the computer system to be able to do. Think of GAMP as the approach you take to achieve those controls.
GAMP has enjoyed the support of numerous regulatory authorities and is now a recognised good practice worldwide.
How do you Validate a Computer System?
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. There are four life cycle phases in a computer system according to the GAMP with each phase containing a number of individual activities. (See diagram below)
In order, these phases are:
Concept – high-level overview of the system and design considerations
Project – detailed description of the system and objectives
Operation – how the system will be managed during operations
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. Supplier expertise should be leveraged in each phase of the lifecycle.
Now, let’s take a look at the individual activities in each of the four phases as well as the supporting processes viewed through the project life cycle phase of computerised systems.
1. Concept Phase
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 and ask questions such as, what are the risks to the business implementing or not implementing this system? Where will further risk assessment be required?
This phase contains the following activities:
In this activity, you typically defined the following.
the overall requirements of the system
what critical functions it will be controlling
what are the available options for hardware and software platforms
what is the overall regulatory impact of the proposed system
what is the novelty of the system and its complexity
what is the requirement for document control
what testing is required, what are our considerations for operating and maintaining the system?
what data and records are generated that will subsequently need to be retained
1.2 System Software Categorization
The range of activities required to validate a computerized system is hugely affected by the type of software you are using and will determine the validation approach, the amount of time the project takes and the deliverables:
The GAMP 5 guidelines categorise software into 4 types. These are:
Software Category 1 – Infrastructure software
This is software upon which 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
Parameters may 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)
Software Category-4 – Configured Software
This software is often very complex. It can be configured by the user to meet the specific needs of the user’s business process. But the software code 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 business process.
Examples: Internally and externally developed IT applications, Internally and externally developed process control applications, Custom firmware, Spreadsheets (macro)
Note: There is no Category 2 anymore as it was discontinued.
1.3 Risk Assessment
Think of risk assessments 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 a method to mitigate that risk. 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 and ultimately harm the patient.
1.4 Supplier Assessment
Part of the concept phase will be narrowing down the vendor options and getting an idea of the cost to include in the business case. So you would send out a request for services document with some general details of system requirements to several vendors. The response from the vendor will detail how their system can meet the customer’s or your requirements and an estimated cost. Where the response looks promising a request for a demonstration of the system will be made. The next stage is an in-depth supplier assessment.
2. Project Phase
In this phase, you finalise the planning, develop the user requirement specifications, functional specifications and design specifications. You have the project built then commissioned and qualified. Finally, you hand over the completed project to the end-user or client.
This stage defines what will be validated and what approach you will use. It also defines the roles and responsibilities and the acceptance criteria. This 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.
2.1.1 Validation Master Plan (VMP)
Every regulated pharma organisation should have a validation master plan in place which governs its approach 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 to 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 would 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:
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 where the v-model (see diagram below) controls 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 V-Model (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), proceeding down to (configure and/or coding) and then back to the top right, ending at (reporting). The left-hand side of the V represents what the computer system does (i.e. what you use the software controls 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, 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 set outlined in the URS such as:
how the software works
what data needs to be captured
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 and 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 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, and in the case of bespoke software, 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 users’ 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 see a link with both 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 be the same document but reviewed at each stage of the V model to ensure the risk classification and control are accounted for in the validation actions 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 that use 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.
You need to train key users of the system on how to use the system software, applications and procedures.
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 and make sure that the system can be used and supported in a controlled manner.
The handover process must verify the following:
The system is fit for purpose.
Roles and responsibilities are defined e.g. process owner/s, system owner.
All personnel are appropriately trained e.g. standard user, system admin.
Operational and support procedures/personnel are in place.
Supporting quality controls and personnel are in place to maintain compliance.
Any residual risks have been accepted.
3. Operation Phase
The following processes must be in place before the system goes live and observed throughout operation:
3.01 Change Management
You must put in procedures and processes to document, evaluate and approve any changes to the live system.
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
Similarly to Microsoft Windows or Apple OS, you may need to install updates on the system on both a regular or an ad-hoc basis on the advisement of the supplier with the customer included in the planning.
3.04 Security Management
You need to define the controls required for securing a computerized system in an operational environment so its data can’t be tampered with along with authentication control and access levels controls. 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 (BCP). 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 with agreed response and resolution times depending on the issues categorisation must be in place.
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 this information 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 will discover that certain aspects of the system may 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. And you would manage these changes like mini-projects using the V-model approach.
3.12 Electronic Data Archiving
You need to develop a suitable data archiving strategy for moving data that is no longer actively used in the active environment where 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 under a state of documented control to maintain its validated status.
4. Retirement Phase
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 retained, what data needs to be migrated from the existing computerised system and what data needs to be destroyed.
4.1 Data Migration
Data migration involves moving data from one platform to another and you need to create a data migration plan. The following considerations should be taken into account:
That all required data has been moved.
The context of the data, its attributes and metadata have been preserved.
Any requested transformation has yielded the expected result.
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 that is no longer actively used in the active environment where it was created to a separate data storage area for long-term retention.
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.
5. Supporting Processes
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.
5.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.
5.2 Traceability Matrix
You need to develop a traceability matrix which is an important project document for tracing all user requirements to design specifications and appropriate verification tests.
5.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.
5.4 Document Management
The documentation associated with CSV is extremely detailed. Someone reading through it should be able to repeat the steps involved simply by following the document. 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 – this continues 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, expensive but necessary in order to keep data quality safe, accurate and secure.
Watch Video on CSV
Check out this video from INTERPHEX 2015 for a great introductory conversation about CSV and how it’s implemented within the pharma industry:
The Growth of Computer System Validation Opportunities
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 attractive.
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 do 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.