19
The Ashvins Group, Inc. 6161 Blue Lagoon Dr Suite 340 Miami, FL 33126 1-877-ASHVINS www.ashvinsgroup.com International Symposium of Laboratory Automation and Robotics (ISLAR) Presentation Computer Related System Validation

Software Validation ISLAR

Embed Size (px)

DESCRIPTION

m

Citation preview

  • The Ashvins Group, Inc.6161 Blue Lagoon DrSuite 340Miami, FL 331261-877-ASHVINS www.ashvinsgroup.com International Symposium of Laboratory Automation and Robotics (ISLAR) PresentationComputer Related System Validation

  • ABSTRACT

    This presentation summarizes approaches for project leaders in the pharmaceutical, biotech, drug discovery and clinical fields who must validate software used to automate laboratory research procedures, consolidate data collection and analysis and/or run sophisticated QC or manufacturing operations.

    The goal of this presentation is to outline general validation principles and quality system regulations (QSRs) that build a framework to establish a comprehensive approach to software validation. Validation technology may be addressed through a variety of formats such as:

    Installation Qualification/Operational Qualification (IQ/OQ) Validation and Verification (V&V) Computer Related Systems Validation (CRSV)

    Several approaches to software validation exist and may be appropriate for the specific project. The scope of any validation effort depends upon a number of factors, including the size and complexity of the software, the origin of the software (custom vs. off-the-shelf) and whether the functions are critical or non-critical in nature. By effectively planning the process, validation time and resources can be reduced while meeting regulatory requirements.

  • In recent years there has been a significant increase in the use of computer-related systems in the Life Sciences industries. Its clear that these systems must satisfy cGMP requirements, but legitimate questions have been raised concerning the scope and methods which should be employed in validations. It is the responsibility of the end-user to assure that systems used are in compliance with applicable regulations; however, many users rely too heavily upon vendor-supplied information and test data to support their system validation.

    The extent of testing and the type of documentation required to support validation is unclear, and it is difficult to delineate vendor and user responsibilities when validating vendor-supplied systems. Validation of computer-related systems is often complex, and any number of alternate approaches can be utilized. INTRODUCTION

  • Defining CRSV can be modeled after the FDAs definition of Process Validation :

    Establishing documented evidence which provides a high degree of assurance that a specific computer-related system will consistently produce a product meeting its pre-determined specifications and quality attributes. Computer Related System Validation

  • Computer Related System Validation Lifecycle

  • A computer-related system (CRS) is a computerized system performing its intended function in its operating environment.

    A CRS can not be validated unless the process it is executing can be validated.Applicable Quality Regulations include:cGMPs/GLPs/GAMPCFR Part 820 and Part 11

    Systems requiring validation include all systems directly or indirectly related to the regulatory process:

    Medical Devices with computer componentsDecision-support/decision-making systemsInventory systemsLab systems including lab automationData management and reporting systemsTesting systemsStatistical analysis systems Computer Related System ValidationSystem Concepts

  • Computer Related System ValidationSystem ConceptsComputer Related System Boundary

  • Build the Validation TeamThe Validation Team incorporates multi-functional participation and depending on the complexity of the validation effort may include:

    Management Information SystemsDevelopersVendorsConsultantsSoftware QAExecutive Management

    The Validation Team is responsible for defining, planning, assessing risk, evaluating intended use, executing, documenting, reviewing and approving the validation efforts. The Validation Team should have a combination of skill sets for effective results. This will include individuals who are experienced with regulations, validation approaches, systems, processes and intended uses associated with the validation effort.

  • Documentation: Write It DownValidation SOPs and Policies Project Management PlanValidation PlanRisk (Hazard) Management PlanConfiguration Management PlanChange Management PlanSystem Test PlansComputer-Related System Requirements SpecificationComputerized System Design Specification and DocumentsTraceability AnalysisSystem Topology and Installation SummariesValidation Protocols / Test Case ProceduresIQ/OQ/PQ ReportsValidation Reports

    The level of documentation required depends on the complexity and intended use of the system; and also on the origin of the software/system (vendor supplied or developed internally). Examples of documentation required to support validation:

  • Validation Approach: 8 Step Model

  • Each organization should have written and approved validation policies. There should be specific SOPs for the validation of Computer Related Systems. Protocols should be developed, test data reviewed and summary reports written in accordance with established procedures that assure the validation objectives are met.

    A Validation Project Plan is used to identify the systems to be included, procedures to be followed and the timeline for a specific validation project. This step also helps project resources and budget requirements.

    A Validation Project Plan can be written for a single system, a combination of systems that support an associated process or an entire facility. An important purpose of the Validation Plan is to establish specific responsibilities and expectations for each validation activity.STEP 1 : Plan Validation Activities

  • STEP 2 : Define Computer-Related System RequirementsThe first task for the internal Validation Team is to create a document that summarizes the high level goals of the CRS.

    The document specifies what at a high level should be accomplished by the CRS. In order to define requirements, the Validation Team reviews available documentation, conducts interviews with users and maps existing processes. The initial overview should concentrate on functionality, operational and performance parameters, and overall objectives for the validation effort. Each requirement written should be described with sufficient detail to support testing that requirement and defining acceptance criteria. Testing protocols should be traced back to each requirement (via a Traceability Matrix) in order to document the comprehensiveness of the protocols.

  • STEP 3 : Select Computerized System VendorsThe term vendor may apply to an internal development group as well as an outside company. Whether the vendor is an outside company or an internal department, the vendors ability to provide a system which can be validated should be a primary consideration.

    A suitable vendor must be technically competent and qualified to supply and support the proposed system. Knowledge of validation requirements and experience in providing systems for cGMP applications are important selection criteria.

    The importance of selection criteria for computerized systems depends upon the type of software and hardware being evaluated.

    For off-the-shelf software and standard hardware components, such as operating systems and computing platform, the history of customer satisfaction is of major importance.For custom developed systems, primary importance should be placed on evaluating the vendors Quality Assurance System.

  • STEP 4 : Design Computerized SystemA Computerized System Design Specification is a document or a collection of documents that describes clearly and completely how the computerized system will operate and satisfy the Computer-Related System Requirements Specification.

    The Design Specification can not be developed until the vendors and the specific hardware and software have been selected.The Design Specification applies to both the computer system and the controlled function/process, and should contain all of the information required to describe both normal and abnormal operating conditions.The Design Specifications should be a joint responsibility of the vendor and user.It is important that the Design Specifications contain detailed information about the interfaces between the computerized system and its operating environment.

  • STEP 5 : Construct Computerized System The computerized system may be constructed by developing custom software and hardware for the application - or purchasing established products - or a combination of both.

    From a validation perspective, custom developed software and hardware require the greatest amount of testing since they have never been proven effective. Three categories of software can be defined:System softwareConfigurable softwareApplication specific software These categories are not intended to be rigid but they allow distinctions to be made so that validation approaches are appropriate. Defined processes, assigned responsibilities, planned audits, structured reviews and management controls, collectively promote an environment to efficiently manage product quality.

  • STEP 6 : Integrate and Install Computerized SystemProper integration, installation and commissioning of a computerized system is essential to the successful qualification of the system.

    A packaged system may be integrated at the vendors site; more complex systems will be integrated at the users site.

    Procedures employed in the project should be specified in the Validation Plan.

    Responsibility for all tasks (including vendors) should be specified in the Validation Plan.

    Installation Qualification (IQ) will demonstrate proper installation of hardware and software.

  • STEP 7 : Qualify Computerized System (IQ/OQ)Qualification is a procedure of testing and collecting data to provide a high level of assurance that a computerized system operates in accordance with the system specification. Protocols are written and approved in advance and should specify the following:Goals of testingTest methodsAcceptance criteriaWho is responsible for testing

    IQ (Installation Qualification) verifies that all aspects of installing hardware and software meet specifications and that user manuals, SOPs and backup procedures are in place.

    OQ (Operational Qualification) verifies that the system operates throughout its anticipated ranges according to its specifications and identifies all important parameters.

  • STEP 8 : Evaluate Computerized System in Its Operating Environment (PQ)PQ (Performance Qualification) verifies that a system performs its intended function in accordance with its specifications. Testing is completed on the entire system while operating in its normal environment.

    In order to assure that the system remains in a validated state, Performance Monitoring is required to continually test a systems performance in executing defined processes:

    Periodic calibration and maintenanceContinuous monitoring of critical parametersConfirmation of security measuresProvisions for contingency planning, disaster recovery and personnel training

    Change Control procedures must be established to keep a CRS in a validated state during planned and unplanned changes.

  • SUMMARYBuild a framework to establish a comprehensive approach to software validation in the following applications: Automating laboratory procedures Data collection and analysis QC & Manufacturing operationsValidation techniques accomplished via: IQ/OQ/PQ Verification & Validation CRSVScope of validation effort depends on: Size and complexity of the software Origin of the software (custom or OTS) Criticality of the software functionValidation is specific to the intended use of the CRS.Adequate preparation will reduce validation time / resources and assure regulatory requirements are addressed.

    *******************