ITI XCDR Endpoint Addressing: Difference between revisions

From IHE Wiki
Jump to navigation Jump to search
Vassil1 (talk | contribs)
No edit summary
Vassil1 (talk | contribs)
No edit summary
 
(2 intermediate revisions by the same user not shown)
Line 27: Line 27:
==5. Discussion==
==5. Discussion==


''<Include additional discussion or consider a few details which might be useful for the detailed proposal>''
=== 5.1 Determining the Home Community ID ===
:''<Why IHE would be a good venue to solve the problem and what you think IHE should do to solve it.>''
:''<What might the IHE technical approach be? Existing Actors? New Transactions? Additional Profiles?>''
:''<What are some of the risks or open issues to be addressed?>''


The requirement that the Document Source supplies the Home Community ID seems to be too restrictive. It is just likely that the gateway will have directory services that can determine the Home Community ID from the intended recipient. This proposal will add that as an option, or loosen the current requirement.


''<This is the brief proposal. Try to keep it to 1 or at most 2 pages>''
=== 5.2 Additional actor responsibilities ===


Additional guidance around author and intended recipient, as well as the use of directories, will enable the use of XCDR in more specific profiles like 360X.


[[Category:ITI]]
=== 5.3 MCSD Directory ===
 
Add profiling to the format of the intended recipient.
 
 
 
[[Category:IT Infrastructure‏‎]]

Latest revision as of 15:09, 20 February 2025


1. Proposed Workitem: Enable XCDR transactions to address a specific endpoint beyond the gateway

  • Proposal Editor: Vassil Peytchev
  • Editor: Vassil Peytchev
  • Date: N/A (Wiki keeps history)
  • Version: N/A (Wiki keeps history)
  • Domain: IT Infrastructure

2. The Problem

Currently, the XCDR specification describes a use case of XDR/XCDR working together to cross community boundaries. There is, however, no discussion or guidance on how the endpoint addressing should work.

This proposal will enhance the description of the XDR/XCDR use case with more details about the author and intended recipient metadata elements, and will add actor requirements to facilitate directed delivery.

3. Key Use Case

The key use case is to add XCDR as an transport option to the PCC 360X profile, and add the US implementation details on how 360X will work on TEFCA.


4. Standards and Systems

  • XDR
  • XCDR

5. Discussion

5.1 Determining the Home Community ID

The requirement that the Document Source supplies the Home Community ID seems to be too restrictive. It is just likely that the gateway will have directory services that can determine the Home Community ID from the intended recipient. This proposal will add that as an option, or loosen the current requirement.

5.2 Additional actor responsibilities

Additional guidance around author and intended recipient, as well as the use of directories, will enable the use of XCDR in more specific profiles like 360X.

5.3 MCSD Directory

Add profiling to the format of the intended recipient.