ITI White Paper: Publish/Subscribe Infrastructure

From IHE Wiki
Jump to navigation Jump to search

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

  1. This white paper uses WS-Notification. Is this choice appropriate?
  2. Notification or pushing: the notification can be just a DocID, the Metadata, or the full full document. This white paper uses the Document ID as the notification.
  3. Topics

Closed Issues

  1. The PCC APS profile may have a specific use case of interest. Added to use cases
  2. 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

Future development

  1. 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 and Transactions

New Actors within an XDS-b affinity domain

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/Notification Broker

The Subscription Manager/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 all 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 is always combined with the XDS-b Document Registry actor.

Notification 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

Subscribe

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. Modification of the subscription can be achieved by sending a new subscription request, followed by a cancellation of the original subscription. Any subscribe actor can cancel a subscription, as long as they have the subscription id.

Examples

  1. Oasis WS-Notification, v. 1.3

Subscription Request: 

<s:Envelope ... >
  <s:Header>
    <wsa:Action>
      http://docs.oasis-open.org/wsn/bw-2/NotificationProducer/SubscribeRequest
    </wsa:Action>
    ...
  </s:Header>
  <s:Body>
    <wsnt:Subscribe>
      <wsnt:ConsumerReference>
        <wsa:Address>
          http://www.example.org/NotificationConsumer
        </wsa:Address>
      </wsnt:ConsumerReference>
      <wsnt:Filter>
        <wsnt:TopicExpression Dialect="http://docs.oasis-open.org/wsn/t-1/TopicExpression/Simple">
            npex:SomeTopic
        </wsnt:TopicExpression>
        <wsnt:MessageContent Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">
            boolean(ncex:Producer="15")
        </wsnt:MessageContent>
      </wsnt:Filter>
      <wsnt:InitialTerminationTime>
          2005-12-25T00:00:00.00000Z
      </wsnt:InitialTerminationTime>
    </wsnt:Subscribe>
  </s:Body>
</s:Envelope>

Subscription Request Response: 

<s:Envelope ... >
  <s:Header>
    <wsa:Action>
      http://docs.oasis-open.org/wsn/bw-2/NotificationProducer/SubscribeResponse
    </wsa:Action>
    ...
  </s:Header>
  <s:Body>
    <wsnt:SubscribeResponse>
      <wsnt:SubscriptionReference>
        <wsa:Address>
          <!--A referencable URL uniquely identifying the subscription request-->
        </wsa:Address>
      </wsnt:SubscriptionReference>
    </wsnt:SubscribeResponse>
  </s:Body>
</s:Envelope>

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

Subscription renewal 

<s:Envelope ... >
  <s:Header>
    <wsa:Action>
      http://docs.oasis-open.org/wsn/bw-2/SubscriptionManager/RenewRequest
    </wsa:Action>
    ...
  </s:Header>
  <s:Body>
    <wsnt:Renew>
      <wsnt:TerminationTime>P1D</wsnt:TerminationTime>
    </wsnt:Renew>
  </s:Body>
</s:Envelope>

Renewal repsonse 

<s:Envelope ... >
  <s:Header>
    <wsa:Action>
      http://docs.oasis-open.org/wsn/bw-2/SubscriptionManager/RenewResponse
    </wsa:Action>
    ...
  </s:Header>
  <s:Body>
    <wsnt:RenewResponse>
      <wsnt:TerminationTime>
        2005-12-26T00:00:00.00000Z
      </wsnt:TerminationTime>
    </wsnt:RenewResponse>
  </s:Body>
</s:Envelope>

Unsubscribe 

<s:Envelope ... >
  <s:Header>
    <wsa:Action>
      http://docs.oasis-open.org/wsn/bw-2/SubscriptionManager/UnsubscribeRequest
    </wsa:Action>
    ...
  </s:Header>
  <s:Body>
    <wsnt:Unsubscribe>
      <!-- Optional XDS-specific data -->
    </wsnt:Unsubscribe>
  </s:Body>
</s:Envelope>

Unsubscribe response 

<s:Envelope ... >
  <s:Header>
    <wsa:Action>
      http://docs.oasis-open.org/wsn/bw-2/SubscriptionManager/UnsubscribeResponse
    </wsa:Action>
    ...
  </s:Header>
  <s:Body>
    <wsnt:UnsubscribeResponse>
      <!-- Optional XDS-specific XML content -->
    </wsnt:UnsubscribeResponse>
  </s:Body>
</s:Envelope>

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 Notification Recepients, 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.

Examples:

  1. Oasis WS-Notification, v. 1.3
<s:Envelope ... >
  <s:Header>
    <wsa:Action>
      http://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/Notify
    </wsa:Action>
    ...
  </s:Header>
  <s:Body>
    <wsnt:Notify>
      <wsnt:NotificationMessage>
        <wsnt:SubscriptionReference>
          <wsa:Address>
            http://www.example.org/SubscriptionManager
          </wsa:Address>
        </wsnt:SubscriptionReference>
        <wsnt:Topic Dialect="http://docs.oasis-open.org/wsn/t-1/TopicExpression/Simple">
          npex:SomeTopic
        </wsnt:Topic>
        <wsnt:ProducerReference>
          <wsa:Address>
            http://www.example.org/NotificationProducer
          </wsa:Address>
        </wsnt:ProducerReference>
        <wsnt:Message>
          <npex:NotifyContent>
            <!-- XDS specific content -->
          </npex:NotifyContent>
        </wsnt:Message>
      <wsnt:NotificationMessage>
    </wsnt:Notify>
  </s:Body>
</s:Envelope>

There is an option to have "raw" notification, where the content of the SOAP body could be the SOAP body of a Register transaction.

  1. Register transaction - optional
  2. Provide and register - Not a good idea
  3. Document Entry UUID (for use with GetDocument query) - required

<<Note: have an example of how to specify 3 or 1>>

Subscription Topics

Subscription topics, or filters, are the mechanism describing under what conditions the subscriber would like to receive a notification. 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 Publish/Subscribe

The XDS profile specifies the particular meta data which is registered about the documents being shared. The Stored Query transaction 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. The following parameters, used by those queries, are appropriate as topics for the XDS publish/subscribe framework (unless otherwise marked).

Parameter Metadata Not appropriate
$XDSDocumentEntryClassCode XDSDocumentEntry.classCode
$XDSDocumentEntryClassCodeScheme XDSDocumentEntry.classCode
$XDSDocumentEntryPracticeSettingCode XDSDocumentEntry.practiceSettingCode
$XDSDocumentEntryPracticeSettingCodeScheme XDSDocumentEntry.practiceSettingCode
$XDSDocumentEntryCreationTimeFrom Lower value of XDSDocumentEntry.creationTime X
$XDSDocumentEntryCreationTimeTo Upper value of XDSDocumentEntry.creationTime X
$XDSDocumentEntryServiceStartTimeFrom Lower value of XDSDocumentEntry.serviceStartTime X
$XDSDocumentEntryServiceStartTimeTo Upper value of XDSDocumentEntry.serviceStartTime X
$XDSDocumentEntryServiceStopTimeFrom Lower value of XDSDocumentEntry.serviceStopTime X
$XDSDocumentEntryServiceStopTimeTo Upper value of XDSDocumentEntry.serviceStopTime X
$XDSDocumentEntryHealthcareFacilityTypeCode XDSDocumentEntry.healthcareFacilityTypeCode
$XDSDocumentEntryHealthcareFacilityTypeCodeScheme XDSDocumentEntry.healthcareFacilityTypeCode
$XDSDocumentEntryEventCodeList XDSDocumentEntry.eventCodeList
$XDSDocumentEntryEventCodeListScheme XDSDocumentEntry.eventCodeList
$XDSDocumentEntryConfidentialityCode XDSDocumentEntry.confidentialityCode
$XDSDocumentEntryConfidentialityCodeSchem XDSDocumentEntry.confidentialityCode
$XDSDocumentEntryFormatCode XDSDocumentEntry.formatCode
$XDSDocumentEntryStatus XDSDocumentEntry.status

<<The parameters of the rest of the queries will be added>>

Combining topics

Options:

  1. Full boolean expressions
  2. Individual topics ANDed or ORed
  3. Equality and negation only - set is good, Stored Query allows multiple values
  4. Single topics only
  5. Use Regular expressions?

Profiling of topics?
Limit it to what can be semantically expressed via stored queries, but we need to also mention that the pub/sub infrastructure allows for future expansions/profiling
Abstract model for Pub/Sub - not now

Next steps

Review standards for transactions; more detailed discussion topics

Appendix A: Notes



Return to ITI Technical Committee

Retrieved from "http://wiki.ihe.net/index.php?title=ITI_White_Paper:_Publish/Subscribe_Infrastructure&oldid=18185"