1 / 18

XDW in a multi-community environment and back-linking to Workflow Documents

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.

sonia-moody
Download Presentation

XDW in a multi-community environment and back-linking to Workflow Documents

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 The use case: XDW Workflow Document management in a multi-community environment Addressing back-link from any referenced document to Workflow Documents in a single community The WF folder approach No folder approach Addressing back-link from any referenced document to Workflow Documents in multiple communities Back-link: Analysis ofrelevanceandusage

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

  4. Affinity Domain A Affinity Domain B WF-A doc WF-A doc XCA XDW in a multi-community environment(2) Ref doc Ref doc 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 Doc Source Doc Source

  5. Affinity Domain A Affinity Domain B WF-A doc WF-A doc XCA Implementation of XDW in a multi-community environmentExisting XDW/XDS/XCA – create a Multi-domain gateway Ref doc Ref doc 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) Multi-domain Doc Source Proxies Doc Source Doc Source

  6. Affinity Domain A Affinity Domain B WF-A doc WF-A doc XCA Implementation of XDW in a multi-community environmentCreate a New profile for XD-Provide and Register Ref doc Ref doc XCP&R 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) Doc Source Doc Source

  7. XDW in a multi-community environment The use case: XDW Workflow Document management in a multi-community environment Addressing back-link from any referenced document to Workflow Documents in a single community The WF folder approach No folder approach Addressing back-link from any referenced document to Workflow Documents in multiple communities Back-link: Analysis ofrelevanceandusage

  8. WF Folder approach (1) „uniqueId“ ofclinical document Registry Stored Query (ITI-18) GetFoldersForDocument Parameter: uniqueId, code=WF Every returned folder is a „workflow“ Loop over all returned folders i = 1 Loop Registry Stored Query (ITI-18) GetFolderAndContents Parameter: uniqueId of folder(i) Returns DocEntries of WFDoc within Document Retrieve (ITI-43) Parameter: WF doc uniqueId Transaction impact= 1+2*#eWFs -- Client filtering= #eWF+#eWF*#docs-per-WFe.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= 9transactions, and 36 entries to filter

  9. WF Folder approach - Analysis • Advantages • No „Documentretrieve“ necessarytodetermineWFDocsofwhichtheClinicalDocispartof • Anyway „retrieve“ is necessary in the end after right WFDoc is determined • Disadvantages • XDS cost: linear, becausesecondqueryis 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. No Folder approach • 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 „patientId“+ „uniqueId“ ofclinicaldocument Retrieve Document Set (ITI-43) Retrieve all foundWFDocs Loop over all retrieved WFDocs i = 1 Loop Parse WFdoc and search for „uniqueId“ of clinical document „uniqueId“ found in WFDoc? Clinical document is part of that workflow -> WFdoc already retrieved Clinical document is not part of that workflow -> Ignore no yes Transaction impact= 1+#rWFs -- Client filtering= #rWF+2*#rWF*#docs-per-WFe.g. a patient with 10 active WFs , 5 relevantWF and 8 docs per WF= 6 transactions, and 90 entries (duplIn&out) to filter e.g. a patient with 100 active WFs , 20 relevantWF 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, oneRetrieve) • 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) • Atthe end oftheprocesstheWFDoc not onlyfound but alreadyretrieved • Disadvantages • „Documentretrieve“ ofWFDocsisnecessaryfordeterminationof back-link • Riskthatthe „Retrieve“ failsdoesn‘t matter much, because „retrieving“ oftheWFDociscrucialforthepurpose in eitherapproach • Ifsearching „all“ workflows, subsequent loopsmaygrowlarge • Seldomused (see Back-link: Analysis ofrelevanceandusage) • PatientId must beknown • Minorissue, becauseusuallyknownanyway

  12. XDW in a multi-community environment The use case: XDW Workflow Document management in a multi-community environment Addressing back-link from any referenced document to Workflow Documents in a single community The WF folder approach No folder approach Addressing back-link from any referenced document to Workflow Documents in multiple communities Back-link: Analysis ofrelevanceandusage

  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 otherqueries (submissionsets, folders, associations) are optional! • See XCA Supp Rev2, page 38 • No major issue to get the transactions GetFoldersForDocument and GetFolderAndDocumentsoptions 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 usefullwith references to documents in WFDoc containing homeCommunityId

  14. Affinity Domain A Affinity Domain B WF Folder WF-A doc WF-A doc XCA XDW in a multi-community environmentwith back-link based on WF Folder (Reason 1) Ref doc Ref doc 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 Doc Source Doc Source

  15. XDW in a multi-community environment The use case: XDW Workflow Document management in a multi-community environment Addressing back-link from any referenced document to Workflow Documents in a single community The WF folder approach No folder approach Addressing back-link from any referenced document to Workflow Documents in multiple communities Back-link: Analysis ofrelevanceandusage

  16. Back-link: Analysis ofrelevanceandusage • The most common use-case: An actor in a worfklow content profile gets a clinical document to perform a specific workflow step for thisworkflow (1) • e.g. dispensing a prescription, fulfill a lab-order, … • This isoneofthemainpurposesof XDW • Important remark: In this case the actor „knows“ which type of workflow it serves and therefore which „type“ of WFDocs is of interest • … becauseit‘swrittenin theprofilewhichdefinestheactor • e.g. theMedicationdispenserispartoftheworkflowof CMPD whenitshalldispense a prescription • Shouldreturn e.g. the 2 open prescriptionsofthepatient

  17. Back-link: Analysis ofrelevanceandusage • The most common use-case: An actor in a worfklow content profile gets a clinical document to perform a specific workflow step for thisworkflow (2) • e.g. a patient with 100 active WFs, whereas 20 are of this “type” and 2 contain the document (8 docs per WF) • CostWF Folder approach • 9 transactions (because filter by “type” is not possible) • 36 entries to filter client-side • CostNofolderapproach • 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 ofrelevanceandusage • Other use-case: An actorwantstoknow in whichworkflows a givendocumentisinvolved • 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 workflowtypes • Cost: seepagebefore • 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

More Related