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 →Il problema: codificare la conoscenza clinica
Uno degli obiettivi storici dell’informatica medica è rappresentare la conoscenza clinica — linee guida, pattern di allerta, raccomandazioni su farmaci, protocolli di monitoraggio — in un formato eseguibile da un sistema informativo, separato dal codice applicativo specifico della cartella. Un allarme per incompatibilità farmaco-allergia, un promemoria per vaccinazione pediatrica, una soglia di attenzione sui risultati di laboratorio sono esempi di regole cliniche che ogni cartella elettronica deve gestire.
Il modo più semplice di farlo è implementarle in codice sorgente (Java, C#, Mumps) all’interno del sistema cartella. Il problema è che il codice è specifico del vendor, manutenuto dai programmatori dell’azienda produttrice, non accessibile al clinico che ne è la fonte di conoscenza. Cambiare una soglia, introdurre una nuova regola, correggere un’imprecisione passa per un ciclo di sviluppo-test-rilascio del software commerciale.
La comunità di informatica medica ha lavorato, dagli anni ‘80 in poi, a linguaggi dedicati che separassero la logica clinica dal codice applicativo, rendendola leggibile e manutenibile da personale sanitario specializzato, portabile tra vendor, condivisibile come bene comune.
Arden Syntax
Il progetto più longevo e più citato è Arden Syntax, nato da una riunione tenutasi nel 1989 alla Arden House (New York), con partecipanti da Columbia-Presbyterian Medical Center, Stanford, Regenstrief Institute e altri centri leader. Il nome deriva dal luogo della prima riunione.
L’unità di codifica è il Medical Logic Module (MLM) — un file di testo strutturato in slot:
- maintenance — metadati: titolo, mantenitore, versione, validazione, istituzione
- library — citazioni bibliografiche, keywords, spiegazione clinica
- knowledge:
- data — binding con il sistema locale (query cartella, lettura da laboratorio); punto critico
- evoke — eventi che attivano l’MLM (nuovo risultato, ricovero, scadenza temporale)
- logic — condizione logica, con sintassi imperativa (assegnamenti, if/then, operatori)
- action — cosa fare se la logica è vera (messaggio all’utente, scrittura in cartella, chiamata a un altro MLM)
- urgency — priorità dell’allerta
- resources — risorse di dati, testo multilingua
Un MLM tipico ha la forma:
maintenance:
title: Potassium-sparing diuretic with potassium supplement;;
mlmname: PotassiumWarning;;
arden: 2.5;;
version: 1.02;;
institution: Example Hospital;;
author: Jane Smith, MD;;
...
data:
active_meds := read last {medications where end_date is null};
...
logic:
if any potassium_sparing_diuretic and any potassium_supplement then
conclude true;
endif;
...
action:
write "Warning: patient on potassium-sparing diuretic
AND potassium supplement — check serum K.";
Arden Syntax 1.0 è diventato standard ASTM nel 1992 ed è passato sotto HL7 nel 1998, che ha rilasciato la versione 2.0 nel 1999. La versione 2.5 è stata approvata ANSI nel 2005 e rappresenta la release corrente di riferimento.
Il problema delle curly braces
Il principale limite storico di Arden Syntax è il curly braces problem: il binding dei dati (slot data) è espresso in sintassi proprietaria racchiusa tra parentesi graffe, non standardizzata. Ogni vendor implementa le proprie query. Un MLM scritto per Cerner non gira per Eclipsys senza riscrivere il data slot. La promessa di portabilità — motore della filosofia Arden — è parzialmente compromessa.
Un’MLM condivide quindi la logica clinica (portabile) ma non il binding dei dati (specifico). È uno dei motivi per cui Arden Syntax è adottato in ambienti chiusi (alcuni CPOE americani, Regenstrief, Columbia, Vanderbilt, Intermountain Healthcare) ma non ha visto l’adozione universale attesa.
GELLO
Il lavoro su un successore di Arden è iniziato in HL7 all’inizio degli anni 2000 con il nome GELLO — Guideline Expression Language, Object-Oriented. GELLO è stato progettato con obiettivi diversi:
- Integrazione con il modello HL7 v3 RIM (Reference Information Model) — il binding ai dati clinici usa il RIM, non query libere specifiche del vendor. Risolve formalmente il problema delle curly braces
- Object-oriented — basato su OCL (Object Constraint Language) di OMG, con sintassi di espressione dichiarativa, simile in spirito a SQL o a OCL stesso
- Separazione tra linguaggio di espressione e logica di workflow — GELLO è puramente expression, il workflow è gestito separatamente
GELLO è stato approvato come standard HL7 nel 2005; la comunità sta valutando l’interazione con CDA R2, con vMR (virtual Medical Record), e l’uso in sistemi CDS. Un working draft della versione 2 è in preparazione per introdurre miglioramenti di ergonomia sintattica.
Il potenziale di GELLO è sostanziale ma l’adozione nel 2006 è limitata: manca un motore di riferimento open source maturo, e la dipendenza dal modello HL7 v3 RIM — complesso — rallenta l’ingresso di vendor commerciali.
Altri approcci
Arden e GELLO non sono gli unici linguaggi di CDS. La letteratura e la pratica internazionale includono:
- GLIF (Guideline Interchange Format) — McGill, Stanford, Columbia, fondata a fine anni ‘90. Modello di rappresentazione di linee guida cliniche come flowchart di decisioni. Formato XML. Con associate implementazioni reference come GLIF interpreters
- PROforma — Cancer Research UK (poi Oxford, OpenClinical), linguaggio logico-argomentativo basato su un calcolo dei tasks (enquiry, decision, action, plan). Runtime Tallis
- Asbru — TU Vienna, specializzato in linee guida con componente temporale (protocolli oncologici, sequenze di trattamento)
- SAGE (Standards-Based Active Guideline Environment) — consorzio GE, IDX, Mayo, Intermountain, University of Nebraska, per implementare linee guida su basi HL7
- EON — Stanford, modello precursore di SAGE
Nessuno di questi linguaggi ha raggiunto la diffusione di Arden Syntax; nessuno ha risolto del tutto il problema del binding ai dati.
CDS in pratica nel 2006
Nonostante la ricchezza di linguaggi e standard, il CDS operativo nella pratica clinica del 2006 si appoggia più spesso a motori proprietari dei vendor EHR (Epic, Cerner, Eclipsys, McKesson, AllScripts):
- Motori di drug-drug interaction (First Databank, Medi-Span come fonti di conoscenza)
- Motori di alert on order entry — criteri di appropriatezza, dosaggi, allergie
- Motori di reminder system — vaccinazioni, screening, follow-up
- Order sets — percorsi prescrittivi pre-confezionati per patologie specifiche
Regole interne ai vendor, a volte codificate in dialetti Arden-like, a volte in Java/XML proprietari. La trasportabilità tra sistemi diversi resta bassa.
Implementazioni open source
L’ecosistema open source di runtime CDS è, al 2006, ancora limitato:
- Arden2ByteCode e strumenti accademici sperimentali per esecuzione MLM
- PROforma / Tallis di OpenClinical — runtime Java disponibile in versione libera
- Drools (JBoss, di cui si parlerà separatamente) — motore di regole general-purpose non medico-specifico ma applicabile
- Jess (Rete in Java) — motore di regole accademico da Sandia National Labs
Mancanti: un motore Arden open source completo e production-ready; un motore GELLO di riferimento; un ambiente di authoring di MLM accessibile ai clinici non programmatori.
Lo scenario italiano
In Italia, al 2006, l’adozione di linguaggi di CDS standardizzati è molto limitata. Le cartelle cliniche aziendali italiane hanno regole di allerta, ma codificate in modo proprietario dal vendor. Alcuni progetti accademici (Università di Pavia, Università di Messina, Istituto Mario Negri) esplorano GLIF/Asbru per scenari specifici — oncologia, epidemiologia. L’ingresso di Arden/GELLO nei capitolati di acquisto pubblici è ancora lontano.
HL7 Italia include un gruppo di lavoro CDS, più orientato al monitoraggio del lavoro internazionale che alla produzione di profili italiani specifici. La concentrazione del programma FSE nazionale (avviato dopo il 2007-2008) sulla parte documentale rende la priorità CDS relativamente minore nel medio periodo.
Prospettive
Il futuro di Arden/GELLO — e del CDS standardizzato in generale — dipenderà da alcuni fattori:
- Disponibilità di motori di riferimento open source maturi che consentano adozione anche ai centri senza partner commerciali
- Integrazione con i modelli informativi clinici emergenti (HL7 v3, CDA R2, e quello che HL7 sta cominciando a discutere come alternativa — una nuova specifica web-oriented è in fase esplorativa)
- Domanda clinica — la pressione sui sistemi sanitari per ridurre errori medici (pubblicata dal famoso report IOM “To Err Is Human” del 1999) aumenta la richiesta di supporto alle decisioni attive e rigorosi
- Politiche di incentivo pubblico — alcuni paesi introducono incentivi finanziari per EHR con funzionalità di CDS certificate
Il salto generazionale più promettente sarà, probabilmente, una standardizzazione basata su web services — in cui la cartella chiama un servizio remoto di CDS con il contesto paziente, e riceve una raccomandazione strutturata. Un’evoluzione lungo queste linee è attesa negli anni a venire. Arden Syntax e GELLO conservano la loro rilevanza come linguaggi di rappresentazione della conoscenza, indipendentemente dall’architettura di esecuzione che prevarrà.
Riferimenti: Arden Syntax for Medical Logic Modules, HL7 v2.5 (ANSI 2005). GELLO — Guideline Expression Language, Object-Oriented, HL7 standard (2005). ASTM E1460 (Arden Syntax 1.0, 1992). GLIF, PROforma, Asbru, SAGE, EON — letteratura accademica. OpenClinical (www.openclinical.org). Jess — Sandia National Laboratories. IOM — To Err Is Human, 1999.