Un risultato compare sul LIMS: può già essere visto dal cliente? Non necessariamente. Tra il dato che arriva dallo strumento e il risultato che il laboratorio può comunicare esistono passaggi tecnici e autorizzativi distinti. La scelta sbagliata di un permesso, di un automatismo o di una notifica può trasformare un dato in lavorazione in un risultato apparentemente definitivo, prima che siano stati completati controlli qualità, riesame e autorizzazione.
Il tema interessa tanto i laboratori che usano un LIMS completo quanto quelli che collegano Excel, strumenti analitici, gestionali e portali dei committenti. In questo approfondimento proponiamo un flusso operativo verificabile, con esempi di permessi, messaggi automatici e casi da testare in fase di validazione del software.
1. Che cosa cambia tra dato grezzo, risultato verificato e risultato autorizzato
Il primo passo consiste nel definire gli stati del dato. Le etichette suggerite di seguito non sono nomi imposti dalla norma: sono un modello organizzativo da adattare al laboratorio, alle procedure e alle responsabilità effettive.
| Stato | Significato | Visibilità verso il cliente |
|---|---|---|
| Acquisito | Dato importato o registrato; ancora da controllare | No, soltanto personale abilitato |
| In lavorazione | Calcoli e verifiche ancora aperti | Solo stato di avanzamento, senza valore numerico |
| Verificato tecnicamente | Controlli eseguiti e registrati; possibile riesame ulteriore | Non automaticamente |
| Approvato e autorizzato | Completato il processo di riesame e autorizzazione previsto | Sì, nelle forme concordate e ammesse |
| Emesso | Risultato comunicato con modalità, identificativo e data tracciati | Sì, con versione e stato del documento univoci |
| Rettificato / sostituito | Risultato già comunicato sottoposto a correzione documentata | Solo con collegamento chiaro alla versione precedente |
Il passaggio verificato → autorizzato deve essere disciplinato dal laboratorio. In certi processi verificatore e autorizzatore possono essere persone diverse; la separazione dei ruoli deve riflettere i requisiti applicabili e l’organizzazione effettivamente adottata. Il LIMS non deve creare un’autorizzazione tacita per il solo fatto che un risultato supera una soglia numerica.
2. Cosa richiede la ISO/IEC 17025 al sistema informatico
Il § 7.8 disciplina la presentazione dei risultati: questi devono essere riesaminati e autorizzati prima del rilascio, oltre a essere forniti in modo chiaro, corretto e non ambiguo. Il § 7.11 disciplina il controllo dei dati e dei sistemi di gestione delle informazioni. In particolare sono rilevanti la verifica della funzionalità del sistema e delle interfacce prima dell’introduzione (§ 7.11.2), la gestione autorizzata e documentata delle modifiche, la protezione da accessi impropri e perdita dei dati (§ 7.11.3) e il controllo sistematico di calcoli e trasferimenti (§ 7.11.6).
Un LIMS commerciale non è automaticamente validato per ogni configurazione del laboratorio. L’uso ordinario del software standard può beneficiare delle considerazioni della norma sul software commerciale, ma configurazioni personalizzate, interfacce, report, formule, regole di arrotondamento, notifiche e automazioni devono essere valutate e verificate per l’utilizzo previsto.
3. Cliente interno e cliente esterno: la stessa schermata può avere rischi diversi
Un’azienda può voler condividere con il reparto produttivo i dati del laboratorio in tempo reale. Un committente esterno può voler verificare lo stato dei propri campioni accedendo a un portale. Sono situazioni diverse, ma in entrambi i casi occorre evitare che un risultato non autorizzato appaia come una comunicazione definitiva.
- Operatore di laboratorio: può vedere dati in elaborazione per eseguire controlli, modifiche ammesse e riesame. L’accesso rientra nel processo tecnico interno.
- Cliente interno: quando opera come destinatario dei risultati, la consultazione del portale deve rispettare le regole per la loro comunicazione; non basta che sia dipendente della stessa azienda.
- Cliente esterno: deve accedere esclusivamente ai dati e documenti che il laboratorio ha deciso e autorizzato a rilasciare, secondo gli accordi contrattuali.
- Amministratore informatico: i privilegi tecnici del sistema non devono diventare potere indiscriminato di autorizzare risultati di prova.
È possibile mostrare informazioni organizzative come campione ricevuto, analisi in corso o rapporto in preparazione, purché queste etichette non veicolino di fatto un esito analitico non autorizzato. La tracciabilità deve permettere di sapere chi ha visto cosa, quando e in quale versione, secondo una valutazione del rischio e le politiche di accesso.
4. Il DT-09-DL di ACCREDIA: prepararsi al 1° gennaio 2027
ACCREDIA ha approvato il DT-09-DL rev.00 il 16 luglio 2026, stabilendone l’entrata in vigore al 1° gennaio 2027. Alla data di questo articolo, ottobre 2026, il documento è dunque pubblicato ma non ancora entrato in vigore. Si tratta di specifiche prescrittive di applicazione del § 7.8, che evolvono quanto previsto da RT-08.
Il documento chiarisce esplicitamente che, nella comunicazione al cliente, i risultati devono essere stati approvati in forma definitiva e autorizzati. Non costituisce una soluzione corretta etichettarli semplicemente come bozza, provvisori o anticipazioni quando non hanno completato le verifiche e l’autorizzazione.
Il DT-09-DL distingue modalità che il laboratorio deve governare e contrattualizzare:
- RdP completo: presenta i risultati secondo tutti i requisiti applicabili.
- RdP parziale: può comunicare tempestivamente risultati già autorizzati mentre altre prove sono in corso, con successiva emissione del rapporto completo o di quello integrativo secondo regole di identificazione e rintracciabilità.
- Presentazione semplificata: è possibile nei limiti previsti, previo accordo con il cliente e mantenendo disponibili le informazioni omesse.
- Email o comunicazione urgente: non sostituisce il rapporto richiesto e non può essere usata per diffondere risultati analitici non ancora autorizzati.
- Portale interno o esterno: occorre chiarire contrattualmente se l’inserimento dei risultati sostituisce o accompagna il RdP e come si gestisce lo stato di accreditamento delle prove.
Il documento dedica attenzione anche alla tracciabilità dello stato di accreditamento nei portali per clienti interni: il sistema deve consentire di comprenderlo o governarlo con accordi e comunicazioni pertinenti quando il portale non lo rappresenta direttamente.
Riferimento ufficiale: ACCREDIA, DT-09-DL rev.00 (entrata in vigore 01/01/2027). Leggi anche l’approfondimento DN sui rapporti di prova semplificati ISO/IEC 17025.
5. Esempio pratico: controllo fuori limite e notifica automatica
Immaginiamo un campione di acqua sul quale il laboratorio sta determinando un analita. Il LIMS riceve una concentrazione preliminare di 0,58 mg/L e la confronta con una soglia configurata a 0,50 mg/L. Il dato potrebbe essere ancora soggetto a conferma analitica, controllo del bianco, verifica del recupero, valutazione delle diluizioni e applicazione di eventuali regole decisionali.
| Evento | Azione del sistema | Comunicazione corretta |
|---|---|---|
| Importazione del dato 0,58 mg/L | Stato «acquisito» | Solo visibilità tecnica interna |
| Superamento della soglia di attenzione | Segnalazione al personale abilitato | Avviso interno per verifiche, non risultato al cliente |
| QC fuori controllo | Blocco dell’autorizzazione e apertura anomalia | Nessuna comunicazione analitica definitiva |
| Ripetizione, verifica e riesame completati | Registrazione esiti e responsabilità | Dato ancora non necessariamente rilasciato |
| Autorizzazione del risultato | Rilascio secondo le regole approvate | RdP o forma ammessa e concordata |
| Rilevata successivamente una correzione | Gestione versione e documento sostitutivo/rettificato | Notifica riferita in modo univoco al documento corretto |
Superamento di una soglia di attenzione, superamento di un limite e dichiarazione di non conformità non sono automaticamente la stessa cosa. Prima di generare un giudizio il sistema deve considerare la regola decisionale applicabile e l’incertezza, quando pertinente.
6. Flag di superamento N1 e N2: limiti di legge e limiti del cliente
Nel LIMS, N1 e N2 sono flag di superamento associati a un limite di legge applicabile oppure a un limite o valore soglia definito dal cliente. Non sono stati di autorizzazione e non costituiscono categorie previste dalla ISO/IEC 17025. Il laboratorio deve documentare a quali condizioni e soglie corrispondono i singoli codici N1 e N2, senza presumere un’associazione univoca che non sia stata definita nella configurazione del gestionale.
- Superamento di limite di legge: il sistema confronta il valore con un limite applicabile alla matrice, al parametro e al contesto normativo pertinente, verificando unità di misura e condizioni di confronto.
- Superamento di limite del cliente: il sistema confronta il valore con una soglia contrattuale o operativa concordata con il committente, che può essere diversa da quella prevista dalla legge.
Un flag N1 o N2 non è automaticamente una dichiarazione di non conformità. È l’esito di una regola informatica di confronto: prima di usarlo per prendere decisioni o comunicare il risultato al cliente occorre verificare il dato analitico, la correttezza della soglia selezionata, eventuali regole decisionali e lo stato di riesame e autorizzazione.
Il LIMS dovrebbe registrare, per ogni flag, il tipo di limite (legge/cliente), il valore e l’unità della soglia, la fonte applicabile, il risultato confrontato, l’eventuale regola decisionale, la data dell’evento e gli utenti destinatari. Il flag può attivare un avviso interno anche durante la lavorazione, ma non deve provocare l’invio automatico al cliente di un risultato non autorizzato.
In sintesi: il superamento di un limite e l’autorizzazione alla comunicazione sono due controlli distinti. Il primo può essere automatizzato; il secondo deve seguire le responsabilità e le procedure del laboratorio.
7. Requisiti funzionali da chiedere al fornitore del LIMS
In capitolato, contratto e test di accettazione suggeriamo di tradurre la procedura in requisiti osservabili:
- Stati non ambigui: acquisito, in lavorazione, verificato, autorizzato, emesso, rettificato.
- Permessi distinti: inserimento, modifica, verifica, autorizzazione e consultazione per ciascun ruolo.
- Blocco tecnico delle pubblicazioni: il portale e le API non devono esporre risultati non autorizzati, neppure tramite link diretto, email o esportazione CSV.
- Audit trail: identificazione dell’operatore, data/ora, versione, valore precedente e motivo della modifica per gli eventi rilevanti.
- Gestione QC: collegamento tra analisi, controlli, criteri e possibilità di sospendere il rilascio.
- Calcoli e approssimazioni: regole di arrotondamento, LOQ, diluizioni, incertezza, somme e trasferimenti verso RdP coerenti con procedure e metodi.
- Documenti parziali e integrativi: collegamento univoco tra emissioni e possibilità di ricostruire che cosa è stato comunicato.
- Accreditamento: rappresentazione corretta delle prove accreditate/non accreditate e dei relativi cambiamenti.
- Flag di superamento N1/N2: distinzione tra superamento dei limiti di legge e dei limiti del cliente, soglie e fonti documentate, criteri di attivazione e destinatari delle eventuali notifiche.
- Recupero e sicurezza: backup, controlli di accesso, gestione dei guasti e verifiche delle interfacce.
8. Come validare il flusso prima della messa in produzione
La validazione del LIMS deve riferirsi al processo reale, non limitarsi alla dimostrazione che il programma si apre. Una matrice essenziale di casi di prova comprende:
| Test | Esito atteso |
|---|---|
| Operatore inserisce un risultato senza QC | Il cliente non visualizza il numero |
| QC supera la soglia di scarto | Autorizzazione bloccata e anomalia tracciata |
| Risultato verificato ma non autorizzato | Nessuna pubblicazione tramite portale, API o email |
| Risultato autorizzato e rapporto emesso | Accesso del cliente al documento corretto |
| RdP parziale autorizzato | Identificativo, contenuti e collegamento al successivo RdP governati |
| Modifica di un risultato già emesso | Nuova versione/documento e tracciabilità della correzione |
| Utente senza autorizzazione tenta accesso diretto | Accesso negato; nessuna fuga di dati |
| Esportazione automatica di un risultato non approvato | Blocco anche sul canale di esportazione |
Per ogni test conservare requisito, configurazione, input, risultato atteso, risultato osservato, evidenza, responsabile ed esito. Va inoltre programmata la verifica dopo modifiche di versione, regole, template o interfacce. È utile integrare questi controlli con la tracciabilità delle registrazioni informatiche e con l’approfondimento sull’arrotondamento dei risultati.
9. Il punto decisivo: accordo contrattuale e procedura interna
Il laboratorio dovrebbe indicare nel riesame della richiesta o del contratto quali informazioni verranno trasmesse, attraverso quali canali e con quale carattere. Occorre distinguere un portale di avanzamento delle attività da un canale di presentazione dei risultati di prova. Il secondo richiede il governo di autorizzazione, contenuto, identificazione, riservatezza, accreditamento e successive correzioni.
Una procedura efficace chiarisce almeno: chi autorizza, che cosa viene rilasciato, a chi, con quale atto, in quale momento, con quale identificativo e come si interviene in caso di errore. Senza queste risposte, neppure un LIMS tecnologicamente avanzato può dimostrare da solo il rispetto dei requisiti.
Riferimenti
- ISO/IEC 17025:2017, requisiti § 7.8 (presentazione dei risultati) e § 7.11 (controllo dei dati e dei sistemi informativi).
- ACCREDIA, DT-09-DL rev.00 del 16/07/2026, entrata in vigore 01/01/2027.
- DN Consulenze: rapporti di prova semplificati ISO/IEC 17025.
Articolo tecnico DN Consulenze, ottobre 2026. Gli stati del flusso costituiscono un modello operativo proposto. I flag N1/N2 segnalano il superamento di limiti di legge o di limiti del cliente secondo la configurazione documentata del LIMS: non equivalgono all’autorizzazione o alla comunicazione del risultato. Verificare sempre i requisiti contrattuali, normativi e di settore applicabili al caso specifico.