XDW Proposal for a generic technical specification Shown by Pharmacy use-case as an example

1. XDWProposalfor a generictechnicalspecificationShownby Pharmacy use-caseas an example Jürgen Brandstätter

2. Goals • Completelygenericand neutral • Clear separationbetween XDW anddomainwhichusesit • Don‘ttouchtheclinicaldocumentsinvolved in theworkflow • Becausewewanttostrictly separate workflowfromclinicalcontent • Clinical documentscanbeinvolved in manyworkflows (whoofthesewouldhavethe „right“ totouchtheclinicaldocuments? -> Problem!) • Fast filtering ofthevastmajorityof „completed“ workflowsby just registryaccess (noretrieveofdocuments), but also … • … avoidcomplexre-queryscenarios • Forexample: firsttheclinicaldocument, thentheworkflowdocumentrelatedtoit • … avoidtheneedofnew XDS queries • Forcoveringthisabove in an atomictransaction • It will behardtogetthemfrom ITI • … avoidtheneedofnew XDS documentmetadata • Iftheyare not optional it‘shardtogetthemfrom ITI • Iftheyare optional interoperabilityisreduced (becauseyourestricttocomponentswhichcan deal withthese optional ones) • Avoiddocumentassociationssincethese bind usto XDS • … andtheypollutetheclearseparationofcontentandworkflow

3. A sample workflow PADV PRE with 3 items DIS Part of Part of Part of Workflow of CMPD Profile Workflow Document Also partof Workflow ofother Profile (e.g. Nursing, whatever, …)

4. Metadataof Workflow Document classCodesetwithcodeidentifying a Workflow document e.g. 99999-9, Workflow Document, LOINC Definedbythe XDW Profile (for all domainsbuilding on top of XDW) formatCodesetwith URN identifyingthespecificworkflow e.g. urn:ihe:pharm:cmpd:xdw:workflow1 “CMPD Workflow Document for workflow 1” Defined by the CMPD Profile (used in PHARM domain only) PADV PRE with 3 items DIS Part of Part of Part of Workflow of CMPD Profile Thisdedicationofmetadataslotsis valid, becauseweconstraintthe „workflowdocument“ only! (whichisunderauthorityofthe XDW profile) Workflow Document serviceStartTime indicatesthestartoftheworkflow serviceStopTimeindicatesthe end oftheworkflow Empty: workflowis still ongoing, end dateunknown Date in thefuture: workflow still ongoing but determined end alreadyknown Date in thepast: workflowcompleted

5. Contentof Workflow Document PADV PRE with 3 items DIS Part of Part of Part of Workflow of CMPD Profile Workflow Document LinkagetothedocumentbyuniqueIdandhomeCommunityId Domain andworkflowspecificinformationlike „status“, etc. Struturedefined in XDW, contentdefined in the PHARM profileforfulfillingtherequirementsofthepharmacyworkflow

6. Who specifieswhat? XDW Domain profile (e.g. CMPD) using XDW Contentofmetadataslotsoftheworkflowdocument formatCodetoidentifythespecificworkflow Whentosetstartand end ofworkflow Contentofworkflowdocument Domain specificneedshavetobeputintothe XDW structureoftheworkflowdocument • Dedicationofmetadataslotsofworkflowdocument • formatCode • serviceStartTime • serviceStopTime • Structureofcontentofworkflowdocument • Accordingtosomestandard • OASIS Human Task? • CDA?

7. 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 classCodefor 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)

8. Advantages 2 • Fast filtering ofthevastmajorityof „completed“ workflowsby just registryaccess • Nocomplexre-queryscenarios • Nonew XDS queries • Nonew XDS documentmetadata • 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 forformatCode= 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 homeCommunityIdof 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.

9. 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

10. What do youthinkofit? • 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