$$\rightleftharpoonup{xx}$$
$$\longleftharp{xx}$$,
$$\longrightharp{xx}$$,
Motivazione per una cartella clinica elettronica integrata e un database di ricerca
La ricerca clinica si basa sulla disponibilità di dati di alta qualità, indipendentemente dal fatto che per l'analisi vengano utilizzati metodi statistici classici o tecniche di Machine Learning (ML)1,2. Oltre ai dati di routine (ad esempio, dati demografici, di laboratorio e sui farmaci), sono richiesti dati specifici del dominio (ad esempio, dati rilevanti per il trapianto) con elevata granularità3,4. Tuttavia, l'assistenza di routine in molti ospedali universitari viene eseguita con sistemi informativi ospedalieri (HIS) che non consentono né la raccolta sistematica di dati specifici della ricerca né una facile estrazione dei dati di routine5,6,7. Di conseguenza, i ricercatori clinici creano database di ricerca specifici, che presentano una varietà di problemi tra cui il complesso processo di creazione di un database, l'immissione manuale dei dati, i problemi di protezione dei dati e la manutenzione a lungo termine (Tabella 1). La quantità limitata di dati, i dati mancanti e le incongruenze sono un problema importante per la ricerca clinica in generale e impediscono l'uso delle tecnologie ML8,9,10,11,12,13. Questi database di ricerca autonomi sono solitamente focalizzati su determinati aspetti della malattia o del paziente, non collegati ad altri database e spesso interrotti dopo un certo periodo, con conseguente "silos di dati" inaccessibili. In definitiva, i dati di alta qualità e a lungo termine su vari aspetti della malattia sono scarsi. Nell'era della medicina digitale vi è una crescente necessità di una cartella clinica elettronica completa (EHR)7,14,15, che consenta una facile documentazione dei dati specifici del dominio e la raccolta automatizzata di dati di routine dai sistemi di assistenza ospedaliera e ambulatoriale.
Queste considerazioni generali si applicano anche alla medicina dei trapianti16. Pertanto, una documentazione completa della storia medica del paziente, compresi tutti i trattamenti ospedalieri e ambulatoriali, i dati di routine clinica e i dati specifici del trapianto è necessaria per il successo delle cure di follow-up17,18. Poiché gli HIS ordinari sono statici e focalizzati sul trattamento ospedaliero, non possono integrare i dati specifici del trapianto, come i dati del donatore, i tempi di ischemia fredda e i dati sugli antigeni leucocitari umani (HLA). Tuttavia, questi dati sono un prerequisito di base per la ricerca sui trapianti19,20,21,22 e per l'assistenza clinica a lungo termine. Mentre la degenza ospedaliera iniziale di solito è di sole 1-2 settimane e i processi e gli esiti precoci dopo il trapianto di rene sono paragonabili tra molti centri di trapianto, l'assistenza post-trapianto per tutta la vita è complicata e manca di un approccio strutturato comune. Ciò motiva un EHR integrato e un database di ricerca per catturare il percorso del paziente post-trapianto per tutta la vita. 23 anni
Al fine di integrare queste funzionalità per la cura di routine e la ricerca di KTR, è stato sviluppato un EHR chiamato "TBase" con l'idea che l'uso di routine per la cura post-trapianto creerà un database di ricerca unico con la massima qualità dei dati (Tabella 2).
Design e Architettura
TBase si basa su una tipica architettura client-server. Per lo sviluppo sono stati utilizzati i componenti e gli strumenti di SAP High Performance Analytic Appliance extended application advanced (SAP HANA XSA). Basato sulle più recenti tecnologie web Hypertext Markup Language 5 (HTML5), l'EHR è stato sviluppato e testato per Google Chrome Engine. Questo motore web è utilizzato da Chrome e dal browser Microsoft Edge e consente di utilizzare l'EHR nei browser Web più utilizzati24 senza la necessità di installazione locale. La tecnologia applicata consente un responsive web design e permette di utilizzare l'EHR web-based su tutti i dispositivi (PC, tablet, smartphone). L'innovativa piattaforma di sviluppo ad alte prestazioni è composta da vari componenti (Web IDE, UI5 e HANA DB) e ci ha permesso di implementare rapidamente il progetto EHR TBase con strumenti software all'avanguardia (Figura 1).
Per la rappresentazione dei dati dei pazienti, è stata implementata una semplice struttura a tabella per un design intuitivo e autoesplicativo dell'EHR. Ad esempio, la tabella del paziente con il PatientID come chiave primaria si trova al centro della struttura della tabella. Quasi tutte le tabelle (ad eccezione delle singole sottotabelle) sono collegate a questa tabella centrale tramite PatientID (Figura 2).
La Figura 3 mostra parte della struttura della tabella di TBase e i tipi di dati utilizzati in modo più dettagliato. L'utente finale può accedere ai campi dati tramite interfaccia utente grafica (GUI), per la quale un esempio è mostrato nella Figura 4.
Questo EHR contiene tutti i dati attuali del paziente e viene utilizzato per le cure ambulatoriali di routine. Importanti dati clinici di routine (ad esempio, dati di laboratorio, risultati medici, radiologia, microbiologia, virologia e patologia, dati ospedalieri, ecc.) vengono importati direttamente in TBase tramite interfacce standardizzate (ad esempio, sulla base di Health Level Seven (HL7) - uno standard per la comunicazione digitale nel settore sanitario25). I dati specifici del trapianto come i tempi di ischemia fredda, i dati dei donatori, i dati HLA e le note di follow-up, i segni vitali, i referti medici e l'elenco dei farmaci vengono inseriti dagli utenti tramite GUI nell'EHR. Prima che i dati vengano trasferiti al database, viene eseguito un controllo di plausibilità automatizzato per il rilevamento tempestivo di un'immissione errata dei dati che fornisce la possibilità di correggere immediatamente. Inoltre, la convalida dei dati prende parte durante la routine clinica in cui gli utenti clinici scrivono regolarmente rapporti e lettere a pazienti e medici. Queste lettere devono fornire dati corretti (ad esempio, su farmaci, valori di laboratorio e osservazioni cliniche) per ulteriori piani di trattamento e farmaci. Di conseguenza, medici e pazienti convalidano e correggono costantemente i dati clinici nella loro pratica quotidiana, un processo che si traduce in un'elevata qualità dei dati. Se i dati vengono immessi tramite API (Application Programming Interface) o altre interfacce, i controlli di plausibilità vengono eseguiti nel back-end in modo simile ai controlli di plausibilità nel frontend.
Frontend (GUI)
Per implementare il frontend, viene utilizzato il framework UI5. Questo framework fornisce una vasta libreria per gli elementi frontend e una varietà di funzionalità aggiuntive come il multilinguismo e le librerie grafiche per la visualizzazione dei dati. Attualmente, gli elementi frontend TBase vengono visualizzati in inglese o tedesco a seconda dell'impostazione della lingua del browser.
Un'interfaccia master-detail viene utilizzata per il frontend per garantire una struttura della pagina semplice e intuitiva. La parte superiore della pagina di visualizzazione è costituita da singole schede per le pagine di dettaglio (dati di base, dati medici, dati di trapianto, ecc.). Questa parte master rimane invariata indipendentemente dalla pagina di dettaglio mostrata di seguito (Figura 4). La visualizzazione dettagliata di ogni pagina consente una facile panoramica sull'argomento della pagina.
Per la manipolazione dei dati, l'EHR ha diversi livelli di diritti utente ("lettura", "scrittura", "eliminazione" e "amministratore"). C'è un livello di "modifica" oltre al livello di "visualizzazione", che può essere attivato solo da utenti con diritti superiori a "lettura". Se l'utente ha il diritto di scrivere, tutti i campi di input per l'inserimento dei dati vengono attivati e possono essere compilati con i dati. Gli utenti con diritti di "eliminazione" possono eliminare i dati tramite un pulsante corrispondente, ma solo dopo la conferma attraverso una finestra pop-up.
Struttura e interfacce del database
Lo sviluppo di TBase viene eseguito nel database di sviluppo. Test approfonditi e dettagliati di tutte le modifiche al software, come le nuove funzionalità, vengono eseguiti nel database di garanzia della qualità. Gli aggiornamenti software che superano i controlli di qualità vengono trasferiti al sistema live. Ai fini della ricerca, il sistema live viene copiato nel database di replica, che può essere interrogato tramite interfacce standard ODBC (Open Database Connectivity) (ad esempio, tramite il software open source R Studio). Poiché non esiste una connessione diretta tra la replica e il sistema live, i dati nel sistema live sono protetti da danneggiamento, perdita o manipolazione dei dati. Questa struttura modulare e la netta separazione dei quattro database (sviluppo, garanzia della qualità, sistema live e database di replica), che sono adattati alle esigenze specifiche di sviluppatori, ricercatori e medici, facilita la manutenzione e la protezione dei dati dei dati sensibili dei pazienti.
L'EHR è completamente integrato nell'infrastruttura dati di Charité e si basa su diverse interfacce per l'importazione di dati da varie fonti di dati. L'interfaccia con l'HIS importa tutti i dati rilevanti come dati amministrativi, esami, farmaci, risultati di laboratorio e lettere di dimissione. Questa interfaccia collega entrambi i sistemi tramite un'area di staging. Qui, tutti i nuovi dati (delta dei dati) vengono trasferiti dall'HIS al TBase in tempo reale. I pazienti vengono identificati tramite un numero di paziente o un numero di caso e i dati corrispondenti dall'HIS vengono importati (se non già disponibili in TBase).
Per i pazienti ambulatoriali, il nostro partner di laboratorio fornisce i risultati di laboratorio tramite messaggi HL7. Questi vengono distribuiti in un'area condivisa nel sistema di laboratorio e prelevati tramite un'interfaccia HL7 e importati nell'EHR. Per la comunicazione bidirezionale e lo scambio di dati con KTR (tramite app per smartphone) e nefrologi domestici, è stata implementata un'interfaccia HL7 Fast Healthcare Interoperability Resource (HL7 FHIR)26. Questa interfaccia garantisce interoperabilità e flessibilità per uno scambio di dati sicuro con altre fonti di dati (ad esempio, Eurotransplant, app per i pazienti) in futuro.
Gestione degli utenti e protezione dei dati
TBase si basa sulla gestione degli utenti a livello di applicazione. Pertanto, l'utente può accedere solo al frontend dell'applicazione, ma non al database stesso. Come descritto sopra, è stato scelto un concetto di autorizzazione in quattro fasi, riservando la gestione degli utenti a coloro che dispongono di diritti amministrativi. Gli amministratori utilizzano un'applicazione "Identity Management Console" per aggiungere nuovi utenti dal pool di utenti Charité per l'applicazione TBase e per mantenere i relativi diritti utente (Figura 5). La maggior parte degli utenti può accedere a tutti i pazienti nel database. Tuttavia, è possibile limitare l'accesso per utenti specifici come i monitor dello studio a un gruppo di pazienti.
Utilizzando la piattaforma di database in memoria commerciale, viene utilizzata una tecnologia di database sicura che protegge i dati con strategie quali l'autorizzazione a livello di applicazione, il Single Sign-On (SSO), il protocollo MIT-Kerberos e il linguaggio SAML (Security Assertion Mark-up Language). La piattaforma protegge la comunicazione, l'archiviazione dei dati e i servizi applicativi utilizzando le più recenti tecniche di crittografia e test. Tutti gli sviluppi sul database sono controllati da autorizzazioni. Ciò garantisce la sicurezza dei dati fin dalla progettazione ad alto livello. Inoltre, tutti i dati sono conservati dietro il firewall certificato Charité. In conformità con l'ultimo regolamento generale sulla protezione dei dati dell'Unione europea (GDPR dell'UE) è stato implementato un solido concetto di protezione dei dati, inclusi diagrammi di flusso dei dati, valutazione del rischio di protezione dei dati (DSFA) e concetto di autorizzazione. Tutti i documenti sono redatti in un elenco delle procedure dell'Ufficio per la protezione dei dati charité.