Cross Community Access - Discussion

Introduction

The Cross Community Access profile supports sharing of patient health information across communities. A community is defined as a coupling of facilities/enterprises for the purpose of sharing patient-relevant medical information. A community must have an established mechanism for sharing medical information among the organizations belonging to the community. An example of a community is an XDS Affinity Domain which defines document sharing using the XDS profile. This profile supports sharing of medical documents across XDS Affinity Domains. This profile should allow for extensions which support sharing of patient health information between communities other than XDS Affinity Domains. These extensions are out of scope for this profile.

In 2006 a White Paper was developed by the ITI technical committee proposing a set of profiles that supports cross community patient data access. This proposal is one of the profiles specified in the White Paper.

Tcon March 28, 2007

The purpose of this tcon is to resolve issues discussed during the face-to-face, which are:

• Rename bridge actor
• Large volume data and significant delay of response
• Uniquely identifying the patient
• Interaction with XDS actors
• Managing metadata from external communities
• Privacy and Security

Attendees:Jeff, Charles, Lynn, Bill, Karen, Tony, Chalres, LaVerne, Laurie

Rename bridge actor

The term bridge suggests the connections to the community as well as the span across. The actor it describes is not the span among communities but only the connecting entity within a community. For clarity it was suggested that a new name be found. Suggested name: gateway.

Resolved: Rename this actor to Cross Community Gateway (XCG). The XCG may be simplified to gateway when it is clear in context. Updated document with most instances of bridge changed to gateway at: XCA Technical Approach. Flow diagram bridge to gateway conversion will be done as time permits.

Large volume data and significant delay of response

The group agreed that some form of iterative response to a query is needed. Suggestion is to use ebRS Iterative Query Support. Unclear whether this support covers all requirements.

XCA Query

We have previously stated the following requirements for XCA queries:

1. Able to request results be returned in chunks
2. Able to specify a timeout on the next chunk (give me up to 20 entries with no more than 20 second delay)
3. Able to terminate the request
4. The above requirements operate through the fan-out of a XC-Bridge
5. Ordering
6. Partial results, possibly associatiated with an error

It has further been requested that the non-XCA portions of the above be applied to the existing Stored Query transaction.

There are two mechanisms that can be used to support these requirements.

This protocol attaches to the AdhocQueryRequest the following parameters:

• startIndex
• maxResults
  

which can be used to request ‘page at a time’ results returning. The resulting AdhocQueryResponse include the parameters:

• startIndex
• totalResultCount

WS-Addressing

In section 3 “Message Information Headers” of this specification, the following excerpts offer detail regarding how this specification may be useful.

The message information headers collectively augment a message with the following abstract properties. These properties enable the identification and location of the endpoints involved in an interaction. The basic interaction pattern from which all others are composed is "one way". In this pattern a source sends a message to a destination without any further definition of the interaction. "Request Reply" is a common interaction pattern that consists of an initial message sent by a source endpoint (the request) and a subsequent message sent from the destination of the request back to the source (the reply). A reply can be either an application message, a fault, or any other message. The properties below support one way, request reply, and any other interaction pattern.

Options

Web Services would be used as an outer wrapper for XCA queries. AdhocQueryRequest/Response message formats would be used as an inner wrapper. The resulting work lies in managing the capabilities of these two wrappers and their semantics.

Going back to the requirements section:

1. Return results in chunks: AdhocQueryRequest/Response enables this.
2. Timeout on the next chunk. Neither wrapper enables this. There are two options:
   1. Specify, for each Stored Query, an optional timeout parameter. Since unexpected parameters to a Stored Query shall be ignored, this can be sent to a Document Registry that does not support this feature without issue.
   2. Specify, as a WS header, an optional timeout parameter. With either specification, we need to define whether each chunk is returned as a result of a new AdhocQueryRequest/Response message or whether we would specify a WS-Addressing interaction pattern that resulted in a single AdhocQueryRequest message being followed by multiple AdhocQueryResponse messages being returned. If multiple AdhocQueryResponse message were allowed we should use the following semantic to allow the chunk specification to still operate as a form of flow control. An AdhocQueryRequest that includes both a chunk specification and a timeout shall respond with at most:
      1. One response after the timeout has expired
      2. One (or more) responses with the left over results
3. Terminate the request: neither wrapper defines this natively. We would have to define a message for this purpose.
4. Operate through a bridge fan-out: no protocol issues here, only issues related to security.

If the above requirements and technical elements can be agreed to then the next step is to mold them into a specific protocol with binding set and define the specific parameters and semantic interpretations.

Resolved: General agreement in the approaches suggested in Bill's document above. Further technical details need to be refined. Bill to update document based on discussion.

Discussion Subjects

• Is there a requirement for ordering of results? Potential exists for adding an option on the existing query to ask for a specific ordering. Expanding this to a cross community setting introduces complexity. In order to support this the gateway would need to wait for response from all remote gateways, do a sort of the merged results, and then respond to requestor.
• ebRS description of maxResults needs to support the requirement that the responder may not know the total number of results, or if there are any more.
• Query response status is needed to identify "partial success". This is especially important in a cross community setting where a remote gateway is not responding so the local gateway can only return partial results. It is important that this information get reflected to the user.
• Use case where the gateway is a cache of sorts and first query (potentially requesting no immediate response) gets the gateway starting in "priming the pump" so to speak. Following requests would reference the first query and ask for results that have hopefully been accumulated in the gateway so the request is immediate.
• Request for definition of "push" versus "pull"

Push

A chunking interaction between requestor/responder where the requester repeats the request over some interval, receiving chunks of data in each request until all data is returned.

Pull

A chunking interaction between requestor/responder where the requester sends an initial request and receives response chunks asynchronously at a time determined by the responder. Generall requestor uses a listening socket/service which gets triggered by an incoming transaction from responder.

• Discussion of Implementation patterns. This type of information will be useful in understanding potential uses of the profile. A separate page will be used to accumulate these. Tony will work on developing this page.

Uniquely identifying the patient

Review XCA Technical Approach section 7.2.1 Patient Identification in a Hierarchical Cross Community Exchange and section 7.2.2 Patient Identification in a Lateral Cross Community Exchange. These diagrams depict two potentials ways of ensuring the patient is uniquely identified prior to execution of the gatewaye-to-gateway query.

Ensuring unique patient idenfication is frequently tied to the process of determining which communities to query. The profiling of managing which communities have information about a specific patient is defered until next year. For that reason it is suggested that we defer the detailed profiling of this work until next year. For this year we can require that the gateway must ensure that the patient has been uniquely identified prior to the gateway-to-gateway query and leave out of scope how exactly the gateway does that.

Resolved: Agreed that details regarding how the gateway finds the right patient id to use in a query is out of scope for this years work and will be addressed in the follow-on work.

Issue: Consideration for hierarchical gateways is needed.

Interaction with XDS actors

Review XCA Technical Approach section 7.6 Connection with XDS for a diagram showing the interaction between the gateway and Document Registry and Repository. In short, the gateway acts as a Document Consumer when interacting with the Registry and Repository. Nothing further is required.

At issue is the interaction between the XDS Document Consumer (DC) and Cross Community Consumer (XCC). Phrased another way: at issue is the difference between the Stored Query transaction and the XCC to gateway query.

Proposal for interaction between DC and XCC

The XCC to gateway query is identical to the Stored Query with support for the ebRS "Iterative Query Support". Iterative Query Support is believed to also be useful in the DC to Registry query and may be applied there, potentially optionally. With this proposal the additional work for an existing DC to become a XCC would be:

• Configure a second "link" to talk to a gateway (versus registry)
• Support Iterative Query

The expectation is that the DC and XCC would be implemented within one system and there would not be any need for a transaction between them.

Resolved: Above proposal was acceptable to those on the call.

Managing metadata from external communities

Potentially scope this years work to assume all sharing communities have a shared vocabulary.

Still need to manage document references. This could potentially be done using DNS... map all Repository OIDS from outside the community to the gateway. Will this work?

What about document entry references: UUID and uniqueid. These can be used in subsequent queries. How will the gateway translate to the right community to send the query to?

Is there a 1-1 relationship between the gateway and the registry? Do we support gateway chaining? Hierarchical gateways?

Dscussion

• Agreed that scoping for this year should assume all sharing communities are using the same coding vocabulary for metadata elements
• Gateway needs to handle document entry references (UUUID & uniqueID) so that future queries using those values can be related to the gateway from which the document entry came. Two approaches:
  • Have gateway cache the relationship between UUID & uniqueID's returned from other gateways. Then on subsequent queries gateway consults cache to find relationship. Concern that cache must be cleared and backup behavior (query everything) is painful. Also consumer may want/need some clue in terms of which gateway returned the data, even if the clue is only a OID that some other entity needs to resolve before it is useful.
  • Have gateway "rewrite" the data, or add to the data in the document entry to include an OID (or equivalent) for the entity from which the gateway received the data. This OID could then be used on subsequent requests (which would need to include the OID) to target the request to the right remote gateway.

Privacy and Security

Require ATNA and CT. Gateways are secure nodes and must audit all transactions.

Need to verify we have enough information included in the request to support common policy decisions.

Other security and privacy issues will be deferred to other profiles (i.e. XUA, BPPC).

Result: Ran out of time prior to getting to this item.