This is an early draft of a white paper on this topic. The current published version can be found at the IHE web site. The general ITI Publish Subscribe wiki page contains the most up-to-date information on this topic.

Overview, Use Cases, and Definitions

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 as applied to the XDS.b integration profile. An additional goal is to provide a blueprint for other IHE profiles to add publish/subscribe functionality.

Publish/subscribe patterns of data exchange are conceptually simple, and involve a limited numbers of actors and transactions. The transactions 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.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 leverages existing access controls and auditing controls from the underlying profile.

Issue Log

Open Issues

This white paper uses WS-Notification. Is this choice appropriate?
Notification or pushing: the notification can be just a DocID, the Metadata, or the full document. This white paper uses the Document ID as the notification to limit security exposure and leverage access control points.
Topics/Filters: the white paper uses a stored query based model for filters. There are other possible models, e.g. XPath expressions.
Reflecting the Topic filter in the Notification - it is an option in WS-Notification, however revealing this information (as well as the producer reference) could be introducing additional risks to reveling patient information.
No risk assessment has been done on the transactions presented. This is necessary to be completed before a supplement to the ITI Technical Framework is published in the future.

Closed Issues

The PCC APS profile may have a specific use case of interest. Added to use cases
Reuse XDS transactions, or use specific web services transactions - use WS-Notification
1. ebRIM/ebRS 3.0 define services compatible with these use cases. - use for topics
The only modification allowed to existing subscriptions is the end time of a subscription. While the underlying standard allows for other types of modifications, this paper adds this restriction for the sake of simplicity. Other types of modifications can be achieved via initiating a new subscription, and canceling the original.

Future development

Expand the white paper to a cookbook for adding pub/sub to any IHE profile

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.

Antepartum Record Availability

From the Antepartum Record profile under development in the PCC Technical Committee:

During the 40 weeks of a typical pregnancy duration, the patient will have an initial History and Physical Examination, followed by repetitive office visits with multiple laboratory studies, imaging (usually ultrasound) studies, and serial physical examinations with recordings of vital signs, fundal height, and the fetal heart rate. As the patient is seen over a finite period in the office, aggregation of specific relevant data important to the evaluation of the obstetric patient upon presentation to Labor and Delivery is caputured on paper forms. The antepartum record contains the most critical information needed including the ongoing Medical Diagnoses, the Estimated Due Date, outcomes of any prior pregnancies, serial visit data on the appropriate growth of the uterus and assessments of fetal well being, authorizations, laboratory and imaging studies. This data must all be presented and evaluated upon entry to the Labor and Delivery Suite to ensure optimal care for the patient and the fetus.

Once the electronic means of communicating the Antepartum Record are established via this new profile, the ability of the PCC content consumer to establish a subscription for the Antepartum Record updates for a given expectant mother will enhance the ability to automate the delivery of the information in a timely manner.

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.

Actors/Transactions

The following diagram represents the main actors in a publish/subscribe setup (aka brokered notification). Note that the Publisher actor is added for completeness, as this white paper does not prescribe any specific method for relaying the occurrence of an event (i.e. a submission set registration) from the XDS.b Registry to the Notification Broker. It is possible, however, that other IHE profiles may find the Publisher actor useful within the context of their transaction flows.

Publish/Subscribe Actor Diagram

XDS.b Publish Subscribe Actors and Transactions
Actor	Transaction	Opt.	Section
Subscriber	Subscribe	R	#Subscribe
Notification Broker	Subscribe	R	#Subscribe
Notification Broker	Notify	R	#Notify
Notification Consumer	Notify	R	#Notify

Actor Definitions

Subscriber

The Subscriber actor initiates, modifies, and terminates subscriptions on behalf of a Notification Consumer. Within an XDS affinity domain the subscriber will most likely be combined with a document consumer actor.

Notification Broker

The Notification Broker keeps track of all subscriptions in the XDS affinity domain, it must be aware of events in the XDS registry (e.g. that a new document has been registered), and based on the topics associated with the document sends notifications to interested subscribers. This actor is the receiver of subscription requests, subscription modifications, and subscription cancellations. It also keeps track of the time limits of subscriptions. This actor may be combined with the XDS-b Document Registry actor.

Notification Consumer

This actor receives the notification about an event, when the subscription filters for this Notification Consumer is satisfied. Within XDS-b, this actor will very likely be grouped with a document consumer.

Transaction Definitions

Subscribe

This transaction is sent by the Subscriber to the Notification Broker in order to start a subscription for a particular set of topics, indicating possible start and end time for the subscription. Subscriptions can be modified. Any subscribe actor can cancel a subscription, as long as they have the subscription id.

Notify

This is a transaction from the Notification Broker to the Notification Consumers, sending a notification about the availability of a document or documents of interest, based on the subscribers' filter on selected topics.

Detailed Transaction Definitions

Subscribe

Scope

This transaction involves a request by the Subscriber actor to the Notification Broker to start a subscription using a particular set of filters, or to modify or cancel an existing subscription.

Use Case Roles

Actor: Subscriber
Role: Sends, on the behalf of Notification Consumers, subscription requests, subscription modifications, or subscription cancellation messages to the Notification Broker

Actor: Notification Broker
Role: Manages subscriptions of Notification Consumers

Referenced Standards

[1]: OASIS Web Services Notification Family of Standards
[2]: WS-BaseNotification 1.3 OASIS Standard
[3]: WS-BrokeredNotification 1.3 OASIS Standard
[4]: WS-Topics 1.3 OASIS Standard
[5]: IHE ITI TF - Registry Stored Query Transaction

Interaction Diagram

Subscribe sequence

Subscription Request

Trigger

A Notification Consumer's need to initiate a subscription will cause the Subscriber to trigger a Subscription Request message.

Message Semantics

This white paper doesn't specify how the Notification Consumer and Subscriber communicate the need to initiate a subscription. One possible way to do that is to have a combined Notification Consumer and Subscriber actor.

The Subscription Request message SHALL comply with the requirements in the WS-BaseNotification standard. The wsnt:ConsumerReference element contains the Web Services end point where notifications must be sent. The wsnt:Filter element contains the topics and values for these topics for which a notification must be sent. This specification uses a "topic dialect" based on the XDS Stored Query syntax and semantics.

Expected Actions

The Notification Broker SHALL be capable of receiving multiple concurrent Subscription Requests and responding accordingly with Subscription Request Response messages.

The Notification Broker SHALL keep track of of each unique subscription and will assign a unique referencable Web Services end point where subsequent modifications and a cancellation can be sent.

The Subscriber shall indicate the duration of the subscription using the wsnt:InitialTerminationTime element, where a time stamp (expressed as an XML Schema dateTime data type value) or a duration (expressed as an XML Schema duration data type value) can be used.

Example

<?xml version="1.0" encoding="UTF-8"?>
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
    xmlns:a="http://www.w3.org/2005/08/addressing"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2"
    xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
    xsi:schemaLocation="http://www.w3.org/2003/05/soap-envelope http://www.w3.org/2003/05/soap-envelope http://www.w3.org/2005/08/addressing http://www.w3.org/2005/08/addressing/ws-addr.xsd http://docs.oasis-open.org/wsn/b-2 http://docs.oasis-open.org/wsn/b-2.xsd urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0 ../schema/ebRS/rim.xsd">
    <s:Header>
        <a:Action>http://docs.oasis-open.org/wsn/bw-2/NotificationProducer/SubscribeRequest</a:Action>
        <a:MessageID>382dcdc7-8e84-9fdc-8443-48fd83bca938</a:MessageID>
    </s:Header>
    <s:Body>
        <wsnt:Subscribe>
            <!-- The Consumer on whose behalf the subscription is requested - the address where the notification is to be sent -->
            <wsnt:ConsumerReference>
                <a:Address>https://NotificationConsumerServer/xdsBnotification</a:Address>
            </wsnt:ConsumerReference>
            <wsnt:Filter>
                <wsnt:TopicExpression Dialect="urn:ihe:iti:xds-b:pubsub:2008"> 
                    <rim:AdhocQuery id="urn:uuid:14d4debf-8f97-4251-9a74-a90016b0af0d">
                        <rim:Slot name="$XDSDocumentEntryPatientId">
                            <rim:ValueList>
                                <rim:Value>'st3498702^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO'</rim:Value>
                            </rim:ValueList>
                        </rim:Slot>
                        <rim:Slot name="$XDSDocumentEntryHealthcareFacilityTypeCode">
                            <rim:ValueList>
                                <rim:Value>('Emergency Department')</rim:Value>
                            </rim:ValueList>
                          </rim:Slot>
                    </rim:AdhocQuery>
                </wsnt:TopicExpression>
            </wsnt:Filter>
            <wsnt:InitialTerminationTime>2008-05-31T00:00:00.00000Z</wsnt:InitialTerminationTime>
        </wsnt:Subscribe>
    </s:Body>
</s:Envelope>

The URN identifying the Topics dialect in this example is defined in the Topics and Filter Expressions section of this white paper.

Subscription Request Response

Trigger

This message is an immediate response to a Subscription Request, and it is sent from the Notification Broker to the Subscriber.

Message Semantics

The Subscription Request Response message SHALL comply with the requirements in the WS-BaseNotification standard.

The subscription identifier is assigned by the Notification Broker as a Web Services end point, communicated in the response in the SOAP body in wsnt:SubscribeResponse/wsnt:SubscriptionReference. In order to modify the subscription, or to unsubscribe, these requests are sent to this SubscriptionReference end point.

Expected Actions

The Subscriber SHALL associate the accepted subscription request with the subscription reference address assigned by the Notification broker in order to be able to send modifications or cancellations for existing subscriptions.

Example

<?xml version="1.0" encoding="UTF-8"?>
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
    xmlns:a="http://www.w3.org/2005/08/addressing"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2"
    xsi:schemaLocation="http://www.w3.org/2003/05/soap-envelope http://www.w3.org/2003/05/soap-envelope http://www.w3.org/2005/08/addressing http://www.w3.org/2005/08/addressing/ws-addr.xsd http://docs.oasis-open.org/wsn/b-2 http://docs.oasis-open.org/wsn/b-2.xsd">
    <s:Header>
        <a:Action>http://docs.oasis-open.org/wsn/bw-2/NotificationProducer/SubscribeResponse</a:Action>
    </s:Header>
    <s:Body>
        <wsnt:SubscribeResponse>
            <!-- A WS endpoint, where modification and cancelation requests for this subscription must be sent -->
            <wsnt:SubscriptionReference>
                <a:Address>https://NotificationBrokerServer/Unique Subscription/382dcdc7-8e84-9fdc-8443-48fd83bca938</a:Address>
            </wsnt:SubscriptionReference>
        </wsnt:SubscribeResponse>
    </s:Body>
</s:Envelope>

Subscription Renewal

Trigger

The need for a Notification Consumer to modify an existing subscription will cause the associated Subscriber to trigger a Subscription Renewal message.

Message Semantics

This message conveys a different termination time for an existing subscription. This message SHALL NOT be used to modify other subscription parameters of an existing subscription. This message SHALL NOT be used for subscriptions which are past their termination time.

Expected Actions

The subscriber SHALL send this message to the unique Web Services end point associated with the existing subscription.

The Notification Broker SHALL modify the corresponding subscription, and respond with an Subscription Renewal Response message.

Example

<?xml version="1.0" encoding="UTF-8"?>
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
    xmlns:a="http://www.w3.org/2005/08/addressing"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2"
    xsi:schemaLocation="http://www.w3.org/2003/05/soap-envelope http://www.w3.org/2003/05/soap-envelope http://www.w3.org/2005/08/addressing http://www.w3.org/2005/08/addressing/ws-addr.xsd http://docs.oasis-open.org/wsn/b-2 http://docs.oasis-open.org/wsn/b-2.xsd">
    <s:Header>
        <a:Action>http://docs.oasis-open.org/wsn/bw-2/SubscriptionManager/RenewRequest</a:Action>
        <a:MessageID>382dcdc8-8e85-9fdd-8444-48fd83bca939</a:MessageID>
        <a:To>https://NotificationBrokerServer/Unique Subscription/382dcdc7-8e84-9fdc-8443-48fd83bca938</a:To>
    </s:Header>
    <s:Body>
        <wsnt:Renew>
            <!-- This illustrates the use of the xs:duration XML Schema data type - the subscription ends after one day -->
            <wsnt:TerminationTime>P1D</wsnt:TerminationTime>
        </wsnt:Renew>
    </s:Body>
</s:Envelope>

The subscription modification example above shows the use of another way to specify subscription duration - using the XML Schema duration data type instead of a time stamp. The renewal response below uses the XML Schema dateTime datatype to indicate the precise moment in time when the subscription will expire.

Subscription Renewal Response

Trigger

This message is an immediate response to a Subscription Renewal message and is sent from the Notification Broker to the Subscriber.

Message Semantics

The message contains the new termination time of the subscription.

Expected Actions

The Subscriber SHALL update the termination time of the existing subscription with the new time as sent by the Notification Broker.

Example

<?xml version="1.0" encoding="UTF-8"?>
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
    xmlns:a="http://www.w3.org/2005/08/addressing"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2"
    xsi:schemaLocation="http://www.w3.org/2003/05/soap-envelope http://www.w3.org/2003/05/soap-envelope http://www.w3.org/2005/08/addressing http://www.w3.org/2005/08/addressing/ws-addr.xsd http://docs.oasis-open.org/wsn/b-2 http://docs.oasis-open.org/wsn/b-2.xsd">
    <s:Header>
        <a:Action>http://docs.oasis-open.org/wsn/bw-2/SubscriptionManager/RenewResponse</a:Action>
    </s:Header>
    <s:Body>
        <wsnt:RenewResponse>
            <wsnt:TerminationTime>2008-05-22T15:39:14-05:00</wsnt:TerminationTime>
        </wsnt:RenewResponse>
    </s:Body>
</s:Envelope>

Unsubscribe

Trigger

When a subscription is no longer needed, a Subscriber will trigger an Unsubscribe message.

Message Semantics

The message conveys the request to cancel an existing subscription.

Expected Actions

The subscriber SHALL send this message to the unique Web Services end point associated with the existing subscription.

The Notification Broker SHALL cancel the corresponding subscription, and respond with an Unsubscribe Response message.

Example

<?xml version="1.0" encoding="UTF-8"?>
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
    xmlns:a="http://www.w3.org/2005/08/addressing"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2"
    xsi:schemaLocation="http://www.w3.org/2003/05/soap-envelope http://www.w3.org/2003/05/soap-envelope http://www.w3.org/2005/08/addressing http://www.w3.org/2005/08/addressing/ws-addr.xsd http://docs.oasis-open.org/wsn/b-2 http://docs.oasis-open.org/wsn/b-2.xsd">
    <s:Header>
        <a:Action>http://docs.oasis-open.org/wsn/bw-2/SubscriptionManager/UnsubscribeRequest</a:Action>
        <a:MessageID>382dcdc9-8e86-9fde-8445-48fd83bca93a</a:MessageID>
        <a:To>https://NotificationBrokerServer/Unique Subscription/382dcdc7-8e84-9fdc-8443-48fd83bca938</a:To>
    </s:Header>
    <s:Body>
        <wsnt:Unsubscribe/>
    </s:Body>
</s:Envelope>

Unsubscribe Response

Trigger

This message is an immediate response to an Unsubscribe message, and it is sent from the Notification Broker to the Subscriber.

Message Semantics

This message indicates that an Unsubscribe message was successfully processed.

Expected Actions

The Notification Broker SHALL cancel the corresponding subscription.

The Subscriber SHALL mark the corresponding subscription as successfully terminated.

Example

<?xml version="1.0" encoding="UTF-8"?>
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
    xmlns:a="http://www.w3.org/2005/08/addressing"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2"
    xsi:schemaLocation="http://www.w3.org/2003/05/soap-envelope http://www.w3.org/2003/05/soap-envelope http://www.w3.org/2005/08/addressing http://www.w3.org/2005/08/addressing/ws-addr.xsd http://docs.oasis-open.org/wsn/b-2 http://docs.oasis-open.org/wsn/b-2.xsd">
    <s:Header>
        <a:Action>http://docs.oasis-open.org/wsn/bw-2/SubscriptionManager/UnsubscribeRequest</a:Action>
    </s:Header>
    <s:Body>
        <wsnt:UnsubscribeResponse/>
    </s:Body>
</s:Envelope>

Notify

Scope

Use Case Roles

Actor: Notification Broker
Role: Sends notifications to subscribed Notification Consumers based on events occurring in an XDS.b Document Registry
Actor: Notification Consumer
Role: Receives and processes notifications about events matching a set of filter expressions.

Referenced Standards

[6]: OASIS Web Services Notification Family of Standards
[7]: WS-BaseNotification 1.3 OASIS Standard
[8]: WS-BrokeredNotification 1.3 OASIS Standard
[9]: WS-Topics 1.3 OASIS Standard
[10]: IHE ITI TF - Registry Stored Query Transaction

Interaction Diagram

Notify sequence

Notification

Trigger

When an event occurs, where the topics of the event match the filter requirements of one or more existing subscriptions, the Notification Broker will trigger a Notification message to the corresponding Notification Consumer.

Message Semantics

The events, for which a Notification Consumer within an XDS Affinity Domain subscribes, are registrations at the XDS-b Registry. While this paper does not specify how the Notification Broker becomes aware of the registrations, there are several possible approaches:

Combined actor: XDS-b Registry and Notification Broker
Forwarded transaction: The XDS-b Registry can be enhanced to forward all Register transactions to the Notification Broker. ebXML-RS 3.0 contains this registry functionality already
Proxy: The Notification Broker can sit in front of the registry and intercept all Register transactions sent by Document Repositories, before forwarding them to the Registry

Depending on the XDS submission, which triggered the notification, there may be one or more documents whose metadata matches the filter conditions of each corresponding subscription. The notification message contains the document unique ID of each document relevant to the particular Notification Consumer.

Expected Actions

The Notification Consumer needs to convey the notification information to other systems and/or users. An XDS.b Document Consumer can then use the information to obtain the metadata about the document(s) from the XDS.b registry as necessary for the relevant workflows. This white paper does not specify how the Document Unique ID is conveyed from the Notification Consumer to an XDS.b Document Consumer. One possible solution is to have a combined Notification Consumer/Document Consumer actor, or even a Subscriber/Notification Consumer/Document Consumer actor.

The Notification Broker MAY send the filter conditions of the subscription, and/or the address of the Document Source where the document submission originated. Both of these options increase certain security risks, their use should be determined by local policy to security and confidentiality.

Example

<?xml version="1.0" encoding="UTF-8"?>
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
    xmlns:a="http://www.w3.org/2005/08/addressing"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2"
    xmlns:ihe="urn:ihe:iti:xds-b:2007"
    xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
    xsi:schemaLocation="http://www.w3.org/2003/05/soap-envelope http://www.w3.org/2003/05/soap-envelope http://www.w3.org/2005/08/addressing http://www.w3.org/2005/08/addressing/ws-addr.xsd http://docs.oasis-open.org/wsn/b-2 http://docs.oasis-open.org/wsn/b-2.xsd urn:ihe:iti:xds-b:2007 ../schema/IHE/XDS.b_DocumentRepository.xsd urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0 ../schema/ebRS/rim.xsd">
    <s:Header>
        <a:Action>http://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/Notify</a:Action>
        <a:MessageID>382dcdca-8e87-9fdf-8446-48fd83bca93b</a:MessageID>
        <a:To>https://NotificationConsumerServer/xdsBnotification</a:To>
    </s:Header>
    <s:Body>
        <wsnt:Notify>
            <wsnt:NotificationMessage>
                <wsnt:SubscriptionReference>
                    <a:Address>https://NotificationBrokerServer/Unique Subscription/382dcdc7-8e84-9fdc-8443-48fd83bca938</a:Address>
                </wsnt:SubscriptionReference>
                <wsnt:Topic Dialect="urn:ihe:iti:xds-b:pubsub:2008"> 
                    <rim:AdhocQuery id="urn:uuid:14d4debf-8f97-4251-9a74-a90016b0af0d">
                        <rim:Slot name="$XDSDocumentEntryPatientId">
                            <rim:ValueList>
                                <rim:Value>'st3498702^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO'</rim:Value>
                            </rim:ValueList>
                        </rim:Slot>
                        <rim:Slot name="$XDSDocumentEntryHealthcareFacilityTypeCode">
                            <rim:ValueList>
                                <rim:Value>('Emergency Department')</rim:Value>
                            </rim:ValueList>
                        </rim:Slot>
                    </rim:AdhocQuery>
                </wsnt:Topic>
                <wsnt:ProducerReference>
                    <a:Address>https://DocumentSource</a:Address>
                </wsnt:ProducerReference>
                <wsnt:Message>
                    <ihe:DocumentUniqueId>1.3.2458.2423.456.5.3.5</ihe:DocumentUniqueId>
                </wsnt:Message>
            </wsnt:NotificationMessage>
        </wsnt:Notify>
    </s:Body>
</s:Envelope>

Note to reader: providing the complete metadata for the submission set is another option for content of wsnt:Message element

Subscription Topics and Filter Expressions

Subscription topics are the concepts used for describing under what conditions the subscriber would like to receive a notification. Filter expressions bind topics to a particular value (or set of values) and combine them into expressions describing the actual conditions. Topics are context dependent, and as such are closely related to the information for which a subscription is requested. At the same time, the ability of the Subscription Manager to quickly process and publish the notifications may depend on the ease of computability of the topics.

Topics for XDS.b Publish/Subscribe

The XDS.b profile specifies the particular metadata which is registered about the documents being shared. The Stored Query transaction (ITI-18) uses a subset of the metadata to build a list of queries available to a XDS Document Consumer to search for documents with specific characteristics. The list of queries is in section 3.18.4.1.2.3.7 currently in the TF Supplement for trial implementation. This paper chooses to restrict the list of topics to the metadata represented by query parameters, and restrict the semantics of filter expressions to the semantics of the corresponding stored query.

Building Filter Expressions

The filter expressions used in this white paper use the syntax of the Stored Query transaction. In order to identify this syntax, the following URN is hereby defined as the "topics dialect":

urn:ihe:iti:xds-b:pubsub:2008

A good understanding of the Stored Query transaction and the XDS.b metadata is necessary to understand how the filter expressions work. In general, for each submission set registered, the filter expression will yield a match, if the corresponding query would return the same object(s) from an XDS.b registry, which contained only this submission set. For example, the stored query

<rim:AdhocQuery id="urn:uuid:14d4debf-8f97-4251-9a74-a90016b0af0d" xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0">
    <rim:Slot name="$XDSDocumentEntryPatientId">
        <rim:ValueList>
            <rim:Value>'st3498702^^^&1.3.6.1.4.1.21367.2005.3.7&ISO'</rim:Value>
        </rim:ValueList>
    </rim:Slot>
    <rim:Slot name="$XDSDocumentEntryEventCodeList">
        <rim:ValueList>
            <rim:Value>('44950' '44955' '44960' '44970' '44979')</rim:Value>
        </rim:ValueList>
    </rim:Slot>
</rim:AdhocQuery>

will return all document entries for patient with ID st3498702 (assigned by an authority identified by the OID 1.3.6.1.4.1.21367.2005.3.7) where the event code metadata contains at least one of the codes listed (in this case CPT codes for various appendectomies). When used as a filter expression, the same structure will yield a match against a document entry in an XDS.b registry submission, where the document entry is for patient with ID st3498702 and the event code is "44970". The following snippet shows an example of such a submission:

<lcm:SubmitObjectsRequest>
    <rim:RegistryObjectList>
        <rim:ExtrinsicObject id="Document01" mimeType="text/xml" objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1">
...
            <rim:Classification classificationScheme="urn:uuid:2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4" classifiedObject="Document01" nodeRepresentation="44950">
                <rim:Name>
                    <rim:LocalizedString value="Appendectomy"/>
                </rim:Name>
                <rim:Slot name="codingScheme">
                    <rim:ValueList>
                        <rim:Value>CPT codes</rim:Value>
                    </rim:ValueList>
                </rim:Slot>
            </rim:Classification>
...
            <rim:ExternalIdentifier id="ei01" registryObject="Document01" identificationScheme="urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427" value="'st3498702^^^&1.3.6.1.4.1.21367.2005.3.7&ISO'">
	        <rim:Name>
                    <rim:LocalizedString value="XDSDocumentEntry.patientId"/>
                </rim:Name>
            </rim:ExternalIdentifier>
...
        <rim:ExtrinsicObject>
    </rim:RegistryObjectList>

When a filter expression is constructed, the whole stored query expression (as shown above) is included directly in the Subscribe Request message:

<?xml version="1.0" encoding="UTF-8"?>
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
    xmlns:a="http://www.w3.org/2005/08/addressing"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2"
    xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
    xsi:schemaLocation="http://www.w3.org/2003/05/soap-envelope http://www.w3.org/2003/05/soap-envelope http://www.w3.org/2005/08/addressing http://www.w3.org/2005/08/addressing/ws-addr.xsd http://docs.oasis-open.org/wsn/b-2 http://docs.oasis-open.org/wsn/b-2.xsd urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0 ../schema/ebRS/rim.xsd">
    <s:Header>
        <a:Action>http://docs.oasis-open.org/wsn/bw-2/NotificationProducer/SubscribeRequest</a:Action>
        <a:MessageID>382dcdc7-8e84-9fdc-8443-48fd83bca938</a:MessageID>
    </s:Header>
    <s:Body>
        <wsnt:Subscribe>
            <!-- The Consumer on whose behalf the subscription is requested - the address where the notification is to be sent -->
            <wsnt:ConsumerReference>
                <a:Address>https://NotificationConsumerServer/xdsBnotification</a:Address>
            </wsnt:ConsumerReference>
            <wsnt:Filter>
                <wsnt:TopicExpression Dialect="urn:ihe:iti:xds-b:pubsub:2008"> 
                    <rim:AdhocQuery id="urn:uuid:14d4debf-8f97-4251-9a74-a90016b0af0d">
                        <rim:Slot name="$XDSDocumentEntryPatientId">
                            <rim:ValueList>
                                <rim:Value>'st3498702^^^&1.3.6.1.4.1.21367.2005.3.7&ISO'</rim:Value>
                            </rim:ValueList>
                        </rim:Slot>
                        <rim:Slot name="$XDSDocumentEntryEventCodeList">
                            <rim:ValueList>
                                <rim:Value>('44950' '44955' '44960' '44970' '44979')</rim:Value>
                            </rim:ValueList>
                        </rim:Slot>
                    </rim:AdhocQuery>
                </wsnt:TopicExpression>
            </wsnt:Filter>
            <wsnt:InitialTerminationTime>2008-07-31T00:00:00.00000Z</wsnt:InitialTerminationTime>
        </wsnt:Subscribe>
    </s:Body>
</s:Envelope>

How the filter expression is evaluated, and how the matching against the existing subscriptions is done is out of scope of this white paper. It is expected that such implementation detail will allow vendors to differentiate themselves in the marketplace.

It is important to note that not all stored queries, and not all parameters defined for the stored queries, are suitable for filter expressions. The following stored queries and associated parameters can be used in subscription requests:

Subscriptions based on FindDocuments query

Filter expressions based on the FindDocuments stored query will yield a match any time a document entry for a particular patient, and with the appropriate metadata restrictions, is part of a registry submission.

$XDSDocumentEntryPatientId: this required parameter contains the patient ID for which a document entry is being registered in the XDS.b registry
$XDSDocumentEntryClassCode and $XDSDocumentEntryClassCodeScheme: these parameters match against the XDSDocumentEntry.classCode metadata elements in a given registry submission
$XDSDocumentEntryPracticeSettingCode and $XDSDocumentEntryPracticeSettingCodeScheme: these parameters match against the XDSDocumentEntry.practiceSettingCode metadata elements in a given registry submission
$XDSDocumentEntryHealthcareFacilityTypeCode and $XDSDocumentEntryHealthcareFacilityTypeCodeScheme: these parameters match against the XDSDocumentEntry.healthcareFacilityTypeCode metadata elements in a given registry submission
$XDSDocumentEntryEventCodeList and $XDSDocumentEntryEventCodeListScheme: these parameters match against the XDSDocumentEntry.eventCodeList metadata elements in a given registry submission
$XDSDocumentEntryConfidentialityCode and $XDSDocumentEntryConfidentialityCodeScheme: these parameters match against the XDSDocumentEntry.confidentialityCode metadata elements in a given registry submission
$XDSDocumentEntryFormatCode: this parameter matches against the XDSDocumentEntry.formatCode metadata elements in a given registry submission

Subscriptions based on FindSubmissionSets query

Filter expressions based on the FindSubmissionSets stored query can be used to subscribe for events, where the source ID, author, or content type of submission sets about a particular patient are the topics of the subscription.

$XDSSubmissionSetPatientId: this required parameter contains the patient ID for which a submission set is being registered in the XDS.b registry
$XDSSubmissionSetSourceId: this parameter matches against the XDSSubmissionSet.sourceId metadata elements in a given registry submission
$XDSSubmissionSetAuthorPerson: this parameter matches against the XDSSubmissionSet.authorPerson metadata elements in a given registry submission
$XDSSubmissionSetContentType: this parameter matches against the XDSSubmissionSet.contentTypeCode metadata elements in a given registry submission

Subscriptions based on FindFolders query

Filter expressions based on the FindFolders stored query can be used to subscribe for patient-specific events related to Folders with a particular code or set of codes.

$XDSFolderPatientId: this required parameter contains the patient ID associated with the folder, for which a submission set is being registered in the XDS.b registry
$XDSFolderCodeList and $XDSFolderCodeListScheme: these parameters match against the XDSFolder.codeList metadata elements in a given registry submission

Note to Reader: Document-centric queries are not included in this list. Any use cases supporting inclusion of these queries in the list are welcome.

Combining topics in filter expressions

A filter expression is equivalent to a specific stored query with certain parameters. Topics expressed as query parameters and used in the expressions must satisfy the same requirements as a corresponding Stored Query:

the values for all specified topics must match (AND all different topics)
at least one of the values of multivalued parameters must match (OR the values in a multivalued query parameter)

Since the current catalog of queries for Stored Query always has either the patient ID or the document ID as a required parameter, subscriptions are only allowed on a per-patient or per-document basis.

Note that there are various other ways to specify topics, and filter expressions. One of the most common is the use of XPath expressions as the filter expression. Future extensions to this white paper and future profiles can and should investigate the feasibility of this and other alternative approaches.

Return to ITI Technical Committee

ITI White Paper: Publish/Subscribe Infrastructure

Overview, Use Cases, and Definitions

Introduction

Issue Log

Open Issues

Closed Issues

Future development

Use cases

Unexpected notification

Long-term subscription

Antepartum Record Availability

Public Health Surveillance

Actors/Transactions

Actor Definitions

Subscriber

Notification Broker

Notification Consumer

Transaction Definitions

Subscribe

Notify

Detailed Transaction Definitions

Subscribe

Scope

Use Case Roles

Referenced Standards

Interaction Diagram

Subscription Request

Trigger

Message Semantics

Expected Actions

Example

Subscription Request Response

Trigger

Message Semantics

Expected Actions

Example

Subscription Renewal

Trigger

Message Semantics

Expected Actions

Example

Subscription Renewal Response

Trigger

Message Semantics

Expected Actions

Example

Unsubscribe

Trigger

Message Semantics

Expected Actions

Example

Unsubscribe Response

Trigger

Message Semantics

Expected Actions

Example

Notify

Scope

Use Case Roles

Referenced Standards

Interaction Diagram

Notification

Trigger

Message Semantics

Expected Actions

Example

Subscription Topics and Filter Expressions

Topics for XDS.b Publish/Subscribe

Building Filter Expressions

Subscriptions based on FindDocuments query

Subscriptions based on FindSubmissionSets query

Subscriptions based on FindFolders query

Combining topics in filter expressions

Navigation menu

Search