Come validare sistemi informativi clinici per studi di ricerca: guida AISIS

La validazione dei sistemi informativi clinici per l’uso in contesti di ricerca rappresenta una sfida crescente per le organizzazioni sanitarie.

Con l’aumento dell’integrazione tra sistemi di gestione clinica (EMR/EHR) e piattaforme dedicate alla ricerca (eCRF), diventa fondamentale garantire che i dati raccolti per scopi clinici possano essere utilizzati in modo affidabile e conforme alle normative negli studi clinici, mantenendo integrità, tracciabilità e qualità dell’informazione.

Evoluzione dei sistemi di raccolta dati per la ricerca clinica

La ricerca clinica, nel momento in cui entra nelle strutture sanitarie (dove è sempre stata presente…), necessita di supporto sistematico sia sul piano organizzativo/sostanziale che su quello formale per la raccolta dei dati necessari per le sue finalità.

Questa esigenza ha fatto emergere, nella storia, strumenti quali le CRF (Case Report Forms: modulistica standardizzata cartacea per la rilevazione dei dati di singoli casi arruolati in progetti di ricerca), poi divenute rapidamente eCRF (Electronic Case Report Forms). Questi strumenti, per quanto semplici e mirati alle esigenze specifiche di singoli studi, in molte realtà sono stati i primi strumenti di rilevazione elettronica di dati clinici, anche anni prima della introduzione delle vere e proprie cartelle cliniche informatizzate.

L’Electronic Case Report Form (eCRF) è definito da FDA (Food and Drug Administration, ente federale degli USA per il controllo delle attività sanitarie e in particolare di gestione del farmaco) come “un registro elettronico verificabile delle informazioni che generalmente viene riportato al promotore su ciascun soggetto della sperimentazione, secondo un protocollo di indagine clinica.”

Alcuni di questi strumenti hanno in parte, e a volte impropriamente, assolto anche all’esigenza di raccolta dati a supporto dell’attività clinica. In Italia un esempio emblematico di questa transizione da sistema di rilevazione dati per attività di ricerca verso strumento di vero e proprio supporto dell’attività clinica è stato lo studio Margherita3, dell’Istituto Mario Negri, che ha fornito a supporto di uno studio comparativo tra le Terapie Intensive di tutta Italia uno strumento di rilevazione dati (omonimo) rivelatosi sufficientemente completo da poter essere “interpretato” come Cartella Clinica Informatizzata (adozione che ha portato poi negli anni a confusione di ruoli, e ad una difficoltà di questo settore di transitare verso soluzioni di cartella vera e propria). Questa adozione ha portato negli anni a confusione di ruoli e destinazioni d’uso, che ha peraltro indotto ad intraprendere una transizione di questa soluzione verso una soluzione di cartella vera e propria, a conferma del fatto che una sovrapposizione “poco chiara” tra i due ambiti risulta poco sostenibile ed opportuna.

Il settore delle eCRF ha visto nel tempo la nascita di piattaforme commerciali ed anche in anni più recenti alla crescita di soluzioni nate in contesti pubblici/cooperativi quali la soluzione RedCap (Vanderbilt University; https://redcap.vumc.org/ ).

La principale spinta verso l’evoluzione di queste soluzioni è nata dal mondo delle sponsorizzazioni degli studi clinici (in particolare del mondo Pharma) come conseguenza del graduale stringersi dei vincoli normativi legati alla documentazione degli studi da parte degli enti regolatori (in particolare FDA[1] [2]ed EMA – European Medicines Agency [3]). Garantire una rispondenza a questi vincoli ha richiesto un sempre maggiore controllo

L’approccio alla base delle CRF e delle eCRF assume che la raccolta dati avvenga tramite trascrizione. Come alternativa si pone l’opportunità di raccolta tramite integrazione con sistemi di origine, anche se il tema è discusso in quanto si apre il tema dei dati di origine, o “source document”, o “eSource” in caso di origine nativamente digitale.

Il documento di orientamento eSource della FDA, scritto nel 2013[4], identifica cinque potenziali metodi di acquisizione dei dati di origine (vedi Figura 1 ):

• Inserimento diretto dei dati nell’eCRF
• Trascrizione dei dati da fonti cartacee o elettroniche all’eCRF
• Trasmissione automatica dei dati da dispositivi o strumenti direttamente all’eCRF
• Trasmissione dei dati da strumenti di Patient Reported Outcome (PRO) all’eCRF
• Trasmissione diretta dei dati dal sistema di Cartella/Fascicolo Clinica Elettronica (EMR/EHR) all’eCRF

Questa classificazione introduce scenari con confini differenti sulla gestione digitale del dato.

I primi due scenari vedono l’eSource nella eCRF, mentre gli ultimi tre scenari vedono una estensione della eSource verso sistemi di origine, nativamente digitali, slegati dalla eCRF.

Normative e linee guida per i sistemi informativi in ambito sanitario

L’ultimo scenario, in particolare, vede la trasmissione automatica dei dati da Cartella/Fascicolo elettronico verso la eCRF, mediato da sistema/processo denominato EDC (Electronic Data Capture). Questa modalità presenta la peculiarità di ipotizzare una continuità tra sistemi con destinazione d’uso prettamente clinica (EMR/EHR) e sistemi destinati esclusivamente e nativamente all’attività di ricerca (eCRF).

Quest’ultimo scenario, inizialmente solo ipotizzato e raramente implementato sia per problematiche di interoperabilità tra sistemi [5], sia per la scarsa diffusione di reali soluzioni di EMR/EHR, diviene ora gradualmente sempre più frequente per tre motivi:

• Diffusione di EMR/EHR sempre più strutturati, in grado di assolvere alla funzione di eSource per gran parte dei dati rilevati nello studio
• Nascita di standard di comunicazione tra i due ambiti (differenti da quelli usato normalmente in sanità digitale), quali CDISC ODM e OMOP[6]
• Diffusione della metodologia “Real World Data” nell’ambito degli studi clinici[7]

Di interesse anche una evoluzione del settore EMR che vede la nascita e diffusione di soluzioni di cartella informatizzata che includono, nello strumento clinico, soluzioni di gestione eCRF fondendo di fatto i due ambiti e facendo venire meno il layer di EDC.

L’avanzare di questo scenario di interazione tra sistemi dedicati ai due ambiti pone l’attenzione sulla rispondenza a normative / linee guida differenti, e conseguenti necessità di attestazione di tale rispondenza.

Questo aspetto di “cross-rispondenza alle normative dei due settori”, oggetto del presente contributo, dovrà sicuramente essere integrato in future analisi (futuri gruppi di lavoro AISIS) da linee guida sulle modalità di interazione sia sul piano tecnico che di processo/semantico.

Figura 1 – Scenari di Rilevazione del Dato per Attività di Ricerca – Interazioni con sistemi di Gestione Clinica

Normative e linee guida per i sistemi informativi in ambito sanitario

Considerando in modo distinto i due settori: attività clinica e attività di ricerca, questi condividono entrambe la necessità di rispondere alle normative relativa al trattamento del dato personale: GDPR (in UE) o la HIPAA (negli Stati Uniti). In relazione a queste normative i due settori si pongono però in modo diverso:

• il settore clinico tradizionalmente pone particolari criticità in quanto i dati gestiti sui sistemi informativi di ambito clinico sono intrinsecamente originali, e nominali (in quanto legati alla gestione clinica del paziente). Queste due caratteristiche inquadrano i trattamenti come a rischio di perdita/alterazione dati, oltre che a rischio di violazione della confidenzialità del dato.
• il settore ricerca sfrutta normalmente sistemi su cui la rilevazione del dato è fatta o per trasposizione/copia da parte di operatori umani, o di copia tramite sistemi di interoperabilità (EDC); peraltro in ottica di minimizzazione del trattamento, quando possibile questa trasposizione viene fatta privilegiando l’anonimizzazione o pseudonimizzazione del dato. Conseguentemente, i trattamenti svolti in questi contesti presentano meno criticità in quanto la perdita ed alterazione del dato non compromette la versione originale dello stesso (che rimane tutelata sui sistemi clinici) e pone minore rischio di violazione della confidenzialità in quanto dati non direttamente riconducibili alla persona.

Framework metodologico per la validazione dei sistemi informativi clinici

Sui sistemi informativi in uso a supporto dell’attività clinica sempre più di frequente si applicano tutele alla sicurezza del paziente, in particolare nei casi di software Medical Device o IVD (SAMD: Software as a Medical Device; IVD: In Vitro Diagnostic Device), normati rispettivamente la MDR (Medical Device Regulation) e la IVDR (In Vitro Medical Device Regulation).

Sui sistemi informativi a supporto dell’attività di ricerca, si applicano invece normative e linee guida/requisiti differenti e variegati, spesso legati a contesti specifici o dettati da enti/agenzie specifiche. Le linee guida e requisiti più rilevanti traggono però il più delle volte ispirazione diretta o indiretta dalle linee guida GCP e GMP[8] (Good Clinical Practice e Good Manufacturing Practice), ampiamente adottate in ambito farmacologico e di sperimentazione di dispositivi medici. Queste, nell’ambito specifico del trattamento del dato si declinano nei principi ALCOA-C[9] (vedi seguito).

Negli scenari in cui tramite interoperabilità tra EMR ed eCRF o di inclusione di funzionalità di eCRF all’ìnterno dei sistemi di EMR, si crea continuità tra sistemi di gestione clinica (EMR, sistemi di rilevazione PROMs, e sistemi ad esso connessi) e sistemi di gestione dell’attività di ricerca. Viene quindi implicitamente esteso l’onere di rispondenza alla normative/linee guida relative all’ambito ricerca (tipiche della sola eCRF) anche agli eSource (EMR/EHR e sistemi di rilevazione PROMs).

I singoli attori del settore ricerca (es. gli sponsor privati degli studi clinici) e gli enti regolatori del settore richiedono quindi che nei contesti in cui sistemi quali gli EMR sono estesi all’utilizzo in attività di ricerca, questi siano sottoposti a processi di validazione rispetto a linee guida e requisiti originariamente orientati alle eCRF.

In particolare, EMA, con le sue recenti linee guida[10], definisce in modo chiaro:

• le linee guida di riferimento per i sistemi software di supporto all’attività di ricerca di competenza dell’ente
• le modalità di validazione di tali sistemi software

Il concetto di validazione ha in particolare lo scopo di verificare la rispondenza del sistema informativo adottato:

• alle esigenze di rilevazione del dato per lo specifico contesto di ricerca (che potrebbero non coincidere esattamente ed essere solo casi particolari della destinazione d’uso più generale del sistema software)
• ai principi di riduzione del rischio sul paziente
• ai principi di corretto trattamento del dato personale
• ai principi di corretto trattamento del dato finalizzato ad attività di ricerca

Le aziende sanitarie coinvolte nel gruppo di lavoro promosso da AISIS hanno affrontato la richiesta emergente di declinare operativamente un processo di validazione che attestasse la rispondenza dei sistemi per attività clinica (EMR e sistemi ancillari quali LIS, RIS, PACS, ecc.) alle linee guida richieste dai contesti di ricerca.

In particolare, sono stati presi in considerazione i processi di validazione rispetto alle linee guida EMA ed AIFA nell’ambito degli studi clinici farmacologici

Obiettivo del gruppo di lavoro è stato la definizione di:

• Un insieme di stakeholders coinvolti nel processo di validazione
• una metodologia di validazione, declinata in una procedura (SOP: Standard Operating Procedure)
• un insieme di modelli documentali e che consentano un approccio uniforme, coerente e definito su come e cosa sia necessario rilevare e documentazione nell’ambito del processo di validazione

Qualificazione secondo i principi Alcoa-C

La metodologia di validazione di sistema software sviluppata dal gruppo di lavoro, basata sulle linee guida EMA già citate, suddivide il processo in tre elementi:

• Qualificazione del
  • Produttore
  • Sistema Software
  • Installazione locale
• Analisi dei casi d’uso
• Analisi dei rischi

Lo step di qualificazione, che ha l’obiettivo di determinare la rispondenza ai principi ALCOA espressamente citati dalle linee guida EMA, delle caratteristiche oggettive di:

• Produttore – Manufacturer Qualification
• Sistema Software – System Qualification
• Installazione Locale – Installation Site Qualification

La checklist risultante, suddivisa appunto nei tre livelli citati, verifica la declinazione specifica dei principi di:

• Attributable
• Legible
• Contemporaneous
• Original
• Accurate
• Complete

Tali principi sono declinati nella checklist da due punti di vista:

• Caratteristiche tecniche di sistema
• Principi organizzativi / procedurali del produttore e dell’ente che governa l’installazione locale

Dal punto di vista del processo di validazione, gli step di qualificazione sopra descritti possono ricadere sui servizi ICT della struttura, in quanto semplice rilevazione di caratteristiche oggettive del sistema e della sua declinazione locale.

Validazione funzionale e analisi dei rischi

Come da linee guida EMA è necessario, inoltre, che il processo di validazione oltre alla verifica dei principi di qualificazione ALCOA-C, verifichi due altri ambiti:

• La rispondenza funzionale del sistema ai casi d’uso oggetto dell’attività di ricerca
• L’analisi dei rischi derivanti dall’adozione del sistema software
  • Per il paziente
  • Per il dato personale
  • Per il dato di ricerca

Validazione della rispondenza funzionale

Un sistema nativamente destinato all’attività di ricerca ha fondamentalmente uno o pochi casi d’uso, interamente orientati a tale attività. La loro individuazione e verifica con casi d’uso è quindi immediata e di semplice implementazione (es. verificare che una eCRF risponda alle esigenze funzionali di rilevazione dati, e loro estrazione/elaborazione finale).

Un sistema che nasce invece con finalità di gestione dell’attività clinica presenta i casi d’uso per l’attività ricerca come delle sotto-tipologie dei casi d’uso principali (es. la gestione di campioni acquisiti in ambito di studi clinici all’interno del LIS, richiede la definizione delle modalità di gestione di tali campioni, degli esiti, della loro estrazione e indirizzamento verso i destinatari per l’elaborazione nel contesto del progetto di ricerca).

È quindi necessario attuare un processo di verifica composto da:

• Identificazione dei casi d’uso per l’adozione del sistema di gestione clinica nel contesto di ricerca
• Identificazione dei test/verifiche funzionali necessari alla validazione della rispondenza funzionale
• Implementazione dei test/verifiche funzionali

Questi step richiedono il coinvolgimento attivo, per la loro valutazione, di un Gruppo di Lavoro composto da:

• Attori del settore ricerca, che possano declinare i casi d’uso del sistema clinico nel conteso specifico (es. ambito farmaceutico, ambito clinico specifico, ambito di coordinamento attività sanitarie)
• Attori del settore ICT clinico, che possano identificare le modalità di test/verifica del sistema stesso per la conferma della rispondenza funzionale al caso d’uso individuato dai colleghi del settore ricerca

Analisi dei rischi

Nell’ambito di ciascun caso d’uso individuato dal processo precedentemente descritto è necessario individuare i possibili rischi indotti con riferimento a:

• Sicurezza del paziente
• Sicurezza del dato
• Sicurezza del dato in relazione al suo utilizzo nella pratica di ricerca

È importante sottolineare come i primi due elementi, nel contesto dei sistemi destinati all’attività clinica, possono essere nativamente già verificati qualora sussista già (come auspicabile e prevedibile):

• Certificazione come MD o IVD: da questo deriva, assumendo che non si esca dalla destinazione d’uso dello stesso (cosa che non sarebbe ammissibile su un piano normativo) una verifica di sicurezza per il paziente già ampiamente verificata e documentata nel processo di certificazione (come da MDR, IVDR)
• Rispondenza a GDPR: qualsiasi sistema clinico in uso deve garantire la rispondenza ai principi di trattamento del dato della normativa europea, e ne consegue che, assumendo che i trattamenti in contesto di ricerca siano sotto-tipologie dei trattamenti clinici ordinari, la rispondenza generale si applichi anche al sotto-contesto di ricerca

Il processo di analisi dei rischi, qualora si considerino sistemi già in uso per l’attività clinica, si può pertanto limitare alla sola individuazione ed analisi dei rischi relativi alla gestione del dato per l’attività di ricerca.

Il processo di analisi dei rischi può trarre gli elementi principali dalle metodologie ampliamento consolidate nel settore del Rischio Clinico, quali FMEA-FMECA.

Elementi rilevanti di tali metodologie, incluse nel framework proposto, sono:

• Individuazione dei rischi
• Analisi dell’impatto
• Analisi della probabilità
• Definizione delle azioni di mitigazione

L’analisi dei rischi impone la presenza nel Gruppo di Lavoro di:

• Attori che abbiano familiarità con le metodologie di analisi del rischio (es. mutuati dai gruppi di valutazione del Rischio Clinico presenti della struttura)
• Attori che governano la metodologia di trattamento del dato per attività ricerca / qualità del dato

Implementazione del framework multidisciplinare

La metodologia proposta dal gruppo di lavoro promosso da AISIS nel contesto emiliano-romagnolo è un primo tentativo di declinare operativamente e metodologicamente i principi introdotti dalle linee guida EMA, mutuati dalle metodologie GCP e ALCOA-C.

Questa metodologia, incentrata sulla costituzione all’interno delle organizzazioni di un Gruppo di Lavoro Multidisciplinare Composto da:

• Attori dei settori di ricerca specifica (con competenza sui progetti oggetto di adozione)
• Attori del settore ICT a supporto della ricerca
• Attori del settore Trattamento del Dato per attività di ricerca / Metodologia della ricerca
• Attori del settore Metodologia di Valutazione del Rischio (es. Rischio Clinico)

La metodologia è già sperimentata nel contesto di ispezioni AIFA per siti di sperimentazione farmacologica di Fase I, ed ha trovato riscontri positivi sia in termini di terreno comune di comunicazione e condivisione metodologica, sia in termini di completezza informativa.

AISIS nell’arco del 2025 estenderà il gruppo di lavoro di sviluppo metodologico ad un insieme più ampio di organizzazione sanitarie (18 strutture sanitarie di tutta Italia, di cui 10 IRCCS) e attori privati del settore Software Sanitario, allo scopo di ottenere un consensus più solido sulla metodologia e consentirne una sperimentazione e validazione su scala nazionale.

Nota: SOP e Checklist risultato del Gruppo di Lavoro AISIS sono disponibili su richiesta inviando e-mail vicepresidenza@aisis.it

Note

[1] https://www.fda.gov/regulatory-information/search-fda-guidance-documents/part-11-electronic-records-electronic-signatures-scope-and-application

[2] https://www.fda.gov/regulatory-information/search-fda-guidance-documents/electronic-source-data-clinical-investigations

[3] https://www.ema.europa.eu/en/documents/regulatory-procedural-guideline/guideline-computerised-systems-and-electronic-data-clinical-trials_en.pdf

[4] https://www.fda.gov/media/85183/download

[5] Mats Sundgren, Wai Keong Wong, eSource Interoperability Between EHR and EDC, August 14, 2023 Applied Clinical Trials-08-01-2023, Volume 32, Issue 7/8

[6] Matsumura Y, Hattori A, Manabe S, Takeda T, Takahashi D, Yamamoto Y, Murata T, Mihara N. Interconnection of electronic medical record with clinical data management system by CDISC ODM. Stud Health Technol Inform. 2014;205:868-72. PMID: 25160311.

[7] Liu, F., Panagiotakos, D. Real-world data: a brief review of the methods, applications, challenges and opportunities. BMC Med Res Methodol 22, 287 (2022). https://doi.org/10.1186/s12874-022-01768-6

[8] https://www.ema.europa.eu/en/human-regulatory-overview/research-development/compliance-research-development/good-clinical-practice

[9] https://www.fda.gov/media/85183/download

[10] https://www.ema.europa.eu/en/documents/regulatory-procedural-guideline/guideline-computerised-systems-and-electronic-data-clinical-trials_en.pdf