Gestione del Workflow Document

7.4.1 Gestione del Lifecycle del Workflow Document

Il profilo Cross-Enterprise Document Workflow si avvantaggia della gestione del lifecycle di XDS se utilizzato in un contesto XDS.

Un Workflow Document deve essere creato ed inserito all'interno di una cartella. Il documento iniziale deve includere almeno una task all'interno delkla taskList ed avere un WorkflowStatus

OPEN. Il Workflow Document è aggiornato quando:

-Le informazioni associate alla task vengono modificate, come per esempio un aggiornamento dei informazioni in output.

-Quando una nuova task viene aggiunta alla <TaskList> -Quando lo status del Workflow è cambiato in CLOSED

Ogni aggiornamento può essere effettuato utilizzando l'XDS document replace, se ci sitrova nel contesto XDS. La serie di step da seguire sono:

-Aggiornare il Workflow Document con le nuove informazioni richieste. Questo richiede spesso la modifica dell'elemento <taskData>. Ma si può verificare anche un aggiunta di una nuova task all'interno della <taskList> o di un nuovo <taskEvent> di una task.

-Utilizzare l'operazione XDS replace per sostituire il documento modificato alla versione precedente

-Questa operazione può generare un errore dall'XDS Registry se un altro attore ha effettuato un replace prima che l'operazione sia stata completata. Se succede questo, un nuovo contenuto viene realizzato e aggiornato. Questa tipologia di errore è molto rare in quanto la velocità di realizzazione delle tasks è generalmente molto più bassa rispetto all'operazione di replace.

Nel caso in cui si operi in un contesto XDM o XDR l'attore che riceve il documento deve realizzare operazioni di aggiornamento simili.

Quando si arriva nell'istante in cui è necessario interrompere i lavori associati ad uno specifico Workflow, è necessario un ultimo processo di aggiornamento che setta lo status del Workflow a CLOSED.

Le regole specifiche per determinare quando un lavoro è stato completato non sono definite dal profilo XDW. Esse devono essere definite dagli altri profili IHE, dall'amministratore locale del Workflow, o da altre sorgenti. Il profilo XDW, inoltre, non definisce le regole che determinano la gestione del lifecycle del documento, ma gli altri profili coinvolti nelle specifiche istanze di Workflow possono richiedere una certa sequenza di task, che il Workflow inizi con un determinato processo, e che il processo di aggiornamento avvenga in risposta a cambiamenti effettuati su specifiche tasks.

7.4.2 Associazione tra le varie versioni del Workflow Document

Un documento clinico può essere utilizzato come riferimento in più Workflow Document diversi, ed in differenti steps dello stesso Workflow Document. Quando si ha conoscenza di un Workflow Document i documenti clinici ad esso correlati sono sempre rintracciabili attraverso il riferimento (attraverso XDSDocumentEntry.uniqueId e homeCommunityId) tracciato all'interno del Workflow Document stesso nelle sezioni di input e output delle differenti task.

L'utilizzo di una cartella per raggruppare le diverse versioni del Workflow Document è necessario per avere un id fissato che identifichi l'intero workflow. Dato che il Workflow Document può essere aggiornato più volte (più precisamente ad ogni step evolutivo del workflow), il suo uid/id non è utile per mantenere un riferimento fisso. Posizionando tutte le versioni dello stesso Workflow Document all'interno della stessa cartella permette l'utilizzo del FolderId come un link fisso verso lo specifico Workflow. Un Workflow Document può essere contenuto all'interno di una sola Workflow Content Folder, nella quale è presente un unica versione del documento in uno stato “approved” e tutte le versioni precedenti nello stato “deprecated”. Se un workflow genera un sotto-workflow saranno presenti due distinte folders, una per ogni sotto-workflow. La relazione tra i due workflow è garantita all'interno del Workflow Document utilizzando l'XDSFolder.uniqueId come output della task del parent Wokflow Document e come input della prima t5ask del child Workflow Document.

7.4.3 Creazione di un nuovo Workflow

Quando viene completato il primo step di un nuovo workflow, l'XDW Content Creator deve: -creare la prima versione del Workflow Document

In seguito l'XDS Document Soiurce raggruppato con l'attore precedente deve: -creare un nuovo Workflow Context Folder

-inviare il Workflow Document all'XDES Document Repository, all'interno della nuova cartella creata utilizzando ITI-41 Provide and Register Document Set-b

7.4.4 Aggiornamento il Workflow Document

Per ogni step seguente nel Workflow l'XDW Content Updater deve:

-ottenere la versione più recente del Workflow Document, che rappresenta l'unica versione nello stato approvato contenuta all'interno della cartella (utilizzando l'XDS Document Consumer raggruppato).

-aggiornare il contenuto del Workflow Document (aggiungendo una nuova task o aggiungendo ad una task pre-esistente un elemento <taskEvent>)

-ri-registrare la nuova versione del Workflow Document attraverso un replace della versione precedente (utilizzando l'XDS Document Source raggruppato con l'XDW Content Updater) Questa nuova versione è automaticamente aggiunta alla cartella corretta attraverso le normali regole XDS per il replacement in una folder.

In un infrastruttura per la condivisione (per esempio XDS) due dufferenti Content Updaters potrebbero essere nella situazione di apportare contemporaneamente un aggiornamento allo stesso Workflow Document. In questo caso entrambi gli updator (definiti come Content Updator A, Content Updator B) ritirano il Workflow Document (per esempio il WD a cui è associat il document id 1) e lo modificano.

-Content Creator A trasforma in deprecated la versione precedente del documento, e pubblica successivamente la versione aggiornata con il nuovo documentId (per esempio documentId=2)

-Quando il Content Creator B prova a sostituire lo stesso Workflow Document (con documentId=1) con la sua versione aggiornata la transazione viene impedita, perchè il documetnId=1 è diventato deprecated in quanto già sostituito con il documentId=2.

-Il Content Creator B ritira dunque la versione corrente del Workflow Document (documentId=2) e la aggiorna con la nuova versione del documento con documentId=3

7.4.5 Ottenere tutti i documenti associati al Workflow

La versione più recente del Workflow Document può essere consultato durante ogni punto del Workflow. La versione del Workflow Document con lo stato approvato, contiene le informazioni

più recenti relative al Workflow ed alle tasks correlate. Quindi un XDW Content Consumer deve solamente analizzare il documento nello stato approvato per ricavare tutte le informazioni necessarie. Ogni Workflow Document contiene dettagli di ogni task che è stata eseguita. Una task o un <taskEvent> include il riferimento (XDSDocumentEntry.uniqueId e homeCommunity.Id) da zero a più input o output documenti clinici. Questi documenti possono essere ottenuti attraverso l'utilizzo delle potenzialità offerte dal profilo XDS, oppure XDR o XDM se sono utilizzati.

7.4.6 Utilizzo del eventCodeList per gestire lo stato del Workflow Document

E' necessario avere una modalità per definire lo stato del Workflow ad ogni step. Questo stato può essere OPEN o CLOSED. Questo stato deve essere definito per ogni step del Workflow. Settando questo metadato a OPEN, l'autore dello step indica che, per la definizione del Workflow e dello step eseguito, necessita ulteriori step per essere completato.

Settando questo metadato a CLOSED, l'autore dello step indica che per la definizione del Workflow e dello step eseguito non sono necessari e non possono essere eseguiti ulteriori steps.

Questo codice deve essere presente per tutti gli XDW Workflow Document e deve essere definito anche per ogni task all'interno dell'eventCodeList, un elemento che permette di tracciare i cambiamenti di stato di una task. L'utilizzo dei codici permette l'utilizzo di query specifiche per individuare Workflow attivi con specifiche proprietà. I codici per eventCodeList possono essere OPEN o CLOSE.