Difference between revisions of "Mobile eHealth MeH (PESOS 2012)"
From Scube-casestudies
Berardinelli (talk | contribs) |
Berardinelli (talk | contribs) (→Domain Model) |
||
| Line 164: | Line 164: | ||
| − | [[File: | + | [[File:Use Case Service Diagram1.png]] |
== Scenarios== | == Scenarios== | ||
Revision as of 15:03, 18 April 2012
Contents
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
| 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. |
| 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
| 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
The following figure shows the general use-case diagram for the EHealth case study.
| Field | Description |
|---|---|
| UniqueID | EHEALTH-S-01 |
| Short Name | Access previously collected health data |
| Related To | EHEALTH-BG-01, EHEALTH-DA-02 |
| Involved Actors | Doctor, Other Medical Staff |
| Detailed Operational Description | During the medical examination, the doctor or other medical staff may need access to the patient’s previously recorded and now archived health data (that is, blood test results, X-ray images, etc.) which were either recorded in the same location or at a different place. For instance, this data might have been recorded at a different hospital (which possibly belongs to a different hospital chain). |
| Problems and Challenges | The problems and challenges related to this scenario are the following:
granted access rights
|
| Additional Material | None |
| Field | Description |
|---|---|
| UniqueID | EHEALTH-S-02 |
| Short Name | Access current health data |
| Related To | EHEALTH-BG-01, EHEALTH-DA-02 |
| Involved Actors | Doctor, Other Medical Staff |
| Detailed Operational Description | The doctor also needs access to the data recorded online during the consultation by either the doctor himself or his assistants. He may, in addition, need data that was recorded shortly before the consultation, or that was collected in the hospital or at home during a long-term monitoring with a mobile diagnostic device like, for instance, an ambulatory blood pressure unit. It is even conceivable that the doctor would use diagnostic data received from nanobots (that is, agent-like devices of nanometre-size brought into a human body for diagnosis or even for therapy). In addition, whatever kind of data he is using, the doctor should be supported in his analysis by expert systems and databases. |
| Problems and Challenges | The problems and challenges related to this scenario are the following:
|
| Additional Material | Sub use case:
|
| Field | Description |
|---|---|
| UniqueID | EHEALTH-S-03 |
| Short Name | Access health data during examinations |
| Related To | EHEALTH-BG-01, EHEALTH-BG-04, EHEALTH-DA-02 |
| Involved Actors | Doctor, Patient, Other Medical Staff |
| Detailed Operational Description | To reach a diagnosis during a complex examination, the doctor may need to use several devices in several locations. The devices could be a general-purpose handheld computer or a specific integrated device for medical diagnostics, for instance, an X-ray device. They are often located in the same hospital, but also their usage in a different place, e.g. the patient’s home, is conceivable. For the execution of patient checks a doctor could exploit different devices. In this case, their status has to be properly aligned. |
| Problems and Challenges | The problems and challenges related to this scenario are the following:
|
| Additional Material | Sub use-case:
|
| Field | Description |
|---|---|
| UniqueID | EHEALTH-S-04 |
| Short Name | Expert Consultation |
| Related To | EHEALTH-BG-02, EHEALTH-BG-05, EHEALTH-DA-02 |
| Involved Actors | Doctor, Expert |
| Detailed Operational Description | The doctor might need to call a colleague for consultation or to evaluate a specific result. To this end, the doctor has access to directories and can place a phone call by one mouse-click from just the computer he uses at that moment. This feature may be taken a step further to collaborative environments and expert call centres. |
| Problems and Challenges | The problems and challenges related to this scenario are the following:
|
| Additional Material | Sub use-case:
|
