Talk:ITI White Paper: Publish/Subscribe Infrastructure
Conference Call February 12, 2008
After introduction of the original outline, the group consensus was that the white paper should closely follow the format of a profile, and, as originally proposed, concentrate on resolving XDS-specific problems, rather than stating general principles of publish/subscribe. The following notes reflect the discussions at the conference call on 2/12:
Use cases
Use cases are central to the development of the white paper, and the discussion produced several of them for a general XDS workflow:
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.
Actors
The discussion on actors produced the following suggestions:
Subscriber
The Subscriber actor initiates, modifies, and terminates subscription. Within an XDS affinity domain the subscriber will most likely be combined with a document consumer actor.
Subscription Manager
The Subscription Manager keeps track of all subscriptions in the affinity domain. This actor is the receiver of subscription requests, subscription modifications, and subscription cancellations. It also keeps track of the time limits of subscriptions. It is very likely that this actor would be combined with the Notification Broker actor (or even merged into a single actor).
Notification Broker
The Notification Broker receives notifications that a new document has been registered in the XDS Registry, and based on the topics associated with the document sends notifications (or possibly the documents themselves) to all subscribers. In an XDS affinity domain this actor can be combined with the XDS Document Registry actor.
Notification/Publication Recipient
This actor receives the notification about document availability (and/or the documents themselves). It is unclear if there is any benefit to separate this actor from the subscriber. In either case, this actor will very likely be always grouped with a document consumer.
Transactions
The discussion on transactions produced the following suggestions. An open issue is using XDS-specific transactions, vs. using some of the emerging web services standards.
Initiate Subscription
This transaction is sent by the Subscriber to the Subscription Manager in order to start a subscription for a particular set of topics, indicating possible start and end time for the subscription.
Modify Subscription
This transaction is used to modify an existing subscription, by changing it's parameters, or outright canceling it.
Event Notification
This is a transaction from the XDS Document Registry to the notification broker indicating that a new submission has been registered. One way to implement this would be to simply forward the XDS Register transaction to the notification broker.
Publication
This is a transaction from the Notification Broker to the Subscribers, sending a notification about the availability of a document of interest, based on the subscribers' topics. This implies that there is an interaction with the subscription manager to determine the recipients of the publication. Given the close sequencing the Event Notification and Publication, and the interaction between Notification Broker and Subscription Manager, a likely outcome is that the two transactions and the two actors are combined into one actor and/or one transaction.
Topics
Within a publish/subscribe framework, topics are the "units" of subscription. In the context of XDS it seems natural to derive topics from the metadata defined by XDS. The discussion highlighted the following issues to be considered:
- The Stored Query XDS transaction already defines a set of query parameters, which are a good initial starting point for a list of topics. The recommendation is to limit the initial publication of the white paper to such a list.
- How are topics specified? In particular, how to distinguish between requiring a specific value for a topic, vs. simple existence of the topic?
- How are topics combined? Always AND, Always OR, or any boolean combination? Support of a list of values for a topic?
Original Outline
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 publish/subscribe is not a practical option - it is unlikely that, for example, IHE actors which exchange information using DICOM transaction will be inclined to add Web Services based transactions for enabling publish/subscribe. To address this issue this paper describes the publish/subscribe actors and their transactions in an abstract manner, and present the way to make these abstract constructs into regular IHE actors and transactions.
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 various approaches to specifying topics, and some discussion on how these approaches can be used in IHE profiles.
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 methodology to include publish/subscribe transactions in IHE profiles contains a discussion on the security implications arising in such situations.
As a proof of concept, Appendix A of the paper demonstrates the use of publish/subscribe as part of the XDS profiles.