4.1. Application Specification
For an application specification it has to be taken into account that, in the end, eHealthcare applications will be composed by a set of software components running under the supervision of a management platform, but it must start with the specification of the health-centered monitoring (R2) that defines the customized supervision of a patient, including the detection of the hazardous situations and the corresponding reaction. That is, application specification is leaded by the medical staff although completed by technology experts. With this purpose, the modeling approach consists of a set of interrelated concepts, many of which are initially defined by a physician, and afterwards shared among different technology experts for a detailed characterization. It has to be also considered that each patient suffers from particular diseases such as diabetes, hypertension or cardiopathies, with very different necessities. Even two patients with the same health problem cannot be similarly treated. For example, heart rate thresholds are different for each individual, or the amount of exercise the patient does influenced on the glucose level.
In order to better understand the proposed modeling approach, let us consider a use case related to the hypoglycemia described in the previous section. If the previous example focused on correlation analysis, the current one completes it as it is aimed at the early prevention of hypoglycemia events in diabetics. In this context, a physician specifies to measure the sweating and heart rate of the patient. In case of abnormal measures during a period of time, apart from warning medical staff, the patient will be asked to measure its glucose level. Finally, if the patient does not respond or the measured level is unsuitable, the physician determines to activate fall detection, which is a right signal of loss of consciousness.
In the modeling approach every patient is represented by the Scenario
concept, grouping all the monitoring activities demanded by its health status (Application
concept). Therefore, in the previous example the scenario for the diabetic patient consists of three applications (see Figure 12
): one for identifying a possible hypoglycemia event, another one for checking the current glucose level and the last one for detecting a possible severe case.
Each supervision activity, i.e., application, can be decomposed in several tasks represented by the Component
concept. For example, the specification of the Hypoglycemia
application consists of six components (see Figure 12
): periodically, the galvanic skin response of the patient (GSR_Acq
component), as well as its heart rate (HR_Acq
component) are measured. Both values are stored as part of the patient’s medical history (GSR_Storage
components, respectively). Additionally, the measures are analyzed together with other previous ones in order to determine if the patient evolution may correspond with a possible hypoglycemic episode (HG_Checking
component). In that case, apart from warning the medical staff (NursingMsg
component) the possibleHG
event is triggered. This involves starting the GlocoseLevel
application in charge of confirming the alarming situation through the current glucose level of the patient.
It is important to remark that all these components must be customized for the particular patient, as it is presented in Table 2
(properties in blue color).
Thus, the physician must also determine when the components activate (periodically or after data reception) as well as all the information about the patient needed by the component (e.g., particular thresholds for analyzing the captured data or the patient identifier needed to obtain these data from a local database, which is the case of the example in Table 2
As components are in charge of different parts of the application functionality, they need to collaborate by exchanging data among them. With this purpose, components are provided with an Input Port
and/or an Output Port
for data reception and transmission, respectively. Exchanged data are collected in the Connector
concept that links the output port of a sending component with the input port of the receiving component. Doctors have to detail both the information required and provided by every component (Parameter
concept, see Table 2
) and how they are connected. In the case of the GSR_Acq
component, the captured measurement must be sent to the HG_Checking
(see blue properties in Table 3
) and GSR_Storage
(blue properties Table 4
) components. The latter also needs its acquisition time. Note that all the provided parameters are not always sent to all the successor components. Furthermore, data might be sent under certain circumstances that the physician must establish. This Data Logic
is defined as an activity diagram attached to the output port, based on the parameters provided by the component as a result of its execution. For instance, as it is depicted in the activity diagram of the HG_Checking
(see Figure 12
) component, it communicates with the NursingMsg
component only when the galvanic skin response and heart rate are too high for the patient. Furthermore, this output parameter (isAlarming
parameter) is just used for logical decisions as it is not sent to any component.
As previously stated, health-centered monitoring also includes the reaction to abnormal situations, such as a high heart rate and too much sweating, a very low glucose level, or fall detection. The physician makes use of the Event
concept to identify these relevant situations that demand a reaction and has to define the Event Logic
that describes the conditions under which the event occurs. Again, the event logic is described by an activity diagram attached to the component in charge of detecting the event, based on its output parameters. As far as reaction is concerned, the modeling approach allows its definition as a set of Actions
that involve applications. For instance, when the patient status gets worse, i.e., heart rate accelerates and he sweats more, the possibleHG
event is triggered, which implies starting the GlucoseLevel
application (see Figure 12
, create action). Similarly, when the patient does not respond or the measured level is unsuitable the noAnswer
and the unsuitable
events are triggered, respectively, both initiating the FallDetection
Live data persistence, demanded by the R5
requirements, must also be declaratively defined in the design phase. With this aim, the modeling approach has been extended with properties that allow the care teams to identify which data must be persisted. In particular, the information to be persisted corresponds with the parameters provided by the components, as they constitute their processing results (see Table 3
and Table 4
). Additionally, as events represent relevant situations during the supervision of patients, they are also persisted by default. For example, in the first scenario a further analysis of both, the occurrences of the noAnswer
events and the glucose level measured, might allow to study the evolution of the disease in a concrete patient or even infer conclusions at a more global level. Similarly, a deep study of the possibleHG
events together with normal glucose levels might help in defining a theory for detecting false positives.
Once medical experts have finished applications specification, technology experts complete it by integrating information related to their expertise (green properties in Table 2
, Table 3
and Table 4
). This is the case of the dependability level of components that must be replicated in order to assure application availability (R6
). Additionally, it is necessary to indicate if there are stateful components that need to maintain their execution state after a recovery.
Finally, as components collaborate by exchanging data, usually related to sensitive information about patients, technology experts must identify, through properties, if the connectors specified by the medical staff demand safety (R7) and/or security (R8) support.
4.2. Application Development
The proposed modeling approach allows care teams to play an important role in application specification abstracting them from the particularities of the management platform. Certainly, it is a management platform independent approach. Therefore, it is necessary a methodology for software developers to implement the applications specified by medical experts and that will be managed by the DAMP platform. It is worth noting that the Component concept is the unique modeling concept that becomes source code, therefore it will be the focus of this section. Indeed, the Scenario concept is used by medical experts for structuring applications specification, very useful in large institutions. Therefore, on the basis of the information captured in the application specification, component implementation involves:
Extending the base class provided by the DAMP platform (see Figure 4
) with functional code of the component (see Figure 13
Defining the declarative configuration of the component in XML format (as in Figure 11
Developing the Java Interfaces needed for data reception (as in Figure 11
The proposed methodology consists of the following steps, closely related to the modeling concepts described in the previous subsection:
(1) Configuration Parameters
Components must be configured before its first activation. Therefore, the software developer extends the initWithState
method of the base class to include them (see Figure 4
). This method is also used for including all actions needed to initialize the component, e.g., establishing the connection to a database.
(2) Input Port
Data reception is performed through a Java Interface composed by as many methods as Connectors arrive to the port. The arguments of these methods are determined by the connections established during Connector specification. Additionally, in the declarative configuration an input port implies adding an SCA service, taking into account the possibility of persistence demand (see Figure 11
The software developer has to write the code corresponding to the functionality described by the medical experts. It has to be taken into account the required and/or provided parameters previously defined, assigning to them the proper data-type.
(4) Output Port
Data delivery is also performed through Java Interfaces. In this case, the software developer has to add as many references to Java Interfaces as connectors leave the port. Therefore, an output port implies overwriting the writeOutputs method of the base class, including the data delivery to all the successor components as well as coding the data logic, if necessary. It is also necessary to add an SCA reference in the declarative configuration.
On the other hand, if the connector has been tagged as persisted, it is necessary to persist all its related output parameters through the reference that is commonly used to transfer its internal state (IStatus
in Figure 6
(5) Triggered Events
If the component is in charge of event triggering, the software developer has to overwrite the triggerEvents method of the base class. This includes writing the code of the associated logic and invoking the services offered by the DAMP platform for launching, stopping or modifying the QoS parameters of applications. Additionally, as previously stated, triggered events must be persisted by also using the IState_Ref reference. In this case, the input parameters that have leaded to the event triggering must be persisted, indicating the associated event.
(6) Internal State Transfer
If it is a stateful component, it is necessary to overwrite the writeState method of the base class that manages the component status for availability purposes.
Finally, the Connectors of the modeling approach are related to SCA bindings, which are declaratively configured. It is the XML file where the software developer has to indicate if the connector demands safety and/or security (see Figure 11
As an example, Figure 13
shows the source code of the HG_Checking
component implementation which has been developed following the previous guidelines, based on the definition of the component and the related connectors (Figure 12
, Table 2
, Table 3
and Table 4
, respectively). As it is depicted in the “Input Port” part of the code, the gsr
input parameter is received through the GSR2C
connector, whereas the hr
input parameter through the HR2C
connector. Additionally, in the “Triggered Events” part, as a result of the possibleHG
event detection, the application component invokes the LaunchApp
method provided by the platform manager (see Figure 7
) as a web service. This is the way application components implement the reaction to context changes defined by medical experts. It is important to remark that the HG_Checking
is a stateful component as it analyzes several sweat and heart rate measures in order to determine a possible hypoglycemia. In this context, a node or component failure may lead to lose data relevant to event triggering, being mandatory to assure its internal state in case of failure recovery. Therefore, before finishing every execution (“Internal State Transfer” in Figure 13
) its internal state is transferred to the corresponding node manager, as explained in Section 3.2
. Therefore, in case of failure, the recovery process is the one described in Figure 8