Computer System Validation Services
The foundation of any GxP IT Application is its computer system validation process and its system lifecycle documentation (SDLC).
During initial system implementation, system enhancements, or remediation activities, Lean Biologix will perform a gap assessment on system documentation and provide path forward and activity management to bring a GxP system to a high level of compliance. Efficient process design, documentation, and maintenance is required and supported during a GxP software validation IT project.
As the industry matures and advances, creating independent test scripts and manual testing is quickly being replaced by comprehensive testing strategies and automated testing.
Software Development Lifecycle Documentation (SDLC)
System Assessment (SA)
-
- The System Assessment Document provides guidance on the classification of an enterprise software system. This document will drive compliance and testing requirements based on a system category of GxP or Non-GxP. GxP systems must adhere to GAMP5 and 21 CFR Part 11 process guides while Non-GxP does not require the same level of documentation. Lean Biologix recommends comprehensive documentation on Non-GxP systems although not required from a compliance standpoint. This level of attention on Non-GxP systems standardizes the approach to IT system management and provides time and cost savings over time.
Requirements Specifications
-
- User Requirements Specifications (URS)
- Business Use Cases
- User requirements can most easily be identified by reviewing and understanding existing or new business processes. The general functional user requirements are developed via discussion of the system intended use with the business users or end users.
- Non-Functional Requirements
- Non-functional requirements are all requirements which users may have outside normal system operation. Examples are system availability and performance requirements.
- Regulatory Requirements (21 CFR Part 11)
- Industry standards for regulatory requirements are provided by the FDA in the United States. Note that if an enterprise application has sites inside and outside of the USA, additional requirements from that countries governing bodies need to be considered. For countries in the European Union Annex 11 “The Rules Governing Medicinal Products in the European Union” standards can be referenced.
- Download the FDA Guidelines
- Visit the FDA Part 11 article for reference
- Visit the EU health site article for reference
- Data integrity requirements
- Data Integrity requirements are often built into the non-functional requirements section of a URS. Though not fully represented in the formal FDA requirement set, standard recommendations are provided by the FDA.
- See the FDA Data Integrity Guide
- Download the FDA Data Integrity and Compliance Guide
- Business Use Cases
- Functional Specifications (FS)
- Functional specifications add a level of detail to each user requirement. Specifics on how and by which software component the user requirement is to be met are identified and explained. An example of this is light configuration of an out of the box system functionality like an approval/E-signature workflow.
- Design Specifications (DS)
- The design specification contains all levels of detail required to understand the configuration details required to enable a functionality. The design specification document often contains sections below the main requirements list which detail configuration specifics for all requirements in the system. An example of this would be configuration parameters for a specific instrument/equipment services which are required for the software system to integrate or acquire data successfully.
- User Requirements Specifications (URS)
Risk Assessment (RA)
-
- The assessment (RA) document contains a systematic approach for the assessment, control, and review of risks to regulations for patient safety, product quality, data integrity, and business processes as defined in the URS. The RA is typically an excel sheet or module in a user requirement management system such as HPALM / VERA. Each requirement is evaluated against a company standard risk scoring logic and assigned a risk score of LOW, MED, or HIGH.
- LOW – If functionality is to fail, users, data, system stability are not affected
- MED – If functionality is to fail, users, data, system stability, system security are affected
- HIGH – If functionality is to fail the system will be unusable and/or non-compliant. For example, every regulatory related requirement will have the HIGH risk score if applicable.
- Typically, LOW risk requirements are default system functionality (COTS) and do not require a high level of testing. For requirements with the MED risk score positive functional testing is required. HIGH risk requirements require positive and negative testing.
- The GAMP5 standard provides a detailed Risk analysis framework that can be used as a reference for risk scoring. This framework is often transcribed into an internal company standard which should be the priority reference to perform risk assessment within an organization.
- The assessment (RA) document contains a systematic approach for the assessment, control, and review of risks to regulations for patient safety, product quality, data integrity, and business processes as defined in the URS. The RA is typically an excel sheet or module in a user requirement management system such as HPALM / VERA. Each requirement is evaluated against a company standard risk scoring logic and assigned a risk score of LOW, MED, or HIGH.
Traceability Matrix (TM)
-
- The requirements traceability matrix is one of the most referenced and updated documents for a GMP system. The TM links the URS, FS, DS, and testing references in one place and provides clear traceability between the desired user function and the specific test that was performed to verify the functionality.
Validation Plan (VP)
-
- The Validation Plan describes the implementation strategy, including System Development Life Cycle (SDLC) activities required to provide documented evidence that the system reliably performs as intended. The validation plan also identifies release for use criteria and project role definitions.
Test Plan (TP)
-
- The Test Plan details the tests activities required by the Validation Plan. This document contains the full scope of system testing and is used as the input requirements for the Validation Test Report which is generated after testing in the validation environment.
Data Migration Plan (DMP)
-
- Specifical actions required to move data from one location to another, one format to another, or one application to another. Typically data migration is required when a legacy system is being replaced or a system is being upgraded to a much newer software version.
- Lean Biologix has experience guiding clients through system data migration and employs control processes to ensure consistent transformation of current data for migration.
Backup and Restore Plan (BRP)
-
- On-Premises (Hosted Internally)
- SAAS (Hosted Externally / Cloud Hosted)
- VM Backup and Restore
- SQL Backup and Restore
Computer System Validation – GMP System Test Plan
Once system lifecycle documentation has been planned and developed system change control activities and testing can be scoped out and planned. Lean Biologix develops lifecycle documentation alongside testing activities and provides a complete compliant software package.
Testing activities are typically performed by a combination of Lean Biologix team, vendor, or by internal client resources.
IT Change Control Management
-
- Change control creation and change control management
System Testing
-
- Authoring and execution of installation, functional, and user acceptance test scripts
- Installation Qualification (IQ)
- Operational Qualification (OQ)
- Functional Qualification (FQ)
- User Acceptance Testing (UAT)
- Performance Qualification (PQ)
- Authoring and execution of installation, functional, and user acceptance test scripts
Computer System Validation Support, Remediation, and Auditing
Documentation and Testing activities are the critical parts of any system implementation, upgrade, or remediation. Post-implementation activities should not be a secondary consideration. Having a Firm Go-Live plan, schedule, and support package is essential for the success of the project. These activities build confidence for the system in the user base and ensure a smooth roll-out. Lean-Biologix provides hypercare support and ongoing system monitoring and assessment support.
- Hyper Care Support
- Continuous IT system support is always available to ensure a smooth onboarding / transition for users.
- Periodic Reviews & System Compliance Auditing
- Evaluate IT portfolio systems for compliance with current industry standards and federal regulations.
- GAMP5 Lifecycle System Documentation Remediation
- Update documentation to adhere to current company governance policies and federal regulations for compliance, security, and data integrity.
Lean Biologix incorporates the ISPE GAMP 5 process during IT computer system validation project execution. We have extensive expertise creating and working with System Development Lifecycle Documentation (SDLC) alongside compliant system design, configuration, testing, hypercare support, and production implementation.