The interplay between quality and safety is critical in the pharmaceutical industry, as lives often rely directly on the products that are developed and produced. That is why various authorities closely monitor this sector. When it comes to computer systems (e.g., software), they must also meet all the criteria and go through different validation stages to achieve compliance.
This blog will discuss GxP criteria and other standards and regulations firmly entrenched in this sector, how they apply to computer systems, and how the validation is performed. We will also reveal a vendor’s responsibility regarding this market area and how we can assist in developing or transforming already existing software to meet the required criteria.
1. Regulations and standards
Pharmaceutical regulations and standards are defined as the combination of legal, administrative, and technical measures that governments take to ensure the safety, efficacy, and quality of medicines, as well as the relevance and accuracy of product information (Lezotre, 2013; Rägo and Santoso, 2008). These ensure that nothing is brought to market that does not comply with pertinent quality and safety measures.
1.1. What is GxP
Businesses operating in the Health and Life Sciences (HLS) industry are bound by law to comply with GxP rules and regulations determined and regulated by Food and Drug Administration (FDA) in the US and The European Medicines Agency (EMA) in European Union. GxP is a general abbreviation for good practices and encompasses different standards and guidelines in this industry.
G – stands for “Good”
P – stands for “Practice”
x – stands for different fields (e.g., good manufacturing practice (GMP), good laboratory practice (GLP), good automated manufacturing practice (GAMP), etc.)
1.1.1. ALCOA+ Principles
The most central aspect of GxP is good documentation practice (GDP), where requirements on data are described with ALCOA+ principles (see Figure 1). The acronym ALCOA+ defines that data should be Attributable, Legible, Contemporaneous, Original, Accurate, and in addition also Complete, Consistent, Enduring, and Available. It is very much advised that vendors also, as we have, implement ALCOA+ principles to maintain data integrity and traceability, which is usually a precept when working with the pharmaceutical industry.
ALCOA+ principles (Source: Pharma Specialists)
1.2. ISO standards
These GxP requirements have plenty of crossover with other quality standards and accreditations, meaning you can align GxP compliance with your other quality initiatives. Frequently, working for GxP companies involves implementing a quality management system (QMS) since they mainly revolve around traceable, accountable, and secure processes. When it comes to pharmaceutical companies, choosing a vendor with at least some basic certifications by ISO or IEC standards is a common practice. We have collected three important standards to consider when providing software to the pharmaceutical industry.
ISO 9001:2015 – QMS standard is a good way of working towards GxP since data integrity and document control are crucial for GxP
ISO/IEC 27001:2013 – compliance on how to manage information security
ISO/IEC 26580:2021 – software and systems engineering standard which describes methods and tools for a feature-based approach to software and systems product line engineering.
If you are interested to learn more about standards and regulations, we invite you to read our article Digitalization – Understanding standards, regulations and guidelines.
1.3. FDA 21 CFR Part 11
The Code of Federal Regulations (CFR) is a codification of general and permeant rules published in the Federal Register by the Federal Government in the US. Part 11 establishes US regulations on electronic records and signatures (ERES).
It defines criteria under which ERES are trustworthy, reliable, and equivalent to paper records. FDA 21 CFR Part 11 applies whenever information is to be created, modified, stored, transmitted, or accessed electronically in regulatory (e.g., FDA) filings. The purpose of this document is data security, non-repudiation, traceability, and no falsification of electronic data.
1.3.1. Difference between FDA 21 CFR Part 11 ready and compliant software
It is essential to distinguish between those two concepts. When we say that software is FDA 21 Part 11 ready, it means that the software meets the technical specifications of this regulation. When software is validated with all the documentation, SOPs, and training provided, the software is compliant. You can check the official guidance to satisfy the software’s compliance criteria here.
CFR-ready features are:
Every user must log in with their unique username and password, and every action within the software is associated with a user.
A series of audit logs where system and electronic signatures should be logged, and electronic records also be versioned.
Software should allow multiple signatures from multiple users on the same electronic record, displayed at any time.
Electronic records (incl. electronic signatures) shall be exportable to be able to be provided to auditors.
This layer defines user roles within the software. It is not strictly a must-have feature, but it maps very well to laboratory practices and is recommended for implementation.
We at BioSistemika have many experiences developing and transforming software to be CFR-ready. One example is our product SciNote, one of the most popular electronic laboratory notebooks (ELN), widely used in pharmacy. You can check out the product here.
We also provide workshops on this subject. Get in touch with us for consultancy on your specific situation.
1.4. EU GMP Annex 11
Annex 11 applies to all forms of computerized systems used as part of GxP-regulated activities. It is the FDA 21 CFR part 11 European equivalent, and it is a guidance system for electronic records and electronic signatures in the pharmaceutical industry in the EU. Annex 11 and FDA 21 CFR are two essential resources available to regulated life-science professionals regarding the validation of computer systems.
Annex 11 also requires that the supplier must show that they have a QMS, irrespective of whether the supplier is an internal department or an external service provider, a small or large company. It is mandatory that the software development life cycle is defined and integrated into the supplier’s QMS.
1.5. EU GMP Annex 15
Annex 15 describes the principles of qualification and validation of facilities, equipment, utilities, and processes for manufacturing medicinal products as part of a GxP-regulated industry. It also describes the planning and organizing for qualification and validation, documentation, qualification and validation processes, etc.
Here computerized systems are also included in the document and should be validated according to the requirements of Annex 11. Key points in this annex are:
- All qualification and validation activities should be planned and consider the computerized systems’ life cycle.
- That should only be performed by suitably trained personnel who follow approved procedures.
- There should be appropriate quality oversight over the whole validation life cycle
- A risk-based management approach should be used
- The key elements of the site qualification and validation program should be clearly defined and documented in a validation master plan (VMP). This document should include validation policies, an organizational structure including roles and responsibilities, change control and deviation management, qualification, validation strategies, and others.
This document also describes all the qualification stages for computerized systems, which are presented in the article’s next section.
2. Computer system validation process in the pharmaceutical industry
Computer systems in the pharmaceutical industry that have an influence on product quality, patient safety, or data integrity must be validated according to strict national and international legal requirements and kept in a valid state throughout the entire system life cycle (SLC). The term system validation is used in the pharmaceutical industry in the context of satisfying regulatory requirements.
The entire system must be validated — not just each individual piece of software but also interactions between software packages. It is also essential to state that the validation process is done for each installation on every site for each usage or workflow.
Annex 15 describes the validation process in multiple stages, which are:
User requirement specification (URS) – in this phase, all the specifications should be defined, functional and non-functional. All the essential quality elements need to be built in at this stage. The URS should be a point of reference throughout the validation life cycle.
Unit, integration, and systems tests – testing of individual programming steps, known as modules, interactions between modules and the whole system, which is tested against functional specifications from URS
Design qualification (DQ) – here, the compliance of the design with GxP standards should be demonstrated and documented by verifying the URS.
Factory acceptance testing (FAT) – evaluation of the system at the vendor prior to delivery and installation to comply with the URS.
Site acceptance testing (SAT) – FAT may be supplemented by the execution of SAT following the receipt of the equipment at the manufacturing site. With SAT, we prove that transport and installation do not affect the system.
Installation qualification (IQ) – verification of the correct installation of the system, calibration and collection of supplier operation and working instructions, and maintenance requirements.
Operation qualification (OQ) – follows IQ but depending on the complexity of the system, it may be performed as a combined Installation/Operation Qualification (IOQ). Here we test the system to confirm it operates as designed. We also confirm upper and lower operating limits or ‘’worst case’’ conditions.
Performance qualification (PQ) – here, we test the system using production materials. Tests should cover the operating range of the intended process.
From our vast experience in this field, we suggest performing unit, integration, and system tests during all the stages of the development to prevent any defects at the end of the process and therefore reduce the time and cost of the development. Another great practice is to perform design qualifications to show the software functions as stated in URS.
Therefore, the product can be advertised as ‘’validated’’ or ‘’pre-validated’’. Even then, the equipment must still be validated in the user’s environment and workflow. Thus, pre-validation mainly streamlines the process with readily available documentation.
IQ, OQ, and PQ are always performed in the user’s environment within their intended workflow by trained personnel. Vendors can provide documentation and technical assistance for IQ, OQ, and PQ. We usually assist our clients by preparing templates and checklists, user manuals, etc., to perform validation quicker and more easily. Some clients ask us for other validation services like a consultation or more active involvement.
2.1. Good automated manufacturing practice (GAMP)
When it comes to computerized systems in the pharmaceutical industry, it is essential to discuss good automated manufacturing practices (GAMP). This set of guidelines was created by The International Society for Pharmaceutical Engineering (ISPE) to achieve compliant computerized systems in this industry. The guide GAMP®5 issued by ISPE provides a risk-based approach to computer system validation where a system is evaluated and assigned to a predefined category based on its intended use and complexity. Categorizing the systems helps guide the writing of system documentation, including specifications, test scripts, and everything in between. It is essential to state that customized software is considered category 5, which needs the most thorough validation process.
As a part of GAMP, ISPE introduced the V-model concept for system validation, and it is a universally accepted model.
Figure 2: V-model concept (Source: Business Technology For All)
3. What about the changes to already validated software?
In the context of changes to validated systems, it is useful to distinguish between the following cases:
Modification (release or patch updates) – Modifications should be approved via change management and should lead to the creation of a new version, sub-version, or patch level of the application.
Configuration – here, an existing system configuration is changed or adjusted. Those should also be subject to change and version control.
Parameterization only influences the sequence of operations but not directly system coding. Parameter settings should be recorded in the process logs or presented in the system’s audit trail.
When you release a new update for software already validated in the GxP environment, you need to consider that for every software alternation that was not validated before, a new validation must be performed. That goes especially for software updates and some major configurations; therefore, you should think twice if major alternation (etc. patch) is necessary.
For every validation process, a lot of money and time is spent, especially if an interruption in software usage disrupts any vital processes in production, quality control, etc. The validation process usually lasts from 1 to 14 weeks, where many personnel with different responsibilities are involved – project manager system operators, quality assurance personnel, validation team, supplier, regulators, etc.
4. Transforming your software to become CFR-ready for Pharma
If you have already developed software that was not designed according to 21 CFR Part 11 requirements and now consider implementing software in a GxP environment, starting from scratch is not necessary. We successfully finished many projects requiring a software transformation to make them CFR-ready.
Usually, our approach includes workshops with clients where we discuss and consult on how to transform the software and prepare Software requirement specification (SRS) documentation. SRS is the basis for developing the new code for the software or configuring the existing one.
- Pharmaceutical industry is strongly regulated to ensure nothing is brought to market that does not comply with pertinent quality and safety measures.
- Industry is bound by law to comply with GxP rules and regulations determined and regulated by Food and Drug Administration (FDA) in the US and The European Medicines Agency (EMA) in the EU.
- There are three ISO standards you can implement to align with GxP standards and regulations – ISO 9001, ISO/IEC 27001, and ISO/IEC 26580.
- Whenever information is to be created, modified, stored, transmitted, or accessed electronically in regulatory (e.g., FDA) filings, FDA 21 CFR Part 11 applies. The European equivalent is EU GMP Annex 11.
- Software must be validated in the environment it will be used. Validation in the pharmaceutical industry is usually performed as a part of GAMP’s V-model. Vendors can only assist in validation by providing documentation and technical assistance for IQ, OQ, and PQ.
- Updates must be very carefully deployed because validation must be performed each time which is time and cost-consuming.