Salute Digitale

Quanto è efficace utilizzare il modello dati di FHIR per conservare e ricercare dati clinici? È una scelta ragionata o una scorciatoia per semplificare il problema?

FHIR è uno standard, come indica la lettera I – Interoperability – dell’acronimo, per l’interscambio di dati sanitari che vengono esposti come risorse (per saperne di più vedi qui). Nel progetto del nuovo fascicolo sanitario elettronico, così come nelle gare di telemedicina regionali, FHIR è stato indicato non soltanto per realizzare l’interoperabilità con gli altri sistemi ma anche come formato per la persistenza delle informazioni. In altre parole si è scelto di adottare FHIR per realizzare l’Ecosistema dei Dati Sanitari (nel FSE 2.0) o il Clinical Data Repository (CDR) della telemedicina.

L’equazione CDR uguale FHIR server è stata inoltre presa a modello in molti progetti di Cartella Clinica Elettronica regionali – aziendali o nel caso dei nuovi sistemi territoriali. La domanda che dobbiamo farci è se questa scelta è la più appropriata per conservare e ricercare dati clinici. Prima però di rispondere al quesito è necessario definire quale sia il contesto e lo scopo per cui dobbiamo / vogliamo gestire dati clinici strutturati e non.

Il contesto

Se il contesto include più sorgenti dati per le stesse classi, ad esempio una regione in cui vi sono più sistemi di laboratorio (LIS) o cartelle cliniche elettroniche (CCE), diventa fondamentale poter organizzare e aggregare le informazioni in modo da, ad esempio, poter visualizzare in forma grafica l’andamento della glicemia (che può essere misurata in diversi modi e con unità di misura differenti) o della pressione arteriosa.

Cosa vogliamo fare con i dati

Se vogliamo utilizzare i dati per arricchire i sistemi clinici e dotarli di funzioni intelligenti (si veda ad esempio qui) è necessario associare loro un preciso significato medico, operazione che richiede una esatta comprensione delle informazioni che questi esprimono. Questo compito viene oggi svolto dai medici che leggendo i dati sono in grado di interpretarli, correlarli e utilizzarli nel loro processo decisionale. Se vogliamo implementare queste logiche nel software clinico è indispensabile attribuire un preciso significato ai dati.

L’importanza della semantica

Per utilizzare i dati nei due ambiti appena descritti non basta fissare un formato dei dati, ossia la sintassi, ma è necessario definire una semantica che esprima il significato che il dato esprime e che, in medicina, può essere molto ampio. Prendiamo ad esempio la pressione arteriosa. Questa è espressa con due misure, la diastolica (detta anche minima) e la sistolica (massima). La pressione può essere misurata in diverse parti del corpo, a riposo o in movimento, in diverse posizioni (ad esempio seduti o distesi), con differenti dispostivi medici e metodiche. In alcuni casi possono essere sufficienti le due misurazioni mentre in altri, ad esempio nel caso di una forma di ipertensione instabile, possono essere rilevanti anche le altre informazioni.

Il modello dati di FHIR

Il modello dati di FHIR è composto da 157 risorse ripartite in 5 livelli logici ciascuno dei quali comprende uno o più moduli.

In linea di principio, le risorse sono progettate per lo scambio tra sistemi, piuttosto che come formato di archiviazione di database. Una conseguenza pratica di ciò è che, in qualche modo, le risorse sono altamente denormalizzate, in modo che gli scambi granulari siano abbastanza indipendenti. Ogni risorsa gestisce una tipologia di dati, ad esempio, i dati demografici dei pazienti si trovano solo nella risorsa Paziente ma a livello clinico ci possono essere delle sovrapposizioni (ad esempio un problema di salute espresso come Observation anziché come Condition).

Le Observation

Una delle risorse più utilizzate è Observation che può esprimere:

• Segni vitali come il peso corporeo, la pressione sanguigna e la temperatura
• Dati di laboratorio come la glicemia o una misura del GFR
• Risultati di imaging come la densità ossea o le misurazioni fetali
• Risultati clinici come la tensione addominale
• Misurazioni di dispositivi medici come i dati dell’elettrocardiogramma o della pulsossimetria
• Impostazioni del dispositivo, come i parametri del ventilatore meccanico.
• Strumenti di valutazione clinica come APGAR o Glasgow Coma Score
• Caratteristiche personali come ad esempio il colore degli occhi
• Anamnesi sociale, come l’uso del tabacco, il sostegno della famiglia o lo stato cognitivo.
• Caratteristiche fondamentali come lo stato di gravidanza o la certificazione di morte
• Test di qualità del prodotto come pH, dosaggio, limiti microbici, ecc. su prodotto e sostanza

Il dato espresso da Observation viene identificato da un codice e da un sistema di codifica (ad es. LOINC). La struttura della risorsa comprende vari dati tra cui data e ora, la parte del corpo osservata, la metodica, il campione, il dispositivo, i valori di riferimento. Il significato semantico è dunque demandato alla codifica ed è integrato dai dati presenti nella struttura, con il rischio di possibili incongruenze con quanto definito dal sistema di codifica (ad esempio un codice LOINC che si riferisce a un campione diverso da quello espresso all’interno dell’Observation).

Nell’Ecosistema dei Dati Sanitari viene menzionato LOINC come sistema di codifica (peraltro già utilizzato nell’attuale FSE) e citato SNOMED che tuttavia non è stato ufficialmente adottato dal nostro paese.

Nella prossima puntata vedremo in dettaglio come è strutturato LOINC e quali problemi presenta.

1 – Continua