openEHR, FHIR e CDA: differenze, complementarità e convivenza

AIHealth

Piattaforma clinica on-premise con LLM locali, RAG su dati FHIR/DICOM, supporto alla diagnosi, follow-up remoto. Architettura progettata per il percorso MDR.

Scopri AIHealth →

Digital Health

Sviluppo di software medicale conforme agli standard normativi CE e MDR. Sistemi di supporto alle decisioni cliniche, integrazione AI nei flussi di lavoro clinici.

Scopri →

Tre standard, tre scopi

Un equivoco ricorrente nel dibattito sull’interoperabilità sanitaria è considerare CDA R2, FHIR e openEHR come alternative tra cui scegliere. In realtà coprono scopi strutturalmente diversi: il fatto che tutti e tre modellino dati sanitari non ne fa prodotti concorrenti. Sono piuttosto strati di un’architettura, ciascuno con il proprio uso naturale e con punti di contatto ben definiti. A fianco si colloca OMOP CDM, ortogonale ai tre: un modello dati osservazionale non di scambio né di persistenza clinica, ma di analisi aggregata, di cui abbiamo parlato altrove.

Ogni scelta di architettura di un sistema sanitario — sia essa di una singola azienda, di una Regione o di un programma nazionale — si gioca sulla composizione di questi livelli. Forzare uno standard in un ruolo che non è il suo — per esempio usare CDA R2 come API transazionale, o FHIR come archivio legale — produce attriti che nessuna ottimizzazione tecnica risolve.

CDA R2: il documento

HL7 CDA R2 (Clinical Document Architecture Release 2, ANSI 2005) risponde alla domanda: come rappresento un documento clinico in modo che sia archiviabile, firmabile, conservabile nel tempo e interpretabile in assenza del sistema che l’ha prodotto?

I suoi principi di progettazione sono quelli del documento: persistenza, stewardship, autenticazione legale, interezza, contesto predefinito, leggibilità umana. Un documento CDA R2 ha un autore identificato, un’organizzazione custode, una firma legale potenziale, un contenuto che può essere letto senza il sistema originario grazie allo XSLT di rendering. È un’unità archivistica autoconclusa.

Lo scopo naturale di CDA R2 è archivistico e documentale: lettera di dimissione, referto di laboratorio, patient summary, verbale di pronto soccorso come entità con propria identità giuridica e ciclo di vita. Nelle architetture dei Fascicoli Sanitari Elettronici europei di prima generazione (compreso l’italiano) CDA R2 è il formato dei documenti pubblicati, condivisi via IHE XDS.b e XCA.

I suoi limiti sono altrettanto noti:

• Complessità ereditata dal RIM di HL7 v3, con curva di apprendimento ripida
• Serialization unica in XML (nessuna variante JSON)
• API non definita — lo scambio è demandato a framework esterni (IHE XDS)
• Granularità di entry difficile da aggregare per l’analitica

FHIR: lo scambio transazionale

HL7 FHIR (Fast Healthcare Interoperability Resources, prima DSTU 2014, R4 nel 2018, R5 nel 2023) risponde a una domanda diversa: come scambio in modo transazionale e granulare dati sanitari tra sistemi, con le convenzioni del web moderno?

I suoi principi sono quelli dell’API: risorse atomiche con identità URL, composizione via riferimenti, REST con HTTP verbs, due serializzazioni equivalenti (JSON e XML), estensibilità tramite Extension, conformance-driven design con Profile in formato machine-readable.

Lo scopo naturale di FHIR è applicativo: consultazione dello stato clinico di un paziente da un’app, integrazione di servizi di supporto alle decisioni (CDS Hooks), alimentazione di Clinical Data Repository, scambio di singole osservazioni o richieste, esportazione bulk per analytics. FHIR eccelle dove serve granularità e interazione frequente tra sistemi — scenari in cui il modello documentale CDA sarebbe pesante e l’archivio XDS inappropriato.

FHIR non è progettato come formato archivistico di lungo termine. Una risorsa FHIR non ha per sua natura le caratteristiche documentali del CDA (autore unico, firma unica, stewardship, ciclo di vita come atto). Il Bundle di tipo document copre scenari documentali ma richiede comunque un framework di conservazione esterno per soddisfare requisiti archivistici e di conservazione a norma.

openEHR: la persistenza nativa con governance clinica

openEHR (openEHR Foundation, specifiche in evoluzione dal 2003, ISO 13606 come equivalente standard) risponde ancora a una domanda diversa: come memorizzo i dati clinici in modo che il modello clinico possa evolvere nel tempo senza rompere database e applicazioni?

La risposta è il modello a due livelli: un Reference Model stabile e generico per lo schema tecnico, un livello clinico governato dai clinici attraverso archetipi in ADL, con template che compongono archetipi per il caso d’uso specifico. I dati sono persistiti secondo il RM e annotati con i percorsi archetipali; una query AQL interroga i dati indipendentemente dal database fisico.

Lo scopo naturale di openEHR è la persistenza di dati clinici strutturati in contesti dove l’evoluzione del modello è un requisito — Clinical Data Repository regionali, cartelle cliniche di nuova generazione, piattaforme di ricerca longitudinale. La governance clinica degli archetipi attraverso il Clinical Knowledge Manager è un asset specifico: uno stesso archetipo di Blood pressure è usato nel Regno Unito, in Norvegia, in Germania.

openEHR non è un formato di scambio in senso stretto: quando un sistema openEHR deve comunicare con altri sistemi, lo fa attraverso FHIR (con mapping automatici da archetipi a risorse FHIR), CDA (export documentale), o protocolli specifici (HIP, openEHR REST API). È un layer di persistenza che si apre verso l’esterno attraverso standard di scambio.

Confronto sintetico

Convivenze reali

Nel mondo reale, una piattaforma sanitaria matura non usa un solo standard: li combina. Alcune combinazioni tipiche, osservabili nelle implementazioni europee del 2025:

CDA R2 + FHIR affiancati

È lo scenario attuale del Fascicolo Sanitario Elettronico italiano 2.0: documenti strutturati CDA R2 e profili FHIR italiani coesistono sul Gateway FSE. Il Gateway espone entrambe le interfacce — SOAP/XDS.b per i sistemi legacy, FHIR REST per le applicazioni moderne — con convertitori automatici nei casi richiesti. La transizione è pluriennale: i documenti nati in CDA restano CDA, i nuovi nascono in FHIR, il consumatore sceglie come interrogare.

openEHR come CDR + FHIR come API

È il pattern adottato da alcuni sistemi sanitari regionali europei (Slovenia, parti del NHS UK, progetti universitari italiani). Il Clinical Data Repository regionale memorizza i dati clinici nativamente in openEHR, con archetipi governati attraverso il CKM. L’accesso esterno — da cartelle cliniche, app paziente, sistemi di ricerca — passa per un’API FHIR che traduce al volo dai dati openEHR ai profili FHIR richiesti dal consumatore. openEHR non è mai visto dall’esterno; FHIR non è mai il formato di persistenza.

FHIR come scambio, OMOP come analitica

È il pattern della ricerca osservazionale europea (EHDEN, DARWIN EU): acquisizione dei dati via FHIR API (da sistemi produttivi o da EHR regionali), ETL verso OMOP CDM per l’analisi longitudinale. FHIR porta i dati, OMOP li rende analizzabili in modo federato. Sono modelli complementari, non in competizione.

openEHR + OMOP per la ricerca longitudinale

Per contesti di ricerca in cui serve sia una persistenza clinica governata sia un modello analitico, alcune piattaforme mantengono openEHR come CDR e OMOP come data mart analitico. I mapper openEHR → OMOP sono oggetto di ricerca attiva, con progetti pilota in Germania e in altri contesti.

Criteri di scelta

Un’organizzazione che progetta un nuovo sistema sanitario si trova davanti una serie di domande che orientano la scelta degli standard:

• Qual è la unità di scambio principale? Documenti con identità legale (CDA), entità clinicamente granulari (FHIR), osservazioni longitudinali (openEHR o FHIR)?
• Qual è il pattern di accesso? Pubblicazione/consultazione (CDA + XDS), API transazionale frequente (FHIR), persistenza con query longitudinali (openEHR)?
• Chi governa il modello clinico? Il team IT/vendor (CDA, FHIR), la comunità clinica internazionale (openEHR)?
• Qual è l’orizzonte di evoluzione? Modello stabile per anni (CDA, FHIR profili nazionali), evoluzione clinica continua (openEHR)?
• Qual è la compatibilità con i programmi nazionali? (in Italia: FHIR IT per FSE 2.0, CDA R2 per documenti legacy)
• Qual è l’interfaccia verso la ricerca? OMOP via ETL, esposizione FHIR Bulk, query openEHR AQL?

Raramente la risposta coinvolge un solo standard. Più spesso, l’architettura tipica del 2025 in un contesto avanzato è:

• FHIR come API di scambio (con profili nazionali — FHIR IT in Italia, US Core negli USA)
• CDA R2 per i documenti archivistici con firma legale e per la retrocompatibilità con i FSE di prima generazione
• openEHR o database FHIR-native come layer di persistenza (scelta architetturale)
• OMOP CDM come data model per l’analitica e per il secondary use (EHDEN, DARWIN EU, EHDS)
• IHE come framework di profili di orchestrazione quando serve trasportare i dati tra domini amministrativi diversi

Nel contesto EHDS

L’European Health Data Space — Regolamento (UE) 2025/327 in vigore da marzo 2025 — non impone un singolo standard ma specifica standard di riferimento armonizzati. Le indicazioni che emergono dai lavori preparatori e dai primi atti di esecuzione della Commissione:

• FHIR R4/R5 come formato principale per il primary use cross-border (MyHealth@EU) e per l’esposizione di dati sanitari ai cittadini
• IPS FHIR come contenuto del patient summary europeo
• Esposizione FHIR o equivalente attesa dagli EHR system certificati EU
• OMOP CDM come formato naturale di secondary use, con il supporto di DARWIN EU e HealthData@EU

CDA R2 non sparisce — gli archivi storici restano — ma non è più il formato di riferimento per le specifiche europee armonizzate. openEHR continua a esistere come layer di persistenza scelto da singoli sistemi, con compatibilità FHIR in esposizione.

Convergenze

Una tendenza strutturale del decennio è la convergenza semantica tra questi standard. Gli stessi concetti clinici — pressione arteriosa, glicemia, allergia, farmaco in uso — hanno rappresentazioni compatibili in CDA R2, FHIR e openEHR, spesso con identici codici LOINC/SNOMED CT. Il lavoro di HL7 International e openEHR Foundation sulle Common Clinical Models va in questa direzione: un concetto clinico modellato una volta, con binding verso FHIR StructureDefinition e openEHR Archetype.

Nel limite, la distinzione tra gli standard riguarderà sempre meno la semantica e sempre più il livello architetturale: chi produce dati usa quello che il sistema interno gli offre, chi li consuma vede un layer di presentazione coerente, i mapper fanno il lavoro di traduzione. È un obiettivo realistico per la fine del decennio corrente.

La scelta non è permanente

Una lezione che la storia dei sistemi sanitari italiani ha insegnato — dalla transizione HL7 v2 a CDA R2 a FHIR — è che la scelta degli standard non è permanente. Un sistema disegnato oggi in FHIR IT con CDA come fallback probabilmente sarà in FHIR R6 o R7 tra dieci anni, con openEHR o database FHIR-native come persistenza, e OMOP come data lake parallelo. La stabilità architetturale si ottiene separando bene i layer, non ancorandosi a uno standard specifico. È una lezione ricorrente ma costosa — ogni generazione di sistemi che non la ha adottata si è trovata a riscrivere integrazioni di larga scala.

Riferimenti: HL7 Clinical Document Architecture, Release 2. HL7 FHIR R4 (Normative) e R5. openEHR Foundation specifications, ISO 13606. OMOP Common Data Model (OHDSI). IHE IT Infrastructure Technical Framework. Regolamento (UE) 2025/327 EHDS.