HL7 CDA R2: i documenti clinici strutturati e i profili italiani

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 →

Dal messaging al documento

Lo standard HL7 v2 descrive eventi attraverso messaggi: un ricovero, una prescrizione, un referto appena prodotto. Ci sono però informazioni cliniche che hanno la natura del documento: una lettera di dimissione ospedaliera, un verbale di pronto soccorso, un patient summary. Hanno un autore identificato, una firma legale, una versione, un ciclo di vita proprio — e per questo HL7 ha sviluppato uno standard separato e complementare: la Clinical Document Architecture.

La versione 1 del CDA è stata pubblicata nel 2000 (allora Patient Record Architecture), e la Release 2 (CDA R2) è stata approvata come standard ANSI nel 2005. Da allora CDA R2 è il formato documentale di riferimento per lo scambio di documenti clinici tra sistemi — e, soprattutto, per l’alimentazione dei Fascicoli Sanitari Elettronici nazionali e regionali in Italia e in Europa.

Il modello: RIM, XML, sei principi

CDA R2 deriva dal Reference Information Model di HL7 v3. Gli oggetti informativi (Act, Observation, Procedure, Organization, Patient, Encounter) e le loro relazioni sono modellati secondo RIM, e serializzati come XML. Lo schema del documento è definito da un XSD ufficiale; la trasformazione per la presentazione al professionista avviene tramite un foglio di stile XSLT standard.

Lo standard è costruito intorno a sei principi, esplicitati da HL7:

1. Persistenza — il documento esiste in uno stato immutabile per un periodo definito
2. Responsabilità (stewardship) — è mantenuto da un’organizzazione incaricata
3. Autenticazione potenziale — è firmabile legalmente
4. Contesto — stabilisce un contesto predefinito per tutto il contenuto
5. Interezza (wholeness) — l’autenticazione vale sul documento intero
6. Leggibilità umana (human readability) — il contenuto narrativo è leggibile senza strumenti specifici

La struttura: Header e Body

Ogni documento CDA R2 è costituito da due parti:

• Header — metadati machine-readable: identificativo del documento, tipo di documento (un codice LOINC in code), paziente (recordTarget), autori (author), custode (custodian), validatore legale (legalAuthenticator), documenti correlati (relatedDocument), organizzazione di erogazione (componentOf / encompassingEncounter)
• Body — contenuto clinico, che può essere nonXMLBody (PDF o altro file incapsulato) oppure structuredBody suddiviso in section

Ogni sezione contiene una parte narrativa <text> — leggibile dall’utente finale tramite l’XSLT di rendering — e, opzionalmente, <entry> strutturate e codificate. L’obbligo della leggibilità umana si concretizza nella relazione tra narrativa ed entry: la narrativa non è dedotta dalle entry, ma ne è la rappresentazione autoritativa; le entry sono un’annotazione computabile sulla narrativa.

I tre livelli

CDA R2 definisce tre livelli di strutturazione:

• Livello 1 — documento con header strutturato e body narrativo (anche PDF incapsulato). Minima formalizzazione delle informazioni cliniche
• Livello 2 — sezioni codificate (identificate da un codice LOINC o equivalente) con contenuti ancora prevalentemente narrativi
• Livello 3 — entry completamente strutturate, con osservazioni, procedure e valori codificati rispetto a terminologie controllate (SNOMED CT, LOINC, ICD-9-CM/ICD-10, ATC, …)

La scelta del livello è una decisione progettuale: un livello 3 completo consente analisi e reasoning automatici, ma richiede produzione strutturata da parte dei sistemi cartella; un livello 1 è sempre producibile a partire da un documento già esistente in forma testuale.

I profili italiani

CDA R2 è uno standard ampio: per un uso effettivo nei sistemi nazionali servono profili di implementazione (Implementation Guide) che ne restringano l’opzionalità, ne precisino i vincoli e specifichino le terminologie. In Italia questo lavoro è svolto da HL7 Italia, associazione affiliata di HL7 International, in collaborazione con il Ministero della Salute, AgID e il Tavolo Tecnico sul Fascicolo Sanitario Elettronico.

I profili italiani CDA R2 di prima generazione si concentrano sui documenti clinici più rilevanti per il FSE:

• Lettera di Dimissione Ospedaliera (LDO) — il documento principale al termine di un ricovero, con anamnesi, diagnosi, terapie eseguite, esami significativi, terapia alla dimissione, indicazioni al curante
• Referto di Laboratorio — risultati di esami di laboratorio, strutturati in osservazioni codificate LOINC con valori di riferimento, unità di misura, osservazioni testuali
• Verbale di Pronto Soccorso — documento di chiusura di un accesso in PS con triage, anamnesi, diagnosi, procedure, esito, dimissione
• Profilo Sanitario Sintetico (Patient Summary) — vista di sintesi del paziente: anagrafica, problemi attivi, allergie, terapia in corso, vaccinazioni
• Referto di Radiologia — versione CDA del referto testuale, con possibile integrazione con studi DICOM correlati
• Prescrizione specialistica e farmaceutica

Ogni profilo specifica:

• Il templateId del documento e delle sezioni (OID sotto il root italiano 2.16.840.1.113883.2.9)
• Le sezioni obbligatorie e facoltative con il codice LOINC di ciascuna
• Le terminologie ammesse per ogni entry (ATC per farmaci, ICD-9-CM per diagnosi codificate, LOINC per osservazioni)
• Le regole di trasformazione XSLT per la presentazione

La firma e la conservazione

I documenti CDA R2 destinati al FSE devono essere firmati digitalmente (CAdES o XAdES sul file XML) dal medico autore o legal authenticator, e conservati nel rispetto del Codice dell’Amministrazione Digitale. L’integrazione con i sistemi di firma remota e HSM ospedalieri è uno degli snodi implementativi più delicati, insieme alla gestione del ciclo di vita dei documenti (annullamento, sostituzione, addendum) che lo standard gestisce tramite relatedDocument.

Strumenti

La produzione e il consumo di CDA R2 sono supportati da strumentazione aperta:

• MDHT (Model-Driven Health Tools) — progetto Eclipse/OpenHealthTools per la generazione di API Java a partire da modelli MDMI/UML di CDA, con validazione automatica rispetto al profilo
• HAPI Structures CDA — libreria Java della famiglia HAPI, parte dell’ecosistema di University Health Network
• Schematron italiani — HL7 Italia distribuisce schemi Schematron che validano l’aderenza di un’istanza CDA al profilo italiano, complementari alla validazione XSD

Lo scenario non è privo di attriti: la complessità di CDA R2 — ereditata dal modello RIM — è oggetto di critiche ricorrenti, e i tempi di produzione di un documento di livello 3 coerente sono non banali. Proprio queste criticità stanno spingendo HL7 a lavorare, in parallelo a CDA, a un nuovo modello orientato a risorse e API REST; il lavoro è iniziato e dovrebbe portare a una prima versione pubblica nei prossimi anni.

Nel FSE

Per il FSE italiano, CDA R2 è oggi — al 2013 — il formato di alimentazione previsto. I documenti prodotti dagli erogatori vengono indicizzati e condivisi attraverso la cornice IHE XDS (profili XDS.b, XDS-SD per i documenti scansionati), con il registro regionale che gestisce i metadati e il repository che archivia i file. Il pieno dispiegamento attende le regole tecniche operative — il DPCM attuativo dell’articolo 12 del DL 179/2012, atteso nei prossimi anni.

Riferimenti: HL7 Clinical Document Architecture, Release 2 (ANSI/HL7 CDAR2-2005). HL7 Reference Information Model (RIM). Profili CDA R2 HL7 Italia. IHE Content Profiles (XDS-SD, CCD). MDHT — Eclipse Model Driven Health Tools.