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)
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.
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 bridge-to-bridge 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 bridge must ensure that the patient has been uniquely identified prior to the bridge-to-bridge query and leave out of scope how exactly the bridge does that.
Interaction with XDS actors
Review XCA Technical Approach section 7.6 Connection with XDS for a diagram showing the interaction between the bridge and Document Registry and Repository. In short, the bridge 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 bridge query.
Proposal for interaction between DC and XCC
The XCC to bridge 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 bridge (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.
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 bridge. Will this work?
What about document entry references: UUID and uniqueid. These can be used in subsequent queries. How will the bridge translate to the right community to send the query to?
Is there a 1-1 relationship between the bridge and the registry? Do we support bridge chaining?
Privacy and Security
Require ATNA and CT. Bridges 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).