2008 Detailed Profile Proposal: IHE ITI Publish/Subscribe Profile

This proposal is based on the Publish/Subscribe Infrastructure for XDS.b white paper.

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:

• IHE ITI White Paper: Publish/Subscribe Infrastructure for XDS.b
• OASIS Web Services Notification Family of Standards
• XPAth 2.0

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 Subcriber, Notification Broker, and xxxx can be grouped with document consumer and document registry actors.

5. Technical Approach

<This section can be very short but include as much detail as you like. The Technical Committee will flesh it out when doing the effort estimation.>

<Outline how the standards could be used/refined to solve the problems in the Use Cases. The Technical Committee will be responsible for the full design and may choose to take a different approach, but a sample design is a good indication of feasibility.>

<If a phased approach would make sense indicate some logical phases. This may be because standards are evolving, because the problem is too big to solve at once, or because there are unknowns that won’t be resolved soon.>

Existing actors

<Indicate what existing actors could be used or might be affected by the profile.>

New actors

<List possible new actors>

Existing transactions

<Indicate how existing transactions might be used or might need to be extended.>

New transactions (standards used)

<Describe possible new transactions (indicating what standards would likely be used for each. Transaction diagrams are very helpful here. Feel free to go into as much detail as seems useful.>

Impact on existing integration profiles

<Indicate how existing profiles might need to be modified.>

New integration profiles needed

<Indicate what new profile(s) might need to be created.>

Breakdown of tasks that need to be accomplished

<A list of tasks would be helpful for the technical committee who will have to estimate the effort required to design, review and implement the profile.>

6. Support & Resources

<List groups that have expressed support for the proposal and resources that would be available to accomplish the tasks listed above.>

7. Risks

<List technical or political risks that could impede successfully fielding the profile.>

8. Open Issues

<Point out any key issues or design problems. This will be helpful for estimating the amount of work and demonstrates thought has already gone into the candidate profile.>

<If there are no Open Issues at Evaluation Time, it is usually a sign that the proposal analysis and discussion has been incomplete.>

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