I've been wondering how to know whether we've "captured the context" of the patient in our system. It seems as though we'd need another source to confirm that the determined or computed context is indeed the actual context. And this leads me to believe that we should ask the user to describe their situation from time to time.
To enhance a DTN, our system needs to provide any application with information to make a decision regarding the state of the network and the available energy. When a message needs to be sent, there's a question of whether to transfer it now using whatever means are available, to wait for better opportunities (requiring less energy or having a higher probability of deliver), or to panic and declare it's not worth it to attempt delivery of the message (no network or contact is going to be available in time, there's not enough power). The question is to determine the inputs to that decision making process and to determine how correct it is at making that decision.
For the final piece, we'll need to slice the system in half such that the tetherless care application falls to one side and the tetherless care middleware to the other and then glue the two back together with an API. Where there is an infinite number of ways to do this, we have to determine a good one. The problem here is that I don't yet know how to necessarily prove 'good'.
There are a set of properties we'd like this middleware to possess:
- Easy to Develop Tetherless Care Applications
- It should be easy to incorporate the system's pieces into a range of tetherless care applications.
- Modular
- Individual components should be replaceable if alternative or improved functionality is desired.
- Versatile
- It should support a wide range of use cases and potential applications.
I don't yet see how to scientifically demonstrate that these have been met. At best, it seems I can show a proof of concept.
No comments:
Post a Comment