Difference between revisions of "Mobile eHealth MeH (PESOS 2012)"

The behavioral description of the Remote Diagnosis service is illustrated in the above figure. A multi-radio networking service provided by a context-aware middleware (MRNAPI instances mrn-patient and mrn-doc), choose the best networks available (MRNAPI::activateBestNetworks()) before establishing either a multicast or a point-to-point communication among patients’ and doctors’ devices. In particular, the former communication protocol is used to send alarms from patients to any of their supervising doctors. In order to execute the sendAlarm() operation a networks with low bitrate and power consumptions is required. Indeed, the alarm message is usually very small (few bytes) and sent from a safety critical and possibly battery-powered device (e.g., a panic button). In this case a GPRS network satisfies the requirements as modeled by the QoSProfile01. On the doctor’s side, when the alarm is received, the visualcheck() service available on the patient’s side is invoked.

A point-to-point communication needs to be established from the doctor to the patient: the adopted middleware is in charge of selecting the best network available according to certain quality profile. For example, a quality profile may require a free network with very high bitrate to transmit a video stream from the patient’s side. In this case the context-aware middleware (named ubiSOAP) ignores GPRS and switches to a WiFi network.

PLASTIC Middleware (download)

The figure shows a UML Sequence Diagram associated to the Patient Data Retrieval (PDR) service. When the doctor, once logged in, invokes the distributed service, the server-side components are in charge of retrieving data from a local (i.e. connected by LAN) database and, if suited, from a remote (i.e. connected by WAN) image server for patients’ x-rays or disease-related images. Finally the result is displayed on the client. The service behavior can be determined by the current context conditions defined by the values of the managers’ model variables. The figure represents indeed an Interaction Overview Diagram (IOD) that models the behavior alternatives and the conditions that determine the current behavior, as expressed at the topmost branching point of the figure. Hence, the same service can have multiple implemented behaviors whose activation is driven by the logics expressed within a context model called managers whose details are described in [6]. Besides the StandardBehavior described above, the right side of figure reports a box for a ResourceConstrained behavior that will be executed in case of scarce resources and that excludes the interactions with the image server (i.e. the white lifeline and the bold labeled messages in the figure).

PLASTIC Middleware (download)