extending xdw in cross community n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Extending XDW in Cross-Community PowerPoint Presentation
Download Presentation
Extending XDW in Cross-Community

Loading in 2 Seconds...

play fullscreen
1 / 13

Extending XDW in Cross-Community - PowerPoint PPT Presentation


  • 97 Views
  • Uploaded on

Extending XDW in Cross-Community. Editor: Charles P arisot Notes for the March 19 th , 2013 – ITI Tech Committee. Analyzed the two main alternatives :. Sacrifice partitionability . Sacrifice consistent responses .

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Extending XDW in Cross-Community' - verity


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
extending xdw in cross community

Extending XDW in Cross-Community

Editor: Charles Parisot

Notes for the

March 19th, 2013 – ITI Tech Committee

analyzed the two main alternatives
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.

further details on a and b approach
Further details on a/ and b) approach
  • Working paper from Rob Horn used to drive the analysis on the previous slide.
deployment models
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

1 xdw wf document located in any affinity domain where initially created a

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

1 xdw wf document located in any affinity domain where initially created b

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

slide7

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.

2 xdw wf documents located in a separate affinity domain

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

deployment models1
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.

5 policies issues
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.
need a decision on folders vs wf number in xdw
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.
documentation structure
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

next steps
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).