1. XDW in a multi-community environment and back-linking to Workflow Documents A high-level analysis to avoid design choices that would make XDW Trial Implementation (single community) difficult to be extended to multiple communities Brainstorming from Luca, Jurgen and Charles in progress

2. XDW in a multi-community environment 1.The use case: XDW Workflow Document management in a multi-community environment 2.Addressing back-link from any referenced document to Workflow Documents in a single community 1.The WF folder approach 2.No folder approach 3.Addressing back-link from any referenced document to Workflow Documents in multiple communities 4.Back-link: Analysis of relevance and usage

3. Affinity Domain A XDW in a multi-community environment(1) Workflow initiated by Doc Source in Affinity Domain A. WF doc and one output doc provided and registered in AD A. Affinity Domain A WF-A doc Doc Source Ref doc Doc Source XCA

4. Affinity Domain AAffinity Domain B WF-A doc Ref doc Ref doc WF-A doc XDW in a multi-community environment(2) Doc Source Doc Source Next workflow step performed by Doc Source in Affinity Domain B. One output doc provided and registered in AD-B. Updated WF document needs to be registered as “replacement” of previous WF doc in AD-A where is registry tracking initial WF document.  A cross-community provide and register is needed  A cross community document referencing mechanism is needed XCA

5. Affinity Domain AAffinity Domain B WF-A doc Ref doc Ref doc WF-A doc Implementation of XDW in a multi-community environment Existing XDW/XDS/XCA – create a Multi-domain gateway Doc Source Doc Source  A cross-community provide and register is provided through a “Multi-domain doc source proxy”  A cross community document referencing mechanism is needed: perform an XCA Query (with doc OID) XCA Multi-domain Doc Source Proxies

6. Affinity Domain AAffinity Domain B WF-A doc Ref doc Ref doc WF-A doc Implementation of XDW in a multi-community environment Create a New profile for XD-Provide and Register Doc Source Doc Source  A cross-community provide and register is needed: create a new profile.  A cross community document referencing mechanism is needed: perform an XCA Query (with doc OID) XCA XCP&R

7. XDW in a multi-community environment 1.The use case: XDW Workflow Document management in a multi-community environment 2.Addressing back-link from any referenced document to Workflow Documents in a single community 1.The WF folder approach 2.No folder approach 3.Addressing back-link from any referenced document to Workflow Documents in multiple communities 4.Back-link: Analysis of relevance and usage

8. Loop WF Folder approach (1) „uniqueId“ of clinical document Registry Stored Query (ITI-18) GetFoldersForDocument Parameter: uniqueId, code=WF Every returned folder is a „workflow“ Registry Stored Query (ITI-18) GetFolderAndContents Parameter: uniqueId of folder(i) Returns DocEntries of WFDoc within Loop over all returned folders i = 1 Document Retrieve (ITI-43) Parameter: WF doc uniqueId Transaction impact= 1+2*#eWFs -- Client filtering= #eWF+#eWF*#docs-per-WF e.g. a patient with 10 active WFs, 2 effective WF and 8 docs per WF= 5 transactions, and 18 entries to filter e.g. a patient with 100 active WFs, 4 effective WF and 8 docs per WF= 9 transactions, and 36 entries to filter

9. WF Folder approach - Analysis Advantages – No „Document retrieve“ necessary to determine WFDocs of which the ClinicalDoc is part of Anyway „retrieve“ is necessary in the end after right WFDoc is determined Disadvantages – XDS cost: linear, because second query is in a loop But loop is most likely not large (except if document is part of many workflows) Filtering out of closed workflows takes place based on retruned document metadata

10. Loop No Folder approach „patientId“+ „uniqueId“ of clinical document Registry Stored Query (ITI-18) FindDocuments Parameters: patientId classCode=WFDoc Optional: serviceStopTime for just „active ones“ Every returned DocEntry (WFDoc) could contain a reference to the clinical document Retrieve Document Set (ITI-43) Retrieve all found WFDocs Loop over all retrieved WFDocs i = 1 „uniqueId“ found in WFDoc? Clinical document is part of that workflow -> WFdoc already retrieved Clinical document is not part of that workflow -> Ignore yes no Parse WFdoc and search for „uniqueId“ of clinical document Transaction impact= 1+#rWFs -- Client filtering= #rWF+2*#rWF*#docs-per-WF e.g. a patient with 10 active WFs, 5 relevant WF and 8 docs per WF= 6 transactions, and 90 entries (dupl In&out) to filter e.g. a patient with 100 active WFs, 20 relevant WF and 8 docs per WF= 21 transactions, and 340 entries to filter

11. No Folder approach - Analysis Advantages – XDS cost: constant (always just one Query, one Retrieve) – Filtering (Doc Consumer) of „relevant“ workflows at first query cut subsequent costs In query select „active workflows“ Costs can be even reduced by additional selection of workflow „types“ These are the most likely use-case (see Back-link: Analysis of relevance and usage) – At the end of the process the WFDoc not only found but already retrieved Disadvantages – „Document retrieve“ of WFDocs is necessary for determination of back-link Risk that the „Retrieve“ fails doesn‘t matter much, because „retrieving“ of the WFDoc is crucial for the purpose in either approach – If searching „all“ workflows, subsequent loops may grow large Seldom used (see Back-link: Analysis of relevance and usage) – PatientId must be known Minor issue, because usually known anyway

12. XDW in a multi-community environment 1.The use case: XDW Workflow Document management in a multi-community environment 2.Addressing back-link from any referenced document to Workflow Documents in a single community 1.The WF folder approach 2.No folder approach 3.Addressing back-link from any referenced document to Workflow Documents in multiple communities 4.Back-link: Analysis of relevance and usage

13. Back-link in multiple communities WF Folder approach – The use of folders XDW poses serious constraints in multi-domain scenarios Reason 1: The Folder concept require that all documents referenced in a WF be referenced in WF folder (= in one XDS affinity domain) – This constraint is not wanted in multi-domain scenarios, as itwould disrupt any policies on choices of repositories with affinity domains. Reason 2: XCA defines only handling of FindDocument and GetDocuments as mandatory – All other queries (submission sets, folders, associations) are optional! » See XCA Supp Rev2, page 38 – No major issue to get the transactions GetFoldersForDocument and GetFolderAndDocuments options supported accross XCA communities. – The use of folders by document sources requires only creation of the folder when WF is initiated. Replace automatically manages folders. No Folder approach – Same transaction flow as in single domain scenario (Just use XCA to query and retrieve WFDocs) – Given WF Doc structure, how quick is it to parse it for referenced documents ? Note: Multi-domain optimization would be usefull with references to documents in WFDoc containing homeCommunityId

14. Affinity Domain A WF Folder Affinity Domain B WF-A doc Ref doc Ref doc WF-A doc XDW in a multi-community environment with back-link based on WF Folder (Reason 1) Doc Source Doc Source Next workflow step performed by Doc Source in Affinity Domain B. One output doc provided and registered in AD-B. Updated WF document needs to be registered as “replacement” of previous WF doc in AD-A where is registry tracking initial WF document (done automatically by registry).  Reference doc in AD-B in a folder managed in AD-A. This is not supported today !! Seems challenging XCA

15. XDW in a multi-community environment 1.The use case: XDW Workflow Document management in a multi-community environment 2.Addressing back-link from any referenced document to Workflow Documents in a single community 1.The WF folder approach 2.No folder approach 3.Addressing back-link from any referenced document to Workflow Documents in multiple communities 4.Back-link: Analysis of relevance and usage

16. Back-link: Analysis of relevance and usage The most common use-case: An actor in a worfklow content profile gets a clinical document to perform a specific workflow step for this workflow (1) – e.g. dispensing a prescription, fulfill a lab-order, … – This is one of the main purposes of XDW – Important remark: In this case the actor „knows“ which type of workflow it serves and therefore which „type“ of WFDocs is of interest … because it‘s written in the profile which defines the actor – e.g. the Medication dispenser is part of the workflow of CMPD when it shall dispense a prescription – Should return e.g. the 2 open prescriptions of the patient

17. Back-link: Analysis of relevance and usage The most common use-case: An actor in a worfklow content profile gets a clinical document to perform a specific workflow step for this workflow (2) – e.g. a patient with 100 active WFs, whereas 20 are of this “type” and 2 contain the document (8 docs per WF) Cost WF Folder approach – 9 transactions (because filter by “type” is not possible) – 36 entries to filter client-side Cost No folder approach – 21 transactions (because filter by “type” is possible) – 340 entries to filter client-side  Is the Folder worth the optimization gain and cros- domain challenge ?

18. Back-link: Analysis of relevance and usage Other use-case: An actor wants to know in which workflows a given document is involved – Case 1: The actor „knows“ a specific set of types of workflows and wants to check, if the document is part of one of them and therefore processable by this actor This is a variant of the prior scenario with multiple workflow types Cost: see page before – Case 2: The actors does „not“ know the workflows returned in which doc is involved and just asks to „see“ the set of workflows Need to research if that this type of question is asked being specific to a document. Cost: like on pages 8 and 10