Il Sistema di Registrazione per il Controllo degli Eventi nei Dispositivi Medici Software

Nel contesto attuale dei dispositivi medici software – sia Software as a Medical Device (SaMD) sia Software in Medical Device (SiMD) la crescente complessità architetturale, l’integrazione cloud, la connettività e l’attenzione alla cybersecurity hanno reso la Registrazione e la Tracciabilità delle attività software, un elemento centrale della progettazione di un dispositivo, che ha implicazioni dirette sulla sicurezza del paziente, sulla qualità del software e sulla conformità normativa.

Per cui sempre più spesso, durante gli audit regolatori, nel corso di indagini su incidenti oppure nell’ambito delle attività di post-market surveillance, emerge una domanda fondamentale: “È possibile ricostruire con certezza cosa è accaduto nel sistema?”

La capacità di rispondere in modo oggettivo, documentato e tecnicamente dimostrabile a questa domanda, è dovuta all’esistenza di un Sistema di registrazione degli eventi, progettato in modo strutturato che è oramai diventato parte integrante del dispositivo stesso

Gli aspetti che rendono indispensabile la presenza un’azione sistematica di registrazione riguardano ad esempio:

1. Aspetto legale e di responsabilità in caso di incidente dove , il fabbricante, al fine di difendere tecnicamente il funzionamento del dispositivo in sede ispettiva o durante un contenzioso, deve poter dimostrare in modo oggettivo: quali azioni sono state eseguite, da chi, quando, e con quale configurazione software
2. Sicurezza del paziente e gestione del rischio allorquando la tracciabilità delle operazioni consente di: individuare utilizzi impropri o anomalie, ricostruire sequenze operative critiche, valutare l’efficacia delle misure di controllo
3. Sicurezza informatica (Cybersecurity)  in un contesto di crescente connettività, sono necessari strumenti di monitoraggio della sicurezza informatica. Per questo  le azioni di  registrazione e di analisi degli eventi  sono  indispensabili per rilevare accessi non autorizzati, alterazioni e comportamenti anomali

Elementi di registrazione

Nell’ambito di un sistema di controllo degli eventi sono generalmente coinvolti due modalità di registrazione che hanno importanza e utilizzi diversi

1. File di Log (Il “Diario Tecnico”) è una registrazione cronologica di eventi di sistema. È orientato al funzionamento del software e all’infrastruttura che ha lo scopo di monitoraggio delle prestazioni, rilevamento di errori di runtime o crash e facilitare il debugging

Nasce storicamente come strumento tecnico per monitoraggio e manutenzione e può essere formato da un sistema di file di registrazione  anche distinti che hanno finalità diverse come ad esempio:

• 1. monitoraggio tecnico del funzionamento del software o firmware.
  2. rilevazione e analisi di eventi di sicurezza
  3. tracciabilità delle comunicazioni con sistemi terzi
  4. controllo delle modifiche a livello strutturale o dati
  5. tracciabilità degli interventi tecnici
  6. tracciabilità di eventi fisici o elettromedicali.

2. Audit Trail (La “Traccia di Responsabilità”): è un registro immutabile e sicuro che traccia le azioni degli utenti che hanno un impatto sulle prestazioni del disposiivo, sulla sicurezza del paziente e sull’integrità dei dati . Non è semplicemente una registrazione di eventi, ma un meccanismo di responsabilità, controllo e ricostruzione delle attività. Il suo scopo è garantire che ogni azione rilevante possa essere attribuita a un soggetto, collocata nel tempo e collegata ai dati o ai parametri coinvolti

Deve quindi garantire: identificazione del soggetto (utente o sistema) che ha eseguito l’azione, data e ora affidabili, descrizione dell’evento, eventuale variazione dei dati (prima/dopo) e può anch’esso essere formato da un sistema di file di registrazione che hanno finalità diverse come ad esempio :

• • tracciabilità delle attività clinicamente rilevanti
  • responsabilità e tracciabilità delle azioni degli utenti.

Sebbene condividano spesso gli stessi meccanismi tecnici di base, file di log e audit trail non sono sinonimi. Il primo è orientato alla gestione del sistema, il secondo alla dimostrazione della conformità e della corretta gestione delle attività. Un audit trail può essere costruito all’interno di un file di Log, ma con regole più stringenti in termini di struttura, integrità e accesso.

La progettazione di un Audit Trail e dei file di Log non può ovviamente prescindere dall’architettura del dispositivo medico software

Nei SaMD è comune la registrazione su PC o server: ciò consente maggiore capacità di archiviazione, facilità di backup, integrazione con sistemi centralizzati di monitoraggio e accesso remoto per supporto e manutenzione

Nei SiMD, invece, la registrazione avviene spesso su memoria locale del dispositivo (flash interna, EEPROM, schede SD). Questo garantisce la disponibilità delle informazioni anche in assenza di connettività e permette di analizzare eventi critici direttamente sul dispositivo: ad esempio in caso di malfunzionamento o incidente. In questo caso spesso i file di registrazioni sono vincolati a risorse hardware definite: memoria limitata, capacità di scrittura ridotta, assenza di connettività continua, requisiti di real-time

Quadro normativo e Regolatorio

Il termine “Audit Trail” non è sempre esplicitamente menzionato nella normativa sui dispositivi medici; tuttavia, numerosi regolamenti e standard ne rendono la presenza di fatto necessaria per garantire tracciabilità, controllo e integrità dei dati

Nel contesto europeo, l’Audit Trail è spesso un requisito implicito ma sostanziale, necessario per dimostrare conformità alle richieste di sicurezza, qualità e gestione del rischio. Ad esempio Il Regolamento (UE) 2017/745 non impone esplicitamente un “Audit Trail”, ma richiede: tracciabilità lungo il ciclo di vita del dispositivo, documentazione delle attività rilevanti, gestione e analisi degli incidenti, sorveglianza post-commercializzazione; mentre la normativa di riferimento per la Cybersecurity IEC 81001-5-1 evidenzia la necessità di: registrare eventi di sicurezza, monitorare accessi e modifiche, garantire integrità delle informazioni

Nel contesto FDA, in particolare con il 21 CFR Part 11, l’obbligo di registrazioni elettroniche sicure e tracciabili rende l’Audit Trail un requisito esplicito

Quindi per i fabbricanti di dispositivi medici software che operano su mercati internazionali, la progettazione di un Sistema di registrazione non è quindi una scelta tecnica facoltativa, ma una componente strategica di conformità regolatoria

Progettazione di un Sistema di Registrazione

La realizzazione di un corretto ed efficace Sistema di Registrazione non deve essere progettato come un semplice elenco di eventi da documentare ma come una misura di controllo definita attraverso un’analisi basata sul rischio.

Un approccio sistematico, coerente con la ISO 14971, consente di evitare due errori opposti:

• registrare troppo (sovraccarico, inefficienza, inutilità analitica)
• registrare troppo poco (perdita di tracciabilità su eventi critici)

Tale sistema deve :

• derivare dall’analisi del rischio
• essere proporzionato alla criticità del dispositivo
• essere protetto contro alterazioni
• essere verificato e validato come qualsiasi altra funzione software critica

Non è un componente aggiuntivo finale, ma un elemento architetturale che deve essere definito fin dalle prime fasi di progettazione

Identificazione degli eventi rilevanti

Il primo passo consiste nell’individuare quali siano gli eventi di cui è indispensabile tenere traccia perché ad esempio : clinicamente significativi, rilevanti ai fini regolatori, critici per la sicurezza informatica, necessari per la ricostruzione di eventuali incidenti

La determinazione di tali eventi significativi dovrebbero essere il frutto di un processo ingegneristico multidisciplinare che dovrebbe coinvolgere:

• Analisi dei Rischi dove l’individuazione di situazioni da tenere sotto controllo é strettamente collegata al rischio e al danno che tali situazioni possono comportare durante l’esecuzione delle operazioni connesse al Dispositivo Medico
• Threat Analysis (Cybersecurity): dove occorre identificare eventi che potrebbero indicare un attacco o una vulnerabilità in termini di Sicurezza informatica
• Analisi dei Processi Clinici : che permettono di individuare i “punti decisionali” critici, ovvero quei momenti in cui, ad esempio, un’azione umana modifica l’esito clinico del dispositivo
• Sorveglianza Post-Market (PMS) e Feedback :  attraverso l‘analisi dei reclami o degli incidenti avvenuti su dispositivi simili (o versioni precedenti)
• Requisiti di Compliance : dove é necessario verificare gli standard applicabili per garantire che tutti gli eventi richiesti per la conformità (es. installazione aggiornamenti, manutenzione, gestione accessi) siano inclusi nel sistema di registrazione

Contenuti dei documenti di registrazione

Una volta definiti gli eventi rilevanti attraverso l’approccio risk-based, occorre stabilire quali informazioni minime debbano essere registrate affinché il documento di registrazione abbia reale valore tecnico, regolatorio e probatorio.

Un documento  efficace non deve limitarsi a registrare che “qualcosa è successo”, ma deve permettere di ricostruire in modo oggettivo l’evento.

In particolare un Audit Trail adeguato deve rispondere a una domanda semplice ma cruciale: “Sono in grado, leggendo il file di registrazione, di ricostruire con certezza cosa è accaduto, chi lo ha fatto e con quale impatto”?

Ogni record dovrebbe contenere almeno alcune informazioni minime essenziali :

• Identificativo univoco dell’evento
• Data e ora affidabili (timestamp sincronizzato)
• Identificazione dell’utente o del sistema che ha eseguito l’azione
• Descrizione chiara dell’evento : Il livello di dettaglio deve essere proporzionato alla criticità dell’evento, in coerenza con la gestione del rischio
• Versione del software o della configurazione attiva

Oltre al contenuto informativo, il record deve garantire anche una struttura del suo formato che permetta: record organizzati per campi definiti ; modalità di ricerca e filtraggio ; esportazione controllata

Ciclo di Vita delle Registrazioni

Un Sistema di Registrazioni efficace non si esaurisce nella definizione del contenuto del record. È necessario governarne l’intero ciclo di vita, dalla generazione alla conservazione, fino all’eventuale cancellazione o archiviazione. Tale gestione deve garantire

• scrittura automatica e protetta e, soprattutto nel caso degli Audit Trail una registrazione automatica e non disattivabile degli eventi critici
• protezione contro modifiche o sovrascritture non autorizzate
• sincronizzazione temporale affidabile (timestamp coerenti)
• conservazione affidabile attraverso meccanismi di back up e con una gestione che sia strettamente vincolata al Regolamento (UE) 2016/679 (GDPR), con particolare riferimento ai principi di minimizzazione e limitazione della retention
• politiche controllate di sovrascrittura o cancellazione
• accesso sicuro e disponibilità nel tempo

Il sistema di registrazione non è solo un insieme di record: è un sistema informativo che deve essere governato con lo stesso rigore di qualsiasi altra funzione critica del dispositivo. Non dovrebbe dipendere da azioni manuali dell’utente ma deve essere una funzione intrinseca del sistema

Gestione dello spazio

La generazione continua di registrazioni, se non adeguatamente governata, può compromettere le prestazioni e la stabilità del software medico. Tuttavia, nei dispositivi SaMD e SiMD, la necessità tecnica di liberare spazio non può mai andare a discapito della disponibilità dei dati. Gestire lo spazio significa, dunque, implementare strategie di rotazione e archiviazione che proteggano l’integrità deli file di registrazione , garantendo che ogni operazione di cancellazione sia sicura, tracciata e conforme ai tempi di conservazione previsti dalle normative.

In particolare la cancellazione deve

• Essere formalmente regolamentata: definita all’interno delle procedure operative del Sistema di Gestione della Qualità (SGQ)
• Essere tracciata: ogni operazione di eliminazione o rotazione dei file deve generare a sua volta un record di log (meta-log), che attesti l’autorizzazione e l’avvenuta esecuzione della pulizia

In particolare nei dispositivi embedded (SiMD) o in ambienti con risorse limitate, può essere necessario adottare meccanismi circolari (ring buffer), politiche FIFO (First In – First Out), soglie di saturazione con alert. I file di Log tecnici seguono generalmente policy di rotazione basate su parametri di sistema (es. saturazione spazio disco o finestre temporali di 30/90 giorni)

In questi casi è fondamentale garantire che: la sovrascrittura sia controllata, gli eventi critici non vengano persi prematuramente e sia possibile esportare i file prima della cancellazione automatica. La perdita non controllata di eventi può compromettere la ricostruzione delle situazione critiche

Validazione del Sistema di registrazione 

Un Sistema di registrazione non validato è, di fatto, inutilizzabile in caso di audit regolatorio o contenzioso.

La sua validazione deve dimostrare non solo che “scrive”, ma che scrive ciò che serve, quando serve, in modo affidabile e dimostrabile. La validazione non può essere limitata alla verifica della semplice “scrittura del file”, ma deve dimostrare che il sistema:

1. registra tutti gli eventi critici definiti nei requisiti e nell’analisi dei rischi
2. garantisce integrità, completezza e non alterabilità dei dati
3. assicura tracciabilità coerente lungo l’intero ciclo di vita del software

In particolare deve essere opportunamente verificata :

1. la corretta generazione degli eventi (trigger corretti)
2. la correttezza e completezza dei campi registrati
3. la  sincronizzazione temporale (timestamp affidabile)
4. la protezione da modifica o cancellazione non autorizzata
5. la coerenza tra azione utente e record generato
6. la gestione corretta in condizioni di errore (es. crash, perdita connessione)

Export delle registrazioni

L’estrazione dei dati dal sistema di registrazione è il momento in cui la tracciabilità diventa fruibile per autorità regolatorie, organismi notificati o team di assistenza tecnica. Tuttavia, le modalità di export variano significativamente a seconda della natura del dato trattato.

1.  negli Audit Trail prevale il concetto di Integrità e Leggibilità in quanto il loro principale compito é quello di fornire una prova legale e clinica. Devono essere standardizzati e “Human Readable” (es. PDF/A, XML, JSON) . Il file esportato dovrebbe includere metadati di sicurezza (come un hash o una firma elettronica) per garantire che il documento non sia stato manipolato dopo l’estrazione. Deve permettere filtri precisi (per data, utente o tipo di evento) per rispondere a specifiche richieste ispettive senza violare la privacy di dati non pertinenti
2.  Nei log di Sistema prevale il concetto di Diagnostica e Analisi Massiva in quanto l’export dei log tecnici serve a ricostruire il comportamento del software. Spesso esportati come testo semplice (.txt, .log) o compressi (.zip, .gz) per gestire grandi volumi di dati, Devono essere facilmente importabili in strumenti di analisi esterna per il debugging o l’analisi delle performance

Mentre l’export dei log è una procedura di supporto tecnico, l’export dell’Audit Trail è una procedura di compliance. Un sistema di export efficace deve garantire che il dato estratto sia speculare a quello registrato, senza perdite di informazioni critiche durante la conversione

Analisi delle registrazioni

L’analisi delle registrazioni è un’attività fondamentale per trasformare i dati registrati dall’Audit Trail in informazioni utili a supporto di controllo, vigilanza e sicurezza. Essa non si limita alla lettura di eventi, ma richiede tecniche sistematiche di interpretazione, correlazione e contestualizzazione . Un’analisi  ben strutturata migliora la capacità di risposta agli incidenti, supporta la vigilanza post‑commercializzazione, potenzia i processi di cyber‑defense, riduce rischio clinico e compliance gap

In sintesi, le registrazioni non sono solo dati storici, ma strumenti diagnostici e predittivi fondamentali per la qualità, la sicurezza operativa e regolatoria dei dispositivi medici software

le tipologie di analisi che devono essere garantite possono essere:

1. Analisi delle registrazioni per incidenti : Quando si verifica un malfunzionamento o un evento avverso, i file rappresentano una fonte primaria di evidenza per ricostruire la sequenza temporale degli eventi, identificare cause tecniche o operative, determinare responsabilità di sistema o dell’utente, supportare root‑cause analysis. I file  consentono di evidenziare pattern, errori sistematici o sequenze anomale che altrimenti non emergerebbero dall’osservazione diretta del software o dell’hardware
2. Analisi dei log per Post‑Market Surveillance (PMS) : Nel contesto della sorveglianza post‑commercializzazione, l’analisi delle registrazioni diventa uno strumento proattivo per: monitorare l’uso reale del dispositivo in campo, identificare trend di performance o criticità ricorrenti, evidenziare segnalazioni non formalizzate di malfunzionamenti, correlare eventi operativi con reclami o segnalazioni. La raccolta e l’interpretazione sistematica dei file alimentano i processi di PMS e PMCF, contribuendo a migliorare la sicurezza e l’efficacia del dispositivo nel tempo
3. Analisi dei log per la Cybersecurity : In ambito cybersecurity, l’analisi delle registrazioni è un pilastro per: rilevare attività anomale (es. accessi insoliti), identificare compromissioni (es. pattern tipici di attacco), correlare eventi da diverse fonti (network, applicazione, sistema).Un’analisi accurata può evidenziare, ad esempio, sequenze di accessi falliti, escalation di privilegi o attività sospette tra più log correlati

Una buona analisi si basa su:

• Normalizzazione : Uniformare formati di file diversi per facilitare correlazione e comparazione
• Correlazione degli eventi : Mettere in relazione eventi provenienti da più livelli (applicazione, sistema, autenticazione) per costruire timeline coerenti
• Identificazione di pattern : Rilevare comportamenti anomali rispetto ai trend consolidati
• Contestualizzazione : Associare eventi a condizioni operative, profili utente o configurazioni specifiche

Aspetti di Cybersecurity delle registrazioni

In un dispositivo medico software (SaMD/SiMD), i file di registrazione non sono solo documenti, ma asset critici. Se un hacker o un utente malintenzionato riuscisse a modificare l’Audit Trail, potrebbe nascondere azioni nocive o alterare la storia clinica di un paziente senza lasciare traccia.

La sicurezza informatica deve coprire l’intero ciclo di vita del dato, dalla sua generazione sul dispositivo (attività di registrazione) fino alla sua fuoriuscita verso l’esterno (attività di export) garantendo di continuo gli aspetti di Riservatezza, Integrità e Disponibilità.

In particolare é necessario prendere in considerazione minacce quali :

1. Modifica o cancellazione dolosa delle tracce di Audit Trail che portano a Impossibilità di ricostruire incidenti, perdita di conformità e responsabilità legale non attribuibile
2. Consultazione dei file da parte di soggetti privi di privilegi che può comportare Violazione della Privacy (GDPR) e fuga di dati sensibili sulla salute dei pazienti.
3. Inserimento di falsi record nel sistema di registrazione che può indurre un Depistaggio delle analisi tecniche e generazione di falsi allarmi o diagnosi distorte
4. Generazione massiva di record inutili per riempire il disco che comporta Blocco del dispositivo medico (Crash) e indisponibilità del software durante un intervento critico
5. Intercettazione dei dati durante il trasferimento esterno che può portare alla Fuga di proprietà intellettuale o dati clinici verso terzi malintenzionati.

GRAZIE PER L’ATTENZIONE