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

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.

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.

See xca_bill_28mar07.doc for further information.

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.