First, some background (in case you might be interested):

Here at Kaweah Delta, I have been challenged with providing a solution for a common health care problem.  Like most hospitals, we are constantly looking for effective ways to put pertinent information into the hands of our physicians.

How can we communicate lab results to a physician when he/she is not within the hospital?  If a patient is ready to go home, is it possible for the physician to discharge her without making her wait until his rounds?  Is there a secure, discreet, way for physicians to communicate with each other, regarding a patient?  If so, can this communication be secured and retained for future use?

We have identified that being able to communicate this type of data to physicians, when they are outside our hospital, is becoming more and more of a demand.  We believe that advances in mobile computing can answer that demand.

Therefore, I am currently in the process of developing a suite of mobile applications that will, hopefully, provide solutions to these types of challenges.

We are calling it Verity and, currently, it is built on the Windows Mobile 6.0 platform.

The first, most fundamental, challenge that I encountered was instituting a communication model that would be best for critical information without creating a high resource demand on the device.

More specifically, I have created a series of web services that retrieve and send information to the device, however, having a device check these services periodically (every 5 minutes) proved to be too much demand on the battery.

The question became: “How can we send messages to our mobile application as they arrive?”

Enter Microsoft Direct Push.  Those of us that have access to this technology, understand how great it is.

The next question became: “Is there some way to leverage this existing technology for our mobile application?”.

The answer is yes.

Enter the Windows Communication Foundation available in the Windows Mobile 6.0 SDK.

This framework provides an ability to create a communication channel between a server application and a custom mobile application.  The important factor is that it relies on Exchange 2007 and Direct Push to send this communication.

With these tools, I can create system messages that get sent through our Exchange server, to a mobile device’s inbox.  My mobile application listens on a specified channel, retrieves that message on processing, performs the event, and removes the e-mail from the inbox.  Essentially, Direct Push for my application!

My primary source for establishing this was this example by Andrew Arnott in the September 2008 issue of MSDN Magazine.  The code download can be found here.

Although this example demonstrates an IM-like messaging application, the fundamentals are demonstrated.  I can create any type of server application I want, as long as it can effectively send a message to the device.

So let’s evaluate how this might work for my suite of mobile applications:

1. A message or event is triggered in one of our clinical systems.  I have designed a server application that is looking for those events.

2. The server application recognizes that the event occurred, looks up the appropriate physician’s e-mail address, and sends a serialized XML message to the Exchange server.

3. Exchange then pushes it to the device using Direct Push.  My mobile application is listening for messages hitting the device’s inbox with a particular channel name.

4. Because the message has the right channel name, the mobile application retrieves the message from the inbox (effectively removing it) and performs a call to the web service.

5. The web service supplies the clinical system event that occurred.

I did, however, run into a snag when accessing the web services on our Exchange server.  We found that they were not enabled.  D’uoh!  That will be a week of my life I’ll never get back.

Anyway, our Exchange guru was able to figure out how to enable those services.

If connecting to your Exchange server requires SSL, here is an additional resource.