Rappresentazione e Gestione di Linee Guida Cliniche tramite YAWL

Presentazione sul tema: "Rappresentazione e Gestione di Linee Guida Cliniche tramite YAWL"— Transcript della presentazione:

1 Rappresentazione e Gestione di Linee Guida Cliniche tramite YAWL
Sistema Informativo Aziendale – Zona Territoriale 7 Rappresentazione e Gestione di Linee Guida Cliniche tramite YAWL Rachele Minnozzi Ancona 19/6/2007

2 CONFERENZA STATO-REGIONI 2005
Sistema Informativo Aziendale – Zona Territoriale 7 CONFERENZA STATO-REGIONI 2005 Nell’ Accordo Collettivo Nazionale, reso esecutivo il 23 marzo 2005 mediante intesa nella conferenza Stato-Regioni, si evidenzia : l’ accentuarsi delle problematiche inerenti la sostenibilità economica del SSN la necessità di porre maggiore attenzione su : - prevenzione - educazione del cittadino ad un uso più efficiente delle risorse del SS - integrazione funzionale fra le diverse figure sanitarie territoriali (MMG, pediatri, Specialisti).

3 OBIETTIVO Sistema Informativo Aziendale – Zona Territoriale 7
E’ necessario quindi ottimizzare l’utilizzo delle risorse del Sistema Sanitario attraverso la definizione di opportune linee guida.

4 LINEE GUIDA (Clinical Guidelines)
Sistema Informativo Aziendale – Zona Territoriale 7 LINEE GUIDA (Clinical Guidelines) Le CG sono state definite dall’ U.S. Institute of Medicine come “asserzioni sviluppate sistematicamente per assistere i professionisti e i pazienti nelle decisioni di cura appropriata nello specifico”.

5 DEFINIZIONE DI LINEA GUIDA
Sistema Informativo Aziendale – Zona Territoriale 7 DEFINIZIONE DI LINEA GUIDA E’ utilizzata dal medico nella prassi giornaliera come supporto nella cura di una determinata patologia. Una linea guida deve: - fornire supporto decisionale; - suggerire la sequenza delle azioni; - consentire di individuare gli scopi da perseguire nell’applicare uno specifico trattamento di cura ad un caso clinico; - consentire di derivare concetti astratti da dati concreti; - consentire la capacità di riconoscere specializzazioni d’interventi astratti.

6 SISTEMI DI GESTIONE DELLE CG
Sistema Informativo Aziendale – Zona Territoriale 7 SISTEMI DI GESTIONE DELLE CG Medical Logic Modules (MLM) GEODE-CM; MBTA; EON; GLIF; GEM; PROforma; ONCOCIN; Prodigy; DILEMMA; Workflow.

7 La Workflow Management Coalition (WfMC) ha definito il workflow
Sistema Informativo Aziendale – Zona Territoriale 7 WORKFLOW La Workflow Management Coalition (WfMC) ha definito il workflow “l’ automazione parziale o totale di un processo aziendale, durante il quale documenti, informazioni o compiti sono scambiati tra i vari partecipanti per essere eseguiti, rispettando un insieme di regole procedurali.”

8 Sistema Informativo Aziendale – Zona Territoriale 7
LINEE GUIDA E WORKFLOW Un modo completamente nuovo per rappresentare una linea guida è quello che utilizza il workflow, in cui essa è vista come un insieme di task da eseguire secondo un ordine temporale e sulla base di condizioni che ne ordinano il flusso. Per definire e gestire l’ esecuzione di un workflow, si utilizza un WFMS (Workflow Management System), “un sistema che definisce, crea e gestisce l’esecuzione di un WF attraverso l’ uso di software. E’ capace di interpretare gli schemi, interagire con i partecipanti del WF e invocare l’uso di strumenti ed applicazioni automatizzate.” (WfMC)

9 Sistema Informativo Aziendale – Zona Territoriale 7
LINEE GUIDA E WORKFLOW WF e WFMS apportano alla gestione delle linee guida i seguenti miglioramenti: - la possibilità di standardizzare il processo - la possibilità di gestire il processo - una efficiente distribuzione dei task basati sulle definizioni degli esecutori del WF - la possibilità di progettare e gestire il processo mediante una rappresentazione grafica Tali caratteristiche garantiranno in breve tempo il successo di tale schema di rappresentazione in ambito sanitario.

10 YAWL (yet another workflow language)
Sistema Informativo Aziendale – Zona Territoriale 7 YAWL (yet another workflow language) Si basa sulle reti di Petri E’ un linguaggio completamente nuovo con una propria semantica e creato specificamente per la gestione dei workflow. La specifica di un flusso di lavoro in YAWL è costituita da un insieme di process definitions strutturate gerarchicamente. E’ stato sviluppato un WFMS che supporta YAWL.

11 PROCESS DEFINITION Sistema Informativo Aziendale – Zona Territoriale 7
Ogni process definition è costituita da task (atomici o compositi) e condition. Possiede un’unica input condition ed un’unica output condition. A differenza delle reti di Petri, due task consecutivi (transition-like objects) possono essere connessi direttamente senza la necessità di dover introdurre una condition (place-like objects). Ogni task composito richiama una process definition ad un livello più basso nella gerarchia.

12 SIMBOLI Sistema Informativo Aziendale – Zona Territoriale 7
Atomic task Composite task Multiple atomic task: consente di eseguire istanze multiple di un task atomico Multiple composite task: consente di eseguire istanze multiple di un task composito Condition: rappresenta uno stato

13 SIMBOLI Sistema Informativo Aziendale – Zona Territoriale 7
AND split task OR split task XOR split task AND join task OR join task XOR join task

14 YAWL PERSPECTIVES Sistema Informativo Aziendale – Zona Territoriale 7
Control-flow perspective: consente di rappresentare il flusso di lavoro con una sequenza di task in successione Data perspective: consente - la definizione dati (data visibility) - il passaggio di dati tra i componenti del workflow (data transfer interno) - lo scambio di informazioni con l’ ambiente operativo (data transfer esterno) - la definizione di condizioni booleane per determinare il flusso di esecuzione (db conditional routing) - la manipolazione di istanze multiple di dati

15 YAWL PERSPECTIVES Sistema Informativo Aziendale – Zona Territoriale 7
Operational perspective: fornisce un insieme di servizi, che consentono l’ interazione della macchina YAWL con l’ ambiente operativo esterno, per assegnare l’esecuzione di task. Sono - YAWL worklist handler (assegna il work-item ad utenti del sistema) - YAWL web service broker (delega l’ esecuzione di un task ad un servizio web esterno) - YAWL interoperability broker (connette fra loro differenti macchine di workflow) - custom YAWL service (consente la connessione con un servizio registrato nella macchina YAWL)

16 Sistema Informativo Aziendale – Zona Territoriale 7
CUSTOM YAWL SERVICE Questi servizi possono essere sviluppati in qualsiasi linguaggio di programmazione. Vengono eseguiti su qualunque piattaforma capace di gestire messaggi XML su protocollo HTTP, tramite i quali avviene l’ interazione con la macchina YAWL. Vengono registrati nella macchina YAWL specificando un URL dal quale risponde il servizio. Il pacchetto YAWL fornisce fra gli altri il servizio Time Service. Esso consente il check back del work item nel motore di YAWL, una volta trascorso un certo intervallo di tempo, rendendolo di nuovo disponibile per il completamento dell’ esecuzione del processo. In questo modo è possibile introdurre dei ritardi nell’esecuzione dei task che compongono l’intero processo.

17 DIABETE Sistema Informativo Aziendale – Zona Territoriale 7
E’ una patologia molto costosa per il sistema sanitario nazionale (sia dal punto di vista sanitario che sociale). E’ stato evidenziato che i maggiori costi sono dovuti alle cure ospedaliere per il trattamento delle complicanze o all’ assistenza in case di riposo per diabetici in stato avanzato della malattia. Quindi la prevenzione delle complicanze rappresenta un investimento vantaggioso e necessita di un rigoroso e continuo controllo nel tempo di tutti i fattori di rischio presenti simultaneamente nella malattia diabetica.

18 CONTROL-FLOW PERSPECTIVE
Sistema Informativo Aziendale – Zona Territoriale 7 CONTROL-FLOW PERSPECTIVE

19 CONTROL-FLOW PERSPECTIVE
Sistema Informativo Aziendale – Zona Territoriale 7 CONTROL-FLOW PERSPECTIVE Il workflow diagnosi diabete rappresenta una linea guida per la diagnosi ed il follow-up di un paziente diabetico. Il primo task controllo glicemia suggerisce al medico, sulla base di un valore glicemico, di indirizzare il paziente ad un semplice follow-up per la prevenzione della patologia diabetica (se glicemia a digiuno<110mg/dl); un test OGTT per una ulteriore indagine prima di diagnosticare la malattia (se glicemia a digiuno è un valore compreso fra 110 e 126); un follow-up per il paziente neodiagnosticato (se glicemia a digiuno>126).

20 CONTROL-FLOW PERSPECTIVE
Sistema Informativo Aziendale – Zona Territoriale 7 CONTROL-FLOW PERSPECTIVE Il task composito diabete richiama la sottorete start_diabete, che consente di gestire il follow-up annuale di un paziente diabetico.

21 CONTROL-FLOW PERSPECTIVE
Sistema Informativo Aziendale – Zona Territoriale 7 CONTROL-FLOW PERSPECTIVE Il workflow start_diabete definisce una serie di controlli a cui il paziente diabetico deve sottoporsi. Tali controllo avvengono con frequenze differenti (ogni tre mesi, ogni sei mesi, ogni anno) e possono sovrapporsi temporalmente. Lo split AND del task iniziale ed il join AND del task finale consentono la loro sincronizzazione. Contiene 3 composite task che richiamano altrettante sottoreti (ciclo3mesi, ciclo6mesi, ciclo12mesi).

22 CONTROL-FLOW PERSPECTIVE
Sistema Informativo Aziendale – Zona Territoriale 7 CONTROL-FLOW PERSPECTIVE

23 DATA PERSPECTIVE Sistema Informativo Aziendale – Zona Territoriale 7
I dati definiti in diagnosi diabete consentono di gestire il flusso di esecuzione, nel caso di task con OR/XOR split (ad esempio, controllo glicemia e test OGTT). YAWL utilizza xPath per specificare una condizione booleana da associare a ciascun ramo. Non è possibile lo scambio diretto di dati fra task. Per questo, si utilizzano: le variabili di task per manipolare i dati nel task stesso le variabili di rete per consentire il passaggio di dati fra i vari task (interno) e quello con l’ ambiente operativo (esterno). YAWL utilizza xQuery per il passaggio interno di dati.

24 OPERATIONAL PERSPECTIVE
Sistema Informativo Aziendale – Zona Territoriale 7 OPERATIONAL PERSPECTIVE Le sottoreti ciclo3mesi, ciclo6mesi e ciclo12mesi utilizzano il servizio Time Service, rispettivamente, nei task mesi3, mesi6 e mesi12. Impostando un intervallo di tempo di 3, 6 e 12 mesi per i 3 task, l’ elenco dei controlli a cui si deve sottoporre l’assistito viene reso disponibile allo scadere del corrispondente ritardo.

25 CONCLUSIONI Sistema Informativo Aziendale – Zona Territoriale 7
Secondo gli accordi presi alla conferenza Stato-Regioni del 2005 è necessario adottare misure per ottimizzare l’utilizzo delle risorse del Sistema Sanitario. Una possibile soluzione è quella di favorire la prevenzione e l’educazione del cittadino. Per raggiungere questo scopo una possibile strategia potrebbe essere quella di ricorrere all’utilizzo di linee guida per rappresentare percorsi di prevenzione e di cura destinati anche al cittadino/assistito. Sono state elencate tutte le possibili soluzioni tecnologiche per la rappresentazione delle linee guida, focalizzando l’attenzione su quella che potrebbe essere la scelta migliore: i flussi di lavoro. Si è scelto di utilizzare come WFMS la piattaforma open source definita per YAWL, linguaggio basato sulle reti di Petri. Tale piattaforma è estensibile tramite la definizione di opportuni servizi. Come esempio è stata modellata in YAWL una possibile linea guida per gestire la prevenzione ed il trattamento del diabete. Si potrebbe ricorrere a tale linguaggio anche per rappresentare le linee guida per la prevenzione ed il trattamento di altre malattie e disturbi particolarmente diffusi come i problemi cardiovascolari.