5.4 XDW Workflow Content Module

This section defines the XDW Workflow Document by providing a schema and explaining its use. This document does not include clinical information about the patient directly. It shall only contain information necessary for organizing and defining work tasks. All clinical information regarding any task shall be provided through separate documents that are referenced from the associated input or output documents.

5.4.1 Referenced Standards

HL7 CDA Release 2.0 (denoted HL7 CDA R2, or just CDA, in subsequent text)

Web Services – Human Task (WS-HumanTask) Specification Version 1.1, OASIS

5.4.2 Discussion of Content Standards

The XDW Workflow Document is a document that incorporates elements from the HL7 CDA document structure and from the WS-HumanTask structure. The Workflow Document exists to coordinate the activities of multiple people in different organizations. They agree to share these documents as a method of exchanging work information. These documents are used by these organizations to feed what is often considered their own internal task management systems and have their own administrative rules for managing activities.

Sharing clinical documents is often accomplished as a normal part of providing healthcare. The XDW workflow allows the work information to be shared in the same way as other patient related clinical information. Integrating the internal workflow management systems of independent organizations with independent administrative rules, and perhaps in different legal and regulatory systems, is avoided.

The XDW Workflow Document does not contain clinical information about the patient. The input, output, and other elements of the task data shall contain references to documents (DocumentEntry.uniqueId) that contain the clinical information.

XDW Workflow uses the XDS lifecycle management tools to coordinate updates to the Workflow Document instead of requiring an integration of all the different task management systems in the different organizations.

The XDW Workflow Document builds upon two other standards, HL7 CDA and OASIS WS-Human Task.

The XDW Workflow Document shall comply with the XDW XML Schema that includes elements from the CDA and OASIS Human Task standards. Access to the schema files from those standards will be needed.

The figure below represents the main level structure of the Workflow Document with the first level of the elements that composed the structure.

It is possible to divide the structured into four parts:

• Part 1: elements derived from HL7 CDA standard (Type of the element: CDA),
• Part 2: two elements, patient and author, defined in the XDWSchema with the structure derived from HL7 R-MIM standard (Type of the element: tXDWpatient and tXDWauthor),
• Part 3: elements defined by IHE XDW Profile
• Part 4: the element <TaskList> in which is defined by elements derived from the OASIS WS-HumanTask standard. In this last section the <TaskList> is a list of elements <XDWTask> composed of the HumanTask <taskData> (all data that define the XDWTask) and the HumanTask <taskEventHistory> that contains a list of elements <taskEvent>.

All the elements of the Figure 5.4.2-1 are described in Section 5.4.3.

5.4.2.1 XDW Workflow Document Elements from HL7 CDA Standard

Some elements are incorporated directly from the HL7 CDA standard. This means that the elements, their definitions, and the rules for interpreting them are in the HL7 standard. These are summarized here for convenience.

<patient> and <author> elements have been defined based upon the HL7 CDA R-MIM. The XDW schema defines these elements using elements from CDA, and was derived by eliminating all elements that are not needed for workflow identification purposes. The R-MIM includes elements that are of clinical value. These have been removed for workflow use.

5.4.2.2 XDW Workflow Document Elements defined by IHE XDW Profile

The XDW Workflow Document also has elements that are defined by IHE (see Table 5.4.3-1):

• <workflowInstanceId> Every version of the Workflow Document shall have the same workflowInstanceId value. This value shall be an OID. It is conveyed in the DocumentEntry.referenceIdList attribute of the workflow document’s metadata. It shall be globally unique, because it is shared by many organizations.
• <workflowDocumentSequenceNumber> This is used to simplify management of the changes to the Workflow Document as the workflow is executed. It shall be created as "1", and be incremented for each update to the Workflow Document.
• <workflowStatus> This shall be either:
• OPEN– which means that further updates are expected for this Workflow Document. These updates could be modifications to existing tasks or addition of new tasks or update to an existing task. Tasks shall not be deleted.
• CLOSED– which means that further updates to this Workflow Document are not expected. A workflow with a CLOSED workflowStatus may continue to be updated, after which the value of workflowStatus may be transitioned back to OPEN or remain CLOSED. These constraints will be defined by the Workflow Definition referenced.
• <workflowStatusHistory> This element represents the history of changes of status of the workflow document. It consists of sub-elements named documentEvent. Each documentEvent describes a change of status of the workflow document. In case that the workflowDefinitionReference describes a type of workflow that can’t change its status from CLOSED to OPEN, the workflowStatusHistory contain at most two documentEvent elements, one for the opening of the workflow corresponding to the creation of the workflow document, and one to track the closing of the process related. Instead, if the workflowDefinitionReference permits the change of status from CLOSED to OPEN (e.g., OPEN-->CLOSED-->OPEN…) the element workflowStatusHistory will contain from 1 to N documentEvent elements to track these changes. A documentEvent is described by sub-elements defined in Table 5.4.3-5.

• <workflowDefinitionReference>. This is the reference to the workflow definition. This is usually contained in policy or procedure document or may be defined by IHE as a specific workflow definition profile. This profile places no restriction on the style used to document such Workflow definition. It is recommended to assign an OID to those. It shall be recorded by the creator of the initial Workflow Document and shall be preserved unchanged in all subsequent versions of the document.

5.4.2.3 XDW Workflow Document Elements from the OASIS Human Task

The descriptions of a task and of <taskEvent> are taken from the OASIS Human Task standard. This standard defines a way to describe a human task. It was defined as an extension to the BPEL and BPMN workflow standards. These standards are in use to manage the workflow of automated tasks under the control of an integrated task management system. It was recognized that while these standards do not have the ability to control human task, they needed a way to describe tasks to be performed by humans and other organizations.

The element <XDWTask> groups all information about one task in the workflow, the <XDWTask> is structured in two sub elements: <taskData> and <taskEventHistory>.

• <taskData> describes a single task. This is a list of details about the task, a description, the inputs to the task (e.g., documents), the outputs from the task (e.g., documents), fault descriptions and comments. The <taskDetails> include elements like the task ID, description, state, etc. (see Table 5.4.3-8)
• <taskEventHistory> contains a list of the <taskEvent> elements that describe the changes of the task. For each task, there is one or more <taskEvent> that describes the history of the task. There is a list of the <taskEvent>: an <eventType>, a description, the inputs to the <taskEvent> (e.g., documents), the outputs from the <taskEvent> (e.g., documents), fault descriptions, comments, and attachments (other documents that do not represent outputs). The details include elements like the task ID, status, etc. (see Table 5.4.3-10)

The definitions and rules such as the state machine that defines status are in the Human Task standard. There are other datatypes and web services also defined in Human Task standard that are not used by XDW.

5.4.2.4 Relationship between Task and <taskEvent>

When a Task is generated it has a first <taskEvent>. A Task can either have only one <taskEvent> if the status of the task is not modifiable and it is born just completed or it can have more status and so more taskEvents. In this case at any time the task changed a new <taskEvent> is created.

When a new Task is generated, zero or more references to external documents, associated with the Task, either as input or output, are put in the respective element of the Task. As a Task changes new input or output documents may be added (cumulative list of references). However, for each Task Event, only the input and output document related to the specific task Event shall be included. The inputs documents of a <taskEvent> are the documents that have been used as input for performing the Task change. The Output documents are those that have been created as a result of the Task Change. As a consequence, all input and output document references, present one or more times in the task Events list shall be listed (without duplicates) in the Task. Likewise for output document references.

The clinical documents referenced in the input or output data elements of Tasks and task Events shall be accessible in the affinity domain (if XDW is used along with XDS) or Media Interchange (if used along with XDM) or Point-to-point submission set (if used along with XDR). In anticipation of the use of XDW in a cross-community environment, both the document uniqueId and homeCommunityId are permitted to be included.

The XDW Workflow Document defines a task list which is a series of task descriptions. The relationship between the task, the order of the elements in this list and the possible status of a task, all of the rules are defined in the Workflow Definition Document.

The XDW Profiles define the recommended statuses processable in a Task with the <taskEvent>. These statuses are a subset of the HumanTask Standard. There are other task status values possible, but these are not normally used.

Table 5.4.2.4-1: Description of Task Status

Task status	Description
CREATED	The workflow is open, the task is created but not assigned to an owner
READY	The task created is assigned to an owner and is ready to be performed
IN_PROGRESS	The task is started and the owner is performing the task actions
FAILED	The task is completed with fault response (it is not possible conclude the action of the task)
COMPLETED	The task is completed with response

 

Note: See HumanTask standard specification for the complete list of task statuses and transitions between them (OASIS Web Services – Human Task (WS-HumanTask) Specification Version 1.1 Section 4.10 “Human Task Behavior and State Transitions”).

The elements <XDWTask> and XDW <taskEvent> are constrained by XDW with a minimal set of elements required. These elements are fully extensible with any kind of attributes defined by Human Task standard. This allows specific Workflow Definition profiles to add elements defined in Human Task to manage for example intertask relationships, additional status, etc. to address more advanced specific workflow requirements.

5.4.3 Content Specification

The tables below represent all Workflow Document elements. The tables show for each element the Optionality and the standard from which the definition and the structure of the element derive.

Optionality:

R = element Required for XDW Profile

R2 = element Required if known for XDW Profile

O = element Optional for XDW Profile

X = element shall not be used

Inside the tables the column description is used to constrain the use of the attribute when referring to element defined in the underlining standard. When the description in blank no constrains is required. When the element is defined by XDW this is the complete description.

There are three functional roles for interacting with these elements.

• The "create" role specifies what elements shall be created. The Content Creator is permitted to include any optional element, and may include other elements.
• The "view" role specifies what elements shall be presented by Content Consumer or Content Updater that support viewing of the document. It may present for viewing any other element that it understands or has a means of presenting. There are elements that are required for viewing, while being optional for both creation and viewing.
• The "update" role specifies what elements shall be maintained with correct values when updating a document. An "update" operation shall preserve the value of all elements that are present, even if their meaning is unknown. This means that an updater might not update the contents of optional elements when updating a workflow document.

If one of the following tables does not specify separate values for the three roles, then the specified value applies to all three roles.

Tables uses the following namespace conventions:

• cda="urn:hl7-org:v3"
• ht="http://docs.oasis-open.org/ns/bpel4people/ws-humantask/types/200803"
• xs="http://www.w3.org/2001/XMLSchema"
• xdw="urn:ihe:iti:xdw:2011"

• <XDW.WorkflowDocument>

Table 5.4.3-1: Elements of the Workflow Document

XDW.WorkflowDocument element	Standard	Data Type	Optionality	Description
id	HL7 CDA	cda:II	R	Document ID
title	HL7 CDA	cda:ST	O	Displayable title
effectiveTime	HL7 CDA	cda:TS	R	Time of most recent update
confidentialityCode	HL7 CDA	cda:CE	R
languageCode	HL7 CDA	cda:CS	O
patient	HL7 CDA	xdw:tXDWpatient	R	Patient information derived from R-MIM. Restricted to non-clinical necessary content. See Table 5.4.3-2
author	HL7 CDA	xdw:tXDWAuthor	R	Author information derived from R-MIM. Restricted to non-clinical necessary content. See Table 5.4.3-3
workflowInstanceId	IHE	OID	R	Conveys the workflow identifier. It shall contain the same value as the CXi.1 component of the DocumentEntry.referenceIdList metadata attribute.
workflowDocumentSequenceNumber	IHE	xs:int	R
workflowStatus	IHE	xs:token	R	OPEN if modifications are permitted to the document contents. CLOSED if modifications are not expected.
workflowStatusHistory	IHE	xdw:workflowStatusHistory_type	R	List of changes of the workflowStatus See Table 5.4.3-4
workflowDefinitionReference	IHE	xs:anyURI	R	References (urn: OID:) to the documents that define this kind of workflow.
TaskList	IHE	xdw:TaskList_type	R	List of all tasks and their history See Table 5.4.3-6

• <patient>

Table 5.4.3-2: Patient Element

Patient element	Standard	Data Type	Optionality	Description
id	HL7 CDA	cda:II	R
name	HL7 CDA	cda:PN	O
administrativeGenderCode	HL7 CDA	cda:CE	O
birthTime	HL7 CDA	cda:TS	O
martialStatusCode	HL7 CDA	cda:CE	O

• <author>

Table 5.4.3-3: Author Element

Author element	Standard	Data Type	Optionality	Definition
assignedAuthor	HL7 CDA	cda:POCD_MT000040.AssignedAuthor	R	Either assignedAuthoringDevice or assignedPerson should be specified

• <workflowStatusHistory>

Table 5.4.3-4: workflowStatusHistory Element

workflowStatusHistory element	Standard	Data Type	Optionality	Description
documentEvent	IHE	xdw:tXDWdocumentEvent_type	R	A detailed event that represents a change of the workflowStatus The first documentEvent element is added when the workflow document is created. A documentEvent element is then added whenever the workflowStatus of the workflow document changes. See Table 5.4.3-5

• <documentEvent>

Table 5.4.3-5: documentEvent Element

documentEvent element	Standard	Data Type	Optionality	Description
eventTime	OASIS_WS-HumanTask	xs:dateTime	R	Time when the specific documentEvent element is added to the workflow document.
eventType	OASIS_WS-HumanTask	ht:tTaskEventType	R	The type of event that happens that solicits the modification of the workflowStatus. Valued with one of the types defined in the HumanTask specification (C. WS-HumanTask Data Types Schema, <!-- Defines the human task event types -->).
taskEventIdentifier	IHE	xs:anyURI	R	Element that permits to track the reference to the taskEvent that solicits the modification of the workflowStatus. It stores the same value of the element taskEvent/identifier of the taskEvent of reference.
author	IHE	xs:string	R	Actual owner of the workflow after the event
previousStatus	IHE	xs:token	R	The previous value of workflowStatus. Either “OPEN” or “CLOSED”. In case of a Workflow Document just created this element shall be valorized with “”
actualStatus	IHE	xs:token	R	Equal to the current value of the workflowStatus element. Either “OPEN” or “CLOSED”.

• <TaskList>

Table 5.4.3-6: TaskList Element

TaskList element	Standard	Data Type	Optionality	Description
XDWTask	IHE	xdw:tXDWTask	R	List of tasks See Table 5.4.3-7

• <XDWTask>

Table 5.4.3-7: XDWTask Element

XDWTask element	Standard	Data Type	Optionality	Description
taskData	OASIS_WS-HumanTask	ht:tTaskInstanceData	R	Description of the current task (status, inputs, outputs, etc.) See Table 5.4.3-8
taskEventHistory	IHE	xdw:tXDWeventHistory	R	History of the changes to the current task (dates, changes, etc.) See Table 5.4.3-11

• <taskData>

The XDW Profile adds the following restrictions to the OASIS definition for taskData:

• The taskData/input shall contain a taskData/input/part for every clinical document or workflow that is to be used as input to the task. This element is of type tMessagePartsData. An element <part> shall have a child element <AttachmentInfo> of type tAttachmentInfo. Table 5.4.3-9 describes how to assign values to each AttachmentInfo child element.
• The taskData/output shall contain a taskData/output/part for every clinical document or workflow that is created as a result of the task that is to be shared. This element is of type tMessagePartsData. An element <part> shall have a child element <AttachmentInfo> of type tAttachmentInfo. Table 5.4.3-9 describes how to assign values to each AttachmentInfo child element.
• Any clinical documents that are registered in an XDS Document Registry shall be identified in the taskData/input/part, taskData/output/part, or taskData/attachmentInfos/info as described in Table 5.4.3-9.
• The element <part> shall have an attribute @name. The value of this attribute identifies the role played by the referenced object within the task. A Workflow Definition profile shall define a list of acceptable values for this attribute. If no Workflow Definition profile is supported and if no values are defined by local policies, this value shall be set to “XDSRegisteredDocument”.

Table 5.4.3-8: taskData Element

taskData element	Standard	Data Type	Optionality			Description
			Create	View	Update
taskDetails	OASIS_WS-HumanTask	ht:tTaskDetails	R	R	R	See Table 5.4.3-10
description	OASIS_WS-HumanTask	xs:string	R	R	R	Textual description
input	OASIS_WS-HumanTask	ht:tMessagePartsData	R	R	R	This element lists documents/workflows referenced by the task as inputs, using a child <part> element for each document/workflow.
output	OASIS_WS-HumanTask	ht:tMessagePartsData	R	R	R	This element lists documents/workflows referenced by the task as outputs, using a child <part> element for each document/workflow.
fault	OASIS_WS-HumanTask	ht:tFaultData	O	R	O	Description of fault
comments	OASIS_WS-HumanTask	ht:tComments	O	R	O	Structured comments about the task

• <AttachmentInfo>

Each document referenced in input or output elements is structured using a tAttachmentInfo data type. The XDW Profile extends this data type, adding a new optional child element (homeCommunityId) that can be used to convey the home community Id of the referenced document. The structure of the <AttachmentInfo> element is described in Table 5.4.3-9. An <AttachmentInfo> element can be used to refer to another workflow. An <AttachmentInfo> element that stores a reference to a child or parent workflow shall contain an accessType with the value urn:ihe:iti:xdw:2013:workflowInstanceId.

Table 5.4.3-9: AttachmentInfo Element

AttachmentInfo element	Standard	Data Type	Optionality			Description
			Create	View	Update
identifier	OASIS_WS-HumanTask	xs:anyURI	R	R	R	If the accessType is urn:ihe:iti:xdw:2011:XDSregistered ; the identifier shall contain the value of DocumentEntry.uniqueId If the accessType is urn:ihe:iti:xdw:2013:workflowInstanceId ,; the identifier shall contain the value of the DocumentEntry.referenceIdList in the referenced workflow. See Note 1.
name	OASIS_WS-HumanTask	xs:string	R	R	R	Stores the same value of the part/@name attribute
accessType	OASIS_WS-HumanTask	xs:string	R	R	R	If the attachment is a document, the value of accessType shall be urn:ihe:iti: xdw:2011:XDSregistered . If the part element references another workflow, the value of accessType shall be urn:ihe:iti:xdw:2013:workflowInstanceId . See Note 1.
contentType	OASIS_WS-HumanTask	xs:string	R	R	R	Conveys the MIME type of the referenced document. If the attachment refers to a child/parent workflow then this element shall be empty.
contentCategory	OASIS_WS-HumanTask	xs:anyURI	R	R	R	Fixed value http://www.iana.org/assignments/media-types
attachedTime	OASIS_WS-HumanTask	xs:dateTime	R	R	R	The date/time when the document is attached as reference
attachedBy	OASIS_WS-HumanTask	ht:tUser	R	R	R	The owner that attached the reference to the task
homeCommunityId	IHE	OID	O	O	O	The home community Id of the referenced document

Note 1: The XDW Profile allows for reference to objects other than XDS documents or XDW Workflows. In this case the <identifier> element identifies the uid of the referenced object. The <accessType> of this referenced objects shall be “URL”. No further constraints are defined for other elements.

• <taskDetails>

Table 5.4.3-10: taskDetails Element

taskDetails element	Standard	Data Type	Optionality			Description
			Create	View	Update
id	OASIS_WS-HumanTask	xs:anyURI	R	R	R	Internal ID for the task
taskType	OASIS_WS-HumanTask	xs:string	R	R	R
name	OASIS_WS-HumanTask	xs:QName	R	R	R	The name of the task
status	OASIS_WS-HumanTask	ht:tStatus	R	R	R	Recommend limiting values to the statuses described above.
priority	OASIS_WS-HumanTask	ht:tPriority	O	R	O
taskInitiator	OASIS_WS-HumanTask	ht:tuser	O	O	O
taskStakeholders	OASIS_WS-HumanTask	ht:tOrganizationalEntity	O	O	O
potentialOwners	OASIS_WS-HumanTask	ht:tOrganizationalEntity	O	O	O	Owners in Human Task terminology are people/organizations/ etc. that perform the task.
businessAdministrators	OASIS_WS-HumanTask	ht:tOrganizationalEntity	O	O	O
actualOwner	OASIS_WS-HumanTask	ht:tUser	R	R	R	The actual performer of the task.
notificationRecipients	OASIS_WS-HumanTask	ht:tOrganizationalEntity	O	R	O	Notification Recipient may be used to contain information about persons to be notified. Use of this element does not imply that Human Task "notification" will be used. This element may be used to trigger notification mechanisms outside of XDW (e.g., IHE DSUB Profile). This combined use is not part of this profile specification
createdTime	OASIS_WS-HumanTask	xs:dateTime	R	R	O
createdBy	OASIS_WS-HumanTask	ht:tUser	R	R	O
lastModifiedTime	OASIS_WS-HumanTask	xs:dateTime	R (Note 1)	R	R
lastModifyBy	OASIS_WS-HumanTask	ht:tUser	O	R	R
activationTime	OASIS_WS-HumanTask	xs:dateTime	O	R	O
expirationTime	OASIS_WS-HumanTask	xs:dateTime	O	R	O
isSkipable	OASIS_WS-HumanTask	xs:boolean	O	R	O
hasPotentialOwners	OASIS_WS-HumanTask	xs:boolean	O	O	O
startedByTimeExists	OASIS_WS-HumanTask	xs:boolean	X	X	X
completedByTimeExists	OASIS_WS-HumanTask	xs:boolean	X	X	X
presentationName	OASIS_WS-HumanTask	ht:tPresentationName	O	O	O
presentationSubject	OASIS_WS-HumanTask	ht:tPresentationSubject	O	O	O
renderingMethodExists	OASIS_WS-HumanTask	xs:boolean	R	R	R	Value shall be “false”
hasOutput	OASIS_WS-HumanTask	xs:boolean	X	X	X
hasFault	OASIS_WS-HumanTask	xs:boolean	X	X	X
hasAttachments	OASIS_WS-HumanTask	xs:boolean	X	X	X
hasComments	OASIS_WS-HumanTask	xs:boolean	X	X	X
escalated	OASIS_WS-HumanTask	xs:boolean	O	R	O
searchBy	OASIS_WS-HumanTask	xs:string	X	X	X
outcome	OASIS_WS-HumanTask	xs:string	X	X	X
parentTaskId	OASIS_WS-HumanTask	xs:anyURI	X	X	X	XDW prohibits use of subTasks
hasSubTasks	OASIS_WS-HumanTask	xs:boolean	X	X	X	XDW prohibits use of subTasks.

Note 1: lastModifiedTime shall be the same as createdTime

• <taskEventHistory>

Table 5.4.3-11: taskEventHistory Element

taskEventHistory element	Standard	Data Type	Optionality	Description
taskEvent	OASIS_WS-HumanTask	ht:taskEvent_type	R	See Table 5.4.3-12

• <taskEvent>

Table 5.4.3-12: taskEvent Element

taskEvent element	Standard	Data Type	Optionality	Description
id	OASIS_WS-HumanTask	xs:integer	R
eventTime	OASIS_WS-HumanTask	xs:dateTime	R
identifier	OASIS_WS-HumanTask	xs:anyURI	R
principal	OASIS_WS-HumanTask	xs:string	O
eventType	OASIS_WS-HumanTask	ht:tTaskEventType	R	The type of event that happens that solicits the modification of the status of the task (adding a new taskEvent). Valued with one of the types defined in the HumanTask specification (C. WS-HumanTask Data Types Schema, <!-- Defines the human task event types -->).
startOwner	OASIS_WS-HumanTask	xs:string	O
endOwner	OASIS_WS-HumanTask	xs:string	O
status	OASIS_WS-HumanTask	ht:tStatus	R
hasData	OASIS_WS-HumanTask	xs:Boolean	O
eventData	OASIS_WS-HumanTask	xs:anyType	R2	This structure includes the data elements that were changed by this event.
faultName	OASIS_WS-HumanTask	xs:string	O

5.4.4 Complete Example

In the example in Figure 5.4.4-1 represents the XML of the XDW Workflow Document for the use case described in ITI TF-1: 30.4.2.1. This example represents the complete Workflow Document at the end of the process (see column C of ITI TF-1: Figure 30.4.2.2-1).

In this case there are two tasks:

• the first task has been created in status “COMPLETED” and so it has only one taskEvent in the taskEventHistory;
• the second task ends the process in status “COMPLETED” and it has two taskEvent.

Figure 5.4.4-1: Sample XDW Workflow Document

5.4.5 Workflow Document Management

5.4.5.1 Workflow Document Lifecycle Management

The Cross-Enterprise Document Workflow Profile takes advantage of the lifecycle management of XDS when used in an XDS environment.

A Workflow Document shall be created and be assigned a workflow identifier. The initial document shall include at least one task on the TaskList, and have a workflowStatus of OPEN. The Workflow Document is updated when:

• The information about a task is modified. This may be due to a change in some other task related information like updating the output information.
• A new task is added to the <TaskList>.
• The workflow status is changed to CLOSED.

Each update shall be done using the XDS Document Replace when in an XDS environment. The series of steps to be taken is:

• Update the XDW document to reflect the desired changes. This is often replacement of the <TaskData>. It may also be a change by adding a new task to the <TaskList> or a new <taskEvent> to a Task.
• Use the XDS Replace operation to replace the old document with this modified document. This replacement document shall carry the same workflow identifier as the original Workflow Document.
• It is possible that a document replace will be rejected by the XDS Document Registry if another actor has also done a replace in the time since the Workflow Document instance was obtained. In this case (attempting to replace a document already replaced), the XDW Document Creator or Updater shall obtain the most recent version of the Workflow Document which was updated by another XDW actor, consider the evolution of the workflow, and performed a new content update. This kind of race condition should be very rare because updating is much faster than the rate at which people perform tasks. If certain workflows definitions require reducing the likelihood of such race conditions, one should consider placing in the Workflow Description one or more tasks "In Progress" and requiring that other actor wait while such tasks are in-progress.

When using XDR or XDM, the receiving actor shall perform an equivalent local update process.

When an XDW actor decides that a workflow status code shall be placed in a CLOSED status, a final update to set the workflow status code to CLOSED shall be performed. The specific rules for determining when and which XDW actors are allowed or should set the workflow status code to CLOSED are not specified by the XDW Profile. They may be determined within the Workflow Definition. XDW Content Consumer and Content Updater Actors shall support the means to query for Workflow Documents that are in a workflow status OPEN.

This profile does not further constrain the rules for document lifecycle management, but a specific Workflow Definition may add requirements requiring that certain kinds of tasks be created initially, restricting the kinds of tasks that can be added, and requiring that updates be performed for specific task changes.

5.4.5.2 Associations Types

A clinical document can be referenced by many Workflow Documents in different steps and for different reasons. When the content of a Workflow Document is known, the related clinical documents are always reached through the references (DocumentEntry.uniqueId and homeCommunityId) tracked inside the different task in the “input" and “output” elements.

The use of a workflow identifier is necessary to have a fixed id to identify the whole workflow. Since the Workflow Document will be replaced many times (it is replaced at each step), its DocumentEntry.uniqueId metadata attribute is not useful for maintaining a fixed reference. The document uniqueId of each of the successive XDW documents can be used to identify a particular state of the workflow.

XDW uses a workflow identifier stored in the DocumentEntry.referenceIdList metadata attribute of each workflow document to group all versions of the workflow document.

• The Content Creator shall create a workflow identifier, as an OID, when a new workflow is created.
• The Content Creator shall create a single value in DocumentEntry.referenceIdList containing the workflow identifier. Only the CXi.1 and CXi.5 component shall be present.
  An example workflow identifier in DocumentEntry.referenceIdList is: 2.16.840.1^^^^urn:ihe:iti:xdw:2013:workflowInstanceId
• The Content Updater shall use the same value for the workflow identifier when it creates a new version of the Workflow Document.

Since every version of the Workflow Document replaces the previous, there is always one and only one approved document with a given workflow identifier.

If a workflow generates another workflow there shall be two different workflow identifiers, one for each workflow. The relationship between the different workflows is always guaranteed to be inside the Workflow Documents using the DocumentEntry.referenceIdList as output of the task of the parent Workflow Document and as the input of the first task in the child Workflow Document.

5.4.5.3 Create workflow

When the first step of a new workflow is completed, the XDW Content Creator shall:

• create the first version of the Workflow Document.

Then the XDW Content Creator shall use Provide and Register Document Set-b [ITI-41] (in the case of XDS):

• submit the Workflow Document to the XDS Document Repository, using a new workflow identifier in the document’s DocumentEntry.referencedIdList metadata attribute, using Provide and Register Document Set-b [ITI-41].

5.4.5.4 Update Workflow Document

For each subsequent step in the Workflow an XDW Content Updater shall:

• obtain the most recent version of the Workflow Document, the only version approved with the specific workflow identifier in the DocumentEntry.referenceIdList  (e.g., using a grouped XDS Document Consumer)
• update the content in the Workflow Document (by adding a new task or updating an existing task with a new <taskEvent>)
• re-register (update) the Workflow Document by performing a document replace (e.g., in a XDS environment using a grouped XDS Document Source).

This new version of the workflow document has the same workflow identifier as the previous version.

In a Document Sharing infrastructure (e.g., an XDS environment) two different Content Updaters could be in the situation of race condition when they both update the same Workflow Document at the same time.

In this case two actors (Content Updater A and Content Updater B) retrieve the same Workflow Document (e.g., Workflow Document with document uniqueId 1) and change it.

Content Updater A publishes a new version updated with a new document uniqueId (e.g., document uniqueId 2) and the previous version (with document uniqueId 1) is deprecated.

When Updater Creator B tries to replace the same Workflow Document (document uniqueId 1) with his updated version this transaction generates an error because the document uniqueId 1 is deprecated and replaced with document uniqueId 2.

Content Updater B shall retrieve the current version of the Workflow Document (document uniqueId 2) and update it with a new version of the document with document uniqueId 3.

5.4.5.5 Association of a clinical document to a task and <taskEvent>

Any clinical documents included as input or output documents within the taskData element that are registered in an XDS Document Registry shall be referenced using uniqueId and homeCommunityId of the Clinical Document referenced.

5.4.5.6 Get the Workflow Document and a clinical document associated to the workflow

The most recent version of the Workflow Document may be retrieved at any point during the workflow.

The version of the Workflow Document with an approved status contains the most current information on the workflow and its tasks. So, an XDW Content Consumer needs to analyze only the approved version to get all current information.

Any Workflow Document contains details of each task that has been performed. A task or <taskEvent> includes the references (DocumentEntry.uniqueId and homeCommunityId) to zero or more input and/or output clinical documents. These documents may be obtained by means of XDS, or should be included along with the Workflow Document if XDR or XDM is used.

5.4.5.7 Use of the eventCodeList to manage the status of a Workflow Document

An overall workflow status is required to be set by each author of a new step. This value is either OPEN or CLOSED.

This workflow status is required to be present in every workflow step, and shall take either the value OPEN or CLOSED.

By setting this workflow status to OPEN, a step author indicates that, for the workflow definition and the step author further steps are expected to be performed.

By setting this workflow status to CLOSED, a step author indicates that, for the workflow definition and the step author no further steps are expected to be performed.

This workflow status shall be present for all XDW documents in its eventCodeList metadata.

This use of workflow status enables the use of query to locate OPEN or CLOSED workflows with certain other properties.

The EventCodeList contains the workflow status with two possible code values: either OPEN or CLOSED.

5.4.5.8 Parameters for Required Queries

The section below documents some examples of the possible queries in an XDS environment (defined in the Registry Stored Query [ITI-18] transaction) to obtain the different documents related to the workflow from some parameters available:

• Find all open Workflow Documents for a patient

A Registry Stored Query “FindDocuments” maybe used with patientId, XDW document formatCode and eventCodeList with the value “urn:ihe:iti:xdw:2011:eventCode:open” for the Workflow Document.

• Find all particular type of open Workflow Documents for a patient

A Registry Stored Query “FindDocuments” may be used with patientId, XDW document formatCode, eventCodeList with the value “urn:ihe:iti:xdw:2011:eventCode:open” for the Workflow Document and a specific XDW document typeCode.

• Get one or more documents referenced in a Workflow Document

A Registry Stored Query “FindDocuments” which retrieves the Workflow Document (like in the first example) and a Registry Stored Query “GetDocuments” with document uniqueId and homeCommunityId to retrieve one or more documents referenced inside the Workflow Document.

• Find the latest version of a Workflow Document for a given workflow identifier

A Registry Stored Query “FindDocumentsByReferenceId” may be used with patientId and the workflow identifier.

5.4.6 XDS Metadata

5.4.6.1 Document Metadata

The following metadata elements shall be used to describe the Workflow Document in an XDS Affinity Domain. The XDW Profile does not introduce new metadata and all the metadata elements used are the common Document Sharing specified in Section 4.2.3.2.

Table 5.4.6.1-1: XDW Constraints for Document Metadata Attributes

DocumentEntry Attribute	XDW Constraints
author	Represents the humans and/or machines that authored the document. In the Workflow Document the Author is the human and/or machine which most recently updated the Workflow Document. This means that when a Workflow Document is updated by a different person or machine, the author changes.
authorInstitution (sub-attribute of author)	No special requirements for Workflow Document
authorPerson (sub-attribute of author)	No special requirements for Workflow Document
authorRole (sub-attribute of author)	No special requirements for Workflow Document
authorSpecialty (sub-attribute of author)	No special requirements for Workflow Document
availabilityStatus	No special requirements for Workflow Document
classCode	This code is specified by the XDS Affinity Domain. The XDS Affinity Domain should specify a code for non-clinical Workflow Management documents.
comments	No special requirements for Workflow Document
confidentialityCode	No special requirements for Workflow Document
creationTime	No special requirements for Workflow Document
entryUUID	No special requirements for Workflow Document
eventCodeList	For a Workflow Document, one code of this list shall be used to define the overall status of the workflow. This code shall have one of the following two values: code: urn:ihe:iti:xdw:2011:eventCode:open codingScheme:  1.3.6.1.4.1.19376.1.2.3 code:  urn:ihe:iti:xdw:2011:eventCode:closed codingScheme:   1.3.6.1.4.1.19376.1.2.3 (See Section 5.4.5.7.)
formatCode	Each XDW Workflow Document shall have the following value for the formatCode attribute: code:  urn:ihe:iti:xdw:2011:workflowDoc codingScheme: 1.3.6.1.4.1.19376.1.2.3
hash	No special requirements for Workflow Document
healthcareFacility TypeCode	No special requirements for Workflow Document
homeCommunityId	No special requirements for Workflow Document
languageCode	No special requirements for Workflow Document
legalAuthenticator	No special requirements for Workflow Document
mimeType	No special requirements for Workflow Document
patientId	No special requirements for Workflow Document
practiceSettingCode	No special requirements for Workflow Document
referenceIdList	Contains the workflow identifier. Only a single value shall be sent in this list. Only the CXi.1 and CXi.5 components shall be used: CXi.1 shall contain same value as XDW.WorkflowDocument.workflowInstanceId CXi.5 shall contain urn:ihe:iti:xdw:2013:workflowInstanceId.
repositoryUniqueId	No special requirements for Workflow Document
serviceStartTime	Shall be the starting time the service being documented took place For the Workflow Document the serviceStartTime is the time at which work began on the earliest task for this workflow. If present, shall have a single value.
serviceStopTime	No special requirements for Workflow Document
size	No special requirements for Workflow Document
sourcePatientId	No special requirements for Workflow Document
sourcePatientInfo	No special requirements for Workflow Document
title	No special requirements for Workflow Document
typeCode	For Workflow Documents defined by an IHE profile, the profile specifies the value of typeCode used. For other Workflow Documents defined in the XDS Affinity Domain, the XDS Affinity Domain specifies the value for typeCode.
uniqueId	No special requirements for Workflow Document
URI	No special requirements for Workflow Document

5.4.6.2 XDS SubmissionSet Metadata

No additional constraints. See Section 4.2.3.3.

5.4.6.3 XDS Folder Metadata

No additional constraints.