COMPUTERIZED SYSTEM LIFE CYCLE
PURPOSE:
The purpose of this procedure is to define the system life cycle methodology that shall be used while implementing GxP computerized system to ensure that system remains in state of validation throughout the system life cycle.
SCOPE:
This SOP is applicable for all GxP computerized system at all the manufacturing sites & companies and affiliates.
RESPONSIBILITY:
Project Team Member’s:
Develops project deliverables as defined in PVP.
Prepare Qualification test scripts.
Document discrepancies that occur during test execution.
Assists in the resolution of discrepancies that occur during test execution.
Execute the Qualification Test Scripts authored by other Project Team Members.
Ensures that the approved project deliverables are submitted to the Process owner for the archival purposes.
Performs software code reviews (if applicable).
Perform & documented Risk Assessment during the different phases of system life cycle procedure for the system.
System Owner:
Accountable for the technical aspects of the project.
Responsible for the technical quality of the project by performing Technical Reviews on the project deliverables, which focus on the completeness and accuracy of the technical aspects of the project to ensure that the deliverables are technically correct and meet the technical requirements of the project.
Ensure that all technical SOPs required for operation, Maintenance and Use of the system are prepared and followed.
Resolves technical issues along with Supplier / Service Provider and concern stakeholders.
Reviews and approves project deliverables SOPs, System Administrator’s Guides, and CCs (if applicable).
Responsible for the administration and maintenance of the system.
Participate in the Risk Assessment during the different phases of system life cycle procedure for the system.
Ensure resources support in operational Phase of the Validation effort/activities.
Ensure that system follows the effective change management procedure.
Review audit reports, respond to findings, and take appropriate actions to ensure compliance.
Process Owner:
Accountable for the business aspects of the project.
Responsible for the business quality of the project by performing Subject Matter Expert (SME) Reviews on the project deliverables, which focus on the completeness and accuracy of the business aspects of the project to ensure that the deliverables are functionally correct and meet the user requirements of the project.
Responsible for the development, revision, and compliance of business SOPs.
Reviews and approves project deliverables, User/Training Manuals, and CCRs (if applicable).
Participate in the Risk Assessment during the different phases of system life cycle procedure for the system.
Ensure resources support from business user department in operational Phase of the Validation effort/activities.
Ensure that all Business/Process SOPs required for operation, Maintenance and Use of the system are prepared and followed.
Ensure that system follows the effective change management procedure.
Review audit reports, respond to findings, and take appropriate actions to ensure compliance.
Maintained the system in validated status throughout its lifecycle.
Quality Assurance/ Corporate Quality & Compliance:
Ensure that CSV activities are being carried out in accordance with the internal procedures and applicable regulatory requirements.
Review and Approval of CSV deliverables as outlines in the specific Project Validation plan and /or variant document of PVP.
Participate in risk assessment process for determining level of validation required for the systems and approving exemptions with appropriate justifications (where deemed necessary).
Participate in Supplier/ Service Provider Assessment & evaluation.
Review & approve change control request (if required) as per procedure.
Auditing the systems at planned periodic intervals to ensure that they are compliant to defined policies, guidelines & SOPs.
Site Quality Head shall be accountable for implementation & ensure compliance of this procedure.
Note: The QA can have members from corporate Quality & Compliance team (CQC) and /or QA-IT Compliance and /or plant QA.
QA-IT Compliance:
Accountable for the validation aspects of the project.
Responsible for the Validation of the project by performing validation Reviews on the project deliverables, which focus on the completeness and accuracy of the validation aspects of the project to ensure that the deliverables are complete, consistent, clear and adhere to Good Documentation Practices (GDP), as well as comply with applicable policies, standards and procedures.
Reviews and approves project deliverables, SOPs, System Administrator’s Guides, and CC Rs (if applicable).
Coordinates, tracks, and reports validation activities for the project.
Trains/assists the Project Team members in the use of the CSV methodology.
IT Team:
Accountable for the infrastructure aspects of the project.
Responsible for the infrastructure of the project by performing Technical Reviews on the project deliverables, which focus on the completeness and accuracy of the infrastructure aspects of the project to ensure that the deliverables are technically correct and meet the infrastructure requirements of the project.
Review project deliverables, including the Infrastructure Test Scripts for executing IQs/OQs, SOPs, System Administrator’s Guides, and CCRs (if applicable).
Responsible for the development, revision, and compliance of infrastructure
SOPs, and System Administrator Guides.
Supplier/ Service Provider:
A Supplier/ Service Provider is contracted to provide additional products or services the project where required, and also act as another member of the project team.
DEFINITIONS:
Project Team: Project team is the group responsible for the overall adherence to this SOP and for planning and executing the project. It consists of a system owner, Process owner and a variable number of project team members, who are brought into deliver their tasks according to the Project schedule. Project team members consist of representatives from Business users, QA-IT Compliance, QA, IT Personnel (Infra & Application), system owner, Process owner, Supplier / Service Provider (including Implementation Partner) and other stakeholders (if any).
System Owner: The person ultimately responsible for the availability, support and maintenance of a system, and for security of data residing on that system. This person is usually the head of the department accountable for the system support and maintenance although the role can be allocated to any person other than head of department based on specific knowledge of the system. The system owner is responsible for ensuring that the computerized system is supported and maintained in accordance with applicable SOPs. Responsibility for control of system access should be agreed between process owner and system owner. The system owner may also be process owner.
Process Owner: The person ultimately responsible for the business process or processes being managed. This person is usually the head of the functional unit or department designee using that system. The process owner is responsible for ensuring that the computerized system and its operations in compliance and fit for intended use in accordance with applicable SOPs throughout its useful life. Process owner also act as Project manager. Ownership of the data held on a system should be defined and typically belongs to the process owner.
Computer System: A computer system consists of the hardware, network components, operating system, and application software.
Computerized System: A computerized system consists of hardware, Application software and network components, which together fulfil certain functionalities. It can also be defined as a logical entity partially or entirely controlled by computers but may also include some equipment, utilities, sensors & actuators along with the governing procedures. E.g. Building Management System; Automated manufacturing / Laboratory System; Document Management System and Adverse Drug Reporting System.
Computerized System Validation: Achieving and maintained compliance with applicable GxP regulations and fitness for intended use by:
The adoption of principles, approaches, and life cycle activities within the framework of validation plans and reports.
The application of appropriate operational controls throughout the life of system.
GxP Compliance: Meeting all applicable pharmaceutical and associated life science regulatory requirements.
PROCEDURE:
General Considerations: This section describes the System life cycle (SLC) with following details:
Computerized System validation approach shall be followed as per annexure-21 (Computer System Validation Deliverable Flow) Overviews of phases describing purpose & objective.
The activities required to be executed in each phase with identification of documents/deliverables being generated as on outcome.
Details of each documents – How the documents is created, reviewed and updated; procedures required to be followed to develop the document Contents of each of the documents.
Project Team scanned approval signatures and date shall be accepted on validation deliverables, provided the scanned signatures and dates are made in the order required on each deliverable. i.e., the team members’ scanned approval signatures and dates must be made on copies that contain the signatures and dates of the preceding approval signatories.
All Validation deliverables/document are version control, any change/update in approved deliverable/document, after system released for operational Use (operational phase) shall be handled through change management for computerized system SOP.
For any validation document number; Project team shall follow the defined numbering procedure in this SOP.
Project Manager shall identify the Process owner, System owner and Project Team members as Project team who will involve in different phases of Computer system life cycle for various activities.
All the Templates which are parts of this SOP shall be considered as reference templates, Author of document based on need can add any section if required and if any defined particular section not relevant write as “Not Applicable”.
Procedure for Identifying the Scope of Validation The result of the GxP Assessment shall decide whether Validation required for computerized system. If Outcome is, “GxP Applicable” follow this procedure “computerized system lifecycle for validating the system.
All systems, which handle data, or processes which fall under the impact of GxP or any other regulatory requirements must be validated.
A search can be conducted to determine whether the application has been validated. If this is the case, User may take reference of the documents if required.
If required any “Non GxP Applicable” systems that process data critical to operations of the business. Quality assurance, IT, QA-IT Compliance responsible person, HOP ·of User department may consider the validation of such systems as a part· of good business practice
Procedure for Defining the extent of Validation
The result of the GxP Assessment, system category, complexity, novelty, risk and use of the system shall be considered to define the extent of validation of any computerized system.
Classifying the system into different categories, this section defines the procedures for classification of computer systems into various categories.
These categories are based on increasing risk & complexity of system with the progression from Cat1, standard software (Cat 3) to Custom software (Cat5).
All the system required to be implemented having GxP applicable shall be classified into software Category using the GxP assessment checklist.
SOFTWARE & HARDWARE CATEGORIES
SOFTWARE CATEGORIES AS PER GAMPS
SW Category
- Infrastructure –
Description
Layered Software (i.e. upon which specifications are built)
Software used to manage the operating environment
Examples
Operating Systems
Database Engines
Middleware Programming languages
Statistical packages
Spreadsheets
Network monitoring tools
Scheduling tools
Recommended Validation Approach
Version control tools
SW Category
- Non-Configurable
Description
Run-time parameters may be entered and stored, but the software cannot be configured to suit the business process.
Examples
- Firmware-based applications
Commercial off the shelf (COTS) software
SCADA
Human Machine interface
Recommended Validation Approach
Abbreviated Life cycle approach
URS
Risk-based approach to supplier assessment
Record version number, verify correct installation
Risk-based tests against requirements as dictated by use
Procedures in place for maintaining compliance and fitness for intended use.
- Configurable
Description
Software, often very complex, that can be configured by the user to meet the specific needs of the user’s business process. Software code is not altered.
Examples
- LIMS
- Data acquisition systems
- SCADA
- ERP
- Clinical Trial Monitoring
- DCS
- ADR Reporting
- CDS
- EDMS
- Building Management Systems
- Human Machine interface
Recommended Validation Approach
- Life cycle approach
- Risk-based approach to supplier assessment
- Demonstrate supplier has adequate OMS
- Some life cycle documentation retained only by supplier (e.g. Design Specifications)
- Record Version number, verify correct installation
- Risk based testing to demonstrate application works as designed within the business process.
- Procedures in place for maintaining compliance and fitness for intended use.
- Procedures in place for managing data.
- Custom
Description
Software custom designed and coded to suit the business process
Examples
Varies, but includes:
- Internally and externally developed IT applications
- Internally and externally developed process control applications
- Custom ladder logic
- Custom firmware
- Spreadsheets (Macro)
Recommended Validation Approach
Same as for above Category, additional More rigorous supplier assessment, with possible supplier audit.
Possession of full life cycle documentation Design and source code review.
HARDWARE CATEGORIES AS PER GAMP5
HW Category
Category 1
Description
Standard Hardware Components
Typical Approach
Standard Hardware components should be documented including manufacturer or supplier details, and version numbers. Correct installation and connection of components should be verified .The model, version number and where available serial number of pre-assembled hardware should be recorded Configuration and Change Control apply.
Category 2
Description
Custom Built Hardware Components
Typical Approach
Custom items should have a Design Specification and be subjected to acceptance testing. The approach to suppler assessment should be risk-based Custom and documented. Assembled systems using custom hardware from different sources require verification confirming compatibility of interconnected hardware components. Any hardware configuration should be defined in the design documentation and verified. Configuration and Change Control apply.
Note: Examples of software provided in each category are purely for guidance, it is not intended to imply that all software of a particular type always fit into a particular category.
Combining of validation deliverables due to nature, size, complexity, novelty, risk and use to which the system is put shall be addressed in project validation plan.
Enterprise systems; some large enterprise systems may have some modules/flows etc.; that handle GxP data and some do not. If the boundaries of the modules/flows can define properly then, based on that GxP and Non GxP can be made; only GxP modules/flows need to be validated.
Supplier/ Service Provider Assessment:
A Supplier / Service Provider assessment may be conducted based on system category along with complexity & risk as per respective procedure for Supplier/ Service Provider assessment.
System Life Cycle (SLC) Model:
The SLC concept; a systematic approach that defined the stages involved in an information system development/implementation project, from the Concept Phase to Retirement/decommissioning Phase of a computerized system.
The SLC model represents; a high level view of the processes used on a software/ system development or maintenance projects, from initial requirements to delivery of the system
V-Model approach shall be used for developing/implementing any GxP system in the organization. The SLC shall comprise of the following phases:
Phase
I – Concept/Project initiation Phase
II – Project Phase
Ill – Operation /Maintenance Phase
IV – Retirement/Decommissioning
Each of the phase mentioned above consists of activities which are required to be executed as a part of project execution and shall have some deliverables generated as an outcome of those activities. The details of each of the phase are stated in the subsequent section of this SOP
The SLC model is an elaboration of the V model. All documents required to be generated must be identified in the Project Validation plan (PVP) for the system.
Some of the activities defined for a system shall be subject to iteration when more knowledge of the system or Supplier / Service Provider available, for example Risk Assessment, enhanced user requirements.
Concept I Project Initiation Phase:
Project is initiated when there is a need from the Business to have an automated solution for their Business requirements or system, which undergoes a change/upgrade.
Details of the business requirement are studied by the cross functional team (IT, Business User, SME, QA, and QA-IT Compliance) and documented User/ System requirement specification.
Approval of the User / System requirement specification document from management (Project Sponsor), the project can be formally kicked off and Change control shall be initiated for the Project.
When purchase any equipment instrument and computer system is part of that then, Business User department shall prepared URS document or any other format but approval from QA-IT Compliance & IT Department is must on that document.
A feasibility study is conducted and evaluation is done for multiple solutions available in market from different Supplier / Service Provider and as a part of this study, a decision is made to make /buy the suitable solution and proceed to project phase or not.
URS should clearly and precisely define what the user wants to the system to do. It should define the functions to be carried out, the data on which the system will operate. The URS may also define any non-functional requirements, constraints. The emphasis of the URS should be on required functions and not on the methods of implementing those functions.
Some general guidelines should be kept in mind while finalizing the URS:
- URS must only state the essential business needs from a user perspective, rather than various design aspect.
- Each requirement must be uniquely referenced to easy traceability.
- Requirement must not be repeated or contradicted.
- Each requirement must be testable & verifiable.
- The requirements should be defined at a high level as compared to the requirements defined in the FRS
Wherever possible, requirements should be prioritized. It should be to identify essential and desirable requirements.
Following deliverables must be generated as a result of execution of this concept/Initiation phase –
- Change control
- User/ System requirement specification (URS/ SRS) Project Phase
This phase defining the approach for successful implementation of the system. Project phase is further divided into no of stages-
- Planning
- Specification, Configuration and/or coding
- Qualification
- Reporting/Implementation
Project phase shows how these stages and supporting processes (such as risk assessment, change management and document Management etc.) are part of the computerized life cycle. The stages are equally applicable to the project phase and to subsequent changes during operation.
Project phase is made up of generally sequential stages; detailed activities often will be performed in parallel or with some overlap.
Planning Stage: this stage of the project phase must focus around planning and defining the approach for successful implementation of the system.
New System required to be implemented in Environment should be assessed for its impact from regulatory perspective using the GxP
Assessment checklist
Supplier/ Service Provider Assessment; to fulfill a regulatory expectation & good business practice conduct Supplier / Service Provider assessment of the potential Supplier/ Service Provider.
Once the Supplier/ Service Provider is finalized for a system, then identified Process Owner needs t6 ensure that NOA and SOW are signed off (if applicable)
ER/ES Assessment; Based on the applicability of ER/ES, Project Team shall complete the ER/ES assessment in planning stage and document the requirement compliance status in ER/ES Assessment checklist
Project Validation Plan: Project Team should prepare the Project Validation Plan (PVP).
PVP should be developed during this planning phase of the SLC. A project validation Plan shall be created to identify and define the validation strategy and deliverables generated as an outcome of the execution of the strategy.
The PVP should be project specific and describes the approach for the validation of the system, required activities and deliverables.
The PVP ensures that the system is validated according to the facility’s standard, established IT procedure and department validation practices and applicable regulatory requirements.
In case of Enterprise System with high complexity (such as SAP etc.) and a group of similar GxP Computerized system such as standard COTS in Laboratory /Manufacturing area, a common Project Validation Plan (PVP) shall be prepared.
Following deliverables must be generated as a result of execution of this planning phase/stages-
- GxP Assessment
- Electronic Record & Electronic Signature Assessment
- Supplier/ Service Provider Assessment (if applicable)
- SOW/NOA (if applicable)
- Project Validation Plan (PVP)
Specification, Configuration and/or coding stage; this phase includes the identification, analysis and documentation of information about the system and its intended use. Also comprises of development/configuration activities required to be executed during SLC.
The number and level of details of the specifications will vary depending upon the type of system and its intended use.
For Standard COTS (cat3): A simple approach consisting of one level of specification (URS), is typically applicable.
For Configurable COTS (cat4):
Following approach consisting of 3 level of specification (URS, FRS & CS) is typically applicable. The number of documents required to cover these 3 levels will depend upon the complexity & impact of the system. For example, a simple system with cat 4 the functional and configuration specification documents may be combined into one document.
For Custom Application (Cat 5):
Following approach consisting of 4 level of specification (URS, FRS, OS, and Module specification) is typical.
The number of documents required to cover these 4 levels will depend upon the complexity & impact of the system.
Functional Requirement Specifications (FRS); Supplier / Service Provider or Implementation partner shall develop and provide the FRS to Project team for review & Approval.
If functional requirement specification not provided by Supplier / Service Provider, Project team along with Supplier / Service Provider shall developed FRS.
FRS defined what the system should do, and what functions and facilities are to be provided. Some general guidelines should be kept in mind while preparing the FRS:
- FRS must state essential business needs from a functional & technical perspective.
- Each requirement specified in the URS document for the system shall be addressed in the FRS document. In case any specific requirement defined in the URS cannot be implemented as a part of the system then reason for the same shall be addressed.
- Each functional requirement must be uniquely numbered for each traceability
- Requirement must be unambiguous
- Each requirement must be verifiable and /or testable
- FRS document serve as the foundation to implement the functionality.
During SLC, qualification testing of the system should trace back to the FRS through RTM to demonstrate that functionality of the system as defined in FRS meets and satisfies.
Design Specification; the system design specification is a description of what software should do and how it should do.
For each requirement, a set of one or more design elements may be produced.
Supplier / Service Provider or Implementation partner shall develop and provide the Design Specifications to Project team for review & Approval.
If Design specification not provided by Supplier/ Service Provider, Project team along with Supplier / Service Provider shall developed OS.
For simple or small systems, it may be possible to include the design specifications into FRS. For any such cases, the approach should be clearly defined in the PVP.
For Custom (Bespoke) Software, it is mandatory to develop both Hardware & Software Design specification.
Complex systems (configurable COTS) may require a further hierarchy of specifications covering Hardware design specifications and configuration specification. –
Some general guidelines should be kept in mind while preparing the DS:
- The Design Specification must state the system design from a technical and infrastructure perspective.
- Each Design specification statement must be stated with technical clarity
During the SLC, the qualification testing of the system should be trace back to the OS through RTM to demonstrate that the design of the system as define the design specification meets and satisfies the functional requirements as required by the business users.
Configuration Specification (CS): For category 4 system, Supplier /Service Provider or Implementation partner shall develop and provide the
CS to Project team for review & Approval.
If Configuration specification not provided by Supplier / Service Provider, Project team along with Supplier / Service Provider shall developed CS.
The system configuration describes the configuration of the implementation of the system from a business, technical and infrastructure perspective.
The configuration specification includes the configuration items for the application hardware and software, operating system, interface (if any) and data for the implementation of system.
The CS serves as the basis for further development or configuration activities for the system.
For configurable COTS Application, it is mandatory to develop the Configuration specification.
Software Code; All details of Software code numbering, pattern and others defined in Design specification and verify the same in software code review checklist ( Code review shall be perform in case of change in the program and new program development).
Following deliverables must be generated as a result of execution of this phase /Stage:
- Functional Requirement Specification (FRS)
- Design Specification (OS)
- Configuration specification (CS) (for Configurable COTS)
- Software Code; Code review (for bespoke systems)
Functional Risk Assessment; A detailed pre risk assessment shall be conducted to address the following.
- Assessment of risk exist in requirements/specifications
- Determination of the extent of validation
- What aspects of the systems are critical to product quality & patient safety and data integrity
- What aspects of the systems are critical to business
- Determination of extent of testing is required for the systems
- Risk to be considered for release of the system into operational phase.
Project Team shall perform pre risk assessment, identified risk scenario, risk analysis and evaluation. Mitigation control shall be defined based on evaluation of the risk.
Mitigation control shall be verified during qualification phase.
Upon completion of mitigation controls, risk review shall be performed.
Evaluation shall be done to see if any risk are introduce as a result of the identified risk being controlled. Based on post risk assessment, further decision shall be taken.
Qualification Stage; during this phase of SLC, the system is thoroughly tested using the pre-defined Test scripts defined in qualification protocol.
Qualification testing shall cover all the requirements defined in the URS,FRS, other specification & Risk Assessment documents. In case any of the requirements are not covered in the qualification Testing phase and corresponding procedural controls also do not exist, then appropriate justification should be provided in the RTM.
Requirement Traceability Matrix shall be prepared to ensure that all requirements tested in Qualification phase.
At this phase/stage, qualification protocol shall be executed to verify the correctness and robustness of the system.
Successful execution of the qualification testing confirms that system meets the pre-determined requirements.
Testing in general must ensure that the entire system works as intended and complies with applicable regulations.
The qualification protocols and test scripts must be designed in such a way as to provide sufficient and appropriate documented evidence to determine that acceptance criteria have been met or not.
The Qualification strategy/approach must be based on strong risk management principles. Functions and processes that are determined via an assessment to be high risk must have more rigorous testing than those to be of lower risk.
For standard COTS (cat3) system: It is recommended to execute testing to demonstrate fitness for intended use and to allow acceptance of the system against user requirement.
For Configurable COTS (cat4) system: It is recommended to execute testing for verification of configuration and testing of installation may occur at any of the testing levels depending on the system.
For in house developed applications or hired Supplier/ Service Provider for customized application (bespoke systems), it is recommended to conduct unit/module testing, system testing, integration testing (as applicable) using pre -defined test scripts.
If Supplier / Service Provider provided validation documents are well documented and meets all the requirements of this SOP, then Supplier / Service Provider doc9m’ents shall be acceptable and these shall be reviewed and approved by authorized personnel.
If Supplier / Service Provider provided qualification protocols are well documented and meets all pre-defined requirements can be leveraged to reduce subsequent testing in IQ/OQ/PQ protocols by given reference and justification. Verify the traceability between requirements & verification testing to ensure that each requirement verified adequately.
Environments: The following environments are advisable, but may vary for the different systems and their complexity /nature. Same shall be addressed in Project Validation Plan;
- Development Environment
- Validation Environment
- Production Environment
Qualification testing methodology (IQ/OQ/PQ) in different environment should be defined in Project Validation plan. Preferable in Multiple environments, Qualification Testing (IQ/OQ/PQ) shall perform and documented for Validation & production environment.
Qualification protocols (NQ, IQ, OQ & PQ) must define testing strategy and shall be developed.
Protocol should reference and interpret the relevant GxP regulations, to assist the Project team and Supplier to deliver a complaint system meeting GxP requirements.
Test Scripts (TS) for NQ/IQ/OQ/PQ shall be developed.
During execution of TS, Test Evidence shall be capture test evidence shall be signed by manual /digitally, digital sign shall be done on last page of test evidence attachment however manual sign done on each page of test evidence attachment. During digital signature compiled by (sign/date) shall be removed from each page.
Each test script must be pre-approved and post approval once execution completed along with discrepancy (if any) status.
Installation Qualification Protocol (IQP) should confirm that; System has been installed as specified in design document; Specified hardware has been assembled and installed correctly. All the connection such as power supply, network is installed as specified.
Operational Qualification protocol (OQP) should confirm that, Testing or Verification of the system against specifications to demonstrate correct operation of functionality that supports the specific business process throughout all specified operating ranges.
Performance Qualification Protocol (PQP) should confirm that, System is capable to demonstrate fitness for intended use and to allow acceptance of the system against specified requirements.
Network Qualification: A separate infrastructure Qualification protocol (NQP) shall be prepared by IT to perform the qualification of all infra components, which are required to implement the software application or based on the design /architecture of application.
Based on complexity & risk of the system, Infra component qualification merged with IQ& OQ protocol of software application. Hardware Qualification (like Server, workstation etc) shall be performed prior to installation of any Software application on that.
Discrepancy Handling: All discrepancies that occur during qualification Testing should be documented .The details of all discrepancy forms should be recorded in Discrepancy Log which shall summarize all the discrepancies that occur during the execution of the qualification Tests.
Quality assurance or QA-IT Compliance (as applicable) shall assign unique number to each Discrepancy form and maintained the log project wise as per current version of SOP” Computer System Validation Document Numbering Procedure”.
All discrepancies that occur during Qualification Testing will be assigned a discrepancy type as follows:
Discrepancy Type
System: The discrepancy is due to a failure of the application software.
Environmental/ Setup: The discrepancy is due to environmental and/or configuration parameters being set up improperly.
Script: The discrepancy is due to the test script being incorrect.
Tester: The discrepancy is due to an error on the Tester’s part when executing the test script.
Other: The discrepancy is due to causes not covered by the above mentioned Discrepancy types.
All discrepancies that occur during qualification Testing will be assigned a Severity level as follows:
Severity Level
Critical: A discrepancy determined to have a potential impact to product quality, purity, strength, and integrity, an event representing a significant breach of GxP or a failure of a GxP system.
Major:
A discrepancy determined to have no impact to product quality, purity, strength, and integrity. Impact to product and / or process can be determined through preliminary analysis of data available at the time of discrepancy. No evidence of a failure in GxP systems.
Minor:
Not a GxP failure, no product impact.
All discrepancies status shall be recorded in Qualification report. Based on impact of discrepancy, risk assessment may be required to perform for that particular requirement and propose mitigation (procedural or technical) to close the same.
Qualification Report: Project Team executes the pre-approved test script identified in the qualification protocol.
Executed and completed test script submitted to identified reviewer & Approver.
Once all identified Test script post approval completed, Qualification report shall be developed and submitted for review and approval.
The testing is considered as completed successfully once Qualification report approved by Quality team along with closure of all discrepancy (if any).
Data Migration; Data migration may take place multiple times during the life cycle of a computerized system.
- During initial system development and deployment
- During Application upgrades
- During System Retirement
During data migration several activities to be performed and tested. The Entire process of data migration shall be documented in project validation plan.
If data from older version system is not required to be migrated to new system, the same should be clearly documented in PVP. However, the requirements of data archival shall be assessed using system retirement/Decommissioning Procedure
The data from legacy systems needs to be migrated to the new system by many ways. What method to choose depends on the complexity and amount of data to be migrated. Large data sets will typically migrate via automated program. Where small data sets may be migrated manually.
Means/ways shall be defined to check and test that the data migration has been successful. This may include reconciliation tests in the new system to see if result is the same as in the legacy system, based on the same data.
Verification of migrated data against the original data must be performed to ensure that the data has been migrated appropriately.
It must be considered how much of the data migrated needs to be verified.
Depending on the critically of data this may vary from sampling of data to 100%.
Following deliverables must be generated as a result of execution of this Stage:
- Qualification protocol (IQ/OQ/PQ/NQP) as applicable
- Test scripts identified in Qualification protocols
- Qualification Execution report (IQ/OQ/PQ/NQR)
- Requirement Traceability Matrix (RTM)
- Discrepancy Forms & logs (if applicable)
- Data migration plan (if applicable)
Implementation Stage: In this phase all the activities performed during the SLC for the project/system are summarized in Validation Summary Report (VSR).
Business users are notified once the system is released for production use.
Users who would be using the system will also be trained on the system.
Various Business SOPs, Technical work instructions etc. to be established as identified in the PVP are brought to closure.
The Change control initiated during the phase I shall be brought to closure during this phase.
Project team shall perform post risk assessment to ensure effectives of all controls considered for determination of risk priority number. Mitigation control effectiveness for risk which is in unacceptable range. Validation Summary Report; Project team should prepare the Validation Summary Report (VSR).
The VSR should summarize the approach that was taken for the validation of the system The VSR should describe the following –
- Scope for validation of the system
- Qualification Test Summary Results
- Summary of the Validation Strategy (approach, activities, procedures) undertaken and deviations if any
- List of project/ validation Deliverables along with approval dates
- Details of trainings conducted and approved business SOPs required for usage of the system
- Other Supporting SOPs required in operational phase
Upon completion of all the validation/Qualification activities defined in the PVP for the system, the results of the validation effort for the system to show that the system is validated according to the established policy, Procedures,
SOPs and applicable regulatory requirements should be summarized in Validation Summary Report (VSR).
The summary activities should be obtained by reviewing the validation deliverables that were developed, reviewed, and approval during each phase of SLC.
Approval of the VSR shall certify that the system is ready to be rolled out to business users for routine business use once corresponding SRC is approved.
Update the Inventory list of computerized system once VSR approved with details as defined in SOP or site specific procedure.
System Release Certificate: Project team should prepare the system Release certificate.
The SRC summarizes the status of following:
- Training conducted by business users for all the Users required to undergo trainings
- Business SOPs are effective or not
The SRC certifies that the system had been configured successfully to use for routine business operation and site is ready for the system to be rolled out. Post approval of this document, Users are allowed to use the system.
Following Deliverables must be generated as a result of execution of this stage-
- Post Risk Assessment
- System specific SOPs
- Validation Summary Report (VSR)
- System released certificate (SRC)
- Notification for Go – Live to Users
- Change control (Closure)
- Update the inventory list of computerized system
Operation I Maintenance Phase:
System Operation, Maintenance and Support: Once the system have been validated and released for use in operation, appropriate operational processes, procedures and plans shall be implemented during this phase to maintain compliance and fitness for intended use throughout its life. This will be achieved by the use of up to date documented procedures and training that covers use, maintenance and management. The system maintenance phase shall embody all maintenance and support activities necessary to ensure that the validated status of the system shall be maintained throughout its operational life.
Changes to the system in operational phase shall be handled through standard change management for computerized system procedure or site specific procedure. The scope of the validation effort will be assessed depending upon the nature of change in validated system and its associated impact.
The scope of the validation effort will be assessed depending upon the nature of change in validated system and its associated risk /impact.
In case of enterprise applications in operation and maintenance phase, qualification reports and validation summary report shall be updated with latest qualification details (If applicable) during periodic review of application or as identified during major changes.
The Project Team Members, users, and Support Personnel responsible for the validation, use, administration, and/or maintenance of the system will be required to have the appropriate qualifications and/or receive adequate training prior to performing their roles and responsibilities for the project.
Periodic Review: Periodic review shall be performed / conducted as per current version SOP “Periodic Review of Computerized System” or site-specific procedure throughout the operational life of SLC to verify that system remains complaint with regulatory requirements, fit for intended use, and satisfy company policies and procedures
A number of SOPs and /or variants should be developed or update for the Project/system that supports the system operations in this phase of SLC.
SOPs required in operational phase to maintained the system in validated state but not limited to these only,
- Incident/Deviation Procedure
- Periodic review of computerized system
- Corrective & Preventive Action
- Data Backup, Restore, Archival & Retrieval
- System administrative control
- Business Operational SOPs
- Preventive Maintenance /Performance monitoring Procedure shall also depend on the nature, size, risk, complexity & novelty of computerized system
Following deliverables may be generated as a result of execution of this phase:
- Change control request (If any)
- Training records (If any)
- Periodic review report
- Number of SOPs such as Data backup & restore, system administrative controls, Preventive maintenance etc. (if applicable)
Conduct planned audits of the systems to ensure their compliance with regulatory requirements and effective policies/guidelines/SOPs.
Retirement/Decommissioning Phase: System retirement represents the end of the SLC. Any system implemented in Environment can be retired/ decommissioned based upon business decision using the SOP on System Retirement/ Decommissioning or site specific procedure.
Validation Document Deliverable Matrix The list of deliverables, which shall be generated by the project team. “Validation Document Deliverable Matrix”. This matrix is subjected in nature for guidance purpose, number of deliverables may be changed based on system risk, complexity & Novelty and same shall be defined in Project Validation Plan.
Validation Document Numbering: Each document shall be uniquely identifiable and traceable. Number shall be assigned to document as per current version SOP “Computer System Validation Document Numbering Procedure”.
Annexures having prefix title as ‘Template’ are guidance templates and shall be used as soft copy to prepare validation documents without changing format and main headings·. However, sub-headings can be amended based on validation document requirement of any specific system.
PLC (Programmable Logic Control) with HMI/MMI/IPC installed in the equipment shall be qualified using this SOP, if electronic record and / or electronic signature and data backup is applicable.
Computerized system software version change or hardware change upgradation or any other reason) shall be assessed “Template for Computerized System software Version/ hardware Change Assessment”. Based on the outcome of assessment, further action (Extent of Qualification) shall be decided. Document Number for the “Computerized System Software Version/ hardware Change Assessment” shall be the Reference change control number. System after Partial Validation shall be released on the basis of the Validation Summary Report.
Additional validation or verification activity addressed through deviation or other QMS tool, shall be performed “Template for Protocol Cum Report.
Site specific Computerized System list (i.e. Production, Engineering, QA, warehouse, Administration, QC & Enterprises system) shall be maintained from site “List of computerized System”
List of computerized system shall prepared by QA-IT compliance, Reviewed by IT department and approved by site QA head.
ABBREVIATIONS:
ADR: Adverse Drug Reactions
CAT: Category
cc Change Control
CDS : Chromatography Data System
COTS: Commercial off the shelf
Csv: Computer system Validation
DS: Design specification
ER/ES: Electronic record/Electronic signature
ERP Enterprise resource planning
FRA: Functional Risk Assessment
FRS: Functional Requirement Specification
GAMP: Good Automated Manufacturing Practice
GxP : It is a general term as Good X Practice where, X=Manufacturing, Clinical, Laboratory, documentation etc.
LIMS: Laboratory Information Management System
NDA: Non-Disclosure Agreement
NQ: Network Qualification
NQP: Network Qualification Protocol
NQR: Network Qualification Report
PVP: Project Validation Plan
QAMS: Quality Assurance Management system
RTM: Requirement Traceability Matrix
SCADA: Supervisory control and data acquisition
SLC: System Life Cycle
SME : Subject matter Expert
