Extending XDW in Cross-Community

1. Extending XDW in Cross-Community Editor: Charles Parisot Notes for the March 19th, 2013 – ITI Tech Committee

2. Analyzed the two main alternatives: • Sacrifice partitionability. • Sacrifice consistent responses. It was decided to sacrifice partitionability, because inconsistent responses for workflow management can lead to unpredictable situations in health delivery. For details see next two slides.

3. Further details on a/ and b) approach • Working paper from Rob Horn used to drive the analysis on the previous slide.

4. Deployment Models 1 - XDW WF Document located in any affinity domain where initially created  Needs extensions 2 – XDW WF Documents located in a separate affinity domain. All XDW Doc Creators/Consumers/Updaters access this shared ‘WF domain” in addition to another Affinity Domain where referenced documents are shared.  Does not need extensions, but more complex end systems

5. Document Registry Document Registry Document Repository (External Docs) ITI Document Register 2 1 - XDW WF Document located in any affinity domain where initially created (a) Receiving Gateway 5 Document Repository Initiating Gateway 2 ITI Stored Query 4 ITI Document Set Retrieve Ref Doc XDW Doc 5 3 3 ITI Stored Query ITI Document Set Retrieve 1 ITI Provide & Register Document Consumer Document Source 1 Document Source 4 1 & 2 - When an XDW document is initially created (along with a referenced document), the XDW document remains under the control of a single XDS Registry for its entire life-cycle (replacement, folder if used, race condition detection). 3, 4 & 5 – A document consumer in an other Affinity Domain discover a workflow of interest through the XCA profile. The document consumer may also accessed referenced documents (XDW document needs to store the HomeCommunity ID along with the referenced UUID or extend XCA to discover a referenced document across affinity domain by ID or UUID). Affinity Domain B Affinity Domain A

6. Document Registry XDW Doc Document Registry/Repository 9 Document Repository (External Docs) ITI Document Register Ref Doc 8 ITI Provide & Register 2 1 - XDW WF Document located in any affinity domain where initially created (b) Receiving Gateway 5 Document Repository Initiating Gateway ITI Provide & Register 2 ITI Stored Query 4 6 ITI Document Set Retrieve Ref Doc XDW Doc 7 5 3 3 ITI Stored Query ITI Document Set Retrieve 1 ITI Provide & Register Document Consumer Document Source 1 Document Source 4 6 -The document consumer may create a new document referenced in an updated XDW document. 7, 8 & 9 - The document consumer in affinity domain B replaces the previous XDW document , that is stored in the remote affinity domain A that remains under the control of a single XDS Registry for its entire life-cycle (replacement, folder if used, race condition detection). A new XCR profile covers transactions 7, 8 and 9. It extends the cross-domain capabilities: Cross-Domain Provide and Register an XDW doc. “XCR” is based on the XDR transactions that need to be extended to convey the HomeCommunity Id, where the updated XDW needs to be updated. Open Issues: See Next Slide Affinity Domain B Affinity Domain A

7. 1 - XDW WF Document located in any affinity domain where initially created (cont’nd)HomeCommunity Id in XDR - Open Issue ITI-41 (P&R) needs to includes HomeCommunity Id (eb-Attribute or SOAP header)? As in Query/retrieve in home attribute ? Home attribute is present in every “extrinsic objects” Id. It Does Home attribute (exists in every identifiable object type) in P&R exists in P&R Doc Set request, Registry Object List = not identifiable object in Submit Object Request. = not identifiable object Registry Package ebXML Object (= XDS Submission Set). It is identifiable and only one is present per P&R Recommends to take #4 as the highest level and has an identifiable object type ? How does ITI-41 sender knows SOAP end point ? The initiating GW (or a configuration in the Receiving GW in the receiving affinity domain) Need to have Home Community Id in the Doc Ref in XDW Doc or if absent the ref doc is in the same home community as the XDW document. (sources need to know their own home community ID). Make it “required if known”. Should it be a shall when ref docs is in different domain than XDW doc ? Need to look at other documents that are not at all electronically reachable. No better no worse.

8. Document Repository Document Registry Document Repository Document Registry 2 1 ITI Document Register Ref Doc Ref Doc Initiating Gateway Receiving Gateway ITI Stored Query 5 ITI Provide & Register 2 1b 6 ITI Document Set Retrieve 2 - XDW WF Documents located in a separate affinity domain. 4 ITI Provide & Register 5 3 ITI Stored Query ITI Document Set Retrieve 1 Document Source Document Consumer Document Source 4 Affinity Domain B Affinity Domain A Document Source Document Consumer (option if not XCA to adC Document Source Document Repository XDW Doc ITI Document Register Affinity Domain C is dedicated to the sharing and update of XDW documents. This requires each Document Source that actively updates the XDW needs to be on both the Affinity Domain A or C. There is no need for a new XCR profile to extend the cross-domain capabilities Open Issues: Reference Document need the Home Community Id to access ref documents. XDW Doc 4 XDW Doc 1a 8 2 ITI Provide & Register 7 Document Registry 3 ITI Document Register Affinity Domain C ITI Stored Query

9. Deployment Models Offer both models. 1 - XDW WF Document located in any affinity domain where initially created 2 – XDW WF Documents located in a separate affinity domain. All XDW Doc Creators/Consumers/Updaters access this shared ‘WF domain” in addition to another Affinity Domain where referenced documents are shared. Should we offer a third model ? 3 – Keep the Workflow where created (WF source affinity domain) and expects that workflow contributors are members of the affinity domains of their “workflow customers” This is a degenerate case of Model 1 and Model 2. Model 2 and 3 may need “declared options” in XDW Doc Content updaters on the way they are grouped with XD* Actors (on egde systems needed). “XCF” is applicable beyond XDW.

10. 5 - Policies issues • Cross-domain Vocabulary, incl. Metadata • Check list of item to do, coding of tasks (already in WD). Good practice in WD profiles specs and deployment check lists. • Privacy/Security policies • Explain how BPPC applies: authorization to update across domains (so far only within own domain). • Limited to WF docs ? (explain the technical: doc class, error codes) • Explain use of “XUA in XDR”. Unknown user ids ? No different than is XCA queries, but applied on XDR.

11. Need a decision on Folders vs WF number in XDW • Should we create an XDW CP on use of Folder vs workflow Id versus folding this into this supplement ? • This XDW CP is distinct but conditional on the XD* CP659.

12. Documentation Structure Current XDW Supplement Create 2 new supplements and one CP Reference use of CP XXX and CP 659 CP XXX XDW Change use of folder to workflow Id Add use of XCR and XCA CP 659 Workflow Id in Metadata Annex: Deployment models for XDW XCR Supplement (Or CP YYYY on XDR to add the directed HomeCommunity Id ?) Extend XDW to cross domain deployment

13. Next Steps • Document deployment models • Analyze them and identify issues • “Promote” the cross-community document reliable (XCR) and identify style of documentation (for info, different actors/options, etc) • Create an XDW CP to replace the use of Folder vsby that of workflow Id(Distinct XDW CP but conditional on the XD* CP659 that introduces workflow ID in metadata).