Scegliere FHIR come modello dati per un Clinical Data Repository è molto rischioso. Vediamo perché.
Ritorno su un tema che ha suscitato molta curiosità e diverse domande. Ricordiamo cosa è FHIR, riportando cosa dice il sito HL7 – “FHIR is a standard for health care data exchange, published by HL7®” – ossia uno standard per lo scambio di dati. Esistono due modelli:
- Facade (facciata), in cui un sistema espone servizi per l’accesso e la scrittura di risorse FHIR, nel quale i dati possono avere qualsiasi formato;
- Repository (archivio), nel quale i dati vengono convertiti e memorizzati come risorse FHIR e resi accessibili tramite servizi.
Come sapete, molte regioni, sulla spinta di quanto il Ministero della Salute e il Dipartimento per la Trasformazione Digitale hanno definito per l’Ecosistema dei Dati Sanitari, previsto con il FSE 2.0, hanno deciso di basare i Clinical Data Repository delle Cartelle Cliniche Elettroniche e delle proprie infrastrutture EDS sul modello dati FHIR.
Ma perché nel titolo richiamo le sabbie mobili? Perché FHIR è uno standard che non è ancora consolidato. Guardiamo la mappa delle risorse della versione attuale, la 5.
Riporto, traducendo alla lettera, ciò che il sito HL7 indica. Le risorse contrassegnate da N sono “normative”, ossia sono state approvate con il processo normativo ANSI in una versione precedente e il loro contenuto può essere considerato stabile ed è stato “bloccato”, sottoponendolo alle regole di compatibilità inter-versione di FHIR. Le modifiche sono possibili, ma si prevede che siano poco frequenti e strettamente limitate.
Le altre sono identificate da un numero (alla destra) che indica il livello di maturità, in cui zero è il più basso, 5 il più alto. Sono quasi tutte, tranne 4, definite come Trial Use, i cui contenuti sono stati ben revisionati e gli autori li considerano pronti per l’uso nei sistemi di produzione. Sono state sottoposte a votazione e approvate come standard ufficiale. Tuttavia, non hanno ancora visto un uso diffuso in produzione nell’intero spettro di ambienti in cui sono destinate a essere utilizzati. In alcuni casi, potrebbero esserci problemi noti documentati che richiedono esperienza di implementazione per determinare le soluzioni appropriate. Le versioni future di FHIR potrebbero apportare modifiche significative ai contenuti di Trial Use che non sono compatibili con i contenuti pubblicati in precedenza.
Come potete vedere voi stessi, nell’ambito clinico, c’è una sola risorsa che ha raggiunto lo status normativo: Observation. Tutte le altre variano dallo 0 al 5. Risorse importanti come AllergyIntolerance (3), AdverseEvent (2), CarePlan (2), CareTeam (2), RiskAssessment (2) sono tra il 3 e il 2. Stessa cosa anche per alcune risorse di base, importanti, come Task (3), Appointment (2), Schedule (3), EpisodeOfCare (2).
Ma quale modifiche può avere una risorsa? Viene garantita la retrocompatibilità o la compatibilità in avanti? Vediamo qualche esempio. La risorsa Observation, nella versione 5, pur essendo normativa dalla 4, ha introdotto questi elementi:
Esaminiamo la risorsa Condition – Content che è a livello 5 e scopriamo quale modifiche sono state apportate dalla versione 4 e 4B.
La risorsa Condition si usa per definire una condizione, un problema, una diagnosi o un altro evento, situazione, questione o concetto clinico che ha raggiunto un livello di preoccupazione. Come potete osservare le modifiche non sono irrisorie.
Ma quanto tempo è trascorso tra una versione e l’altra? La versione 4 è uscita a ottobre 2019, la 4B a maggio 2022, la 5 a marzo 2023.
Ha senso allora scegliere FHIR come modello dati per un Clinical Data Repository? Chi ha fatto questa scelta ha ponderato questi aspetti? E nel caso a quali conclusioni è giunto?
Per chi volesse saperne di più su FHIR e anche su altre motivazioni che suggeriscono di non utilizzarlo per la persistenza dati, nonché sull’alternativa openEHR, trova qui diversi articoli.
In linea generale dissento dall’articolo e dalle conclusioni cui esso arriva.
Vediamo innanzitutto lo standard Italiano: il Bid Document commissionato dalla Regione Lombardia e predisposto dal Politecnico di Milano, fa riferimento alla versione 2 di HL7, e già questo è un problema_ dalla versione 2 di HL7 alla versione 4B di HL7 FHIR è passata un’eternità: la versione 4, e meglio ancora la 5 (la 6 è in fase di definizione) sono versioni stabili.
Io, oggi, mi sentirei di suggerire l’utilizzo della 4B.
Inoltre, i due aspetti citati (Facade e Repository), esistono perchè chi ragiona su questee tematiche, lo fa utilizzando modalità legacy sia nella parte metodoogica che in quella dell’implementazione.
Mi spiego meglio:
Ci sono almeno 3 diversi modelli di costruzione di un repository:
a) Utilizzo di un DB relazionale
b) utilizzo di un DB documentale
c) utilizzo di una base dati RDF/OWL
c) utilizzo di un DB a grafo
d)Per completezza esisterebbero anche gli CML DB, ma non hanno al momento la capacità di supportare una tale massiva quantità di dati)
Vediamo in cosa differiscono i diversi approcci:
a) DB Relazionale (Es: da Oracle a SQL Server a Postgres via via fino a Maria DB)
in tutti questi casi c’è la necessità di convertire il modello dati ER tradizionale (descritto in UML da FHIR fino alla 4B) in un modello relazionale che tra l’altr richiede uno Schema predefinito: ci troviamo di fronte all’annosa questione del marshalling ed unmarshalling dei dati, ovvero della trasformazione di un modello che è essemzialmente rappresentato da un modello ad Oggetti in un modello ER dove gli oggetti non trovano collocazione diretta ma devono invece essere costruiti per essere memorizzati e poi essere de-costruiti per venir resi come risposta alle query.
Insomma, ci si trova di fronte a tutte le limitazioni di un DB SQL (trent’anno fa non c’era nulla di meglio, ora ci sono per fortuna delle alternative!)
b) DB Documentale (Es: Mongo DB) questa soluzione offre già qualche vantaggio rispetto alla soluzione a): si possono memorizzare i dati in XML oppure in JSON come documenti nell’ambito del DB. In questo modo se io scelgo come root del mio repository il paziente, potrei memorizzare tutti i dati relativi ad uno specifico paziene e ritirarle fuori con una singola query. Peccato però che questo funzioni solo per il paziente!!! Se già volessi conoscere tutti i pazionti di un medico, o tutti i pazienti che hanno subito una resezione epatica, non potrei accederli con la stessa facilità: la struttura documentale salva un documento, altri documenti non sono direttamente accessibili. Quindi tralascerei per questo il DB Documentale.
c) utilizzo di una base di dati RDF/OWL: dal punto di vista strettamente tecnologico sarebbe un approccio fantastico, permetterebbe di fare dell’automatic reasoning e dell’inferenza tra i dati. Peccato che non ci siano strumenti adatti, tranne Protégé, che però non è certo in grado di performare con una tale quantità di dati.
d) utilizzo di un Graph DB: I Graph Db esistono dal 2008 circa: hanno quindi raggiunto una sensibile stabilità.
In cosa consiste un BRAPH DB? E’ una struttura dati molto efficiente che contiene al suo interno dati (Nodi) e relazioni come elementi di prim’ordine (al confronto, gli SQL contengono dati, le Tabelle, ma non le Relazioni, che sono realizzati mediante link tra le Tabelle). E’ una struttura SCHEMALESS, che non richiede la definizione a priori di uno schema, e che permette la ‘mancanza’ di attributi (o la loro opzionalità a priori).
Se guardate bene la struttura di FHIR, potete facilmente rendervi conto di come essa sia corrispondente ad un grafo composto da nodi e relazioni. Quindi, quale modo migliore di rappresentare HL7 se non attraverso un grafo?
Io ho sperimentato la definizione di interfacce FHIR esporre le query necessarie ad interfacciarsi con il Back-Office, e la possibilità di memorizzare il contenuto delle singole query AS_IS nel GRAPH DB, senza dover fare alcuna trasformazione, e poter rispondere a query di interrogazione allo stesso modo, anche qui senza trasformazioni. Il risultato è il documento JSON previsto da FHIR, come nel caso del DB documentale, permettendo però la definizione di infinite query sui dati, restituendo di volta in volta quello che richiede la query, senza alcun limite.
Inoltre, non essendo il GRAPH DB limitato dal linguaggio SQL, si possono effettuare anche query diverse del tipo FOAF (Friend of a Friend) indipendentemente dall’ordine di HOPS richiesti. Il DB a grafo utilizza un linguaggio di query chiamato CYPHER, che è estremamente più efficace del corrispondente GRAPHQL; una conversione CYPHER GRAPHQL è comunque possibile.
Insomma, si allarga all’infinito la modalità di utilizzo di FHIR., oltre a poter anche supportare/convertire versioni diverse in input ed in output, ed eventualmente convertire in FHIR eventuali query specifiche customizzate per fornitori specifici.