XDW

Proposal for a generic technical specificationShown by Pharmacy use-case as an example

Jürgen Brandstätter

Goals• Completely generic and neutral

– Clear separation between XDW and domain which uses it• Don‘t touch the clinical documents involved in the workflow

– Because we want to strictly separate workflow from clinical content– Clinical documents can be involved in many workflows (who of these would have the

„right“ to touch the clinical documents? -> Problem!)• Fast filtering of the vast majority of „completed“ workflows by just registry

access (no retrieve of documents), but also …– … avoid complex re-query scenarios

• For example: first the clinical document, then the workflow document related to it

– … avoid the need of new XDS queries• For covering this above in an atomic transaction• It will be hard to get them from ITI

– … avoid the need of new XDS document metadata• If they are not optional it‘s hard to get them from ITI• If they are optional interoperability is reduced (because you restrict to components which can deal

with these optional ones)

• Avoid document associations since these bind us to XDS– … and they pollute the clear separation of content and workflow

A sample workflowPRE with 3 items

Part of

Also part of

PADV DIS

Part of Part of

Workflow of CMPD Profile

Workflow of other Profile (e.g. Nursing, whatever, …)

WorkflowDocument

Metadata of Workflow DocumentPRE with 3 items

Part of

PADV DIS

Part of Part of

Workflow of CMPD Profile

WorkflowDocument

classCode set with code identifying a Workflow documente.g. 99999-9, Workflow Document, LOINC

Defined by the XDW Profile (for all domains building on top of XDW)

formatCode set with URN identifying the specific workflowe.g. urn:ihe:pharm:cmpd:xdw:workflow1

“CMPD Workflow Document for workflow 1”Defined by the CMPD Profile (used in PHARM domain only)

serviceStopTime indicates the end of the workflow

Empty: workflow is still ongoing, end date unknownDate in the future: workflow still ongoing but determined end already knownDate in the past: workflow completed

serviceStartTimeindicates the start of the workflow

This dedication of metadata slots is valid,

because we constraint the „workflow

document“ only!

(which is under authority of the XDW profile)

Content of Workflow DocumentPRE with 3 items

Part of

PADV DIS

Part of Part of

Workflow of CMPD Profile

WorkflowDocument

Linkage to the document by uniqueId and homeCommunityId

Domain and workflow specific information like „status“, etc.Struture defined in XDW, content defined in the PHARM profile for

fulfilling the requirements of the pharmacy workflow

Who specifies what?XDW

• Dedication of metadata slots of workflow document

• formatCode• serviceStartTime• serviceStopTime

• Structure of content of workflow document– According to some standard

• OASIS Human Task?• CDA?

Domain profile (e.g. CMPD) using XDW

• Content of metadata slots of the workflow document– formatCode to identify the

specific workflow– When to set start and end of

workflow

• Content of workflow document– Domain specific needs have to

be put into the XDW structure of the workflow document

Advantages 1

• Generic and neutral approach– No domain specific knowledge in XDW

• Clinical documents don’t have to be touched, neither in content nor metadata– Clean separation between workflow and clinical documents– Workflow documents acting like a “glue” between the clinical

content– Clinical documents can be part of many workflows

• Workflow documents are clearly identified by classCode for being able to filter them out in standard document queries– since they are not clinical documents they should be not part of the

result set)

Advantages 2• Fast filtering of the vast majority of „completed“ workflows by just

registry access– No complex re-query scenarios– No new XDS queries– No new XDS document metadata– Workflow by its “workflow document” by an unique formatCode and that allows

the following procedure:• Domain specific transactions are able to query for „their“ workflow documents only (with

standard ITI-18)– Example: „PHARM-1, Query Pharmacy documents“ would filter for

formatCode= urn:ihe:pharm:cmpd:xdw:workflow1

• By serviceStopTime of the workflow document they can filter out all „completed“ ones already on query level– serviceStopTime = empty or date in the future

• The remaining ones are possible interesting – so it’s no loss to retrieve all remaining workflow documents to get the uniqueId and homeCommunityId of all currently related documents of the workflow

• Dependent on the semantics of the transaction it “knows” what to do with this information– E.g. further sub-filtering, etc.

Advantages 3• No technical associations needed from workflow document to its

relating documents is necessary– Just semantic linkage in the workflow document– No folder scenario necessary– No document associations necessary– Consequences:

• Could work also in XCA scenarios!– Workflow documents could even reside in own domains

• XDW does not require some documents to be a “start point” of the workflow

• Triggering of sub-workflows possible– By relating to them semantically in the “content” of the workflow document

• Concept sufficient for “documenting” the steps of a workflow (as a first step) but does not hinder more– Later enhancements to also “predicting” or “demanding” workflow steps are

not hindered by the concept

What do you think of it?

• Questions / open issues:– It would work for Pharmacy CMPD, but is it

generic enough for other domains?– The concept depends on finding a content

structure which is sufficient to carry uniqueId and homeCommunityId for doing semantic linkage to the related clinical documents