Difference between revisions of "2008 Brief Profile Proposal: IHE ITI Publish/Subscribe Profile"

Latest revision as of 14:23, 10 October 2013

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

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

New Actors:

Subscriber
Notification Broker
Notification Consumer

Standards and specifications:

5. Discussion

Why would IHE be a good venue to solve the problem and what you think should IHE do to solve it?

Profiling this type of exchange infrastructure is integral to some of the work in other IHE committees. Rather than reinventing the wheel, the IHE ITI technical committee has the opportunity to provide a profile which can be used across the board in IHE specifications.

What might the IHE technical approach be? Existing Actors? New Transactions? Additional Profiles?

A new profile with new actors, which are intended to be grouped with other profiles' actors (similar to how ATNA Secure Node and Secure Application actors are used). The grouping can be done via "content profiles" or via extensions to existing/future profiles.

What are some of the risks or open issues to be addressed?

There are additional use cases where publish/subscribe may be useful. There is likely a need for the ITI, PCC, QRPH, etc. committees to create content profiles defining topics and filters for their specific purposes.

@@ Line 1: / Line 1: @@
-{|border="1" cellspacing="0" style="background:lightblue; color:white"
+{|border="1" cellspacing="0" style="background:lightyellow; color:blue"
-||This proposal is based on the [http://www.ihe.net/Technical_Framework/upload/IHE_ITI_Whitepaper_XDS-b_pub_sub_2008_08_22.pdf Publish/Subscribe Infrastructure for XDS.b] white paper.
+||This proposal is based on the [http://www.ihe.net/Technical_Framework/upload/IHE_ITI_Whitepaper_XDS-b_pub_sub_2008_08_22.pdf 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.
 |}
 __NOTOC__
@@ Line 15: / Line 14: @@
 ==2. The Problem==
-The IHE XDS profiles require Document Consumers to constantly poll the Document Registry for new documents or updates to existing documents in cases when there is an expectation that additional documents may become available after an initial query. In many such cases a publish/subscribe method of receiving new information for patients of interest. In addition, the NAV profile assumes some kind of subscription method. Providing a consistent pub/sub framework will benefit various use cases where constant polling is not feasible.
+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, see proposal for referral orders), 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.
+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, see proposal for referral orders), 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, either a notification is sent to the specialist's system, or an online XDR transaction is exectuted.
+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==
-Document Source, Document Consumer, Document Repository, Document Registry
+New Actors:
+* Subscriber
+* Notification Broker
+* Notification Consumer
-ebXML Registry, existing XDS transactions
+Standards and specifications:
+* [http://www.ihe.net/Technical_Framework/upload/IHE_ITI_Whitepaper_XDS-b_pub_sub_2008_08_22.pdf IHE ITI White Paper: Publish/Subscribe Infrastructure for XDS.b]
+* [http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn OASIS Web Services Notification Family of Standards]
+* [http://www.w3.org/TR/xpath20/ XPAth 2.0]
 ==5. Discussion==
-''Why would IHE be a good venue to solve the problem and what you think should IHE do to solve it.''
+''Why would IHE be a good venue to solve the problem and what you think should IHE do to solve it?''
-This is a natural extension to the XDS-b profile (possibly including asynchronous transactions).
+Profiling this type of exchange infrastructure is integral to some of the work in other IHE committees. Rather than reinventing the wheel, the IHE ITI technical committee has the opportunity to provide a profile which can be used across the board in IHE specifications.
 ''What might the IHE technical approach be? Existing Actors? New Transactions? Additional Profiles?''
-A new profile, derived from XDS-b and XDR
+A new profile with new actors, which are intended to be grouped with other profiles' actors (similar to how ATNA Secure Node and Secure Application actors are used). The grouping can be done via "content profiles" or via extensions to existing/future profiles.
 ''What are some of the risks or open issues to be addressed?''
-There are additional use cases where publish/subscribe may be useful. There is likely a need for PCC (or several committees) to define appropriate topics for healthcare-specific publish/subscribe infrastructure.
+There are additional use cases where publish/subscribe may be useful. There is likely a need for the ITI, PCC, QRPH, etc. committees to create content profiles defining topics and filters for  their specific purposes.
+[[Category:ITI Proposal]]
 [[Category:Profile Proposals]]