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

Presentazione sul tema: "Linguaggi per la specifica e la verifica di linee guida in campo medico DEIS – Università di Bologna ENDIF – Università di Ferrara Sergio Storari."— Transcript della presentazione:

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 Proof procedure SEKB SOKB GOAL ICs SOKB ICs Abbiamo formalizzato manualmente una linea guida medica tramite ICs Infezioni MicrobiologicheScreening 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 entityaction 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 Esci dal ciclo Rientra nel 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 MODELLO Diagramma di flusso ontologia Event source evento1 evento2 evento3 evento4 … Gestione CUSTOM di ogni sorgente Traduzione automatica In ICs ESECUZIONE

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