Salute Digitale

Perché FHIR non è la scelta migliore per conservare dati clinici.

In un post precedente ho illustrato perch la sanità ha bisogno di piattaforme dati aperte e indicato come la scelta migliore per la persistenza dei dati clinici sia openEHR anziché FHIR che è oggi la soluzione che in Italia va per la maggiore.

In questo articolo spiegherò le differenze che ci sono tra questi due standard che, ricordo, sono nati per scopi differenti e che possono coesistere molto bene.

openEHR si basa su un modello di riferimento molto astratto e semplice sul quale si costruiscono gli archetipi, un modello dati semantico che definisce un concetto clinico, ad esempio la pressione arteriosa, il body mass index e così via. Ogni archetipo rappresenta un set di dati massimo per un caso d’uso universale.

Attraverso i template è possibile creare, combinando uno o più archetipi, definizioni di contenuti, come un “referto radiologico”, una lettera di dimissione ospedaliera, un patient summary. Esistono molte knowledge base che contengono archetipi e template che si possono adottare così come sono, modificare per le proprie esigenze o crearne di nuovi. Ad oggi esistono più di 880 archetipi attivi.

FHIR, viceversa, si basa su un ampio numero di risorse ciascuna delle quali descrive un concetto clinico o un’azione. Ogni risorsa ha una propria struttura che è fissa e non è modificabile. È possibile aggiungere informazioni mediante delle estensioni che però non sono standard. Si utilizza la risorsa Observation per esprimere la misurazione della pressione, una valutazione del dolore, oppure una diagnosi che però può anche essere espressa con la risorsa Condition. Quest’ultimo è un esempio di ambiguità su come associare alcuni concetti alle risorse (ad esempio alcune CCE esprimono le diagnosi con la risorsa Observation, altri con Condition). Ad oggi ci sono circa 150 risorse pubblicate anche se solo una parte sono “normative”, ossia possono essere considerate definitive.

Risorse di questo tipo hanno una struttura generica per esprimere, anche attraverso l’uso di vocabolari o sistemi di codifica, concetti che possono essere molto diversi tra loro. FHIR non supporta nativamente l’ereditarietà delle classi o la gestione di multi-tipi. Non è poi facile codificare concetti non strutturati nativamente.

FHIR non possiede un analogo dei template; eventuali regole e vincoli sull’uso dei dati in casi d’uso specifici vanno definiti fuori dallo standard. La struttura delle risorse di FHIR crea inoltre problemi di retro compatibilità al variare delle stesse.

openEHR ha un vero e proprio linguaggio per l’interrogazione dei dati, AQL, che un mix di SQL e XQuery/XPath e che opera sugli archetipi e non sul modello dati fisico con cui questi sono memorizzati. FHIR possiede al contrario capacità di query limitate.

Ci sono poi possibili problemi di prestazioni al crescere della quantità di dati gestiti in repository FHIR per la struttura stessa con cui questi sono memorizzati.

Questi che ho elencato sono solo alcuni degli aspetti che andrebbero considerati in modo approfondito prima di fare una scelta su come conservare dati clinici.