Cross Community Fetch

From IHE Wiki
Jump to: navigation, search

Summary

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 (XCA).

Benefits

  • 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

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 (XCA) profile.

When only a few dynamically created documents are needed from the other community, a single transaction may reduce implementation difficulty when transcoding and translation of the documents is desirable. XCF simplifies the implementation of stateless Responding Gateways, at the expense of possibly more complex Initiating Gateway deployment.

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,
  • 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 is too large, an error code is returned by the Responding Gateway. If these prerequisites cannot be met then XCA can be used.

Systems Affected

Systems involved in this profile are:

  • HIS

Actors & Transactions:

XCF Actors Transactions.png

Specification

Profile Status: Trial Implementation

Documents: 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 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.

Current: IT Infrastructure Technical Framework.