30 Cross-Enterprise Document Workflow Content Profile (XDW)

The Cross-Enterprise Document Workflow (XDW) Profile enables participants in a multi-organizational environment to manage and track the tasks related to patient-centric workflows as the systems hosting workflow management applications coordinate their activities for the health professionals and patients they support. XDW builds upon the sharing of health documents provided by other IHE profiles such as XDS, adding the means to associate documents conveying clinical facts to a patient-specific workflow. XDW provides a common interoperability infrastructure upon which a wide range of specific workflow definitions may be supported. It is designed to support the complexity of health services delivery with flexibility to adapt as workflows evolve.

This profile defines an instrument, called a “Workflow Document”, to manage and track a shared workflow. It records the creation of tasks and maintains a historical record of tasks as they move through the associated workflow. The Workflow Document also maintains the references to health information input and output associated with each task. Such shared workflow status information allows the various participating systems to coordinate by:

• being aware of the history of a workflow for a patient;
• obtaining and reading the workflow’s incomplete tasks;
• updating this shared document as the workflow tasks are performed according to a referenced workflow definition.

XDW provides to offer a common, workflow-independent interoperability infrastructure that:

• provides a platform upon which a wide range of specific workflows can be defined with minimal specification and applications implementation efforts on the workflow definition (e.g., Medical Referrals Workflow, Prescriptions Workflow, Home Care Workflow);
• benefits many clinical and non-clinical domains by avoiding different competing approaches to workflow management;
• increases the consistency of workflow interoperability, and enables the development of interoperable workflow management applications where workflow-specific customization is minimized;
• facilitates the integration of multi-organizational workflows with the variety of existing workflow management systems used within the participating organizations;
• offers the necessary flexibility to support a large variety of different healthcare workflows by not being overly constrained.

More specifically XDW supports workflows that are:

• patient-centric;
• based on business/clinical needs which are defined externally to the XDW Profile. Such workflow definitions have to be known only by the applications within the participating systems, not by the infrastructure systems;
• executed in loosely connected, distributed environments, where centralized workflow management systems are not desired, or in many instances, possible.

The XDW Workflow Architecture illustration (Figure 30-1) shows how the sharing of XDW Documents between “edge” applications using Document Sharing infrastructure supports the management of Workflow according to Workflow Definitions established between participating applications.

This Profile has been updated by the Cross-Enterprise Document Workflow Extension for Cross-Community Environments (XDW for XCA and XCDR) Supplement.

30.1 XDW Actors, Transactions, and Content Modules

The XDW Content Profile is based on three actors, the Content Creator, the Content Consumer and the Content Updater. Content is created by a Content Creator or a Content Updater and is to be consumed by a Content Consumer or a Content Updater. The sharing or transmission of content or updates from one actor to the other is addressed by the use of IHE integration profiles such as XDS, XDM or XDR (see PCC TF-1: 2.1 for a detailed explanation of the use of “Content Profiles” with “Integration Profiles”).

Figure 30.1-1 shows the actors directly involved in the XDW Profile and the direction that the content is exchanged.

A product implementation using this profile must group actors from this profile with actors from a workflow or transport profile to be functional. See Section 30.3 “XDW Actor Groupings and Profile Interactions”.

Table 30.1-1 lists the content module(s) defined in the XDW Profile. To claim support of this profile, an actor shall support all required content modules (labeled “R”) and may support optional content modules (labeled “O”).

Table 30.1-1: XDW Profile - Actors and Content Modules

Actors	Content Modules	Optionality	Reference
Content Creator	XDW Workflow Content Module (see Note 1)	R	ITI TF-3: 5.4
Content Consumer	XDW Workflow Content Module (Note 1)	R	ITI TF-3: 5.4
Content Updater	XDW Workflow Content Module (Note 1)	R	ITI TF-3: 5.4

Note 1: The XDW Workflow Content Module defines how to create an agnostic unstructured Workflow Document. Implementations may also choose to support Content Modules for specific workflows defined by IHE in workflow definition profiles (e.g., profiles in the PCC domain: Cross-Enterprise eReferral Workflow Definition (XBeR-WD), Cross-Enterprise TeleHomeMonitoring Workflow Definition (XTHM-WD), Cross-Enterprise Tumor Board Workflow Definition (XTB-WD), and others.)

30.1.1 XDW Content Creator

The Content Creator is responsible for creating content that will be shared or exchanged between other IHE actors. It is required to be grouped with other actors that perform the actual sharing or exchanging of information (see Section 30.3). The XDW Content Creator shall be able to create new workflows by creating a new XDW Workflow Document as defined in ITI TF-3: 5.4 . This actor is workflow agnostic and it is responsible only for the creation of the first version of the XDW Workflow Document.

30.1.2 XDW Content Consumer

The Content Consumer is responsible for accessing XDW Workflow Documents that have been shared or exchanged between other IHE actors. It is required to be grouped with other actors that perform the actual sharing or exchanging of information (see Section 30.3). The XDW Content Consumer may only obtain and read the last version of a specific XDW Workflow Document. The XDW Workflow Document consumed can belong to any kind of clinical workflow.

30.1.3 XDW Content Updater

A Content Updater shall be able to contribute to existing workflows by consuming an existing XDW Workflow Document and replacing it with an updated Workflow Document. It is required to be grouped with other actors that perform the actual sharing or exchanging of information (see Section 30.3). This actor shall be able to consume and read the most recent version of a specific XDW Workflow Document. The XDW Content Updater shall be able to update the XDW Workflow Document, acting on the content in many different ways (tracking a new task initiated or performed, changing the status of tasks, adding documents reference in some tasks, changing the status of the whole workflow, etc.). After the update, the XDW Content Updater shall be able to replace the previous version of the XDW Workflow Document with the new one. This actor shall be able to solve “race condition” events (see ITI TF-3: 5.4.5.1 ).

30.2 XDW Actor Options

Options that may be selected for this Profile are listed in the Table 30.2-1 along with the actors to which they apply.

Table 30.2-1: XDW - Actors and Options

Actor	Options	Vol. & Section
Content Creator	No options defined	- -
Content Consumer (Note 1)	View Option	ITI TF-1: 30.2.1
	Document Import Option	ITI TF-1: 30.2.2
Content Updater (Note 1)	View Option	ITI TF-1: 30.2.1
	Document Import Option	ITI TF-1: 30.2.2

Note 1: The actor shall support at least one of these options

30.2.1 View Option

A Content Consumer or a Content Updater that supports the View Option shall be able to:

• use the appropriate XD* transactions to obtain the Workflow Document along with associated necessary metadata;
• interpret the content of the Workflow Document and display its required content elements in a way which shows the tasks that are not complete and the completed task in a chronological way. The required elements to display are identified in the “View” column in ITI TF-3: Table 5.4.3-8 and Table 5.4.3-9.
• For each task, it shall list the documents referenced inside the Workflow Document and may optionally support the retrieve and the rendering of the documents referenced inside the Workflow Document.
• Any additional display capabilities that are specific to the referenced Workflow Definition profile may be provided.

30.2.2 Document Import Option

A Content Consumer or a Content Updater that supports the Document Import Option shall support the storage of the entire Workflow Document (as provided by the XD* sharing framework) along with applicable metadata to ensure its later processing. Documents referenced in the Workflow Document may also be stored. This Option requires the proper tracking of the relation between the Documents referenced and the content of the Workflow Document origin. Once a document has been imported, the Content Consumer or the Content Updater shall offer a means to use the document without the need to retrieve it again from the XD* sharing framework. When viewed after it was imported, a Content Consumer and/or a Content Updater may choose to access the XD* sharing framework to find out if the related Document viewed has been deprecated or replaced.

Note: For example, when using XDS, a Content Consumer may choose to query the Document Registry about a document previously imported in order to find out if this previously imported document may have been replaced

30.3 XDW Actor Grouping and Profile Interactions

An XDW Content Creator, Content Updater and Content Consumer shall be grouped with appropriate actors from the XDS, XDM and XDR Profile to exchange XDW Workflow Documents. The metadata used for document entries in document sharing or interchange has specific relationships or dependencies (which we call bindings, see ITI TF-3: 5.4.6 ) to the content of the clinical document – a XDW Workflow Document.

When XDW is used in conjunction with XDS:

• an XDW Content Creator shall be grouped with

• an XDS Document Source;

• an XDW Content Updater shall be grouped with

• an XDS Document Source with the Document Replacement Option;
• an XDS Document Consumer;

• an XDW Content Consumer shall be grouped with

• an XDS Document Consumer.

When XDW is used in conjunction with XDR:

• an XDW Content Creator shall be grouped with

• an XDR Document Source;

• an XDW Content Updater shall be grouped with

• an XDR Document Source;
• an XDR Document Recipient;

• an XDW Content Consumer shall be grouped with

• an XDR Document Recipient.

When XDW is used in conjunction with XDM:

• an XDW Content Creator shall be grouped with

• an XDM Portable Media Creator;

• an XDW Content Updater shall be grouped with

• an XDM Portable Media Creator;
• an XDM Portable Media Importer;

• an XDW Content Consumer shall be grouped with

• an XDM Portable Media Importer.

Note: The support of Workflow spanning XDS, XDR and XDM environments is not explicitly addressed.

30.4 XDW Process Flow

30.4.1 XDW Approach to Workflow

XDW is a core component of a common, workflow-independent interoperability infrastructure that provides a platform upon which a wide range of specific workflows can be defined by “content specialization” with minimal specification and implementation efforts (e.g., Medical Referrals, Prescriptions, Home Care).

This section first describes the overall architecture within which the XDW Profile operates. Next, the structure of the XDW workflow document, the primary data structure that is shared among the workflow participants, is described.

30.4.1.1 XDW Workflow Architecture

A Workflow Definition is structured as a set of logical or clinical tasks definitions and rules. Each task definition describes an activity or a group of activities that needs to be accomplished by the owner of the task. The rules in the workflow definition ensure that the different participants in a workflow operate jointly to advance within process and to move from one task to another in a consistent way.

Figure 30.4.1.1-1 presents an overview of the Workflow Architecture built around the XDW Profile.

In this workflow architecture:

• The first layer supports the sharing or exchange of documents. This interoperability foundation is enabled by a set of existing IHE document sharing profiles such as XDS, XDR and XDM along with document content profiles and security/privacy profiles such as ATNA and (optionally) BPPC.
• The second layer defines a generic data structure called a Workflow Document which is shared among the workflow participants by using the first layer of this architecture. Likewise, the clinical and administrative documents that are used as input and produced as output by the tasks of workflows managed by the XDW Profile are shared using the same first layer of this architecture.
• The third layer introduces the semantic definition of the workflows that can be understood and executed among the participating systems/applications. The orchestration of specific workflows allows the workflow participants to share a common understanding of the specific tasks, the dependencies between these tasks, and a number of rules that control the workflow execution. Execution details are conveyed through the XDW Workflow Document defined by the second layer of the architecture. The specification of Workflow Definitions at this third layer is not part of the XDW Profile and is currently best handled with a natural language expression (See example of Basic Unstructured Workflow Definition Profile, ITI TF-2: Appendix X).
• The fourth layer of this architecture contains the applications executed by the participating systems. Such applications bridge between XDW managed workflow and the locally managed workflow. Much of the details of the local workflows managed by each application will be hidden and encapsulated in “higher” granularity tasks exposed through XDW; as such details would not need to be externally exposed. The workflow definitions conveyed by the third layer should only contain higher granularity tasks that require workflow coordination across organizational boundaries.

30.4.1.2 XDW Document Structure

The XDW Profile uses the XDW Workflow Document to manage workflows.

The XDW Workflow Document enables participants in a multi-organization environment to manage and track the execution of patient-centric workflows. The structure of WorkflowDocument is organized into Tasks and TaskEvents.

A Task describes an activity, or a group of activities, that need to be accomplished or have been accomplished. A Task is characterized by several attributes:

• the type of task,
• the owner of the task,
• the current status of this task (one of the status values that are valid for this task),
• the references to documents used for input or produced as output
• the history of past Task Events for this task, that document the progress of the task up to the present state

When a person or organization has been assigned as owner of a task, the task is placed under execution. (It moves from a “CREATED” or “READY” status to an “IN_PROGRESS” status). When the expected activity(ies) is completed successfully the task moves to the “COMPLETED” status, otherwise to the “FAILED” status (for the state diagram see ITI TF-3: 5.4.2.4 ).

Task Event is a record of a change (status and/or other attribute) of a task; a Task Event history is the list of Task Events for a specific task.

As shown in the Figure 30.4.1.2-1, the XDW Workflow Document is structured into two parts:

• a first part with general workflow information about the document, 
• a second part that collects the different Tasks that are completed or not yet completed in the workflow, as well as for each task, the related Task Events that tracks its progress. Task and Task Event specification leverages a proper subset of the task model and specification from the OASIS Human Task, a standard closely related to well-known workflow standards such as BPEL and BPMN.

The Task and Task Events include references to clinical or administrative input/output documents to the Task or Task Event:

• The Input attribute contains references to documents that are relevant for workflow participants in performing the Task. For example, for a performed examination, this could contain a reference to a referral request. It may also contain references to "parent" workflows to which this workflow is a "child".
• The Output attribute contains references to documents that were produced as a result of performing this Task. For example, this could contain a reference to a report written by a specialist. It may also contain references to "child" workflows initiated by this workflow as a parent.

At any time, if a participant chooses to update the workflow for a specific patient, it shall either create one (or more) new task or update an existing task and record a past taskEvent. Each update to the Workflow document results in a new instance of the Workflow Document which is published as a replacement. The prior version being replaced is then placed in the status “deprecated” (DocumentEntry availabilityStatus) so that only the newest Workflow Document is active. The technical description of the updating process of the Workflow Document is specified in ITI TF-3: 5.4.5.4 .

When a new Workflow Document is created, the Content Creator assigns it a workflow identifier in the DocumentEntry.referenceIdList metadata attribute and in the workflow document. This workflow identifier does not change during the evolution of the workflow itself, and allows the grouping of all the XDW Workflow Documents that belong to the same instance of workflow.

All subsequent replacement workflow documents also carry the same workflow identifier so that this identifier provides a stable reference to an instance of a workflow, while the Workflow Document DocumentEntry.uniqueId is different for each version of the workflow document.

30.4.2 XDW Use-Cases and Process Flow in an XDS Affinity Domain

A broad range of use cases may be supported by the XDW Content Profile.

The purpose of this section is to describe a typical use of XDW with no intent to present the breadth and flexibility of XDW. The use case described in this section provides the necessary background to the reader in understanding the basic capabilities of XDW.

This use case is not intended as a Workflow Definition Profile specification. Such Profiles are being developed by clinical IHE Domains in order to support their specific workflows.

30.4.2.1 Referral Workflow Use Case - Overview

This workflow is a three-step process:

1. a physician refers a patient to another healthcare provider for a specialist’s consultation;

2. the specialist starts the consultation which may span one or more visits
3. the specialist completes the consultation and produces a report.

Each step will be described both from a clinical and a technical point of view.

The description will rely on two figures:

• Figure 30.4.2.2-1 represents the evolution of the Workflow Document during this Referral workflow. Each one of the three steps A, B, C is depicted in a column.
• Figure 30.4.2.2-2 is a sequence diagram of the transactions between “system actors” in the sharing of the Workflow Document as it is updated, using an infrastructure based on the XDS Profile (although not shown here, this use case could be transposed on the XDR or XDM Profiles).

30.4.2.2 Referral Workflow Use Case - Step by Step

We present below the detailed chronological sequence of steps:

1. A physician refers a patient to another healthcare provider for a specialist’s consultation

In this task, the GP examines the patient and reviews the patient’s most recent laboratory report. The GP refers the patient to a specialist, creating an eReferral Document and referencing the laboratory report.

The GP’s software, as Content Creator, produces the e-Referral Document and one Workflow Document to track the clinical workflow of the eReferral. As shown in column A of Figure 30.4.2.2-1, at this moment the Workflow Document created has only one task (“Referral Requested”) characterized by:

• a task status “COMPLETED”
• as inputs of the task the references to the laboratory report analyzed by the GP
• as outputs of the task the reference to the eReferral document produced.

In order to share the documents that are produced during the task, the GP’s Software (as a grouped Content Creator and XDS Document Source) submits the eReferral Document and the Workflow Document to the XDS Document Repository as shown in box A of Figure 30.4.2.2-2.

2. The specialist starts the consultation which may span one or more visits

In this task, the patient goes to the specialist of his choice (or suggested by his GP).

The specialist consults the eReferral document and the associated Workflow Document to understand the task that needs to be performed.

The specialist accesses the document by using his software, which is a grouping of a Content Updater and an XDS Document Consumer, to query and retrieve the Workflow Document and the eReferral document, as shown in box B of Figure 30.4.2.2-2.

If consistent with the Workflow Definition referenced in the Workflow Document, the specialist accepts the patient and updates the Workflow Document so that no other specialist may perform the consultation.

As shown in column B of Figure 30.4.2.2-1, at this step of the workflow, the Workflow Document is updated with a new version in which a new task “Referral Referred” is added to the content of the previous version of the Workflow Document. The task “Referral Referred” is characterized by:

• a task status “IN_PROGRESS”
• as inputs of the task the references to the eReferral document produced by the GP

The Specialist’s software, as a Content Updater and an XDS Document Source, provides the updated version of Workflow Document to the XDS Document Repository/Registry through a Replace of the previous version of the Workflow Document (see box B in Figure 30.4.2.2-2).

3. The specialist completes the consultation and produces a report

The specialist ends the consultation, and he produces a report of the consultation.

In this task, the software of the specialist, as a Content Updater, updates the Workflow Document changing the status of the “referred” task.

As shown in column C of the Figure 30.4.2.2-1 the Workflow Document, the “Referral Referred” task is characterized by:

• a task status “COMPLETED”
• as inputs of the task the references to the eReferral document produced by the GP (the laboratory report was not used by the specialist)
• as output of the task the references to the report of the consultation

The history of the changes of the statuses of the task is tracked inside the task as a list called taskEventHistory.

The Specialist’s software, as a Content Updater and Document Source, provides the updated version of Workflow Document to the Document Repository through a replace of the previous version of the Workflow Document (see box C in Figure 30.4.2.2-2).

At any time, the GP may review the Workflow Document and the new documents produced related to this workflow. This is accomplished through a query and retrieve by the GP’s software of the active Workflow Document from the XDS Document Registry and the XDS Document Repository.

Although not shown in this use case, it would also be possible to manage a system of subscription and notification to communicate the progress between the different steps through the use of the Document Metadata Subscription (DSUB) Profile.

30.5 XDW Security Considerations

The XDW Content Profile relies on the security controls in the underlining transport (e.g., XDS). The XDW content is an administrative document that should not include clinical information but administrative information can be just as sensitive as clinical information.

The XDW Workflow Document will be authored by different organizations. As the document is updated the active version will be replaced with a newer version as the workflow progresses. However, with clinical documents it is not expected that organizations will replace documents authored by other organizations, as typically a clinical document comes from only one organization or individual. Therefore, in order to adhere to the principle of least privilege, organizations want to prevent clinical documents from being replaced by other organizations, while allowing XDW Workflow Documents to be replaced. It is recommended that organizations retain general restrictions on XDS documents, but make an exception for XDW Workflow Documents, based on classCode.

When a Workflow Description Profile is created a risk assessment following the Security Cookbook may result in additional security considerations beyond those for the usual clinical report.

30.6 Cross-Profile Considerations

The XDW Profile and actors rely on an XDS document sharing infrastructure. The need for a fixed reference to the whole workflow (workflow identifier) requires that XDW actors operate in an XDS affinity domain where the XDS Document Registry supports the Reference ID Option. For more details about this option, see Section 10.2.6.