Sistema Informativo Aziendale – Zona Territoriale 7
Rappresentazione e Gestione di
Linee Guida Cliniche tramite
YAWL
Rachele Minnozzi
Ancona 19/6/2007
Sistema Informativo Aziendale – Zona Territoriale 7
CONFERENZA STATO-REGIONI 2005
Nell’ Accordo Collettivo Nazionale, reso esecutivo il 23
marzo 2005 mediante intesa nella conferenza StatoRegioni, 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).
Sistema Informativo Aziendale – Zona Territoriale 7
OBIETTIVO
E’ necessario quindi ottimizzare l’utilizzo delle risorse del
Sistema Sanitario attraverso la definizione di opportune
linee guida.
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”.
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.
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.
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.”
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)
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.
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.
Sistema Informativo Aziendale – Zona Territoriale 7
PROCESS DEFINITION
• 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.
Sistema Informativo Aziendale – Zona Territoriale 7
SIMBOLI
• 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
Sistema Informativo Aziendale – Zona Territoriale 7
SIMBOLI
• AND split task
• OR split task
• XOR split task
• AND join task
• OR join task
• XOR join task
Sistema Informativo Aziendale – Zona Territoriale 7
YAWL PERSPECTIVES
• 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
Sistema Informativo Aziendale – Zona Territoriale 7
YAWL PERSPECTIVES
• 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)
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.
Sistema Informativo Aziendale – Zona Territoriale 7
DIABETE
• 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.
Sistema Informativo Aziendale – Zona Territoriale 7
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
1.
2.
3.
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).
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.
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).
Sistema Informativo Aziendale – Zona Territoriale 7
CONTROL-FLOW PERSPECTIVE
Sistema Informativo Aziendale – Zona Territoriale 7
DATA PERSPECTIVE
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.
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.
Sistema Informativo Aziendale – Zona Territoriale 7
CONCLUSIONI
 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.