In openEHR il significato clinico di un dato vive in un artefatto separato dal codice e dallo schema del database — l’archetipo — scritto in un linguaggio formale e versionato per conto suo, indipendentemente dal software che lo esegue. È qui che openEHR si stacca dalle altre scuole dell’interoperabilità sanitaria, costruite invece attorno al formato dei messaggi scambiati.

Contesto

Quando si parla di standard per la cartella clinica elettronica, il riferimento più diffuso è la famiglia HL7: messaggi v2, documenti CDA R2 e, da pochi anni, le risorse FHIR, ancora allo stadio di Draft Standard for Trial Use. Tutte queste tecnologie risolvono un problema di scambio: come spostare un dato clinico da un sistema a un altro. openEHR affronta un problema diverso, quello della rappresentazione e della persistenza native del dato clinico nel tempo.

Le radici stanno nei progetti europei degli anni Novanta: il Good European Health Record (GEHR), finanziato nel terzo programma quadro UE tra il 1992 e il 1995, e i lavori successivi confluiti nella openEHR Foundation, ente non profit con sede nel Regno Unito. Il problema osservato allora vale ancora oggi. La conoscenza medica cambia di continuo, mentre i sistemi software hanno cicli di rilascio lunghi e costosi. Ogni volta che cambia un protocollo clinico, qualcuno deve mettere mano a schemi, query e interfacce. Su dieci o vent’anni questo diventa insostenibile.

Architettura

La risposta di openEHR è la modellazione a due livelli. Il livello inferiore è il Reference Model (RM): una piccola famiglia di classi dalla semantica del tutto generica, implementata una volta nel software e tenuta apposta ferma. Le classi strutturali principali sono COMPOSITION (il contenitore di un atto clinico, vicino all’idea di documento), SECTION (raggruppamento), OBSERVATION (rilevazioni e misure), EVALUATION (giudizi, diagnosi, valutazioni di stato), INSTRUCTION (ordini e piani) e ACTION (azioni eseguite). Sopra queste sta una famiglia di tipi di dato: DV_QUANTITY, DV_CODED_TEXT, DV_TEXT, DV_DATE_TIME, DV_ORDINAL, DV_PROPORTION e altri.

Il livello superiore è quello degli archetipi. Un archetipo descrive un concetto clinico — la pressione arteriosa, il peso corporeo, una lista dei problemi, l’anamnesi familiare — vincolando le classi del RM. L’archetipo della pressione arteriosa, per dire, dichiara una OBSERVATION che contiene due DV_QUANTITY (sistolica e diastolica, in millimetri di mercurio), più alcuni campi opzionali per la posizione del paziente, il punto di misura, la dimensione del bracciale. I vincoli sono scritti in forma esplicita — cardinalità, intervalli, terminologie ammesse — e quindi una macchina li può verificare.

Gli archetipi si scrivono in ADL (Archetype Definition Language). La versione stabile è ADL 1.4, rilasciata nel 2007 e rivista nel 2008 nell’ambito di AM Release 1.0.2; il modello a oggetti che le corrisponde è l’Archetype Object Model (AOM 1.4). Una definizione ADL è un file di testo a struttura gerarchica che dichiara il concetto, i vincoli, i legami con le terminologie e le traduzioni linguistiche — ogni archetipo nasce multilingue. Una revisione ADL 2 è in lavorazione da tempo, ma non è ancora standard.

Sopra gli archetipi stanno i template: aggregazioni pensate per un caso d’uso preciso — una scheda di triage, uno schema di monitoraggio post-operatorio — che selezionano gli archetipi rilevanti per quella situazione e li restringono ancora.

Per interrogare i dati c’è AQL (Archetype Query Language): un linguaggio dichiarativo che scrive le query lungo i percorsi archetipali anziché sulle colonne delle tabelle. Una query AQL del tipo «tutte le glicemie a digiuno sopra una certa soglia» si scrive contro il modello clinico, senza sapere nulla dello schema fisico di memorizzazione sottostante.

Punto critico

Il fatto tecnicamente decisivo è che archetipi e template sono dati di runtime, non codice. Il software conosce solo il Reference Model; carica archetipi e template a esecuzione e li interpreta. Aggiungere o modificare un concetto clinico vuol dire pubblicare un nuovo archetipo o un nuovo template, non ricompilare l’applicazione né migrare lo schema del database.

Così si sposta il confine di responsabilità. La definizione di cosa sia clinicamente la pressione arteriosa diventa un artefatto che un medico può leggere, discutere e correggere senza essere un programmatore. Per tenere tutto questo governabile su scala internazionale, la openEHR Foundation mantiene un repository pubblico, il Clinical Knowledge Manager (CKM), dove gli archetipi vengono proposti, revisionati da commissioni di clinici e pubblicati lungo un ciclo di vita formale (bozza, revisione, consenso, versionamento). Il CKM nella forma attuale è in funzione dal 2009. L’idea di fondo è che l’archetipo di Body weight usato in Norvegia, in Australia o nel Regno Unito sia lo stesso archetipo, discusso in un solo posto; le specializzazioni locali restano possibili, ma derivate da quelle internazionali.

Implicazioni

Con ISO 13606 — lo standard per la comunicazione di Electronic Health Record, diviso in cinque parti — c’è un rapporto diretto e spesso frainteso. ADL 1.4 e AOM 1.4 sono la base della parte 2 di ISO 13606 (Archetype Interchange Specification): il Reference Model di ISO 13606 è un sottoinsieme compatibile con quello openEHR, e i due dialetti di archetipo combaciano. L’ambito però cambia nettamente: ISO 13606 normalizza la comunicazione di EHR tra sistemi (export e import), mentre openEHR copre anche la persistenza nativa. In pratica un repository openEHR può esportare estratti conformi a ISO 13606 spendendoci poco in più.

L’adozione, nel 2015, è concentrata in pochi paesi. La Slovenia ha una piattaforma nazionale costruita su tecnologia openEHR; la Norvegia ha programmi regionali; Regno Unito, Australia e Finlandia hanno progetti di peso, spesso costruiti su clinical data repository più che sullo scambio di documenti. In Italia l’adozione resta confinata alla ricerca e a qualche progetto isolato, mentre l’infrastruttura del Fascicolo Sanitario Elettronico è ancorata a HL7 CDA R2; openEHR compare nel dibattito tecnico come possibile strato di modellazione clinica sotto gli standard di trasporto, non come loro alternativa.

Limiti

Il prezzo della separazione è la disciplina di modellazione che serve a monte. Per produrre dati interoperabili occorre un governo degli archetipi attivo e competente; senza, ogni progetto ridefinisce i propri concetti e si ritrova la stessa frammentazione semantica che il modello vorrebbe scongiurare, solo a un livello più alto. L’ecosistema implementativo, poi, è più stretto di quello HL7: meno strumenti maturi, meno fornitori. AQL, per quanto solido sul piano concettuale, ha implementazioni disomogenee e prestazioni che dipendono parecchio da come il repository materializza i percorsi archetipali. E il guadagno vero — un sistema che evolve aggiornando un archetipo invece di fare una migrazione — si vede su orizzonti lunghi, mentre il costo d’ingresso lo paghi subito. Il ritorno tocca a chi pianifica per la durata e accetta di pagare in anticipo.

https://specifications.openehr.org/releases/AM/latest/ADL1.4.html https://specifications.openehr.org/releases/AM/latest/AOM1.4.html https://specifications.openehr.org/releases/QUERY/latest/AQL.html https://specifications.openehr.org/releases/BASE/latest/architecture_overview.html https://ckm.openehr.org/ckm/ https://www.noze.it/insights/openehr-archetipi-clinici/

Immagine di copertina: Diagramma del framework semantico di openEHR: i riquadri Reference Model, Archetypes e Templates, le query AQL e la Terminology che… — diagramma di openEHR International, CC BY-SA 3.0 — https://commons.wikimedia.org/wiki/File:Openehr_4pillars.png