Cross Community Access - Discussion

From IHE Wiki
Revision as of 16:42, 1 May 2007 by Witting (talk | contribs) (→‎Comments)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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 the profile this year (2007).

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.

April 18-30 online discussion

This section collects ideas regarding technical solutions for agreed requirements of the profile. Each section addresses a particular requirement and comments related to that requirement. Please add comments under the Comments section identified with your name. Do not remove or modify anyone else's comments or any Introduction.

As background please review the beginings of the profile at XCASupplement.2007.04.18.doc. Especially review page 4 which has a proposed transaction diagram. If anyone can tell me how to export that diagram into a wiki I would be pleased to copy it here.

Support large volume data

Introduction

The current XDS Stored Query assumes all data is returned in one synchronous response. It is expected that queries spanning multiple Affinity Domains will result in larger sets of data and it is a requirement that the requestor be able to request that results be chunked in the response. The ebRS Stored Query specification supports "Query Iteration" in the following way:

  • On the request the caller specifies maxResults and startIndex
  • The responder returns at most the maxResults specified and a totalResultCount indicating the complete number of results. If startIndex is specified the responder starts at that index.

The following issues remain:

  1. The design of ebRS Iterative Query assumes that the registry coorelation of requests is done because the same query is sent for each request. This mechanism for coorelation may be complicated for the gateway to implement.
  2. The responder (gateway) may cache results waiting for a request for the next chunk from the requestor. The ability to cancel or timeout the block of requests is needed.
  3. The responder (i.e. gateway) may not know the final number of results so specification of totalResultCount could be a problem.
  4. Question whether support for "transactional consistency" is required. The following quote from ebXML RS V 3.0 relates to this:

The iterative queries feature is not a true Cursor capability as found in databases. The registry is not required to maintain transactional consistency or state between iterations of a query. Thus it is possible for new objects to be added or existing objects to be removed from the complete result set in between iterations. As a consequence it is possible to have a result set element be skipped or duplicated between iterations. Note that while it is not required, an implementations MAY implement a transactionally consistent iterative query feature.

Comments
  • (Karen) #1 we could consider requesting an update to ebXML which support iterative query using some session identifier instead of a repeat of the query.
  • (Karen) #3 we could consider requesting an update to ebRS which specified that totalResultCount=-1 inidicates there may be more entries but the complete number is not known.
  • (Karen) #4 we should require transactional integrity, but this will put a significant burden on the gateway.
  • (Tony) #1 The gateway would have to support a PIX which would define the Id to be used for each query. It is not clear that the gateway can delegate the fan out query to a transport but may have to issue each query with its own patient id in parallel and manage the completion. This is a classical orchestration mechanism that can be managed by concurrent threads or something like BPEL.
  • (Tony) #2 The cancellation would be supported by a session mechanism mentioned elsewhere.
  • (Tony) #3 The consuming gateway (i.e. at the consuming community) would know the total number if it has been requested to sort the results since it must buffer them prior to returning to the XC consumer.
Resolution from 4/30/07 call

Many alternative approaches were discussed on the call. It was felt that if chunking was supported then the chunking should be ordered, meaning the most recent data be provided in the first chunk. Since the "chunks" are collected across multiple domains it was believed that supporting chunking by timeframe would be complicated.

After much discussion it was agreed that chunking was already supported by the Stored Query Transaction in two ways:

  • A find documents query can request only object references and then retreive objects separately. This allows for a paging ability where the first request gets all references and subsequent requests get a "page" at a time.
  • A find documents query can be refined to select a smaller group of documents, either a smaller time range or restriction on document type or other class of documents.

If a request is received which is too big the gateway processing the request will have a particular return value which will indicate that the request returned too many records. This will be returned to the requestor who can then refine the query so fewer records are returned. Those on the call agreed that this was a sufficient solution to the problem for now. Chunking algorithms are complicated and to adopt one without a clear, demonstrated use case experienced in a real implementation it does not make sense to design a solution.

Support significant delay in response

Introduction

The current XDS Stored Query does not allow the requester to specify a timeout value for a time frame where a subset of data is returned. For example, a requestor may want to get as many results as possible in one minute. Current support allows for canceling the request at one minute - hence getting nothing - or waiting for as long as it takes to get everything. In a multiple Affinity Domain environment it is important that the requestor can specify a time frame to receive partial results.

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.
Comments
  • (Karen) I support option #1
  • (Tony) We should not assume that there will be big delays. Operational experience shows that multiple affinity domains can be queried in parallel in about 6-7 seconds with sorted results across about a six month record history. Obviously the longer the history the longer the delay.
Resolution from 4/30/07 call

The group is still determining whether this is a real problem. The VA has collected statistics regarding its multi-domain healthcare system which states that the average delay is 6-7 seconds. More data needs to be collected to determine if this is a problem to be solved. For now we assume it is not critical to solve.

Ordering of query response data

Introduction

The XDS Stored Query does not specify any ordering to the query results. Ordering of results is seen as very important but technically difficult in a cross Affiniy Domain environment. To support a sorted query result the gateway must get all results from all Affinity Domains and perform the sort against all results before anything is returned. This will result in a potentially long delay in receiving results.

Comments
  • (Karen) Discussion suggested that sorting should be an option with the understanding by the requestor that there may be a significant delay in receiving a response.
Resolution from 4/30/07 call

Agreed that if chunking is not implemented, meaning a request returns all records in one batch, then the consumer should do the sorting. Most EHR/EMR type applications (which will be implementing the consumer) already support a variety of sort options so there is no duplicate implementation happening. Putting the sort in the consumer also allows for a more flexible approach to sorting, while requiring it in the gateway introduces extra complexity in the specification of the gateway as the exact sort needed would have to be detailed.

Multiple asynchronous response messages (pushed messages)

Introduction

The definity of ebRS Iterative Query assumes the requestor repeats the query for each chunk of data. This solution drives the transactions always from the requestor end. Another alternative that many see as valuable is a "push" mechanism where the requestor sends one request to the gateway, which returns partial results as part of the response to the original request and subseqent requests initiated by the gateway. Thus the requestor must provide a service endpoint which will receive subsequent "pushed" results.

We could 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
Comments
  • (Karen) I think we should not support this this year. It should be considered for future years work.
  • (Tony) There is a case for a complete asynchronous response where it "primes the cache" in preparation for Performance Intensive Applications such as drug-drug interaction testing for Pharmacy orders. We could work the thinking towards this.
Resolution from 4/30/07 call

Not specifically addressed, but given above decision not to support chunking this would no longer be a question.

Error handling

Introduction

Neither the ebXML specification or XDS deals specifically with a situation when results plus errors are both returned. In a cross Affinity Domain environment this situation as much more prevalent, coming up whenever the gateway is able to reach some of the other affinity domains and not others. In this case the gateway should return both the results received as well as a message explaining that some affinity domains could not be reached. A suggested approach to this is have return status="Success" or define a new status indicating partial success and include the error messages as registry errors. For example: 

<AdhocQueryResponse ... status="Success_Partial">
<RegistryErrorList>
   <RegistryError ...>
   <RegistryError ...>
</RegistryErrorList>
<RegistryObjectList>
   <ExtrinsicObject ...
...

One key point is that the profile must require the consumer to present the errors and results to the end user so that the user is aware that partial results have been received.

Comments
  • (Karen) The example needs improvement.
  • (Tony) Agreed. Since the XC Consumer cannot do anything about a non-responsive responding Gateway, it must present the fact to the user. The best we have come up with is a missing information (document) which shows in the result set saying that a named community at which the patient is known did not respond. It then appears in the result set for the clinician.
Resolution from 4/30/07 call

Agreed that a new status code indicating partial success would be used and the consumer would be required to reflect the errors. The RegistryError's returned must indicate which community the error came from. There was discussion regarding whether this information could be the community OID, or should be a community name as well. No clear resolution on this.

An open question came up regarding whether we should profile a way for the gateway to return to the consumer a list of successfully contacted gateways. The error list should indicate any unsuccessful requests, but a list of successful may be useful. This may not be necessary given the resolution of metadata below.

Unigue Idenfication of Patient

Introduction

See Uniquely identifying the patient for a discussion.

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.

Comments
  • (Karen) This is resolved as per the March 28 tcon. Included here to collect comments from those not on the March 28'th call.

Interaction with XDS

Introduction

See Interaction with XDS actors for discussion.

Comments
  • (Karen) This is resolved as per the March 28 tcon. Included here to collect comments from those not on the March 28'th call.

Managing metadata

Introduction

See Managing metadata from external communities for discussion from previous tcon.

Clarified into the following sub-issues:

Affinity Domain specific values
Assume a common set of values used across Affinity Domains
patientId
See Uniquely identifying the patient for discussion. Resolved: Query from consumer to gateway uses Affinity Domain patient id, query from gateway to gateway uses receiving gateway patient id. Out of scope for this year is how the gateway translates from its local Affinity Domain patient id to the receiving gateways patient id.
doclink
The XCA profile will only support the new Web Services based Retrieve. At issue is how a gateway knows which Affinity Domain to direct a retrieve request to. Some form of re-writing of the request is needed to ensure that the request is routed to the gateway rather than the external document repository. We could defer this to "magic" of the gateway. One sort of magic is that the gateway has one service entry point for each affinity domain it interacts with. It then redirects each document link to the appropriate service entry point which automagically redirects to the right place. Question is, is this a reasonable implementation?
EntryUUID&UniqueID
EntryUUID and Uniqueid are values in the ExtrinsicObject which can be used in subsequent queries. When the gateway receives a query which only references one of these values it needs to know which Affinity Domain to route the request to. Two potential solutions to this a) cache the coorelation b) rewrite the value to imply the correlation. Currently only a) seems feasible.
Comments
  • (Karen) EntryUUID&UniqueID the option of caching the coorelation seems error prone in that the gateway may discard the relation before the query comes back. I would prefer to define a way that the gateway re-writes the returned data so the consumer can specify the value in the subsequent query. But those queries do not currently support that kind of extra data so this will be new support that will be needed.
Resolution from 4/30/07 call

Suggestion that the home attribute be used to indicate the community which returned the entry. The home attribute is defined in ebXML 3.0 on both the ObjectRef entry and the ExtrinsicObject (inheriting from Identifiable). Thus the attribute is available in the places where it is needed. The requirement would be:

  • The gateway MUST add the home attribute to entries returned from a Find Documents or equivalent patient id based query.
  • The consumer MUST specify the home attibute on "secondary" queries, namely those that do not include a patient id. This home attribute must be used by the gateway to determine which external gateway to route the query to.

A solution for the document link may also make use of this home attribute. The definition of the web services retrieve must be reviewed to determine the best approach to this.

Security & Privacy

Introduction

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

Comments
  • (Karen) Need to do a Risk Analysis of this.
Resolution from 4/30/07 call

No discussion during the call.

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.

Proposal at xca_bill_28mar07.doc discussed.


Resolved: General agreement in the approaches suggested in Bill's document above. Further technical details need to be refined. First refinement and further documentation of discussion at Solution Outline .

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.

Solution Outline

The version 3 ebXML Registry specifications are available (pdf) from

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.

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.

Retrieved from "http://wiki.ihe.net/index.php?title=Cross_Community_Access_-_Discussion&oldid=4507"