OpenCDS espone la logica di supporto alle decisioni cliniche come un servizio di rete: riceve i dati di un paziente e restituisce raccomandazioni strutturate, invece di vivere come libreria compilata dentro una singola cartella elettronica. È un’implementazione di riferimento, in licenza Apache 2.0, di due specifiche HL7 — la Decision Support Service e il virtual Medical Record — che tengono separata la conoscenza clinica dal sistema che la consuma.

Contesto

Per anni il supporto alle decisioni cliniche (CDS, Clinical Decision Support) è stato più una questione di linguaggi per rappresentare la conoscenza che di servizi operativi. L’Arden Syntax, lo standard HL7 per i Medical Logic Modules, descrive una regola clinica come testo eseguibile; GELLO definisce un linguaggio di espressioni per interrogare un modello dati clinico. Tutti e due risolvono il problema di come scrivere una regola, non quello di come distribuirla a più ospedali e a cartelle diverse senza riscriverla ogni volta.

Il curly braces problem dell’Arden Syntax lo mostra bene: la sintassi lascia indefinito il modo in cui una variabile clinica viene letta dalla cartella locale, e così ogni installazione deve riempire a mano quelle parentesi graffe. La logica è portabile; il legame con i dati no.

OpenCDS nasce nel 2010 da un consorzio guidato dall’Università dello Utah, con Kensaku Kawamoto — co-chair del gruppo HL7 sul Clinical Decision Support — come figura tecnica centrale e con il coinvolgimento del Department of Veterans Affairs statunitense. La prima release pubblica è del 2011.

Architettura

OpenCDS è un’applicazione Java che pubblica un endpoint DSS (Decision Support Service), specifica diventata standard normativo HL7 nel 2011 dopo il passaggio per l’Object Management Group. DSS descrive l’interfaccia, non l’implementazione: il client chiama il servizio passando l’identificatore del knowledge module richiesto e i dati del paziente, e si vede tornare valutazioni e raccomandazioni. Il trasporto è un web service SOAP, in linea con l’integrazione enterprise dell’epoca.

I dati del paziente viaggiano nel formato vMR (virtual Medical Record), il modello informativo HL7 — in via di consolidamento come Domain Analysis Model — che serializza in XML problemi attivi, farmaci, risultati di laboratorio, procedure e anagrafica. Il vMR è il contratto che tiene il servizio indipendente dalla cartella: il chiamante traduce il proprio schema interno in vMR, e il servizio non vede altro.

Il flusso interno ha quattro passaggi:

  • l’endpoint DSS riceve la richiesta e deserializza il vMR;
  • un data layer trasforma le entità cliniche del vMR in fatti per il motore di regole;
  • il motore — costruito su Drools, con regole scritte in .drl o come decision table — valuta i fatti contro il knowledge module richiesto;
  • un output layer ricostruisce dalle conclusioni la risposta DSS, con raccomandazioni, razionale e rimandi alle linee guida.

Il deployment tipico è on-premise presso l’istituzione sanitaria, con una o più cartelle che chiamano il server via web service. La conoscenza clinica vive in un repository di knowledge module tenuti separati dal motore, ciascuno con i propri metadati e la propria versione.

Il nodo difficile

Il difficile non è il motore: Drools è un sistema di produzione RETE maturo, e il round-trip di una chiamata DSS resta sotto il secondo per moduli di media dimensione. Il difficile è scrivere e mantenere i knowledge module.

Un modulo di OpenCDS è codice Drools: regole .drl che operano su fatti generati dal vMR. Per scriverlo servono competenze di programmazione, non solo cliniche. Chi conosce la linea guida — l’epidemiologo, il farmacologo, il pediatra — non scrive .drl; chi scrive .drl non possiede la linea guida. In mezzo c’è un passaggio di traduzione manuale, soggetto a errori e difficile da validare in modo formale. Le decision table Excel alleggeriscono il problema per regole tabellari semplici, ma non reggono logiche con dipendenze temporali o ramificazioni profonde.

Poi c’è il ciclo di vita dell’artefatto. Una regola clinica poggia su un’evidenza che cambia: una soglia di dose viene rivista, una raccomandazione di screening si aggiorna, un farmaco entra in interazione con un altro. Servono versionamento, validazione clinica documentata, tracciabilità della linea guida sottostante e un processo di ritiro dei moduli superati. OpenCDS dà il contenitore tecnico — il repository, i metadati — ma è il processo organizzativo che lo riempie e lo mantiene a decidere se il sistema regge in produzione. Lo standard porta la regola da un ospedale all’altro; non porta con sé chi garantisce che la regola sia ancora corretta.

Implicazioni

Esporre il CDS come servizio standard ha una conseguenza diretta sull’integrazione: il punto di contatto tra cartella e logica clinica diventa un’interfaccia documentata (DSS) su un formato documentato (vMR), e non un plugin legato a un prodotto. In teoria lo stesso knowledge module per le vaccinazioni pediatriche secondo i calendari ACIP del CDC può servire una cartella open source e una commerciale, purché entrambe sappiano produrre e leggere vMR.

Così il costo di adozione si sposta sull’adapter di traduzione. Cartelle open source come OpenMRS hanno prototipato l’integrazione con OpenCDS; le cartelle commerciali americane hanno soluzioni interne proprie e un incentivo debole a esporre i propri dati in vMR. Il modello vale di più quanti più moduli condivisibili circolano, e al 2012 quel numero è basso.

Il ruolo del Department of Veterans Affairs qui pesa più come segnale che come volume. Il VA gestisce una cartella open source con funzioni CDS storiche; investire in un layer CDS esterno e standardizzato dice una scelta architetturale precisa — la logica clinica come componente riutilizzabile, indipendente dalla cartella che la ospita.

Limiti

OpenCDS al 2012 è un progetto giovane dai confini netti. La libreria di knowledge module distribuita è fatta soprattutto di esempi di riferimento — immunizzazioni, calcolo del BMI, controlli di dose — non di contenuto pronto per la produzione senza adattamento al contesto di chi lo adotta. L’authoring resta in mano a chi sa programmare in Drools. Manca ancora un catalogo condiviso di moduli validati e versionati: senza un ecosistema di curatori riconosciuti, ogni istituzione finisce per ricostruire la propria conoscenza.

L’adozione è ristretta a centri sperimentali statunitensi e a prime presentazioni nei gruppi di lavoro HL7. In Italia il tema vive in qualche progetto di ricerca: scarseggiano cartelle con API di integrazione HL7 v3 vMR diffuse, moduli clinici italiani validati sulle linee guida nazionali e un investimento istituzionale paragonabile a quello del VA. Il lavoro HL7 su FHIR, ancora agli inizi, lascia poi aperta la prospettiva che il formato dati in ingresso evolva, con la necessità per OpenCDS di reggere più rappresentazioni del paziente nel tempo.

Immagine di copertina: Diagramma schematico dell’algoritmo Rete con reti alpha e beta e nodi di produzione collegati, alcuni evidenziati in verde come nodi… — diagramma di Razorbliss, CC0 — https://commons.wikimedia.org/wiki/File:Rete.svg