Linguaggi per la specifica e la verifica di linee guida in campo medico

1. Linguaggi per la specifica e la verifica di linee guida in campo medico DEIS – Università di Bologna ENDIF – Università di Ferrara Sergio Storari

2. Sommario • Esempio di formalizzazione • Linguaggio grafico per la formalizzazione • Raccolta di eventi interessanti • Conclusioni e attività future

3. Medical guidelines formalization ICs SOKB SOKB ICs GOAL SEKB Proof procedure Abbiamo formalizzato manualmente una linea guida medica tramite ICs Infezioni Microbiologiche Screening cancro al seno e pap-test

4. Linea guida microbiologica • Abbiamo identificato: • Tutti gli attori coinvolti: • Paziente, Pronto Soccorso, Medico, … • Tutte le interazioni: • Visita, Ricovero, Richiesta di test, … Patiente Medico

5. Considerazioni • La linea guida è stata correttamente formalizzata e testata su diverse history (conformi o no) • Diversi strumenti per la formalizzazione sono proposti in letteratura • La nostra proposta offre un diverso punto di vista: • Tutti gli attori della linea guida sono esplicitamente modellati (non solo il paziente) • Tutte le interazioni dono formalizzate e verificate • Si condiderano i processi legati alla linea guida

6. Modello di linea guida diagramma di flusso ontologia di azioni e partecipanti MODELLO

7. Diagramma di flusso • Modella graficamente il flusso di esecuzione della linea guida • Tipico approccio top-down con uso di macroblocchi • Interconnessioni fra blocchi rigidamente controllate • Tool per la progettazione (Ippocrate) • Ispirato alla programmazione strutturata

8. Ontologia • Tramite il tool progettiamo la struttura della linea guida • Come andiamo a caratterizzare i vari blocchi? • Ontologia di dominio per modellare • Partecipanti (attivi e passivi) • Azioni in cui i partecipanti sono coinvolti

9. Struttura ontologica • Abbiamo quindi due gerarchie entity action Partecipanti (nessun attributo) Azioni (ogni azione è legata ad una serie di partecipanti)

10. Mapping ontologia-ICs • Nell’ottica dei vincoli di integrità: • Le azioni sono performative • I partecipanti sono variabili (o, al limite, costanti) • A livello di ICs, si perdono le distinzioni ontologiche • Che rimangono però utili al fine di ricostruire quali sono le sorgenti di eventi (vedi dopo…)

11. Domain-independence • Un diagramma di flusso è indipendente dal dominio (e quindi, dall’ontologia) • La generalità è stata mantenuta integrando il tool con Protégé • Le ontologie sono sviluppate con Protégé e sono caricabili dinamicamente dal tool

12. Blocco di azione • Rappresenta una reale attività da svolgere nell’ambito del protocollo • È associata all’istanziazione di un’azione ontologica dicendo quali sono i partecipanti • Ha un ingresso e un’uscita • Si mappa in un evento (a livello degli ICs)

13. Decisione automatica • Punto di diramazione del protocollo (un ingresso, più uscite) • Ha la semantica dell’X-OR • Ogni ramo di uscita è associato a una condizione logica valutabile dal sistema • Le condizioni possono utilizzare predicati prolog precedentemente “caricati” • Il ramo di uscita è uno fra quelli che vengono valutati positivamente

14. Decisione • Come nella decisione automatica, ma senza agganciare condizioni logiche alle uscite • Il ramo da seguire viene deciso dall’operatore

15. Macroblocchi • Contenitori di nuovi frammenti di linea guida (approccio top-down) • Permettono di definire variabili dando precise regole di visibilità: • Ogni variabile ha come scope il macroblocco in cui è stata definita (è utilizzabile da tutti i blocchi al suo interno) • La variabile rappresenta l’istanziazione di un partecipante ontologico • Possibilità di specificare variabili globali (visibili in tutto il protocollo) • Ad esempio il PAZIENTE in una linea guida

16. Definizione di variabili Protégé

17. Macroazione • Vista all’esterno come un’azione semplice • Quando viene incontrata, il flusso prosegue al suo interno (nel punto di start ) • Il flusso torna al livello superiore quando si incontra un blocco di fine

18. Flusso di esecuzione

19. Cicli 1/2 • Cicli espressi in maniera dedicata come in programmazione strutturata • Macroblocco “for” • Condizione di uscita sul numero massimo di iterazioni • Macroblocco “while” • Condizione di uscita logica • Il contenuto del macroblocco è l’i-esimo passo di iterazione

20. Cicli 2/2 • Il blocco di start di un macroblocco ciclico è appunto un cyclic start • Differenti modalità di uscita • Riconnessione allo start ciclico • Fine del passo di iterazione, ma indicando di rimanere nel ciclo (a meno che la condizione del ciclo non diventi falsa) • fine • Fine del passo di iterazione e uscita prematura dal ciclo (equivalente a un “break”)

21. Esempio di ciclo Rientra nel ciclo Esci dal ciclo

22. Sezioni parallele • Specifica di un insieme di azioni da eseguire in parallelo (semantica dell’AND, vista all’esterno nuovamente come un’unica azione) • Massima generalità • anche una macroazione può far parte della sezione • Semantica di prosecuzione oltre la sezione: • Wait all (prosegui quando tutte le azioni della sezione sono state completate) • Wait one (prosegui quando una delle azioni è stata completata… le altre andranno comunque tutte completate) • Cambiano le modalità di generazione delle aspettative

23. Sezione parallela - esempio

24. Vincoli temporali • Possibilità di legare due azioni con un vincolo temporale H(a,Ta)E(b,Tb),vincolo tra Ta e Tb

25. Gestione inviti screening (1/2)

26. Gestione inviti screening (2/2) H(tell(CENTRO,CODP,invito(CODP,AMB,DATA,ORA),CONV),Tinv) ---> E(tell(CODP,CENTRO,accettazione(CODP,AMB,DATA,ORA),CONV),Tacc) /\ Tacc > Tinv /\ Tacc <= Tinv+7 \/ E(tell(CODP,CENTRO,rifiuto(CODP,AMB,DATA,ORA),CONV),Trif) /\ Trif > Tinv /\ Trif <= Tinv+7 \/ E(tell(CODP,CENTRO,posticipa(CODP,AMB,DATA,ORA),CONV),Tpost) /\ Tpost > Tinv /\ Tpost <= Tinv+7 \/ E(tell(CENTRO,CODP,sollecito(CODP,AMB,DATA,ORA),CONV),Tsoll) /\ Tsoll == Tinv+8.

27. Traduzione in ICs • Stiamo lavorando sulla traduzione automatica di un diagramma in ICs • Come già accennato: • Le azioni divengono eventi • Le interconnessioni “dirette” dicono di costruire un IC • I blocchi di decisione realizzano IC aventi come testa un x-or di aspettative, ognuna associata alla condizione logica specificata • …

28. Iter di sviluppo Event source MODELLO evento1 Diagramma di flusso evento2 evento3 ontologia evento4 … Traduzione automatica In ICs ESECUZIONE Gestione CUSTOM di ogni sorgente

29. Raccolta di eventi da database • Elementi di partenza: • Linea guida in forma strutturata • Ontologia • Gli elementi di partenza vengono relazionati con una ontologia di sorgenti di eventi • Per ogni sorgente si scrive un modulo di accesso: • Per un database si mettono in relazione le dinamiche degli eventi di partenza con quelli delle tabelle del database

30. Considerazioni finali • Il linguaggio utilizza blocchi generici che si vanno a specializzare sulla base dell’ontologia • Il nostro focus non è il supporto alle decisioni, ma il supporto al monitoraggio dei processi clinici legati ad una linea guida • Tale monitoraggio può agire on-the-fly e off-line (feed back sulla qualità della linea guida, statistiche sull'uso della linea guida) • Non c’è una cognizione diretta di tempo, ma di eventi e quindi è più facile implementare servizi tipo “what if” • Limiti da affrontare: • manca la classificazione della gravità delle violazioni • i vincoli temporali sono semplici