Winter Break

It's always hard to keep my focus through semester breaks. Despite being the perfect time to get some work done, it's so much easier to get distracted and to be lazy. My exercise in Zen is trying to accomplish something in the next two weeks.

Finally Continuing Chapter 3

I had returned to my introductory chapter because, during my first trip to my third chapter (the main one), I discovered I didn't really have a footing for my discussion. I'm finally now back to where I left off.

The Basic Outline

The idea here is reiterate the main questions I posed in the first chapter, and then briefly discuss how I expect to answer each of them, which amounts to the development of this middleware and routing protocol along with a study of the application traffic characteristics.

That discussion should segway into a more in depth discussion of the middleware and its various components. I think, here, I'll finally start introducing the plan for a publish/subscribe interface. I have to connect that information to the routing protocol. And I should probably introduce a location service... although, I don't think I'm going to go into much study there. The tether-less patient just needs location information at the application level, so that the middleware will probably manage and provide that information. However, the info might be useful for routing....

After that, it's finally the research plan, which I already have written... unless I (or my committee) feels like changing it.

Routing and its Environment

I already laid out the questions about the networking environment for the system. What I need to recognize is that there's a relationship between the information that is collected about the environment and the routing algorithm that uses that information. We can change the information we collect to better suit the algorithm, and we can change the algorithm to exploit other information.

This relationship gives us a lot of freedom, but we're constrained by what little knowledge we can collect and the application requirements. The algorithm must be able to effect on-time message delivery, and we must then ask whether it's possible to determine if the network can provide that service to us. Can we construct an algorithm that determines if on-time delivery is possible?

Application Data Model

Here's the basic set of statements arguing for an accurate data model in my study:

Deadline and Reliability Requirements

We're trying to extend the tether-less patient system beyond its current environment.

We're limited in this effort by the application's demands, most notably the delivery deadlines of the messages. If we had infinite deadlines, we could use the cheapest means of transmission in all cases, tolerate the longest delays possible, and "operate" in any environment. As the deadlines shorten, we have to make more informed choices and better infrastructure needs to be available (to accept a given message into the middleware for delivery).

Therefore, we need to know how the deadlines behave.

Their behavior depends on usage behavior.

Therefore, the questions we need to ask relate to how healthcare professionals use the system. Would they ever check in on a patient outside the hospital if everything is normal? Would they trust the devices to alert them to problems? Does the use case reduce to a notification that an important event occurred with the patient? How do these notifications vary in their urgency? How frequently can these notifications occur? Can healthcare professionals accept that a patient may not be in an environment that supports streaming data at the time of a request?

These questions beg a study on the matter such that we can generate a traffic model that both accurately depicts the application data and allows us to synthetically adjust its parameters to stress our routing protocol and middleware system.

Multiple Destinations

The second aspect I might need to consider is the multiple destinations of a given message, but I'm not sure if there's really any challenges involved in providing this functionality.

More than one healthcare professional could be interested in some patient data. We want to save power on the patient's device, so that it'd be beneficial if the patient could transmit the data once instead of addressing multiple copies of the message to each destination. This requirement is the classic multicasting paradigm. As such, the routing algorithm has to support multicasting.

With that, there are several questions we could ask: How do the destinations change over time? Does the patient's state change the set of destinations? Is infrastructure likely to be between the patient and the destinations most of the time (is routing a problem of getting messages to infrastructure)? How does the multicasting paradigm react to longer delays?

Summing it up in a Question

I need a question to sum up everything about the application data model. It consists of notifications, reports, streams, and requests potentially addressed to multiple destinations, each with a deadline and priority. We need to be able to adjust the length of the deadlines, the frequency of the notifications, and the intended destinations to mimic the behavior of an actual tether-less patient system. Such a model will allow us to comment on the potential operability scope of these systems.

Still thinking...

Networking Environment

I've been stuck on this for a couple days now. Here's what I need to talk about:

• That WiFi and 3G interfaces have different characteristics. WiFi is shorter range and varies in quality a lot more. 3G doesn't offer communication with what we might consider peer devices... only infrastructure.
• I feel like I need to talk about why they're different. They both use the airspace around us, but they have different characteristics. ... does my audience know why or need to know why?
• I need mention Bluetooth.
• I need to put things in a broader context of what any wireless radio and network protocol offer where Bluetooth, UMTS/EVDO (3G), 802.11, and LTE/WiMax (sub-4G) are just the current incarnations.
• Must introduce the concept of a contact: coming in and out of communication range
• The idea of a contact implies the importance of movement in wireless networks.
• It's the nature of the patient's movements that we have to study.
• Ask how the general intermingling of a population expresses itself in a time-varying network graph (not the first to ask this question).

And I'm probably going to come up with more too.

The section should ultimately arrive at the

Breaking down the Question

I outlined two sources of challenges for the middleware in a previous post: the networking environment and the application data demands. What I need to do is discuss the needed or possible responses in each of those areas, the questions they raise. Therefore, I'm designing the section around that structure:

1. Middleware Design Issues: Network Environment
2. Middleware Design Issues: Application Data Demands
3. Middleware Design Issues: Routing Algorithm

First, though I have to point out the contradiction between long network delays and real-time requirements. The two properties contradict (and make this work interesting). We know, though, that prototypal systems have been built on wireless communication technology, so that we then know there are wireless environments that can be provisioned to support these systems. The question I want to ask, then, is can we extend beyond those environments because the patient, going about his or her life, is probably going to bring the system beyond intended environments. We might also ask if, by adopting these techniques, we can reduce the provisioning needed in those intended environments.

To answer those questions, we need to know more about the environment. We also need to develop a new networking paradigm, which is the basis for my proposal.

What We Already Know

What follows is a list of facts I can use later to support my argument (believe it or not, I forget and rediscover these guys in my notes all the time). My plan is to continually edit this post as needed.

• Prior Work has demonstrated that a body area network can be built around a human.
• Prior Work has demonstrated that some wireless environments can support the needs of a tether-less patient system.
• DTN has provided a blueprint for dealing with disconnected environments, albeit by introducing unbounded message delays.
• Wireless technologies have different power requirements. WiFi, at its best, is faster and requires less energy than a 3G radio. If it's retransmitting packets a lot, though, it loses.

The Question

The main question I'm hoping to arrive at:

Can we deploy a middleware for the tether-less patient system that attempts to support the real-time and reliability demands of the tether-less patient application in the face of extremely variable and power constrained communication environments?

The task now is to break this down into a set of questions. I already have the problems to solve written for the most part. It's a matter of connecting dots now.

Communication Constraints of Tether-less Patient Systems

A constraint is essentially something about the object under study that can't really be solved. A solution has to work around it. Challenges are sort of the same thing, except that they may offer the potential to be solved. Nevertheless, a solution can work around a given challenge if it doesn't solve it outright. The line between the two is somewhat blurry, e.g. maybe some day we'll solve that whole pesky friction thing when we don't want it to be around. In light of that, we can think of both of them as the properties of the studied object that make the solution... fun.

Constraints of The Tether-less Patient Communication Environment

1. Communication Variability. From the patient's perspective, wireless signals fade in and out as he or she moves about a space.
2. Multiple Communication Technologies. The patient's environment probably has multiple wireless technologies available. There's no need to marry the system to one of them if we can potentially use all of them (well). Furthermore, newer technologies are emerging constantly. The airspace offers an increasing number of choices.
3. Varying delays. A direct, synchronous, end-to-end connection to one or more destinations cannot be guaranteed... especially in a wireless environment. Rather than take the perspective that this results in failures, we can take an understanding that a connection may become available later or that another device in the vicinity can offer a connection. From this perspective, the network offers extended and widely varying delivery delays.
4. Power. Smartphones run on limited battery power.

These issues are introduced mainly as a consequence of the patient's mobility.

Constraints imposed by the Tether-less Patient Application

1. Real-timeliness. Messages have to get delivered by some deadline. For some, the deadline is pretty lax. For others, we could use the phrase "as soon as possible."
2. Reliability. Some messages absolutely have to get delivered without failure (for all intents and purposes). Others can be lost without severe degradation to the data or the systems' mission.
3. Multiple Destinations. A given message may need to be sent to more than one destination.

Revisiting my Introduction

I thought I was past the introduction of my proposal, but, after getting back into the flow of the narrative I'm developing, I realized I haven't fleshed out a specific set of questions yet.

I give my reader a description of a typical Tether-less Patient System, and, from there, I have to begin a focus on the communication aspects of the system and the constraints/challenges imposed on this part of these systems, ultimately (hopefully) arriving at the set of questions I will address.

Continuing my Proposal

I need to finish this thing up.

I've been hung up on the social-based multicasting work out there. After implementing social-based DTN routing in the simulator, I have to come back and write up a section in my literature about it. I've since lost the narrative thread I was on, and the semester's distractions aren't helping me find it again.

My ONE Simulator Contributions

Created a new page on my website listing all the software I've written for the ONE Simulator.

Opportunistic Network Environment Simulator

I've been using a simulator called the ONE (great name, I know) to emulate the movement of mobile nodes. The great thing about it is that I can import real world maps and make the hosts move along specific paths through them. I, therefore, picked none other than Pittsburgh as the basis for my simulation. Here's a picture:

I've probably been annoying the rest of my department as my simulations are taking up all of our condor computing resources. Some trials have been running for almost a month, and I'm starting to get annoyed. I have to reduce the number of nodes I define in the simulation next time.

Life's Dependencies

Was talking to my officemate about the average computer user and their poor computing habits (poor password choices, not keeping their software up-to-date), which essentially let's botnets flourish. It also gives those of us in-the-know a lot of power over anyone who doesn't care about the inner workings of their computers.

Most people don't care how it works, only that it works.

I'm not like that. I have to (1) know every system on which my survival and lifestyle depend and (2) how those systems work: Financial Systems, Food Distribution, Transportation, Utilities, Cars, Motorcycles, The Internet, Governing Bodies. I must know how they all work.

Requirements

Four requirements really dictate the design and influence the architecture of a tether-less patient system. I have to present them to avoid questions about why this architecture versus other possible architectures. Without further ado and straight from my proposal draft:

Mobility Support

At its core, the tether-less patient paradigm amounts to the introduction of patient mobility to the traditional hospital monitoring scenario. The primary goal is to provide a similar level of monitoring while the patient goes about his or her normal routine.

Pervasive Operation

Patients too encumbered by the system's hardware will be unlikely to adopt it. As such, the system must be designed to fade into the background of their consciousness, alerting their attention as little as possible and adding a minimum of extra hardware to their person.

Management of Healthcare Professional's Time

Healthcare Professionals have limited time and oversee multiple patients. Where it may not be possible to in any way limit or discard the information delivered to a healthcare professional, the system should incorporate algorithms to intelligently monitor the patient’s situation such that the healthcare professional only be alerted to the important aspects of the situation.

HIPAA Compliance

The Health Insurance Portability and Accountability Act of 1996 stipulates that reasonable steps be taken to ensure an individual’s health information is kept confidential between a patient and his or her current healthcare professional, both through policy and technical means, except under several specific cases or unless the patient provides written authorization indicating otherwise. It defines four broad security requirements for Health Information Systems: Access Controls, Audit Controls, Integrity Controls, and Transmission Security. Access Controls must identify the system’s users (healthcare professionals) and grant access to patient information based on the role the user is currently fulfilling. Audit Controls require a system to log access grants and other activities for a period of six years. Integrity Controls require a system to put in place mechanisms ensuring health information is not altered or destroyed. Transmission Security requires steps to ensure data is not accessed in transit over a network.

Image Upgrade

Slightly improved on my previous images.

I'm getting more into infographics for communicating information. They take much longer to create, but they communicate information at a higher bandwidth, meaning you pick up the information faster.

In this one, I'm splitting the concepts I need to discuss into a conceptual abstraction of these systems and an architectural outline for them (or for the one I'm proposing).

At the conceptual level, a patient exhibits a current Situation, which is the collection of his or her vital signs together with the environmental factors that not only influence those vital signs but also impact the system itself. This Situation is the target of the systems observation and monitoring efforts. By collecting a view of it, the system can make an assessment of the patient's current state and take any needed action, such has alerting a medical professional.

We implement this observation of the patient's situation with a set of sensors attached to the patient that organize into a body area network (a low power peer-to-peer wireless network). The sensors upload their data to a central coordinator in the body area network, which, having the collected information, can implement the algorithms to assess the patients state. It can then initiate the appropriate actions to respond to this assessment.

If communication with a medical professional is needed, the middleware component handles the details of passing that communication from the coordinator to the appropriate doctor, nurse, first responder, or technician. The system has to rely on the wireless networking infrastructure in the patient's environment (since we don't want to restrict where the patient goes), which makes it tough to make guarantees about how good the connection will be... if it even has one. The middleware hides all this, taking messages from the coordinator, connecting to WiFi and 3G/4G networks as needed, and delivering them when a path is found to their recipient.

This last piece is where my work will focus.

Change to the Application Diagram

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.

Publish/Subscribe

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 Middleware Architecture for Wireless Health Monitoring

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

1. Design the location service and the routing protocol (or a bunch of possible designs)
2. Prove to you that they meet the needs of the application I just overviewed

Check Up

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.