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
All the elements of the Figure 5.4.2-1 are described in Section 5.4.3.
Figure 5.4.2-1: XDW.WorkflowDocument Structure
220.127.116.11 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.
<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.
18.104.22.168 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.
Figure 22.214.171.124-1: workflowStatusHistory Element
<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.
126.96.36.199 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.
<XDWTask> groups all information about one task in the workflow, the
<XDWTask> is structured in two sub elements:
<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
<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.
Figure 188.8.131.52-1: XDW Workflow elements derived from OASIS WS-HumanTask
184.108.40.206 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 220.127.116.11-1: Description of Task Status
|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|
Figure 18.104.22.168-1: Task Status Transition
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”).
<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.
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:
Table 5.4.3-1: Elements of the Workflow Document
|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|
Patient information derived from R-MIM. Restricted to non-clinical necessary content.
See Table 5.4.3-2
Author information derived from R-MIM. Restricted to non-clinical necessary content.
See Table 5.4.3-3
Conveys the workflow identifier.
It shall contain the same value as the CXi.1 component of the DocumentEntry.referenceIdList metadata attribute.
|workflowStatus||IHE||xs:token||R||OPEN if modifications are permitted to the document contents. CLOSED if modifications are not expected.|
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.|
List of all tasks and their history
See Table 5.4.3-6
Table 5.4.3-2: Patient Element
|Patient element||Standard||Data Type||Optionality||Description|
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|
Table 5.4.3-4: workflowStatusHistory Element
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
Table 5.4.3-5: documentEvent Element
|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”.|
Table 5.4.3-6: TaskList Element
List of tasks
See Table 5.4.3-7
Table 5.4.3-7: XDWTask Element
Description of the current task (status, inputs, outputs, etc.)
See Table 5.4.3-8
History of the changes to the current task (dates, changes, etc.)
See Table 5.4.3-11
The XDW Profile adds the following restrictions to the OASIS definition for taskData:
taskData/inputshall contain a
taskData/input/partfor 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
taskData/outputshall contain a
taskData/output/partfor 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
- Any clinical documents that are registered in an XDS Document Registry shall be identified in the
taskData/attachmentInfos/infoas 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
|taskDetails||OASIS_WS-HumanTask||ht:tTaskDetails||R||R||R||See Table 5.4.3-10|
|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:tComment||O||R||O||Structured comments about the task|
Each document referenced in
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.
<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
Table 5.4.3-9: AttachmentInfo Element
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|
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.
<accessType> of this referenced objects shall be “URL”. No further constraints are defined for other elements.
Table 5.4.3-10: taskDetails Element
|id||OASIS_WS-HumanTask||xs:anyURI||R||R||R||Internal ID for the task|
|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.|
|potentialOwners||OASIS_WS-HumanTask||ht:tOrganizationalEntity||O||O||O||Owners in Human Task terminology are people/organizations/ etc. that perform the task.|
|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|
|renderingMethodExists||OASIS_WS-HumanTask||xs:boolean||R||R||R||Value shall be “false”|
|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.|
lastModifiedTime shall be the same as
Table 5.4.3-11: taskEventHistory Element
|taskEvent||OASIS_WS-HumanTask||ht:taskEvent_type||R||See Table 5.4.3-12|
Table 5.4.3-12: taskEvent Element
|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 -->).|
|eventData||OASIS_WS-HumanTask||xs:anyType||R2||This structure includes the data elements that were changed by this event.|
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: 22.214.171.124. This example represents the complete Workflow Document at the end of the process (see column C of ITI TF-1: Figure 126.96.36.199-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.
<?xml version="1.0" encoding="UTF-8"?> <xdw:XDW.WorkflowDocument xmlns:hl7="urn:hl7-org:v3" xmlns:ws-ht="http://docs.oasis-open.org/ns/bpel4people/ws-humantask/types/200803" xmlns:xdw="urn:ihe:iti:xdw:2011" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ihe:iti:xdw:2011 XDW-2014-12-23.xsd"> <xdw:id root="188.8.131.52.5"/> <xdw:effectiveTime value="20110401031520"/> <xdw:confidentialityCode code="184.108.40.206.3"/> <xdw:patient> <xdw:id root="220.127.116.11.4.1.21318.104.22.1680" extension="33333" assigningAuthorityName="IHERED"/> </xdw:patient> <xdw:author> <xdw:assignedAuthor> <hl7:id root="22.214.171.124.5" extension="11111"/> <hl7:assignedPerson> <hl7:name> <hl7:family>Blum</hl7:family> <hl7:prefix>Dr.</hl7:prefix> </hl7:name> </hl7:assignedPerson> </xdw:assignedAuthor> </xdw:author> <xdw:workflowInstanceId>126.96.36.199</xdw:workflowInstanceId> <xdw:workflowDocumentSequenceNumber>3</xdw:workflowDocumentSequenceNumber> <xdw:workflowStatus>CLOSED</xdw:workflowStatus> <xdw:workflowStatusHistory> <xdw:documentEvent> <xdw:eventTime>2011-03-28T10:00:12.0Z</xdw:eventTime> <xdw:eventType>create</xdw:eventType> <xdw:taskEventIdentifier> urn:oid:188.8.131.52.5</xdw:taskEventIdentifier> <xdw:author>Mr. Rossi</xdw:author> <xdw:previousStatus/> <xdw:actualStatus>OPEN</xdw:actualStatus> </xdw:documentEvent> <xdw:documentEvent> <xdw:eventTime>2011-04-01T03:15:20.0Z</xdw:eventTime> <xdw:eventType>complete</xdw:eventType> <xdw:taskEventIdentifier> urn:oid:184.108.40.206.7</xdw:taskEventIdentifier> <xdw:author>Dr. Brum</xdw:author> <xdw:previousStatus>OPEN</xdw:previousStatus> <xdw:actualStatus>CLOSED</xdw:actualStatus> </xdw:documentEvent> </xdw:workflowStatusHistory> <xdw:workflowDefinitionReference>urn:oid:220.127.116.11.18.104.22.168.9</xdw:workflowDefinitionReference> <xdw:TaskList> <xdw:XDWTask> <xdw:taskData> <ws-ht:taskDetails> <ws-ht:id>1</ws-ht:id> <ws-ht:taskType>Requested</ws-ht:taskType> <ws-ht:name>ReferralRequested</ws-ht:name> <ws-ht:status>COMPLETED</ws-ht:status> <ws-ht:actualOwner>Mr. Rossi</ws-ht:actualOwner> <ws-ht:createdTime>2011-03-28T10:00:12.0Z</ws-ht:createdTime> <ws-ht:createdBy>Mr. Rossi</ws-ht:createdBy> <ws-ht:lastModifiedTime>2011-03-28T10:00:12.0Z</ws-ht:lastModifiedTime> <ws-ht:renderingMethodExists>false</ws-ht:renderingMethodExists> </ws-ht:taskDetails> <ws-ht:description>Request for a specialist visit</ws-ht:description> <ws-ht:input/> <ws-ht:output/> </xdw:taskData> <xdw:taskEventHistory> <xdw:taskEvent> <xdw:id>101</xdw:id> <xdw:eventTime>2011-03-28T10:00:12.0Z</xdw:eventTime> <xdw:identifier>urn:oid:22.214.171.124.5</xdw:identifier> <xdw:eventType>create</xdw:eventType> <xdw:status>COMPLETED</xdw:status> </xdw:taskEvent> </xdw:taskEventHistory> </xdw:XDWTask> <xdw:XDWTask> <xdw:taskData> <ws-ht:taskDetails> <ws-ht:id>2</ws-ht:id> <ws-ht:taskType>Referral Referred</ws-ht:taskType> <ws-ht:name>Referred</ws-ht:name> <ws-ht:status>COMPLETED</ws-ht:status> <ws-ht:actualOwner>Dr. Brum</ws-ht:actualOwner> <ws-ht:createdTime>2011-03-29T09:20:01.0Z</ws-ht:createdTime> <ws-ht:createdBy>Dr. Brum</ws-ht:createdBy> <ws-ht:lastModifiedTime>2011-04-01T03:15:20.0Z</ws-ht:lastModifiedTime> <ws-ht:renderingMethodExists>false</ws-ht:renderingMethodExists> </ws-ht:taskDetails> <ws-ht:description>Specialist visit</ws-ht:description> <ws-ht:input> <!-- one part element for each document in input --> <ws-ht:part name="eReferralDoc1"> <ws-ht:attachmentInfo> <ws-ht:identifier>126.96.36.199.56.7.78</ws-ht:identifier> <ws-ht:name>eReferralDoc1</ws-ht:name> <ws-ht:accessType>urn:ihe:iti: xdw:2011:XDSregistered</ws-ht:accessType> <ws-ht:contentType>application/pdf</ws-ht:contentType> <ws-ht:contentCategory>http://www.iana.org/assignments/media-types</ws-ht:contentCategory> <ws-ht:attachedTime>2011-04-01T03:15:20.0Z</ws-ht:attachedTime> <ws-ht:attachedBy>Dr. Brum</ws-ht:attachedBy> <xdw:homeCommunityId>urn:oid:188.8.131.52.5</xdw:homeCommunityId> </ws-ht:attachmentInfo> <!--eReferralDoc1--> </ws-ht:part> </ws-ht:input> <ws-ht:output> <!-- one documentReference element for each document in input --> <ws-ht:part name="ChildWorkflow"> <ws-ht:attachmentInfo> <ws-ht:identifier>184.108.40.206.12312.34</ws-ht:identifier> <ws-ht:name>ChildWorkflow</ws-ht:name> <ws-ht:accessType>urn:ihe:iti:xdw:2013:workflowInstanceId</ws-ht:accessType> <ws-ht:contentType>application/xml</ws-ht:contentType> <ws-ht:contentCategory>http://www.iana.org/assignments/media-types</ws-ht:contentCategory> <ws-ht:attachedTime>2011-04-01T03:15:20.0Z</ws-ht:attachedTime> <ws-ht:attachedBy>Dr. Brum</ws-ht:attachedBy> </ws-ht:attachmentInfo> </ws-ht:part> </ws-ht:output> </xdw:taskData> <xdw:taskEventHistory> <xdw:taskEvent> <xdw:id>201</xdw:id> <xdw:eventTime>2011-03-29T09:20:01.0Z</xdw:eventTime> <xdw:identifier>urn:oid:220.127.116.11.6</xdw:identifier> <xdw:eventType>create</xdw:eventType> <xdw:status>IN_PROGRESS</xdw:status> </xdw:taskEvent> <xdw:taskEvent> <xdw:id>202</xdw:id> <xdw:eventTime>2011-04-01T03:15:20.0Z</xdw:eventTime> <xdw:identifier>urn:oid:18.104.22.168.7</xdw:identifier> <xdw:eventType>complete</xdw:eventType> <xdw:status>COMPLETED</xdw:status> </xdw:taskEvent> </xdw:taskEventHistory> </xdw:XDWTask> </xdw:TaskList> </xdw:XDW.WorkflowDocument>
Figure 5.4.4-1: Sample XDW Workflow Document
5.4.5 Workflow Document Management
22.214.171.124 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
- 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.
126.96.36.199 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:
- 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.
188.8.131.52 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].
184.108.40.206 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
- 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.
220.127.116.11 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.
18.104.22.168 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.
22.214.171.124 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.
126.96.36.199 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
188.8.131.52 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 184.108.40.206.
Table 220.127.116.11-1: XDW Constraints for Document Metadata Attributes
|DocumentEntry Attribute||XDW Constraints|
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|
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:
(See Section 18.104.22.168.)
Each XDW Workflow Document shall have the following value for the formatCode attribute:
|hash||No special requirements for Workflow Document|
|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|
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
CXi.5 shall contain
|repositoryUniqueId||No special requirements for Workflow Document|
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|
22.214.171.124 XDS SubmissionSet Metadata
No additional constraints. See Section 126.96.36.199.
188.8.131.52 XDS Folder Metadata
No additional constraints.