1 / 30

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

Linguaggi per la specifica e la verifica di linee guida in campo medico. DEIS – Università di Bologna ENDIF – Università di Ferrara. Sergio Storari. Sommario. Esempio di formalizzazione Linguaggio grafico per la formalizzazione Raccolta di eventi interessanti

selene
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related