Cross Community Fetch

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. XCF is highly inspired by the Cross Gateway Query/Cross Gateway Retrieve transactions [1] and integrates these originally distinct transactions.

Benefits

• Enables peer-to-peer querying/retrieving with other communities using one transaction, when few documents need to be fetched

Details

Accessing few dynamically created documents

When a few dynamically created documents need to be accessed from interacting communities with centralized data localization; a single transaction (versus independent query and retrieve) may reduce the coordination and maintenance of the transactional dependencies and transaction states. For such use cases, and in environments where stateless Responding Gateways can be designed, XCF simplifies the implementation of such Responding Gateways. The transaction fetches a small number of documents based upon a few retrieval parameters. This transaction is simplified to permit easier implementation and better performance on Responding Gateways.

Transcoding and translation of the documents and other data can be performed on the Responding Gateway as part of the transaction. The XCF Profile stipulates that the following prerequisites are met:

• 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 size of the set of documents matching the request is too large to be packed into a single response, an error code is returned by the Responding Gateway. The assumption is that the XCA profile is used when requests are expected to return a large number of documents.

Systems Affected

Systems involved in this profile are:

• HIS

Actors & Transactions:

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