Capitolo 1

UNIVERSITÀ POLITECNICA DELLE MARCHE
FACOLTÀ DI INGEGNERIA
_______________________________________________________________
Corso di Laurea in Ingegneria Informatica e dell’ Automazione
Progetto ed implementazione in “YAWL”
di workflows per l’ accesso a
servizi sociosanitari via Internet
Relatore: Chiar.mo
Tesi di Laurea di:
Prof. Dragoni Aldo Franco
Minnozzi Rachele
Anno Accademico 2006 - 2007
1
Indice
Introduzione
5
Capitolo 1 - Linee guida cliniche
8
1.1 - Introduzione
1.2 - Linee guida cliniche
1.2.1 - Criteri di scelta e metodologie per la realizzazione
di una LG
1.2.2 - Presentazione e disseminazione di una LG
1.2.3 - Implementazione ed adattamento locale
1.2.4 - Aggiornamento
1.3 - Sistemi per la gestione delle linee guida
1.3.1 - Rappresentazione formale di una linea guida
1.3.2 - EON
Capitolo 2 – Workflow
24
2.1 - Introduzione
2.2 - Workflow
2.2.1 - Tipologie di workflow
2.2.2 - Workflow clinico
2.3 Definizione di processo
2.4 - Prospettive di un workflow
2.4.1 - Control-flow pattern
2.4.2 - Altri pattern
2
2.5 - Reti di Petri
2.5.1 - Reti di Petri di alto livello
2.5.2 - Reti di Petri e workflow
2.6 - Workflow Management System
2.6.1 - Componenti di un WfMS
2.6.2 - Workflow Reference Model
Capitolo 3 – Yawl
52
3.1 - Introduzione
3.2 - Linguaggio Yawl
3.3 - Sistema Yawl
3.4 - Editor Yawl
3.4.1 - Prospettiva dei dati e delle risorse
3.5 - Yawl Engine
3.6 - Servizi Yawl
3.6.1 - Worklet Service
Capitolo 4 - Linee guida implementate in Yawl
73
4.1 - Introduzione
4.2 - Esempio di linea guida: diabete
4.3 - Esempio di linea guida: obesità
Conclusioni
87
Bibliografia
91
3
4
Introduzione
Le linee guida, sviluppate sulla base delle migliori evidenze disponibili,
consentono di razionalizzare gli interventi clinici e di migliorare la qualità di cura
offerta ai pazienti. In questi ultimi anni sono state create molte linee guida;
sfortunatamente, però, i metodi di diffusione adottati fino a poco tempo fa (per lo più di
tipo cartaceo) non hanno portato ad un loro effettivo inserimento nella pratica clinica.
L’ introduzione dei sistemi informativi all’ interno delle strutture sanitarie ha
fornito nuove possibilità. Si è notato che si riesce ad indirizzare il comportamento
clinico verso una maggiore adesione alle raccomandazioni presenti nelle linee guida se
vengono generati avvisi o segnali di allarme al medico in riferimento alla situazione di
uno specifico paziente.
Da qui, perciò, è nata la necessità di trasferire le informazioni espresse in forma
narrativa in una forma interpretabile ed eseguibile su computer. Molti sforzi sono stati
compiuti fino ad oggi ed hanno portato alla generazione di diversi linguaggi per
modellare linee guida e di vari sistemi in grado di utilizzare la conoscenza in esse
contenuta per supportare il medico nel processo di cura di un dato paziente.
Negli ultimi tempi si sta valutando la possibilità di utilizzare il workflow (wf).
La tecnologia del workflow si è sviluppata nel campo del business e si basa su due
componenti principali: da un lato, la rappresentazione del processo da eseguire in
termini di attività da compiere, informazioni e documenti da gestire, risorse da
utilizzare, ecc. e dall’ altro, la gestione della sua esecuzione su un sistema software, che
prende il nome di workflow management system (wfms).
Lo scopo di questa tesi è quello di individuare i requisiti fondamentali che un
modello per rappresentare linee guida deve possedere e le funzionalità che un sistema
per la gestione delle linee guida deve fornire, da uno studio di quelli già esistenti. Sulla
base di ciò, si vuole mostrare in che modo i workflow ed i workflow management
system possano soddisfare tali esigenze.
5
A questo scopo vengono forniti due esempi di linee guida rappresentate con
Yawl. Yawl (yet another workflow system) è, prima di tutto, un linguaggio per
workflow ma è anche un sistema open source che consente l’ esecuzione di workflow
scritti in tale linguaggio.
La tesi si articola in questo modo: nel primo capitolo vengono introdotti il
concetto di linea guida e la sua importanza nella pratica clinica e viene descritta
sinteticamente l’ articolata procedura che si deve seguire per generare una linea guida di
qualità. Inoltre vengono presentati alcuni modelli e sistemi esistenti per la
rappresentazione e l’ implementazione delle linee guida, in modo da individuare le
caratteristiche salienti che essi possiedono. Il secondo capitolo è dedicato ai workflow
ed ai sistemi per la gestione dei workflow (wfms) mentre nel terzo si descrive Yawl.
Infine, nel quarto capitolo si mostra come sia possibile rappresentare linee guida
utilizzando un workflow e si riportano due esempi. Alcune conclusioni sono riportate
nel capitolo finale.
6
7
Capitolo 1
LINEE GUIDA CLINICHE
1.1 Introduzione
Attualmente il Servizio Sanitario si trova a dover fronteggiare una grande sfida:
quella di accrescere la produttività del sistema e ridurre i costi, pur mantenendo un certo
livello di qualità nella cura del paziente.
Negli ultimi anni i sostenitori della cosiddetta medicina basata sull’ evidenza
hanno puntato sullo sviluppo di linee guida con lo scopo di migliorare la pratica clinica.
Una linea guida deve ridurre le disuguaglianze di trattamento, gli interventi
inappropriati e lo spreco di risorse.
E’ ormai ampiamente riconosciuto che la qualità della cura dipende non solo
dalle abilità professionali dei singoli bensì anche dal livello di collaborazione all’
interno della struttura sanitaria. Quindi, spesso le linee guida prevedono una gestione
integrata della malattia coinvolgendo differenti figure che, nel metterla in pratica,
devono interagire fra loro. Ciò riguarda specialmente chi fornisce la cura primaria
(medici di medicina generale) e chi fornisce la cura secondaria (specialisti del campo),
ma anche altri operatori sanitari come nurses, assistenti domiciliari, farmacisti, ecc.
Le linee guida vengono sviluppate da un gruppo autorevole di esperti, seguendo
un processo articolato ma, affinché possano essere effettivamente implementate all’
interno di una struttura sanitaria, è necessario tener conto delle specifiche caratteristiche
organizzative e strutturali presenti nella realtà locale.
In questo contesto è necessario integrare le attività cliniche con la struttura
organizzativa presente. Un sistema che supporti l’ implementazione di una linea guida
8
deve poter integrare le procedure cliniche con un modello organizzativo della struttura
che prende in considerazione i ruoli, le responsabilità, le risorse, ecc. disponibili.
1.2 Linee guida cliniche
Le linee guida cliniche (clinical guidelines) si sono sviluppate a partire dagli
anni ottanta. Rispondono all’ esigenza di razionalizzare il comportamento clinicoorganizzativo in modo da perseguire l’efficacia e l’ appropriatezza degli interventi
sanitari e l’ efficienza nell’ uso delle risorse.
Costituiscono un supporto per medici ed operatori sanitari nella gestione di una
classe di pazienti, fornendo la sequenza delle azioni da svolgere e le decisioni da
prendere al verificarsi di certi eventi.
Permettono una più rapida diffusione delle nuove conoscenze rispetto a quanto
consentito dai tradizionali testi di medicina, che necessitano di lunghi tempi di
redazione e pubblicazione. Il loro scopo, però, non è quello di fornire solo informazioni,
bensì di modificare la pratica clinica attraverso raccomandazioni. Ed è questo che le
differenzia dalle altre pubblicazioni mediche.
Esse fanno uso dei risultati della medicina basata sull’ evidenza (EBM), che
fonda le decisioni mediche sulla migliore evidenza messa a disposizione dallo stato
attuale della ricerca. La generazioni delle evidenze è un processo sistematico ed in
continua evoluzione.
Secondo la definizione dell’ Institute of Medicine, le linee guida sono
“raccomandazioni di comportamento clinico, elaborate mediante un processo di
revisione sistematica della letteratura e delle opinioni di esperti, con lo scopo di aiutare i
medici ed i pazienti a decidere le modalità assistenziali più appropriate in specifiche
situazioni cliniche”.
La produzione di linee guida nelle varie aree della medicina è in continua
crescita ed il problema che si presenta, quindi, è quello di valutarne la qualità e la
9
completezza e di comprendere la natura delle discrepanze fra quelle esistenti sullo
stesso argomento.
Linee guida prodotte a livello aziendale spesso presentano carenze
metodologiche dovute a competenze tecniche e risorse insufficienti per la loro
elaborazione (difficilmente reperibili in questo ambito). Per questo è nato il Programma
Nazionale per le Linee Guida (PNLG), coordinato dall’Agenzia per i servizi sanitari
regionali e dall’ Istituto superiore di sanità, con lo scopo, non solo di realizzare linee
guida, ma anche di adoperarsi per la loro divulgazione, l’ aggiornamento periodico
(onde evitare che diventino obsolete) e la loro implementazione effettiva.
Infatti non serve produrre linee guida se poi queste non diventano parte
integrante dell’ operato clinico. L’ adattamento di una linea guida, creata a livello
nazionale, ad una realtà locale necessita quasi sempre di modifiche, che tengano conto
del contesto strutturale ed organizzativo nel quale devono essere introdotte. E’
importante però esplicitare ed argomentare le ragioni che hanno portato alla deviazione
dalle raccomandazioni originarie. Una volta che una determinata LG è stata adattata alla
situazione locale prende il nome di “percorso diagnostico-terapeutico”.
A livello nazionale è stata realizzata dal CeVEAS di Modena una “banca dati” di
linee guida, contenente anche una valutazione critica delle LG esaminate ed una sintesi
delle principali raccomandazioni tratte dalle LG pubblicate. Pertanto prima di
imbarcarsi nella produzione di una nuova linea guida, è bene verificare se già ne
esistono sull’argomento, la loro qualità ed, eventualmente, procedere ad un adattamento
ed aggiornamento di ciò che è già stato realizzato.
Il ciclo di vita di una linea guida passa attraverso varie fasi: la scelta dell’
argomento trattato, la realizzazione, la diffusione e l’ implementazione nella pratica
clinica (attraverso un’ adattamento alle esigenze locali, se necessario) ed infine la
revisione e l’ aggiornamento periodico finché non sia ritenuta completamente obsoleta.
10
1.2.1 Criteri di scelta e metodologie per la realizzazione di una LG
Esistono diversi fattori che possono influire sulla scelta dell’ argomento di una
linea guida. Uno di questi è rappresentato dal peso della malattia. L’incidenza della
stessa o delle sue complicanze unita alla possibilità di intervenire più efficacemente per
eliminare l’ inappropriatezza delle cure esistenti costituiscono un buon motivo per la
creazione di una linea guida.
A volte può essere utile invece rispondere ad un bisogno di informazione,
espresso dall’ opinione pubblica e dai pazienti su un dato problema, come avviene ad
esempio ogni anno quando vengono diffuse raccomandazioni per la prevenzione dell’
influenza.
Altre modalità di scelta consistono nel selezionare quei temi per i quali esistono
prove scientifiche e dati accurati sugli effetti degli interventi nell’ ambito in questione
oppure per i quali il rapporto costo e beneficio risulta vantaggioso.
Non esiste uniformità sui metodi adottatati per produrre linee guida neppure a
livello internazionale. Ciò nonostante vi sono alcuni requisiti fondamentali che devono
essere rispettati per garantire rigore e trasparenza e che caratterizzano le linee guida
basate sulle prove di efficacia (evidence-based guidelines) da quelle non basate sulle
prove di efficacia (not evidence-based guidelines). Questi sono:
1.
multidisciplinarietà del gruppo responsabile della produzione della linea
guida;
2.
uso, o realizzazione se non sono già disponibili, di revisioni sistematiche
della letteratura;
3.
classificazione delle raccomandazioni in base alla qualità delle prove
scientifiche che le sostengono;
4.
uso di indicatori di monitoraggio.
E’ importante la costituzione di un gruppo multidisciplinare in modo da
apportare punti di vista e competenze differenti. Quindi devono essere adeguatamente
rappresentati sia i medici specialisti sia i medici di medicina generale e tutte le figure
professionali coinvolte nella gestione del problema in esame, ad esempio tecnici
diagnostici, infermieri, farmacisti, psicologi ecc. Inoltre è utile la partecipazione di
11
pazienti o di loro rappresentanti, per soddisfare il desiderio sempre crescente della
popolazione di essere parte attiva nella gestione della propria salute. Può essere presente
anche un esperto in economia sanitaria, quando si vuole valutare l’ impatto economico
che l’ implementazione della linea guida può avere sul SS. Il numero di partecipanti non
deve essere né troppo piccolo né troppo elevato (tra i 10 e i 20 membri) e si deve dare a
tutti la possibilità di esprimersi liberamente.
Una revisione sistematica (RS) viene definita come una “valutazione delle
conoscenze disponibili su un determinato argomento, nella quale tutti gli studi rilevanti
sono identificati e valutati criticamente”. Negli ultimi anni i metodi per la realizzazione
di RS si sono molto affinati. La produzione di linee guida deve basarsi su revisioni
sistematiche ben condotte in modo da fondare il comportamento clinico su solide basi
scientifiche. Un’ agenzia che si occupa della creazione di RS è la Cochrane
Collaboration.
E’ importante associare ad ogni raccomandazione fornita dalla linea guida una
valutazione o grading sia della qualità delle prove (livello di prova o LdP) su cui essa è
basata sia dell’ importanza di una sua applicazione (forza della raccomandazione o
FdR). Quest’ ultimo indice rappresenta la probabilità che l’ implementazione di tale
raccomandazione porti ad un effettivo miglioramento dello stato di saluto del paziente a
cui è applicata la LG. Non esiste un unico sistema di grading.
Indipendentemente dalla metodologia adottata per la produzione della linea
guida, è importante utilizzare degli indicatori per verificare nel tempo l’ effettiva
implementazione delle raccomandazioni in essa contenute.
Infine una linea guida deve:
-
esplicitare le alternative di trattamento e i loro effetti sugli esiti;
-
essere flessibile ed adattabile alle condizioni locali mutevoli;
-
essere chiara, cioè avere una struttura semplice e un linguaggio
comprensibile.
12
1.2.2 Presentazione e disseminazione di una LG
Sono stati individuati diversi ostacoli all’ introduzione effettiva di una linea
guida nella pratica clinica. Uno di questi è rappresentato dalle caratteristiche formali del
documento con cui viene presentata. Infatti questo deve essere semplice, facile da
consultare e da memorizzare; inoltre deve avere un linguaggio non ambiguo e contenere
termini ben definiti attraverso un glossario.
Per tale motivo sono state fissate le caratteristiche di forma e stile e la struttura
che il documento deve possedere, pur consentendo variazioni dipendenti dall’
argomento trattato nello specifico, dai destinatari e dallo scopo della linea guida.
Innanzitutto il titolo deve indicare il contenuto del documento con la maggior
precisione possibile compatibilmente con la necessaria concisione e deve individuare la
classe di pazienti in base alla patologia, all’ età e/o ad altre caratteristiche e l’ ambito di
intervento (prevenzione, terapia farmacologica, diagnosi ecc.).
Prima della stesura del testo vero e proprio, dovrebbero essere riportate alcune
informazioni essenziali circa gli autori, la loro qualifica ed il loro ruolo, l’indicazione di
eventuali finanziamenti, la data in cui il documento è stato redatto ed, eventualmente,
quando è previsto un suo aggiornamento.
Segue un’ introduzione dove vengono definiti, con maggiore dettaglio rispetto al
titolo, l’ argomento e l’ ambito della linea guida, gli scopi e i destinatari del documento.
Nel corpo viene resa esplicita la sequenza delle decisioni chiave che il clinico
deve prendere. Ad ognuna di esse vengono associate le raccomandazioni formulate sulla
base delle migliori prove empiriche disponibili, i vantaggi attesi dalla loro applicazione
e la probabilità che i risultati attesi si verifichino (forza delle raccomandazioni).
Se sono dichiarate all’interno del documento altre decisioni di minor peso (ad
esempio, la scelta tra diversi principi attivi della stessa famiglia o tra diversi test di
valutazione del rischio), deve essere chiaramente indicata la loro minore importanza.
Spesso sono forniti alcuni allegati per completare le informazioni contenute all’
interno del documento. Per ogni decisione chiave si può riassumere le migliori prove
empiriche disponibili, i riferimenti bibliografici ed i loro livelli di qualità. E’ inoltre
utile per la ricerca futura indicare le “aree grigie”, ovvero gli argomenti per i quali le
13
prove di efficacia esistenti risultano assenti o insoddisfacenti. E’ presente anche un
glossario dei termini tecnici e delle sigle ricorrenti all’ interno del documento.
Per la diffusione di una LG, generalmente, si utilizzano modi e tecnologie
differenti considerando la varietà dei possibili utenti e dei possibili usi. E’ d’ obbligo la
redazione di un tradizionale volume di testo, anche se non rispecchia le caratteristiche di
immediatezza che le linee guida hanno.
Di più facile consultazione, invece, è l’ opuscolo, che generalmente non supera
le 60 pagine e ha un formato tascabile. Il pieghevole ha dimensioni ancora più ridotte e
contiene una sintesi estrema del lavoro. Viene utilizzato come materiale informativo da
distribuire ai cittadini.
In alternativa al supporto cartaceo, si sono diffusi CD-ROM e DVD, i quali
possono contenere sia testi completi sia versioni ridotte ed essere arricchiti con filmati,
registrazioni audio, animazioni grafiche, biblioteche di articoli ed altro. Inoltre le
tecnologie dell’ informazione e della comunicazione facilitano la diffusione delle linee
guida perché un archivio elettronico accessibile tramite Internet consente agli utenti di
disporre sempre delle versioni aggiornate.
1.2.3 Implementazione ed adattamento locale
Sono state messe a punto delle strategie per facilitare l’ utilizzo di una linea
guida e rimuovere gli ostacoli alla loro introduzione nella pratica clinica. L’
implementazione della LG richiede necessariamente a clinici, e non, coinvolti dei
cambiamenti nelle proprie abitudini ed è frequente trovare atteggiamenti non favorevoli
a tali cambiamenti. Inoltre, il contesto strutturale ed organizzativo offerto dalla realtà
locale può non facilitare la realizzazione pratica delle raccomandazioni presenti nella
linea guida.
Pertanto può essere necessario intervenire sulla struttura e sull’ organizzazione,
ad esempio modificando ruoli ed inserendo nuove competenze, ed apportare delle
modifiche alle risorse disponibili, ad esempio introducendo nuove tecnologie. Inoltre
14
vengono messi in atto interventi volti alla formazione e motivazione del personale
medico e non.
1.2.4 Aggiornamento
Ogni documento di raccomandazioni deve essere periodicamente ripreso e
revisionato sulla base delle nuove conoscenze divenute disponibili nel frattempo.
Durante tale revisione si può verificare che il documento sia diventato del tutto obsoleto
e debba essere completamente riconsiderato oppure che necessiti solo di qualche
modifica che può essere apportata dai responsabili della iniziale produzione con la sola
consultazione esterna degli esperti originariamente coinvolti. Infine si può verificare che
il problema che aveva richiesto la produzione delle raccomandazioni si sia risolto e
queste non siano più necessarie.
I tempi per la produzione di una linea guida vanno dai 12 ai 18 mesi nel caso in
cui l’ argomento non è stato precedentemente trattato e non esiste, quindi, alcuna LG
pubblicata a riguardo. Tempi più brevi sono richiesti nel caso di un argomento
consolidato e sul quale sono state già implementate numerose LG di qualità. Invece la
revisione e l’ aggiornamento sulla base di nuove prove pubblicate può richiedere dai 6
ai 12 mesi.
1.3 Sistemi per la gestione delle linee guida
Negli ultimi anni sono state prodotte numerose linee guida; spesso, però, la
semplice esposizione in forma narrativa non facilita la loro effettiva introduzione nella
pratica clinica. In questo modo, infatti, l’ impatto sul comportamento clinico dipende
dalla volontà e dalla capacità dei clinici di memorizzare le raccomandazioni in esse
contenute e di applicarle successivamente nel contesto specifico di un dato paziente. In
realtà, l’ esperienza ha dimostrato che ciò non avviene e tale modalità di diffusione delle
15
linee guida, basata esclusivamente su materiale cartaceo da consultare, non produce gli
effetti sperati nel cambiamento del comportamento clinico.
L’ introduzione dei sistemi informativi nelle strutture sanitarie ha fornito nuove
opportunità per la diffusione delle linee guida. Utilizzando gli strumenti informatici,
infatti, la conoscenza in esse contenute può essere presentata al medico per mezzo di
segnali d’ allarme o di avvisi che richiamano la sua attenzione sulla situazione di uno
specifico paziente in riferimento ad una determinata linea guida. Si è visto che, in
questo modo, si ottiene una maggiore adesione alle raccomandazioni presenti in una
linea guida.
Pertanto, piuttosto che descrivere una linea guida come un elenco di
raccomandazioni senza alcun riferimento al contesto specifico di un paziente, è più
efficiente, ai fini di una sua effettiva implementazione, utilizzare un sistema che
monitora la situazione clinica dei pazienti e che interviene quando si verifica un
“incontro” fra un particolare paziente ed una determinata linea guida, ovvero quando un
paziente entra in uno stato contemplato dalla linea guida e, quindi, da essa trattato con
una raccomandazione. Un sistema siffatto si dice che fornisce un supporto nelle
decisioni cliniche in riferimento ad un paziente specifico e sulla base delle
raccomandazioni proprie di una linea guida. Per fare questo, esso deve poter accedere
all’ informazione presente nella linea guida e ai dati clinici del paziente.
1.3.1 Rappresentazione formale di una linea guida
Negli ultimi anni molti gruppi sono stati impegnati nello sviluppo di sistemi di
questo tipo. Una prima questione da affrontare è quella di creare un modello capace di
rappresentare la conoscenza contenuta in una linea guida in una forma interpretabile da
un computer (Computer-interpretable guideline).
La conversione dalla forma narrativa ad una rappresentazione per computer non
è di facile attuazione perchè le linee guida descritte su carta spesso presentano
mancanze o ambiguità, complici le disattenzioni degli autori e la riluttanza ad essere
specifici quando l’ evidenza scientifica non è disponibile. Pertanto una rappresentazione
16
formale della linea guida, oltre a renderla interpretabile tramite computer, ha l’ ulteriore
vantaggio di portare alla luce i punti non chiari ed imprecisi presenti nella sua
esposizione e, quindi, da revisionare.
Si possono individuare, in una generica linea guida, alcuni elementi
fondamentali, che è necessario considerare ai fini di una sua rappresentazione ed
esecuzione su computer. Anzitutto un modello per linee guida deve permettere di
rappresentare le azioni raccomandate e le decisioni che devono essere prese all’ interno
di una linea guida. Si possono distinguere due tipi di scelte: quelle che vengono
effettuate rigorosamente in funzione ai dati dello specifico paziente trattato e quelle,
invece, che permettono di selezionare fra differenti opzioni in base a preferenze o a
valutazioni personali del clinico.
Un’ altra caratteristica importante è la rappresentazione del criterio di
eleggibilità, ovvero di quelle condizioni che devono essere verificate affinché un
paziente possa essere inserito nella linea guida. Ad esempio, la condizione glicemia a
digiuno >= 126 determina l’ inserimento del paziente all’ interno della linea guida
trattamento paziente diabetico. Inoltre inserire degli obiettivi da raggiungere quando si
effettua una azione o si deve prendere una decisione e fornire collegamenti con altre
fonti di conoscenza ed altro materiale di supporto costituiscono altri aspetti importanti
di una linea guida.
Il collegamento con i dati clinici è necessario se si vuole creare un sistema che
supporti le decisioni cliniche su uno specifico paziente trattato. Una linea guida può
ricevere tali dati in input in vari modi: da un database locale che contiene il fascicolo
personale del paziente, dall’ utente stesso (ad esempio richiedendo di compilare una
form), da un database o sistemi software remoti che forniscono ad esempio i risultati di
esami di laboratorio, ecc.
Sono stati adottati differenti approcci per rendere le linee guida eseguibili su
computer. La rappresentazione basata sulle regole è stato uno dei primi metodi
utilizzati. In essa una linea guida viene modellata come un insieme di regole, ognuna
delle quali è costituita, da un lato, da un criterio da valutare e, dall’ altro, da un insieme
di azioni da compiere nel caso la prima parte assuma valore true. Un sistema che
interpreta ed esegue linee guida rappresentate in questo modo è costituito da un
17
interprete che schedula le regole, verifica il criterio e nel caso il risultato sia true,
realizza le azioni specificate.
Il sistema Help adotta questa tecnica per generare segnali di allarme nel caso si
verifichino condizioni od eventi particolari: ad esempio, risultati anomali in analisi di
laboratorio o combinazioni di farmaci potenzialmente pericolosi.
L’ Arden Syntax è un linguaggio per la codifica di tali regole all’ interno dei
Medical Logic Module (MLM). Un MLM contiene la conoscenza necessaria per
prendere una singola decisione medica. E’ costituito da diversi slot raggruppati in tre
categorie: Manteinance e Library, che forniscono le informazioni e la documentazione
necessaria per ogni MLM e Knowledge che rappresenta la sostanza del MLM e contiene
la conoscenza medica.
Lo slot Manteinance fornisce il nome, l’ autore, l’ origine, la versione e l’
informazione di validazione mentre lo slot Library contiene i collegamenti con altre
fonti di conoscenza, commenti e parole-chiave per facilitare ulteriori ricerche sull’
argomento. Lo slot Knowledge è costituito, a sua volta, da quattro slot principali: data
slot effettua il mapping fra i termini usati nel MLM e quelli del database-paziente
locale; evoke slot specifica l’ evento che si deve verificare per far partire l’ MLM; logic
slot indica quali criteri devono essere soddisfatti affinché si possa eseguire l’ azione
(decisione) specificata nell’ action slot.
Gli MLM costituiscono la base di conoscenza ed, una volta implementati su un
sistema d’ informazione clinica, utilizzano i dati-paziente contenuti nel database locale
per far partire singole decisioni/azioni. Sebbene sia possibile modellare una sequenza di
decisioni/azioni collegando a catena un insieme di MLM, non si riesce a rappresentare
linee guida complesse.
Il limite di questa rappresentazione basata sulle regole è appunto il fatto di non
poter modellare linee guida complesse, costituite, cioè, da sequenze di azioni e decisioni
che devono essere effettuate lungo un arco di tempo (linee guida multi-step). Allora, per
risolvere questo problema, è stato adottato un altro approccio, che prende il nome di
paradigma basato su task (Task-Network Model o TNM). In esso le linee guida sono
rappresentate con delle reti di task collegati in modo da rispecchiare i vincoli temporali,
logici ed altri tipi di relazioni esistenti fra loro.
18
I componenti che formano questo tipo di modello possono essere diversi ma
sempre sono presenti costrutti per rappresentare azioni (actions) e decisioni (decisions),
che costituiscono gli elementi chiave di una linea guida, e sottoreti, che semplificano la
rappresentazione di alto livello e permettono la riusabilità.
Possono essere fornite anche altre primitive. Uno scenario o stato-paziente
caratterizza lo stato del paziente in un dato momento, in base alle azioni effettuate ed
alle decisioni prese nel contesto di una determinata linea guida. Ad esempio, se un
paziente ha più di 50 anni e non è allergico al vaccino dell’ influenza, lo scenario è
“eleggibile per il vaccino dell’influenza”. Branch step e synchronization step
permettono di modellare percorsi paralleli all’ interno della linea guida (ad esempio,
quando sono richieste differenti azioni che devono essere eseguite da differenti medici).
Tali componenti sono disposti nella rete in modo da determinare il flusso di
controllo durante l’ esecuzione. Generalmente sono presenti costrutti differenti per
specificare l’ esecuzione in sequenza, in parallelo e ciclica dei componenti. Il flusso di
controllo non è completamente determinato da questi costrutti bensì dipende anche da
modelli decisionali che dirigono il flusso verso rami selezionati del modello in base al
verificarsi o meno di certe condizioni.
PROforma adotta questo tipo di approccio ed utilizza quattro classi di task:
decision, action, enquiry e plan. Un task decision permette di effettuare una scelta fra
diverse opzioni, per ognuna delle quali vengono indicati i pro ed i contro. Un action è
una procedura clinica che deve essere eseguita da un agente esterno (un utente, un altro
software o una macchina) mentre una enquiry fornisce le informazioni necessarie alla
linea guida, ad esempio, richiedendole all’ utente tramite una form od interrogando l’
archivio elettronico contenente i dati clinici del paziente. Infine un plan è costituito da
un insieme di task, che devono essere eseguiti rispettando certi vincoli logici e
temporali per raggiungere un obiettivo clinico.
I task sono modellati secondo un’ approccio orientato agli oggetti, ovvero ogni
task clinico è una istanza di una classe ed ogni classe è collocata in una ontologia. Le
quattro classi sopra menzionate costituiscono una specializzazione di un task radice ed
ognuna di esse può essere a sua volta specializzata in particolari sottoclassi, le quali
ereditano dalla classe genitore un insieme di attributi e li estendono con attributi
19
aggiuntivi. Solo per alcuni di essi è obbligatorio assegnare un valore mentre per gli altri
è opzionale.
La classe radice permette di definire l’ obiettivo clinico che deve essere
raggiunto tramite l’ esecuzione di un task. Nel momento in cui tale obiettivo è
raggiunto, l’ esecuzione termina e se la condizione è raggiunta ancor prima di eseguire
il task, questo viene saltato. Un altro attributo che può essere specificato è la condizione
di trigger che può essere un evento temporale di qualsiasi genere o una descrizione
booleana di uno stato paziente.
L’ unico attributo della classe plan che deve essere necessariamente specificato è
l’ attributo componenti, che elenca l’ insieme dei task che devono essere eseguiti senza
un particolare ordine. Altri attributi specificano i task opzionali, che possono, quindi,
essere saltati dall’ utente, i vincoli temporali fra i task e le condizioni che determinano l’
aborto del plan. L’ esecuzione sequenziale e parallela sono, quindi, supportati definendo
un attributo del task.
Anche GLIF (GuideLine Interchange Format) utilizza una rappresentazione
orientata agli oggetti. E’ stato sviluppato con lo scopo di facilitare la condivisione di
linee guida fra differenti istituzioni ed ha subìto modifiche e miglioramenti in
successive versioni. Nell’ ultima versione, GLIF3, una specifica di linea guida è
costituita da tre livelli di rappresentazione: un flowchart concettuale che permette di
avere una visione globale degli step che formano la linea guida, una specifica
computabile ed una specifica implementabile.
Il modello GLIF è composto da un insieme di classi che rappresentano le entità
di una linea guida, dagli attributi di queste classi e dai tipi di dati per gli attributi. Le
classi formano una gerarchia ed ognuna di esse eredita gli attributi da quelle superiori,
oltre ad avere dei propri attributi. Una particolare linea guida è una istanza del modello
generale.
Il modello GLIF permette di rappresentare una linea guida come un flowchart
costituito da un insieme di step da eseguire secondo un certo ordine temporale. Questi
step sono di diversi tipi: action step che fa riferimento ad una azione o ad una sotto linea
guida ad un livello di astrazione più basso; conditional step che modella una decisione;
patient-state step che rappresenta la condizione del paziente ad un certo punto della
20
linea guida; branch step e synchronization step che, insieme, consentono l’ esecuzione
concorrenziale di azioni e decisioni.
1.3.2 EON
Il progetto EON tenta di modellare la complessità e la varietà delle linee guida
estendendo un modello centrale con sottomodelli in modo da soddisfare i requisiti di
diversi tipi di linee guida. Lo scopo dei progettisti di EON è quello di utilizzare le linee
guida per supportare le decisioni cliniche sullo specifico paziente; pertanto, in aggiunta
ad un modello per la rappresentazione delle linee guida che utilizza l’ approccio basato
sulle reti di task, è stata costruita una architettura composta da vari componenti software
per realizzare un sistema di questo tipo (figura 1).
Il modello è costituito da algoritmi clinici in cui le sequenze di azioni e decisioni
sono specificate in una rete. In EON si fa distinzione fra azioni, che sono istantanee (ad
esempio, la prescrizione di un esame) ed attività, che perdurano nel tempo. Queste
ultime sono caratterizzate da stati che possono cambiare nel tempo, in seguito all’
esecuzione di determinate azioni specificate nella linea guida. Ad esempio, la
somministrazione di un farmaco è una attività e gli stati ad essa associati sono
determinati da un insieme di attributi, come la quantità e la frequenza.
Prendere una decisione è una caratteristica fondamentale di una linea guida.
EON presenta modi differenti di descrivere le alternative a cui corrispondono diversi
meccanismi di scelta. Infatti fa distinzione fra decisioni automaticamente determinate da
criteri booleani associati alle singole alternative, in cui viene selezionata fra le varie
opzioni quella il cui criterio booleano viene valutato true e decisioni che richiedono l’
intervento di un agente esterno per scegliere una fra un insieme di alternative
predefinite.
Lo scenario in EON definisce lo stato del paziente, fornendo una descrizione
testuale e specificando le condizioni che devono essere soddisfatte affinché un paziente
entri in quello scenario (ad esempio, nel caso dello scenario “paziente eleggibile per il
21
vaccino dell’influenza”, la condizione è che deve avere più di 50 anni e non deve essere
allergico al vaccino). Uno scenario è seguito da una decisione o un action step.
Il modello fornisce anche primitive per la diramazione e la sincronizzazione, in
modo da permettere l’ esecuzione di azioni in parallelo. Inoltre le azioni ripetute
vengono modellate tramite un costrutto che consente di specificare il numero di volte o
la frequenza con la quale queste devono essere ripetute.
Azioni, decisioni, sotto linee guida, scenari e diramazioni e sincronizzazioni
sono collegati fra loro da una relazione seguito_da. Action step e decisioni costituiscono
gli step dell’ algoritmo clinico e ad essi vengono assegnati degli scopi da raggiungere
sotto forma di criteri booleani.
Sono definite due classi di linee guida: consultation guidelines, che specificano
azioni e decisioni che non portano conseguenze nel tempo e management guidelines,
che, invece, modellano azioni e decisione che portano a cambiamenti nello stato del
paziente nel tempo. L’ algoritmo clinico può essere specificato per entrambe le classi.
Figura 1.1
22
23
Capitolo 2
WORKFLOW
2.1 Introduzione
Il termine workflow è legato al settore del business ed indica un modo di
descrivere un processo come un insieme di: attività da svolgere rispettando un certo
ordine temporale, informazioni e documenti da gestire e risorse umane e non da
impiegare per raggiungere un obiettivo finale.
Strettamente correlato al workflow è il termine workflow management system
(wfms). Esso è un sistema software che si occupa di controllare e gestire l’ esecuzione
del processo, assegnando le varie attività al momento giusto ed alle persone giuste,
invocando, quando necessario, gli strumenti IT di supporto e fornendo i dati utili allo
svolgimento dei compiti.
Generalmente un wfms comprende nel pacchetto un software per modellare il
workflow con un linguaggio formale o una rappresentazione grafica ed il modello così
creato, che prende il nome di definizione di workflow, viene fornito in input ad un
motore capace di interpretarlo e di gestire l’ esecuzione delle istanze generate da esso.
In altre parole, definizione di workflow e istanza di workflow rappresentano l’ analogo
della classe e dell’ oggetto istanza della classe che si ha nella programmazione orientata
ad oggetti.
Spesso un wfms è dotato di strumenti che consentono di classificare le risorse in
ruoli, in base alle competenze ed abilità di ciascuna di esse e/o in unità, che tengono
conto dell’ organizzazione all’ interno del sistema (team, dipartimenti, ecc.). Questo
perché, assegnare un compito ad una specifica persona, significa l’ interruzione del
lavoro in caso di assenza o momentanea indisponibilità della stessa mentre
24
assegnandolo ad una classe di risorse deputate egualmente idonee si permette una
maggiore flessibilità nella gestione del processo.
In genere sono presenti anche funzioni che permettono di monitorare l’
esecuzione delle istanze, in modo da ricavare analisi statistiche e report utili a valutare il
rendimento del processo così modellato.
La Workflow Management Coalition (WfMC) è una organizzazione
internazionale no-profit fondata nel 1993 con lo scopo di creare standard per quanto
riguarda la terminologia adoperata in questo campo e l’ architettura dei workflow
management system. Nel 1999 ha pubblicato un glossario con l’ intento di fermare il
proliferare sregolato di termini e di definizioni ambigue, ha individuato una architettura
generale per i workflow management system e si adopera a favore della
standardizzazione e dell’ interoperabilità dei vari componenti che la costituiscono.
In questo capitolo si utilizza la terminologia introdotta dalla WfMC e vengono
fornite le corrispondenti definizioni prese dal glossario. Inoltre viene presentato il
modello di riferimento da essa presentato (Workflow Reference Model) e sul quale si
stanno ancora facendo dei tentativi di standardizzazione.
2.2 Workflow
La WfMC definisce il workflow come “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.”
Un processo è costituito da un insieme di attività che devono essere svolte in
maniera opportuna per il raggiungimento di un obiettivo finale. In genere queste attività
vengono eseguite da diversi individui (partecipanti), magari con il supporto di strumenti
IT, e/o da macchine e ci si riferisce ad essi con il termite generale “risorse”. Il lavoro e
le informazioni necessarie devono “fluire” fra le varie risorse rispettando regole ben
precise.
Per poter essere gestito e realizzato utilizzando la tecnologia del workflow, il
processo deve essere innanzitutto modellato in una forma che lo rende processabile su
25
computer e che prende il nome di definizione di processo (process definition). Essa è la
rappresentazione di un processo “in una forma adatta alla manipolazione automatizzata,
come la modellazione o l’ esecuzione per mezzo di un workflow management system”
ed è costituita da un insieme di “attività e delle relazioni esistenti fra di esse, di criteri
per indicare l’ inizio e la fine del processo ed informazioni riguardanti le singole
attività, come ad esempio i partecipanti, le applicazioni IT associate e i dati ecc.” Può
contenere anche uno o più sottoprocessi, definiti separatamente, che permettono una
rappresentazione su più livelli e favoriscono la riusabilità.
Poiché non necessariamente tutte le attività all’ interno del processo sono
automatizzate, bensì alcune possono richiedere un trattamento manuale, si fa distinzione
fra la sopra citata definizione di processo, che specifica sia le attività automatizzate sia
quelle manuali, e la definizione di workflow (workflow definition) che comprende
solamente la parte automatizzata del processo.
Tali definizioni costituiscono l’ analogo della classe nella programmazione
orientata ad oggetti e come viene creato l’ oggetto istanza della classe, così esse
vengono istanziate, generando rispettivamente l’ istanza di processo e l’ istanza di
workflow. E’ quest’ ultima che viene fornita in input al workflow management system e
da esso eseguita. Comunque, poiché generalmente i processi sono completamente
automatizzati, i due termini vengono utilizzati in maniera intercambiabile.
Da un’ unica definizione di processo possono derivare molte istanze, ognuna
delle quali ha una propria identità e la sua esecuzione viene gestita indipendentemente
dalle altre. Alcuni utilizzano il termine specifica di workflow in luogo di definizione di
workflow.
L’ attività è la “descrizione di un pezzo di lavoro” e costituisce un’ unità logica
all’ interno del processo. E’ indivisibile e, quindi, deve essere eseguita in toto: se si
verifica un errore, si deve ripartire dal suo inizio. Mentre essa rappresenta un generico
pezzo di lavoro all’ interno della definizione di processo, la sua istanza si riferisce ad un
pezzo di lavoro che deve essere svolto concretamente per la particolare istanza di
processo. Ogni attività richiede per la sua esecuzione l’ invocazione di applicazioni
opportune e/o l’ assegnamento a partecipanti. In quest’ ultimo caso si introduce il
concetto di work item: una singola attività può generare uno o più work item che
26
insieme costituiscono il compito (task) che deve essere portato a termine da un utente
all’ interno della stessa.
Le relazioni fra tutti questi concetti di base sono rappresentate in figura 1.
Figura 2.1
2.2.1 Tipologie di workflow
Fra le molte classificazioni esistenti dei workflow, ve n’ è una che distingue:

Ad hoc workflow;

Administrative workflow;

Production workflow.
Queste tre tipologie sono descritte in funzione delle seguenti caratteristiche:
ripetitività e predicibilità del flusso di lavoro, modalità di avvio e di controllo del
workflow (controllo umano o automatizzato) e funzionalità richieste dal wfms.
Ad hoc workflow sono prevalentemente costituiti da attività che necessitano
coordinazione, collaborazione o co-decisione fra i vari partecipanti. Quindi
27
sono
caratterizzati da alta variabilità e risulta difficile definire uno schema fisso, visto che la
sequenza delle attività non è prestabilita ma viene definita dinamicamente durante l’
esecuzione del processo. L’ ordine con cui le attività vengono eseguite e la
coordinazione fra di esse non sono automatizzati bensì controllati da uomini e sono
stabiliti durante l’ esecuzione stessa del workflow.
I wfms devono fornire funzionalità che facilitano appunto il coordinamento, la
collaborazione e la co-decisione fra le persone coinvolte, mentre non sono richieste
funzionalità per controllare l’ ordine con cui le varie attività vengono eseguite. Gli
utenti di un ad hoc workflow devono accedere al wfms per verificare che il lavoro sia
stato completato. La tecnologia generalmente utilizzata comprende la posta elettronica, i
sistemi di conferenza, ecc. Di solito un database memorizza le informazioni condivise
fra i partecipanti.
Un ad hoc workflow tipicamente coinvolge un piccolo gruppo di professionisti,
che devono realizzare un lavoro in un tempo breve. Un esempio è la realizzazione di un
programma per un convegno scientifico.
Administrative workflow si riferisce a processi predicibili e ripetitivi e, quindi, è
possibile definire uno schema che viene eseguito da molte o tutte le istanze del
processo. Le attività di cui sono costituiti sono strutturate in maniera semplice, perlopiù
lineare. Pertanto l’ ordine con cui tali attività vengono eseguite ed il loro coordinamento
sono automatizzati. I wfms devono gestire un flusso di informazioni semplice e non è
richiesto l’ accesso a molteplici sistemi informativi. La tecnologia utilizzata
generalmente è la posta elettronica.
Anche i production workflow sono caratterizzati da predicibilità e ripetitività
ma, a differenza degli administrative workflow, sono strutturati in maniera complessa e
richiedono un elevato numero di transazioni che accedono a vari sistemi informativi per
eseguire lavori e prelevare i dati in base ai quali prendere decisioni. L’ ordine con cui le
attività vengono eseguite ed il loro coordinamento possono essere automatizzati.
I wfms devono essere capaci di gestire l’ interoperabilità e l’ intergrazione con
sistemi informativi HAD (Eterogenei, Autonomi e/o Distribuiti). Un esempio può essere
la gestione di un prestito bancario.
28
2.2.2 Workflow clinico
Il concetto di workflow si adatta a vari campi dell’ operato umano, anche a
quello sanitario, in cui l’ informatica e l’ automazione stanno entrando a far parte
sempre più delle procedure mediche. Basta pensare alla possibilità di prenotare un
esame via internet, all’ uso di tecniche diagnostiche come TAC e Risonanza Magnetica
ed alla telemedicina. Facendo l’ esempio della radiologia, in cui l’ informatizzazione e
la tecnologia sono maggiormente diffuse, si può modellare il flusso di lavoro dalla
registrazione del paziente fino all’ esecuzione degli esami diagnostici ed alla produzione
del referto tramite un workflow.
Figura 2.2 – workflow in radiologia
La figura 2 mostra gli attori coinvolti nel processo e i dati scambiati fra di essi.
Si inizia con il paziente che entra per la prima volta nella struttura sanitaria e viene
registrato dall’ ADT, ovvero un sistema di ammissione e anagrafica. Successivamente il
paziente si presenta per prenotare una prestazione (ad esempio, una TAC addominale)
presso il centro unico di prenotazione (CUP) e la sua richiesta viene schedulata sulla
base delle disponibilità esistenti in agenda tramite un sistema RIS (sistema informativo
di radiologia). Questo individua la prima disponibilità per un certo esame, considerando
il parco macchine, gli orari di lavoro e le prenotazioni già presenti, concorda con il
29
richiedente la data e l’ ora e fissa l’ appuntamento inserendolo in agenda. Dopodichè, la
Diagnostica riceve ogni giorno dal RIS tutti i dati necessari per sapere quale paziente
dovrà essere sottoposto a quale esame e quando e fornisce un feed-back al RIS
relativamente agli esami eseguiti in modo che questo possa aggiornare lo stato di
ciascun esame (esame in corso, esame terminato, esame interrotto, lista delle immagini
prodotte). Le immagini prodotte dalla diagnostica vengono spedite ad un archivio di
immagini, detto sistema di archiviazione e comunicazione immagini (PACS), che le
renderà disponibili su richiesta per la refertazione. A questo punto il radiologo recupera
tali immagini dall’ archivio, le copia sulla workstation di Refertazione, dove le apre con
una applicazione di visualizzazione e scrive il referto sulla base delle sue osservazione.
Il referto può essere firmato con la firma digitale del radiologo ed essere archiviato per
poi venire consegnato al paziente.
Si può notare che il processo è costituito da un insieme di attività da eseguire in
maniera coordinata e coinvolgendo una serie di attori (uomini, macchine e sistemi
informatici) che, interagendo fra loro, consentono di arrivare al risultato finale (il
rilascio del referto). L’ ingresso di un nuovo paziente nel workflow corrisponde alla
creazione di una nuova istanza da processare. Mentre risulta relativamente semplice
automatizzare le singole funzioni (registrazione del paziente, refertazione ecc.), è
difficile integrare fra loro i vari sistemi in un unico flusso di lavoro.
2.3 Definizione di processo
La definizione di processo viene creata nel design-time e deve contenere tutte le
informazioni necessarie affinché possa essere gestita e controllata l’ esecuzione di ogni
sua istanza nel run-time. Quindi deve esplicitare l’ insieme delle attività di cui è
costituito il processo e l’ ordine con cui queste devono essere eseguite. Generalmente l’
evolvere del processo fra le varie attività (routing) può avvenire in maniera sequenziale,
parallela, condizionale o iterativa.
30
Nel primo caso una attività non può essere iniziata prima del completamento di
un’ altra, i cui risultati sono necessari alla prima e quindi queste devono essere eseguite
in sequenza. Nel secondo, invece, due o più attività possono essere eseguite
contemporaneamente oppure non è importante l’ ordine con cui vengono eseguite e,
quindi, vengono svolte in parallelo, favorendo, in questo modo, la concorrenza.
Il routing condizionale permette di scegliere fra più alternative, in base al
verificarsi o meno di determinate condizioni, che vengono valutate run time per ogni
singola istanza. Istanze relative alla medesima definizione di processo, pertanto,
possono essere eseguite in maniera differente: ad esempio, una attività può essere
presente in alcune e non in altre oppure può cambiare l’ ordine con cui certe attività
vengono svolte.
Infine si ha il routing iterativo quando è necessario ripetere una particolare
attività più volte, finché non si raggiunge il risultato desiderato.
La definizione di processo non specifica solamente quali attività devono essere
eseguite (cosa) ed in che ordine (quando), ma fornisce anche informazioni sulla risorsa
che deve eseguirle (chi). Una risorsa può essere una macchina o una persona e deve
avere le qualità appropriate per poter svolgere ciò che gli viene assegnato.
Associare un work item ad un partecipante significa ridurre la flessibilità del
sistema perché l’ assenza o la temporanea non disponibilità della stessa, causa l’
interruzione del flusso di lavoro. Per questo, generalmente, risorse con caratteristiche
simili vengono raggruppate in classi. Tale raggruppamento può avvenire in base alle
capacità dei suoi membri ed in questo caso la classe prende il nome di ruolo (role)
oppure in base all’ appartenenza o meno ad una determinata struttura organizzativa
(team, dipartimento, settore) ed allora essa prende il nome di unità organizzativa
(organizational unit). Una risorsa può appartenere a più classi.
Pertanto quando è presente una suddivisione di questo tipo, nella definizione di
processo si deve specificare per ogni attività, che richiede l’ assegnamento ad una
risorsa, i requisiti che questa deve possedere (principio di allocazione), ovvero il ruolo o
l’ unità a cui deve appartenere. Spesso vengono definiti entrambi ed in questo caso essa
va cercata fra l’ intersezione delle due classi. Inoltre l’ allocazione può dipendere anche
da particolari dati interni al processo. Ad esempio, nel caso di una compagnia di
31
assicurazioni con diverse sedi dislocate in un’ ampia area geografica, si può utilizzare l’
indirizzo del cliente come criterio per assegnare l’ istanza ad una risorsa appartenente
alla sede più vicina. A volte si possono specificare altri requisiti che la risorsa deve
soddisfare, che non fanno riferimento alle sue capacità o all’ appartenenza ad una
classe, come ad esempio il fatto che sia la meno impegnata o la più economica.
L’ assegnazione di un work item ad una particolare risorsa che soddisfa tale
principio di allocazione avviene nel run-time secondo diverse modalità ed utilizzando
specifiche regole nel caso sia necessario scegliere fra un certo numero di risorse
ugualmente idonee.
2.4 Prospettive di un workflow
Una definizione di workflow rappresenta una astrazione del processo reale e tale
astrazione può essere effettuata a diversi livelli in funzione dell’ uso che ne si vuole
fare. Ad esempio, una definizione di workflow realizzata ad un alto livello concettuale
può essere utilizzata per capire, analizzare e ristrutturare un processo. Lo stesso deve
essere rappresentato ad un livello più basso se lo si vuole successivamente
implementare su un workflow management system.
In questo ultimo caso una definizione deve catturare il processo sotto diversi
aspetti: l’ insieme delle attività di cui è costituito, le informazioni che devono essere
passate da una attività all’ altra, le risorse e le applicazioni necessarie per l’ esecuzione
del processo, ecc. Si parla allora di differenti prospettive (perspective) di una
definizione di workflow.
La principale è la cosiddetta prospettiva del flusso di controllo (control-flow
perspective), che descrive l’ insieme delle attività e l’ ordine con cui queste devono
essere eseguite. Poiché informazioni, dati e documenti sono un aspetto fondamentale in
un processo la cosiddetta prospettiva dei dati (data perspective) descrive come questi
vengono definiti ed utilizzati all’ interno del workflow. Inoltre l’ elenco delle attività da
svolgere ed i dati da trattare da soli non bastano; servono persone e attrezzature/impianti
32
per realizzare concretamente il processo. Allora la prospettiva delle risorse (resource
perspective) riguarda la strutturazione di queste in ruoli ed in che modo avviene l’
assegnazione dei work item.
A causa della grande varietà di processi reali che utilizzano la tecnologia del
workflow, la maggior parte dei prodotti esistenti sul mercato utilizzano un linguaggio
proprietario per creare definizioni di workflow. Il risultato è, quindi, un proliferare di
linguaggi molto differenti gli uni dagli altri e con diversi livelli di espressività in
funzione delle necessità richieste dalla tipologia di processo da modellare.
Si è tentato di effettuare un’ analisi del potere espressivo di un certo numero di
linguaggi usando dei workflow pattern. Questi sono stati individuati astraendo dal
contesto specifico nel quale i vari linguaggi esistenti venivano utilizzati e
rappresentando i requisiti più comuni che un linguaggio deve possedere per modellare i
processi reali indipendentemente dal tipo di processo e dalla tecnologia impiegata per
implementarlo.
In un primo tempo è stato raggruppato un insieme di 20 pattern che catturavano i
requisiti fondamentali relativamente al flusso di controllo in una definizione di
workflow. Successivamente sono stati presi in considerazione anche la prospettiva dei
dati e quella delle risorse.
2.4.1 Control-flow pattern
Inizialmente si è posta l’ attenzione sul flusso di controllo, che è l’ aspetto
basilare di un workflow, in cui le varie attività si devono susseguire secondo un certo
ordine per ottenere il risultato desiderato e, quindi, l’ implementazione su un sistema
informatico significa, per prima cosa, gestire il passaggio del controllo fra di esse.
Si è giunti, quindi, ad individuare un insieme di 20 pattern, che sono stati
suddivisi in 6 gruppi in questo modo:
1.
Basic Control Flow Patterns;
2.
Advanced Branching and Synchronization Patterns;
3.
Structural Patterns;
33
4.
State-based Patterns;
5.
Cancellation Patterns;
6.
Patterns involving Multiple Instances.
Il primo gruppo è costituito da pattern molto semplici da realizzare e, per questo,
presenti in qualsiasi linguaggio. Appartengono ad esso quei pattern che corrispondono
ai concetti definiti dalla WfMC riguardanti la natura del flusso di controllo attraverso il
processo. Primo fra tutti la Sequenza, che si ha quando “una attività in un workflow è
abilitata dopo il completamento di un’ altra attività nello stesso processo” e
generalmente è realizzata collegando le due attività in questione con una freccia.
Prima di presentare i pattern che consentono di modellare l’ esecuzione parallela
e la scelta fra varie attività, introduciamo i concetti di split e join. Si parla di split
quando, dopo il completamento di una attività, si ha una ramificazione che conduce a
due o più attività. Si distinguono differenti tipi di split in funzione del fatto che una sola
(XOR-split), alcune (OR-split) o tutte (AND-split oppure OR-split, se tutti i criteri di
scelta associati ai rami assumano il valore true) queste attività devono essere eseguite.
Analogamente quando due o più rami convergono in un unico ramo si parla di join.
Dipendentemente dal tipo di join prima di iniziare l’ attività successiva si deve attendere
il completamento di una (XOR-join), alcune (OR-join) o tutte (AND-join) le attività
precedenti.
Nel caso di esecuzione parallela di due o più attività si utilizzano i due pattern
Split Parallelo (AND-split) e Sincronizzazione (AND-join). Il primo viene definito
come “un punto dove un singolo thread di controllo si divide in molteplici thread di
controllo che possono essere eseguiti in parallelo”. Il secondo viene descritto come “un
punto dove molteplici sottoprocessi/attività convergono in un singolo thread di
controllo, consentendo, quindi, la sincronizzazione di molteplici thread”.
Analogamente si possono definire la Scelta Esclusiva (XOR-split), in cui una
sola fra varie alternative viene selezionata ed eseguita, e la Simple Merge (XOR-join),
nella quale i vari rami vengono fatti riconvergere senza necessità di sincronizzazione.
Oltre questi pattern molto semplici, ne esistono altri più complessi ma, ciò
nonostante, ricorrenti nella modellazione dei processi reali. Ad esempio, spesso si ha la
necessità di scegliere, a seconda dei casi, una, alcune o tutte fra molte alternative (Scelta
34
Multipla o OR-split) e questo è di più difficile implementazione. Nei workflow
management system nei quali è possibile associare una condizione ad ogni arco uscente
dal nodo di split, tale pattern può essere realizzato direttamente. Ciò non è possibile,
invece, negli altri, nei quali, quindi, si deve utilizzare una combinazione di Split
Parallelo e Scelta Esclusiva, come mostrato in figura 3 (workflow B). Ogni alternativa è
preceduta da uno XOR-split che decide, in base al verificarsi o meno di una determinata
condizione, se selezionarla o passare oltre. Tutti gli OR-split sono attivati da un ANDsplit.
Figura 2.3
Ancora più difficile è la realizzazione del corrispondente Synchronizing Merge,
nel quale i vari flussi generatisi dalla Scelta Multipla devono riconvergere in uno unico.
Il problema è che non si sa quali rami devono essere sincronizzati. Infatti nel caso in cui
uno solo è attivo, non è necessaria alcuna sincronizzazione e tale pattern deve svolgere
la funzione di XOR-join. A volte, invece, è richiesta la sincronizzazione di tutti i rami
(AND-join) ed altre una sincronizzazione parziale (OR-join).
Un altro gruppo molto importante è quello che supporta le istanze multiple,
ovvero la possibilità di istanziare più volte una singola attività o una parte del processo,
permettendo così l’ esecuzione concorrente. Facendo di nuovo l’ esempio di una
compagnia di assicurazioni che deve gestire una richiesta di indennizzo può essere
35
necessario raccogliere deposizioni di vari testimoni. Ciò può essere modellato con un
sottoprocesso che viene istanziato tante volte quanti sono i testimoni.
Esistono diversi pattern appartenenti a questa categoria. Innanzitutto si può avere
o meno la sincronizzazione di tali istanze, cioè prima di procedere con l’ attività
successiva si attende che tutte siano state completate (istanze multiple con
sincronizzazione) oppure per ognuna si procede oltre indipendentemente dalle altre
(istanze multiple senza sincronizzazione).
Inoltre un’ altra questione che genera differenza nei pattern di questo gruppo
riguarda il numero delle istanze che vengono create. Raramente nei processi reali tale
numero è conosciuto nel design time perché esso può dipendere dalle caratteristiche
della particolare istanza di processo o dalla disponibilità delle risorse. In questo caso,
quindi, tale numero è noto solamente durante l’ esecuzione (nel run time) prima di
iniziare la parte di processo che deve essere istanziata più volte. Si può verificare, però,
anche la situazione in cui tale numero varia dinamicamente, ovvero nuove istanze
possono essere generate, mentre altre sono già in fase di processamento e addirittura
qualcuna è stata completata. Infatti riprendendo l’ esempio precedente, si può verificare
che, durante la deposizione di un testimone, ne vengano fuori degli altri fino ad allora
non noti che devono essere aggiunti alla lista. Allora per supportare tali differenti
situazioni esistono tre tipi di pattern: istanze multiple con conoscenza a priori nel design
time, con conoscenza a priori nel run time e senza conoscenza a priori nel run time.
Proseguendo nella descrizione dei vari pattern, un ulteriore gruppo che si può
prendere in considerazione è quello che consente di cancellare una parte o l’ intera
istanza di processo. Questo è necessario quando, in qualunque momento durante l’
esecuzione di una istanza, si verifica un evento che va ad influire su una qualsiasi parte
del processo (non necessariamente quella che si sta eseguendo).
Successivamente sono stati individuati altri 23 control-flow pattern, che si sono
aggiunti a questi primi 20.
36
2.4.2 Altri pattern
Dopo i pattern per il flusso di controllo, l’ attività di astrazione è continuata
prendendo in considerazione altre prospettive del workflow ed ha portato all’
elaborazione di ulteriori pattern, in riferimento, ad esempio, all’ utilizzo dei dati ed alla
strutturazione delle risorse.
Per quanto riguarda i dati, si sono riscontrate caratteristiche comuni
raggruppabili in quattro differenti concetti:

la visibilità, ovvero i differenti modi in cui le variabili possono essere
definite e che determina dove i dati possono essere utilizzati: ad esempio, a
livello di istanza di attività (variabile locale), di istanza di processo
(variabile globale), ecc.;

l’ interazione, che considera la capacità di scambiare dati fra le varie attività
costituenti il workflow (passaggio interno) e fra workflow e risorse o servizi
(passaggio esterno);

il trasferimento, che analizza il modo in cui i dati del punto precedente
vengono trasferiti (ad esempio, per valore o per riferimento);

il routing, cioè come i dati possono influenzare altri aspetti del workflow,
particolarmente il flusso di controllo (ad esempio, la successiva attività da
compiere può essere determinata run time in base al valore assunto da una
variabile).
Sono stati confrontati differenti linguaggi esistenti per modellare workflow in
base alla loro capacità di implementare i primi 20 control-flow pattern presi in
considerazione e si è evidenziato che la maggior parte di essi ne supporta direttamente
meno della metà. A volte alcuni, come abbiamo già visto, possono essere costruiti
utilizzandone degli altri (anche se a costo di una rappresentazione meno compatta) ma
per quelli più complessi generalmente ciò non è possibile.
I linguaggi basati sulle reti di Petri consentono di descrivere efficacemente
workflow anche complessi e di modellare molti di questi pattern. Inoltre la teoria
37
sviluppatasi alla base delle reti di Petri fornisce potenti tecniche di analisi per verificare
la loro correttezza.
2.5 Reti di Petri
Una rete di Petri classica è un grafo bipartito, i cui nodi possono essere di due
tipi: posti o transizioni. I primi sono rappresentati da cerchi, i secondi da rettangoli.
Archi orientati consentono la connessione posto-transizione e transizione-posto, mentre
non è permessa la connessione fra due nodi dello stesso tipo.
Definizione. Una rete di Petri è una tripla (P,T,F) dove:
-
P è un insieme finito di posti;
-
T è un insieme finito di transizioni (disgiunto da P);
-
F  (T x P)  (P x T) è la relazione di flusso, ovvero l’ insieme di tutte le
coppie ordinate (P,T) e (T,P) connesse da un arco orientato.
Ad ogni arco viene associato un peso n   (se n=1, viene omesso). I posti
possono contenere zero o più token (indicati con punti neri) e la loro distribuzione in un
determinato istante di tempo rappresenta lo stato della rete, chiamata anche marcatura:
M  P  .
Un posto p viene definito posto di input di una transizione t quando esiste un
arco orientato da p a t. Invece viene definito posto di output quando l’ arco va da t a p.
Si utilizzano t e t per indicare, rispettivamente, l’ insieme dei posti di input e l’
insieme dei posti di output della transizione t. Alla stessa maniera possono essere
definite le notazioni p e p come l’ insieme delle transizioni che hanno p,
rispettivamente, come posto di output e come posto di input.
Una transizione, in genere, rappresenta un evento, un’ azione, una
trasformazione o un trasporto, mentre un posto un mezzo, un buffer, un luogo
geografico o una condizione. I token indicano oggetti fisici o informazioni.
Facendo il caso della solita compagnia di assicurazioni che deve gestire diverse
richieste di indennizzo, il processo può essere così modellato: ogni richiesta viene prima
38
registrata e, dopo essere stata analizzata, si effettua il pagamento oppure si spedisce una
lettera di rifiuto. Quindi si utilizzano tre posti e tre transizioni (figura 4).
Figura 2.4 - rete di petri
I token nel primo posto indicano la presenza di tre richieste che devono essere
trattate. Lo stato della rete viene indicato con questa notazione M=[3 0 0].
Una transizione si dice abilitata se ogni suo posto di input contiene un numero di
token almeno pari al peso dell’ arco che lo connette alla transizione. Una transizione
abilitata può scattare e ciò determina la rimozione da ogni suo posto di input e l’
aggiunta ad ogni suo posto di output di un numero di token pari al peso degli archi che
la collegano a tali posti. Si può anche dire che, quando la transizione scatta, essa
consuma token dai suoi posti di input e produce token nei suoi posti di output (figura 5).
Nel nostro esempio, solo la transizione registrazione è abilitata e quando scatta,
la rete passa ad un altro stato (M1=[2 1 0]).
Figura 2.5 - scatto di una transizione
39
Ora tutte le transizioni sono abilitate ma solo una può scattare. Lo scatto di una
anziché di un’ altra significa una evoluzione futura differente per la rete. Nella versione
classica, in genere, la scelta è del tutto non-deterministica, ovvero fatta a caso.
Uno stato M si dice raggiungibile da uno stato M’ se esiste almeno una sequenza
di transizioni tali che facendole scattare si arriva da M’ a M. Considerando una rete di
Petri con stato iniziale M (PN,M), essa gode delle seguenti proprietà fondamentali:
-
vivezza, quando per ogni stato raggiungibile M ed ogni transizione t, esiste
uno stato M’ raggiungibile da M che abilita t;
-
limitatezza, quando in un qualunque stato raggiungibile ogni posto possiede
un numero di token inferiore a k; se per ogni posto il massimo numero di
token non supera il valore 1, la rete si definisce safe.
Un percorso connette dei nodi tramite una sequenza di archi ed è definito
elementare se ogni nodo è unico. Data una rete di Petri un percorso C da un nodo n1 ad
un nodo nk è una sequenza (n1,n2,….nk) tale che (ni,ni+1)  F per 1 i k-1. C è
elementare se per ogni coppia di nodi ni e nj di C, con i  j, risulta ni  nj. Data questa
definizione si può introdurre un’ ulteriore proprietà: una rete di Petri si definisce
fortemente connessa quando per ogni coppia di nodi (posti e transizioni) x e y, c’ è un
percorso che collega x con y.
2.5.1 Reti di Petri di alto livello
Sono state proposte molte estensioni alla versione classica: ad esempio, il colore,
il tempo e la gerarchia. In una rete di Petri classica due token nello stesso posto sono
indistinguibili e spesso ciò è indesiderabile. Ad esempio, nel caso di due differenti
richieste di indennizzo, si desidera associare ad ognuna caratteristiche quali la sua
tipologia, il numero di polizza, il nome del detentore della polizza ed il valore stimato
della richiesta. Ciò può essere fatto utilizzando l’ estensione colore, ovvero si associa ad
ogni token, appunto, un colore o valore che permette di identificarlo come oggetto con
quelle caratteristiche. In questo caso, lo scatto di una transizione abilitata produce token
nei suoi posti di output di valore ed in numero dipendenti dai valori di quelli consumati.
40
Ad esempio, ora si può verificare che, in seguito allo scatto, uno o più posti di output
non ricevano alcun token in funzione delle informazioni contenute in quelli presenti nei
posti di input. Ciò consente di modellare la scelta; cosa che non è possibile nella rete di
Petri classica.
Inoltre è possibile associare ad una transizione una condizione sul valore dei
token da consumare. In questo modo la transizione è abilitata solamente quando ogni
suo posto di input contiene un numero di token pari al peso dell’ arco che lo collega ad
essa e, contemporaneamente, è soddisfatta tale condizione. Ad esempio, nel processo di
assemblaggio di una macchina, i vari pezzi da montare (telaio, motore, ruote, ecc.) non
possono essere scelti a caso bensì devono adattarsi bene l’ uno con l’ altro. Tale
situazione può essere modellata con una rete di Petri colorata, in cui ognuno di questi
pezzi viene rappresentato da un token, il cui colore contiene le caratteristiche principali
del pezzo e la transizione assemblaggio contiene una condizione che consente di
combinare fra loro pezzi che possiedono determinate caratteristiche.
Contrariamente a quanto accade nella rete di Petri classica, ora la sola
rappresentazione grafica non è sufficiente, ma è necessario aggiungere un testo, che
specifichi tutte queste informazioni aggiuntive.
Un’ altra estensione molto importante è l’ introduzione del tempo, ovvero si
associa ad ogni token un valore di tempo, che indica da quale momento lo stesso sarà
disponibile per essere consumato. In questo modo, i token presenti nei posti di input di
una transizione possono non essere immediatamente disponibili ma necessitare dello
scorrere di un certo tempo prima che possano essere utilizzati. In questo caso, quindi,
una transizione è abilitata solo quando il tempo associato ai token che essa deve
consumare ha un valore uguale o precedente a quello corrente. Fra più transizioni
abilitate, scatta quella che lo è da un tempo maggiore. Inoltre ai token prodotti nei posti
di otput può essere associato un ritardo, che deve trascorrere dal momento dello scatto
prima che essi siano disponibili.
Infine si può aggiungere anche la gerarchia, introducendo nella rete un nuovo
blocco: un quadrato con bordo doppio. Questo rappresenta una sottorete, a sua volta
costituita da posti, transizioni, archi ed eventuali ulteriori sottoprocessi. Ciò permette di
41
strutturare reti complesse in una forma più facilmente leggibile e gestibile e di
consentire il riuso di reti già definite.
Una rete di Petri estesa con colore, tempo e gerarchia viene definita di alto
livello.
2.5.2 Reti di Petri e workflow
Ora vediamo come un workflow può essere modellato da una rete di Petri di alto
livello. Questa deve possedere determinate caratteristiche, ovvero deve avere una
entrata (un posto senza archi in ingresso) ed un’ uscita (un posto senza archi in uscita).
Inoltre deve soddisfare due requisiti fondamentali: deve sempre essere possibile
raggiungere lo stato in cui è presente un token nel posto di uscita e, quando ciò si
verifica, non deve essere presente nessun altro token all’ interno della rete relativo a
quella stessa istanza. Ciò garantisce che questa sia stata completata correttamente. Tale
rete prende il nome di workflow net.
Le transizioni modellano le varie attività che costituiscono il processo, mentre i
posti rappresentano le condizioni che devono verificarsi affinchè ciascuna attività possa
essere eseguita. Un token nel posto di ingresso indica la presenza di una nuova istanza
che deve essere eseguita, mentre un token nel posto di uscita significa che l’ istanza è
stata completata. Ogni distribuzione di token presente nella rete fra questi due istanti
rappresenta lo stato del processo in quel momento. Infine una transizione abilitata indica
che l’ attività corrispondente può essere eseguita e lo scatto indica che è stata eseguita.
La rete di Petri consente di modellare il routing sequenziale, condizionale,
parallelo e iterativo e vediamo come. Per quanto riguarda il primo caso, le due
attività/transizioni che devono essere eseguite sequenzialmente vengono collegate
interponendo fra di loro un posto (figura 6).
42
Figura 2.6 - routing sequenziale
Quando, invece, due attività possono essere eseguite contemporaneamente o non
è importante l’ ordine con cui vengono eseguite, si utilizza una transizione per
rappresentare l’ AND-split da cui partono due rami. Quando tale transizione scatta,
produce un token in ognuno dei suoi posti di output che abilitano contemporaneamente
entrambe le attività. Una volta che queste sono state eseguite, una ulteriore transizione
funge da AND-join e consente di sincronizzare i due flussi paralleli (figura 7).
Figura 2.7 - routing parallelo
Quando si deve scegliere fra due alternative, OR-split ed OR-join sono modellati
ciascuno con un posto: dal primo partono due rami che rappresentano le alternative,
mentre al secondo questi due rami convergono (figura 8). In questo modo, però, la
scelta a livello della rete è non deterministica ed è lasciata al sistema a run time.
43
Figura 2.8 - routing condizionale
Se la si vuole, invece, modellare sulla base del valore di alcuni attributi del
processo stesso, si utilizza l’ estensione colore e l’ OR-split, in questo caso, viene
rappresentato da due transizioni a cui vengono associate delle precondizioni che
selezionano l’ attività da svolgere in funzione del colore del token (che contiene gli
attributi/dati relativi all’ istanza in questione). L’ OR-join è sempre rappresentato da un
posto. Infine è possibile ripetere più volte una attività (figura 9).
Figura 2.9 - iterazione
Nel caso vengano processate contemporaneamente più istanze della stessa
definizione di processo, queste devono poter essere gestite separatamente l’ una dall’
altra. Ciò può essere modellato in una rete di Petri in due modi: è possibile utilizzare
una unica rete di Petri colorata, in cui ogni token ha un colore che contiene informazioni
sull’ identità della particolare istanza a cui appartiene oppure si può utilizzare una copia
della rete di Petri in questione per ciascuna istanza.
Infine una rete di Petri estesa con gerarchia consente di modellare sottoprocessi
all’ interno di processi complessi utilizzando sottoreti.
44
2.6 Workflow Management System
Il Workflow Management System (WfMS) viene definito come “un sistema che
definisce, crea e gestisce l’esecuzione di un workflow attraverso l’ uso di software. E’
capace di interpretare gli schemi, interagire con i partecipanti del workflow e invocare
l’uso di strumenti ed applicazioni automatizzate” (WfMC).
La nascita del WfMS ha segnato la separazione fra il sistema software che si
occupa della gestione del processo e le applicazioni che eseguono effettivamente le
attività necessarie per la realizzazione del processo. Tale separazione consente di creare
un sistema per la gestione del workflow con funzionalità generiche e, quindi,
indipendente dalle specifiche applicazioni utilizzate. Ciò ha alimentato le aspettative di
chi desidera raggiungere l’ interoperabilità e l’ integrazione fra i diversi prodotti di
workflow e si adopera per lo sviluppo di standard. La questione, però, è tutt’ altro che
semplice.
Esiste una grande varietà di processi che utilizzano la tecnologia del workflow,
da quelli che hanno un ciclo di vita di minuti o che coinvolgono un piccolo gruppo
locale a quelli che richiedono giorni (persino mesi) per essere eseguiti o necessitano la
cooperazione di diverse aziende distribuite su un territorio esteso. Inoltre un sistema per
la gestione di workflow può puntare al raggiungimento di differenti obiettivi: la
flessibilità, l’ integrazione del sistema, l’ ottimizzazione del processo, ecc. e, quindi, è
difficile determinare quali funzionalità deve avere un generico WfMS.
Lo sforzo della WfMC in tale direzione ha portato ad identificare tre aree
funzionali comuni nei workflow management system esistenti. La prima fornisce le
funzioni di build-time per l’ analisi, la definizione e la rappresentazione del processo.
La definizione di processo, che ne deriva, può essere espressa in una forma testuale o
grafica o utilizzando un linguaggio formale. Questa è considerata l’ area in cui è
consentita la maggior differenziazione fra i vari prodotti presenti sul mercato, in modo
da fornire differenti funzionalità per facilitare la modellazione di tipi diversi di
processo. Invece l’ opera di standardizzazione riguarda la possibilità di trasportare i dati
della definizione di processo a differenti strumenti di analisi, definizione e modellazione
45
e prodotti per l’ esecuzione del processo. La freccia a tratto discontinuo in figura 10
indica che alcuni sistemi di workflow consentono di modificare dinamicamente la
definizione di processo, ovvero durante l’ esecuzione di un’ istanza di processo.
Figura 2.10
La seconda area funzionale è costituita da software capace di interpretare la
definizione di processo, creare le istanze e controllare l’ evoluzione del processo
attraverso le varie attività di cui è costituito invocando, quando necessario, le risorse
umane e/o le applicazioni IT opportune. Il componente principale è il motore di
workflow (workflow engine).
Infine l’ ultima area funzionale gestisce l’ interazione fra le singole attività ed il
software per il controllo del processo per permettere il trasferimento del controllo fra le
varie attività, invocare le applicazioni e passare i dati appropriati, ecc.
2.6.1 Componenti di un WfMS
Sulla base delle tre aree funzionali individuate, si può definire un modello
generale di sistema di workflow, che si adatta bene alla struttura della maggior parte dei
46
prodotti presenti sul mercato e ne identifica i principali componenti. In figura 11 si fa
distinzione fra i componenti software propri del sistema (rettangoli riempiti scuro), che
forniscono le funzionalità sopra citate e le applicazioni esterne (rettangoli riempiti
chiaro), che non fanno parte del prodotto di workflow ma possono essere invocate da
questo per eseguire le attività. Inoltre i rettangoli senza riempimento rappresentano i
vari dati utilizzati per il controllo e la definizione del processo.
Ora analizziamo uno per uno i diversi componenti del modello.
Figura 2.11 - componenti di un wfms
Lo strumento per la definizione (Definition Tool) consente di specificare una
rappresentazione formale del processo, in modo che questo possa essere poi eseguito dal
workflow enactment service. La definizione di processo deve contenere tutte le
informazioni necessarie al suo processamento: le condizioni di inizio e di
completamento, le attività di cui è costituito e le regole per passare dall’ una all’ altra, i
47
compiti che devono essere assegnati all’ utente (o ad una classe di utenti, nel caso siano
presenti strumenti per strutturare le risorse in ruoli e/o unità) e riferimenti alle
applicazioni che possono essere invocate.
Il workflow enactment service è il componente principale. Interpreta la
definizione di processo, crea le istanze e controlla la loro esecuzione, aggiungendo work
item nella work list degli utenti e invocando applicazioni se necessario. In altre parole
assicura che le attività giuste siano eseguite nell’ ordine giusto e dalle persone e/o
applicazioni giuste.
Può essere costituito da più motori (sistema distribuito), che possono cooperare
nell’ esecuzione del processo in vari modi. La distribuzione del lavoro fra di essi può
essere fatta in base al tipo di processo, ovvero ogni motore controlla e gestisce
interamente l’ esecuzione di quei processi che corrispondono ad una determinata
tipologia. Altre volte, invece, ad ogni motore è consentito gestire l’ esecuzione di quelle
parti del processo che richiedono l’ uso di risorse appartenenti al suo dominio di
controllo oppure possono essere adottati altri meccanismi di partizionamento del lavoro.
Sistemi distribuiti usano specifici protocolli per sincronizzare le operazioni e lo scambio
di informazioni fra i vari motori.
Se è richiesta l’ interazione dell’ utente, il motore aggiunge il work item alla
worklist, che contiene appunto una lista di tutti gli item che devono essere eseguiti da
un partecipante o un gruppo di partecipanti. E’ compito del worklist handler assegnare
tali item all’ utente secondo due possibili modalità: presentandogli il lavoro successivo
che deve portare a termine (modalità push) oppure consentendogli di selezionarlo
direttamente dalla lista (modalità pull). L’ interfaccia utente è responsabile del look and
feel e in molti sistemi può costituire un’ unica unità funzionale con il worklist handler.
Nel caso l’ utente abbia bisogno del supporto di una applicazione locale per
svolgere un compito, l’ invocazione di questa può essere effettuata dal worklist handler,
al momento in cui presenta il work item all’ utente, o dall’ utente stesso. Quindi una
applicazione può essere invocata direttamente dal workflow engine o, nel caso debba
supportare una attività umana, dal worklist handler/utente.
Tipicamente, nei sistemi di workflow sono fornite delle funzioni di supervisione,
che consentono di alterare le regole per l’ allocazione del lavoro, identificare i
48
partecipanti appartenenti ad un determinato ruolo, conoscere la storia di una particolare
istanza, avere informazioni sul throughput ed altre statistiche, ecc. Queste funzioni sono
accessibili solo a chi possiede il privilegio di supervisore, generalmente assegnato ad
una particolare workstation o utente.
Per il buon funzionamento dell’ intero sistema, i vari componenti devono
scambiare informazioni l’ uno con l’ altro. Si distinguono differenti tipi di dati. Quelli
manipolati direttamente dalle applicazioni invocate prendono il nome di workflow
application data e non sono accessibili dalle macchine di workflow, sebbene queste,
quando necessario, sono responsabili del trasferimento di tali dati fra diverse
applicazioni invocate in differenti punti del processo. A volte possono essere usati per
determinare un cambiamento di stato, allora diventano relevant data ed, in questo caso
eccezionale, sono accessibili alle macchine di workflow. Questo secondo tipo di dati,
conosciuto anche come case data, viene utilizzato, insieme alla definizione di processo,
dal workflow management system per controllare l’ esecuzione delle varie attività all’
interno del processo. Quindi contengono informazioni riguardanti i criteri di ingresso e
di uscita di ogni singola attività, i compiti da assegnare ad utenti o le applicazioni da
invocare. Infine esiste un terzo tipo di dati denominato control data. Questi sono interni
al workflow management system e non accessibili alle applicazioni ed indicano lo stato
delle istanze e delle attività in esecuzione.
Il workflow management system non ha l’ assoluto controllo sull’ esecuzione del
processo, bensì semplicemente lo gestisce, come esplicitato nella definizione stessa.
Infatti, se un task deve essere eseguito, non significa che lo sarà per certo. Ad esempio,
se si deve elaborare una form compilata da un cliente, può capitare che tale cliente non
l’ abbia compilata. Quindi l’ istante in cui il task è abilitato dal sistema per essere
eseguito e l’ istante in cui inizia l’ esecuzione effettiva non coincidono necessariamente.
Si parla allora di triggering: un trigger è una condizione esterna il cui verificarsi
determina l’ esecuzione di un task abilitato (ad esempio, la selezione del task in
questione da parte di un utente, lo scadere di un tempo, ecc.).
49
2.6.2 Workflow Reference Model
Per raggiungere l’ interoperabilità fra differenti prodotti è necessario creare un
insieme standard di interfacce e di formati per lo scambio di dati fra i vari componenti.
La WfMC ha sviluppato un modello di riferimento nel quale sono identificati i
componenti di un generico sistema di workflow e le interfacce fra di essi.
Figura 2.12 - workflow reference model
Ogni interfaccia è realizzata usando il cosiddetto WAPI (Workflow Application
Programming Interface), ovvero un gruppo di servizi che sono offerti da un server ad un
client. Questi servizi possono essere comparati alle chiamate ad una procedura in un
classico linguaggio di programmazione. Nel sistema, il Workflow Enactment Service
funziona da server mentre gli altri software di supporto per la creazione della
definizione di processo e per l’ amministrazione e monitoraggio del processo e le
applicazioni sono i client.
50
E’ previsto in tale modello l’ interoperabilità fra differenti Workflow Enactment
Service. Sono stati proposti degli standard per queste interfacce ma si sta lavorando
ancora alla loro creazione.
51
52
Capitolo 3
YAWL
3.1 Introduzione
Yawl (Yet another workflow language) nasce nel 2002 come linguaggio per
workflow da un progetto congiunto fra la Eindhoven University of Technology e la
Queensland University of Technology. Successivamente è stato creato anche un sistema
open source per interpretare ed eseguire workflow scritti in tale linguaggio e che porta
lo stesso nome. La prima versione è uscita nel novembre 2003.
In questo capitolo viene presentato il linguaggio Yawl con i simboli che utilizza
e viene analizzata la sua espressività in base alla sua capacità di rappresentare i
workflow pattern individuati nel capitolo precedente.
In seguito viene descritto il sistema Yawl, con i suoi componenti software che
permettono la gestione e l’ esecuzione di workflow scritti in tale linguaggio. Vengono
presentati: l’ editor, che fornisce un ambiente grafico per modellare ed analizzare i
workflow; il motore, che gestisce l’ esecuzione di tali workflow ed un insieme di servizi
inclusi nel sistema per fornire funzionalità utili allo svolgimento di alcune attività
presenti nel workflow. Si accenna anche alle sue capacità (al momento attuale limitate)
di gestire le risorse in ruoli e di effettuare analisi statistiche e monitorare l’ esecuzione
delle varie istanze.
In questo capitolo si adotta la stessa terminologia utilizzata dagli sviluppatori di
Yawl, che differisce rispetto a quella introdotta nel capitolo precedente. Infatti i termini
task, work item ed attività, qui, hanno un significato diverso da quanto stabilito dalla
WfMC. Il primo coincide con il termine attività da questa definita e, quindi, è un
generico pezzo di lavoro rappresentato come una entità logica all’ interno della specifica
53
di workflow. Quando ci si riferisce ad una determinata istanza di workflow, il termine
task viene sostituito con il termine work item. Infine quando un work item passa allo
stato in esecuzione prende il nome di attività.
3.2 Linguaggio Yawl
I linguaggi basati sulle reti di Petri possiedono molti dei 20 pattern citati nel
capitolo precedente, in particolare quelli basati sullo stato, supportati solamente da quei
linguaggi che consentono di rappresentare esplicitamente lo stato (come appunto le reti
di Petri). Ciò nonostante queste non permettono di modellare direttamente pattern
importanti come quelli che trattano le istanze multiple, il Synchronizing Merge e quelli
per la cancellazione.
Sulla base di queste considerazioni nel 2002 è iniziato lo sviluppo del linguaggio
Yawl da un progetto congiunto fra la Eindhoven University of Technology e la
Queensland University of Technology con lo scopo di superare le limitazioni presenti
nei linguaggi per workflow allora esistenti. Si ispira alle reti di Petri ma è esteso con
costrutti che consentono di modellare anche quei pattern non rappresentati da esse;
infatti supporta 19 dei 20 pattern presi in considerazione.
Una specifica di workflow in Yawl è un insieme di workflow net (rete di
workflow) che formano una gerarchia e, quindi, realizza una struttura ad albero. Un task
corrisponde ad una transizione in una rete di Petri e può essere atomico o composito. Un
task composito fa riferimento ad una workflow net ad un livello più basso nella
gerarchia. I task atomici costituiscono le foglie della struttura ad albero.
Ogni workflow net consiste di un insieme di task e condizioni (corrispondenti a
posti in una rete di Petri) e possiede un’ unica condizione di input ed un’ unica
condizione di output. Come nelle reti di Petri, questi due elementi (task e condizioni)
sono connessi in modo da formare un grafo orientato, ma a differenza di esse, è
possibile connettere task/transizioni direttamente fra loro senza necessariamente
utilizzare condizioni/posti in mezzo.
54
La simbologia usata in Yawl è simile a quella delle reti di Petri: un quadrato
semplice rappresenta un task atomico mentre un quadrato con bordo doppio un task
composito; un cerchio rappresenta una condizione (con l’ aggiunta di notazioni
particolari per la condizione di input e la condizione di output). Ulteriori simboli
consentono di modellare le istanze multiple di un task atomico e di un task composito e
la possibilità di cancellare una specifica regione.
Figura 3.1 - simboli utilizzati nel linguaggio Yawl
Per quanto riguarda le istanze multiple, Yawl permette di specificare un limite
superiore ed uno inferiore per il numero di istanze che possono essere create. Inoltre
consente di indicare una soglia che rappresenta quante istanze vengono completate
prima che il task completii e si proceda con il successivo. Le istanze ancora non
completate vengono interrotte. Se tale soglia non è specificata il task completa quando
sono state completate tutte le istanze. Infine è possibile definire un ultimo parametro che
può assumere i valori “statico” o “dinamico” e si riferisce alla possibilità o meno di
creare nuove istanze mentre altre sono già in esecuzione.
Inoltre per rappresentare i vari split e join il simbolo del task viene modificato in
questo modo:
55
Figura 3.2 - simboli dei vari split e join in Yawl
Si può notare come Yawl consenta di modellare direttamente le istanze multiple
e le cancellazioni fornendo appositi simboli grafici. Inoltre introduce, accanto agli
AND/XOR-split/join, l’ OR-split e l’ OR-join, che corrispondono rispettivamente ai
pattern Scelta Multipla e Synchronizing Merge.
3.3 Sistema Yawl
Successivamente alla creazione di Yawl è stato sviluppato anche un sistema
open source per interpretare ed eseguire workflow scritti in tale linguaggio e che porta
lo stesso nome. Esso fornisce un editor grafico per realizzare workflow in Yawl ed un
motore per gestire l’ esecuzione delle istanze, oltre ad un insieme di servizi che
costituiscono il cosiddetto “ambiente” di Yawl. Poiché il sistema adotta una architettura
orientata al servizio, le sue funzionalità possono essere facilmente estese aggiungendo
altri servizi a quelli già esistenti. Inoltre offre un supporto per la persistenza dei dati
interfacciandosi a PostgreSQL. L’ architettura di questo sistema è mostrata in figura.
56
Figura 3.3 - architettura del sistema Yawl
Le specifiche di workflow sono realizzate utilizzando lo Yawl designer e
caricate nel motore Yawl (Yawl engine). Questo, dopo aver effettuato tutte le necessarie
verifiche e la registrazione dei task, le immagazzina nello Yawl repositary. A questo
punto, le specifiche caricate con successo, possono essere istanziate in qualsiasi
momento attraverso il motore Yawl, che gestisce l’ esecuzione di tali istanze.
L’ ambiente di un sistema Yawl è composto da un insieme di servizi. In Yawl
con il termine servizio si intende senza distinzione una applicazione, un utente o una
organizzazione. Infatti viene adottato il principio proprio delle architetture orientate al
servizio (SOA) in cui per astrazione tutte le entità esterne o offrono o richiedono servizi.
In figura sono mostrati quattro servizi:
1.
Yawl worklist handler corrisponde al classico worklist handler presente
nella maggior parte dei workflow management system e, come si è già detto
nel capitolo precedente, svolge la funzione di assegnare compiti agli utenti
del sistema;
57
2.
Yawl web services broker funge da mediatore fra il motore Yawl ed i servizi
web esterni che possono essere invocati per svolgere alcune operazioni (ad
esempio, per poter utilizzare un servizio di pagamento online);
3.
Yawl interoperability broker consente di interconnettere differenti motori di
workflow;
4.
custom Yawl service connette il motore Yawl con una entità presente nell’
ambiente del sistema.
Infine un ultimo componente è costituito dallo Yawl manager, che fornisce
funzioni di management: consente di controllare manualmente le istanze (ad esempio, se
si vuole cancellare una istanza o una specifica di workflow), fornisce informazioni sullo
stato delle istanze in esecuzione e dati riguardanti le istanze completate.
Il motore Yawl possiede due gruppi di interfacce:

il gruppo A consente l’ interazione fra lo Yawl designer e lo Yawl manager
da un lato e il motore Yawl dall’ altro corrisponde alle interfacce 1 e 5 del
modello di riferimento introdotto dalla WfMC;

il gruppo B permette l’ interazione fra i servizi e il motore Yawl e
corrisponde alle interfacce 2, 3 e 4 dello stesso modello sopra citato.
Entrambi i gruppi sono specificati in WSDL.
Gli utenti interagiscono con il sistema tramite un browser web, ovvero sia lo
Yawl manager sia il worklist handler offrono front-end HTML.
Una differenza fondamentale rispetto ai workflow management system esistenti
è che il motore Yawl gestisce il flusso di controllo e i dati delle istanze di workflow ma
non direttamente gli utenti. Quindi si preoccupa del “cosa” e “quando”, mentre il
“come” e “da chi” è affidato ai servizi Yawl.
3.4 Editor Yawl
L’ editor Yawl consente di modellare specifiche di workflow e di verificarne
build time la correttezza semantica (ad esempio, rileva la presenza di eventuali deadlock
58
e di task non eseguiti) e quella sintattica, ovvero il rispetto delle regole che consentono
la sua esecuzione nel motore (ad esempio, segnala la mancata definizione dei parametri
per il passaggio dei dati attraverso il workflow). Una volta terminata la creazione dello
schema, questo viene esportato in formato XML per poter essere elaborato dal motore.
L’ editor permette anche l’ operazione inversa, ovvero di importare le specifiche in
formato XML e tradurle nel formato proprietario Yawl.
Consente di rappresentare i vari task (atomici, compositi, istanze multiple) ed i
collegamenti fra di essi utilizzando differenti tipi di split e join (AND, OR, XOR).
Permette anche di modellare le cancellazioni, come già visto. Quindi supporta 19 dei 20
control-flow pattern presi in considerazione nel capitolo precedente, fornendo una
grande capacità espressiva per quanto riguarda la prospettiva del flusso di controllo di
un workflow.
Figura 3.4 - editor Yawl
59
La definizione di un task, atomico o composito, avviene nella cosiddetta
decomposizione di task (task decomposition). Per poter essere eseguito, ogni task deve
avere una decomposizione (identificata da un nome), nella quale si possono specificare
le variabili utilizzate, una label da associare al task ed un servizio che deve essere
invocato a tempo di esecuzione. Le decomposizioni di task definite nella specifica sono
visibili a tutta la rete e più task possono condividere (riutilizzare) la stessa
decomposizione, ad indicare che per loro è richiesta la stessa attività. Si può dire,
quindi, che esiste una relazione di 1:N fra decomposizioni e task. Quindi, per specificare
la decomposizione di un task, la si può selezionare fra quelle che sono già state create o
crearne una nuova. La decomposizione di un task composito coincide con quella della
sottorete a cui è collegato.
Anche la rete ha la sua decomposizione, nella quale vengono definite le variabili
di rete. In questo caso, però, tale decomposizione deve essere unica e non condivisibile
con altre reti.
Ora analizziamo in che modo l’ editor consente di definire ed utilizzare i dati all’
interno di una specifica di workflow (prospettiva dei dati) e di selezionare la risorsa che
deve eseguire un task (prospettiva delle risorse).
3.4.1 Prospettiva dei dati e delle risorse
Mentre la maggior parte dei workflow management system usano un linguaggio
proprietario per gestire i dati, Yawl si appoggia completamente sugli standard basati su
XML. E’ possibile definire tipi di dati utilizzando XML Schema e ne vengono forniti
per default un certo numero di base: boolean, string, double, long, date (con il formato
yyyy-mm-dd) e time (con il formato hh:mm:ss). Tramite questi, possono essere definiti
tipi più complessi.
Yawl usa variabili di rete per memorizzare dati che devono essere letti e/o scritti
dai componenti della rete, e variabili di task, che contengono dati utilizzabili all’ interno
di ogni singola istanza di task. Le prime servono per trasferire dati attraverso i vari task
60
della rete e/o con altre reti; le seconde, invece, sono usate per lo scambio di
informazioni fra gli utenti del workflow ed il motore e fra i servizi che il motore invoca
a tempo di esecuzione e la rete. Le variabili dichiarate in un task composito
costituiscono le variabili di rete per la corrispondente sottorete.
Nella definizione di una variabile, oltre il nome e il tipo, è necessario indicare l’
uso, che può essere input only (i dati possono solo essere scritti nella variabile), output
only (i dati contenuti nella variabile possono solo essere letti) e input and output (i dati
possono essere scritti e letti). Per le variabili di rete è possibile scegliere anche local (i
dati possono essere manipolati solo internamente alla rete) e, solo in questo caso, può
essere assegnato un valore iniziale.
Figura 3.5 – task decomposition
Yawl supporta il passaggio di dati fra i task di un processo (trasferimento
interno) e fra quest’ ultimo e l’ ambiente operativo, costituito da utenti, servizi web, ecc.
(trasferimento esterno). Il trasferimento interno di dati avviene fra la rete ed i suoi task
utilizzando XQuery. Ad un task viene assegnato un parametro di input, che utilizza una
XQuery per estrarre l’ informazione dalla variabile di rete e passarla alla corrispondente
variabile di task. Allo stesso modo gli viene assegnato un parametro di output per
61
consentire il passaggio inverso. Yawl non permette il passaggio diretto di dati fra i vari
task, perché la variabili di task sono locali al task al quale appartengono e, quindi, non
accessibili agli altri task. Non consente neppure il passaggio diretto di dati fra le
variabili di rete locali e le sue sottoreti.
Figura 3.6 – definizione delle XQuery per il passaggio dei dati da e verso le variabili di
rete
Quando sono richiesti dei dati dall’ ambiente esterno, questi vengono forniti run
time tramite una form che l’ utente deve compilare oppure invocando un servizio web.
Il trasferimento esterno di dati non può essere applicato alle variabili definite locali.
Ogni variabile di input, ad eccezione di quelle della rete di alto livello, riceve i
dati dalla corrispondente variabile di rete utilizzando un parametro di input mentre ad
ogni variabile di input della rete di alto livello o viene assegnato un valore iniziale
design time o riceve i dati dall’ ambiente (ad esempio, richiedendoli all’ utente tramite
una form) quando inizia l’ esecuzione della rete. Ogni variabile di output, eccetto quelle
associate ai task compositi, richiede i dati dall’ ambiente una volta che la corrispondente
62
rete o task vengono eseguiti mentre ogni variabile di output associata ad un task
composito riceve i dati dalla sua sottorete attraverso un parametro di output. Infine le
variabili di input ed output combinano i due comportamenti precedenti.
Yawl supporta il routing condizionale basato sui dati del processo. Quando un
task possiede uno split XOR od OR, una espressione booleana XPath viene associata a
ciascun ramo (o flusso) ed, in funzione del valore (true o false) da essa assunto al tempo
di esecuzione, il ramo corrispondente verrà o meno eseguito dal motore Yawl. Tali
espressioni vengono valutate nello stesso ordine con cui sono state specificate nella lista
ed il flusso relativo all’ ultimo elemento è quello di default, che viene direttamente
eseguito (senza valutazione) quando tutti gli altri sono risultati false.
Figura 3.7 – definizione delle espressioni XPath in caso di OR/XOR-split
Poiché nel caso di uno split XOR è permessa una scelta unica, appena il motore
raggiunge il primo predicato valutato true, sceglie il ramo corrispondente senza
proseguire nella valutazione della restante lista. Diversamente accade per lo split OR,
dove ogni predicato deve essere valutato. Solamente le variabili di rete possono essere
63
utilizzate all’ interno dei predicati perché la valutazione di questi avviene dopo il
completamento del task e le variabili di task non sono più accessibili.
L’ editor Yawl facilita la definizione delle XQuery e delle espressioni XPath in
due modi: fornendo pulsanti che generano automaticamente XQuery ed espressioni
XPath compatibili ed evidenziando l’ uso di una sintassi valida o non valida da parte
dell’ utente tramite l’ uso dei colori, rispettivamente, verde o rosso. Per quanto riguarda
le XQuery gli errori semantici sono segnalati run time dal motore Yawl e l’ esecuzione
viene bloccata. Invece espressioni booleane XPath semanticamente non valide vengono
valutate false ed il processo continua la sua esecuzione.
Per quanto riguarda la prospettiva delle risorse, l’ editor consente di selezionare
per ogni task il ruolo o la persona che deve eseguirlo.
Figura 3.8 – definizione del ruolo e/o della persona a cui è consentito l’ esecuzione di
un task
64
3.5 Yawl engine
Il motore è in esecuzione presso una macchina server a cui si può accedere
utilizzando un browser. Differenti pagine rappresentano diverse funzionalità:

Yawl home consente il log in al sistema in veste di amministratore o di
utente (figura 9);

Administrate è riservata agli amministratori, permette il caricamento
(upload) o l’ eliminazione (unload) delle specifiche e di accedere alla pagina
per la gestione delle risorse e ad altre funzioni amministrative;

Workflow Specifications presenta informazioni sulle specifiche caricate e le
rispettive istanze in esecuzione, consente anche il lancio di nuove istanze o
la terminazione manuale di quelle già esistenti;

Available Work mostra la lista dei work item disponibili per essere eseguiti
dall’ utente (identificato, in base all’ autenticazione, come risorsa idonea
allo svolgimento di quei compiti);

Checked Out Work presenta la lista delle attività che sono in esecuzione
presso un utente o un altro servizio;

Logout permette di uscire dal sistema.
Pertanto il caricamento e l’ eliminazione delle specifiche che devono essere
eseguite viene fatto manualmente dalla pagina Administrate ed è riservato
esclusivamente a chi possiede il ruolo di amministratore (come anche la gestione delle
risorse e dei ruoli e l’ accesso alle funzioni di monitoraggio). Invece, a chiunque è
consentito lanciare nuove istanze o cancellare quelle già in esecuzione dalla pagina
Workflow Specifications.
Ovviamente
è
possibile
caricare
nel
motore
diverse
specifiche
contemporaneamente in modo da consentire l’ esecuzione delle loro istanze in parallelo
senza che interferiscano in alcun modo fra loro.
Ogni utente che accede al sistema, previa autenticazione, trova i work item, che
può eseguire, elencati nella pagina Available Work e selezionandone uno, questo
scompare dalla lista dei work item in attesa di essere eseguiti e compare nella lista di
quelli in esecuzione nella pagina Checked out Work.
65
Figura 3.9 – pagina di log in al sistema Yawl
Yawl fornisce funzioni di base per la gestione delle risorse in ruoli e l’
assegnamento dei work item alle risorse. Infatti è possibile accedere a pagine che
permettono di aggiungere, modificare ed eliminare risorse (umane o non umane), così
pure di creare nuovi ruoli o cancellare quelli esistenti e di assegnare uno o più ruoli ad
una risorsa.
Yawl fornisce anche semplici strumenti per effettuare analisi statistiche e
monitorare l’ esecuzione delle varie istanze. Attraverso una interfaccia grafica è
possibile costruire query che consentano di estrarre i dati dal database per produrre
report utili all’ amministrazione.
66
3.6 Servizi Yawl
Yawl consente l’ interconnessione con servizi esterni, ai quali si può delegare l’
esecuzione di determinati compiti. La struttura orientata al servizio, con cui è stato
realizzato il sistema, permette di estendere i servizi connessi con il motore. Inoltre la
loro indipendenza da quest’ ultimo favorisce la portabilità anche in ambienti diversi da
Yawl.
Il servizio richiesto da un task viene specificato build time nella cosiddetta task
decomposition. Questa richiede anche ulteriori informazioni in base al tipo di servizio
che deve essere invocato. Ad esempio, nel caso il task richieda il servizio worklist,
devono essere esplicitati quali ruoli possono vedere le istanze di tale task e quali
possono prelevarle dalla worklist. Per default l’ autorizzazione è estesa a tutte le risorse.
Quando una nuova istanza di workflow viene caricata nel motore, questo registra
la decomposition di ogni task atomico nel servizio in essa indicato. Se tali registrazioni
si concludono con un successo, il motore può creare le istanze di tali task; altrimenti
viene restituito un errore, il caricamento è abortito ed ogni registrazione già avvenuta
viene cancellata.
Come si è già detto, Yawl consente l’ interazione con le risorse tramite la
worklist, la connessione con altri motori di workflow e l’ invocazione di servizi esterni.
Questi ultimi possono comunicare con il motore in due differenti modi: direttamente
tramite messaggi XML/HTTP (Custom Yawl Services) o indirettamente attraverso il
Yawl Web Services Invoker.
I Custom Yawl Services interagiscono con il motore tramite messaggi
XML/HTTP attraverso certi endpoint, di cui alcuni localizzati dalla parte del motore
Yawl ed altri dalla parte del servizio. Possono essere sviluppati in qualsiasi linguaggio
di programmazione ed eseguiti su qualunque piattaforma capace di mandare e ricevere
messaggi HTTP. Vengono registrati nel motore specificando la loro locazione URL.
Quando il servizio riceve il messagio che un work item è pronto per essere
eseguito (è abilitato), lo preleva dal motore ed il work item passa allo stato in
esecuzione (check out). Quando il processamento del work item si è concluso, il
67
servizio lo restituisce al motore ed il work item passa allo stato completato (check
back).
Yawl fornisce due Custom Yawl Services precostruiti: il Worklet Service, che
introduce flessibilità nella gestione dei workflow ed il Time Service, che è capace di
effettuare il check-in ed il check-out dei work item con un certo ritardo di tempo. E’
possibile estendere le funzionalità del sistema aggiungendo ulteriori servizi e per
registrarli basta compilare una form presente nella pagina Administrate dell’ interfaccia
HTLM del motore Yawl.
Nel secondo caso, invece, il motore Yawl non interagisce direttamente con il
servizio, bensì comunica con il Yawl WSInvoker che a sua volta invoca una operazione
del servizio esterno. Il WSInvoker viene utilizzato quando una applicazione esterna
deve essere invocata per eseguire una istanza di task in maniera sincrona e l’ interfaccia
del servizio è stata descritta in WSDL. I servizi che sono connessi al motore in questo
modo non hanno bisogno di essere registrati.
3.6.1 Worklet Service
I Workflow management system gestiscono e controllano l’ esecuzione di
processi che sono stati modellati nel build time tramite una ben determinata
rappresentazione, dalla quale vengono derivate le istanze. Generalmente, essi non
supportano una evoluzione dinamica del processo, ovvero non permettono di apportare
modifiche run time alla sua definizione per gestire cambiamenti inaspettati o insiti nella
sua normale natura. Ciò li rende adatti per processi caratterizzati da alta predicibilità e
ripetitività, che costituiscono, però, solo una parte di quelli che si trovano nella realtà.
Gestire una deviazione da quanto stabilito nella definizione di processo significa
sospendere l’ esecuzione ed intervenire manualmente oppure addirittura l’ aborto dell’
intero processo. Quindi, per quei processi nei quali i mutamenti costituiscono un aspetto
significativo della loro natura, è necessario adottare un approccio più flessibile.
Utilizzare delle worklet può essere una soluzione a tale problema. Queste
formano un repertorio estensibile di sottoprocessi e rappresentano un certo numero di
68
azioni differenti che possono essere intraprese in base al contesto che si verifica durante
l’ esecuzione di un processo. Esiste, però, una differenza sostanziale fra un
sottoprocesso modellato con una sottorete, come lo abbiamo inteso fino ad ora ed una
worklet; infatti, mentre una sottorete viene staticamente assegnata alla rete genitore nel
design time, una worklet viene selezionata dal repertorio nel run time ed assegnata
dinamicamente alla rete genitore per svolgere un determinato task. Ciò consente di
catturare a tempo di design la struttura principale del processo senza dover per forza
includere tutte le possibili varianti, che, invece, vengono gestite dinamicamente durante
l’ esecuzione.
Una worklet non è altro che una normale specifica di workflow (infatti viene
creata utilizzando l’ editor di Yawl) ed in quanto tale può, anche, essere eseguita sul
motore singolarmente, come una qualsiasi altra istanza di workflow.
Per assegnare una worklet ad un task, bisogna collegare quest’ ultimo al worklet
service nella sua task decomposition e quando, durante l’ esecuzione, viene generato il
work item, il sistema sceglie dal repertorio la worklet appropriata in base a determinati
attributi associati all’ istanza in questione ed utilizzando un insieme di regole (RDR).
Quindi viene effettuato il check out del work item, le sue variabili di input vengono
mappate in quelle di rete della worklet selezionata e quest’ ultima viene lanciata nel
motore come istanza separata rispetto all’ istanza genitore. Quando la worklet è stata
completata, le sue variabili di output di rete vengono mappate nelle variabili di output
del work item di origine, viene fatto il check in di quest’ ultimo e l’ esecuzione dell’
istanza genitore continua.
Dal punto di vista del motore, quindi, la worklet e l’ istanza genitore sono due
casi separati e spetta al Worklet Service provvedere ai collegamenti fra i due, al
mapping dei dati, alla sincronizzazione ed alla creazione del log relativo alla worklet.
L’ architettura di un Worklet Service in riferimento con gli altri componenti del
sistema è rappresentata in figura 10.
69
Figura 3.10 – architettura del Worklet Service in Yawl
Il servizio utilizza l’ interfaccia A per caricare le specifiche di worklet sul
motore e l’ interfaccia B per iniziare e cancellare le istanze e per fare il check out del
work item, dopo aver interrogato i dati ad esso associati ed il suo check in, una volta
completata l’ esecuzione.
Un qualsiasi numero di worklet può essere inserito nel repertorio da associare ad
un task atomico semplice o ad un task atomico ad istanze multiple (nel qual caso le
worklet lanciate per le varie istanze possono essere differenti in funzione degli attributi
che queste possiedono) così come la stessa specifica di workflow può possedere più di
un task che usa il Worklet Service. Inoltre una worklet può far parte di uno o più
repertori, ovvero può essere riutilizzata in un certo numero di task all’ interno della
stessa specifica o appartenenti a specifiche diverse. Infine è anche possibile che una
specifica di worklet contenga task che, a loro volta, utilizzano il Worklet Service e che,
quindi, al tempo di esecuzione vengono sostituiti con altre worklet, consentendo l’
annidamento.
La scelta della worklet da eseguire run time avviene tramite l’ uso di un insieme
di regole disposte a formare un albero binario. Ognuna di queste regole è del tipo “if
condizione then conclusione”, dove la conclusione indica la worklet da selezionare. Da
ogni nodo dell’ albero possono partire zero, uno o due rami che conducono ad altrettanti
70
nodi. L’ albero è percorso dalla radice attraverso i suoi rami valutando di volta in volta
la condizione di ogni nodo incontrato: se questa è true ed il nodo possiede un figlio true,
anche la condizione del nodo figlio viene valutata; se invece è false ed esiste un figlio
false, è valutata la condizione di tale figlio. Quando si giunge ad un nodo terminale, se
la condizione è soddisfatta, si segue la sua conclusione altrimenti si risale l’ albero fino
all’ ultima regola incontrata la cui condizione era soddisfatta. Il nodo radice
(corrispondente alla regola 0) contiene una condizione true ed una conclusione null di
default.
In realtà ogni figlio true rappresenta una regola eccezione rispetto a quella
generale del nodo genitore (si dice anche che è un raffinamento), mentre ogni figlio
false costituisce una regola alternativa.
L’ RDR (Ripple Down Rules) Editor fornisce una interfaccia GUI, che consente
di facilitare la creazione di tali regole. Ogni specifica che richiede l’ uso del Worklet
Service per uno o più dei suoi task deve avere il suo insieme di alberi di regole (un
albero per ogni task) il quale viene memorizzato nella forma di documento XML su un
file che porta lo stesso nome della specifica ma con estensione “.xrs” (XML Rule Set).
In qualunque momento (anche mentre il processo è in esecuzione), possono
essere aggiunte nuove worklet al repertorio associato ad un task e queste diventano
automaticamente disponibili per istanze correnti e future, purchè all’ albero relativo a
quel task vengano aggiunte le corrispondenti regole.
Infatti se, durante l’ esecuzione di una particolare istanza, ci si rende conto che
la worklet selezionata dal sistema è inappropriata al caso in questione, si può intervenire
dinamicamente e modificare la scelta introducendo un nuovo nodo all’ albero delle
regole, in modo da poter gestire una situazione che non era stata considerata
precedentemente. L’ aggiunta di tale nodo avviene secondo il seguente algoritmo: se la
worklet selezionata è il risultato di una regola terminale soddisfatta, allora la nuova
regola è aggiunta come un nodo eccezione; se, invece, essa è il risultato di una regola
non terminale (ovvero la condizione della regola terminale non era soddisfatta), allora il
nuovo nodo viene inserito come una alternativa al nodo terminale non soddisfatto.
Una volta che è stata aggiunta la nuova regola, l’ editor comunica al worklet
service tramite una interfaccia JSP/Servlet la sostituzione della worklet selezionata dal
71
sistema con quella aggiunta dinamicamente e che risulterà disponibile anche per le
istanze future.
L’ editor RDR fornisce strumenti differenti per la creazione di nuovi insiemi di
regole e l’ aggiunta di nuove regole ad un insieme già esistente. In quest’ ultimo caso dà
la possibilità di accedere direttamente all’ editor di Yawl per realizzare una nuova
worklet.
72
73
Capitolo 4
LINEE GUIDA IMPLEMENTATE IN YAWL
4.1 Introduzione
Il processo di cura di un paziente può essere paragonato ad un processo di
business. Entrambi sono caratterizzati da un insieme di azioni da svolgere rispettando
certi vincoli temporali e logici e da un insieme di decisioni da prendere per raggiungere
determinati obiettivi. Da questo punto di vista, quindi, una linea guida può essere
modellata come un workflow.
In questo capitolo si mostra come si possono modellare le linee guida
utilizzando Yawl. Sono state scelte due linee guida di esempio: una linea guida per la
diagnosi ed il trattamento del diabete mellito tipo 2 e di IGT/IFG ed una linea guida per
il trattamento dell’ obesità. Sono state rappresentate nell’ editor e, successivamente, si è
verificata la correttezza delle due rappresentazioni eseguendole sul motore.
Si utilizzano i task per modellare le azioni che devono essere compiute all’
interno di una linea guida. L’ AND-split consente l’ esecuzione parallela o in qualsiasi
ordine di due o più azioni mentre lo XOR-split e le espressioni booleane XPath,
associate a ciascun ramo in uscita, permettono di rappresentare la scelta automatica fra
un insieme di alternative sulla base del verificarsi o meno di certe condizioni.
Inoltre le condizioni possono modellare le decisioni che devono essere prese
dall’ utente. Si è evidenziato, infatti, l’ esistenza di due tipi di scelte che un sistema per
la gestione delle linee guida deve essere capace di implementare: quelle fatte
automaticamente dal sistema sulla base di rigidi criteri e quelle che, invece, richiedono
l’ interazione dell’ utente. Questo perché è importante consentire al medico di decidere,
ad esempio, quale terapia farmacologica o test diagnostico adottare fra diversi
74
ugualmente possibili, così come è importante lasciare libertà decisionale laddove la
linea guida prevede una valutazione soggettiva della situazione. La prima tipologia di
scelta è modellata nell’ esempio della linea guida per la diagnosi del diabete mentre la
seconda è presente nell’ esempio della linea guida per il trattamento dell’ obesità.
In Yawl è possibile anche modellare il ciclo, nel caso in cui una o più azioni
devono essere ripetute e consente di rappresentare linee guida complesse su più livelli
utilizzando sottoreti.
Una caratteristica molto importante per una linea guida è la possibilità di
specificare un vincolo temporale, ovvero di fissare un tempo di inizio, di fine e/o la
durata di una azione od un insieme di azioni. Ad esempio, per il follow up di un
paziente diabetico è richiesto di effettuare una serie di esami ed accertamenti di
controllo dopo un certo intervallo di tempo e, quindi, di specificare un vincolo
temporale per l’ inizio di tali controlli. Come si può vedere nell’ esempio trattato in
questo capitolo, ciò può essere fatto in Yawl utilizzando il Time Service.
4.2 Esempio di linea guida: diabete
Come esempio è stata rappresentata in Yawl sfruttando la metodologia del
workflow una linea guida per la diagnosi di “paziente diabetico tipo 2” o di paziente con
ridotta tolleranza agli zuccheri (IGT) o alterata glicemia a digiuno (IFG), che viene
sinteticamente chiamato “paziente con IGT/IFG”.
La linea guida è costituita da un insieme di esami ed accertamenti con lo scopo
di indagare su un presunto sospetto di diabete. Pertanto il criterio di eleggibilità per
questa linea guida può essere individuato in uno stato sintomatologico del paziente che
costituisce un campanello d’ allarme per la malattia.
Il primo passo da compiere è quello di effettuare un controllo del valore
glicemico a digiuno (figura 1). In base al risultato ottenuto si verifica una fra queste tre
situazioni:
75

se il valore è inferiore ad una certa soglia (110 mg/dl) si esce dalla linea
guida;

se il valore è compreso nell’ intervallo fra 110 e 126 mg/dl, è necessario
effettuare un ulteriore esame chiamato glicemia due ore dopo OGTT prima
di poter fare una eventuale diagnosi;

se il valore è superiore a 126 mg/dl la diagnosi è quella di diabete mellito
tipo 2.
Nel caso si verifichi la situazione numero 2 (glicemia a digiuno compresa fra
110 e 126 mg/dl), il paziente deve essere sottoposto al test glicemia due ore dopo
OGTT, il cui risultato porta ad

uscire dalla linea guida (paziente sano), se il valore è minore di 140 mg/dl;

una diagnosi di paziente con IFG/IGT, se il valore è compreso fra 140 e 200
mg/dl;

una diagnosi di diabete mellito tipo 2, se il valore è supera i 200 mg/dl.
La linea guida è stata implementata in Yawl nel modo seguente:
1.
i vari esami a cui deve sottoporsi il paziente e le possibili diagnosi a cui si
perviene vengono modellati con dei task;
2.
vengono rappresentati i dati necessari per determinare il flusso delle attività
da eseguire run time;
3.
nel motore Yawl viene verificata la correttezza della rappresentazione
ottenuta con l’ editor.
76
Figura 4.1 - linea guida per la diagnosi di diabete mellito tipo 2 o di IGT/IFG
Si può vedere, in figura 1, come sono stati disposti i vari task e collegati
opportunamente fra loro in modo da implementare la linea guida sopra descritta. Sono
presenti due XOR-split nei task controllo_glicemia e test_OGTT che consentono la
scelta di una sola fra tre alternative.
Il task con etichetta fine è stato aggiunto
semplicemente perché Yawl non permette l’ ingresso di archi multipli nel posto di
output e non ha alcuna funzionalità ai fini dell’ esecuzione del workflow. Per questo ad
esso non viene assegnata alcuna decomposizione in modo da non generare alcuna
attività quando viene eseguito sul motore.
Nella decomposizione di rete sono state definite due variabili, entrambe locali:
glicemia_a_digiuno e glicemia_a_2ore. Queste sono utilizzate all’ interno della linea
guida con lo scopo di indagare sullo stato del paziente ed arrivare ad una diagnosi.
Nella decomposizione del task controllo_glicemia è stata specificata
glicemia_a_digiuno come variabile di output. Ciò vuol dire che, quando il work item
del task passa dallo stato abilitato allo stato in esecuzione, viene presentata all’ utente
una form nella quale deve essere inserito il valore da assegnare a tale variabile. Tale
valore viene utilizzato prima che il work item passi allo stato completato per selezionare
il task successivo da eseguire fra tre possibilità. Sono state esplicitate una XQuery per
77
consentire il passaggio del valore inserito tramite la form dalla variabile di task alla
variabile di rete e tre espressioni XPath per determinare il flusso all’ uscita del task in
funzione del valore assunto dalla variabile glicemia_a_digiuno. Allo stesso modo è
stato fatto per il task test_OGTT.
Lo scopo di questo workflow è quello di presentare al medico di medicina
generale una sequenza di azioni da svolgere (esame della glicemia a digiuno, valore
della glicemia due ore dopo il test OGTT) prima di arrivare ad una diagnosi.
Nel caso si arrivi ad una diagnosi (sia essa di diabete o di IGT/IFG), il paziente
deve essere sottoposto ad una serie di controlli e visite (follow-up) ad intervalli di
tempo regolari, onde evitare il peggioramento del suo stato di salute e prevenire la
comparsa
delle
complicanze
direttamente
legate
a
tale
malattia
(malattie
cardiovascolari, cecità, insufficienza renale, amputazione arti inferiori). Quindi i due
task diagnosi_diabete e diagnosi_IFG-IGT sono compositi, ovvero richiamano due
sottoreti che implementano due ulteriori linee guida: rispettivamente, la linea guida per
il follow-up del paziente diabetico e quella per il follow-up del paziente con IGT/IFG.
Ognuna di esse elenca gli esami e/o visite che il paziente malato deve effettuare
ad intervalli di tempo regolari nell’ arco di uno o due anni ed è stata implementata in
Yawl in modo da fornire un avviso al medico allo scadere di ogni intervallo di tempo
dopo il quale il paziente deve essere sottoposto ad un elenco di controlli. E’ stato
possibile realizzare ciò utilizzando il Time Service, che permette il check in (passaggio
dallo stato in esecuzione a quello completato) di un work item una volta trascorso un
certo tempo.
In figura 2 è raffigurato il workflow che rappresenta la linea guida che il medico
deve seguire per sottoporre il paziente a cui è stato diagnosticato il diabete mellito tipo 2
ad un follow up annuale.
78
Figura 4.2 - linea guida per il follow-up del paziente con diabete mellito tipo 2
Il task inizio contiene un insieme di variabili di output che rappresentano una
lista di controlli che il medico deve effettuare sul paziente immediatamente dopo la
diagnosi: ad esempio, una visita generale, il controllo del peso e della pressione ed una
prescrizione dietetica. Al tempo di esecuzione, all’ utente compare una form che deve
essere compilata con i dati raccolti dalla visita.
Figura 4.3
Successivamente, il task aspetta utilizza il Time Service ed imposta la variabile
time ad un valore pari a 3 mesi, cosicché il task controllo1 viene abilitato solo allo
79
scadere di tale termine. Questo task presenta un’ altra form al medico con la lista dei
controlli che il paziente deve fare una volta che sono trascorsi 3 mesi dalla diagnosi.
Impostando le variabili come input e output vengono ricordati i valori ottenuti dalle
visite precedenti e si possono sovrascrivere i nuovi valori, una volta effettuati gli esami.
Figura 4.4
Si esegue di nuovo il task aspetta, che riutilizza la task decomposition
precedente e fa trascorrere altri 3 mesi prima di prima di ricordare al medico che il
paziente deve essere sottoposto ad altri esami. Il task controllo2 presenta all’ utente la
lista dei controlli che il paziente deve effettuare dopo 6 mesi dalla diagnosi.
Si continua alla stessa maniera: a 9 mesi dalla diagnosi si ripetono gli esami fatti
a 3 mesi ed infine dopo 1 anno gli effettuano gli ultimi controlli prima di uscire dalla
linea guida ed anche dalla specifica di workflow.
La linea guida per il follow up di un paziente con IGT-IFG è implementata
esattamente allo stesso modo.
80
4.3 Esempio di linea guida: obesità
Come ulteriore esempio è stata rappresentata in Yawl una linea guida per il
trattamento dell’ obesità. Essa inizia con una raccolta di dati (peso ed altezza) da parte
dell’ utente per poter inserire il paziente in una di queste cinque categorie: paziente con
peso normale, in sovrappeso, con obesità di tipo I, con obesità di tipo II e con obesità di
tipo III. La classificazione viene fatta in base all’ intervallo nel quale è compreso il
valore di BMI, calcolato in funzione del peso e dell’ altezza della persona. Una volta
valutata la categoria di appartenenza del paziente, la linea guida presenta il
corrispondente trattamento consigliato (eccezion fatta per il paziente con peso normale,
per il quale la linea guida termina immediatamente).
La particolarità che presenta il workflow, utilizzato in figura 5 per rappresentare
questa linea guida, è che in diversi punti offre la possibilità all’ utente di effettuare una
scelta. Infatti può decidere, nei casi più gravi, se iniziare un trattamento farmacologico,
nel qual caso può optare per la somministrazione di una classe di farmaci anziché di un’
altra, o se ricorrere, addirittura, all’ intervento chirurgico.
Lasciare al clinico l’ ultima parola su quale terapia farmacologica adottare fra
diverse ugualmente possibili è una caratteristica importante di una linea guida. Così
come è importante consentirgli di prendere decisioni laddove la linea guida prevede una
valutazione soggettiva della situazione.
Pertanto si può distinguere fra due tipi di scelte che un sistema per la gestione
delle linee guida deve essere capace di implementare: quelle fatte automaticamente dal
sistema sulla base di rigidi criteri e quelle che, invece, richiedono l’ interazione dell’
utente.
In Yawl, il primo tipo è realizzato utilizzando un task con XOR-split ed
esprimendo i criteri di scelta tramite espressioni XPath (come si è potuto vedere anche
nell’ esempio precedente), mentre il secondo si può realizzare usando una condizione
(rappresentata dal cerchio).
Ora si analizza il workflow di figura 5 descrivendo la funzione di ogni task ed
analizzando i dati utilizzati. Le variabili di rete sono: peso, altezza, bmi, normale,
81
sovrappeso, obesità_tipo1, obesità_tipo2, obesità_tipo3, classificazione, consiglio,
posologia_orlistat, posologia_sibutramine ed errore e sono tutte dichiarate locali.
Anche in questo esempio, si è verificata la correttezza della rappresentazione
eseguendo il workflow nel motore Yawl.
Figura 4.5 – linea guida per il trattamento dell’ obesità
Il task misura richiede all’ utente di immettere il peso e l’ altezza del paziente.
Pertanto utilizza le variabili di output peso ed altezza (entrambe di tipo double); in
questo modo, al tempo di esecuzione, il motore presenta una form che deve essere
compilata con i dati richiesti (figura 6). Due semplici XQuery consentono ai parametri
di output di trasferire i valori immessi dal medico dalle variabili di task alle
corrispondenti variabili di rete. Una ulteriore XQuery è stata definita per assegnare alla
variabile di rete bmi il valore ottenuto dividendo il peso per l’ altezza (in metri) al
quadrato:
{(/misura/peso_in_kg/text())div(/misura/altezza_in_metri/text()*/misura/altezza_in_met
ri/text())}.
82
Figura 4.6
Il task possiede uno XOR-split che consente di valutare se, per errore, l’ altezza
viene espressa in centimetri anziché in metri. Quindi, l’ espressione XPath relativa al
ramo
che
conduce
al
task
messaggio_di_errore
è
la
seguente:
(/trattamento_obesita/altezza_in_metri>2.5)='true'. Quest’ ultimo contiene, appunto, un
messaggio di errore contenuto nella variabile di input errore (tipo string) e che ricorda
all’ utente di inserire l’ altezza in metri (figura 7).
Figura 4.7
Il task visualizza_BMI visualizza il valore calcolato di BMI (figura 8). Quindi
utilizza la variabile di input bmi, il cui valore era stato calcolato precedentemente.
Figura 4.8
In uscita da questo task, le espressioni XPath, associate ai vari rami che partono
dallo XOR-split, consentono di decidere quale alternativa seguire fra quattro possibili,
in funzione del valore di BMI:
83
1. Se BMI è minore di 25 kg/m2, il paziente ha un peso normale per la propria
statura. Pertanto si passa al task peso_normale che segnala semplicemente
all’ utente questo fatto prima di uscire dalla linea guida. Esso utilizza la
variabile di input (tipo string) classificazione, a cui viene assegnata, tramite
una XQuery, la stringa contenuta nella variabile di rete normale (“peso
normale”).
2. Se BMI è compreso fra 25 e 30 kg/m2, si ha un paziente sovrappeso; mentre
se BMI appartiene all’ intervallo 30-35 kg/m2, il paziente rientra nella
categoria obeso di tipo 1. Entrambe queste situazioni sono gestite all’ interno
dell’ unico task sovrappeso-obesitàI, che visualizza la classificazione del
paziente (sovrappeso o obesità di tipo 1, appunto) ed il consiglio di
somministrare una dieta e di intraprendere una qualche attività fisica (figura
9). Pertanto utilizza la variabile di input classificazione, a cui viene
assegnata, tramite XQuery, la stringa contenuta nella variabile di rete
sovrappeso o quella contenuta nella variabile di rete obesità_tipo1 a
seconda del caso. La XQuery è: {if (/trattamento_obesita/bmi/text()<30)
then
(/trattamento_obesita/sovrappeso/text())
else
(/trattamento_obesita/obesita_tipo1/text())}. Infine utilizza la variabile di
input consiglio di tipo string che contiene la stringa “dieta ed attività fisica”.
La situazione del paziente, non eccessivamente grave, non richiede alcun
trattamento aggiuntivo, per cui dopo questo task la linea guida termina.
Figura 4.9
3.
Se BMI è compreso fra 35 e 40 kg/m2, il paziente ha una obesità di tipo 2 e
si passa al task obesitàII. Questo si comporta come il precedente, ad
84
eccezion fatta per la stringa “obesità tipo 2” visualizzata per classificare il
paziente. Invece il trattamento consigliato è lo stesso: dieta ed attività fisica.
4.
Se BMI supera 40 kg/m2, il paziente ha una obesità di tipo 3. Il task
obesitàIII, di nuovo visualizza la stringa “obesità tipo 3” per classificare il
paziente e consiglia dieta ed attività fisica.
Nei casi 3 e 4 il workflow continua presentando al medico la possibilità di
decidere se uscire dalla linea guida (task fine), se iniziare un trattamento farmacologico
(task trattamento_farmacologico?) o, solo nell’ ultimo caso, se effettuare un intervento
(task intervento?). Ovviamente la scelta di una di queste soluzioni annulla le altre.
Infine se si dovesse optare per la terapia farmacologica, si può decidere di
prescrivere orlistat, scegliendo di eseguire il task orlistat o sibutramine, scegliendo,
invece, il task sibutramine. Ognuno di questi task utilizza una variabile di output
posologia_orlistat e posologia_sibutramine, rispettivamente, che è di tipo posologia,
ovvero di un tipo generato dall’ utente utilizzando XSchema (figura 10).
Figura 4.10 – definizione di un tipo di dati complesso tramite XSchema
Quando viene eseguito uno dei due task, compare una form che il medico deve
compilare indicando la quantità e la frequenza con cui il farmaco deve essere assunto e
la durata del trattamento (figura 11).
85
Figura 4.11
86
87
Conclusioni
Una linea guida contiene un insieme di raccomandazioni che devono essere
seguite nella gestione di una classe di pazienti in modo da promuovere la migliore
pratica clinica. Per questo, tali raccomandazioni devono essere basate sulle migliori
evidenze disponibili, derivanti dalle ultime ricerche scientifiche.
Esistono numerose linee guida, che riguardano i diversi campi di azione del
servizio sanitario: la diagnosi, la prevenzione, il trattamento di una malattia, ecc. A
volte una linea guida è molto semplice e coinvolge un singolo individuo: ad esempio,
quella per il vaccino contro l’ influenza è rivolta al medico di medicina generale che
deve decidere se un determinato paziente a rischio deve essere vaccinato. Altre volte,
invece, una linea guida è molto più complessa, può essere costituita da un insieme di
passi da eseguire nel tempo e coinvolgere più persone (cura primaria, cura secondaria,
nurses, assistenti domiciliari, farmacisti, analisti e tecnici di laboratorio, ecc.) che
devono collaborare nella gestione del paziente.
Non basta produrre linee guida di qualità, è necessario anche diffonderle e far in
modo che il comportamento clinico venga modificato secondo quanto in esse contenuto.
Le tecnologie dell’ informazione e della comunicazione contribuiscono alla loro
disseminazione: archivi elettronici accessibili tramite Internet forniscono le versioni
sempre aggiornate e programmi di simulazione ne facilitano l’ apprendimento. Si è
visto, però, che ciò non è sufficiente, in quanto si riscontrano delle difficoltà reali nel
memorizzare le raccomandazioni in esse contenute e nell’ applicarle quando si presenta
il caso specifico di un paziente.
In questo senso un contributo notevole deriva dall’ uso di sistemi software come
supporto nelle decisioni cliniche durante la cura di un determinato paziente, sulla base
delle raccomandazioni contenute nelle linee guida. Sistemi di questo tipo ricevono come
input i dati relativi al paziente trattato e forniscono all’ utente informazioni su ciò che la
linea guida, di volta in volta, raccomanda di fare.
88
Sono stati condotti diversi studi che hanno affrontato le questioni di creare un
linguaggio adatto a modellare le linee guida e di sviluppare un sistema capace di
interpretarlo e di fornire un supporto decisionale nel trattamento di un determinato
paziente. Tale sistema deve reperire i dati utili al fine di caratterizzare lo stato clinico
del paziente e determinare, in base ad esso, le successive azioni e/o decisioni previste
dalla linea guida. Questi dati possono essere richiesti all’ utente tramite una form o
possono essere prelevati da un database locale che contiene il fascicolo personale del
paziente o da sistemi software remoti che forniscono i risultati di esami di laboratorio,
ecc. Pertanto è necessaria una integrazione fra questi sistemi ed uno scambio di dati.
Spesso la cura di un paziente è un processo distribuito. Il trattamento del diabete
mellito, ad esempio, richiede la collaborazione fra differenti figure professionali e
strutture sanitarie: medici di medicina generale, centri specialistici, ospedali, dietologi,
ecc. Quindi, è di fondamentale importanza la cooperazione e lo scambio di informazioni
fra i vari attori coinvolti.
Da questo punto di vista la tecnologia del workflow può essere di grande aiuto
grazie alla sua capacità di coordinare la distribuzione dei compiti e delle informazioni
necessarie alla loro esecuzione fra i vari partecipanti al processo. Rappresentando una
linea guida come un workflow, la cui esecuzione viene gestita da un’ apposito software
(il Workflow Management System), si ha il vantaggio di poter coordinare tutte le figure
coinvolte nella cura del paziente e, contemporaneamente, di fornire un supporto
automatizzato al workflow clinico.
Il Workflow Management System è “capace di interpretare gli schemi, interagire
con i partecipanti del workflow ed invocare l’uso di strumenti ed applicazioni
automatizzate”. Quando, nell’ esempio riportato nel capitolo 4, il medico decide di
trattare il paziente obeso con una determinata terapia farmacologica, il WfMS può
consentire al medico di compilare la ricetta corrispondente invocando una applicazione
ad hoc.
Realizzando un sistema distribuito, diverse strutture sanitarie possono cooperare
per realizzare un processo di cura integrato. Infatti quando nel follow up periodico di un
paziente diabetico è prevista una visita specialistica (elettrocardiogramma o visita
presso un centro di diabetologia), il WfMS comunica alla struttura interessata la
89
necessità di eseguire tale visita su quel paziente, ad esempio, inserendo il relativo work
item nella sua work list.
Un punto di debolezza del sistema workflow è la mancanza di flessibilità.
Durante il trattamento di un paziente, possono verificarsi situazioni inaspettate o di
emergenza che richiedono una deviazione da quanto stabilito dalla linea guida (ad
esempio, l’ aggiunta o la soppressione di un task). L’ impossibilità di gestire tali
situazioni determina l’ inutilità del sistema, quando si verificano casi di questo tipo.
90
91
Bibliografia
Manuale metodologico. Come produrre, diffondere e aggiornare raccomandazioni per
la pratica clinica. Disponibile al sito http://www.pnlg.it
Mor Peleg, Samson Tu, ed altri. Comparing Computer-Interpretable Guideline Models:
A Case-Study Approach. 2003.
Tu SW, Musen MA. Modeling Data and Knowledge in the EON Guideline
Architecture. 2000.
Dimitrios Georgakopoulos, Mark Hornick, e Amit Sheth. An overview of workfow
management: From process modelling to workfow automation infrastructure. 1995.
W.M.P. van der Aalst e K.M. van Hee. Workflow Management: Models, methods and
systems. 2000
Workflow Management Coalition. The Workflow Reference Model. 1995. Disponibile al
sito www.wfmc.org
Workflow Management Coalition. Terminology & Glossary. 1999. Disponibile al sito
www.wfmc.org
W.M.P. van der Aalst, A.H.M. ter Hofstede, B. Kiepuszewski, e A.P. Barros. Workflow
patterns. 2003.
W.M.P. van der Aalst e A.H.M. ter Hofstede. YAWL: Yet Another Workflow Language.
2005. Disponibile al sito www.yawl-system.com
W.M.P. van der Aalst, L. Aldred, M. Dumas, e A.H.M. ter Hofstede. Design and
implementation of the YAWL system. 2003. Disponibile al sito www.yawl-system.com
Michael Adams, Arthur H. M. ter Hofstede, David Edmond e Wil M. P. van der Aalst.
Worklets: A Service-Oriented Implementation of Dynamic Flexibility in Workflows.
2006. Disponibile al sito www.yawl-system.com
92