Difference between revisions of "Cross Community Fetch"

From IHE Wiki
Jump to navigation Jump to search
 
(13 intermediate revisions by 3 users not shown)
Line 1: Line 1:
−
== Summary ==
+
defines a single transaction to retrieve medical data held by other communities when only a few documents need to be fetched.
 +
__TOC__
  
−
The '''Cross-Community Fetch (XCF)''' profile defines a single transaction to retrieve medical data held by other communities when only a few documents need to be fetched. See also Cross-Community Access ([http://wiki.ihe.net/index.php?title=Cross-Community_Access XCA]).
+
==Formal Specification==
  
−
== Benefits ==  
+
===[https://profiles.ihe.net/ITI/TF/Volume1/ch-29.html XCF specification]===
 +
* [https://profiles.ihe.net/ITI/TF/Volume1/ch-29.html Trial Implementation]
  
−
* Enables peer-to-peer querying/retrieving with other communities using one transaction, when few documents need to be fetched.
 
−
* Simplifies implementation of stateless gateways where the types of documents have been pre-negotiated.
 
  
−
== Details ==
+
[[Category:Profiles]]
 +
[[Category:ITI Profile]]
 +
[[Category:DocShare]]
  
−
The Cross-Community Fetch (XCF) profile defines a single transaction for accessing medical data between gateways that facilitate multiple dimensions of communication (trust, semantics, encoding, legislation, authority, etc.). XCF is related to the Cross-Community Access ([http://wiki.ihe.net/index.php?title=Cross-Community_Access XCA]) profile.
+
Current: [[Frameworks#IHE IT Infrastructure Technical Framework| IT Infrastructure Technical Framework]].
−
 
 
−
When only a few dynamically created documents are needed from the other community, a single transaction may reduce the coordination and maintenance of the transactional dependencies and transaction states.
 
−
 
 
−
XCF also simplifies the implementation of stateless Responding Gateways.  However, it may increase the implementation complexity of Initiating Gateways, such as XDS Affinity Domains. XCF offers an alternative deployment option to XCA Profile. The transaction fetches only a small number of documents based upon a few retrieval parameters.
 
−
 
 
−
Transcoding and translation of the documents and other data can be performed on the Responding Gateway as part of the transaction.
 
−
 
 
−
The XCF Profile prerequisites are:
 
−
*the document properties to be communicated are known in advance
 
−
*the result data sets can be characterized in advance
 
−
*the documents are feasible to be returned in a single response
 
−
*no further selection and/or manual interaction is needed in the communication process
 
−
*preconditions, such as purpose of use, legitimate data, and environment, are agreed upon in advance and are documented in a community or framework agreement
 
−
*the document fetching may not always be repeatable – it may not be assumed in every case that the same query with the same query parameters will return the same document version with the same document id.
 
−
 
 
−
Ideally, only one document will satisfy the Fetch (e.g., only the most current instance of a patient summary is provided by the Responding Gateway). If the set of documents returned, an error code is returned by the Responding Gateway. Use XCA when this is true.
 
−
 
 
−
==Systems Affected==
 
−
Systems involved in this profile are:
 
−
* HIS
 
−
 
 
−
'''Actors & Transactions:'''
 
−
 
 
−
[[Image:XCF_Actors_Transactions.png]]
 
−
 
 
−
==Specification==
 
−
 
 
−
'''Profile Status:''' [[Comments| Trial Implementation]]
 
−
 
 
−
'''Documents:'''
 
−
[http://www.ihe.net/Technical_Framework/upload/IHE_ITI_Suppl_XCF_Rev1-1_TI_2011-08-19.pdf# Cross-Community Fetch (XCF)]
 
−
 
 
−
 
 
−
'''Underlying Standards:'''
 
−
:* ebRIM OASIS/ebXML Registry Information Model v3.0
 
−
:* ebRS OASIS/ebXML Registry Services Specifications v3.0
 
−
 
 
−
'''Actor Grouping and Profile Interactions'''
 
−
 
 
−
Interoperable interaction between communities which have chosen to implement only XCF and those that are based on XDS or XCA may be enabled through transformation agents. IHE does not specify the mechanism used by such transformation agents or any details about their implementation.
 
−
* “responding agent” for XDS- acts as an XCF Responding Gateway and converts incoming Cross Gateway Fetch transactions into XDS transactions to collect the content needed for the response.
 
−
* “responding agent” for XCA- acts as an XCF Responding Gateway and converts incoming Cross Gateway Fetch transactions into XCA transactions to collect the content needed for the response.
 
−
* “initiating agent” for XDS – acts as an XCF Initiating Gateway and converts XDS transactions into Cross Gateway Fetch transactions to collect content from XCF only communities.
 
−
* “initiating agent” for XCA– acts as an XCF Initiating Gateway and converts XCA transactions into Cross Gateway Fetch transactions to collect content from XCF only communities.
 
−
 
 
−
Some agents are relatively easy to implement and others are quite complicated. In environments where integration of with XCA and XDS is important it would be advisable to consider XCA with the On-Demand option as an alternative to the use of XCF.
 
−
 
 
−
The Initiating Gateway shall be grouped with ATNA Secure Node or ATNA Secure Application, CT Time Client and XUA X-Service User.
 
−
The Responding Gateway shall be grouped with ATNA Secure Node or ATNA Secure Application, CT Time Client and XUA X-Service Provider.
 

Latest revision as of 16:27, 29 November 2021

defines a single transaction to retrieve medical data held by other communities when only a few documents need to be fetched.

Formal Specification

XCF specification

Current: IT Infrastructure Technical Framework.

Retrieved from "http://wiki.ihe.net/index.php?title=Cross_Community_Fetch&oldid=126904"