PHARMA LAB · PL-06-025

Fornitori di software e cloud per il laboratorio: qualificazione e responsabilità

Qualifica il servizio che userà davvero il laboratorio: dal campione ai metadati, fino al recupero dei record quando il contratto termina.
Illustrazione tecnica di specialisti di laboratorio e informatici che esaminano insieme un servizio digitale e le evidenze dei dati da conservare.

Un fornitore può gestire bene la propria infrastruttura senza conoscere come il laboratorio usa un risultato per decidere su un lotto. La qualificazione deve collegare il servizio acquistato alle attività e ai record che deve sostenere. Per un LIMS ospitato in cloud, la domanda concreta è se campioni, metodi, risultati, revisioni e storia restino controllabili durante l’uso e dopo l’uscita dal servizio.

Il nome commerciale della piattaforma, un certificato o una demo non risolvono questa domanda. Occorrono evidenze pertinenti, responsabilità assegnate e prove sull’uso previsto. Questo approfondimento propone criteri tecnici di valutazione; gli accordi effettivi devono essere esaminati dalle funzioni aziendali competenti.

Qualificare un servizio definito, non un marchio

Descrivi processi, utenti, dati e dipendenze prima di chiedere documenti. Distingui software applicativo, hosting, gateway dello strumento, manutenzione e archiviazione. Identifica il fornitore contrattuale e i subfornitori che svolgono attività rilevanti: il supporto del LIMS e il gestore dell’infrastruttura potrebbero essere soggetti diversi.

Definisci dove risiedono e come transitano i dati, quali configurazioni controlla il laboratorio e quali dipendono dal servizio. Le etichette SaaS, PaaS o IaaS aiutano a descrivere il modello, ma non assegnano da sole ogni compito. Valuta anche connessione di rete, autenticazione, licenze, strumenti locali e disponibilità necessaria al flusso QC.

Un servizio usato solo per pianificazione non ha necessariamente lo stesso impatto di quello che conserva l’unica copia del dato nativo. Documenta criticità e motivazione della profondità di valutazione, comprese eventuali verifiche dirette e informazioni ancora mancanti.

Esaminare competenza, sviluppo ed evidenze

Chiedi esempi riferiti al servizio e alla versione proposta: gestione requisiti, sviluppo, test, anomalie, rilascio e cambiamenti. Verifica come le criticità vengono segnalate ai clienti e quali prove siano disponibili quando una funzione è configurata diversamente. Un pacchetto di test del fornitore può contribuire alla validazione dell’uso di laboratorio, ma non dimostra da solo la correttezza di workflow e interfacce locali.

Per certificazioni e attestazioni, controlla organismo, periodo, perimetro, esclusioni e controlli demandati al cliente. Un’attestazione sull’infrastruttura non copre automaticamente l’applicazione, la configurazione del tenant o l’integrità di un risultato. Le limitazioni di accesso alle evidenze devono essere valutate, non compensate con una dichiarazione generica «cloud GMP».

Assegnare compiti sul percorso del campione

La matrice deve distinguere chi esegue, chi valuta l’esito e chi decide. Le assegnazioni seguenti sono esemplificative: vanno confermate con il servizio reale e tradotte in accordi e procedure coerenti.

Attività o controllo Responsabilità da definire Evidenza Impegno da concordare Riesame
Trasferimento strumento–LIMS Gestore gateway e fornitore applicativo eseguono; laboratorio riconcilia Campione, unità, versioni, errori e messaggi ripetuti Confini di assistenza e gestione degli scarti Dopo modifiche di interfaccia o difetti
Ruoli e accesso di assistenza Cliente autorizza utenti; provider governa propri operatori Permessi effettivi e attività privilegiate attribuibili Accesso limitato, notifica e revoca secondo condizioni definite Cambi di personale, rischio o servizio
Nuova versione del metodo Laboratorio approva; servizio conserva legami e storia Risultato collegato alla versione utilizzata Disponibilità e integrità delle versioni storiche Cambi di modello dati o configurazione
Recupero di un dataset Provider esegue il recupero previsto; cliente verifica l’utilizzabilità Segnali, metadati e relazioni recuperati Perimetro, obiettivi e responsabilità di restore Prove e cambi delle dipendenze
Incidente e rilascio software Provider comunica; cliente valuta impatto QC Evento, dati coinvolti, release note e azioni Canali, tempi pertinenti, evidenze e gestione delle urgenze Incidenti e qualità delle comunicazioni
Uscita dal servizio Provider restituisce; laboratorio riconcilia e conserva Export completo, leggibilità, audit trail e legami Formati, accesso residuo, assistenza, costi e condizioni di cessazione Prove di export e modifiche del servizio

Una casella «condiviso» senza esecutore ed evidenza può nascondere un’attività che nessuno svolge. Per esempio, una copia del database gestita dal provider può non includere i file nativi conservati su un gateway locale: il laboratorio deve riconoscere e coprire quel confine.

Accordi verificabili e continuità del record

Gli accordi devono rendere chiari perimetro dei dati, attività affidate, subfornitura, comunicazioni, gestione dei cambiamenti e disponibilità delle evidenze. Definisci come laboratorio, IT e qualità valutino incidenti e release che possono incidere su acquisizione, calcolo, audit trail, firme o conservazione. Un preavviso privo delle informazioni necessarie può non permettere una valutazione utile.

La possibilità di verifica va definita in modo coerente con rischio e obblighi applicabili, includendo accesso alle informazioni pertinenti e audit delle attività affidate. Non confondere un questionario compilato con la dimostrazione che i controlli funzionino. Conserva le conclusioni e le condizioni con cui il servizio viene accettato.

Prima di dipendere dal servizio, prova una strategia di uscita. Quali oggetti sono esportabili? Con quali formati, legami, visualizzatori e condizioni di licenza? Chi permette l’accesso dopo la cessazione e per quanto, secondo l’accordo? L’articolo sulla migrazione di CDS e LIMS approfondisce la riconciliazione del contenuto e del significato. Non pianificare la cancellazione della sorgente prima di una soluzione verificata e autorizzata.

Caso simulato: risultati esportati, storia assente

Durante la valutazione di un LIMS, il laboratorio chiede l’export del campione di prova C52, che contiene risultato corretto, versione precedente e motivo della modifica. Il file ricevuto include soltanto l’ultimo valore e l’identificativo del campione; mancano storia, identità degli autori e collegamento alla specifica applicata.

Il numero di risultati coincide, ma l’export non permette di ricostruire la decisione. Il team registra il gap e chiede una dimostrazione dell’esportazione completa o una soluzione documentata di conservazione e accesso. Verifica il nuovo pacchetto su un ambiente separato, con persone che non dipendano dalla memoria dell’autore.

Se la soluzione resta insufficiente, quel requisito critico non è soddisfatto: il servizio non viene accettato per l’uso previsto solo perché la demo funziona. Il caso è simulato e non descrive un difetto di un fornitore reale.

Riesaminare il servizio durante l’esercizio

Segui indicatori pertinenti: incidenti che coinvolgono record, esiti del recupero, difetti delle interfacce, qualità delle notifiche e chiusura delle azioni. Definisci frequenza del riesame secondo criticità e prestazioni; rivaluta cambi di subfornitore, architettura o servizio. Disponibilità percentuale e velocità dell’assistenza sono utili, ma non sostituiscono la completezza dei dati.

L’EU GMP Chapter 7, revisione 1, operativo dal 31 gennaio 2013, tratta attività esternalizzate, responsabilità, accordi e accessibilità dei record. L’Annex 11, gennaio 2011, §3, riguarda fornitori e prestatori di servizi. La PIC/S PI 041-1, 1 luglio 2021, §10, approfondisce la data integrity nelle attività affidate a terzi.

Fonti consultate il 2 ottobre 2026, con riferimento al contesto GMP dei medicinali per uso umano. L’accettazione del servizio deve restare collegata a ciò che è stato dimostrato, alle responsabilità concordate e alle condizioni d’uso del laboratorio.

Contenuto tecnico per decisioni informate: non sostituisce procedure approvate, requisiti applicabili o manuale dello strumento.

Continua l’approfondimento