Medical Device Manufacturers use Rational
Pharmaceutical Companies use Rational
The concept phase addresses early evaluation and planning activities to determine if an automated solution is suitable for supporting a specific business process. High level assessments of benefits and costs may be considered to justify further investment in pursuing potential computerized solutions.
System Hardware and Software Categorization
The following GAMP 4 software and hardware categories are used to establish the validation approach and determine the deliverables.
Unless a very simple control system (PLC and HMI) there is likely to be some elements of infrastructure software.
Infrastructure software in its most simple form is the operating system which the application software resides.
Additional software for managing the infrastructure the process control system includes:
- Operating Systems
- Anti-virus Software
- Active Directory / Domain Controller
- Database Software (SQL / Oracle)
- Server and Network Hardware
- Virtual Environments
- Firewalls, including configuration
- Server and Network Monitoring Tools
- Backup Systems
Configuration relates to adding functionality through standard modules, library items to standard software applications to meet the business requirements.
In a process control system a DCS would be configured from standard modules to control a specific process and would fall under GAMP Category 4.
An electronic chart recorder which is also configured with Input Ranges, Alarm Setpoints, etc. would fall under GAMP Category 3 for while it is has parameters entered under the configuration it does not define functionality or a process flow.
It is important to understand the distinction between true configuration and parameterisation when assigning the category.
Other examples that would fit under GAMP category 3 would be systems that are provided with computerised controllers, including Programmable Logic Controllers (PLC’s) where the application is not modified (although may be parameterised) to meet the business need. Within the pharmaceutical industry there are many examples of these including Labelling and Packaging equipment.
There is no fixed rule as to the validation approach for GAMP Category 3 systems. This should be combined with the impact or criticality of the process that the system is monitoring and / or controlling. It can support decisions as to lifecycle steps that may not need to be performed for example Source Code Reviews, limited verification activities and greater reliance on vendor test documentation.
As with any supplier you should ensure that the software has been performed in accordance with an appropriate quality management system. However the GAMP Category can support the decision as to the level of supplier assessment that needs to be performed (Postal Questionnaire rather than Full Site Audit.
EU Annex 11 states that the need for an audit should be based on a risk assessment refer to the Validation Determination post.
Configured software for a process control system is software applications that are configured to meet specific business needs (see above GAMP Category 3).
GAMP Category 4 – Configured Software range in complexity from simple configuration of SCADA system graphics to complex process control within a DCS or PLC (linking standard library objects to control the process).
Examples of configurable software for a Process Control System includes:
- DCS / SCADA Mimics
- DCS / SCADA Databases (Alarms, Tags, History)
- PLC / DCS programs configured from Standard functions library / IEC61131-3
For GAMP Category 4 software the approach to the computer systems validation may be to use the supplier’s documentation and verification to demonstrate the suitability of the standard modules and limit the regulated company’s verification to the critical functions of the business process and functions to support regulatory compliance (security, electronic records, etc.).
Custom application is software that is generally written from scratch to fulfil the business need. As this software is going the full development lifecycle there is a higher level of risk of errors within the application code.
In terms of a Process Control System GAMP Category 5 software may range from PLC logic (Ladder, Sequence Flow Chart, C++, etc.) to custom scripts written within the SCADA / DCS system.
As GAMP Software Category 5 the level of verification through software testing (FAT, SAT, IQ, OQ, etc.) will be increased. The level and formality of performing and documenting this testing will be determined on the GMP Impact (Product Quality, Patient Safety, Data Integrity and GMP regulatory requirements).
The GxP impact assessment is carried out to determine if the computer system has an impact on product quality, patient safety, or data integrity. All GxP impact computer systems must comply with applicable regulatory requirements.
Perform GxP assessment using the below Questioners.
1. Is the system used to generate data used in support of a regulatory submission?
2. Is the system is used to monitor, control or supervise a GxP manufacturing or packaging process and has the potential to affect Product Quality, Safety, Identity, or Efficacy?
3. Is the system used to hold and/or manipulate clinical study data?
4. Is the system used to monitor, control or supervise packaging and labeling operations?
5. Is the system used to create critical study control data?
6. Does the system hold electronic records that are or could be used in the electronic form to make GxP decisions?
7. Is the system used to transmit e-data/ records to other systems for the execution of GxP activities?
8. Is the system is used for GxP analytical quality control?
9. The system manipulates data or produces reports, to be used by GxP quality-related decision authorization/approval processes, where the data supports the decision process or the electronic record constitutes the master record.
10. Is the system is used to maintain compliance with a GxP requirement?
11. Is the system is used to monitor, control, or supervise warehouse or distribution within a GxP requirement?
12. Is the system is used for GxP batch sentencing or batch records?
13. Is the system used to store GxP documents for example SOPs, Specifications, BMR, BPR, DMF
14. Is the system used for GxP data backup, restore, archival or storage, data security, or access/domain control?
15. Is the system used for physical access to GxP to the environment (i.e. area or location)?
16. Does the system support a GxP application i.e. LAN/WAN?
If any of the above questions are answered “Yes” then the system has a GxP impact and the system requires a level of Validation and control through the Computer Systems Validation.
If all the questions are answered “No” then the system may be deemed not to have a GxP Impact. This should be documented to support the decision not to perform formal validation.
Electronic Records and Electronic Signatures (ERES) Assessment
An assessment is carried out to establish if the system needs to meet the requirements of electronic records and electronic signatures by determining what electronic records are created by the system, how those records are maintained, and how the records will be signed, either by hand or electronically.
Based upon a decision to proceed from conceptual planning, the project phase covers all aspects of system development and implementation. Multiple sub-phases support a controlled approach to providing a compliant computerized solution to support the regulated business process. Each sub-phase will produce key deliverables that provide evidence that the system is fit for its intended purpose, i.e., Computer System Validation.
The system supplier must be assessed to determine their suitability to provide a quality system that meets all requirements. Confidence will be gained through their adherence to a documented Quality Management System and Software Development Life Cycle (SDLC). The assessment may take the form of a basic checklist, a postal questionnaire, or an onsite audit, depending on the outcome of the risk assessment. Supplier selection should then be documented in a report, along with whether the supplier documentation will be leveraged or not.
Risk assessments should be performed at various key stages of the validation process by a multidisciplinary team so that a full understanding of all processes and requirements are covered and taken into account. This helps to identify and manage risks to patient safety, product quality and data integrity.
An initial risk assessment is conducted early on in the project phase so that the results can be used in the validation plan, along with the outcome of activities in the concept phase, to define the depth and rigor of required activities and compile a list of deliverables. This produces a validation approach which is commensurate with the level of risk the system poses.
A functional risk assessment is performed following approval of the functional specification to identify potential risks. Mitigation activities are then planned to manage the identified risks and allow focusing on critical areas, e.g.by modifying functionality, detailed testing, procedural controls or training.
Further risk assessments can be performed during the course of the project such as testing and deployment, and for other activities throughout the life of the system.
A risk assessment uses a simple scoring system documented in a matrix to produce the level of risk. A maximum scoring of 1 to 3 and low, medium and high are used to judge the severity of the risk, likelihood of occurrence and the probability of detection to attain an overall risk level.
The Validation Plan (VP) is produced to define the validation approach, describe the required activities, detail the acceptance criteria and list the deliverables and responsibilities. The VP specifies how flexible and scalable the validation approach will be which is derived from the outcome of activities in the concept phase.
The system overview is a brief description of the system and includes:
- System identification
- Business processes the system supports
- Data managed by the system
- High level functionality of the system
- High level schematic diagram of system architecture/hardware
- All interfaces to external systems
- How data is secured by physical or electronic means
The system overview may be incorporated into a section of the VP.
The User Requirements Specification (URS) clearly and precisely states what the user wants the system to do, what attributes it should have and details any non-functional requirements and constraints. The following areas should be considered:
- Operational and data requirements
- Regulatory requirements including ERES
- System access & security
- Data handling and reporting
- System capability
- Environmental health and safety
- Supplier support – documentation and testing
The Functional Specification (FS) defines the full system functionality including how the user and business requirements are satisfied. It is the basis for system design, customization, development and testing. Supplier documentation should be leveraged wherever possible or referenced from the FS. It must be clear how the requirements are met from the URS and provide sufficient information to allow the design specification to be written. The FS may be combined with the URS as a Functional Requirement Specification (FRS)
The Configuration Specification details the configuration parameters and how these settings address the requirements in the URS. This may be a standalone document or detailed in the FS.
This activity involves documenting both the hardware and software as a combined document (DS) or for larger systems as two separate specifications, Hardware Design Specification (HDS) and Software Design Specification (SDS). It can be merged with the Functional Specification as the Functional Design Specification (FDS).
Design Reviews are conducted to verify that the design conforms to required standards; the FS meets the requirements defined in the URS and that the requirements can be traced through the design documents in preparation for testing. The output from the risk assessment is also considered in the review process. A design review report documents the outcome of the design review process.
This is a process where source code is planned and written in accordance with pre-defined programming standards.
If applicable, a code review is performed to detect and fix coding errors before the system goes into formal testing. It verifies that the software has been developed in accordance with the design and programming standards have been followed.
A Data Migration Plan is created when a system requires data loading from an existing system. It describes the activities and deliverables required to select, remove, cleanse, migrate and verify all data to assure its security and integrity. Data can be manually or automatically loaded/migrated, however if any critical data has been manually entered, an evaluation should be carried out to ensure its correctness.
Testing is carried out to verify that installation and configuration has been conducted in line with specifications and that the functionality is challenged at subsystem and system level. This verifies that system components perform their tasks separately, that the subsystems integrate correctly and that the system meets the requirements and expectations of its users. The testing approach is described in a test plan as either a section within the validation plan or as a standalone document. Where possible at each stage, any previous testing should be leveraged, which is defined in the plan. The plan also defines the different types and details the level of testing (e.g. installation, unit, system, acceptance) that will be required for a project. The results from the outcome of the risk assessment will define how precise the depth and rigor of testing shall be and the level of testing will be scaled appropriately. The plan will specify the test environment (development, test, or production) in which testing shall be performed, the use of any tools to be employed for testing and test data requirements.
The installation verification, functional verification and requirements verification testing documents are generated against pre-approved specifications. Test cases are written in test steps as instructions to be followed to test whether the system satisfies the defined acceptance criteria appropriate for the test level. The test steps are written in sufficient detail so that testing is repeatable with consistent results. A printed copy of the approved test case document is executed and the test steps annotated to record the test results. Verification against the expected result defines whether the test step is a pass or fail. Evidence produced during test execution (e.g. reports or screen prints) is attached to allow an independent review and approval of the results. Test results are reviewed, summarized and approved as a standalone test report or as part of the executed document.
System Operating Procedures should be written to provide clear unambiguous instructions to personnel as to the accepted process of completing a particular operation in a systematic, consistent and safe manner. User manuals should be leveraged wherever possible.
Key users must be trained in the use of the system software, applications and procedures as necessary for the development, maintenance, testing and support of the system.
A System Support Plan defines the supporting organizations and procedures to support and maintain the quality/validation of the system during its operation phase.
A Service Level Agreement (SLA) documents a mutual agreement for the service provided between all parties. It should clearly define service, document and data ownership and ensure accountability, roles and responsibilities are established. The escalation process should be fully described along with the service performance criteria.
A plan should be written to define when the application will transition into the operation phase and how any disruption will be managed. The risk management process could be used in this process together with a back out plan. It should ensure that project and validation / verification deliverables are complete prior to handover.
When the system is ready to be released for routine use, a certification statement is created detailing the following:
- System name and version
- Date of release
- Department using the system
- The activities and deliverables relating to the release
- Restrictions on use (if any)
- Open incidents (if any)
Deployment activities include the installation, configuration, data migration and testing of the system and components on the final operating environment (production).
The Validation Report (VR) summarizes the activities carried out during the project, describes any deviations, with justification, from the Validation Plan (VP), lists any limitations or restrictions on use, summarizes any incidents and details any outstanding and corrective actions.
A certification statement concludes whether the validation was successful or not and approves or declines the system for its intended routine use.
An Interim Validation Report may be issued if all post go-live activities are not complete.
The Operational phase of the typical System Life Cycle is supported primarily through Standard Operating Procedures developed and verified as key deliverables during system development.
Key processes to consider include incident and problem management, system backup and recovery, system administration, change and configuration management, ongoing access controls, and periodic review.
Emphasis is on maintaining a controlled and validated state for the system through the remainder of its life.
Backup and restore is a routine process consisting of copying software, data and electronic records to a separate safe and secure area. This information is protected, available and when required, able to be restored, uncorrupted in its original format.
Backup and restore is not the same as the archiving and retrieval processes.
The continuity plan defines the approach to test all or part of a system’s restoration process. This verifies the activities required to get a system or its component parts in an operating condition again in the event of a disaster. Periodic continuity testing should be conducted as a tabletop or full test to verify recovery processes are up to date.
A schedule is created to detail the test type and frequency depending on system criticality and risk.
The cumulative effect of changes to a system could affect its validated status. Periodic reviews are performed to ensure that the computer system remains within both company and regulatory compliance, and is fit for its intended use.
The review evaluates the compliance status of the entire system and plans any required corrective action activities. The frequency of review depends on such things as system criticality, risk, business impact and complexity. However the frequency interval is generally not greater than 3 years.
Data archiving is the process of removing data and electronic records that is no longer actively used to a separate, secure data storage area for long-term retention.
Data that must be retained for regulatory compliance has to be archived and be available for retrieval when required. Records retention requirements should also be considered with respect to the protection, preservation, and confidentiality of electronic records, including their associated audit trail information.
Archiving and retrieval is not the same as the backup and restore processes.
Eventually, any system will reach the end of its productive life, often driven by advances in technology and changes in the needs of supported business processes. The final phase of the typical SLC focuses on activities that are important for the effective decommissioning of the system and transition to a new system to support it. Particular attention should be given to the migration or archive of critical business data to ensure its retention is consistent with company policies and regulatory requirements.
A decommissioning plan must be prepared for systems that are to be retired from operational service so that the process is documented and controlled. Consideration must be taken into account with regards to the archiving of data and records retention requirements, along with any hardware disposal.
Traceability must be documented to identify the connection between the results
of the risk assessment, via the requirements specification,
design and through all testing to individual test cases.
The change management process defines the requirements for assessing, documenting and managing changes to ensure systems remain in a validated state and applies to software, hardware, configuration data and documentation.
The process requires all planned and unplanned changes to be planned, assessed, executed and closed in a controlled and compliant manner.
Project change control is used to manage changes made to any approved primary design documents, project scope changes or changes that will have an effect on product quality, patient safety, data integrity, project cost or schedule.
The incident / deviation management process defines the requirements for managing incidents / deviations for the entire system lifecycle. It details the recording, analyzing, resolution and closure of faults, anomalies and problems that have been identified during the project phase, testing and operation of the system.
Incident logs should be created to allow the collection and tracking of incidents.
Traceability must be documented to identify the connection between the results
of the risk assessment, via the requirements specification,
design and through all testing to individual test cases.
The configuration management process defines the identification, control and status for configuration items (e.g. software, objects) which are under change and version control; as well as the controls, procedures, tools and processes to manage the configuration modifications.
The access and security management process defines the requirements for the security and integrity of a system. Physical and logical security protection mechanisms should secure the system and data against deliberate or accidental loss, damage or unauthorized change. Access requests and permissions should be defined with regard to the initiation, authorization, amending, revoking, recording and auditing of access rights.