ITI White Paper: Publish/Subscribe Infrastructure: Difference between revisions
No edit summary |
|||
| Line 9: | Line 9: | ||
The implementation of publish/subscribe in healthcare environments also needs to take into account the need for security and privacy of the exchanged information. The described methodology to add publish/subscribe transactions to an IHE XDS affinity domain contains a discussion on the security implications arising in such situations. | The implementation of publish/subscribe in healthcare environments also needs to take into account the need for security and privacy of the exchanged information. The described methodology to add publish/subscribe transactions to an IHE XDS affinity domain contains a discussion on the security implications arising in such situations. | ||
==Open/Closed Issues== | |||
===Open Issues=== | |||
===Closed Issues=== | |||
==Use cases== | ==Use cases== | ||
Revision as of 18:20, 8 March 2008
Introduction
Event driven information exchange patterns dominate the data interchange in most healthcare settings. For example, most HL7 version 2.x interfaces send messages based on events within the sender's system. Most current IHE profiles assume either static, out-of-band determination of the senders and receivers of event driven information exchange, or describe query-response patterns. There is a need for a profiled dynamic infrastructure for event-driven information exchange patterns within IHE. This white paper describes such a framework based on the publish/subscribe data exchange model, and the methodology to apply the framework to IHE profiles.
Publish/subscribe patterns of data exchange are conceptually simple, and involve a limited numbers of actors and transactions. The transaction allow for automating the determination of information consumers based on events or content "topics". For example, if an IHE profile describes information content where a diagnosis is present and coded using a particular coding system, a subscriber can request to receive any transactions where one from a particular set of diagnosis codes is present. If the subscription is accepted, the system which keeps track of information recipients will start sending the transactions which match the described criteria to the subscriber.
The above example demonstrates two important issues which need to be addressed by profilers and implementers of publish/subscribe interactions. The first one is that the implementation of transactions and actors are dependent on the information exchange environment. Prescribing a specific technology for a general publish/subscribe infrastructure is not a practical option - it is unlikely that, for example, IHE actors which exchange information using DICOM transactions will be inclined to add Web Services based transactions for enabling publish/subscribe. This paper describes the publish/subscribe actors and their transactions in the context of the XDS-b profile, with a secondary goal to serve as an example or blueprint for binding these actors and transactions to other IHE profiles.
The second issue that needs to be addressed is the use of subscription topics. Based on the information exchange environment, topics can be described in various ways. This paper presents a specific approach within the context of XDS-b, including a discussion on how topics can be extended in the future.
The implementation of publish/subscribe in healthcare environments also needs to take into account the need for security and privacy of the exchanged information. The described methodology to add publish/subscribe transactions to an IHE XDS affinity domain contains a discussion on the security implications arising in such situations.
Open/Closed Issues
Open Issues
Closed Issues
Use cases
Unexpected notification
A patient in the emergency department has all her relevant available documents retrieved via XDS-b transactions. As initial triage of the patient is done, an additional document regarding diagnostic results for this patient is registered in the XDS registry. Currently, there is no way for the Emergency department to learn about the existence of this new information. With a publish/subscribe infrastructure, the initial query to the registry would be accompanied with a subscription request, as a result of which a notification (or the document itself) would be send to the emergency department. The subscription will be terminated once the patient is no longer under the care of the emergency department's institution.
Long-term subscription
A patient visits their PCP after being discharged from a hospital, which belongs to the same XDS affinity domain as the provider's organization. The provider sends a query to the affinity domain registry, and retrieves the hospital discharge summary. The patient also has follow-up visits with a specialist at the hospital, and these visit summaries (including diagnostic test results) are registered in the affinity domain registry. Currently, the PCP would have to periodically query the registry for documents about the patient in order to retrieve the follow-up visit summaries. With a publish/subscribe infrastructure, the PCP would have a subscription for all his patients, so that notifications (or the documents themselves) would have been received as the summaries were registered in the affinity domain registry.
Public Health Surveillance
For the purposes of detecting patterns of infectious disease outbreaks, public health organizations may need to receive notifications on topics based on document content, such as specific diagnoses. While this is similar to the long-term subscription use case, the different use of topics in this use case makes an important difference. There needs to be further investigation as to how topics would be represented in order for this use case to be addressed.
PCC Antepartum Summary Profile
Need to review if the PCC profile has needs, which are not met by the other use cases.