Salute Digitale

Scopriamo quali sono i limiti di LOINC, il sistema con cui codificare le osservazioni.

Dopo aver esaminato le finalità e la struttura di FHIR (qui trovate l’articolo precedente) vediamo di entrare un po’ più nel dettaglio su LOINC, il sistema di codifica con cui rappresentare parametri vitali, misure, osservazioni e risultati di laboratorio.

LOINC è un sistema di codifica inizialmente nato proprio per quest’ultimo scopo (si chiamava infatti Laboratory Observation Identifiers Names and Codes) e successivamente esteso per gestire osservazioni e documenti clinici (trasformando la L iniziale in Logical). Il criterio di codifica si basa su sei dimensioni: il componente o l’analita, ossia la sostanza o il fatto che viene misurato; la proprietà che viene misurata; l’intervallo di tempo cui si riferisce la misurazione; il campione o il sistema; la scala, ossia come il valore dell’osservazione è espresso (ad es. quantitativo, qualitativo), la metodologia di misurazione (metodica) adottata (facoltativo). A differenza di altri sistemi non è presente una vera e propria ontologia. Ad ogni voce viene associato un codice numerico di cinque cifre più una sesta di controllo (checksum). Ad esempio questi due voci:

• 14749-6; Glucose ; SCnc ; Pt ; Ser/Plas ; Qn ; ;
• 2345-7; ; Glucose ; MCnc ; Pt ; Ser/Plas ; Qn ; ;

si riferiscono alla glicemia misurata nel siero o plasma in modo puntuale con un valore quantitativo. Nel primo caso viene misurata la concentrazione della sostanza, il cui risultato è espresso in mmol/L, nel secondo la concentrazione della massa, il cui risultato è espresso in mg/dL.

Ogni qual volta c’è una variazione in una qualsiasi delle sei dimensioni, viene generato un nuovo codice. Ad esempio, sempre per la glicemia, ci sono codice ad hoc in caso di risultato prodotto con strip in modo automatizzato (2340-8) o manuale (2341-6). Analogamente se l’esame è fatto sul sangue prende altri codici (15074-8 e 2339-0). Come è facile comprendere questo meccanismo genera un numero elevato di voci e codici; solo per la glicemia, nei vari sistemi in cui può essere misurata (sangue, urine, ecc..), ci sono 82 codici.

Questo fenomeno riguarda un po’ tutte le misurazioni. Ad esempio nel caso della pressione arteriosa c’è un codice (55284-4) che permette di esprimere la minima e la massima insieme (120/80), uno per la diastolica (8462-4) e uno per la sistolica (8480-6), nonché un codice (35094-2) per un “pannello” di voci che include diastolica, sistolica, la pressione media e altri sei codici (facoltativi) che definiscono la metodologia di misurazione, la dimensione del bracciale, il nome e il codice del dispositivo medico.

FHIR consente l’uso di diversi sistemi di codifica, non solo LOINC, con cui si esprime il valore semantico del dato che tuttavia è anche espresso nella struttura delle risorse che, in quanto generiche, non è detto sia sufficiente per esprimere tutti i concetti rilevanti che possono variare da struttura a struttura, da branca a branca, da un setting assistenziale a un altro.

Per questa ragione il modello dati di FHIR può essere sufficiente per garantire lo scambio dei dati tra sistemi ma insufficiente per esprimere la varietà e la complessità di un sistema clinico (ad esempio una cartella clinica elettronica). Impostare un Clinical Data Repository di una cartella clinica su FHIR può dunque comportare dei limiti in termini di capacità di rappresentazione dei concetti clinici.

Anche in ambito regionale, ad esempio per l’FSE 2.0, questa scelta può rivelarsi debole in quanto poco capace di gestire l’eterogeneità che esiste tra le aziende sanitarie e tra le diverse branche della medicina. Non è soltanto un problema di mapping che si risolve con un buon terminology server ma è una tematica ben più complessa che riguarda i concetti e la struttura semantica che questi esprimono. Neppure la scelta di un’unica cartella clinica elettronica a livello regionale risolve questo problema, come ho espresso in un precedente articolo che potete leggere qui.

Ci sono poi considerazioni tecnologiche su come sono realizzati e strutturati i server FHIR. Molti di essi sono basati su database non relazionali in cui vengono registrati direttamente i JSON delle risorse. Come abbiamo già visto queste hanno molte ridondanze e con grandi volumi di dati possono sorgere problemi di performance. Ulteriori riflessioni si possono infine indirizzare alle capacità di ricerca di FHIR.

Viene allora da chiedersi se esistono delle alternative alla scelta (scorciatoia?) di FHIR per la persistenza dei dati. È quanto scopriremo nella prossima puntata.

2 – Continua