CDA R2, FHIR e openEHR rispondono a tre domande tecniche diverse, e l’errore più comune nelle architetture sanitarie è trattarli come alternative tra cui scegliere. Modellano tutti dati clinici, ma il dominio condiviso non li rende intercambiabili: stanno a livelli diversi di un sistema. La domanda da farsi non è quale dei tre adottare, ma che problema risolve ciascuno e cosa succede quando lo si mette dove non dovrebbe stare.

Contesto

HL7 Clinical Document Architecture Release 2 (CDA R2) è standard ANSI dal 2005, e deriva dal Reference Information Model di HL7 v3. HL7 Fast Healthcare Interoperability Resources (FHIR) ha avuto la prima bozza nel 2014, la release R4 con parti normative nel 2018, la R5 a marzo 2023. openEHR è specificato dall’omonima Foundation dal 2003, con ISO 13606 come standard formalmente equivalente per comunicare estratti di cartella clinica.

Tre date, tre contesti, tre problemi diversi. Conviene ricostruirli prima di metterli a confronto, perché il confronto regge solo se si parte dalla domanda originaria di ciascuno.

CDA R2: l’unità archivistica

CDA R2 risponde a una domanda precisa: come rappresentare un documento clinico perché resti leggibile e valido anche quando il sistema che lo ha prodotto non esiste più. I tratti portanti sono quelli del documento, scritti nero su bianco nella specifica: persistenza, custodia (un’organizzazione responsabile identificata), possibilità di autenticazione, integrità, contesto, leggibilità umana garantita.

Un documento CDA è un’entità chiusa in sé. Ha un autore, un custode, una possibile firma legale e un foglio di stile XSLT che ne garantisce la resa visiva qualunque sia l’applicativo che lo apre. Lettera di dimissione, referto di laboratorio, patient summary, verbale di pronto soccorso: ognuno è un atto con una propria identità giuridica e un proprio ciclo di vita.

Nei Fascicoli Sanitari Elettronici europei di prima generazione — quello italiano compreso — CDA R2 è il formato dei documenti pubblicati e condivisi, trasportati dai profili IHE XDS.b e XCA. I limiti sono altrettanto noti: una sola serializzazione, in XML; nessuna API di scambio definita dallo standard, che la delega a framework esterni come IHE; una granularità a livello di entry che si presta male all’aggregazione analitica. La complessità ereditata dal RIM rende la curva di apprendimento ripida.

FHIR: la risorsa transazionale

FHIR risponde a un’altra domanda: come scambiare dati clinici in modo granulare e frequente tra sistemi diversi, con le convenzioni del web. L’unità non è il documento ma la risorsa — Patient, Observation, MedicationRequest — atomica, identificata da un URL, componibile per riferimento.

Il modello è quello di un’API REST: verbi HTTP, due serializzazioni equivalenti (JSON e XML), estensibilità tramite Extension, un design guidato dalla conformità in cui i Profile sono leggibili dalle macchine. FHIR dà il meglio dove servono interazioni frequenti e dati a grana fine: un’app che consulta lo stato clinico, l’integrazione dei servizi di supporto decisionale via CDS Hooks, l’alimentazione di un repository, l’export massivo per l’analitica.

Quello che FHIR non dà di suo è la dimensione archivistica. Una risorsa non porta con sé un autore unico, una firma, una custodia: non fanno parte di com’è costruita. Il Bundle di tipo document copre gli scenari documentali, ma per rispettare gli obblighi di conservazione a norma serve comunque un framework esterno: il documento FHIR è una composizione di risorse, non un’unità conservata di per sé.

openEHR: la persistenza che evolve

openEHR risponde a una terza domanda: come memorizzare dati clinici perché il modello clinico possa cambiare nel tempo senza riscrivere database e applicazioni. La risposta è il modello a due livelli. Un Reference Model tecnico, stabile e generico, definisce lo schema dei dati. Sopra, un livello clinico governato da chi fa clinica, fatto di archetipi scritti in ADL (Archetype Definition Language); i template compongono gli archetipi per il caso d’uso concreto.

I dati vengono memorizzati secondo il Reference Model e annotati con i percorsi degli archetipi. Le interrogazioni passano per AQL (Archetype Query Language), che lavora sui percorsi clinici a prescindere dallo schema fisico del database. Aggiungere un campo a un archetipo non richiede una migrazione di schema: il livello tecnico resta fermo, cambia l’annotazione clinica.

Il suo terreno naturale è la conservazione di dati strutturati dove l’evoluzione del modello è un requisito dichiarato: repository clinici regionali, cartelle longitudinali, piattaforme di ricerca. La governance degli archetipi tramite il Clinical Knowledge Manager è un tratto suo — lo stesso archetipo della pressione arteriosa è condiviso tra sistemi di paesi diversi. openEHR non è uno standard di scambio in senso stretto: quando deve comunicare verso l’esterno lo fa esponendo FHIR, esportando documenti CDA o tramite la propria REST API.

Il punto critico

Il problema architetturale serio nasce quando uno standard viene messo nel ruolo di un altro. Tre attriti che tornano spesso.

Usare CDA come API transazionale. Un documento è fatto per essere pubblicato e recuperato intero, non interrogato campo per campo. Trattarlo come una risorsa granulare vuol dire parsare XML pesante a ogni lettura, senza i verbi e i meccanismi di ricerca che FHIR offre di suo. Lo scambio frequente diventa costoso e fragile.

Usare FHIR come archivio legale. Una risorsa o un Bundle non hanno, per costruzione, le garanzie documentali del CDA. Le si possono ricostruire — firma, custodia, immutabilità — ma fuori dallo standard, con un framework di conservazione che riporta dentro proprio la complessità documentale che si voleva evitare. Si finisce per reimplementare CDA sopra FHIR.

Esporre openEHR come formato di scambio. Gli archetipi servono alla governance interna e alla conservazione, non a fare da contratto verso terzi. La strada prevista è mapparli su FHIR in esposizione: openEHR resta il modo in cui i dati sono memorizzati, FHIR il modo in cui sono visti da fuori. Pubblicare archetipi grezzi come interfaccia significa esportare il proprio modello interno, e da quel momento chi lo consuma ci resta legato.

Il filo comune è uno solo: ogni standard porta vincoli che vengono dalla sua domanda originaria. Forzarlo altrove non li cancella, li scarica a valle sotto forma di codice di adattamento.

Implicazioni

Le architetture mature non scelgono un solo standard, li dispongono su livelli diversi. Due combinazioni che si osservano nei sistemi europei:

  • CDA e FHIR affiancati. È lo scenario del Fascicolo Sanitario Elettronico italiano: documenti CDA già esistenti e profili FHIR italiani convivono sul gateway, che espone sia interfacce SOAP/XDS per i sistemi legacy sia FHIR REST per le applicazioni nuove. I documenti nati CDA restano CDA, quelli nuovi nascono FHIR.
  • openEHR come repository, FHIR come API. I dati clinici sono memorizzati nativamente in openEHR con archetipi governati; l’accesso esterno passa per un layer FHIR che traduce al volo. È il pattern di diversi sistemi regionali europei. openEHR non si vede mai da fuori, FHIR non è mai il formato di conservazione.

Sul piano normativo, il Regolamento (UE) 2025/327 che istituisce lo European Health Data Space è entrato in vigore il 26 marzo 2025, con applicazione scaglionata negli anni successivi. Non impone un singolo standard, ma indica FHIR come formato di riferimento per l’uso primario transfrontaliero attraverso MyHealth@EU, con l’International Patient Summary in profilo FHIR come contenuto del patient summary europeo. CDA R2 non sparisce — gli archivi storici restano e vanno conservati — ma smette di essere il formato di riferimento delle specifiche armonizzate europee.

Limiti

Questa mappa è un’astrazione, e le astrazioni perdono dettagli. Tre cautele.

I confini non sono netti come fa pensare uno schema a tre colonne. FHIR copre scenari documentali con il Bundle, openEHR si può usare anche per lo scambio in contesti chiusi, e una parte dell’industria conserva direttamente su database FHIR-native saltando openEHR. La divisione documento/transazione/persistenza è un criterio di progetto, non una legge fisica.

Il costo di un’architettura a più livelli è reale: ogni mapping è codice da scrivere, testare e mantenere, e la convergenza semantica tra gli standard — concetti clinici con codici LOINC e SNOMED CT condivisi — riduce l’attrito di traduzione ma non lo azzera. Un sistema con un solo standard è più semplice, finché non incontra il requisito che quel singolo standard non sa servire.

Infine, la scelta non è per sempre. La storia dei sistemi italiani, dal passaggio da HL7 v2 a CDA fino a FHIR, dice che la vita di uno standard è più breve della vita di un sistema sanitario. La stabilità si ottiene separando bene i livelli, così che cambiare lo standard di un layer non costringa a riscrivere gli altri. È una lezione che torna a ogni generazione, e chi non l’ha applicata ha pagato il conto riscrivendo le integrazioni.

https://www.hl7.org/implement/standards/product_brief.cfm?product_id=7 https://hl7.org/fhir/R5/ https://hl7.org/fhir/versions.html https://specifications.openehr.org/ https://www.iso.org/standard/67868.html https://eur-lex.europa.eu/eli/reg/2025/327/oj/eng https://www.ihe.net/resources/technical_frameworks/ https://www.noze.it/insights/openehr-vs-fhir-vs-cda/

Immagine di copertina: Diagramma a classi dell’HL7 Reference Information Model: riquadri collegati da linee che rappresentano le classi base del modello… — diagramma di Darek098, CC BY-SA 3.0 — https://commons.wikimedia.org/wiki/File:Hl7rim.jpg