Small change to the Application Diagram:
The Middleware will provide information about who's interested in the data and what network interfaces are available, both of which will ultimately affect the decisions made, so they've been added as part of the physical context.
I want to go back to the middleware diagram.
There's an agreement implied between the application and the middleware in the messages exchanged between them. The application has to describe enough information in its proper format so that the middleware, the location service and the routing protocol, can do their job. Being that the diagram doesn't lay any requirements for that out, you might deduce that my proposal will be equally ambiguous. In reality, this is part of what I intend to examine in my work.
To start, though, we've noticed that the interaction of the patients and their healthcare professionals fit nicely with what is known as a Publish/Subscribe Architecture.
The idea of Pub/Sub is that some entity produces a stream of data packets (publishes) to some publication, and other entities subscribe to that publication. The architecture then moves all the data packets from the publisher to the subscribers. It's easiest to think of this in terms of a blog (like this one), where each new blog entry is ultimately sent to the RSS readers of those people subscribed to the blog's RSS feed. The only thing that publishers and subscribers need to communicate is the name of the publication.
A more complicated implementation is called Content-based Publish/Subscribe. Here the publishers, instead of attaching just a name to each message, attach a series of values, like patientID = 1234, signal = ECG, situation = 'heart attack', etc. An interested party can then subscribe by declaring a filter that says something like, "send me all messages where the 'situation' is 'heart attack'."
You might imagine that Content-based Pub/Sub is harder to implement. It might, however, make the entire system easier to operate.
Thus, one of the questions I have to (want to) answer in my work is:
Which Pub/Sub Architecture better serves the application/system?
A little bit about what I'm getting into these days.
We all know healthcare costs are going up. We've identified a class of applications that fall under the label Wireless Health Monitoring and are argued to help reduce these costs. Essentially, they're related to the remote observation of vital signs and behavior. They help reduce costs by keeping people out of a hospital bed, potentially moving the elderly from the nursing home to an assisted living facility, or moving them from assisted living to their own home (i.e. "aging in place").
Here's a diagram of the typical application:
A set of sensors is attached to the body and produces a set of signals for the application. We combine these inputs with other signals like the battery power of these devices and the network conditions to define an application context, organized through the Monitoring component and presented to the Decision Making Component as the current situation.
The Decision Making Component computes the severity of the situation and takes one of a set of possible actions. Low severity, indicating normal or expected vital signs, requires no action unless there is an outstanding request to service or a regular report to generate. As the severity increases, the application starts taking local action to increase the frequency or granularity of monitoring. A high severity level is reported to appropriate healthcare professionals, such as the patient's Primary Care Physician (PCP), nurses, or Emergency Responders.
The part I'm adding to this dance is the middleware architecture. This part takes responsibility for delivering messages from to and from the application, or, more formally, given a message, to deliver that message to all of the intended recipients. Here's a diagram outlining the components of the middleware:
We define a Location Service that looks up the most likely location of the recipients, patients, doctors, nurses, or emergency responders who could be at home, at work, in transit, or outside their normal routine. The location service uses their past known locations and potentially their calendar service to predict a likely location for the person. This location, if it's found, then aids in the routing component, which is responsible for finding a set of paths to the recipients.
My Task: Design the location service and the routing protocol
I should have known that I'd never really update this guy. This is my perennial resolution to update my research blog more. This one, though, comes with the commitment to update my website as well. I'm going for a CSS3 and HTML5 experience. I also want this page to match that layout as best it can. If these Blogger templates don't let that happen, then I might go with something else.
As far as my research goes, I'm working on my proposal. The idea is to determine the systems infrastructure needed to support Personalized Health IT Applications. Many people are starting to track their own vital signs, and we're entering an era where your doctor can ask you to start tracking them in your every day life. The question is then how do we connect you to your doctor in this new intimate, personalized health monitoring environment.
At the moment, I'm having trouble convincing my advisor that I understand the goal of all this.
