2008 Detailed Profile Proposal: IHE ITI Publish/Subscribe Profile

This proposal is based on the Publish/Subscribe Infrastructure for XDS.b white paper. The general ITI Publish Subscribe wiki page contains the most up-to-date information on this topic.

1. Proposed Workitem: ITI Publish/Subscribe Infrastructure

Proposal Editor: Vassil Peytchev
Editor: Vassil Peytchev
Date: N/A (Wiki keeps history)
Version: N/A (Wiki keeps history)
Domain: IT Infrastructure

Summary

Various healthcare workflows, both inside and outside the enterprise, require event-based data exchange among systems. There is currently no standard way for healthcare applications or systems to declare interest in, or manage the exchange of event-based information.

OASIS has a family of standards for web services notification, which can be used as a generic publish/subscribe framework. This profile will describe the parts of these standards which are appropriate for such a framework.

The ITI publish/subscribe profile will describe the actors and transactions in the framework, and will describe a mechanism for binding content-specific topics within the framework. A binding for XDS.b will be included as an illustration.

There is a significant interest in a publish/subscribe framework in the quality, research, and public health area. A significant uptake of this profile is expected among vendors and public health agencies.

2. The Problem

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 profile will provide the underlying infrastructure for publish/subscribe interactions, which other profiles and domains can reuse within their specifications.

3. Key Use Case

The use case describes the use of a publish/subscribe infrastructure together with an XDS.b content profile, which determines how topics and filters are used.

How it works with current XDS

Person A visits his PCP with week-old trauma to his foot. Concerned about possible fracture and infection, the PCP orders x-ray and a lab panel, and refers him to a specialist. Upon receiving the referral (which is out of scope here), the specialist queries the document registry, and received the referral summary. Noticing the outstanding radiology and lab orders, the specialist, or the staff at the specialist's practice, will have to periodically query the registry to retrieve the radiology and lab reports.

How it should work

Person A visits his PCP with week-old trauma to his foot. Concerned about possible fracture and infection, the PCP orders x-ray and a lab panel, and refers him to a specialist. Upon receiving the referral (which is out of scope here), the specialist queries the document registry, and received the referral summary. The specialist also subscribes for any additional information about the patient. As the radiology and lab reports are submitted to the registry, a notification is sent to the specialist's system, and an XDS document retrieve transaction is executed.

4. Standards & Systems

Standards and specifications:

The ITI publish/subscribe framework will involve new systems, which will implement the new actors specified bellow. It is expected that in various subject areas, the new actors would affect existing systems, as it will be beneficial to group them with existing infrastructure actors, and therefore systems. An example is XDS.b where the Subscriber, Notification Broker, and Notification Recipient can be grouped with document consumer and document registry actors.

5. Technical Approach

The proposed profile will refer to the OASIS Web Services Notification standards to define the appropriate transactions. A pub/sub binding to XDS.b will reference the ebXML Registry standards. A possible generic format for topics and filters will reference XPath 2.0.

Existing actors

Existing actors in other profiles may be grouped with one or more of the actors introduced in the publish/subscribe profile.

New actors

Subscriber - sends subscription management requests to the Notification Broker on behalf of a Notification Consumer
Notification Broker - Manages subscriptions and topics
Notification Consumer - receives notifications from the notification broker based on its current subscriptions
Publisher - publishes content to the notification broker to be sent to current subscribers

Existing transactions

No existing transactions will be affected by this profile. It is possible that some existing transactions may be re-used when a binding of the pub/sub profile to an existing profile is specified.

New transactions (standards used)

Subscribe - sent from the Subscriber to the Notification Broker
Notify - sent from the Notification Broker to the Notification Consumer
Publish - sent from the publisher to the Notification Broker

Impact on existing integration profiles

Existing profiles will have the opportunity to add publish/subscribe functionlity via bindings of this profile.

New integration profiles needed

This proposal is for a new profile, describing general publish/subscribe functionality. The new profile will describe the mechanism by which other integration profiles can add publish/subscribe functionality. It will likely have sections for different message exchange patterns (MEP) as well as different technologies (HL7, HL7V3, DICOM).

Breakdown of tasks that need to be accomplished

Generalize pub/sub transactions and actors (including the Publisher actor and a Publish transaction) based on the current pub/sub white paper.
Develop binding specifications
- Determine how bindings will be described (based on MEP and/or content)
- Determine how formats for topics and filters will be specified
- Determine if general XPath expressions need to be specified as a generic format
Based on the current pub/sub white paper, create a pub/sub binding for XDS.b
- include risk analysis for pub/sub functionality in the context of XDS.b

6. Support & Resources

There is wide support for this proposal among in the public health and bio-surveillance domains, and there are several offers for help in the development of the profile.

7. Risks

The main technical risk for this profile is to create a framework which could exclude a particular technology, or particular format. A political risk would be to produce a specification incompatible with some unknown parallel effort in he same area.

8. Open Issues

Use of SOAP 1.2 - IHE is promoting the use of SOAP 1.2 as the preferred web services format. Will the constraint to use SOAP 1.2 cause hardship to implementers of the profile?
Use of web services - the proposed standard is based on web services, however the format of the topics and filters needs to allow for arbitrary content, due to the widespread use of non-XML formats in the healthcare industry (e.g. DICOM, HL7, X12, etc.). Will the profile be able to accomodate non-XML content?

9. Tech Cmte Evaluation

<The technical committee will use this area to record details of the effort estimation, etc.>

Effort Evaluation (as a % of Tech Cmte Bandwidth):

<35% for ...>

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

Vassil Peytchev