Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "Extending XDW in Cross-Community Editor: Charles Parisot Notes for the March 19 th, 2013 – ITI Tech Committee."— Presentation transcript:

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

2 Analyzed the two main alternatives: 1.Sacrifice partitionability. 2.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 1 - XDW WF Document located in any affinity domain where initially created (a) 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). XDW Doc Ref Doc Document Registry Receiving Gateway Initiating Gateway ITI Stored Query ITI Document Set Retrieve Document Source Document Repository Document Consumer Document Source Document Repository (External Docs) ITI Provide & Register ITI Document Register ITI Stored Query ITI Document Set Retrieve 4 5 Affinity Domain A Affinity Domain B

6 1 - XDW WF Document located in any affinity domain where initially created (b) 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 XDW Doc Ref Doc Affinity Domain A 3 Document Registry Document Registry/Repositor y Receiving Gateway Initiating Gateway ITI Provide & Register ITI Stored Query ITI Document Set Retrieve Document Source Document Repository Ref Doc Document Consumer Document Source Document Repository (External Docs) ITI Provide & Register ITI Document Register ITI Stored Query ITI Document Set Retrieve ITI Provide & Register 7 8 XDW Doc Affinity Domain B

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 1.P&R Doc Set request, 2.Registry Object List = not identifiable object 3.in Submit Object Request. = not identifiable object 4.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 2 - XDW WF Documents located in a separate affinity domain. 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. Ref Doc Affinity Domain A 3 Document Registry Receiving Gateway Initiating Gateway ITI Stored Query ITI Document Set Retrieve Document Source Document Repository Ref Doc Document Consumer Document Source ITI Provide & Register ITI Document Register 1b 2 3 ITI Stored Query ITI Document Set Retrieve ITI Provide & Register 7 8 XDW Doc Affinity Domain B XDW Doc 1 Document Registry Document Repository ITI Document Register 1a 2 ITI Document Register Document Source Document Consumer ( option if not XCA to adC ITI Stored Query ITI Provide & Register 4 Document Repository Affinity Domain C Document Source XDW Doc

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 CP 659 Workflow Id in Metadata XCR Supplement (Or CP YYYY on XDR to add the directed HomeCommunity Id ?) Annex: Deployment models for XDW CP XXX XDW Change use of folder to workflow Id Reference use of CP XXX and CP 659 Extend XDW to cross domain deployment Add use of XCR and XCA Create 2 new supplements and one CP

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


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

Similar presentations


Ads by Google