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...
No comments:
Post a Comment