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.