IHE – XDS Notifications

By on April 1, 2013

IHE – XDS Notifications 

Here is an interesting article regarding XDS notifications.  A lot of us here about XDS, but I don’t think many of us venture ‘under the hood’ and see what XDS is doing and what can be done.
A highly passionate discussion happened today regarding the use of XDS and the case of ‘how does an individual know that they have documents of interest they should look at’.
One specific example is when the individual is a key individual of a workflow step. It could be as well that the individual should be simply interested in new content.The discussion got heated because there is interest in getting a very targeted notification. As elaborated there is indeed no specific IHE profile capability to do this notification.
There is however many ways that the functionality can be implemented. No single functionality is universal, there are really good reasons for each method.

Here are some great HL7 and XDS resources that I found on Amazon…great tools!

  


The XDS notification functionality methods are:

Poll: An individual (system) can poll XDS. That is to use Queries one for each patient that system has individuals that are interested in. How often should it poll is left as a configurable parameter as there are good reasons to have this configurable.
** Note this is very much what e-mail uses at the technical level with POP. Clearly as users we are not polling, nor do we know our machines (cellular phones) are polling. This is the most basic, and most robust mechanism. But this is also cumbersome and causes unnecessary traffic and query processing.
*** Note that doing date specific queries are not easy to do, but can be done; and there is a Change Proposal to enhance the query.

Notification: The Notification of Document Availability (NAV) Profile is a little known supplement. It defines a simple XML encoded manifest of document references, and indicates to send this in an e-mail message. This is just a list of document ID values, so it is not exposing patient privacy in any direct way.
This e-mail could surely be sent using encrypted email if you have that capability. The drawback is that it does require that someone knows that you need to be notified, and that you would like to be notified in this way. *Note that the profile does have a specification of how to encode this on paper as well.
** Note a degenerate form is simply an e-mail with no information, just a ‘ping’ that you might recognize, however this isn’t interoperability. *** Of course you could also just pick up the phone as well.

PUSH: That is to Push the content using XDR or XDM. This could be a copy of the documents, because they are globally uniquely identified there is no problem that they get duplicated.
** Clearly again the publisher must know who to next notify *** Because this is full content one must secure the communications.


Subscription: There is the Document Subscription (DSUB) profile that allows a system to ‘subscribe’ to be notified. This subscription contains a filter criteria that would constrain why a notification would happen. Although this is a rather technically easy profile, it is not implemented often. It is not clear how big does a notification system need to be to satisfy a growing population of systems that want notification. This profile is also tied to SOAP webservices, and really only works within a single XDS domain.


Atom Feed: This is really a polling query, but the results often is seen as a form of notification. The Atom feed is a part of the Mobile Health Documents (MHD) profile.

Is there a pattern that we don’t have? I know of some creative ways to use TCP sessions that are left in a closing state, where the one that knows who to notify closes the connection when there is something useful to pull, thus causing the system to poll only when this session close event happens. This is a very low overhead, but does require the systems handle many failure-modes robustly. This is what happens in some mobile APIs to help limit the polling traffic.

Specific to workflows, in the Cross-Enterprise Document Workflow (XDW) profile we did document that a workflow does need to have a system watching to make sure workflows do progress normally. This system could notice a workflow document that seems to have stalled, and give notice via a mechanism like NAV.

It seems we have plenty of ways to achieve the functionality. This technical solution should not be confused with what the user sees or feels.

Click here to read the original article about IHE – XDS Notifications

About dkorolyk

I've been involved in Healthcare IT and PACS since Y2k. Over the years I've been fortunate enough to be involved in a lot of interesting an diverse projects. My experience also includes numerous HL7/EMR integration projects as well as many hardware and software platforms. My three main areas of expertise include technical integration aspects of radiology, oncology and laboratory diagnostics.

You must be logged in to post a comment Login

Join 1000s of other Healthcare IT Professionals

Enter your email below to get the latest News on Healthcare IT, Training Events and Career Information

We hate SPAM too. Your email is safe with us.