Mobile eHealth MeH (PESOS 2012)

Business Goals and Domain Assumptions

In this page we briefly describe a case study, i.e. the Mobile eHealth (MeH), developed in the context of the IST PLASTIC project aimed at supporting self-adapting and context-aware services. The goal of the case study is to show how to model a service-based application and to demonstrate that model-based solutions are suitable to generate Quality of Service (QoS) models and adaptable code from service models.

In the following sections will be reported the Business Goals and the Domain Assumptions for the current case study.

Business Goals

Table BG1. Business Goal EH-BG-01

Field	Description
UniqueID	EH-BG-01
Short Name	Patient Data Retrìeval (PDR)
Type	Business Goals.
Description	By invoking the PDR service, the doctors retrieve mixed media information of their patients that combines text with or without different kinds of images referring to their personal data, their medical histories and patient-related diseases. The results can be displayed on the doctors’ handheld device. A more detailed description of this service is provided in [1].
Rationale	Provide the service that is tailored to a certain execution context.
Involved Stakeholders	Doctors, Patients, MeH System
Conflicts	None
Supporting Materials	[2]
Priority of accomplishment	Must have.

Table BG2. Business Goal EH-BG-02

Field	Description
UniqueID	EH-BG-02
Short Name	Remote Diagnosis
Type	Business Goals.
Description	By invoking the RD service, the patients update some vital parameters (e.g. heart rate) thus to provide the knowledge aimed at monitoring their health. On the basis of such data an alarm is sent in case of warning conditions that can be forwarded to his/her relatives, rural doctors and social workers. A more detailed description of this service is provided in [3].
Rationale	Improve the effectiveness and reliability of healthcare activities. Reduce costs of healthcare activities.
Involved Stakeholders	Doctors, Patients
Conflicts	None
Supporting Material	[4]
Priority of accomplishment	Must have.

Domain Assumptions

Table DA1. Assumption EH-DA-01

Field	Description
UniqueID	EH-DA-01
Short Name	Context/Resource Awareness
Type	Domain assumption
Description	The MeH system shall be a context-aware and adaptable service. Context is a set of heterogeneous information that can be sensed by and influence the system behavior. At design time, it results in artifacts (i.e., models) where structural and behavioral descriptions of the MeH System can be combined with a context model. At run time, it corresponds to the availability of an appropriate middleware that is capable to monitor the execution context and to adapt the system behavior accordingly.
Rationale	Provide the best QoS in an ubiquitous environment despite a continuosly evolving execution context.
Involved Stakeholders	Doctors, Patients
Conflicts	None
Supporting Material	[5]
Priority of accomplishment	Must have.

Domain Analysis

Strategic Dependency Model and Context Diagram

The SDD figure illustrates the strategic dependency diagram of the case study. The diagram puts in evidence the business goals shared among the related actors. For example, in the diagram we can note that the Doctor makes a remote diagnosis for the Patient. He/She can also retrieve multimedia data (text and images) about the assisted patients by accessing databases from the MeH System.

The following figure illustrates the context diagram of the current case study. In the context diagram, all the actors that appear in the business goals and scenarios are agents.

Domain Model

The figure below illustrates the domain model of the current case study. The model is represented using a UML notation. In particular the model shows the entities of the scenario, the actors and the relationship among them.

Scenarios

In this section the Business Goals, namely Remote Diagnosis and Patient Data Retrieval, are further detailed using UML Sequence Diagrams

Table S1: Scenario EH-S-01

Field	Description
UniqueID	EH-S-01
Short Name	Remote Diagnosis
Related To	EHEALTH-BG-01
Involved Actors	Doctor, Patient, MeH System
Detailed Operational Description	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.
Problems and Challenges
Additional Material	Case Study Content (Eclipse Labs Project) PLASTIC Middleware (download)

Table S1: Scenario EH-S-02

Field	Description
UniqueID	EH-S-02
Short Name	Remote Diagnosis
Related To	EHEALTH-BG-02
Involved Actors	Doctor, Patient, MeH System
Detailed Operational Description	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).
Problems and Challenges
Additional Material	Case Study Content (Eclipse Labs Project) PLASTIC Middleware (download)

Case Study Content

The Case Study Content (Eclipse Labs Project) archive here [7] contains the following folders and files:

001_conceptual model It contains the PLASTIC deliverable describing the PLASTIC Conceptual Model

002_Service_Model It contains the Mobile eHealth UML Model in several formats (.mdzip / .uml / .html) and the PLASTIC Domain Specific Environment (i.e. MagicDrawe Customization)

003_model transformations It contains several ATL-based model2code transformations tools and user guides that describe their usage.

004_adaptable_code It contains the Chameleon Tool for generating adaptable java code and user guides that describe its usage.

005_Analysis_Model It containts an MeH Analysis Model based on Queuing Network (to be simulated on JMT) and a user guide that describe its usage.

PLASTIC-D2.3.pdf An overall guide about supporting tools developed in the PLASTIC Project

The detailed content of each subfolder follows:

./001_conceptual model: CONCEPTUAL-MODEL.pdf

./002_Service_Model: D2_2-final2.pdf MagicDraw Customization MeH.mdzip MeH.mdzip.bak profiles templates

./002_Service_Model/MagicDraw Customization: DSE_v1 DSE_v2

./002_Service_Model/MagicDraw Customization/DSE_v1: MD_DSE_user_guide.pdf plastic Profiles.Plastic.rar Samples.Plastic.rar Templates.Plastic.rar

./002_Service_Model/MagicDraw Customization/DSE_v1/plastic: eHealth Scenario.mdzip eHealth Scenario.mdzip.bak eHealth Scenario.mdzip_pre17.0.mdzip.bak Vacation Planning Service.mdzip

./002_Service_Model/MagicDraw Customization/DSE_v2: MD_DSE_euromicro_2010.pdf Profiles.Plastic.zip

./003_model transformations: it.univaq.plastic.m2c.runner_1.0.1.jar it.univaq.plastic.m2c.uml2hutn_1.0.2.jar it.univaq.plastic.m2c.uml2wsdl_1.0.0.jar modelTransformationTool.pdf uml2hutn_guide.pdf uml2wsdl.pdf

./004_adaptable_code: ARA-v2.0.zip Chameleon-ARA-Guide.pdf CHAMELEON-Client-Server-Registry-v2.0.zip Chameleon-Client_Server_Uddie_Developer-Guide.pdf CHAMELEON-IDE-Eclipse-plugin-v2.0.zip ChameleonIDE-UserGuide-ENG.pdf ChameleonIDE-UserGuide-ITA.pdf example.zip

./005_Analysis_Model: guideForPerformanceAnalysis.pdf MeH-perfAnalysis.xlsx MeH-QNmodel.jsimg