Lims: una metodologia di progettazione di un sistema informatico convalidato per un'azienda farmaceutica

2 – Capitolo 1 
 
¾ Gestire gli items tipici del Dipartimento (metodi d’analisi, specifiche, standard, 
strumentazione analitica, materiali, training e accessi del personale, tecniche analitiche, 
campioni, richieste d’analisi e analisi) e comunicare con moduli esterni che elaborano i 
dati analitici generati dalla strumentazione di laboratorio. 
¾ Controllare e promuovere lo scambio delle informazioni. 
¾ Gestire tutti i flussi informativi che attraversano i vari Dipartimenti. 
¾ Promuovere l’integrazione delle attività del dipartimento con gli altri processi aziendali. 
¾ Definire un unico insieme di dati accessibili a tutti gli interessati e utilizzabili per 
prendere delle decisioni. 
¾ Eliminare la duplicazione dei dati. 
¾ Aumentare l’efficienza di laboratorio. 
¾ Esercitare coerentemente le migliori tecniche di laboratorio. 
¾ Incrementare il livello della conformità qualitativa, ed in particolare l’integrità dei dati 
(accuratezza, validità e sicurezza), le firme di approvazione e l’Audit Trail automatico. 
¾ Ridurre i controlli manuali, attraverso l’implementazione di controlli automatici e 
procedure di “auditing”. 
¾ Promuovere e gestire l’acquisizione automatica dei dati strumentali. 
¾ Implementare l’archiviazione automatica dei Raw Data, riducendo la documentazione 
cartacea. 
Due sembrano gli aspetti fondamentali del problema da risolvere. In primo luogo, si 
dovrà tenere conto che la progettazione di un sistema con simili requisiti porterà 
conseguentemente ad automatizzare oltre che il trattamento delle informazioni gestite dai 
laboratori analitici, anche, ed è cosa ben più importante, una buona parte del sistema 
informativo della realtà organizzativa interessata. 
In effetti il Dipartimento di Sviluppo Farmaceutico rappresenta un’organizzazione di 
persone con la necessità di raccogliere, archiviare, elaborare e comunicare informazioni per il 
raggiungimento di obiettivi comuni. Due appaiono gli scopi legati alla necessità di 
informazione ([12],[28]): 
¾ Scopo operativo: mantenimento e gestione delle informazioni secondo i requisiti 
specifici (informazioni di servizio). 
¾ Scopo decisionale: proiettare nel futuro le informazioni, su cui si prendono delle 
decisioni (informazioni di governo). 
– 3 
 
L’insieme organizzato delle procedure, delle risorse umane e dei materiali per la 
raccolta, l’archiviazione, l’elaborazione e la comunicazione di informazioni necessarie per 
gestire sia le attività operative che quelle di governo di un’organizzazione aziendale non 
rappresenta altro che il suo Sistema Informativo. Quindi realizzare un sistema informatico, 
ossia un sistema per il trattamento automatico delle informazioni, significa realizzare il 
sottoinsieme del sistema informativo, dedicato alla gestione automatica delle informazioni 
rappresentate mediante dati digitali. 
In secondo luogo, realizzare un sistema informatico che soddisfi i requisiti regolatori 
imposti in ambito farmaceutico, condurrà a gestire un processo continuativo e a produrre della 
documentazione per evidenziare che il sistema è stato sviluppato in accordo a specifiche 
predeterminate e continuerà a comportarsi secondo tali specifiche. Nella pratica porterà a 
realizzare un sistema informatico convalidato per un’azienda farmaceutica. 
Negli ultimi anni, le aziende farmaceutiche multinazionali stanno subendo una notevole 
pressione da parte degli Organismi Ispettivi americani FDA
3
, che si concretizza nella richiesta 
di requisiti regolatori sempre più precisi ed espliciti. Questo ha determinato, a livello 
aziendale della GlaxoWellcome di Verona, la nascita di una struttura interna alla Direzione 
Sistemi Informativi, dedicata alla supervisione e al controllo dell’adeguamento informatico, 
tecnologico e applicativo nel rispetto delle normative GLP/GCP/GMP
4
, poste appunto dalla 
FDA. Tale struttura, definita IT QA
5
, interagisce con le varie unità aziendali di “Quality 
Assurance” con cui tiene aggiornate le conoscenze relative all’ambito regolatorio. Inoltre, 
essa effettua, in collaborazione con la struttura di sviluppo software, un monitoraggio costante 
dei sistemi informatici esistenti, definendo gli standard e i requisiti a cui dovranno 
conformarsi quelli di nuova creazione. 
Una particolare attenzione deve essere posta sull’ultima normativa CFR 21 Part 11
6
, che 
a partire dal 1997 definisce i requisiti minimi che permettono di considerare le registrazioni e 
le firme elettroniche del tutto equivalenti, in termini di sicurezza ed attendibilità, alle 
registrazioni ed alle firme manuali eseguite sulla carta ([70],[71],[72]). 
La progettazione e la realizzazione di un sistema informatico, obiettivo della tesi, è 
generalmente un processo molto complesso che richiede un’alta qualificazione in coloro che 
                                                 
3
 Acronimo per Food and Drug Administration. 
4
 Per una descrizione dettagliata delle normative GXP si rimanda il lettore al paragrafo 3.1 della tesi. 
5
 Acronimo per Information Tecnology Quality Assurance. 
6
 Per una descrizione dettagliata della normativa CFR21 si rimanda il lettore al paragrafo 3.4 della tesi. 
4 – Capitolo 1 
 
sono chiamati a realizzarlo. Le conseguenze di un progetto approssimativo possono essere 
gravissime per un’organizzazione aziendale: inefficienza, perdita di informazioni, costi di 
manutenzione, costi di riprogettazione, blocco di attività operative, ecc.  
Un errore tipico è quello di interpretare il sistema informatico come la meccanizzazione 
di procedure prima eseguite manualmente. In questo modo si presenta il rischio di riprodurre 
delle inefficienze preesistenti, giungendo ad un prodotto diverso da quello ottenibile con una 
razionalizzazione del sistema informativo.  
Secondo la letteratura informatica ([2],[61],[62]), per fornire una metodologia di 
progettazione appare indispensabile eseguire una decomposizione in passi successivi, 
indipendenti dall’intera attività di progetto. Si suggerisce inoltre di considerare una serie di 
strategie da seguire nei vari passi e di stabilire preventivamente alcuni criteri per la scelta di 
alternative e modelli di riferimento, che vanno a descrivere i dati di ingresso/uscita delle varie 
fasi. 
Le tre proprietà che una metodologia deve garantire sono principalmente: la generalità 
rispetto alle applicazioni e ai sistemi in gioco; la qualità del prodotto in termini di correttezza, 
completezza ed efficienza rispetto alle risorse impiegate e la facilità d’uso sia delle strategie 
che dei modelli di riferimento ([2],[61],[62]). 
Nella realtà non esiste una metodologia di progettazione universalmente riconosciuta, 
ma tante metodologie (più o meno formalizzate) seguite dalle varie “scuole”: case costruttrici, 
software house, liberi professionisti, ecc. 
Le metodologie attualmente più diffuse possono essere classificate in due grandi 
categorie a seconda che il progetto sia guidato dalle procedure richieste nelle specifiche 
applicazioni (metodologie HIPO, Warnier, Jackson e altre) o dalla struttura dei dati da 
conservare (metodologie basate sulla modellazione dei dati). Nel primo caso, si perviene 
normalmente a un software molto efficiente, ma modifiche o future applicazioni comportano 
in genere dei costi elevati. Nel secondo caso, si cerca di costruire un modello della realtà 
indipendente dalle applicazioni e ciò costituisce una forma di garanzia per soddisfare le future 
applicazioni senza compromettere il lavoro svolto ([1],[13]). 
Nel seguito di questo lavoro, si restringerà l’attenzione esclusivamente a questo secondo 
tipo di metodologie, prendendo in considerazione un principio per la modellazione dei dati 
semplice, ma efficace: quello di separare in maniera netta le decisioni relative a cosa 
rappresentare da quelle relative a come farlo ([43]). 
– 5 
 
Esiste un generale accordo, nell’ambito delle basi di dati, nel ritenere che la 
progettazione di un sistema informatico sia un processo ciclico permanentemente in vita, che 
passa attraverso una serie di attività raggruppabili in tre fasi concettualmente distinte 
([1],[2],[13]): 
1. raccolta delle richieste degli utenti: individua e studia le proprietà e le funzionalità che 
il sistema dovrà avere, attraverso un’interazione con l’utente, per ottenere una 
descrizione completa informale dei dati coinvolti; 
2. progettazione concettuale: rappresenta le specifiche della realtà di interesse in termini 
di una descrizione formale e completa, indipendente dai criteri di rappresentazione 
utilizzati nei sistemi di gestione di basi di dati; 
3. realizzazione o progettazione logica e fisica: traduce la descrizione formale prodotta 
nella fase precedente in una struttura di rappresentazione propria del tipo di sistema per 
la gestione della base di dati a disposizione, completandola con la specifica dei 
parametri fisici di memorizzazione dai dati. 
La delimitazione delle fasi non è mai chiaramente distinguibile, come risulterà evidente 
nella seguente figura: 
 
 
 
 
 
 
 
 
 
 
 
 
 
Gli archi con il doppio senso stanno ad indicare un’attività di verifica che occorre 
sempre intraprendere (anche più volte) prima di passare alla fase successiva. Ognuna delle tre 
fasi produce un risultato: rispettivamente la definizione dei requisiti, il progetto concettuale, il 
Figura 1-1 Ciclo di vita del sistema informatico. 
6 – Capitolo 1 
 
progetto logico e fisico. Quest’ultimo rappresenta in definitiva il software che implementa il 
sistema informatico. 
Il processo di progettazione è ciclico, perché l’uso stesso del sistema informatico può 
stimolare gli utenti ad avanzare nuove richieste, cui non avevano pensato precedentemente. 
Inoltre, si possono effettivamente creare nuove esigenze per la dinamica stessa di ogni 
organizzazione. Questi nuovi bisogni degli utenti non dovrebbero comunque influenzare i 
risultati delle prime due fasi, almeno nel medio termine, in quanto una loro frequente 
modifica comporterebbe dei costi notevoli, specie qualora il sistema fosse già operante. 
Non vi è dubbio che la scelta delle strategie, dei criteri e dei modelli che caratterizzano 
una metodologia di progettazione dipendono dalla natura del progetto, dai metodi e dagli 
strumenti che si hanno a disposizione. L.B.S. Raccoon (1995), in un interessante articolo, si 
serve dei frattali
7
 per dare una rappresentazione idealizzata del processo software. Per quanto 
riguarda il lavoro di tesi, si sono qui adottate strategie e modelli imposti dagli standard 
definiti nella realtà aziendale GlaxoWellcome di Verona, oltre ai principi e ai concetti offerti 
dalla letteratura informatica. 
Un progetto tende sempre a risentire degli stili dei diversi progettisti e dunque altri 
avrebbero sicuramente dato, a questo problema, soluzioni diverse rispetto a quella qui 
esposta. 
Per gestire in modo efficace il progetto si è posto particolare attenzione sulle Persone, 
sul Problema e sul Processo (gestione fondata sulle tre “P”, [43],[45]). L’ordine non è casuale 
visto che le Persone rappresentano il primo elemento chiave per ogni progetto software. 
Di fronte ad un problema così complesso si è preferito gestire la scomposizione in parti 
(partitioning) e la loro successiva ripartizione all’interno di un team (nel presente caso 
costituito mediamente da tre persone), dove risulta fondamentale un’organizzazione fondata 
sulla collaborazione e sulla comunicazione.  
Per quanto concerne il Problema, prima della pianificazione del progetto si è cercato di 
stabilire nel modo migliore gli scopi e la portata, considerando eventuali soluzioni alternative 
e individuando ogni possibile vincolo tecnico e organizzativo. Per scopi si intendono gli 
obiettivi globali del progetto, i quali vengono determinati senza preoccuparsi di come 
raggiungerli. La portata individua i dati, le funzioni e i comportamenti principali che 
                                                 
7
 In origine, i frattali sono stati introdotti per scopi di rappresentazione geometrica. Una configurazione viene 
definita e applicata ricorsivamente a scala sempre più piccola; le configurazioni sono “inscatolate” una dentro 
l’altra. 
– 7 
 
caratterizzano il problema e soprattutto tenta di stabilire dei limiti qualitativi a queste 
caratteristiche. 
Infine, si è posto particolare attenzione al Processo in quanto offre il quadro di 
riferimento entro cui è possibile definire il piano complessivo di sviluppo del software ([45]). 
Il progetto di un sistema informatico rappresenta un processo generalmente molto 
delicato e complesso che, sebbene presenti aspetti creativi, deve essere affrontato in accordo 
ad una precisa metodologia e con adeguati supporti software. Utilizzare una metodologia 
consolidata negli anni, che ha dato prova di soddisfare pienamente le proprietà sopra descritte, 
ha costituito una buona base di partenza. 
Per i passi successivi ci si è lasciati guidare da chi è maestro (”..prendiamo questa via 
anche se difficile perché le cose belle sono sempre difficili”, Platone). 
Si spera che il presente lavoro possa essere apprezzato, in modo particolare, da coloro 
che, per lavoro o per studio, sentono l’esigenza di trovare illustrato un caso reale di 
progettazione di una base di dati, che permette, partendo dai requisiti utente, di arrivare a 
produrre una struttura di dati qualitativamente accettabile. 
1.2 Contributo teorico del lavoro di tesi 
Il contributo teorico originale di questa tesi può individuarsi nella realizzazione di un 
meccanismo per la gestione di record e firme elettroniche, che soddisfi i requisiti regolatori, 
richiesti dalla normativa CFR 21 Part 11 sancita dalla FDA, per tutti i sistemi che gestiscono 
dati considerati critici in area farmaceutica ([70],[71]). 
Si è basata la soluzione proposta sulla costruzione di una base di dati, con un 
comportamento reattivo, realizzata codificando una parte applicativa, che normalmente viene 
gestita all’interno dei programmi, tramite regole attive. In questo modo, si è garantita una 
nuova dimensione alla indipendenza della basi di dati definita indipendenza della conoscenza 
([2],[59]). 
Numerosi sono i vantaggi introdotti da questa nuova dimensione, la quale in particolare 
rende “attivo” il comportamento stesso della base dati (altrimenti passivo), permette di far 
condividere tali regole a tutte le applicazioni interessate (diversamente si avrebbe una 
replicazione in tutti i programmi applicativi) e, infine, soddisfa i requisiti regolatori, gestendo 
i dati in modo “intrinsecamente sicuro”. 
8 – Capitolo 1 
 
Le basi di dati attive, oggi, sono oggetto di molti studi sperimentali; la letteratura 
tecnica presenta esempi di sistemi prototipali, sia relazionali che ad oggetti, che mettono a 
disposizione delle regole attive particolarmente potenti ed espressive ([2],[59]). 
Nella tesi si andrà a prendere in considerazione solo il caso relazionale ([11],[14]), in 
quanto costituisce lo standard aziendale della realtà lavorativa presso cui è stata realizzata la 
tesi. 
1.3 Organizzazione della tesi 
Per facilitare il lettore nella scoperta dei contenuti si è articolata la tesi in tre sezioni. 
Nella prima sezione, “I concetti di base”, si sono raggruppati i capitoli 
2.“INTRODUZIONE” e 3.”LA CONVALIDA IN AREA FARMACEUTICA” in cui 
vengono presentate le caratteristiche fondamentali della filosofia dei LIMS e della convalida 
dei sistemi computerizzati in area farmaceutica. In essi vengono illustrati brevemente, ma in 
modo sufficientemente dettagliato, tutti i concetti di base che hanno influenzato la 
progettazione. La lettura di questi capitoli, propedeutici al resto della tesi, è consigliabile per 
una buona comprensione delle scelte da me adottate nel facimento del presente lavoro (es. 
firma elettronica). 
Nella seconda sezione, “Il progetto del sistema”, si sono inseriti i capitoli salienti della 
tesi, 4.“DEFINIZIONE DEI REQUISITI”, 5.“PROGETTAZIONE CONCETTUALE”, 
6.“PROGETTAZIONE LOGICA” e 7.“PROGETTAZIONE FISICA”. In essi vengono 
illustrati ed esemplificati i risultati ottenuti in ogni fase caratteristica della metodologia di 
progettazione adottata: la definizione delle specifiche finali, il modello concettuale, il modello 
logico e il modello fisico. In particolare, nel capitolo 7.“PROGETTAZIONE FISICA” si 
trova la descrizione in dettaglio del meccanismo di record e di firma elettronica che 
rappresenta il contributo teorico originale di questa tesi. Il meccanismo è stato potenziato con 
la proposta di una possibile soluzione per la realizzazione di un riconoscitore (Parser) di 
giustificativi, validi per l’ Audit Trail e/o la firma di un record elettronico. 
Nella terza sezione, “Le considerazioni finali”, si potranno leggere, nel capitolo 
8.”CONSIDERAZIONI CONCLUSIVE”, i risultati raggiunti con il lavoro svolto, le difficoltà 
e i limiti riscontrati durante le fasi di progettazione e sviluppo, ed infine la previsione delle 
future implementazioni che andranno a caratterizzare la pianificazione delle prossime attività 
– 9 
 
lavorative. Nei restanti capitoli si troverà il materiale di supporto e di completamento alla tesi 
stessa, organizzato in APPENDICE, GLOSSARIO e BIBLIOGRAFIA. 
Nell’APPENDICE si riportano gli ulteriori dettagli tecnici della progettazione fisica, 
mentre nel GLOSSARIO si riporta l’elenco, in ordine alfabetico nella dizione italiana, dei 
termini informatici ed analitici utilizzati nella stesura della tesi. Per alcuni termini si 
riporteranno più definizioni numerandole progressivamente. La presenza, in una definizione, 
di un termine in grassetto, identifica che tale termine presenta a sua volta una definizione 
nello stesso glossario. 
Conclude il lavoro un articolata BIBLIOGRAFIA, per dar modo al lettore in qualunque 
momento che lo desideri di risalire al testo originale, che si chiude con il paragrafo “Ulteriori 
fonti di informazioni”, contenente le fonti di informazioni elettroniche consultate durante il 
facimento del presente lavoro. Con l’avvertenza che gli indirizzi del World Wide Web 
mutano di frequente, alcuni degli URL citati potrebbero già essere cambiati dopo la stesura 
della tesi.