Conclusioni sull'indagine comparativa

Nei capitoli 6 e 7 verranno poi analizzati in modo specifico i dettagli implementativi per entrambe le versioni dell'XDW Workflow Document. Tuttavia è già possibile definire le due principali differenze che contraddistinguono le soluzioni proposte. La prima riguarda la struttura scelta per descrivere un evento del processo. La seconda e più evidente differenza risiede nei diversi linguaggi standard utilizzati per la strutturazione del documento, la quale comporta un gran numero

di conseguenze pratiche legate alla particolare architettura dei sistemi definiti tramite Human Tasks ed alle potenzialità del linguaggio.

Per quanto riguarda il primo spunto di analisi, infatti, si può osservare come nel caso CDA-based si sia deciso di strutturare il body del documento con una serie di steps identici, associando ogni azione svolta all'interno del Workflow ad uno step ben definito. In questo modo i cambiamenti di stato dei documenti o degli step stessi vengono tracciati come step indipendenti. Questo tipo di approccio fornisce linearità al linguaggio adottato e elevata semplicità nella strutturazione del documento, ma soffre dei limiti legati alla descrizione specifica di ogni step. Non è sempre possibile infatti definire degli step specifici per ogni cambiamento di stato.

Attraverso l'approccio offerto dallo standard Human Task è stato invece possibile strutturare il documento in task. Ad ogni task sono associati uno o più Task Event che permettono di tracciare in una lista i cambiamenti di stato legati alla task stessa. Non si tratta di vere e proprie sotto-task, che tuttavia il linguaggio Human Task renderebbe disponibili, ma un modo per monitorare l'evolvere di un processo che non è stato ultimato (descrivendo le varie fasi di un processo più complesso). In questo modo dunque, se non è possibile definire una particolare task per un evento che comporta solo il cambiamento di stato di una task precedente, l'approccio offerto permette di modificare lo stato della task aggiungendo un elemento task Event. Non essendo tuttavia definite in modo specifico quali attività debbano essere descritte tramite una task e quali siano riconducibili ad un task Event, questo secondo approccio potrebbe portare alla perdita di consistenza del linguaggio perché documenti strutturati in modo diverso potrebbero descrivere lo stesso processo. Vengono quindi fornite parallelamente al profilo delle indicazioni che suggeriscono, ovunque sia possibile, di utilizzare task e non task Event. Attraverso questo approccio possono essere definite task anche per compiti in programma e non ancora eseguiti, gestendo i vari stati che può assumere la task stessa (creato, preso in gestione, in programma di esecuzione, in-progress, fallito, ultimato ecc...).

Per quanto riguarda invece le differenze imposte dalla scelta del linguaggio standard, usato per la strutturazione del documento, si possono fare diverse considerazioni. Innanzitutto in entrambi gli approcci non si è deciso di utilizzare tutte le funzionalità dei linguaggi utilizzati. In particolare il linguaggio CDA è progettato per strutturare documenti clinici, e permette di definire un template specifico per ogni tipo di informazione clinica descritta. Tuttavia una caratteristica fondamentale del XDW Workflow Document prevede che il documento non debba contenere informazioni cliniche, ma solamente riferimenti esterni ai documenti correlati allo specifico workflow clinico. Di conseguenza viene impedito l'utilizzo di tutti quei metadati che forniscono informazioni cliniche. Per quanto riguarda lo standard Human Task, invece, si è deciso di adottare per semplicità una struttura semplificata per le task, che vengono definite “lean tasks”. Questa scelta permette in

particolare di non fornire all'interno delle task indicazioni per il rendering delle informazioni e impedisce la definizione di sotto-tasks. Entrambe le scelte permettono di migliorare l'interoperabilità delle applicazioni che si scambiano i Workflow Document.

Il linguaggio Human Task è concepito all'interno di un architettura di sistema organizzata su più livelli. In particolare è possibile definire una sovrastruttura esterna al documento stesso, sulla quale far riferimento per poter individuare non solo la tipologia di workflow in esecuzione ma anche le particolari regole di sviluppo del workflow stesso, definendo espressamente: gli stati possibili, le possibili evoluzioni del flusso da una qualsiasi configurazione specifica e documenti che possono essere referenziati (figura 5.11). XDW costituisce il nucleo centrale del sistema necessario per garantire l'interoperabilità, e fornisce una piattaforma sulla quale possono essere definiti un gran numero di Workflow specifici, definiti tramite una “content specialization” che richiede risorse minime per la specificazione e l'implementazione.

Figura 5.11: Architettura del sistema XDW

Pt of Care

Work

XDS Registry & Repositories Pt of Care

XDW XDW Actor Actor

Document Sharing (e.g. XDS, ATNA, CT)

Workflow Content Profile A

Workflow Document

Defines workflow Tasks/states,rules & referenced docs

Tracks progress of Task for a workflow with reference to input/ouput

documents

Sharing of workflow and referenced input/output

documents

Application Application

Ref’d

Doc ^Ref’d Doc

Questo approccio non può essere utilizzato nel sistema definito tramite il linguaggio CDA, anche se è possibile definire il business del workflow valorizzando appositi campi codificati all'interno del documento strutturato. In questo modo possono essere definite le regole per la successione degli step, il tipo dei documenti che possono essere referenziati, e i valori che possono assumere determinati campi. Altri workflow invece, possono essere referenziati semplicemente attraverso un identificatore univoco. Questo approccio lascia la gestione dello sviluppo del workflow al personale sanitario. Gli step futuri non sono gestiti direttamente tramite XDW, ma vengono considerati solo ad un livello superiore di XDW, dove, le eventuali regole di svolgimento del workflow vengono considerate come parte integrante ai passi precedenti. Questa scelta comunque non comporta la definizione di regole di conformità per la creazione del documento stesso, le quali possono essere

definite solo attraverso il riferimento ad uno specifico template per la particolare tipologia di Workflow.

Il linguaggio Human Task permette inoltre al documento di essere gestito direttamente da tutte le organizzazioni che utilizzano lo standard BPEL per la definizione dei workflw. In particolare un'organizzazione che utilizza questo standard può direttamente estrarre informazioni e le task complete dal Workflow Document una volta che la task deve essere processata, posizionarle all'interno del Workflow Management System per essere eseguite e aggiornare direttamente il documento una volta che il lavoro è stato completato.