Design Qualification SOP

Transcription

1 1.0 Commercial in Confidence 16-Aug of 13 Design Qualification SOP Document No: SOP_0400 Prepared by: David Brown Date: 16-Aug-2006 Version: 1.0

2 1.0 Commercial in Confidence 16-Aug of 13 Document Approval Name Role Date Signature David Brown Author Document Control Version Author Date Description 1.0 David Brown 16-Aug-2006 First version.

3 1.0 Commercial in Confidence 16-Aug of 13 Table of Contents 1 Introduction Purpose Scope Definitions Responsibility References Design Qualification Process Business Requirements Review Functional Design Review Technical Design Source Code Control Coding Standards Code Reviews Unit (Component) Testing Validation Change Control Process Design Qualification - Phase Entry/Exit Phase Entry Phase Exit Design Qualification Protocol - Preparation Protocol Title Pre-approval Introduction Regulatory Requirements Methodologies Documents to be reviewed Acceptance Criteria Design Qualification Report Report on the design evaluation process Summary and Conclusions Protocol Results Acceptance... 12

4 1.0 Commercial in Confidence 16-Aug of 13 1 Introduction 1.1 Purpose 1.2 Scope The Design Qualification process ensures that a computer system requiring validation to is designed to meet the regulatory requirements of the pharmaceuticals industry. Department/Section: Client, IT and Validation groups. This SOP will apply to the design of all computer systems that require validation to meet pharmaceutical industry regulatory requirements. For information on computer systems that require validation see SOP SOP_0200 Validation Determination. 1.3 Definitions Project Team the team formed by the business to implement a new computer system. This team will typical comprise of: a project manager, users, software engineers, IT support staff, trainers, and IT quality assurance staff. Client the business system owner is typically the line manager responsible for the business process where the computer system will be used. Validation Group the group responsible for ensuring that computer systems are implemented and maintained in a validated state. IT Group the group responsible for development, operation, and maintenance of computer systems. 1.4 Responsibility The overall responsibility to ensure that the DQ is carried out in accordance with this SOP lies with the Business System Owner. The Project Team are responsible for ensuring that they follow the process described in this document is followed. The Validation group is responsible for the production of the Design Qualification Protocol document and Design Qualification Report.

5 Title Design Qualification SOP 1.0 Commercial in Confidence 16-Aug of References Document ID SOP_0102 SOP_0401 SOP_0402 SOP_0900 Title Document Standards Code Review SOP Unit Testing SOP Validation Change Control SOP

6 1.0 Commercial in Confidence 16-Aug of 13 2 Design Qualification Process 2.1 Business Requirements Review The User requirements must be documented either as a conceptual description of the system or as a formal statement of user requirements prior to the start of the validation process. The User requirements specification must be reviewed to ensure that the appropriate regulatory conformance requirements are present. These requirements relate to: US Food and Drug Administration 21 CFR Part 211 Current Good Manufacturing Practice For Finished Pharmaceuticals US Food and Drug Administration 21 CFR Part 11 Guidance for Industry Part 11, Electronic Records; Electronic Signatures Scope and Application International Committee for Harmonization (ICH) Guidance for Industry E6 Good Clinical Practice: Consolidated Guidance International Committee for Harmonization (ICH) Electronic Standards for the Transfer of Regulatory Information (ESTRI) International Committee for Harmonization (ICH) Electronic Common Technical Document Specification US Food and Drug Administration Guidance for Industry: Computerized Systems Used In Clinical Trials US Food and Drug Administration 21 CFR Part 58 Good Laboratory Practice For Nonclinical Laboratory Studies All Requirements should have a unique identifier to allow for traceability of system functionality back to requirements. 2.2 Functional Design Review The functional design must be reviewed to ensure the business requirements, specifically the regulatory requirements, are addressed in the Functional Requirements Specification. The compliance related functions are: The use of electronic signatures; Access control mechanisms; Audit trails;

7 1.0 Commercial in Confidence 16-Aug of 13 Backup and recovery; Resilience and data integrity, and; Disaster recovery. 2.3 Technical Design Ensure that the technical design specification provides a concise definition of each software module. These definitions must be traceable back to business functions expressed in the Functional Requirements Specification. 2.4 Source Code Control Ensure that all source code related to a validated system is stored in a validated source code control system unless manual procedures are in place to ensure the version management of source code during development. 2.5 Coding Standards Coding standards are vital to ensure consistency and supportability of a computer system. As part of the DQ process it is the responsibility of the project team to ensure that coding standards are employed. 2.6 Code Reviews Evidence must be present that source code reviews have been conducted as part of the development process. (See SOP_401 Code Review SOP). 2.7 Unit (Component) Testing The final step of the design phase of the system should be unit testing. Unit testing should ensure that the components meet the standards identified in the SDLC used. (See SOP_402 Unit Testing SOP). 2.8 Validation Change Control Process The change control process begins at the point of approval of the user requirements specification. This is important to ensure that traceability of requirements is maintained. (See SOP_0900 Validation Change Control SOP).

8 1.0 Commercial in Confidence 16-Aug of 13 3 Design Qualification - Phase Entry/Exit 3.1 Phase Entry The entry point for the Design Qualification is the approval of the User Requirements Specification or concept statement. 3.2 Phase Exit The exit point for the Design Qualification phase of validation is the approval of the Design Qualification Report.

9 1.0 Commercial in Confidence 16-Aug of 13 4 Design Qualification Protocol - Preparation The Design Qualification Protocol describes the process to be followed that will ensure the design and development of a computer system does not compromise its validated status. The audience for the DQ protocol will be business staff within the company and industry regulators. Therefore, the document wherever possible should be written in non-professional terms. The DQ document must be able to be read in isolation and therefore provide enough detail on the purpose of the system. The Design Qualification Protocol must be created to conform to the SOP_102 Documentation Standards SOP. The following subsections provide a synopsis of the content of the DQ protocol. 4.1 Protocol Title Give the Protocol a descriptive title, which reflects the scope of testing performed in the Protocol and provides sufficient differentiation between this Protocol and other protocols for the system. 4.2 Pre-approval At the beginning of the DQ Protocol a pre-approval section is required. This section will contain a table for signatures. The table of signatures must provide for the following information to be captured: 1. The department or function of the signatory; 2. The name of the signatory; 3. A space to record the signature, and; 4. A space to record the date of the signature. The section must contain a statement informing the reviewer that signing this document infers that they have read, understood and agree with the contents of the protocol. Normally this information is collected on the approval page of the DQ Protocol.

10 1.0 Commercial in Confidence 16-Aug of Introduction The introduction section of the DQ protocol must contain subsections providing information on: 1. The objectives of the DQ protocol; 2. The scope of the DQ protocol stating the phase of the implementation lifecycle the IQ protocol applies too; 3. A list of documents referenced in the DQ protocol; 4. A description of the system being designed which identifies the intended use of the system. 4.4 Regulatory Requirements Details of the international regulatory requirements that apply to the computer system being validated must be identified. 4.5 Methodologies This section of the DQ protocol must identify any Software Development Lifecycle or development methodology to be used in the design and development of the system. This section must describe any issues identified with this methodology and the controls that have been put in place to address these issues. 4.6 Documents to be reviewed This section must identify the document to be reviewed as part of the DQ process. In addition, this section must identify any documents that have been omitted or are to be omitted with an explanation of the reasons for their omission. 4.7 Acceptance Criteria List the criteria the system must meet to satisfy the objectives of the DQ. Acceptance Criteria must meet the following standards: The Acceptance Criteria (AC) must be unambiguous, measurable, and verifiable. Terms such as appropriate and very are not acceptable in most functions. Examples: o Unacceptable AC: The Technical Design Specification will contain appropriate definitions of code modules.

11 1.0 Commercial in Confidence 16-Aug of 13 o o Acceptable AC: The Technical Design Specification will contain detailed definitions of code modules including... Unacceptable AC: A message will display when an invalid quantity is entered. o Acceptable AC: A message will display indicating entry of an invalid quantity. Number or uniquely label the Acceptance Criteria so they may later be identified. The Acceptance Criteria should have their basis in the user requirement specification and relevant regulatory requirements.

12 1.0 Commercial in Confidence 16-Aug of 13 5 Design Qualification Report On completion of the Design Qualification process the Design Qualification protocol is revised to include the following sections: Report on the design evaluation process; Summary and Conclusions, and; Protocol Results Acceptance. The inclusion of these sections in the DQ protocol and the associated approval process of the revised DQ protocol will create the Design Qualification Report (DQR). 5.1 Report on the design evaluation process This section identifies: The results of the evaluation of the identified design documents against the user requirements, regulatory requirements, and SDLC/QA processes; Details of the change generated during the design qualification process. See SOP_0900 Validation Change Control SOP. 5.2 Summary and Conclusions Provide a summary of the results of the design qualification process and any encountered deviations. Problems encountered during execution of protocols will be summarised according to: protocol errors, execution errors, specification errors, and non-conformance to regulatory requirements and requirements expressed in the user requirements specification. 5.3 Protocol Results Acceptance The last section of the DQ report must be the Protocol Results Acceptance section. This section records the approval of the revised DQ protocol that forms the DQR. This section will contain a table for signatures. The table of signatures must provide for the following information to be captured: 1. The department or function of the signatory; 2. The name of the signatory; 3. A space to record the signature, and; 4. A space to record the date of the signature.

13 1.0 Commercial in Confidence 16-Aug of 13 The section must contain a statement informing the reviewer that signing this document infers that they have read, understood and agree with the contents of the protocol.