Blood Establishment Licence Amendment Requirements for Information Technology Submissions

Help on accessing alternative formats, such as Portable Document Format (PDF), Microsoft Word and PowerPoint (PPT) files, can be obtained in the alternate format help section.

Contact: Policy and Promotion Division

This document is also available in PDF format
Blood Establishment Licence Amendment Requirements for Information Technology Submissions (PDF Version, 59 kb)
Date: 2002-10-22

HEALTH CANADA
Biologics and Genetic Therapies Directorate
Version 1.1
Issued in October 2002

TABLE OF CONTENTS

• 1. Introduction
• 2. Purpose
• 3. Scope
• 4. Roles and Responsibilities
• 5. Submission and Review Process
• 6. Submission Numbering
• 7. Structure of a Submission
• Part 1 OPERATIONAL CHANGE
  • 1.1 Submission Certification
  • 1.2 Overview
  • 1.3 Operational Impact
  • 1.4 Requirements Specification
  • 1.5 Process Analysis
  • 1.6 Hazard Analysis
  • 1.7 Software Development
  • 1.8 Software Development Standards
  • 1.9 Software Implementation Standards
  • 1.10 Work Instructions Development
  • 1.11 Validation Strategy Overview
  • 1.12 Project Schedule
• Part 2 VALIDATION PLANNING
  • 2.1 Software Validation Plan
  • 2.2 Technical Environment Qualification
  • 2.3 Data Conversion Validation Plan
  • 2.4 Configured Software Validation Plan
  • 2.5 Work Instructions Validation Plan
  • 2.6 Personnel Training Validation Plan
  • 2.7 Materials Validation Plan .
  • 2.8 System Recovery Validation Plan
  • 2.9 Production System Validation Plan
  • 2.10 Project Schedule
• Part 3 VALIDATION
  • 3.1 Software Validation
  • 3.2 Technical Environment Qualification
  • 3.3 Data Conversion Validation
  • 3.4 Configured Software Validation
  • 3.5 Work Instructions Validation .
  • 3.6 Personnel Training Validation
  • 3.7 Materials Validation
  • 3.8 System Recovery Validation
  • 3.9 Production System Validation
  • 3.10 Corrective Action and Results
  • 3.11 Project Schedule
• Part 4 PRODUCTION TRIAL PLAN
  • 4.1 Production Trial Plan
  • 4.2 Production Trial Support
  • 4.3 Decision to Proceed with Production Trial
  • 4.4 Project Schedule
  • 4.5 BGTD Approval to Proceed
• Part 5 PRODUCTION TRIAL
  • 5.1 Production Trial Execution
  • 5.2 Production Trial Report
  • 5.3 Corrective Action Plan
• Part 6 IMPLEMENTATION PLANNING
  • 6.1 Roll-out Strategy and Plan
  • 6.2 Generic Site Verification Guide
  • 6.3 Decision to Proceed with Implementation Roll-out
• Part 7 SITE VERIFICATION
  • 7.1 Submission Certification
  • 7.2 Specific Site Verification Guide
  • 7.3 BGTD Approval to Proceed
  • 7.4 Site Notification Report

1. Introduction

Health Canada regulates facilities that collect blood and/or manufacture blood components. The Biologics and Genetic Therapies Directorate (BGTD) of Health Canada is responsible, in partnership with other areas of Health Canada, for issuing and monitoring the applicable regulations.

Under Division 1A of the Food and Drugs Act and Regulations, Blood Establishments are required to provide Health Canada with Licence Amendment submissions for review of any proposed changes in the manufacturing facilities and procedures, prior to implementation. Failure to meet such requirements can result in the addition of Terms and Conditions to their Establishment Licence, cancellation or suspension of the licence.

In the context of using Information Technology in a Blood Establishment, a License Amendment is required when a Blood Establishment implements a new computerised system which performs one or more of the following functions:

• data handling between automated devices;
• utilization of data used in making decisions regarding the suitability of blood or blood components for transfusion or further manufacture; and,
• utilization of data used to trace a unit of blood or a blood component from the source to its final disposition by manufacturer or consignee.

Additionally, a License Amendment is required when a Blood Establishment makes modifications (described in Section 3 - Scope) to any validated components of a currently installed computerised system.

BGTD is currently in the process of preparing a guidance document entitled Process Guidelines for Reporting Changes and Incidents Occurring in Operational Computerized Blood Systems. Once finalized blood establishments should also refer to this document for guidance in reporting requirements relating to incidents involving approved computerised systems as well as for Licence Amendment requirements for changes to approved computerised systems.

2. Purpose

The purpose of this document is to provide guidance to facilities that collect blood and/or manufacture blood components (Blood Establishments) in the preparation of a Licence Amendment for Information Technology submissions.

3. Scope

For the purpose of this document a computer system is defined to include: application programs, operating systems and other software, hardware, communications, interfaces, and system and user operating instructions. The computer systems are commonly used for, but not limited to, blood collection, donor testing, production, inventory, labeling, release and distribution and lookback/traceback.

A Licence Amendment submission to Health Canada must be approved before any one of the following actions is taken by a Blood Establishment:

• implementation of changes to the operating processes when making major modifications to their computerised system and/or related working instructions;
• the addition of a new computerised system;
• migration to a newer version of the operating or data management system currently installed and validated;
• modifications to the hardware/software configuration currently installed and validated;
• modifications to the networking hardware/software configuration currently installed and validated;
• migration to a newer version of the application software currently installed and validated; and,
• additions to the functionality of the application software already installed and validated.

If the Blood Establishment is unsure whether a proposed change to an existing system requires a Licence Amendment submission under the process defined in this document, then they should contact the responsible authority within Health Canada.

4. Roles and Responsibilities

There are two main stakeholders in the Licence Amendment process, BGTD and the Blood Establishment. These two stakeholders share the roles and responsibilities for the process. There can be other groups involved in supporting the process or providing input to the Licence Amendment process. The following describes the roles and responsibilities of all potential players.

• BGTD's role and responsibilities are to review in a timely manner all the documents submitted under the Licence Amendment Requirements for Information Technology Submission and to provide an acceptance or in the case of rejection, comments on deficiencies.
• The Blood Establishment's role and responsibilities are to submit all the required documents for the Licence Amendment Requirements for Information Technology Submission, such that they are approved by Health Canada and to correct any deficiencies identified from the review process.
• The Software Vendor's role and responsibilities is to submit documents to Health Canada, requested by and on the behalf of the Blood Establishment.

5. Submission and Review Process

The information required in a Licence Amendment submission for Information Technology is separated into seven parts. Each part has clearly defined sections as described in the Structure of a Submission section. The sections of a specific part may be submitted individually. All sections of a part need not be submitted prior to submission of sections for a subsequent part.

The submission process should start with an initial meeting between both parties, called at the request of the Blood Establishment. This meeting provides an opportunity for the Blood Establishment to present to Health Canada an overview of the changes that the Blood Establishment will be undertaking, the size of the project and a schedule for the changes. A Project Charter or Project Book would be a useful document to provide for the initial meeting.

The initial meeting also provides an opportunity to discuss and clarify the submission process. For instance, certification of the software by other regulatory agencies or previous reviews by Health Canada can be discussed at this time to determine if they can be used to support the submitted documents, and the impact they might have on the submission requirements.

The review process employed by BGTD entails the review of the submission documents submitted by the Blood Establishment and may also entail an on-site evaluation. For instance, BGTD may be on-site during the Production System Validation or the Production Trial. Other on-site evaluations may take place when it is deemed necessary to examine more closely the evidence of validation. For example, in the case of implementation of "off the shelf" software it may be necessary to perform an on-site evaluation with the software vendor.

6. Submission Numbering

There are five to seven parts to the submission depending on the number of Blood Establishment sites being implemented. Several interrelated documents need to be submitted and the use of an appropriate numbering system can reduce the problem of relating and identifying documents. The following procedures should be followed:

• The contents of the submission should be listed using the form and classification of Part, Section, Subsection (e.g., 1.2.3. would denote Part 1, Section 2, Subsection 3). If the documentation for any part or section is too voluminous, it may be assembled in Volumes.
• All parts must be included in the submission. If a part is not applicable to the particular situation, prior approval must be obtained from Health Canada to delete the particular part from the submission.
• Each part of the submission and each of its sections should be clearly identified.
• Each part and each section should have its own table of contents.

An additional item of consideration is the numbering used within the documents. Each document submitted is reviewed in context with other documents. The internal numbering within the documents can either hinder or help. Therefore it is suggested that consistent numbering be applied across all documents. For example, the identification numbering of the processes within the Process Model (Part 1, Section 1.5) should have the same identification numbering applied to other documents that are derived from or related to the Process Model. For example, a process in the Process Model may be identified as a risk in the Hazard Analysis (Part 1, Section 1.6) and require a mitigating work instruction. For ease of identification, the work instruction should reference the same numbering as the operational process in the Process Model.

7. Structure of a Submission

A submission is composed of seven parts. Parts 1 to 5 are mandatory. Parts 6 and 7 are only required if the operational changes are to be implemented in additional sites. Therefore a single site implementation only requires Parts 1 to 5.

The 7 Parts are defined as follows:

• Part 1 describes in detail the process changes that are proposed to the manufacturing operations;
• Part 2 defines each of the validation plans that will be used to validate the total operational process change;
• Part 3 documents the results of each of the validation plans defined and described in Part 2;
• Part 4 is the documentation of the Production Trial Plan and the approval by Health Canada to proceed with the Production Trial;
• Part 5 is the execution of the Production Trial and the documentation of the results;
• Part 6 is the overall planning for the implementation of the Production Trial at other Blood Establishment sites; and,
• Part 7 is the planning and implementation of the Production Trial at a specific Blood Establishment site. Part 7 is undertaken for each and every additional site.

Part 1 OPERATIONAL CHANGE

Part 1 describes, in detail the process changes that are proposed to the manufacturing operations, including software and work instructions changes, along with the good manufacturing processes used to create the software and work instructions.

1.1 Submission Certification

The Submission Certification must attest that the information provided in the submission is accurate, complete, not false or misleading nor has any material fact been omitted.

1.2 Overview

A high level overview of the operational process change must be provided. This will include:

• a rationale as to why the change is being made or is required;
• what computerised system is being modified or replaced; and,
• what parts of the operations (processes) will be affected and how.

1.3 Operational Impact

Define the positive or negative impacts the process change will have on the operations, with emphasis placed on safety. Benefits should be expressed both in quantitative and qualitative terms.

The identification of impacts and risks is especially important since the changes to the operational processes are expected to be positive and that these benefits must be measurable to ensure the changes do not result in a negative impact on safety. Therefore a measurable baseline must be provided for the existing operations, including an approach to measure the impact of the changes to ensure that safety has not been compromised.

1.4 Requirements Specification

The change to the operations must be expressed in terms of new or modified functions that will be performed. A "Requirements Specification" document must be developed that outlines in detail the functions of the new or modified processes. These processes must include the changes to all work instructions and any computer systems. The Requirements Specification is the document to use as the basis for outlining the functional requirements and is to be used as one of the tools in providing evidence of validation.

1.5 Process Analysis

The success for a process change, either work instructions or a computerised system, depends on achieving a clear understanding of the needs of the Blood Establishment and the operational environment. To achieve this understanding of the current operational environment and the new operational environment, the processes must be analysed and documented at a detail level to ensure all stakeholders have a clear understanding of the impact the change will have on the operational environment.

To document this understanding, Process Models of both the current and future operations with accompanying Narratives are required for submission. The Process Models should reflect both work instructions and computerised functions described at a level of detail that ensures clarity of understanding of the processes. Additionally, it should reference all the work instructions that are impacted directly or indirectly by the operational change (see 2.5).

If the process changes to be implemented are different at each site of the Blood Establishment then the Process Model and Narrative must detail the differences at each site.

1.6 Hazard Analysis

Risk reduction and mitigation techniques are employed to control the severity of a hazard and/or the likelihood of it occurring. The Hazard Analysis begins with the identification of all potential hazards with the new processes. The severity of each hazard, should it occur, is then assessed qualitatively. Categories of severity such as: minor, significant, critical or catastrophic.

A process may have multiple potential hazards associated with it. Likewise, each hazard may have multiple potential causes. All potential causes for each hazard should be identified. The estimated likelihood of each hazard occurring is then assessed, either qualitatively or quantitatively. The likelihood could be expressed as a specific probability or a range such as high, medium or low.

Subsequently, a determination is made about the hazard's potential impact on the Blood Establishment, based on the severity of the hazard and the estimated likelihood of its occurrence. Migitation measures are then defined for those hazards that the Blood Establishment considers having a high potential impact.

The Hazard Analysis is especially relevant to Control Points. Computerised systems that significantly contribute to decisions regarding the suitability or traceability of a biologic product for use or for further manufacture is said to have Control Points. Control Points must be further analysed to ensure that the mitigation measures themselves do not add any additional risk.

The Hazard Analysis documentation submitted must include the following:

• a list of the hazards and description of how they are identified;
• the estimated likelihood of each hazard occurring and how it is estimated;
• the estimated severity of each hazard and how it is categorised; and,
• a description of the mitigation strategy to be employed for each hazard and for each Control Point, and how its effectiveness is assessed.

1.7 Software Development

The system development activity is mostly concerned with the computerised portion of an operational change but changes in work instructions must be taken into consideration since these must also be validated.

The intent of this section is to ensure that good manufacturing practices were used in the development of the computerised system and the demonstration of these practices. Therefore, the following documents must be included in the Blood Establishment's submission:

• Detailed Functional Specifications;
• Gap Analysis (changes from a prior version to the current version);
• Detailed Customisation Specifications, if any;
• Technical Architecture, including networks and hardware;
• Application Software Architecture description;
• Application Software Module descriptions; and,
• Detailed Description of Internal and External interfaces.

1.8 Software Development Standards

To ensure that software is created and maintained using good manufacturing practices, the following work instructions must be submitted, with examples:

Software Development Life-Cycle Methodology

A description of the process used to create the software including all quality assurance activities.

Software Design Standards

The work instructions followed by the designers to design the system.

Programming Standards

The work instructions followed by the programmers to write the software.

Software Testing

The process and work instructions employed to test the software.

Configuration Management

The work instructions followed for configuration management:

Change Control

which consists of the processes, authorities and procedures used for all changes that are made to the computerised system.

Change Requests

must establish and maintain a procedure to identify, document, review, and classify changes to the computerised system or work instructions requested by its users during the implementation process.

Audit Trails

in the form of a logical path linking a sequence of events, used to trace the transactions that affect the contents of a record. They document changes made to critical data.

Documentation Control

is the management of all the documents associated with a computer system and work instructions.

1.9 Software Implementation Standards

To ensure the software is being implemented by the Blood Establishment using good manufacturing practices, the following work instructions must be submitted:

Configuration Parameter Selection

The work instructions followed by the Blood Establishment to configure the software for the Blood Establishment's specific installation.

Change Control

The work instructions followed by the Blood Establishment to manage all changes made to the environment during the implementation period, either by the Blood Establishment or the Software Vendor.

1.10 Work Instructions Development

The modification or implementation of a system requires changes to or the development of new work instructions to support the operational processes. New work instructions must integrate with computer systems or other work instructions. In instances where new work instructions interface with current work instructions the interface must be made transparent to ensure compatibility and safety of the operations.

All new or modified work instructions and associated directives must be developed using good manufacturing practices. The work instructions must be defined within the context of the Process Model. Work instructions that are used to mitigate risks or are used at Control Points must be identified as such.

In conjunction with the submission, a cross-reference must be provided from the current operational work instructions to the new or modified work instructions with an indication of whether the current work instructions or parts thereof have been deleted, modified or included in the new work instruction.

In summary, the documents required for submission are:

• the new work instructions;
• a list of mitigating or control work instructions;
• a cross reference list from old to new work instructions; and,
• a list of obsolete work instructions.

NOTE: work instructions in this context include standard operating procedures, directives, technical specifications and standards, user guides, manuals or any other vehicle used to convey information to personnel as to how to undertake their work activities whether as a user of the system or supporting the system operation.

1.11 Validation Strategy Overview

Validation is the establishment of documented evidence which provides a high degree of assurance that a specific process or system will consistently produce a product meeting its predetermined specifications and quality attributes. These specifications and quality attributes were specified in the Operational Impact and Requirements Specifications.

A strategy for the validation of all the operational processes being introduced or modified must be presented and encompass all aspects described in Section 2, "Validation Planning".

1.12 Project Schedule

A project schedule should be submitted that identifies significant milestones and the projected dates for the submission of Parts 2 to 7.

Part 2 VALIDATION PLANNING

A computerised system includes software, hardware, work instructions, data, personnel and documentation. Blood Establishments are responsible for the use of computerised systems in their facilities, whether purchased from a software vendor or developed by the Blood Establishment, and they must ensure that the computerised systems are validated prior to use.

Validation is the establishment of documented evidence which provides a high degree of assurance that a specific process or system will consistently produce a product meeting its predetermined specifications and quality attributes. Part 2 of the submission is concerned with the planning for the validation of the process changes that are described in Part 1.

2.1 Software Validation Plan

The Validation Plan for software describes how the specific software installed at the Blood Establishment will be validated and what documents will be provided as validation evidence.

The Validation Plan and documents must be based on recognised software industry testing practices and the principles of software validation. The Validation Plan should explain the approach, the methodologies to be used, tools and techniques and detail the documents to be submitted as evidence of validation. The plan should relate the test cases to the Requirements Specification and Functional Specifications.

If a Blood Establishment purchases a computerised system, information regarding the software vendor's testing and quality assurance processes must be included as part of the Validation Plan. Particular attention must be given to parts of the software that are modified specifically for the Blood Establishment.

Testing is required at several levels, from the individual item to the complete computerised system. There are several different approaches to software testing. The Validation Plan must describe the approaches the Blood Establishment will use.

2.1.1 Types of Testing

Three types of testing must be included in the validation. Each type of testing described below should be conducted as part of the validation.

Unit Testing

Unit testing is conducted to verify the implementation of the design for the software element; e.g., a unit or module; or a collection of software elements.

Functional Testing

Functional testing is the process of attempting to find discrepancies between the programme and its external functional specifications by examining the transaction flows in the software.

System Testing

System testing is the process of testing an integrated hardware and software system to verify that the system meets the specified requirements. There are four categories of system tests that must be presented as part of the validation.

Volume Testing

is subjecting the programme to heavy volumes of data. The purpose of volume testing is to show that the programme can handle the volume of data specified in its objectives.

Stress Testing

is subjecting the programme to heavy loads or stresses. This should not be confused with volume testing; a heavy stress is a peak volume of data encountered over a short period of time.

Performance Testing

is the process of showing that the programme satisfies its performance objectives.

Usability Testing

attempts to find human-factor or usability problems. This is especially important where the user must also follow work instructions based on the output from the computer system.

2.1.2 Approach to Testing

Testing starts by establishing a test plan, test controls, test cases and test scenarios for each Test Type. A testing environment which is segregated or partitioned from the production computerised system (e.g., software and database) must be established and maintained to ensure the integrity of data.

Test Plan
A test plan is documentation specifying the scope, approach, resources, and schedule of the intended testing activity. A test plan should identify:

• each test item, activity or feature to be tested;
• assumptions;
• test procedure to be used;
• acceptance criteria;
• test tools and techniques; and,
• methodologies to be used.

Test Control
For each of the activities related to the test plan, Blood Establishments must establish procedures to ensure that:

• test results are documented and verified;
• test tools are described, tested and qualified prior to use;
• appropriate test configuration is used, including support software and computer hardware; and,
• defect tracking and regression testing process is followed.

Test Cases
One of the more important considerations in computerised system testing is the design of effective test cases. The complete testing of software requires the challenge of each decision path within the programme. Since this is not always practical nor feasible, the coverage approach must be defined for each of the test types for which test cases are developed. Test cases must include:

• test description;
• test scripts;
• test values;
• expected results; and,
• documentation of test values and results.

Test Scenarios
Tests cases are grouped into scenarios to test more complex sequences of test cases. Scenarios usually include test cases that are linked together by a logical sequence according to the operational processes.

2.2 Technical Environment Qualification

The validation of the technical environment must be undertaken to ensure that the operation of the validated application software is not impacted in any way by the technical aspects of the system and additionally the technical environment adequately supports the new operational environment. There are three specific technical aspects that must be considered.

Technical Configuration Testing

is testing the programme with each type of hardware device with the minimum and maximum configuration. Programmes such as operating systems and database management systems support a variety of hardware configurations. If the programme can be configured, each configuration of the programme should be tested.

Recovery Testing

is to demonstrate that the backup and recovery functions work properly. Programmes often have recovery objectives, stating how the system is to recover from programming errors, hardware failures and data errors.

Security Testing

is the protection of hardware and software from accidental or malicious access, use, modification, destruction, or disclosure. Security also pertains to personnel, data, communications, and the physical protection of the computer installation.

2.3 Data Conversion Validation Plan

When a new computer system is introduced or the database of a current system modified, data conversion from the old system to the new system is often necessary. If data conversion is to take place, then a Data Conversion Validation Plan is required. The plan must detail the data conversion processes and the reconciliation that must take place to ensure that the conversion operates correctly and the data is not compromised. If the data needs to be "cleaned" then this process must also be described.

The reconciliation must describe in detail the process for reconciling the data from a source database or files to the target database or files. This reconciliation must include record counts, field counts, deferral codes converted, records or fields merged or deleted, etc. All data transferred from the source to the target must be reconciled and must be accounted for. The Data Conversion Validation Plan must also demonstrate how the reconciliation will be completed before the Production Trial starts.

2.4 Configured Software Validation Plan

Certain types of software can be configured for the specific installation. This is done by selecting appropriate parameters and tables, specifying specific reports, developing custom reports and selecting the software processes and their execution sequence. The software version configured for installation in the Blood Establishment must be validated to ensure that it operates as intended and presents no safety risks, such as printing the wrong label. The plan for validating the specific configured software version to be installed is based on all possible scenarios and associated test cases, developed to ensure that the software operates as configured. Special attention must be given to testing all Control Points, identified in the Hazard Analysis, that may be impacted by the configuration.

The Validation Plan must include:

• the approach to validation;
• the methodology;
• detail lists of software items that are configured; and,
• list of scenarios and test cases.

2.5 Work Instructions Validation Plan

Work instructions define operational activities and must conform to current regulations and guidelines that apply to Blood Establishments and as such must be validated within the context of the operational processes. The validation must take the form of testing the work instructions to ensure they operate as designed.

In instances where work instructions are used in conjunction with a computer system, they must be validated with the computer system. Both direct (those used with the computerised system) and indirect (those that use the input/output of the computerised system) work instructions must be validated. Special attention must be given to work instructions that are used to mitigate risks identified in the Hazard Analysis.

The validation of the work instructions must follow a defined plan and approach. Work instructions must be tested in what will be their normal operational environment. They can be tested individually with the software or included as part of another validation, such as Software Validation. Some work instructions may not be validated easily with the software, due to cost and feasibility considerations. Those may be validated by a simulation or a walk through by the group of individuals who will use the work instruction in their normal work activities.

The Validation Plan must include:

• the approach to validation;
• the methodology;
• detailed list of the work instructions; and,
• scenarios and test cases for each work instruction.

2.6 Personnel Training Validation Plan

There are two aspects to personnel training validation. The first is the approach to training. A training plan must be submitted which clearly details its objective, course outlines, methods, resources, and schedule. The second aspect is the process and approach for validating the competency of the personnel for the Production Trial.

2.7 Materials Validation Plan

In a regulatory environment the validation of materials plays a key role. All new materials consumed and/or produced with an operational change must be validated. These include new bags, test kits, labels, etc. If new materials are included in the system then a Materials Validation Plan must indicate how these will be validated.

2.8 System Recovery Validation Plan

Many types of problems can impact a blood establishment's computerized system such as hardware failure, communications failure, etc. There are two levels of system recovery. The first level is the recovery of the computer system within a few hours without having to use alternate sites and work instructions. The second occurs when alternate sites and work instructions must be used prior to initiating recovery processes.

For a short duration failure, the Blood Establishment must have work instructions to recover the computer system and ensure it is operating properly prior to resuming the use of the system. The validation plan must define how this level of recovery will be validated.

When a computer system is unavailable for a long period and alternate sites and work instructions are used, the Blood Establishment must have in place complete alternate work instructions and the staff trained to use them both to maintain the operations and return it to proper functioning. The validation plan must define how this level of recovery will be validated.

The System Recovery Validation Plan must include:

• the types of system failures to be validated;
• the levels of recovery to be validated;
• the approach;
• the methodology;
• a list of the alternative work instructions; and,
• the tests to be employed.

If there is a general disaster recovery plan in place in the Blood Establishment then it can be used, where appropriate to minimise the amount of validation required.

2.9 Production System Validation Plan

The Production System Validation Plan takes all the production components into one overall parallel test or simulation. The parallel or simulation must be as close to the real world as possible using the equipment, software, configuration and personnel that will operate in a production environment.

The plan must clearly define in detail its approach, objectives to be achieved, process and methods to be employed, personnel, and schedule. It must describe, in detail, what will constitute the validation evidence and how it will be collected. This validation evidence must show that safety has not been compromised and that the positive impacts from the change will be achieved. The evidence of validation must address the following areas:

• Software;
• Technical Environment;
• Internal and External Interfaces;
• Data Conversion;
• Work Instructions;
• Personnel Training; and,
• Materials.

Processes that cannot be fully tested in the Production System Validation must have an alternative method of validation approved by the appropriate authority in Health Canada.

2.10 Project Schedule

A project schedule that identifies significant milestones and the projected dates for the submission of Parts 3 to 7 should be submitted.

Part 3 VALIDATION

The objective of Part 3 is the presentation of demonstrated evidence of validation according to the validation plans submitted. Should there be changes to the various validation plans described in Part 2, the changes must be submitted for approval.

3.1 Software Validation

Documented evidence must be presented to demonstrate validated software. It should follow the previously submitted validation plan. If there are any significant changes made to the plan, they must be documented and the changes justified.

3.2 Technical Environment Qualification

Documented evidence must be presented for each of the three areas under the Technical Environment, namely, Technical Configuration, Recovery Testing and Security Testing.

3.3 Data Conversion Validation

The evidence presented must be an actual data conversion test with a reconciliation of all the data from the source to the target. It should follow the previously submitted validation plan.

3.4 Configured Software Validation

The validation evidence of the installed software must include documented testing of any parameter settings, tables, process settings, labels and reports. It should follow the previously submitted validation plan.

3.5 Work Instructions Validation

The evidence of validation must show that all work instructions were fully tested by personnel that would normally use the work instructions in a production environment. It should follow the previously submitted validation plan.

3.6 Personnel Training Validation

The evidence must demonstrate that the process for training has resulted in the personnel executing software and work instructions correctly. It should follow the previously submitted validation plan.

3.7 Materials Validation

Evidence submitted must show that all the material will function properly in a production environment and that any new medical device has been approved by the appropriate regulators.

3.8 System Recovery Validation

The evidence must demonstrate that the System Recovery Validation will recover all types and levels of failure and return to normal operations without impacting safety. It should follow the validation plan submitted in Part 2, Section 2.8.

3.9 Production System Validation

The validation must provide evidence that all the components operate together correctly, that patient and donor safety is not compromised and that the objectives are met. It should follow the previously submitted validation plan.

3.10 Corrective Action and Results

As a result of the Production System validation, corrective actions may be required to address problems or situations needing correction. These should be documented and evidence presented as to how these changes were or will be validated to meet the Production System Validation Plan.

3.11 Project Schedule

An updated project schedule, which includes significant milestones and at least the projected dates for the submission of Part 4, should be submitted.

Part 4 PRODUCTION TRIAL PLAN

A production trial is the use of the new operational processes at a single site, as the system of record, to evaluate its operational readiness.

4.1 Production Trial Plan

A production trial plan must clearly define in detail its objective, method, resource, and schedule.

The plan must show how disaster recovery will be implemented in the event the Production Trial fails.

The plan must show how Production Trial will be monitored to ensure it is operating correctly.

Consideration will be given to Blood Establishments who wish to perform a Production Trial simultaneously at multiple sites.

4.2 Production Trial Support

The last task prior to the start of the Production Trial is to demonstrate that all the components necessary to maintain the new production environment are in place. This includes putting in place the trained personnel, work instructions, support tools and completing all "as built" documentation (i.e. the final version).

Blood Establishments must establish and maintain a procedure to document all errors / incidents as well as their eventual resolution and the consequences/impacts of unresolved issues.

The procedure should define:

• the responsibility and authority for the disposition of each type of error / incident;
• acceptable methods for reporting, investigating the error and the corrective action designed to prevent recurrence;
• the method for collecting, reporting and tracking until final disposition of all errors / incidents; and,
• how and when the establishment performs management reviews of these.

4.3 Decision to Proceed with Production Trial

The Blood Establishment must accept responsibility for the quality of the new operational processes and the validation of its design and features. The decision statement asserts that by proceeding with the production trial, it will not compromise the safety of the manufactured product(s). The decision statement is to be signed by the Chief Executive Officer (or equivalent) of the Blood Establishment.

4.4 Project Schedule

An updated project schedule which includes significant milestones and at least the projected dates for the remaining activities, should be submitted.

4.5 BGTD Approval to Proceed

Prior to the Blood Establishment proceeding to Part 5, the BGTD must issue an Acceptable Licence Amendment letter for a Single Site Production Trial.

Part 5 PRODUCTION TRIAL

Part 5 focuses on the execution of the Production Trial and the plan to implement the new operational processes in additional sites after the Production Trial is accepted as successful.

5.1 Production Trial Execution

Detailed daily monitoring and daily reporting must be maintained during the Production Trial and problems impacting safety must be reported within 4 (four) hours to responsible authority in BGTD.

5.2 Production Trial Report

The report must detail the results of the Production Trial and provide evidence that the Trial proceeded according to the plan and achieved its objectives. It must identify and detail all problems encountered and the corrective actions and validation taken to address these problems during the Trial, and list the problems not corrected during the Trial.

5.3 Corrective Action Plan

As a result of the Production Trial, there may be a list of problems still outstanding that must be corrected in the future. These problems may require programme fixes, work instruction changes, etc. The corrective action may be required to address problems or situations prior to the implementation at other sites. These should be documented and evidence presented as to how these changes will be validated. Problems that will not be corrected before rollout to other sites must be detailed and a rationale as to why this approach is being taken.

Part 6 IMPLEMENTATION PLANNING

If the Blood Establishment has multiple sites that need to have the system implemented then they must follow the processes described in Part 6 and 7.

6.1 Roll-out Strategy and Plan

The implementation Roll-out Strategy and Plan documents the deployment of the new operational processes at the different sites.

The plan must clearly define in detail its objective, method, resource, and schedule for a complete roll-out to all sites.

6.2 Generic Site Verification Guide

Installing new operational processes in an environment different from the Production Trial can cause unintended consequences. Therefore, testing prior to the implementation must be performed by the Blood Establishment at each site. The Generic Site Verification Guide will describe how the new operational processes, including staff training and work instructions, will be validated and implemented at a site; how specific site work instructions that are different from the Production Trial site will be addressed; and how any data conversion will be validated. The Generic Site Verification Guide must be submitted prior to the beginning of the roll-out.

6.3 Decision to Proceed with Implementation Roll-out

The Blood Establishment must accept responsibility for the quality of the new operational processes and the validation of its design and features. The decision statement asserts that by proceeding with the implementation, it will not compromise the safety of the manufactured product(s). The decision statement is to be signed by the Chief Executive Officer of the Blood Establishment.

Part 7 SITE VERIFICATION

This part is only applicable to Blood Establishments with facilities at multiple sites. A Part 7 must be submitted for each site implemented.

7.1 Submission Certification

A submission certificate must be submitted for each site that is to be implemented.

7.2 Specific Site Verification Guide

The Blood Establishment must complete and document the previously defined Generic Site Verification Guide for each site to be implemented, resulting in a Specific Site Verification Guide for each site. The Specific Site Verification Guide must be completed and submitted for approval prior to implementation at the site.

7.3 BGTD Approval to Proceed

Health Canada, upon approval of a Specific Site Verification Plan, will issue a Notification to Proceed for that site.

7.4 Site Notification Report

At each site of the Blood Establishment where the new operational processes are implemented, the Blood Establishment must notify Health Canada, within seven days after the implementation is completed. It must also provide detailed information on any problems discovered during the implementation and how these problems will be corrected, especially if the problems require changes to be made to previously implemented sites.