XDW Proposal for a generic technical specification Shown 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 workflow PRE with 3 items Part of Also part of PADV DIS Part of Workflow of CMPD Profile Workflow of other Profile (e.g. Nursing, whatever, …) Workflow Document Workflow Document

Metadata of Workflow Document PRE with 3 items Part of PADV DIS Part of Workflow of CMPD Profile Workflow Document Workflow Document classCode set with code identifying a Workflow document e.g , Workflow Document, LOINC Defined by the XDW Profile (for all domains building on top of XDW) formatCode set with URN identifying the specific workflow e.g. urn:ihe:pharm:cmpd:xdw:workflow1 “CMPD Workflow Document for workflow 1” Defined by the CMPD Profile (used in PHARM domain only) classCode set with code identifying a Workflow document e.g , Workflow Document, LOINC Defined by the XDW Profile (for all domains building on top of XDW) formatCode set with URN identifying the specific workflow e.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 unknown Date in the future: workflow still ongoing but determined end already known Date in the past: workflow completed serviceStopTime indicates the end of the workflow Empty: workflow is still ongoing, end date unknown Date in the future: workflow still ongoing but determined end already known Date in the past: workflow completed serviceStartTime indicates the start of the workflow serviceStartTime indicates 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) 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 Document PRE with 3 items Part of PADV DIS Part of Workflow of CMPD Profile Workflow Document Workflow Document 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 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