Sebbene sia la scelta più semplice è però poco indicata per strutturare un Clinical Data Repository. Vediamo quali sono i principali limiti semantici e che impatto hanno.
La scelta prevalente, in Italia, per memorizzare dati clinici in un Clinical Data Repository va verso FHIR, anche a seguito delle indicazioni contenute nelle specifiche dell’Ecosistema dei Dati Sanitari (EDS) relativo al Fascicolo Sanitario Elettronico 2.0. Una scelta fatta da tecnici senza approfondire tutte le implicazioni e i limiti di questa decisione. Una scorciatoia nata dal desiderio di utilizzare lo stesso standard nato e impiegato per l’interoperabilità tra sistemi (FHIR sta per Fast Healthcare Interoperability Resources).
Ma perché FHIR non è adatto a conservare dati clinici? In realtà ci sono diverse motivazioni che ho già trattato su questo blog (qui un esempio). Questa volta voglio però focalizzarmi su un aspetto particolare, ossia sulla capacità di FHIR di rappresentare correttamente il significato che i dati rappresentano, ossia l’abilità semantica. Non si tratta di un concetto astruso ma, come vedremo, di un aspetto che ha un impatto pratico sul modo di rappresentare e utilizzare i dati.
FHIR ha due moduli che hanno particolare rilevanza clinica: Clinical e Diagnostic. Il primo contiene le seguenti risorse: AllergyIntolerance, Condition (Problem), Procedure, FamilyMemberHistory,
AdverseEvent, CarePlan, Goal, CareTeam, ClinicalImpression, DetectedIssue, ServiceRequest,
VisionPrescription, RiskAssessment, NutritionIntake e NutritionOrder. Diagnostic contiene invece Observation, DiagnosticReport, ServiceRequest, DocumentReference, ImagingSelection, ImagingStudy, MolecularSequence, GenomicStudy, Specimen e BodyStructure. Alcuni di essi descrivono più le attività o gli aspetti organizzativi che concetti clinici, ma sono comunque pertinenti l’ambito clinico.
Esaminiamo ora le risorse più importanti e quelle più adoperate. Condition serve per (traduzione letterale) “registrare informazioni dettagliate su una condizione, un problema, una diagnosi o un altro evento, situazione, questione o concetto clinico che ha raggiunto un livello di preoccupazione. La condizione può essere una diagnosi puntuale nel contesto di un incontro, può essere un elemento della Lista dei problemi dell’operatore o può essere un problema che non esiste nella Lista dei problemi dell’operatore. Spesso una condizione riguarda la valutazione e l’affermazione da parte del medico di un particolare aspetto dello stato di salute del paziente“. Come si può notare sono concetti simili ma non equivalenti. Possiamo trovare ad esempio insieme diagnosi con segni e sintomi che hanno un significato molto diverso per un medico.
Procedure serve per “registrare i dettagli delle procedure attuali e storiche eseguite su, con o per un paziente, un operatore, un dispositivo, un’organizzazione o un luogo. Tra gli esempi vi sono procedure chirurgiche, procedure diagnostiche, procedure endoscopiche, biopsie, consulenza, fisioterapia, servizi di assistenza personale, servizi di assistenza diurna per adulti, trasporto non urgente, modifiche alla casa, esercizio fisico, verifica delle qualifiche di iscrizione a un programma sociale, ecc“. Anche in questo caso lo spettro di utilizzo è molto vasto ed eterogeneo.
Ma vediamo adesso Observation che per FHIR sono un elemento centrale dell’assistenza sanitaria, utilizzati per supportare la diagnosi, monitorare i progressi, determinare le linee di base e i modelli e persino acquisire le caratteristiche demografiche, nonché i risultati dei test eseguiti su prodotti e sostanze. Val la pena di elencare gli esempi che sono riportati:
- Segni vitali come il peso corporeo, la pressione sanguigna e la temperatura
- Dati di laboratorio come la glicemia o una stima del GFR
- Risultati di imaging come la densità ossea o le misurazioni fetali
- Risultati clinici, come ad esempio la tensione addominale
- Misurazioni del dispositivo 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 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 l’affermazione di morte
- Test di qualità del prodotto come pH, dosaggio, limiti microbici, ecc. su prodotto e sostanza
Troviamo quindi insieme risultati di laboratorio, parametri vitali, caratteristiche personali, dati anamnestici, condizioni di salute. Concetti molto diversi tra loro.
FHIR è stato progettato prevalentemente da informatici che hanno voluto suddividere le informazioni in classi mantenendo tuttavia un certo livello di astrazione. L’articolazione di FHIR in risorse è in un certo senso “agnostica” rispetto al significato semantico dei dati. Tutto ciò che è “osservabile” o “misurabile – classificabile” diventa una Observation, con una sovrapposizione però con altre risorse, ad esempio Procedure e Condition. Anche queste ultime due infatti descrivono concetti che si “osservano” (ad esempio una diagnosi o un esame diagnostico). Succede infatti che talvolta sistemi diversi impiegano differenti risorse per esprimere lo stesso concetto.
Ma tornando alla domanda iniziale, quale impatto pratico hanno questi aspetti sul modo di rappresentare e utilizzare i dati? Vediamo i più importanti:
- La capacità di dettagliare e descrivere tutte le informazioni che caratterizzano il concetto che vogliamo rappresentare. Generalizzare, astrarre, comporta necessariamente perdere dettaglio che in alcuni casi sono però rilevanti; da qui la necessità di dover ricorrere a delle estensioni che però finiscono con di indebolire o nei casi più estremi vanificare il concetto di standard;
- La capacità di rappresentare le informazioni con un’ontologia medica appropriata. Se voglio disegnare un cruscotto e organizzare le informazioni per diagnosi, parametri vitali, misure di laboratorio, anamnesi, etc.. dovrò “leggere” le risorse per cercare di dividere i concetti che appartengono alla stessa classe (risorsa). L’alternativa, praticata da molti fornitori, è di limitarsi a proporre la stessa struttura – articolazione di FHIR, facendo un “minestrone” di concetti diversi;
- La capacità di conoscere il significato dei dati all’interno della stessa risorsa. La pressione sistolica e il peso sono due parametri vitali che hanno però un significato completamente diverso. Sono entrambi numeri che misurano qualcosa ma la similitudine finisce qui. Purtroppo le cartelle cliniche elettroniche oggi in commercio sono “agnostiche“, non conoscono cioè il significato dei dati che rappresentano e, per questo motivo, non sono in grado di fornire alcun valore aggiunto al medico (ad es. mettere in correlazione la pressione sistolica con un farmaco antipertensivo). È l’utente che legge i dati, li correla e li interpreta. Il software è solo un tramite, uno strumento per leggere e scrivere dati. Non c’è quindi da stupirsi se questo problema non è sentito né considerato.
I dati possono fornire informazioni e queste possono rappresentare della conoscenza che, è bene ricordarlo, è l’essenza della medicina che non è una scienza esatta ma una pratica basata sulle conoscenze. Maneggiare dati senza “capirli” è la stessa cosa che fa un pappagallo quando ripete ciò che sente dagli uomini. Se vogliamo migliorare la sanità non ci servono pappagalli digitali ma strumenti in grado di assistere e aiutare medici e infermieri nel loro lavoro.
Ricordo a tutti che, nell’ambito dell’Accademia di Salute Digitale, abbiamo pianificato dei corsi per comprendere gli aspetti innovativi e meno conosciuti dell’innovazione. Tra questi c’è openEHR, lo standard per gestire i dati clinici che si sta affermando sempre più nel mondo e che viene scelto dai più importanti e prestigiosi ospedali europei. Se volete saperne di più iscrivetevi e partecipate, non si paga nulla!
openEHR
Un’occasione per conoscere openEHR e comprendere perché sta diventando lo standard di riferimento per la persistenza dei dati clinici. Il webinar è articolato in due sessioni:
Martedì 26 novembre ore 18-19
- Introduzione e breve storia di openEHR
- Architettura e modello di riferimento
- Gli archetipi
- I template
- Il linguaggio AQL
Per accedere al webinar è necessario registrarsi qui.
Giovedì 28 novembre ore 18-19
- Modello dati aperto per evitare il lock-in dei fornitori
- Uso di openEHR nello sviluppo delle soluzioni cliniche
- openEHR, FHIR e OMOP, tre standard diversi ma complementari
- Programmazione low-code in openEHR, esempi pratici
Per accedere al webinar è necessario registrarsi qui.
Vi aspetto!