Validation autoclave

Fedegari Autoclavi SpA DM#223225.2 - March 2010

THEMA4 CONTROL SYSTEM

VALIDATION PACKAGE

COVER

Document Rev.1

EQUIPMENT

Serial

number

Model

Customer

HW/SW configuration

Library

config.

Panel PC

H

20

f1 OS/D

G

₆₃

_F4

Rem I/O

O

11

Sb1

Appl. SW

W

40.2

NA2403AW FOA8/DA

TECNOQUIMICAS

(Colombia)

C#

160

Lang.

L

₇₁

K

151

Type

- Cover (template of this document) # 223225 2

1 Validation Package Letter #223213 3

2 Life Cycle of Process Controller - GAMP 5 Approach #102179 6 3 21 CFR Part 11 Compliance Assessment #110434 2

General 4 Critical Review and Risk Management Report #339022 1

5 Software Validation Certificate #339032 1

6 Functional Design Specification (FDS) #221815 20 7 Software Design Specification (SDS) #222852 8

Wxx

8 Hardware Design Specification (HDS) #86791 32

9 Configuration Manual (CM) #188843 36

10 Change Control Manual (CC) #201698 34

11 Libraries Configuration Manual (CM_LIB) #205684 65 12 Library Change Control Manual (CC_LIB) #205878 65

Last change CH

FEDEGARI AUTOCLAVI SpA

S.S. 235 km 8 - 27010 Albuzzano (PV) - ITALY

DECLARATION

After more than fifty years in the business, Fedegari still holds an unquestionable

technological supremacy among sterilizer manufacturers worldwide. This achievement stems

exclusively from its continuing commitment to control every aspect of its machines and of the

process. Fedegari is in fact the only manufacturer that still produces in-house all the critical

components of its sterilizers.

This has allowed Fedegari to acquire, over the years, a deep knowledge and understanding

of everything that directly or indirectly affects the overall performance of the machine in terms

of both process and maintenance.

Nowadays, the process controller of a sterilizer is a highly critical element, both in terms of

performance and in terms of safety and assurance that the processes carried out cannot

be tampered with.

Moreover, pharmaceutical industry is responding to the challenge of significantly improving

the way drug development and manufacturing is managed, by means of the adoption of new

concepts and technologies of production, aiming to the integration of the manufacturing

processes and to match “Product quality & Patient safety” with “Delivery business benefit”. In

this new scenario, computerized systems are regarded as components of a wider

manufacturing process/system, where “Quality verification” and “cGMP compliance” requires

an approach based on “Integrated Quality by Design”, where separate validation may not be

sufficient or necessary.

Thema4 is the process controller of Fedegari pharmaceutical machines (dry- and moist-heat

sterilizers, washing machines, pass box, …) released to the market as a completely

configurable standard product, classified for user, as Category 4 - Configured Products, in

GAMP 5 categorization.

Thema4 It is the natural evolution of the well-established and reliable previous controller

Thema3, which has been on the market since 1995. While Thema4 has inherited the process

management principles of its predecessor, it is absolutely different in terms of the hardware

components used, software architecture, man machine interface and general and integrations

functions.

By Thema4, Fedegari assures the commercial availability of standard components, the

integration levels required in the modern pharmaceutical plants joined the functions and

performances that meets the quality and safety standards of the production processes for

which the application is intended.

Since the most suitable field of application for this new controller is the pharmaceutical one,

great care has been given in Thema4 Life Cycle management: from the Conception phase in

the choice of components and definition of system architecture and project management,

through the Project phase in the development of software parts in compliance with FDA

regulation CFR21 part 11, until the current Operation phase in the definition of product

management procedures (change control, configuration management, support, repair,

maintenance,..) in accordance with the principles of the guide line GAMP.

Now, after continuous improvements on software and hardware components, functions and

processes, Thema4 is in the maturity of its Operation phase and the reference guide line for

its management is the guide line GAMP 5.

Moreover, thanks to the adoption of GAMP5 concepts and CFR21part11 rules, Thema4

allows customers to operate in compliance with new revision1 of the EudraLex (The Rules

Governing Medicinal Products in the European Union) Volume 4 (Good Manufacturing

Practice Medicinal Products for Human and Veterinary Use) Annex 11: Computerised

Systems.

THEMA4 is an unique “standard” and “validated” controller for all Fedegari machines,

completely configurable, to manage:

-

all Fedegari machine types (moist heat sterilizers, dry heat sterilizers, hydrogen

peroxide decontamination pass boxes, washing sterilizers, robotized sterilization cells,

etc.) with implemented different process technologies,

-

all control system hardware configurations,

-

all functional options, developed to meet several integration and operation customer

requirements.

The software is not changeable by the user in order to increase the system safety and to

preserve the validated state.

Thanks its modular software architecture, Thema4 allows a complete independence between

the PROCESS implemented (software component P/G Library Kxx), the APPLICATION

SOFTWARE (software component Wxx), the CONTROLLER HARDWARE (software

component OS/D ) and the HMI/REPORTING LANGUAGE (software component Lxx/Jxx ).

This allows an easy, modular, safety and with a low impact on validation software upgrade, in

order to insert new machine functions, to change and to customize process functions (thank

to the Fedegari Phases’ Groups technology) and to upgrade HW components (in a

transparent way respect to the software) to face the market components obsolescence.

Thema4 is an evolution of the previous generation of Fedegari sterilizer controllers (Thema3

and Super Spectra) designed to maintain continuity with their main characteristics: operator

approach to machine management, process control based on a proper Phases’ Groups

library, the system architecture and the validation approach.

This allows Fedegari to propose “revamping plans”, preserving the customer investment,

improving the machine functions and performances and at the same time maintaining the

system always validated in compliance with the applicable current regulations.

An extensive team of experts assures that the controller is constantly innovated and manages

all new developments in accordance with the customers needs and the adopted GMP

standards.

By means of Thema4 Validation Package, Fedegari certifies and releases a clear evidence

that:

•

Software of the Thema4 process controller has been developed by Fedegari and has

been proper documented and tested, in accordance with the approach of the guideline

GAMP 5.

•

Thema4 is a well-structured software program which offers an extensive set of

functions and instruments, usable and configurable by the end user (according to its

own SOPs), for achieving compliance to FDA regulation CFR21p11 and to the

EudraLex Volume 4 - Annex 11: Computerised Systems (revision 1).

•

Change activities for modifying the software and hardware components of the process

controller, which consist in introducing improvements and in solving problems, are

conducted in accordance with a “Change control and configuration management

procedure”, in compliance with the indications of GAMP.

•

Software versions released by Fedegari are subjected to rigorous maintenance and are

identified by means of a unique code in accordance with the change control and

configuration management procedure.

•

Thema4 source code is stored on PC servers, undergoing regular and clearly defined

backup activities and access policy defined in organization procedures.

•

Source code and all life cycle documentation can be analyzed by customers on

request, in specific audits.

change activities, by means of the application of risk analysis methodology, as defined

in the procedures that are integral part of Fedegari’s quality documentation.

•

Proper training activities are regularly carried out on people involved in computerized

system management.

TUTORIAL: PRESENTATION OF VP DOCUMENTS

The Validation Package is composed of the documents listed in the following table :

VALIDATION PACKAGE DOCUMENTS

N° Document Type

- Cover NF

1 Validation Package Letter (this document)

2 Life Cycle of Process Controller - GAMP 5 Approach 3 21 CFR Part 11 Compliance Assessment

General

4 Critical Review and Risk Management Report 5 Software Validation Certificate

6 Functional Design Specification (FDS) 7 Software Design Specification (SDS)

Wxx.y

8 Hardware Design Specification (HDS) 9 Configuration Manual (CM)

10 Change Control Manual (CC)

11 Libraries Configuration Manual (CM_LIB) 12 Library Change Control Manual (CC_LIB)

Last change CHxxx

The field Type defines the document update, during the life cycle of the product Thema4:

-

NF

HW-SW configuration data depending on the system configuration

released for a defined machine NF (Factory Number)

-

General

documents updated when there is a change in the management of the

Thema4 life cycle

-

Wxx

documents depending on the version of the application software Wxx.y

released to the NF

0 - Cover

This document is of NF type: depending on the machine factory number.

The Cover is the introduction document, that reports the:

-

The equipment general data :customer name, factory number NF, machine model

-

The code of the main components of the system configuration C# assigned to the

equipment.

-

The list of the validation package documents with the document code and version,

assigned in the Fedegari document management system

The architecture of the Thema4 system configuration (SW, HW, tools and Doc

elements) is showed in the following table.

THEMA4 SYSTEM CONFIGURATION ARCHITECTURE

SYSTEM CONFIGURATION CODE (Global)

C#xxx

ELEMENT COMPONENT CODE

1 OPERATOR PANEL

_Hxx

1 HW OPERATOR PANEL

HW

2 I/O BUS BOARD

_Qxx

2

OPERATING SYSTEM/

DRIVER

SW 1 RTOS/DRIVER

Gxx

3

INTEGRATED DEVELOPMENT

ENVIRONMENT

Tool 1 IDE

_IDxx

1 APPLICATION SW

_Wxx.y

2 APP. LANGUAGE FILES

_Lxx

3 RECOVERY DISK

_RDxx

4 REMOTE GUI

_Rxx

4 APPLICATION SW - NUCLEUS

SW

5 ON-LINE MANUAL

_OMxx

5

APPLICATION SOFTWARE -

PHASE GROUPS LIBRARY

SW 1 PGL SW

Kxx

6 REMOTE

I/O

HW 1 REMOTE I/O

_Oxx

7 CONVERTER

RTD

HW 1 CONVERTER RTD

Txx

1 PRINTER

_Zxx

2 HUB/SWITCH

_Yxx

3 UPS

_Uxx

8 HW

EQUIPMENTS

HW 4 MESSAGES DISPLAY LCD

_Mxx

1 USER MANUAL PACKAGE

_UMxx

2 INSTALL. MANUAL

_IMxx

9 DOCUMENTS

Doc

3 REMOTE GUI MAN.

_GMxx

1 - Validation Package Letter (this document)

This document is of General type: depending on the Thema4 product life cycle.

The Letter is the signed (by the Automation Manager and the Quality Manager) formal

declaration of the quality approach followed in the Thema4 life cycle management , that

is based on:

-

a quality system with procedures,

-

guideline (GAMP)

-

standard (CFR21p11)

The document includes a tutorial to introduce the user in the architecture and contents

of the Validation Package documents.

2- Life Cycle of Process Controller - GAMP 5 Approach

This document is of General type: depending on the Thema4 product life cycle.

The document describe the quality approach GAMP based, Fedegari has followed in

Thema4 control system development, starting from the Conceptualization initial phase

of the product life cycle up to the current Operational phase.

The document describes the key operational procedure adopted: Service and

performance Management, Incident Management and CAPA, Change Management

Process, Repair Activity, Periodic Review (Internal Quality Audits), Continuity

Management, Security and System Administration, Record Management.

3- The 21 CFR Part 11 Compliance Assessment

This document is of General type: depending on the Thema4 product life cycle.

The document describe the Thema4 native compliance with Food and Drug

Administration 21 CFR Part 11 (Electronic records; Electronic Signatures; Final Rule).

In fact Thema4 has a well-structured software architecture which offers an extensive set of

“instruments” (i.e. setting variables and parameters) that end user can configure according to

its own SOPs) for achieving and “easy and configurable” compliance to “part 11”.

The document, referring to all sections of the 21CFR11, describe how this requirements have

been interpreted and satisfied by Thema4 computerized control system, in order to provide a

proper management of electronic records and electronic signatures for pharmaceutical

regulated industries.

4- Critical Review and Risk Management Report

This document is of Wxx.y type: depending on the application software version Wxx.y

released for the NF.

The validation for a complex process controller as Thema4 can not be a “pass/fail process”.

The results of the tests should be analysed according to pre-defined criteria in order to

estimate the grade and the quality of the occurred deviations and of the pointed out notes.

Following this approach a more conscious release can be obtained, giving also a scenario for

possible corrective actions to be implemented according to their criticality.

This document can be considered as the conclusion of the validation activity carried

out on process controller software Wxx.y, which requires the critical review of the test

results performed. This activity is part of the Risk Management Process and this

document is the relevant “output”.

With this activity the not-passed tests and the comments collected during the validation are

analysed to verify their criticality, according to the Quality System Procedure PAQ-08 “Risk

the specific software version or not.

Validation activity is part of the Thema4 change control procedure, as described in validation

package document 2.

5- Software Validation Certificate

This document is of Wxx.y type: depending on the application software version Wxx.y

released for the NF.

The document is the formal certificate, that is the output of the Critical Review and Risk

Management Report (VP doc 4) and that enables the release in production of the

application software Wxx.y assigned to the NF.

6- Functional Design Specification (FDS)

This document is of Wxx.y type: depending on the application software version Wxx.y

The FDS is the functional specification of THEMA4 process controller, describing the

hardware configuration (Thema4 is a computerized control and automation system

based on commercial hardware), the software architecture and the controller functions.

The document applicable to all machine types supported by Thema4 control system:

THEMA4 MACHINE TYPES

Machine type

Machine Process managed

1 Autoclave moist-heat or gas sterilization

2 Oven dry-heat sterilization

3 FCDV (VHP) Fedegari Cabinet Decontamination VHP (Vaporized Hydrogen Peroxide)

4 FCDM (DMD) Fedegari Cabinet Decontamination Mist

The document is composed of the following sections:

-

PHYSICAL DESCRIPTION OF THE CONTROL SYSTEM :

SYSTEM ARCHITECTURE, HARDWARE ARCHITECTURE, SOFTWARE ARCHITECTURE, DATA STORAGE DEVICES, BACKUP/RESTORE DATA, DIGITAL/ANALOG I/O FOR THE CONNECTION TO THE FIELD, COMMUNICATION PROTOCOLS FOR THE CONNECTION TO EXTERNAL SYSTEM, UNITS OF MEASURE ADOPTED, SYSTEM LIMIT OPERATING CONDITIONS

-

PROCESS MANAGEMENT :

THEMA4 “PROCESS TASK” ARCHITECTURE, PHASE GROUPS – CYCLES - PROGRAMS, “PHASE GROUP” LIBRARY (P/Gs), CYCLE EXECUTION GENERAL FLOWS, CYCLES AND OPERATING PROGRAMS, ALARMS GENERAL INFORMATION (NUCLEUS, CONFIGURATION AND PHASE ALARMS), ALARM LIST (TEXT, EFFECTS; DELAY), ALARMS CAUSES AND SOLUTIONS.

-

DIALOGUE LANGUAGE

: STANDARD AND CUSTOM LANGUAGES (HMI AND REPORTS), CODE PAGE AND UNICODE FORMATS.

-

PASSWORDS:

ACCESS CODE CONFIGURATION PARAMETERS, LOCAL AND REMOTE ACCESS, OPERATING MODES (ADMINISTRATOR, SUPERVISOR, MAINTENANCE, USER), PASSWORD MODIFICATION, CURRENT LOGIN MANIFESTATION (DISPLAY AND PRINTOUT).

-

LIST OF OPERATIONS

: GUI OPERATING MENUS, RUNS & OPERATIONS (PROGRAM RUN , MONITORING, REPORTING AND CONTROL), PROGRAM MANAGEMENT (PROGRAM CREATION AND CONFIGURATION), CYCLE MANAGEMENT, SYSTEM SETUP & CONFIGURATION (PARAMETERS AND SETTING; SOFTWARE VERSION, OPTIONS ENABLED)

-

DIAGNOSE & MAINTENANCE

: (I/O, ALARM, SENSORS CALIBRATION, MAINTENANCE OPERATIONS, BACKGROUND OPERATIONS, BACKUP & RESTORE, HARD DISK & ARCHIVE MAINTENANCE

-

LOG-IN & PASSWORDS

: LOGGED SESSIONS, LOGOUT AND SHUTDOWN, ACCESS POLICY CONFIGURATION, LOGIN PERMISSION CONFIGURATION AND MANAGEMENT.

-

ON-LINE MANUALS

: GENERAL, NAVIGATOR AND MACHINE TYPE MANUALS.

-

PROGRAM EXECUTION

: TIME CALCULATION, PROCESS SUMMARY, PROCESS REPORT

-

PRINTOUT MANAGEMENT:

PRINTERS SUPPORTED, ARCHIVED AND PRINTED DATA, PROCESS REPORT STRUCTURE.

-

BLACKOUT

MANAGEMENT (DETECTION, MANIFESTATION, PROCEDURE), STERILIZATION AND TREATMENT TIME ELAPSED DURING A BLACKOUT

-

DOOR MANAGEMENT

: DOORS TYPE, OPENING, MOVING AND CLOSING CRITERIA, LOADING AND UNLOADING OPERATIONS.

-

EXTERNAL RECORDERS MANAGEMENT

: INTEGRATION TYPES

7 - Software Design Specification (SDS)

This document is of Wxx.y type: depending on the application software version Wxx.y

The SDS is the software design specification of Thema4 control system.

The detailed design specification is reported in other documents related to all the

software baselines released and the software changes implemented.

SDS document is composed of the following sections:

-

1 SOFTWARE ARCHITECTURE OF THEMA4 CONTROL SYSTEM - This section

describes the software architecture of the control system and provide an overview of the

basic elements of the software management: programming languages, operating system,

development environment tools, software components versioning, general guidelines for

the software development.

-

2 SOFTWARE COMPONENTS This section describes each basic software element that

build up the Thema4 control system.

-

3 FILE SYSTEM ORGANIZATION This section describes the file system organization of

the hard drive partition used to store data and application. It describes also the data

stored and the folder structure of the application.

-

4 LANGUAGES This section describes the approach adopted to implement a software

version independent multi-language system in the Thema4. It describes language files

architecture and codepages format, describing the impact on peripherals.

-

5 INTEGRATION WITH EXTERNAL SYSTEMS This section describes the software

architecture for the communication with external systems, by means of standard protocol

servers and software layers implemented, through Ethernet and serial connections.

8 - Hardware Design Specification (HDS)

This document is of CHxxx type: depending on the last change activity CHxxx

executed

The HDS is the hardware design specification of Thema4 control system, where only

market components are utilized.

The aim of this document is to define the hardware structure of the Thema4 process

controller, detailing each module and the interfaces between these modules and with

external systems.

describes the overall hardware architecture of the control system Thema4, identifying the

basic elements (standard and optional) and how they are interconnected.

-

2 DETAILED SPECIFICATION OF HARDWARE COMPONENTS This section describes

each basic hardware element. Additionally, for each of them, it is reported the list of

models supported with their technical characteristics.

9 - Configuration Manual (CM)

This document is of CHxxx type: depending on the last change activity CHxxx

executed

This document is the final output of the Configuration Management process executed

into a “Change activity” (coded by the index CHxxx) on the Thema4 control system

components:

-

Hardware components

-

Software components, except the PGL software Kxx, that is manage by a proper

document “Libraries Configuration Manual (CM_LIB)”

-

Third party software (operating systems, library files, drivers, firmware, IDE, ..)

-

Manuals released to the end-user

Because the two processes, Configuration Management and Operational Change

Control, are closely related each other, they are executed in parallel during a “Change

activity” and the CM document is the reference for the document “Change Control

Manual (CC)”.

CM document allows :

-

to defines and identify (by a code and a version number) all system items

-

to control the modification and the release of each items

-

to ensure the completeness, consistency and correctness (compatibility) of the items

and their baselines (system configurations)

-

to exactly identify, by a index C#xx, the system configurations released

CM document is composed of several tables: the system configuration table and the derived

components configuration tables and sub-tables .

10 - Change Control Manual (CC)

This document is of CHxxx type: depending on the last change activity CHxxx

executed

This document is the final output of the Operational Change Control process, strictly

related to the Configuration Management process, executed into a “Change activity”

(CH) on the Thema4 control system components as reported in the Configuration

Manual (CM).

The Change activity of hardware and/or software components of Thema4 control system are

required, in order:

-

to solve problems: faults detected coded by FAULT REGISTER (FRxxx)

-

to insert new functions or components: new implementations coded by CHANGE

REQUEST (CRxxx).

CC document is composed of several tables where, all components (new or changed)

present in the CM document are linked to the requirement FRxxx or CRxxx, at the origin of

the change.

11 - Libraries Configuration Manual (CM_LIB)

This document is of CHxxx type: depending on the last change activity CHxxx

executed

This document is the final output of the Configuration Management process executed

into a “Change activity” (coded by the index CHxxx) on the Thema4 control system

component Kxx.

The Kxx component is includes of the sub-components:

THEMA4 SYSTEM CONFIGURATION ARCHITECTURE

APPLICATION SOFTWARE - PHASE GROUPS LIBRARY

Kxxx

ELEMENT COMPONENT CODE

1 P/G LIBRARY SW

_T4LIBxx.y

2 PGL LANGUAGE .FILES

_Jxx

1 PGL

SW

SW

3 PHASE ALARMS LIST

_Px

T4LIBxx.y is a collection of independent software components: the Phase Groups (P/G).

Each P/G implement a process function, composed of several phases (maximum 16), that are

inserted in a process task of one of these types:

-

Cycle task (a sequence of more P/G)

-

Background task (only 1 P/G)

-

Stand-by task (only 1 P/G)

Jxx is the library language files, with string of the Phase parameters, and Phase name, in the

language released (standard and optional)

Pxx is the configuration file to load in Thema4 system, to identify in the machine the Phase

alarms applicable to a defined library.

For each PGL Kxxx, in the CM_LIB there are: the list of P/Gs released in the library

T4LIBxxy, the language file Jxx associated and the phase alarm list file Pxx.

12 - Libraries Change Control Manual (CC_LIB)

This document is of CHxxx type: depending on the last change activity CHxxx

executed

This document is the final output of the Operational Change Control process, strictly

related to the Configuration Management process, executed into a “Change activity”

(CH) on the Thema4 control system component Kxx, as reported in the Libraries

Configuration Manual (CM_LIB).

The Change activity of hardware and/or software components of Thema4 control system are

required, in order:

-

to solve problems: faults detected coded by FAULT REGISTER (FRxxx)

-

to insert new functions or components: new implementations coded by CHANGE

REQUEST (CRxxx).

CC_LIB document is composed of several tables where, all components (new or changed)

present in the CM_LIB document are linked to the requirement FRxxx or CRxxx, at the origin

of the change.

INTRODUCTION

Thema4 is the high performance, standard and validated control systems of Fedegari,

dedicated to control different types of pharmaceutical machines and characterized from an

high capacity, flexibility and configurability in order to fit all customer needs in a standard way

and at the same time providing user an high level of security and reliability.

From its conception, the Thema4 system has been designed, developed and validated

following a defined product life cycle according to GAMP approach, in order to meet the

regulatory requirements of the current GMP.

Now in its operational life, Thema4 has passes from GAMP 4 guide line approach (adopted

since its “foundation”) to the new concepts of GAMP 5, that are been progressively introduced

in the life cycle of the system.

DOCUMENT SECTIONS

This document is composed of the following sections

1

_{GxP REGULATED COMPUTERIZED SYSTEM}

2

_{THEMA4 LIFE CYCLE}

INDEX

1

GXP REGULATED COMPUTERIZED SYSTEM

... 7

1.2

THE PRODUCTION OF PHARMACEUTICAL AND MEDICAL DEVICES ... 8

1.3

THE GUIDE LINE GAMP®... 8

1.3.1 GAMP® 4 ... 8

1.3.2 GAMP® 5 ... 9

2

THEMA4 LIFE CYCLE

... 11

2.1

COMPUTERIZED SYSTEM PRODUCT LIFE CYCLE... 12

2.1.1

GAMP 5 - Product Life Cycle phases ... 12

2.1.2

GAMP 5 – General approach with Project Stages and Supporting Procedures . 13

2.2

THEMA4 PRODUCT LIFE CYCLE ... 14

2.2.1 Thema4:

current

Life Cycle phase... 14

2.2.2

Thema4 Life Cycle defined following GAMP 4 model... 15

2.2.3

Thema4 Life Cycle in GAMP 5 approach ... 16

2.2.4

Thema4: software and hardware GAMP 5 category... 16

2.2.5 Thema4

CONCEPTION phase... 17

2.2.6 Thema4

PROJECT phase ... 18

2.2.7 Thema4

OPERATION phase ... 21

2.3

Thema4 key operation procedures ... 22

2.3.1 Handover ... 23

2.3.2

Service Management and Performance Management ... 23

2.3.3 Incident

Management and CAPA ... 23

2.3.4 Change

Management Process ... 24

2.3.5 Repair

Activity... 29

2.3.6

Periodic Review (Internal Quality Audits) ... 29

2.3.7 Continuity Management... 29

2.3.8

Security and System Administration ... 30

2.3.9 Record

Management ... 31

3

APPENDIX

... 32

3.1

REFERENCES ... 33

3.2

THEMA4 PROCEDURES... 33

TABLES

Table 1 - Fedegari department involved in Thema4 management Table 2 - Thema4 life cycle vs. GAMP 5 life cycle

Table 3 - Thema4 GAMP 5 categorization

Table 4 - Documents released in the Conception phase of Thema4 life cycle Table 5 - Documents released in the Project phase of Thema4 life cycle

Table 6 - Thema4 main operational procedures vs. GAMP 5 key supporting procedures Table 7 - CR/FR PROCESS stages

Table 8 - Thema4 Change Activities Plan phases vs. GAMP 5 Project stages

FIGURES

Figure 1: GAMP 5 Key Concepts Figure 2: GAMP 5 Product life cycle Figure 3: GAMP 5 Project Stages

Figure 4: GAMP 5 Project Stages and Supporting Processes during the Life Cycle Figure 5: Scheme of general Product Life Cycle

Figure 6: Thema4 Life Cycle diagram in GAMP 4 approach Figure 7: Thema4 application of GAMP 4 V-shaped diagram

Figure 8: GAMP 5 Project stages approach for Custom Application (Category 5) Figure 9: Thema4 CR/FR PROCESS - Workflow

Figure 10: Thema4 CH PROCESS - Workflow

Section 1

THEMA4 CONTROL SYSTEM

1 GXP REGULATED COMPUTERIZED

SYSTEM

1.2 - THE PRODUCTION OF PHARMACEUTICAL

AND MEDICAL DEVICES

1.3 - THE GUIDE LINE GAMP®

1.3.1 - GAMP® 4

1.2 THE PRODUCTION OF PHARMACEUTICAL AND MEDICAL DEVICES

The production of pharmaceuticals or medical devices is governed by specific manufacturing

standards

[1-5], which tend to establish tests meant to ensure a certain qualitative level of the

product and define a working method known as Good Manufacturing Practice (GMP).

These rules and standards form a consistent system, meant to keep under control the entire

production and distribution process so as to trace any anomalies, their causes and, in the

worst cases, recall the product from the market.

Among the requirements expressed by GMP, validation of the production process (achieved

through validation of its individual steps) allows to achieve, with a certain margin of safety,

reproducibility of the process and of the qualitative parameters that characterize the product.

In the traditional approach, this cannot be done without validating the machines and the

systems used in the various steps of production.

GMP and other reference standards, however, give generic recommendations, since their

validity is independent of the type of production to which they apply.

1.3 THE GUIDE LINE GAMP®

Since the 1980s, various regulatory bodies and technical organizations have issued

guidelines regarding automatic systems used in the production and control of pharmaceuticals

and medical devices.

However, in those years the attention of control bodies was focused on different problems,

and the interpretation of the guidelines revealed less awareness than in other aspects of

pharmaceutical production.

The need for a shared approach regarding the methods for developing and managing an

automatic system in the pharmaceutical field and medical devices (of which the automatic

system can be an integral part or be a device in itself) led to the establishment of a study

group known as GAMP (Good Automated Manufacturing Practice) Forum, which by

transferring the principles of GMP focused its attention on the automatic systems used in

these two particular fields.

1.3.1 GAMP® 4

In December 2001, the GAMP Forum, by then evolved into a committee within the ISPE

(International Society of Pharmaceutical Engineering), issued the fourth edition of the

guideline for validation of automatic systems

, GAMP® 4 [6].

The GAMP 4 approach identifies not only a way of understanding the validation of an

automatic system but also a way of developing and controlling the entire life cycle of the

system. In other words, one might say that validation is an activity that begins with the

planning phase and accompanies the system development phases up to release, including

any changes and finally decommissioning.

This type of approach allows to keep the project and the product under control during the

various phases that characterize its life cycle, helping to ensure ever better performance and

reliability and therefore higher margins of assurance for the end user.

Validation activity, understood as the documented verification that the requirements of the

system have been achieved according to a stated method, if performed judiciously, is

extremely helpful not only for the customer but also for the developer of the system.

1.3.2 GAMP® 5

In this last years, pharmaceutical and biopharmaceutical industry is facing the challenge of a

significantly improving in the way the drugs are developed and manufactured.

New concepts and ways of working, based on “science based risk management”, “product

and process understanding” and “Quality by Design” are being defined in several documents

(FDA 21st Century Initiative; ISPES’s PQLI; CH Q8, Q9, Q10; ASTM E2500 [7]) and the

industry is in a transition period in which this new ideas are being established.

To meet the needs and the initiatives of this changing environment, in February 2008, ISPE

has released the GAMP® 5 - A Risk-Based Approach to Compliant GxP Computerized

Systems [8], to provides a pragmatic and practical guidance to achieve compliant GxP

regulated computerized systems, fit for intended use in a more efficient and effective manner.

The purpose of GAMP 5 is to provide a cost effective framework of good practice that aims to

ensure that computerized systems are fit for intended use and compliant with applicable

regulations. The guide aims to address the need of safeguard patient safety, product quality

and data integrity while at the same time enabling innovation and technological advance, to

deliver business benefit.

This new approach points to the future of computer systems compliance, centered on a

flexible risk-based approach, based on scalable specification and verification and focused on

5 key concepts:

1. Product and Process understanding

2. Life cycle Approach within a QMS

3. Scalable Life Cycle activities

4. Science Based Quality Risk Management

5. Leveraging supplier involvement

That concern both user (pharmaceutical company) and supplier of computerized systems and

services, in the way showed in the following GAMP 5 scheme:

1.3.2.1.1 The adoption of new and innovative approaches GAMP 5

As stated in the guide, GAMP is not a standard or a rule but it is a guide line and so it is

inappropriate to speak of “GAMP 5 certification or compliance”. It is more proper to speak of

“adoption of GAMP 5 approach” in the computerized system life cycle.

1.3.2.1.2 .. to do the job today, while building a bridge to new approaches

For that systems arrived in their “operational life”, GAMP 5 approach can implemented

gradually and by means a sequence of partial changes, where the new approach coexists

with the previous good practices.

“GAMP documents are guide and not standards. It is the responsibility of regulated companies to establish policies and procedure to meet applicable regulatory requirements. Consequently, it is inappropriate for suppliers or products to claim that are GAMP certified, approved or compliant.“ (GAMP 5 - 1.3 Purpose)

“These innovative approach are available and useable now if the appropriate pre-requisites are met. While acknowledging that not all regulated companies will be in a position to, or will choose to, fully embrace the new approaches immediately, this Guide is intended to encourage the adoption of such approaches and in no way to be a barrier.

Improving Quality Practice

During the period of transition, the industry continues to need practical guidance based on current good practice giving practitioners the tools to do the job today, while building a bridge to new approaches. This Guide aims to describe current good practice in order to satisfy the needs of the majority of practitioners involved with computerized systems, while also enabling new and innovative approaches, e.g. for process systems in a Quality by Design environment.” (GAMP 5 -Foreword)

Section 2

THEMA4 CONTROL SYSTEM

2

THEMA4 LIFE CYCLE

2.1 - COMPUTERIZED SYSTEM PRODUCT LIFE

CYCLE

2.1.1 - GAMP 5 - Product Life Cycle phases

2.1.2 - GAMP 5 – General approach with Project

Stages and Supporting Procedures

2.2 - THEMA4 PRODUCT LIFE CYCLE

2.2.1 - Thema4: current Life Cycle phase

2.2.2 - Thema4 Life Cycle defined following GAMP 4

model

2.2.3 - Thema4 Life Cycle in GAMP 5 approach

2.2.4 - Thema4: software and hardware GAMP 5

category

2.2.5 - Thema4 CONCEPTION phase

2.2.6 - Thema4 PROJECT phase

2.2.6.1 - Testing & Validation

2.2.6.2 - Risk analysis conducted in Project phase

2.2.7 - Thema4 OPERATION phase

2.3- THEMA4 KEY OPERATION PROCEDURES

2.3.1 - Handover

2.3.2- Service Management and Performance

Management

2.3.3- Thema4 Life Cycle in GAMP 5 approach

2.3.4- Change Management Process

2.3.4.1 - Thema4 – Change Activities Plan: workflow 2.3.4.2 - Relation between Thema4 Change Activity Plan

and the Project approach of GAMP 5

2.3.4.3 - Delivery procedure of a Thema4 “Configuration” on NF

2.3.4.4 - Thema4 software licensing

2.3.5- Repair Activity

2.3.6- Periodic Review (Internal Quality Audits)

2.3.7- Continuity Management

2.3.8 - Security and System Administration

2.3.9 - Record Management

2.1 COMPUTERIZED SYSTEM PRODUCT LIFE CYCLE

2.1.1 GAMP 5 - Product Life Cycle phases

In order to achieved computerized systems compliance with regulatory requirements and

fitness for intended use, the guideline GAMP 5 (keeping on the GAMP 4 concepts) promotes

the adoption of a life cycle approach, where all activities, from initial conception to system

retirement, are defined and performed in a systematic way, following good practices.

As showed in this GAMP 5 scheme, Product Life Cycle of a computerized system consists in

four main phases: from Concept phase (to understand and define requirements), through

Project phase (with system specification, development, testing and release of the system for

production) and the next longest phase of Operation (with the safeguard of the validate state

of the system, while it is subject to continuous changes and upgrades), to the final

Retirement.

GAMP 5 encourages the involvement of the supplier in many activities of the computerized

system life cycle, to avoid waste of efforts and duplication of tasks.

This approach requires a periodical satisfactory supplier assessments but allows end user to

use knowledge, experience, documentation and services of the supplier and to benefit from

innovation, technological advance and periodical system upgrades.

2.1.2 GAMP 5 – General approach with Project Stages and Supporting

Procedures

As already introduced by means of the GAMP 4 V-model, to achieve compliance and fitness

for intended use, GAMP 5 proposes a general approach to Project phase, based on a

sequence of project stages, that entail multiple activities:

• Planning

of activities,

responsibilities, procedures

and timelines.

• Specification & Verification,

where specification activities

are addressed by appropriate

verification and review steps,

to determine whether the

specification has been met.

The hierarchy of specification

and testing, is depending on

the system complexity, risk

level and novelty.

• Configuration and Coding, by

configuration activities on

market components and

coding of software

components, supported by a

configuration and change control management.

• Reporting and release, where controlled and documented processes assure the

acceptance and release of the system, for the use in GxP regulated activity.

These project stages are integrated with key supporting processes of Risk management,

Change and Configuration Management, Design Review, Traceability and Document

management,..

Project stages and supporting processes are part of the computerized system Life Cycle and

equally applicable to the Project phase and to change activities of Operation Phase.

Figure 3: GAMP 5 Project Stages

2.2 THEMA4 PRODUCT LIFE CYCLE

2.2.1 Thema4: current Life Cycle phase

Thema4 has been developed following the guideline GAMP 4, from the initial

Conception and Project phases up to the current Operational phase.

Now Thema4 is in the “maturity” of its Operational phase and it has adopted the

reference guideline GAMP 5.

This adoption has not meant a “complete

change” of the quality approach of Thema4,

for three reasons:

1. GAMP 5 is not a complete “twisting” of

GAMP 4 philosophy, but rather its

“completion”, by the acquisition of new

needs and concepts (“science based

risk management”, “product and

process understanding” and “Quality by

Design”) of pharmaceutical industry

(see note above).

2. Thema4 life cycle already implements a

robust approach (by defined procedures

and documentation) based on the main

concepts, present in guidelines GAMP 4,

and fully valid in GAMP 5.

3.

Thanks to Thema4 continue

improvements, suggested from the frequent customers audits and the constant

attention to new GMP regulations, several new aspects pointed out in GAMP5 can

be considered already present (at least at an initial stage) in Thema4 Life Cycle and

they will be enforced in the next developments.

Moreover, for several aspects, it is possible to state that GAMP 5 life cycle framework

is more fitted to describe and to manage the system architecture of Thema4 and the

full implementation of GAMP 5 concepts (as Life Cycle scalability, Risk Management

approach, integrated QbD), will allow big improvements and advantages for both

Supplier and User of Thema4.

“Computerized System Validation Framework

Traditionally GAMP has advocated a computerized system validation framework to achieve and maintain GxP compliance throughout the computerized system life cycle.

This framework is based on system specific validation plans and reports and the application of appropriate operational controls. Validation plans and reports provide a disciplined and consistent approach to meeting regulatory requirements, leading to appropriate documentation at the right level. Such documents are valuableboth in preparing for, and during, regulatory inspections.

This framework is still applicable for the majority of the computerized systems. This Guide has built on these principles by clarifying the scalability of the approach, and the central role of Quality Risk Management, to effectively and efficiently cover the very wide range of system in scope.

(GAMP 5 – 3Life Cycle Approach))

Product/System Life Cycle

Figure 5: Scheme of a general Product Life

2.2.2 Thema4 Life Cycle defined following GAMP 4 model

Thema4 project development and management methodology, has been described in the

document “Thema4 - Quality and Project Plan” [9], which defines the main phases of the

project, giving them the characteristic features of the approach GAMP 4 –Life Cycle Model

According to the diagram shown in figure below, five different phases can be identified during

the development project of Thema4,

The documentation of each phase is tightly linked to the preceding phase and the following

phase and also to the corresponding transverse phase of the V-shaped diagram.

the organization department, to which they are entrusted, in accordance with the acronyms

defined in the table below:

Department Function

DIG General Management

QUA Quality Assurance

SSE Electronic Systems Development

RES Research and Development

Table 1 - Fedegari department involved in Thema4 management

2.2.3 Thema4 Life Cycle in GAMP 5 approach

The phases of Thema4 Life Cycle, have encompassed the first 3 stages, Concept, Project

and Operation, of the corresponding GAMP 5 Product Life Cycle:

GAMP 5 – PRODUCT LIFE CYCLE

Thema4 Life Cycle

CONCEPTION PROJECT OPERATION RETIREMEN T

1 Planning and specification X X

2 Design and construction X

3 Installation and testing X

4 Acceptance final testing X

5 Release & ongoing maintenance

operations X

Table 2 - Thema4 life cycle vs. GAMP 5 life cycle

The management of these three phases during Thema4 Life Cycle has been summarized in

the following paragraphs.

2.2.4 Thema4: software and hardware GAMP 5 category

Supplier and user approach to the system management, depends on the GAMP

categorization of the computerized system.

Based on the system categorization defined in GAMP 5 – Appendix M4 Categories of

Software and Hardware (that is similar to the previous one of guide GAMP 4), Thema4 is

classified as:

GAMP 5 CATEGORY

Thema4 control system

Supplier End User

1 Thema4 Software

Category 5

Custom (bespoke)system

(because it requires software development

and HW configuration to meet defined requirements)

Category 4

Configurable system

(because it require only system configuration by user interface)

2 Thema4 Hardware

Hardware Category 1

Standard Hardware

components

Hardware Category 1

Standard Hardware

components

Table 3 - Thema4 GAMP 5 categorization

2.2.5 Thema4 CONCEPTION phase

The life cycle of the Thema4 controller began formally in November 2001, when Fedegari

management defined the need to develop for its own dry and moist heat sterilizers a new

control system more aligned with new market requirements and the established and

acknowledged technological level, taking however into account that despite the obsolescence

that is typical of information technology products, the previous Thema3 controller has been

able to ensure for a decade a reliability and management of the sterilization processes,

contributing (together with the autoclave section) to the consolidation of the Fedegari brand

worldwide.

The initial base requirements of this new control system, after the understanding of business

needs and benefits and the evaluation of scope, cost and potential solutions, were:

-

a PC-based system including all the functionalities (previously distributed in several

systems);

-

new HW/SW architecture with use of commercial hardware of the main brands;

-

use a Real Time Operative System leader of the market;

-

modern, graphical, multi-language and touch screen interface, portable on different

platforms;

-

adoption of GAMP 4 approach in the product Life Cycle;

-

native compliance with pharmaceutical standard 21 CFR Part 11;

-

preserve the standard, flexible and configurable approach of the previous system in the

management of processes, I/Os configuration, functions enablement and alarms;

-

use the same computerized system (with same software), to equip all types of

pharmaceutical machines;

-

system completely open to all requests of integration of pharmaceutical plants:

-

complete control of the source code in house, not accessible to users, in order to

preserve company know how and system integrity for users;

-

control system development and released fully integrated in the company production

system;

These requirements has been stated in a document of Fedegari Management “Order of

Service”, that assigned the responsibility of Thema4 project to the manager of SSE

department.

In this Conception phase, composed of planning and specification stages, with definition of

life cycle approach and activities, responsibilities, procedures and timelines, the following

basic documents has been released:

Thema4 – Documents released in the Conception phase

Code Document

OdS ORDER OF SERVICE FROM DIG FOR THE DEVELOPMENT OF A NEW GENERATION OF

PROCESS CONTROLLER, FOR MACHINES AND PLANTS

VP THEMA4 - GENERAL VALIDATION PLAN

QPP THEMA4 - QUALITY PROJECT PLAN

URS THEMA4 - USERS’ REQUIREMENTS SPECIFICATIONS

SS SYSTEM (PROPOSAL) SPECIFICATION

QA QUALITY ASSESSMENT

2.2.6 Thema4 PROJECT phase

After the quality assessment and the definition of the preliminary requirements, Thema4 Life

Cycle passed from the Conception phase to the Project phase, consisting of the sequence of

stages of the GAMP 4 V-Model (for Custom system – Category 5). This phase has lasted a

couple of years, with the final acceptance and release of the system on the market for the

Operational phase, in 2004.

Each of these stages has associated support documents: starting from the Functional

Specification document (based on the User Requirements), it is possible to trace the path that

led to the definition of the functional characteristics of the controller, to their implementation

and to subsequent verification, following what is known as the characteristic V-shaped

diagram of GAMP.

The indication of management regarding the technical and performance characteristics of the

new controller are described in Thema4 Functional Specification [10] derived from detailed

specification documents.

From the point of view of the sterilization process management, the new controller has

acquired the entire know-how developed by Fedegari in the systems of the previous

generations.

Development of the requirements is followed by means of the documents described in Figure

of V-diagram, reaching the highest level of detail for writing the code, in the first branch of the

“V”, which corresponds to the design and construction phase.

User Requirement Specifications Functional Specification Hardware Design Specif. Software Design Specification Software Module Specification Code modules Software Module Testing Software Integration Test. Hardware Acceptance Test. System Acceptance Test. DIG

Specification Testing

SSE SSE SSE SSE SSE SSE SSE RES SSE

During Project phase, the following basic documents have been released:

Thema4 – Documents released in the Project phase

Code Document

SP FUNCTIONAL SPECIFICATION

SDTM SOFTWARE DESIGN TRACEABILITY MATRIX

HWDS HARDWARE DESIGN SPECIFICATION

SWDS SOFTWARE DESIGN SPECIFICATION

SWMDS SOFTWARE MODULE DESIGN SPECIFICATION

SWMTS/R SOFTWARE MODULE TEST SPECIFICATIONAND RESULTS

HAT HARTDWARE ACCEPTANCE TEST

CM CONFIGURATION MANUAL

CC CHANGE CONTROL MANUAL

Table 5 - Documents released in the Project phase of Thema4 life cycle

From the point of view of GAMP 5, the steps of V-Model can be grouped in stages of the

general approach: Planning (with suppliers assessment and selection), Specification

(Functional design, HW and SW design, Detailed software design), Coding & Configuration

(for SW and HW components), Verification (SW module testing, Integration testing, HW

acceptance test, System acceptance testing).

As is possible to see from figure below, the V-diagram application on Thema4 project

phase is very similar to GAMP 5 - Project stages approach for Custom Application.

2.2.6.1 Testing & Validation

The Testing stage covers the entire Specification, providing tests on the individual software

modules, tests on the mutual integration of these modules and, rising along the branch of the

“V” of the GAMP life cycle, the final acceptance tests (Validation tests).

The final acceptance tests have been devised by personnel not involved in

development activity, in order to check independently that the original requirements

have been implemented.

During the Coding, review of the source code of the individual modules was performed by

individuals not involved in the creation of the module, so as to separate the writing and control

procedures.

As defined by GAMP guide (and shown in V-shaped diagram), the specification documents,

that correspond to each testing level have been used to define the tests plans and protocols,

so as to outline the methods of execution and define the acceptance criteria for verifying that

the requirements are met.

It is therefore possible to have a complete traceability in detail: given a requirement, its

embodiment in the functions and software modules that compose it, and the associated

verification tests.

A critical approach, based on risk analysis of the functions of the process controller, has been

used for the final validation that corresponds to the System acceptance tests: risk

management is applied to identify risk and to remove or reduce them to an acceptable level.

2.2.6.2 Risk analysis conducted in Project phase

GAMP 4 suggests performing an assessment of the risks linked to the development and

release of an automatic system in view of the fact that no matter how extensive and complex

the testing phase of a system, it is highly unlikely that it is possible to reproduce all possible

operating conditions. It is far more convenient, both for assurance in use and for efforts

related to validation, to focus verification activities on the functions that are most critical due to

their field of application and to the problems associated with the field.

It is evident that this approach (like the falsely exhaustive one) includes a residual risk margin

at the end of the testing process. However, differently from the approach that does not include

assessment of the risks linked to the use of the system, in this case the residual risk is highly

correlated to the less critical functions of the system. Moreover, this risk is managed by the

activities that take place after release of the system, i.e., anomaly management and change

control.

As regards, in the Functional Testing (System Acceptance Testing) stage of Project phase,

Thema4 risk analysis was conducted on the functions of the controller, evaluating their impact

on the following risk criteria:

a) Operator safety

b) Sterilization process

c) GMP

d) Electronic data management

e) Legal and business-related aspects

As a result of this assessment, validation activity has been organized according to the

criticality connected to each function; the functions of the controller related to the same risk

category have been verified together.

Because of the differences between the moist and dry heat sterilizers, from the process and

functionalities points of view, the content of the risk analysis was referred to the two different

kind of sterilizers by means of two document of “Risk analysis – Methodology” [11] [12].

2.2.7 Thema4 OPERATION phase

In January 2004, with the final acceptance and formal release for use at the Project phase

end, Thema4 started its Operation phase with the first installation on users machines, for the

FAT activities and the following SAT (IQ, OQ and PQ).

This phase of operational life is the longest in Thema4 Life Cycle (with a duration

foreseen of 8-10 years) and it is still in progress.

The main aim of this phase is to maintain compliance and fitness for intended use throughout

the computerized system operational life, facing all necessary changes of:

-

system functions (to meet market requirements and expectations)

-

business process (to improve their efficiency and effectiveness)

-

software and hardware components (due to components obsolescence)

-

regulatory requirements

-

personnel involved in maintenance and development team

This has been possible, thanks to the adoption of fitness and documented procedures,

training activities and periodical reviews, covering use, management and maintenance.

This procedures have allowed the implementation of a continuous repetition of product

changes and release activities, by means of “Project stages” integrated with “key

supporting processes” (as defined in GAMP 5 Life cycle), and then to maintain the

control system updated with technological advance, fitness for intended use and

compliance with GxP regulations.

2.3 Thema4 key operation procedures

The main procedures adopted and periodically updated, for the implementation of the key

supporting operational processes, as defined in GAMP 5 approach of Grouping

Operational Processes, are listed in the table below:

GAMP 5

Key Supporting Processes

Thema4

Main operational procedure

Group of

processes

Process

CUSTOMER SOFTWARE SUPPORT – CASE ID MANAGEMENT PROCEDURE CHANGE CONTROL PROCEDURE FOR PRO

C

ESS CO

NTRO

LLERS

PROCEDURE FOR CHOICE, ISSUE INSTALLATION OF APPLICATION SOFTWARE FO

R STERILIZER SETUP

POLICIES AND PROCEDURES THEMA4 SW LICENSES SCHEDULING, EXECUTION AND MANAGEMENT OF INTERNAL AUDIT METHODS OF MANAGEMENT AND CONTROL OF CORRECTIVE ACTION AND PREVENTIVE ACTION THEMA4 SOFTWARE PROGRAMS ARCHIVING PROCEDURE SAVING, CONTROL, ARCHIVING AND RECO

VERY O

F

ELECTRO

N

IC DATA

GENERATION OF “THEMA4 SW BACKUP” FOR NF ACCESS ASSIG

N

EMENT IN SSE

DEPARTEMENT ENTRANCE, CIRCULATION AND EXIT OF PERSO

NNEL INSIDE FEDEG

ARI PREMISES

HOLD IN CHECK OF THE QUALITY RECORS

PAQ 160175 PAQ 27961 PAQ 113262 PP 109735 PSQ 03 PAQ 05 PR 115239 PAQ 0503 PR 113317 PR 109804 PSQ 09 PSQ 02

Reviewed in GAMP 5 Reviewed in GAMP 5 Reviewed in GAMP 5

Handover • Handover Process

- - - - - - - - - - -

Service Management and Performance Monitoring • Support Services • Performance Monitoring

X

Incident Management and CAPA • Incident Management • CAPA

X

• Change Management • Configuration Management

X X X

Change Management • Repair Activity

X

Audits and Review • Periodic Review (Internal Quality Audits)

X

X

Continuity Management

• Backup and Restore • Business Continuity Planning • Disaster Recovery Planning

X

X

X

Security and System Administration • Security Management • System Administration

X

X

Record Management • Retention