|
|
| (32 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| − | ==Business Goals and Domain Assumptions==
| + | This page describes the artifacts of the Mobile eHealth case study. |
| | | | |
| − | In the following sections will be reported the Business Goals and the Domain Assumptions for the current
| + | == Description == |
| − | case study.
| |
| | | | |
| − | === Business Goals ===
| + | [[File:process.png]] |
| | | | |
| − | {| style="background:#cccc99;color:black;width:80%;" border="1" cellpadding="5" cellspacing="0" align="center"
| + | Figure 1 shows the PLASTIC Development Process and the related artifacts. |
| − | |+ Table BG1. Business Goal EHEALTH-BG-01
| |
| − | !Field !! Description
| |
| | | | |
| − | |- style="background:#f0f0f0; color:black"
| + | The '''MeH UML Model''' has been created using the MagicDraw UML modeling tool that can be downloaded here [www.magicdraw.com/]. MagicDraw UML can be seamlessly integrated with the Eclipse Modeling Project [http://www.eclipse.org/modeling/]. For this reason, the MeH UML Model can be opened both in MagicDraw and in any Eclipse UML compliant plugin of the Eclipse platform. |
| − | ! UniqueID
| |
| − | ||EHEALTH-BG-01
| |
| | | | |
| − | |- style="background:white; color:black"
| + | The '''MeHQnmodel.jsimg''' is a queuing Network model that has been created using the Java Modeling Tool [http://jmt.sourceforge.net/]. The QN model has beed derived from the MeH UML Model following the PRIMAUML model-based performance methodology [http://dl.acm.org/citation.cfm?id=607042]. The '''MeHQnmodel.jsimg''' can be opened in JMT and it can be executed to derive the performance indeces of interest. |
| − | ! Short Name
| + | It's worth noting that the transformation from UML2JMT has not been implemented. However a similar UML2PMIF transformation has been implemented in MOSQUITO starting from PLASTIC UML Model (see [http://sealabtools.di.univaq.it/tools.php]). |
| − | | Ubiquitous and Immediate Access to Patient Data
| |
| | | | |
| − | |- style="background:white; color:black"
| + | '''UML2wsdl'''_1.0.0. jar is an archive containing a model transformation from a PLASTIC Service UML Model to WSDL. It has been implemented in ATL. For additional information see the User Guide that can be downloaded from the Download Section. |
| − | ! Type
| |
| − | | Business Goals.
| |
| | | | |
| − | |- style="background:white; color:black"
| + | The RD Adaptable Midlet is a code artifact that uses an extended Java grammar as proposed by the CHAMELEON Framework. |
| − | ! Description
| + | It's worth noting that the case study proposes a possible implementation of the MeH MIDlets while a running example of the MeH System was implemented by Telefonica [http://www.ist-plastic.org/] and it is not available here. However an excerpt of the adaptable JAVA code for the MeH case study is shown in the paper published at PESOS 2012 [http://www.s-cube-network.eu/pesos-2012]. |
| − | | The system shall be able to reduce the overall duration of healthcare activities through ubiquitous and immediate access to patient data. Patient data shall be recorded from any activity of the medical staff, that is, Doctors directly involved in the patient’s diagnosis, but also staff persons performing only examinations or treatments prescribed by the Doctor. Moreover, any data coming from consultations of experts shall be recorded and made available. Patient data shall be ubiquitously available for the Doctor for further examinations.
| |
| | | | |
| − | |- style="background:white; color:black"
| |
| − | ! Rationale
| |
| − | | Improve the effectiveness and reliability of healthcare activities. Reduce costs of healthcare activities.
| |
| | | | |
| − | |- style="background:white; color:black"
| |
| − | ! Involved Stakeholders
| |
| − | | Doctors, Patients, Other Medical Staff
| |
| | | | |
| − | |- style="background:white; color:black"
| + | == Basic technology == |
| − | ! Conflicts
| |
| − | | None
| |
| | | | |
| − | |- style="background:white; color:black"
| + | WSDL, UML, Java, Queuing Network |
| − | ! None
| |
| − | |
| |
| | | | |
| − | |- style="background:white; color:black"
| + | == How to install == |
| − | ! Priority of accomplishment
| |
| − | | Must have.
| |
| − | |}
| |
| | | | |
| | + | All the artifacts and detailed procedures to install tools and case studies are provided here [http://code.google.com/a/eclipselabs.org/p/mobile-ehealth-case-study/] |
| | | | |
| − | {| style="background:#cccc99;color:black;width:80%;" border="1" cellpadding="5" cellspacing="0" align="center"
| + | == Download == |
| − | |+ Table BG2. Business Goal EHEALTH-BG-02
| |
| − | !Field !! Description
| |
| | | | |
| − | |- style="background:#f0f0f0; color:black"
| + | [http://code.google.com/a/eclipselabs.org/p/mobile-ehealth-case-study/] Mobile eHealth Case Study. The archive. |
| − | ! UniqueID
| |
| − | ||EHEALTH-BG-02
| |
| | | | |
| − | |- style="background:white; color:black"
| |
| − | ! Short Name
| |
| − | | Ubiquitous Access to Expert Consultancy
| |
| | | | |
| − | |- style="background:white; color:black"
| + | == Additional info == |
| − | ! Type
| |
| − | | Business Goals.
| |
| | | | |
| − | |- style="background:white; color:black"
| + | [http://dl.acm.org/citation.cfm?id=607042] Vittorio Cortellessa, Raffaela Mirandola: PRIMA-UML: a performance validation incremental methodology on early UML diagrams. Sci. Comput. Program. 44(1): 101-129 (2002) |
| − | ! Description
| |
| − | | The system shall facilitate the ubiquitous access to expert consultancy whenever a doctor working for a diagnosis for a specific patient needs it. The system shall provide easy access to expert address books, facilitate phone calls and should even provide mechanism to automatically manage full collaborative environments for medical experts.
| |
| | | | |
| − | |- style="background:white; color:black"
| + | [http://www.di.univaq.it/chameleon/publications.php] The CHAMELEON Framework |
| − | ! Rationale
| |
| − | | Improve the effectiveness and reliability of healthcare activities. Reduce costs of healthcare activities.
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Involved Stakeholders
| |
| − | | Doctors, Experts
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Conflicts
| |
| − | | None
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Supporting Material
| |
| − | | None
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Priority of accomplishment
| |
| − | | Must have.
| |
| − | |}
| |
| − | | |
| − | | |
| − | | |
| − | {| style="background:#cccc99;color:black;width:80%;" border="1" cellpadding="5" cellspacing="0" align="center"
| |
| − | |+ Table BG3. Business Goal EHEALTH-BG-03
| |
| − | !Field !! Description
| |
| − | | |
| − | |- style="background:#f0f0f0; color:black"
| |
| − | ! UniqueID
| |
| − | ||EHEALTH-BG-03
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Short Name
| |
| − | | Easier Planning of Examinations and Treatments
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Type
| |
| − | | Business Goals.
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Description
| |
| − | | The system shall be able to improve the reliability of healthcare activities through easier planning of examinations, therapies and any kind of treatments. The system shall be able to prevent, avoid or reduce human errors by facilitating medical expert interactions.
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Rationale
| |
| − | | Improve the effectiveness, reliability and duration of healthcare activities. Reduce costs of healthcare activities.
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Involved Stakeholders
| |
| − | | Doctors, Patients, Other Medical Staff, EHealth Organization
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Conflicts
| |
| − | | None
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Supporting Material
| |
| − | | None
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Priority of accomplishment
| |
| − | | Must have.
| |
| − | |}
| |
| − | | |
| − | === Domain Assumptions ===
| |
| − | | |
| − | {| style="background:#cccc99;color:black;width:80%;" border="1" cellpadding="5" cellspacing="0" align="center"
| |
| − | |+ Table DA1. Assumption EHEALTH-DA-01
| |
| − | !Field !! Description
| |
| − | | |
| − | |- style="background:#f0f0f0; color:black"
| |
| − | ! UniqueID
| |
| − | | |EHEALTH-DA-01
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Short Name
| |
| − | | Device Integration and Vertical integration
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Type
| |
| − | | Domain assumption
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Description
| |
| − | | The system shall consist of devices fully integrated in service-oriented architectures, that is, it shall be vertically integrated. For different kind of devices different embedded SOAs have to be developed including respective standards. The system shall provide a dependable device integration which will enable the data from different devices to be accessible in a dependable way. The complex diagnostic workflow system shall provide dependable access when the devices are used during a diagnosis or for monitoring a patient’s health status, that is, after the health data is integrated into application specific workflows, it shall be accessible in a dependable way.
| |
| − | In practice, there exist domain specific standards or best practices for device handling, such as the Microsoft Connected Health Framework (CHF) or the Eclipse OpenHealthFramework. Such standards are of great importance to the developers of applications for devices. These standards often contain domain specific information models and/or protocols and hence substantially facilitate the application development and interoperability.
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Rationale
| |
| − | | Enforce overall system integration, dependability and adaptability
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Involved Stakeholders
| |
| − | | Doctors, Other Medical Staff
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Conflicts
| |
| − | | None
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Supporting Material
| |
| − | | None
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Priority of accomplishment
| |
| − | | Could have.
| |
| − | |}
| |
| − | | |
| − | | |
| − | | |
| − | {| style="background:#cccc99;color:black;width:80%;" border="1" cellpadding="5" cellspacing="0" align="center"
| |
| − | |+ Table DA2. Assumption EHEALTH-DA-02
| |
| − | !Field !! Description
| |
| − | | |
| − | |- style="background:#f0f0f0; color:black"
| |
| − | ! UniqueID
| |
| − | | |EHEALTH-DA-02
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Short Name
| |
| − | | Compliance to Health Privacy and Security requirements
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Type
| |
| − | | Domain assumption
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Description
| |
| − | | The system should be compliant to security and privacy functions regarding treatments, services, workflows and individual services interactions. For example, in the Health domain the US-regulations are defined within the HealthPortability and Accounting Act (HIPAA) Privacy and Security rules. This standard covers all health stakeholders: individuals including doctors, nurses, pharmacists, physical therapists and organisations including hospitals, laboratories, pharmacies, nursing facilities and more generally, all health services and clearinghouses. The privacy and security rules require safeguarding all PHI (e.g. Protected Health Information).
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Rationale
| |
| − | | Effectively manage security and privacy policies, by relying on recognized standards in the world of healthcare. Without this requirement, a
| |
| − | specific security and privacy policy will have to be defined.
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Involved Stakeholders
| |
| − | | Doctors, Patients, Other Medical Staff, EHealth Organization
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Conflicts
| |
| − | | None
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Supporting Material
| |
| − | | Some documents that illustrate and explain this requirement:
| |
| − | | |
| − | * http://www.hipaa.org/
| |
| − | * http://www.hhs.gov/ocr/hipaa/finalreg.html
| |
| − | * http://privacyruleandresearch.nih.gov/resources.asp
| |
| − | * http://www.hipaacomply.com/
| |
| − | * http://www.ioma.org/pdf/iomahipaahelp.pdf
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Priority of accomplishment
| |
| − | | Should 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 diagnosis for the Patient, and plans examinations and treatments which are managed
| |
| − | by the EHealth Organizations. He/She can also request a consultancy to some experts. Moreover, the
| |
| − | medical staff can monitor patient’s data.
| |
| − | | |
| − | [[File:SDD.png]]
| |
| − | | |
| − | | |
| − | 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. | |
| − | | |
| − | [[File:SD.png]]
| |
| − | | |
| − | === 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.
| |
| − | | |
| − | | |
| − | [[File:DomainModel.jpg]]
| |
| − | | |
| − | == Scenarios==
| |
| − | | |
| − | The following figure shows the general use-case diagram for the EHealth case study.
| |
| − | | |
| − | | |
| − | [[File:GlobalUseCase.jpg]]
| |
| − | | |
| − | | |
| − | | |
| − | {| style="background:#cccc99;color:black;width:80%;" border="1" cellpadding="5" cellspacing="0" align="center"
| |
| − | |+ Table S1: Scenario EHEALTH-S-01
| |
| − | !Field !! Description
| |
| − | | |
| − | |- style="background:#f0f0f0; color:black"
| |
| − | ! UniqueID
| |
| − | | |EHEALTH-S-01
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Short Name
| |
| − | | Access previously collected health data
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Related To
| |
| − | | EHEALTH-BG-01, EHEALTH-DA-02
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Involved Actors
| |
| − | | Doctor, Other Medical Staff
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! 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).
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Problems and Challenges
| |
| − | | The problems and challenges related to this scenario are the following:
| |
| − | | |
| − | * Legal and technical issues with distributed and shared patient records
| |
| − | * Integration across domains
| |
| − | * Horizontal (enterprise information systems) and vertical integration (devices)
| |
| − | * Platform heterogeneity, interoperability
| |
| − | * HIPAA privacy and security compliance
| |
| − | * Patient chart autorization access and protection
| |
| − | * Procedure that maintain electronic protected health information to allow access only to those persons or programs that have been
| |
| − | granted access rights
| |
| − | * Emergency access procedure for obtaining necessary electronic protected health information during an emergency
| |
| − | * Dependability, performance, security, and trust
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Additional Material
| |
| − | | None
| |
| − | |}
| |
| − | | |
| − | | |
| − | {| style="background:#cccc99;color:black;width:80%;" border="1" cellpadding="5" cellspacing="0" align="center"
| |
| − | |+ Table S2: Scenario EHEALTH-S-02
| |
| − | !Field !! Description
| |
| − | | |
| − | |- style="background:#f0f0f0; color:black"
| |
| − | ! UniqueID
| |
| − | | |EHEALTH-S-02
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Short Name
| |
| − | | Access current health data
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Related To
| |
| − | | EHEALTH-BG-01, EHEALTH-DA-02
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Involved Actors
| |
| − | | Doctor, Other Medical Staff
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! 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.
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Problems and Challenges
| |
| − | | The problems and challenges related to this scenario are the following:
| |
| − | | |
| − | * Integrate on demand data from various devices
| |
| − | * Store working sessions and allow to move sessions between devices
| |
| − | * Integration of distributed workflows, distributed transactions, federated identities
| |
| − | * Integration across domains
| |
| − | * Horizontal (enterprise information systems) and vertical integration (devices)
| |
| − | * Platform heterogeneity, interoperability
| |
| − | * HIPAA privacy and security compliance
| |
| − | * Use or disclosure of Protected Health information (PHI): Health
| |
| − | * Mitigation procedures to address unauthorized user
| |
| − | * Patient chart autorization access and protection
| |
| − | * Dependability, performance, security, and trust
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Additional Material
| |
| − | | Sub use case:
| |
| − | | |
| − | [[File:UseCaseDiagram2.jpg]]
| |
| − | | |
| − | |}
| |
| − | | |
| − | | |
| − | | |
| − | {| style="background:#cccc99;color:black;width:80%;" border="1" cellpadding="5" cellspacing="0" align="center"
| |
| − | |+ Table S3: Scenario EHEALTH-S-03
| |
| − | !Field !! Description
| |
| − | | |
| − | |- style="background:#f0f0f0; color:black"
| |
| − | ! UniqueID
| |
| − | | |EHEALTH-S-03
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Short Name
| |
| − | | Access health data during examinations
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Related To
| |
| − | | EHEALTH-BG-01, EHEALTH-BG-04, EHEALTH-DA-02
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Involved Actors
| |
| − | | Doctor, Patient, Other Medical Staff
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! 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.
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Problems and Challenges
| |
| − | | The problems and challenges related to this scenario are the following:
| |
| − | | |
| − | * Integrate on demand data from various devices
| |
| − | * Store working sessions and allow to move sessions between devices
| |
| − | * Integration of distributed workflows, distributed transactions, federated identities
| |
| − | * Integration across domains
| |
| − | * Horizontal (enterprise information systems) and vertical integration (devices)
| |
| − | * Platform heterogeneity, interoperability
| |
| − | * HIPAA privacy and security compliance
| |
| − | * Patient chart autorization access and protection
| |
| − | * Emergency access procedure for obtaining necessary electronic protected health information during an emergency
| |
| − | * Dependability, performance, security, and trust
| |
| − | | |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Additional Material
| |
| − | | Sub use-case:
| |
| − | [[File:UseCaseDiagram3.jpg]]
| |
| − | | |
| − | |}
| |
| − | | |
| − | | |
| − | {| style="background:#cccc99;color:black;width:80%;" border="1" cellpadding="5" cellspacing="0" align="center"
| |
| − | |+ Table S4: Scenario EHEALTH-S-04
| |
| − | !Field !! Description
| |
| − | | |
| − | |- style="background:#f0f0f0; color:black"
| |
| − | ! UniqueID
| |
| − | | |EHEALTH-S-04
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Short Name
| |
| − | | Expert Consultation
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Related To
| |
| − | | EHEALTH-BG-02, EHEALTH-BG-05, EHEALTH-DA-02
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Involved Actors
| |
| − | | Doctor, Expert
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! 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.
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Problems and Challenges
| |
| − | | The problems and challenges related to this scenario are the following:
| |
| − | | |
| − | * Legal and technical issues with distributed and shared patient records
| |
| − | * Store working sessions and allow to move sessions between devices
| |
| − | * Integrate external applications (telephony, reservation, external patient records)
| |
| − | * Integration of distributed workflows, distributed transactions, federated identities
| |
| − | * Integration across domains
| |
| − | * Horizontal (enterprise information systems) and vertical integration (devices)
| |
| − | * Platform heterogeneity, interoperability
| |
| − | * Procedure that maintain electronic protected health information to allow access only to those persons or programs that have been granted access rights
| |
| − | * Emergency access procedure for obtaining necessary electronic protected health information during an emergency
| |
| − | * Dependability, performance, security, and trust
| |
| − | | |
| − | |- style="background:white; color:black"
| |
| − | ! Additional Material
| |
| − | | Sub use-case:
| |
| − | | |
| − | [[File:UseCaseDiagram4.jpg]]
| |
| − | | |
| − | | |
| − | |}
| |
The RD Adaptable Midlet is a code artifact that uses an extended Java grammar as proposed by the CHAMELEON Framework.
It's worth noting that the case study proposes a possible implementation of the MeH MIDlets while a running example of the MeH System was implemented by Telefonica [5] and it is not available here. However an excerpt of the adaptable JAVA code for the MeH case study is shown in the paper published at PESOS 2012 [6].
All the artifacts and detailed procedures to install tools and case studies are provided here [7]
