Condivisione della cartella clinica elettronica: interoperabilità

Il PNRR (Piano Nazionale di Ripresa e Resilienza) ha allocato 1,67 miliardi di euro per la digitalizzazione del Sistema Sanitario Nazionale, con il FSE 2.0 come infrastruttura portante per la condivisione della cartella clinica elettronica. Condividere cartelle cliniche elettroniche tra sistemi diversi significa riconciliare almeno quattro standard: HL7 FHIR R4 per lo scambio basato su API, C-CDA R2.1 per il trasferimento basato su documenti, HL7 v2.x per la messaggistica legacy, e DICOM per l'imaging. Il GDPR all'articolo 9 classifica i dati sanitari come categoria speciale che richiede misure tecniche e organizzative specifiche per ogni condivisione.

Lo stack di standard con cui lavori davvero

L'interoperabilità delle cartelle cliniche sembra una insalata di standard perché lo è. Ecco cosa fa ogni livello:

HL7 v2.x — messaggi delimitati da pipe degli anni '90, ancora il motore di lavoro per ordini di laboratorio, feed ADT (ammissione/dimissione/trasferimento) e gestione degli ordini all'interno di un ospedale. Non adatto alla condivisione tra organizzazioni.
C-CDA R2.1 — documenti XML strutturati che rappresentano un riassunto del paziente, una lettera di dimissione o una nota di referral. La spina dorsale della messaggistica PEC e della maggior parte degli scambi di interoperabilità regionali.
HL7 FHIR R4 — risorse RESTful (Paziente, Osservazione, Condizione, RichiestaMedicamento) scambiate su HTTPS con JSON o XML. Il livello moderno, richiesto dall'implementazione italiana del FSE 2.0.
DICOM — standard di imaging, si muove attraverso i propri canali (DIMSE, DICOMweb).

Quando "condividi una cartella clinica elettronica", stai in realtà condividendo frammenti da ciascun livello, cuciti nel formato giusto per il destinatario.

Il FSE 2.0 e il quadro normativo italiano

Il Fascicolo Sanitario Elettronico 2.0 è il sistema nazionale per l'accesso e la condivisione dei documenti clinici dei cittadini italiani. Il D.L. 19/2020 e le successive linee guida del Ministero della Salute ne definiscono l'architettura:

Ogni cittadino ha un FSE accessibile tramite SPID o CNS
Gli operatori sanitari autorizzati accedono ai documenti del paziente con autenticazione forte
I documenti alimentatori (lettere di dimissione, referti, certificati) sono caricati dalle strutture produttrici
L'interconnessione regionale garantisce l'accesso ai documenti indipendentemente dalla regione di produzione

Le regioni hanno diversi gradi di maturità nell'implementazione: alcune offrono accesso praticamente completo alla storia clinica del paziente; altre sono ancora in fase di alimentazione. Il PNRR prevede il completamento e l'armonizzazione entro il 2026.

API FHIR e la questione dell'accesso ai dati

Le API FHIR R4 sono il livello tecnico del FSE 2.0 per l'accesso strutturato. Per uno sviluppatore che integra con i sistemi regionali, questo significa:

Registrazione dell'applicazione nei registri regionali o nazionali
Utilizzo del flusso di autenticazione SMART on FHIR con OAuth 2.0
Richiesta degli scope appropriati (lettura del paziente, risorse specifiche)
Ricezione di bundle JSON su HTTPS

La complicazione pratica: le implementazioni regionali delle API FHIR variano. Alcune regioni hanno endpoint di produzione maturi; altre sono in fase di test. L'accesso in produzione richiede accordi formali e verifica dell'identità dell'ente richiedente.

C-CDA: ancora il default per i riassunti tra organizzazioni

Nonostante l'ascesa di FHIR, la maggior parte dello scambio di record tra organizzazioni viaggia ancora in documenti C-CDA. Un Documento di Continuità delle Cure (CCD) sotto C-CDA R2.1 tipicamente pesa 200 KB-2 MB di XML con HTML embedded per la leggibilità umana. Template chiave:

CCD (Documento di Continuità delle Cure)
Lettera di Dimissione
Nota di Referral
Nota di Consulenza
Nota di Evoluzione

Questi fluiscono attraverso la PEC o lo scambio tramite sistemi regionali di interoperabilità. La cartella clinica ricevente analizza l'XML e acquisisce gli elementi strutturati nel record locale. La qualità del parsing varia — alcuni sistemi acquisiscono le liste problemi pulitamente ma perdono la storia sociale. La riconciliazione dei dati rimane un passaggio manuale nella maggior parte delle strutture.

Quando le API non bastano e serve il trasferimento di file

Nonostante tutti gli standard, i clinici devono regolarmente spostare un file che non si adatta a nessuna API. Esempi:

Un bundle PDF da 300 MB di documenti cartacei scansionati da prima della digitalizzazione della clinica
Un dataset di ricerca in formato SAS o Stata per una revisione retrospettiva
Una serie di foto di ferite dall'assistenza domiciliare che non devono intasare il server di imaging
Documentazione per un fascicolo legale in un caso di responsabilità medica

Per questi casi, si ricade sul trasferimento cifrato di file. I requisiti: accordo sul trattamento dei dati firmato con il fornitore, crittografia AES-256-GCM a riposo, TLS 1.3 in transito, log di audit e scadenza del link. Se questo strumento è una funzionalità integrata nella cartella clinica, un servizio enterprise approvato dall'ospedale, o un trasferimento browser-based ad hoc dipende dalla governance.

HexaTransfer offre il percorso ad hoc con crittografia lato client prima dell'upload. Prova su https://hexatransfer.com — gratuito, senza registrazione, fino a 10 GB. Registra il trasferimento nel tuo record di audit standard per poterlo rintracciare in seguito.

Il problema dell'identità del paziente

Condividere un record richiede sapere che è il paziente giusto. L'Italia dispone del codice fiscale come identificativo univoco nazionale, che risolve molti problemi di matching che altri sistemi devono affrontare con metodi probabilistici. Tuttavia, nella pratica il matching tra sistemi diversi può ancora fallire per problemi di qualità dei dati, variazioni nell'ortografia del nome, o errori di inserimento.

Per i trasferimenti a livello di file, includere sempre gli identificatori del paziente nel nome del file o in un foglio di copertina — codice fiscale, data di nascita, e almeno un identificativo aggiuntivo. Non affidarsi al clinico per sapere a quale paziente appartiene "MariaBianchi-MRI.dcm".

Consenso, segmentazione e categorie speciali

Non tutti i record si condividono allo stesso modo. I dati relativi a salute mentale, HIV, dipendenze e genetica hanno requisiti di condivisione più restrittivi previsti dalla normativa italiana e dalle linee guida del Garante per la protezione dei dati personali.

Dopo la revisione delle politiche di condivisione nel 2024, un singolo consenso del paziente può abilitare una condivisione più ampia, ma i record devono comunque portare un avviso sul divieto di ridivulgazione non autorizzata.

Se il tuo strumento di trasferimento non può rispettare la segmentazione — non può indicare quali parti di un documento richiedono consenso aggiuntivo — non usarlo per i record di salute mentale. Usalo per il pacchetto di follow-up ortopedico.

Contabilità delle divulgazioni

Il GDPR all'articolo 15 dà agli interessati il diritto di accedere ai dati che li riguardano, incluse le informazioni su chi li ha ricevuti. Per il trattamento sanitario la base giuridica di cura non richiede un consenso esplicito, ma le divulgazioni per finalità diverse (ricerca, fini assicurativi, legali) devono essere tracciate.

Il log di audit del tuo sistema di trasferimento alimenta questa rendicontazione. Catturare:

Timestamp in UTC
Organizzazioni mittente e destinataria
Codice di finalità (CURA, PAGAMENTO, OPERAZIONI, AUTORIZZAZIONE, ecc.)
Categorie di dati trasferiti
Identificativo del paziente

Se ti affidi a uno strumento di condivisione file generico che registra solo "l'utente X ha caricato il file Y", avrai difficoltà quando un paziente chiede conto delle divulgazioni dei propri dati.

Strutture piccole e il divario di risorse

Uno studio medico di 3-5 professionisti non ha un CIO. Ha un ufficio amministrativo che gestisce anche l'IT insieme alla fatturazione. Devono comunque produrre record conformi al GDPR su richiesta, firmare accordi sul trattamento con ogni fornitore, e gestire le richieste degli interessati. L'approccio pratico:

Usare una cartella clinica elettronica (quelli certificati per il FSE 2.0) che gestisce l'interoperabilità di base fuori dalla scatola
Scegliere un unico strumento di trasferimento cifrato ad hoc con accordo sul trattamento per tutto ciò che la cartella clinica non può inviare
Documentare il flusso di lavoro in un SOP di una pagina
Formare ogni membro dello staff sui due strumenti che useranno settimanalmente

La condivisione della cartella clinica elettronica non è un problema da risolvere con un unico fornitore. È un flusso di lavoro a strati da mantenere. Fare bene gli standard dove possibile, e avere un fallback cifrato pulito per i casi che gli standard non coprono.