Appendix X: Basic Unstructured Workflow Definition Example

This appendix contains a Workflow Definition example that is intended to be used in conjunction with XDW Profile.

X.1 Workflow definition identifier

Basic Unstructured Workflow is a very simple workflow in which a group of physicians/organizations acts on the same patient in an a priori unpredictable way.

This workflow is performed to allow the continuity of care for a patient in a generic and flexible way.

We expect actual deployment to modify this example when developing basic workflows. It has two simple types of Tasks: the first one is useful for recording and sharing single user actions (“ I did this task” ) and the second one used to request that a task be performed by another organization and reporting its completion ( “please do this,  I did it” ).

Any specific workflow can include any combination of these two types of tasks. This example shows no dependencies among the tasks that are explicitly managed.

The catalog of task that maybe used in this workflow definition is not specified by this profile, and remains to be agreed in the affinity domain where the workflow is been deployed. This definition will result in a list of names and codes for any potential task.

X.2 Workflow definition identifier

The workflow definition identifier shall be inserted into the workflowDefinitionReference element of the Workflow Document.

Workflow Definition name	workflowDefinitionReference
Basic Unstructured Workflow	An “urn:oid” reference to a Workflow definition Document

X.3 Workflow opening and closing

The workflow should be opened by a physician or an Organization that participates in the workflow (e.g., continuity of care process). Any participant may choose to close the workflow.

X.4 Tasks descriptions

X.4.1 Task type “born completed”

Tasks of the type “born completed” are used by any workflow participant when the workflow is open or at any later point in time. This type is used for a workflow in which a participant want to share some actions perform in his enterprise on the patient. Typical examples can be a visit, or an emergency admission, or a patient self-monitoring event.

Task attributes	Rules for the task “born completed”
Task dependencies	none
States allowed	COMPLETED
States transactions	None
input	Zero or more clinical document of unconstrained types
output	Zero or more clinical document of unconstrained types
owner	every physician/organization
owner changes	No
<taskEvent>	Only one

 

X.4.2 Task type “two states task”

This type of task is used by any workflow participant when the workflow is open or at any later point in time. This task type is used for a workflow in which a participant wants to share some actions performed in his enterprise on the patient. Typical examples can be a visit, or an emergency admission, or a patient self-monitoring event.

Task attributes	Rules for the task “two states task”
Task dependencies	None
States allowed	CREATED COMPLETED
States transactions	When a workflow participant request that this task be performed by another workflow participant he places the task in a Workflow Document with CREATED status (no owner). When the requested task is performed by a participant the task status shall be COMPLETED.
input	Zero or more clinical document of unconstrained types (e.g., eReferral Document, ePrescription)
output	Zero or more clinical document of unconstrained types (e.g., reports, radiological images, advice documents, dispensation documents)
owner	any physician/organization that process this task in CREATED state
changes of task owner	Allowed
<taskEvent>	At least two