Un foglio Excel che parla FHIR: interoperabilità a costo zero per il SSN
Nelle aziende sanitarie italiane, lo screening oncologico — cervice uterina, mammella, colon-retto — produce ogni anno migliaia di record clinici. Dati di enorme valore epidemiologico e clinico, che nella maggior parte dei casi finiscono in fogli Excel costruiti localmente, ciascuno con una struttura propria, e in archivi cartacei difficilmente consultabili al di fuori del contesto in cui sono stati prodotti.
Il problema non è la carta, né Excel in sé. Il problema è che quei dati nascono già condannati all’isolamento: non dialogano con il Fascicolo Sanitario Elettronico, non alimentano i flussi regionali in modo strutturato, non possono essere interrogati da piattaforme di analisi nazionali come la PNLA (Piattaforma Nazionale Liste di Attesa). Quando arriva il momento di integrarli in un sistema informativo, bisogna ricominciare da capo.
Esiste però un modo per uscire da questa impasse senza aspettare infrastrutture nuove, gare d’appalto o finanziamenti straordinari.
L’idea: strutturare la raccolta dati secondo i path di HL7 FHIR R4
HL7 FHIR (Fast Healthcare Interoperability Resources) è lo standard internazionale per l’interoperabilità sanitaria, adottato dall’Unione Europea come fondamento dello Spazio Europeo dei Dati Sanitari (EHDS) e dalla normativa italiana per il FSE 2.0. FHIR organizza l’informazione clinica in *risorse* — Patient, Observation, Condition, ServiceRequest — ciascuna con un insieme preciso di campi, identificati da un *path* univoco (es. `Patient.birthDate`, `Observation.code.code`).
L’intuizione alla base di questo progetto è semplice: se le colonne di un foglio Excel vengono nominate e organizzate secondo i path esatti di FHIR R4, quel file cessa di essere un documento proprietario e diventa un *layer di staging* strutturato. I dati esistono già in formato tabellare, che è il formato con cui gli operatori sanitari lavorano da decenni; ma la loro struttura rispecchia già quella di un server FHIR. La conversione, quando servirà, diventerà un’operazione meccanica.
Il workbook per lo screening oncologico
Ho costruito un workbook Excel — scaricabile liberamente — organizzato in quattro fogli corrispondenti alle quattro risorse FHIR più rilevanti per un programma di screening:
**Patient** raccoglie l’anagrafica del paziente: codice fiscale come `Patient.identifier.value`, data di nascita in formato ISO 8601, comune e provincia di residenza, medico di medicina generale, codice ASP di riferimento. Nulla che un consultorio familiare non raccolga già; semplicemente, raccolto nel modo giusto.
**Observation** registra i risultati degli esami di screening — Pap test, mammografia bilaterale, sangue occulto fecale — usando i codici LOINC come `Observation.code.code` (ad esempio `19762-4` per il Pap test cervicale). Il risultato viene espresso sia in forma testuale che tramite codici SNOMED CT nell’apposito campo `Observation.valueCodeableConcept.code`. Il campo `Observation.interpretation` distingue i risultati normali da quelli anomali con una sola lettera — N o A — sufficiente a innescare una segnalazione automatica.
**Condition** traduce i referti in diagnosi codificate secondo ICD-10: `Z12.4` per lo screening della cervice, `Z12.31` per la mammella, `K92.1` per il sangue occulto positivo. È il foglio che, in un futuro sistema FHIR nativo, alimenterebbe direttamente il problem list del paziente nel FSE.
**ServiceRequest** documenta le richieste di prestazione: la richiesta di Pap test, la mammografia pianificata, la colonscopia urgente per una paziente con SOF positivo. Il campo `ServiceRequest.priority` ammette i valori dello standard FHIR — routine, urgent, asap, stat — e il campo `ServiceRequest.basedOn` può contenere il riferimento al protocollo aziendale di screening adottato.
Un quinto foglio, **CodeSets**, raccoglie le tabelle di codifica utilizzate: i codici LOINC per gli esami, i codici SNOMED CT per i risultati, i codici ICD-10 per le diagnosi. È la chiave di volta del sistema: finché gli operatori attingono da queste tabelle anziché inserire testo libero, il workbook rimane semanticamente consistente e automatizzabile.
Cosa cambia nella pratica
Un operatore che compila questo foglio non fa nulla di diverso da quello che farebbe con qualsiasi altro registro Excel. Il carico cognitivo aggiuntivo è minimo: usare il formato YYYY-MM-DD per le date, scegliere il codice dal menù a tendina invece di scrivere a mano il nome dell’esame, attribuire un identificatore univoco a ogni riga.
In cambio, l’azienda sanitaria ottiene un archivio che può essere trasformato in un **Bundle FHIR R4 JSON** — il formato nativo per la trasmissione su rete — con uno script Python di poche decine di righe. Quella stessa Bundle può essere inviata a un server FHIR aziendale, caricata sul Gateway FSE 2.0, integrata nella PNLA, esportata verso il registro tumori regionale. Senza ridigitare nulla. Senza perdere un dato.
Non è la soluzione definitiva. È il primo gradino — quello che nella mia proposta di modello di maturità FHIR per il SSN chiamo **livello L1**: raccolta dati strutturata e codificata, non ancora nativa su rete ma già pronta per esserlo. È la differenza tra un archivio e un patrimonio informativo.
Perché questo interessa il SSN
Il tema dell’interoperabilità viene spesso presentato come una questione tecnologica di alto livello, affare da informatici e da grandi fornitori. In realtà, la transizione verso lo Spazio Europeo dei Dati Sanitari si vince o si perde nei consultori familiari, negli ambulatori di screening, nei poliambulatori distrettuali — nei luoghi dove oggi si apre ancora Excel e si digita a mano.
La sfida non è convincere i dirigenti aziendali che FHIR è il futuro. È convincere chi raccoglie i dati ogni giorno che strutturarli bene non richiede sforzo ulteriore, ma restituisce valore: ai colleghi che li useranno, ai sistemi che li elaboreranno, ai pazienti che ne beneficeranno.
