GAMP 4

GAMP 4 Guide
Quick Reference
Good Automated Manufacturing Practice (GAMP) è una normativa di validazione messa a punto
dal GAMP Forum, un sottocomitato tecnico di ISPE (International Society of Pharmaceutical
Engineering). E' 4 perché è la quarta versione (emessa nel 2001) di un documento il cui primo draft
fu emesso nel 1994 per la industria UK. Tiene conto di raccomandazioni europee e nord-americane.
E' conforme a GxP: GMP (Good Manufacturing Practice), GCP (Good Clinical Practice), GLP
(Good Laboratory Practice), GDP (Good Distribution Practice).
Non è una normativa adatta per la validazione retrospettiva di sistemi esistenti. E' applicabile ad un
ampio spettro di sistemi (PCS (Process Control Systems) e IT Systems).
E' parte della GAMP Guidance, che include la GAMP Guide, Good Practice Guides (da emettere) e
Training Materials (materiale formativo della ISPE).
Si compone di un corpo centrale (concettuale) e di Appendici su temi specifici:
• Gestionali
• Di sviluppo
• Operative.
Nel 2000 è stato costituito un GAMP America, che compendia il Forum europeo.
La validazione di una nuova struttura deve seguire una struttura sequenziale:
1. Edifici e servizi principali
2. Apparati e sistemi automatizzati
3. Processi e normative igeniche.
La validazione può essere vista come ripartita in 3 aree fondamentali:
• IQ installation qualification: corretta installazione dei sistemi,
• OQ operational qualification: corretta (vs. specifiche) funzionalità,
• PQ performance qualification: corrette (vs. specifiche) prestazioni,
• DQ design qualification: rispondenza del progetto (documentazione) agli
obiettivi.
Schema delle attività di validazione:
Attività di validazione
Planning
Specification
Test planning (IQ,OQ,PQ)
Testing (IQ,OQ,PQ)
Review e Report
Prepara un piano di validazione scritto
Specifica i design review di progetto e di realizzazione del sistema
Preparazione della documentazione che descrive i test
Esegue i test e raccoglie i risultati
Revisione della documentazione per mostrare che il sistema è
conforme alle specifiche
E' essenziale per implementare le attività di validazione mantenere documenti di Specifica ben
aggiornati (questo è un requisito GxP).
Lo schema di corrispondenza fra specificazione e qualificazione è quello classico a V:
Specifica
URS User Requirements Spec.
FS Functional Spec.
DS Design Spec:
Realizzazione
Validazione
PQ verifica URS
OQ verifica FS e DS
IQ verifica DS
Sviluppo del sistema
Più specificamente si ha la seguente corrispondenza:
Attività di sviluppo
URS
FS (incluse le specifiche meccaniche ed
elettriche per i sistemi embedded)
Hw DS, Sw DS, Sw module DS, Mechanical
and electrical Specs, Network DS, Package
Configuration Specs
Realizzazione e assemblaggio Hw, Codifica
Sw, Realizzazione e assemblaggio apparati
(sistemi embedded), Realizzazione e
assemblaggio della rete
Hw test, Sw module test, Sw integration test,
Equipment tes (sistemi embedded), Package
configuration test
Hw inst., Sw inst., inst. apparati (sistemi
embedded), inst. rete
Hw acceptance testing
Network acceptance testing
System Acceptance testing
Maintenance
Change Control
Fase
Attività di validazione
Planning & Specification Validation Plan,
Supplier Assesments,
Design Reviews
Design
Design Reviews
Construction
Testing
Installation
Acceptance testing
Operation
Construction
Reviews//Code Reviews
Monitor supplier (NB)
Installation qualification
Operational Qual.,
Performance Qual.,
Validation Report
Validation Report,
Manutenzione dello
stato di validazione
NB: test eseguiti presso il fornitore, se adeguatamente controllati e documentati, possono essere
parte integrante di OQ e PQ, allo scopo di semplificarne la complessità.
Vanno considerate le cose seguenti:
•
•
IT Systems
Il PQ va eseguito con dati realistici (rispondenti all'uso quotidiano). Dovrà esistere un piano di
qualità per qualificare la infrastruttura informatica che ospita l'applicazione validata.
Process Control Systems
E' importante che aspetti meccanici, elettrici e sw vengano qualificati insieme (in assetto
integrato) durante la OQ.
Per mantenere lo stato di validazione del sistema sono essenziali:
•
•
•
Piani operativi e procedure
Addestramento
Gestione e risoluzione problemi
•
•
•
•
•
•
•
•
•
•
•
Contratti di manutenzione e servizio
System Management
Back-up e Recovery
Configuration Management
Controllo dei cambiamenti operativi
Gestione sicurezza
Monitoring delle prestazioni
Mantenimento, archiviazione e recupero delle registrazioni rilevanti per la qualità
Piano di Business Continuity
Review periodiche e valutazioni
Sostituzione sistemi
1 Ciclo di vita della validazione
E' essenziale la cooperazione utente-fornitore. E' essenziale che il fornitore usi un sistema di
gestione formale per controllare e documentare il processo di sviluppo.
La responsabilità della validazione è dell'utente, sebbene il fornitore sia ampiamente coinvolto nel
processo. L'utente deve avere quindi una policy per coprire le seguenti problematiche che sono a
suo carico:
1. Identificazione dei sistemi
2. Produzione del USR
3. Definizione della strategia di validazione con:
Assessment dei rischi
Assessment dei componenti del sistema (con loro categorizzazione)
Assessment del fornitore (può portare all'Audit del fornitore)
4. Produrre un Validation Plan
5. Revisionare e approvare le Specifiche, inclusa la System description
6. Fare il monitoring dello sviluppo del sistema
7. Review del codice sorgente (deve garantire che questa attività sia svolta)
8. Review e approvazione delle Test Specs
9. Eseguire il test (il coinvolgimento può essere come testimone del test o come auditor dei
risultati)
10. Review ed approvazione dei risultati dei test
11. Produzione del Validation Report
12. Mantenimento del sistema con appropriate procedure operative e di gestione
13. Ritiro del sistema
Per la identificazione dei sistemi dovrà come minimo essere gestita una lista di quelli rilevanti ai
fini GxP.
Gli URS debbono essere scritti dall'utente, che può delegare, ma deve mantenere almeno il
reviewing e la approvazione (vedi Appendice D1).
Per la determinazione della strategia di validazione, sono essenziali i seguenti passi:
• Risk Assessment: identificazione dei sistemi e dei processi critici per il prodotto e/o il paziente
e/o il business; la validazione va indirizzata verso le aree critiche (vedi Appendice M3).
• Assessment of System Components: categorizzazione dei componenti per determinare il livello
di validazione richiesto (vedi Appendice M4).
• Supplier Assessment: (vedi Appendice M2).
Devono esistere un Validation Plan, redatto dall'utente, e un Quality & Project Plan, concordato fra
utente e fornitore, basato sul precedente.
Il Validation Plan deve essere prodotto per tutti i sistemi regolati da GxP. Esso definisce:
• Ruoli e responsabilità
• Struttura organizzativa
• Assessment delle criticità GxP
• Strategia di validazione (tenendo conto del risk assessment)
• Deliverables della validazione
• Criteri di accettazione
• Controllo delle modifiche
• Procedure Operative Standard
• Gestione della documentazione
• Mantenimento dello stato di validazione (vedi Appendice M1).
Alla fine della validazione l'utente deve produrre un Validation Report (vedi Appendice M7).
Il Quality & Project Plan deve essere concordato col fornitore, deve soddisfare gli indirizzi del
Validation Plan e deve deve definire in particolare il ruolo dell'utente nelle attività di quality
assurance (vedi Appendice M6).
Per le specifiche di sistema esistono le seguenti direttive:
• Functional Specs (vedi Appendice D2),
• Hardware Design Specs (vedi Appendice D3),
• Software Design e Software Module Design Specs (vedi Appendice D4).
Secondo l'Annex 11 del GMP deve esistere una system description che descrive per ogni sistema
principi, obiettivi, misure di sicurezza, caratteristiche principali, interfacce verso altri sistemi e
procedure: se queste informazioni sono incluse nelle Functional Specs, non è necessario produrre un
documento separato.
Lo sviluppo del software deve essere inquadrato dal fornitore in un quality management system atto
a sviluppare e configurare il software in accordo ai requisiti. L'utente deve controllare il fornitore
per quel che concerne: metodi e strumenti, politiche e procedure, regole di programmazione, metodi
di review, testing e verifica, sicurezza e confidenzialità. L'utente deve anche verificare che il codice
sorgente subisca reviewing formale (vedi Appendice D5).
Le Test Specs devono essere prodotte per le seguenti attività:
• Software module test
• Software integration test
• Hardware acceptance test
• System acceptance test.
Le direttive per test specs e documentazione dei risultati sono definite in Appendice D6.
Per il mantenimento dello stato di validazione l'utente deve predisporre e mantenere procedure e
piani per i seguenti aspetti.
1. Definizione di procedure operative per l'uso e la gestione del sistema. Esse debbono essere
definite prima della messa in servizio.
2. Training per utenti e staff di supporto.
3. Politica per la gestione e risoluzione di problemi: come catturarli, valutarli, priorizzarli,
controllarne l'evoluzione, scalarli e chiuderli.
4. Definizione dei contratti di assistenza e manutenzione (vedi Appendice O2).
5. Definizione di temi di system management come l'amministrazione, l'uso di tool, i test e le
calibrazioni di routine, la gestione di parti di ricambio e materiale di consumo.
6. Debbono essere stabilite procedure di back-up e recovery (vedi Appendice O7).
7. Debbono essere stabilite procedure di gestione della configurazione (vedi Appendice M9).
8. Debbono essere stabilite procedure di gestione delle modifiche (vedi Appendice O4).
9. Debbono essere stabilite procedure di security management (vedi Appendice O3).
10. Esistono sistemi che potrebbero perdere la missione a fronte di degradi prestazionali, essi
debbono essere posti sotto performance monitor periodico (vedi Appendice O5).
11. Debbono essere stabilite procedure per la gestione delle registrazioni relative alla qualità (vedi
Appendice O6).
12. Debbono essere stabilite procedure per la continuità di esercizio: disaster recovery e
rigenerazione del software e dei dati del sistema (vedi Appendice O8).
13. Debbono essere stabilite procedure per la revisione periodica del sistema e del mantenimento
dello stato di validazione (vedi Appendice O1).
14. Debbono essere stabilite procedure per il decommissioning dei sistemi che tengano conto del
fatto che essi gestiscono dati rilevanti per le GxP (per la gestione dati vedi Appendice O6).
Schema riassuntivo della principale documentazione da produrre durante il progetto:
Documento
User Requirement Specification
Validation Plan
Quality & Project Plan
Functional Specification
Hw Design Specification
Sw Design Specification
Test Specification
Validation Report
Responsabilità
U (utente)
U
E (entrambi)
F (fornitore)
F
F
F
U
Appendice
D1
M1
M6
D2
D3
D4
D6
M7
2 Sistema di gestione per fornitori di IT Systems
E' raccomandato che il fornitore segua un sistema formale di gestione, preferibilmente basato su
ISO 9000. Questa parte si applica ai sistemi IT, i MES sono considerati tali, sebbene siano sull'area
di confine con i sistemi di controllo processi.
Oggi si impiegano sovente package commerciali per applicazioni IT; in questo caso la
documentazione del prodotto deve essere usata intensamente per la validazione del sistema.
Di seguito è riportato il ciclo di vita generico. Non tutti i sistemi richiedono tutta la documentazione
elencata (il Quality and Project Plan deve identificare la documentazione richiesta). Il ciclo di vita
deve evolvere in modo sequenziale (i deliverable debbono essere approvati in ordine logico). Ad
esempio mentre il progetto può iniziare prima che URS e FS siano finite, il progetto completo non
può ovviamente essere approvato prima di URS e FS. La tracciabilità deve essere mantenuta
durante l'elaborazione dei documenti. Il planning può richiedere un risk assessment (vedi
Appendice M3).
Il prototyping è consentito come strumento per chiarire i requisiti di utente e per valutare le aree di
rischio. Deve però essere eseguito un rigoroso controllo di versioni: prototipo e software finale
debbono essere segregati.
Planning and Specification
SAMP??? (1)
Validation Plan (M1)
User Requirement Specification (D1)
Supplier Assessment (M2)
Quality and project plan (M6 + M3/M4)
Functional Specification (D2)
System Acceptance test Specification (D6)
Design and Construction
Hardware Design
Specification (D3)
Hardware
Acceptance Test
Specification
(D6)
Hardware Production
Software Design
Specification (D4)
Software
Integration Test
Specification (D6)
Software Module Software Module
Design
Test Specification
Specification (D4)
(D6)
Software Production (D5)
Package
Configuration
Specification
Package
Configuration
Test Specification
(D6????)
Configure Package
Installation and Testing
Hardware Acceptance Test results
(M7)
Verify Configuration (M7???)
Software Module Testing and
Results (M7)
Software integration Testing and Results (M/7) (2)
Acceptance testing
System Acceptance Tesing and Results (M7)
Operation (mantaining the validated state)
Change Control (M8)
Maintenance (O2)
Note: (1) In verde le attività a completo carico dell'utente
(2) In alcuni sistemi l'integration testing non è necessario
L'adozione di software package standard può richiedere una significativa reingegnerizzazione dei
processi, in questo caso i processi debbono essere rivalidati.
Il Quality and Project Plan è un documento contrattuale e quindi deve essere approvato sia
dall'utente, sia dal fornitore.
Per i software package standard i requisiti possono essere soddisfatti da una combinazione di:
• funzioni standard
• settaggi di configurazione
• customizzazioni del prodotto base
• nuovo software custom,
come le specifiche evolvono, il Quality and Project Plan deve essere aggiornato per definire quali di
questi approcci deve essere usato e come esso va documentato.
Le Specifiche non debbono essere vaghe o ambigue: l'obiettivo è quello di usarle successivamente
per il test.
Un piccolo sistema può essere completamente definito da una Specifica, sistemi più grandi possono
invece richiedere un insieme di specifiche funzionali, di progetto e di configurazione di package.
Il processo di tracciabilità requisiti - specdifiche - progetto - test richiede l'uso di matrici di
tracciabilità (vedi Appendice M5).
La Functional Specification è un documento contrattuale e quindi deve essere approvato sia
dall'utente, sia dal fornitore. Per sistemi piccoli si può omettere la produzione di documentazione di
progetto e di package configuration, inserendo questi temi in appendice alla FS (questo deve però
essere definito nel Quality and project plan). In compenso sistemi complessi possono essere
necessarie più FS. Se si usano software package si deve dove possibile fare ricorso alla
documentazione del fornitore. Le System Acceptance Test Specification è opportuno scriverle in
parallelo alle FS.
L'hardware va basato per quanto possibile su prodotti standard di fornitori qualificati. L' Hardware
Design Specification e l'Hardware Acceptance Test Specification è opportuno scriverle in parallelo.
Il Package Configuration Specification include:
• settaggi di configurazione
• motivi del settaggio con riferimento ai requisiti
• strumenti o metodi da usare per impostare le opzioni richieste
• dipendenze e impatti su altri moduli e sistemi
• sicurezza dei settaggi.
Per sistemi di piccole dimensioni è possibile mettere queste informazioni in appendice a FS (questo
va precisato nel Quality & Project Plan).
Le Software Design Specification sono la base per lo sviluppo. Se c'è un solo modulo da sviluppare
non è necessario produrre la documentazione di design e test a livello di modulo e la Specifica di
test di integrazione. Per sistemi di piccole dimensioni è possibile mettere queste informazioni in
appendice a FS (questo va precisato nel Quality & Project Plan).
Se si usa un approccio OOD/P il fornitore deve verificare che il metodo soddisfi le normative di
settore e i requisiti di utente e documentare tale metodo nel Quality & Project Plan. Le design
review dovranno tener conto di questo approccio e così il Configuration Management che dovrà
fornire copertura anche per librerie e tool associati. Il Controllo di Configurazione deve essere
regolato in conformità all'Appendice M9.
Le Software Module Design Specification devono normalmente essere aggiornate dopo lo sviluppo
per includere dettagli essenziali per la successiva manutenzione.
Le Network Design Specification si rendono necessarie per sistemi in cui la rete è rilevante, esse
includono descrizioni su: componenti fisici, protocolli di trasporto, sistemi operativi di rete,
cablaggi, bridge, server, socket, etc. Per sistemi di piccole dimensioni è possibile mettere queste
informazioni in appendice a FS (questo va precisato nel Quality & Project Plan). Le reti debbono
essere realizzate per quanto possibile con prodotti standard di fornitori qualificati. E' opportuno
produrre in parallelo una Network Acceptance Test Specification.
Il codice deve essere sviluppato con metodi, strumenti, regole di programmazione e convenzioni sui
nomi di variabili che debbono essere documentati. I sorgenti debbono essere sottoposti a code
review. Le modalità e frequenza delle review debbono essere specificate nel Quality & Project Plan.
Se si usano componenti software esistenti (i.e. OOP) si deve valutare se essi debbono essere
sottopostia review e testing. Il Quality & Project Plan deve definire se il fornitore consegna i
sorgenti all'utente, se no l'utente può richiedere il deposito dei sorgenti presso una terza parte. Le
linee guida per la produzione di codice sono descritte in Appendice D5.
Per Specifica prodotta deve essere prodotta un corrispondente insieme di Specifiche di Test, con un
metodo di registrazione della tracciabilità. I test sulla configurazione dei software package possono
avvenire per ispezione o per prova. Per le reti è importante eseguire soprattutto i test di componenti
che potrebbero divenire inaccessibili come conseguenza della costruzione del sistema. Le System
Acceptance Test Specification sono un documento contrattuale e quindi vanno accettate sia
dall'utente, sia dal fornitore. Esse coprono varie aree: funzionalità, configurazione, performance,
aspetti critici, procedure operative. I test debbono coprire le verifiche di allarmi, limiti, range di
valori.
Il testing è svolto a vari livelli di dettaglio, corrispondenti ai vari livelli di specificazione. Il
fornitore è di solito coinvolto in tutti i livelli di test e le registrazioni di test del fornitore possono
essere parte della documentazione di validazione, se è appropriatamente controllata.
System Acceptance Testing
(FAT+SAT)
Hardware Acceptance Testing
Software Integration Testing
Software Module Testing
Review & Test module
Valida URS e FS
Package Configuration Testing
Valida HDS
Valida SDS
Valida SMDS e PCS
Verifica la codifica
La validazione è più pesante per sistemi custom, che per sistemi package based. L'utente ha un
coinvolgimento primario sui livelli alti di testing. Nei sistemi gestionali spesso i test vengono svolti
in tre aree: laboratorio software, laboratorio di test e ambiente target. Gli HAT e i SAT (a volte
divisi in Factory Acceptance Test e Site Acceptance Test, nel qual caso l'utente deve essere presente
in entrambi) devono essere prodotti in modo completamente documentato: moduli firmati. Deve
esistere una procedura definita per eseguire i test e registrarne gli esiti. La fase di accettazione
include la consegna della documentazione finale.
Aspetti gestionali che coprono l'intero ciclo di sviluppo (conformi a ISO 9000) e che devono essere
coperti durante il supplier assessment sono:
1. Review: La modalità deve essere definita nel Quality & Project Plan, le direttive sono in
Appendice M5.
2. Configuration Management: Deve esistere un sistema per il CM e per la gestione delle change
(cambiamenti a documentazione contrattuale o a deliverable approvati devono essere concordati
con l'utente). La modalità deve essere definita nel Quality & Project Plan, le direttive sono in
Appendici M8, M9, M10.
3. Controllo sub-fornitori: Debbono essere approvati dall'utente che si può riservare il diritto di
farne audit. Le forniture debbono essere regolamentate da ordini ben definiti. Il fornitore si deve
rendere garante di queste sub-forniture. Per l'hardware possono essere inclusi certificati di test e
calibrazione.
4. Training: Il fornitore deve erogare adeguata formazione al suo personale e documentare la
formazione eseguita nella documentazione di progetto.
Una volta completato lo sviluppo si devono eseguire le operazioni atte a mantenere lo stato di
validazione del sistema. Il fornitore può essere coinvolto in questo mediante servizi di supporto. Per
i sistemi IT particolare considerazione deve essere rivolta a:
• gestione delle modifiche
• configuration management
• gestione release software
• planning del business continuity (i.e, disaster recovery, procedure di rigenerazione).
3 Validazione di Process Control System (PCS)
I precedenti due paragrafi si riferivano soprattutto ai sistemi IT. Qui vengono trattati invece i
sistemi che gestiscono processi di produzione o di laboratorio. La loro validazione è più complessa
perché l'attività è più multi-disciplinare. I PCS sono a volta integrati con sistemi gestionali per
formare una infrastruttura CIM. Per eseguire la validazione si deve tener conto anche della ISPE
Baseline: Guide on commissioning and qualification, che fornisce indicazioni per qualificazioni con
attività di commissioning.
Lo schema di verifica è fatto col solito approccio a V.
Retirement
Operation &
maintenance
Performance
Qualification
Operational
Qualification
Installation
Qualification
Operational Check
(FAT&SAT)
Installation Check
(FAT&SAT)
Planning
Process Requirement
GxP and safety review
Equipment FS
Control System FS
Mechanical and Operating
Electrical
Interface Design
Design
Design review and approval
Control
System
Design
Module integration
and development
testing
Mechanical and Electrical
Build
Operating Interface Build
Control System
Programming
I sistemi PCS possono appartenere a due categorie:
•
•
embedded in macchinari
standalone connessi a impianti (PLC, SCADA, DCS, BMS (Building Management System)).
Normalmente la generazione della documentazione di sistemi embedded è a carico del fornitore. Per
lo sviluppo di sistemi standalone, il coinvolgimento dell'utente è maggiore.
Il fornitore deve comunque applicare un ciclo di vita atto a produrre la documentazione necessaria
al successivo supporto della fase di qualificazione, con tracciabilità dai requisiti fino al testing.
Di seguito si riporta il ciclo di vita e di documentazione per gli embedded system.
Planning and Definition
Vendor
Assessment
Validation Plan (M1)
USR (D1)
Critical Process
Parameters
Specification Approval
Supplier Assessment (M2)
Design Specification, Development and Construction
Mechanical FS
Electrical &
Software FS
Instrument FS
Mechanical
E&I Diagrams, HDS
SDS
Drawings
Mechanical
Cabling
Code (D5)
Construction
Design Reviewing and Testing
STS
HATS
Software testing
and Results
Electrical testing & Software release
Instrumentation
and installation
Calibration and
Results
FATS
Factory Acceptance Testing and Results
Commissioning and Qualification
Installation
GEP
Qualification
Installation
Operational
Site Acceptance Test
Qualification
Commissioning
Performance
Qualification
Ongoing Operation (Maintaining the validation state)
Change Control
Maintenance
Periodic Review
Decommissioning
Retirement
Location
Responsability
C
C
S
C(S)
S
S(C)
S (C)
S
FAT: S (C)
D. Rev.: C (S)
C
Install: S(C)
IQ: C(S)
SAT: S(C)
OQ: C(S)
Comm.: S(C)
PQ: C(S)
C
C (S)
C
C (S)
Legenda: L'area in grigio è quella soggetta a design review; C è customer, S è supplier, () indica un
possibile coinvolgimento
Di seguito si riporta il ciclo di vita e di documentazione per gli standalone system.
Planning and Definition
Validation Plan (M1)
USR (D1)
Vendor
Assessment
Critical Process
Parameters
Specification Approval
Supplier Assessment (M2)
Location
Responsability
C
C
S
C(S)
S
S (C)
S
S (C)
S
S (C)
S
FAT: S(C)
Des. Re.: C (S)
Design Agreement
Process
Contracto
Design Data rs Quality
Plan
Functional
Design Specs
Acceptance
Test Specs
(1)
System
suppliers
Quality Plan
Design and Development Phase
Cabling &
Instrumentation
Application Data Sheet
(5)
C&I Application
Engineering &
Drawings
Computer Hardware
HW
Test
Design
Specs (2)
Specs
Computer HW
Production
Software
Sw
Design
integrat.
Specs
Specs (3)
Sw
Sw
module
module
Design
Test
Specs
Specs (4)
Sw module coding
& configuration
Development Testing & System Build
C&I inspection and
calibration (vs. 5)
Computer Hw Testing
(vs. 2)
Sw module Tesing
(vs. 4)
Sw module
integration testing
(vs. 3)
Supplier's system integration and testing
(vs. 1, 2 e 3)
Design Review & Acceptance Testing
Factory Acceptance Test (vs. 1)
Commissioning and Qualification
Installation
GEP
Qualification
Installation
Operational
Site Acceptance Test
Qualification
Commissioning
Performance
Qualification
Ongoing Operation (Maintaining the validation state)
Change Control
Maintenance
Periodic Review
Decommissioning
Retirement
C
Install: S(C)
IQ: C(S)
SAT: S(C)
OQ: C(S)
Comm.: S(C)
PQ: C(S)
C
C (S)
C
C (S)
Legenda: L'area in grigio è quella soggetta a design review; C è customer, S è supplier, () indica un
possibile coinvolgimento
Le norme concernenti i PCS mi sembrano meno dettagliate e coerenti di quelle relative agli IT
system del paragrafo precedente (ndr).
Durante la fase di planning l'utente esegue un assessment delle procedure di qualità del fornitore,
per verificarne la congruità e valutare l'esigenza di azioni correttive. Il fornitore redige un Quality &
Project Plan (vedi Appendice M6) e supporta l'utente nell'esecuzione del risk assessment (vedi
Appendice M3). In questo caso l'attività riguarderà non solo hw e sw, ma anche strumentazione,
aspetti elettrici e meccanici.
Le USR (vedi Appendice D1) potranno essere più di una, in particolare ce ne potrà essere una
focalizzata esclusivamente sulle funzionalità di controllo. Questo non è necessario in applicazioni di
piccola dimensione ove i dati sul processo possono essere inclusi nella specifica della macchina o
dell'apparato da controllare. Si deve porre particolare attenzione alla definizione dei parametri
produttivi controllati e all'assessment della loro criticità. Per questo è importante gestire delle
matrici di tracciabilità (vedi Appendice M5).
La documentazione rilevante contrattualmente deve essere messa sotto change control una volta
approvata.
Le Functional Specs sono la base per l'OQ. Per sistemi standalone devono coprire tutti i temi,
mentre per gli embedded le problematiche di controllo possono essere trattate nella documentazione
del macchinario. La struttura della documentazione deve comunque essere definità nel Quality &
Project Plan. Se il software include funzionalità non usate nella specifica applicazione, esse
debbono essere elencate. Per piccoli sistemi è possibile che FS includano in appendice anche le
specifiche di progetto.
Questo tipo di sistemi richiedono una documentazione che correli il sistema di controllo
all'impianto controllato, essa consta di:
• layout degli impianti e degli apparati,
• diagrammi di flusso del processo e localizzazione della strumentazione (P&IDs),
• tabella degli anelli di regolazione e della strumentazione (con dati caratteristici dei segnali,
soglie di allarme, etc.),
• sequenze, logiche e interblocchi di processo (normalmente diagrammi o matrici),
• schemi elettrici di cablaggio.
L'HDS deve includere dati anche per la strumentazione e le interfacce. Per piccoli sistemi è
possibile incorporare il tutto nelle FS.
L'SDS definisce non solo la struttura del software, ma anche le norme di programmazione. Il
software deve essere modulare, strutturato e commentato. Per piccoli sistemi è possibile incorporare
il tutto nelle FS.
L' Instrument Specification è derivata dai P&IDs e i parametri relativi sono ottenuti dalle URS. La
specifica fornisce quindi i requisiti per ogni strumento necessario.
La Realizzazione del sistema si compone di:
• sviluppo software
• costruzione sistema
• realizzazione di disegni ingegneristici.
Le Design Review permettono il tracciamento dei lavori dai requisiti (hw, sw, ambientali,
performance, etc), fino alla fine dello sviluppo. Di nuovo è importante usare matrici di tracciabilità.
Si noti che è ammesso che alcuni requisiti di sistema (layout di schermo, formato reports, etc.) non
siano inizialmente ben definiti e vengano chiariti in corso d'opera: in questo caso si esegue una
review 'ad interim'. Norme per le design review sono incluse anche in ISPE Baseline: Guide on
Commissioning and Qualification.
Lo Sviluppo software deve essere fatto con metodi, convenzioni e strumenti appropriati. Il codice
sorgente deve essere commentato (vedi Appendice D5).
La Costruzione del sistema può avvenire presso il fornitore (normale per gli embedded system) o
presso il sito finale. Essa avviene in accordo ai disegni di assemblaggio dell'impianto e dell HDS.
Le Software Review controllano il rispetto delle specifiche e delle metodologie di sviluppo. Esse
debbono essere svolte da personale esperto e indipendente (vedi Appendice D5).
Il Test di sviluppo è svolto dal fornitore e copre:
• Software development test (funzionale e strutturale),
• Hardware manufacturing test,
• Sw/Hw integration test,
• Instrumentation & electrical equipment manufacturing test.
I Test di accettazione debbono essere formalmente documentati, rivisti e approvati. Essi debbono
avere una severità basata su caratteristiche del sistema e criticità GxP. Normalmente sono divisi in
FAT e SAT. Il FAT di standalone system può essere svolto con simulazione del processo. Il FAT è
fonte preziosa di informazioni per la messa a punto finale del sistema. Il SAT controlla che il
sistema non abbia subito danni nel trasporto e operi correttamente nel suo ambiente finale.
Normalmente la procedura di accettazione SAT è identica a quella FAT, più alcuni test eseguibili
solo nell'ambiente target. Se le modalità di test sono sufficientemente rigorose il SAT può fornire la
base di IQ e OQ (vedi ISPE Baseline: Guide on Commissioning and Qualification).
La strumentazione di campo va calibrata prima e dopo la consegna del sistema.
La Qualificazione verifica che il PCS può essere usato presso la struttura dell'utente.
La IQ controlla:
• Il corretto caricamento del software
• Il corretto assemblaggio e installazione dell'hardware
• I cablaggi di alimentazione e di segnale
• Il controllo della calibrazione e della installazione della strumentazione
• Il corretto funzionamento di diagnostica di power-up e on-line.
La OQ la PQ verificano che la funzionalità del sistema sia adeguata nelle condizioni operative reali,
anche di stress e allarme.
Alla fine della qualificazione viene redatto il Validation Report. Si consideri che normalmente la
PQ va in parallelo al Process Qualification.
Il Mantenimento dello stato di validazione implica la definizione di piani e procedure di assistenza e
supporto, che possono coinvolgere il fornitore. In particolare deve essere definita la procedura per la
ricalibrazione e il controllo periodici della strumentazione. I review periodici debbono essere
focalizzati soprattutto alla verifica dei seguenti attributi di sistema: affidabilità, ripetibilità,
prestazioni e diagnostica, salvaguarda di dati critici, etc. Tutte le modifiche debbono essere
sottoposte a Change Control e Configuration Management.
Il Decommissioning come al solito deve verificare la possibilità di archiviare e ritrovare dati
contenuti nel sistema e rilevanti ai fini del tracciamento di qualità o del rispetto di specifiche
normative.