J Med Syst (2016) 40:270 DOI 10.1007/s10916-016-0632-0
MOBILE & WIRELESS HEALTH
Behavioral Reference Model for Pervasive Healthcare Systems Arezoo Tahmasbi 1 & Sahar Adabi 2 & Ali Rezaee 1
Received: 17 July 2016 / Accepted: 3 October 2016 # Springer Science+Business Media New York 2016
Abstract The emergence of mobile healthcare systems is an important outcome of application of pervasive computing concepts for medical care purposes. These systems provide the facilities and infrastructure required for automatic and ubiquitous sharing of medical information. Healthcare systems have a dynamic structure and configuration, therefore having an architecture is essential for future development of these systems. The need for increased response rate, problem limited storage, accelerated processing and etc. the tendency toward creating a new generation of healthcare system architecture highlight the need for further focus on cloud-based solutions for transfer data and data processing challenges. Integrity and reliability of healthcare systems are of critical importance, as even the slightest error may put the patients’ lives in danger; therefore acquiring a behavioral model for these systems and developing the tools required to model their behaviors are of significant importance. The high-level designs may contain some flaws, therefor the system must be fully examined for different scenarios and conditions.
This article is part of the Topical Collection on Mobile & Wireless Health * Arezoo Tahmasbi
[email protected] Sahar Adabi
[email protected] Ali Rezaee
[email protected] 1
Science and Research Branch, Department of Computer Engineering, Islamic Azad University, Tehran, Iran
2
North Tehran Branch, Department of Computer Engineering, Islamic Azad University, Tehran, Iran
This paper presents a software architecture for development of healthcare systems based on pervasive computing concepts, and then models the behavior of described system. A set of solutions are then proposed to improve the design’s qualitative characteristics including, availability, interoperability and performance. Keywords Pervasive healthcare systems . Cloud computing . Software architecture . Behavioral model . Service . Qualitative characteristics
Introduction Pervasive computing is an emerging model for provision of computing and communications services at all times and all places [1]. This concept allows users to have immediate access to information from any place and at any time [2]. Healthcare is one of the most interesting applications of pervasive computing [3, 4]. The Healthcare related applications of pervasive computing, which are often realized by planting a wireless network on the body, include -but are not limited to- provision of e-health services, remote monitoring, disease control, and monitoring the medical status of soldiers during combat missions [5, 6]. Cloud computing is another relatively new computing approach that has found growing application in healthcare related services [7]. Figure 1 shows the general concept of pervasive healthcare system based on cloud computing. Integration of pervasive healthcare system with the concepts of cloud computing can improve the efficiency, scalability, computing power, storage capacity and overall system performance of health monitoring systems [8, 9].
270
J Med Syst (2016) 40:270
Page 2 of 23
Fig. 1 Pervasive mobile healthcare system based on Cloud computing
To achieve a reliable and high-performance healthcare system, having access to an applicable and complete software architecture to model these systems is of significant importance [10]. Garlan and Shaw define software architecture as Ba structure that defines software components of a system, their visible features and the relationships between them^ [11]. This definition focuses on the internal aspects of a system and acts as the basis of most methods of analysis. The aim of this paper is to propose a software architecture for mobile healthcare system based on cloud computing. The purpose of this paper is to propose a software architecture for a cloud-based healthcare system for mobile patients. The proposed architecture is focused on nonfunctional requirements including availability, interoperability, and performance [12]. To enhance the system efficiency and availability, the cloud major component is designed in the form of multiple independent clouds and also makes use of virtualization concept [13]. Virtualization means assembling a computer from a set of distributed components including processing resources, storage resources, data and software [14]. The cloud computing technology provides the necessary platform for such assembly, and hence the possibility of gaining access to extensive amount of processing power and storage resources as a single virtual system [15]. To increase system availability, medical information are stored in multiple separate clouds, and in emergency situations or in case of failure of patent major component to connect to any cloud server, the information will be sent to the nearest patient [16]. To achieve interoperability, the scheme of communication and collaboration (eg the compatibility
of data formats) between components of different clouds and their users including patients, physicians and healthcare system operators is defined. To enhance system performance, data processing is designed to be routed through components with minimum response time. The rest of this article is organized as follows: Related Work Section reviews the previous works on the subject; The Proposed Software Architecture Section discusses the integrated architecture and different system components and describes the software architecture proposed for proposed pervasive healthcare system, its components and their relationships; and The Proposed Architectural Views Section describes the qualitative characteristics and their role in improving the system implementation process; Process View Section contains conclusions.
Related work This section provides a brief introduction to a number of proposed healthcare systems and their work procedures. One of these healthcare systems is Code Blue, which has been designed to enhance the ability of rescue workers and allow patients to be examined while carrying out their normal activities [17]. Another system is Mobi-Health, which is a UMTS and GPRS based universal plan for provision of point to point care for mobile patients [18, 19]. @Home is another healthcare system which allows the patient’s heart rate, blood pressure and oxygen level to be reported remotely from their home. In this method, patient will be provided with portable sensors that will transmit
J Med Syst (2016) 40:270
the patient's health information by Bluetooth or DECT communication link to a local computer [20, 21]. TeleCARE project has been designed as a platform for helping the elderly and their caregivers. This project uses a number of different methods to integrate the Internet with agent technology and mobile agents [22–24]. My-heart is an integrated project supported by the European Union to promote the use of intelligent systems for the prevention and monitoring of cardiovascular diseases. This project is based on development of smart wearables and related electronic systems and provision of appropriate services that allow users to monitor their health status. In this system, the wearable technology plays a central role in measuring and monitoring the vital signs and health parameters [25–27]. The abovementioned mobile healthcare systems have not been designed based on cloud computing, and may therefore be susceptible to issues such as inadequate access, inadequate data storage and low computing power. Provision of comprehensive healthcare services and improvement of e-health systems have been the subjects of extensive research, and some of these works have suggested the cloud infrastructure as a high-potential approach. The Integrated Cloud-based Healthcare Infrastructure project developed in the Edinburgh Napier University (UK) provides a sharing platform and proper access to health records in a highly secure and privacy complete cloud environment [28]. The IOTC 1 project developed by the University of Central Greece is a cloud-based platform for management of mobile and wearable healthcare sensors [29]. There are also a number of mobile healthcare systems that are specifically designed for diabetic patients. One of these projects, which has been developed by the University of London, is called Commodity and provides a smart healthcare environment to aid diabetic patients [30]. The MWCS 2project developed by the University of Greece uses wearable sensors to record heartbeat information and then stores them on a cloud server for further processing and examination [31]. In the University of Murcia, another healthcare study for diabetes is developed, BAn Internet of Things-based Personal device for Diabetes Therapy Management in Ambient Assisted Living (AAL)^, PDIT, which presents a personal diabetes management device based on Internet of Things - so as to support a patient’s insulin therapy to decrease hyperglycemia count and the risks involved [32]. BCloud-Enabled Wireless Body Area Networks for Pervasive Healthcare^ uses the mobile cloud computing capabilities and cloud-enabled wireless body area network 1 2
Bringing IOT and Cloud Computing towards Pervasive Healthcare Managing Wearable Sensor Data through Cloud Computing
Page 3 of 23 270
(WBAN) architecture for pervasive healthcare applications. This project has also been developed in the South China University, King Saud University, and the University of British Columbia [33]. The Personal Health Service Framework (PHSF) is proposed which is an open architecture for developing patient-centric health applications and monitoring systems. PHSF uses new advancements of service-oriented architecture to provide a baseline for developing healthrelated systems. PHSF services are used to make selfmonitoring and remote monitoring possible, and to link healthcare operators and patients [34]. In [35] presents an architecture for health information exchange in pervasive healthcare environments meant to be generally applicable to different applications in the healthcare domain. This architecture has been designed for message exchange by integrating ubiquitous computing technologies, intelligent agents and healthcare standards, in order to provide interoperability between healthcare systems. The Publish/Subscribe Architecture is one of the convenient architectures to support such systems. So using a proper formal language like graph transformation systems for developing of these systems seems necessary. In this paper, a dynamic architectural style for developing Pervasive Healthcare Systems is presented [36].
The proposed software architecture This section describes the proposed system architecture, components and communication technology between components. Figure 2 shows a view of the proposed architecture. The proposed system architecture consists of four major component dedicated to patient, physician, healthcare operator and a cloud server for data storage. The components of are this healthcare system and then functions described in Table 1. The proposed architecture uses a combination of private cloud space and Public or hybrid partner cloud servers. Private cloud server consists of dispersed data centers, on which multiple virtual machines are installed to increase the scalability of the system [39]. In data centers of the private cloud servers, data type, access levels, and their compatibility model are classified as shown in Table 2. When the private cloud data center is unavailable or a certain type of information is not supported by the private cloud server, information will be sent to partner cloud servers. To protect the security and privacy of patients’ medical information, these data will be placed in specified data center, but the method of accessing and synchronizing this
270
J Med Syst (2016) 40:270
Page 4 of 23
Fig. 2 The proposed architecture for cloud-based healthcare system
information is a challenge that is not addressed in this paper and must be covered in future work. Each component that needs a specific data item should request access from the service pertaining to that data time. So services of all related data items can be placed in one virtual machine to increase the scalability of the system. The proposed architectural views The proposed software architecture is described by means of diagrams and charts expressing and illustrating the Table 1
components and their relationships as well as constraints. The proposed software architecture is expressed by the use of 4 + 1 views [40]. This view, which has been designed by PhilippeKruchten for describing the architecture of software systems, is based on the use of several views describing the system from different perspectives, such as the viewpoint of end-users, developers and project managers. The four views of this model are: logical view, development view, process view and physical view. In addition to these views, model also employs use cases for describing the architecture.
Major components of proposed healthcare system
Major Component
Function
The patient major component
• Collecting the medical data from sensors connected to the patient’s body. • Storing and displays the medical data. • Updating the daily test results, adds medication and dietary data. • Requesting a feedback from operator or physician. • Transmitting the emergency information to nearest patient to send to the cloud server. • Communicating with cloud server via a LAN through an access point determined by smartphone or via 3G or 4G network [37] Managing personal health records (PHR) and facilitating the sharing of information between patients and service providers [38] Monitor and enforce the necessary decisions to improve patient’s health status, whether it be through prescription of medication or by dispatching an ambulance Monitor and control patient’s data and apply necessary updates; in case of emergency, this operator is tasked with contacting the patient’s family and dispatching ambulance
The cloud server major component The physician major component The healthcare operator major component
Page 5 of 23 270
Static
Strict Eventual Eventual Eventual
Eventual Strict
Eventual
Strict
& Strict Strict Eventual
Compatibility Model
J Med Syst (2016) 40:270
&
Static Static Middle Middle
Low
High Low Low Middle
Middle
Physicians information Hospitals information
Patient, medical records information
Patient prescription information Electronic Radiology Emergency Information
Patient location information
6 7
8
9 10 11 12
13
Dynamic Dynamic Dynamic Static
Static Low Patient’s relatives information 5
Dynamic
Static Middle Middle 4
Dynamic
Hypertension - Blood sugar - Heartbeat - Body temperature ECG - Brain bar - Muscle strip - Weight Name - The number of children - Height Age - Sex - Blood - National ID - ID number - Insurance code Mobile phone number - Home phone number and address An address, Postcode and telephone number of user Name - the patient’s home phone number and address postcode - Cell Phone Number Name - The type of expertise - Phone - Address Hospital name - Number - Type of hospital (private or public) Hospital address Disease - Years of disease - Treatment of the disease Remission status Treatment and control of disease Electronic images entities - Pay stubs picture MRI - Scan Emergency name - Address the emergency - Phone number The number of ambulances Patient place in an emergency Dynamic Dynamic Static High Middle Low Patient vital information Patient per Non-medical personal information 1 2 3
Table 2
Data items of the healthcare system
Data Type Access level Data Item Name Data Item
Components
&
&
&
Logical view: this view illustrates the capabilities that the designed system provides to end-users. Development view: this view describes the designed system from the viewpoint of software developers and is involved with software management. This view is also known as the implementation view. Process view: this view illustrates the dynamic aspects of the system and describes the system processes and their interactions and the runtime behavior of the system. This view covers the aspects of concurrency, distribution, performance and scalability. Physical view: this view illustrates the system from the perspective of a system engineer, and is focused on the topology of software components of the physical layer and their physical connections. Use Cases: The use cases or scenarios describe the architecture through describing the sequence of relationships between objects as well as processes [41].
In the following, 4 + 1 views for the proposed architecture are described. Use case view Different systems may have different requirements, and developers are responsible for assessing the particular needs and forming a system to meet these requirements. These requirements can be generally divided in to two categories: functional requirements and non-functional requirements [11]. Functional requirements are related to system’s ability to do the task for which it has been designed. For each of the subsystems, there are a number of primary and functional requirements that must be met [42]. To provide a better understanding regarding proposed healthcare system behavior, Use Cases of the system component are shown in Table 3. Use Case diagram for this healthcare system [43] is illustrated in Fig. 3. Process view In the proposed architecture, the flow of data starts from medical sensors that transmit health-related information to patient major component; this component analyzes the information, and when there is no emergency, stores them in a local database on the mobile phone and send them on a daily basis to cloud major component. When component detects an emergency, it immediately sends the data with an emergency tag to cloud server. Cloud server forwards the patient’s emergency data to physician, if no emergency state, data analysis in the cloud and taken necessary actions and stored.
270
J Med Syst (2016) 40:270
Page 6 of 23
Table 3 Use Cases of the proposed healthcare system
Component
Use Cases
Patient major com
• Receiving data from sensors • Analyzing data • Sending data to remote Cloud • Storing data in mobile database • Providing necessary reminders and Instructions to patient
Cloud server major component
• Exchanging data with patients, physicians and operators • Analyzing data • Analyzing the patients’ medical history • Storing information • Exchanging data with the cloud application • Updating the patient’s medical information • Reporting emergency situation • Exchanging data with the cloud application • Updating patient information • Dispatching ambulance
Physician major
Healthcare operator major component
Once physician receives the information, he assesses the patient’s condition and then sends the necessary instructions to the cloud. The physician’s orders will then be forwarded to the patient instructing him to take the necessary measures, or to the healthcare operator instructing him to contact the patient’s family or dispatch an ambulance. Once healthcare system operator receives the information, he addresses the issues based on their importance by dispatching an ambulance, contacting the patient’s family,
Fig. 3 General use cases diagram for proposed pervasive healthcare system
or updating the patient’s information. Figure 4 the system major flow.
Development view The proposed system major components consists of several components, each with high integration with and dependence on other components for low level communications. Description of each components of the major components is
J Med Syst (2016) 40:270
Page 7 of 23 270
Fig. 4 Pervasive healthcare system major flow
checkd separately. In the cloud-side major component, each component is considered as a service. &
Components of patient major component Data-Acquisition: receiving and converts the data into suitable format.
Inference: consists of a set of subcomponents for processing the information received from the cloud or sensor, for managing, controlling and prioritizing information. Encryption-decryption: encrypting and decrypts the information. ConnectionToCloud: sending data over the network for cloud-side processing.
270
Page 8 of 23
Notification: monitoring the outputs of Inference and provides necessary reminders schedules, suitable exercises, proper diet, medicines and medical advices. Data-Access: acting as a database for storage of patient’s information. GIU: allowing patient to interact with the system and provides: – – – – –
Graphical representation of the test results, eg the graph of blood glucose (allowing the patients to view the history of fluctuations of their blood sugar); access to medical data, suggested exercises, diet, and information about medicine; Information on the healthcare team, eg contact information; Access to test results on a daily, weekly basis or another specified period; Notifications and alerts reminding the patients to check the physician feedbacks, take medications, and their schedules.
The Components of patient major component are shown in Fig. 5. &
Components of private cloud major component
According to Fig. 6 the components of private cloud major component are as follows. Edge-Service: exchanging information with users and partner cloud servers.
Fig. 5 Components of patient major component
J Med Syst (2016) 40:270
Encryption-decryption: encrypting and decrypts the information. Transform: converting the information to suitable formats. Parametric-Analysis: checking the received information and determines that whether database contains the service associated with the data item. Early-Response: forwarding urgent information from patient to physician even if data is not supported by the data center. It also handles the physician’s urgent orders to patients, physician’s request from operator to dispatch ambulance, or to identify the location of patient and nearest medical center. Analysis: analyzing the information and keep track of patient’s information history to find and report suspicious trends that might lead to urgent conditions. It also adds, deletes, and updates the patients’ data when required. Estimate-RT: predicting the response time of virtual machines providing the Analysis service. RT-VM: assessing the response times reported by Estimate-RT and selects the virtual machine with most suitable response time. In case of failure to find a virtual machine with suitable response time, it issues a warning message. Pathway-VM: acting as a gateway for sending information to the virtual machine with suitable response time in the current data center. In case of absence of a virtual machine with suitable response time, information will
J Med Syst (2016) 40:270
Page 9 of 23 270
Fig. 6 Components of private cloud major component
be sent to a data centers with suitable response time or to a partner cloud server. RT-OtherDC: using the cloud management service to select from available data centers, the one that can support the data type under process with the suitable response time.
In case of absence of an accessible data center with suitable response time, data will be transferred through the partner cloud servers having appropriate permissions for the data being processed. &
Components of partner cloud major component
270
Page 10 of 23
J Med Syst (2016) 40:270
Edge-Service: exchanges information with users and private cloud servers. Analysis: analyzes the information and keep track of patient’s information history to find and report suspicious trends that might lead to urgent conditions. It also adds, deletes, and updates the patients’ data when required. The components of partner cloud major component are shown in Fig. 7.
&
Components of physician major component Data Acquisition: receiving information from the cloud and send information to the cloud for storage. Inference: assessing and prioritizes the received information, allows the physician to take necessary measures with respect to urgency of situation (prescribe medication or order an ambulance to be dispatched), ands register the information on the cloud for further processing. Encryption-decryption: encrypting and decrypts the information.
The Components of physician major component are shown in Fig. 8. &
Components of healthcare operator major component
Fig. 7 Processes and connectors of partner cloud major component
Fig. 8 Components of physician major component
Data Acquisition: Receiving information from the cloud and send information to the cloud for storage. Inference: Allowing the operator to respond to emergency situations by contacting patent’s family or dispatching ambulance. Encryption-decryption: Encrypting and decrypts the information.
Fig. 9 Components of healthcare operator major component
J Med Syst (2016) 40:270
The Components of healthcare operator major component are shown in Fig. 9. Physical view In the proposed architecture, components and processes use two manners for data transfer and communication: message passing and shared memory [44]. Message passing is used to transmit control messages and in figures show the connection with MP, while shared memory is used to connect two processes working on shared data. Access to shared data is provided through two manners. The first manner is the use of Permanent Memory, ie information will be stored by a process or component in a permanent memory and will be accessed by other processes and components that in figures show the connection with PM. The second manner is the use of Temporary Memory, information will be placed by a process or component in a memory block and will be accessed by another process or components. In figures show the connection with M.
Fig. 10 Processes and connectors of patient major component
Page 11 of 23 270
Communication between components in the cloud server major component is always the message passing. The components described in the following have a series of subcomponents and processes. These subcomponents and collaborative processes and the mechanism of communication between them in various major components will be considered in the following. &
Physical view in the patient major component DataAcquisition: The component has a Receive subcomponent consisting of the ReceiveData process for receiving data and the ReceiveWarning process for receiving control message from medical sensors. NearPatient: The component consists of the TransferData process for data exchange and the Authentication process for verification of user identity and information. Inference: The Inference component of patent major component has an Analysis subcomponent consisting of the Analyze process for processing the information
270
Page 12 of 23
received from sensors, cloud, or information received from near patients NearPatient component, the SaveToDB process for storing information on a local database, and the ConnectionToCloud process for transferring the information to the cloud. Notification: In the Notification component, the Reminder process is use to remind patients about their medications and diets, the Scheduler process is
Fig. 11 Processes and connectors of private cloud server major
J Med Syst (2016) 40:270
tasked with managing the schedule of patient’s medications and diets, preventing interruption in their consumptions, and the TestResult process depicts the information received from the sensor in form of charts for the patient. Communication in patient major component are described in Fig. 10.
J Med Syst (2016) 40:270
&
Page 13 of 23 270
Physical view in the private cloud and partner cloud major component
In the private cloud major component, according to Fig. 11 data transfer as follows: Trransform: The Transform component consists of TransformforPartner and TransformforUser processes for converting the information from the format of private cloud to the format suited for partner clouds and users. Pathway-VM: In the component, the TransferforRT process is tasked with receiving information and sending request to the RT-VM component for reporting the components with lower response times for data processing. The TransfertoRTOtherDC process sends a request to the RT-OtherDC components to find a data center with good response time, the TransfertoOtherDC component acts as an intermediary for transferring the information to another data center, and the CheckValidation process is tasked with checking the responses received from the RTVM and the RT-OtherDC components and finding the component with suitable response time for processing the information. RT-VM: In the RT-VM component, the Transfer process is an intermediary for data transfer between the
Fig. 12 Processes and connectors of partner cloud major component
Fig. 13 Processes and connectors of physician major component
RT-VM and the Pathway-VM components, and the ResponseTime process is tasked with sending request for reporting the response time of componentsand determining the component with shorter response time.
Fig. 14 Processes and connectors of health operator major component
270
J Med Syst (2016) 40:270
Page 14 of 23
Processes and the mechanism of communication Details are shown in Fig. 12. Also message passing is used to transmit information between major components in the roposed health care system. &
Physical view in the physician and healthcare operator major component DataAcquisition: The component consists of the TransferData process for data exchange and the TransferWarning process for transferring the control messages. Inference: The Inference component of physician major component has two processes, the Analysis process for processing the information received from the cloud, and the Notification process for managing the reminders and schedules required to handle patients.
The procedural details and connections in the physician major component and healthcare operator major component are described in Figs. 13 and 14. Fig. 15 The class diagram of the patient major component
RT-OtherDC: In the component, the Transfer process is designed to transfer information between as the RT-VM and the Pathway-VM components, and the RequestRT process is tasked with sending request to the CloudManagement asking for a data center with a suitable response time. Components and processes in the partner cloud, have the same duties the private cloud components and processes.
Fig. 16 The class diagram of the cloud major component
Logical view In the following shows the relationship between different classes defined in proposed pervasive healthcare system. These classes are designed to analyze and store the information, display the test results, remind patients to take their medicines and to address the condition of patients. Functions of each class in the patient, physician, health operator, and cloud components are briefly described in the following.
J Med Syst (2016) 40:270
&
Patient major component’ classes Receive: Class as an interface to receive information from sensors. Convert: Class for converting data from the sensor to the desired format. Analysis: The Analysis class is tasked with processing the information received from the cloud or sensors, converting them into the desired format, processing the user information, and authentication of users. ConnectionToCloud: The ConnectionToCloud class is tasked with sending the emergency information to the cloud, and receiving information from the cloud and sensors MessegeNotification: The MessegeNotification class is tasked with making necessary reminders, displaying schedules, showing recommended exercises, diets, and medications, and reminding physician’s orders. DataAccess: The DataAccess is a database for storing the patient’s information. Figure 15 illustrates the class diagram for patient major component.
&
Private cloud major component’ classes Edge: The Edge class is tasked receiving information from patient-side, physician-side, and operator-side major components, and analyzing and storing and received information. EerlyEstimation: The class detects the urgent and important information and forwards them directly to appropriate users, including patients, physicians, and system operators. ParametricAnalysis: The class checks the data validation. Analysis-cloud: The Analysis class is responsible for information analysis. DataAccess: The class stores the patients’ information in the cloud server. CheckLoadOtherDC, SearchSuitableDC, LoadBalancerVM, EstimationRT: classes to select the data center and virtual machine with the most Partner cloud major suitable response time for data analysis.
&
Page 15 of 23 270
Fig. 17 The class diagram of the physician major component
DataAcquisition-Physician: acting as an interface for exchanging the necessary information with the cloud server. Analysis-Physician: The Analysis class processes and analyzes the information received from the cloud, detects the patient’s critical condition, and sends the patient information to the cloud server in order to update the patient’s medical file. Notification-Physician: The class is tasked with providing necessary alerts and reminders.
Partner cloud major component’ classes Edge-PartnerCloud: class for exchanging information with the private cloud major component or users. Analysis: The class for information analysis. DataAccess: The DataAccess class stores the patients’ information in the cloud server.
The class diagram for private and partner cloud major component shown in Fig. 16. &
Physician major component’ classes
Fig. 18 The class diagram of the Health operator major component
270
J Med Syst (2016) 40:270
Page 16 of 23
Fig. 19 The sequence diagram of data processing in the patient major component
Figure 17 illustrates the class diagram for physician major component.
Figure 18 illustrates the class diagram for component. Sequence diagram
&
Healthcare operator major component’ classes DataAcquisition-HealthOperator: acting as an interface for exchanging the necessary information with the cloud server. Analysis-HealthOperator: The class analyzes the received information, and when necessary, takes the necessary measures to contact the patient’s family or dispatch an ambulance. This class is also tasked with updating the patient’s medical file. Notification-HealthOperator: The class is responsible for providing alerts and reminders.
A sequence diagram is used to demonstrate the routine sequence of system processes. One of the main system processes is the channeling of patient’s emergency information, which is essential for proper handling of situation by physician or system operator. As Fig. 19 shows, the sequence of data transfer starts with patent major component receiving and processing the information sent by sensors, and then sending the information deemed as urgent to the cloud. Figure 20 shows the data processing routine of the cloud. The cloud major components process the
Fig. 20 The sequence diagram of data processing in the cloud major component
J Med Syst (2016) 40:270
Page 17 of 23 270
Fig. 21 The sequence diagram of data processing in the physician major component
information and in case of detection of emergency condition forwards the patient’s medical information to the appointed physician. As Fig. 21 shows, physician assesses the patient’s file, history, and condition and then sends the necessary instructions (which could be addressed to patient or system operator) to the cloud. The cloud processes the physician’s instructions and when necessary alerts the healthcare system operators.
As shown in Fig. 22, once alerted, system operators review the physician’s instructions take the necessary measures to handle the situation.
Qualitative characteristics Non-functional requirements of a system are knowns as qualitative characteristics and are generally expressed as all
Fig. 22 The sequence diagram of data processing in the healthcare system operator major component
270
Page 18 of 23
J Med Syst (2016) 40:270
Fig. 23 Sending information to the nearest patient
features that are not among functional requirements Such as performance, security, reusability, reliability and etc. [11]. This paper provides some solutions for achieving qualitative characteristics including availability, performance, and interoperability. Availability qualitative characteristics Proper access to health information is essential, so to ensure the adequate transmission of necessary information to cloud servers and systems and guarantee system availability, the proposed architecture uses a mechanism based on which in case of failure of patent major component to transmit medical information. The information will be sent to nearest patient and after validation will be forwarded to the cloud server. The basic assumption in this approach is that project is implemented on a large scale and a high number of patients use this system to keep track of their medical conditions.
Fig. 24 Flow Receive information from the nearest patient
In the proposed procedure, in the absence of a response from cloud servers notifying the proper transmission of information, normal (non-urgent) data will be scheduled for resend, but the information tagged as urgent will be send to nearest patient, and this process provides better system availability and performance. In Fig. 23 is showed the flow of data transfer in the patient major component that the flow of availability is bold. Also Fig. 24 illustrates the procedure used to provide availability and receive information from other patients in case of failure to submit information on their own.
Interoperability qualitative characteristics An important issue in developing a system model is to ensure proper interoperability, which is the ability of components of different subsystem to work together coherently toward their objectives.
J Med Syst (2016) 40:270
Fig. 25 Flow data format conversion used in the proposed healthcare system
Page 19 of 23 270
270
Page 20 of 23
Compatibility of data formats used by different subsystems is an example of this concept [45]. In the proposed architecture, patient-side, physicianside, and operator-side major component analyze all medical and health information in XML format and use HL7 [46] format and MLLP protocol on TCP / IP [47] to exchange data with cloud server. MLLP is a network-based protocol that is widely used to transmit data in HL7 format. All information received by the private cloud should be in HL7 format. Proposed system uses partner cloud servers in addition to private cloud to improve availability and performance. In this paper, the IBM [48] and AMAZON [49] partner cloud servers are assumed to be used for this purpose. The data exchange with the IBM cloud server are assumed to be based on MLLP on TCP / IP and HL7 format [50]. For the AMAZON cloud server, data is assumed to be transmitted based on SOAP or REST [51] and to be in XML format. So the XSLT standard is used to convert the HL7 to XML before being transmitted to AMAZON cloud [52]. Figure 25 illustrates the procedure used to provide interoperability. Performance qualitative characteristics In proposed architecture, cloud servers forwards the information sent by the patient, physician or healthcare system operator to the nearest data center, which of course will remain hidden from outside users. To increase the efficiency of the process, the information decoded and reformatted in the data center undergo
Fig. 26 Flow process of sending emergency information
J Med Syst (2016) 40:270
an early validation process carried out through parametric analysis to determine whether or not they are supported by the private cloud. Information that cannot be validated will be then forwarded to partner clouds. But in the case of credit for processing information the Early-Response component determines the urgency of information. Urgent information include medical information of patients who are in emergency condition, physician’s request from operator to dispatch ambulance, physician’s urgent orders to patients, and operator’s request to identify the location of patient. In case of urgent information, software component forwards the data directly to required target, which might be the patint, physician or operator major component, and then proceeds to store data in the cloud and synchronize it with respect to data type. This procedure accelerates the system’s response to emergency conditions and thus improves its performance. Figure 26 shows the flow of Review emergency information. To achieve an efficient healthcare system, transmission of data to different data centers or clouds needs to be effectively managed. The proposed design includes several virtual machines with similar functions that all contain Analysis and Estimate-RT services. To improve the performance, among all available virtual machines in a data center, system must use the one that not only contains the Analysis service but also has the lowest response time. To achieve this end, the Estimate-RT service uses the previous response times to predict the future response
J Med Syst (2016) 40:270
Page 21 of 23 270
Fig. 27 Flow of selecting the virtual machine with suitable response time
times of every available virtual machine, and sends these estimations to the RT-VM service of the virtual machine that is dedicated to calculation of response times of data centers. The RT-VM service selects the VM with suitable response time. In case of absence of any virtual machine with suitable response time, service announces a warning message. The response then returns to Pathway-VM service, and this service sends a request to RT- OtherDC service, which in turn forwards the request to DC-Management service, which is responsible for management of data centers. This service reports the active data center and their response times to RT-OtherDC service, which then selects the data center with the suitable response time.
In case of failure to find any active data center with suitable response time, the RT-OtherDC service suggests the transmission of data to partner cloud servers. The response will be then sent to Pathway-VM service, where the transmitted data and data center or partner cloud will be validated. After validation, this service will forward the information. The details of this flow is shown in Fig. 27.
Conclusions and future work The aim of all healthcare systems is to enhance the quality of life, health, and safety of peoples and make their life easier and more comfortable. Recent decade has seen major breakthroughs
270
J Med Syst (2016) 40:270
Page 22 of 23
in remote health monitoring, but platforms and technologies related to this subject still need further development. This paper presented a general structure for a pervasive healthcare system and a system architecture focused on availability, interoperability, and performance, wherein components, their relationships and the necessary constraints are defined to contribute to easier implementation of these systems. This healthcare system uses a combination of wearable sensors, mobile devices of patients, physicians, and health monitoring operators in a cloud environment to monitor the health of patients safely and securely by sensors implanted in their body, and thereby facilitate the management of their medical conditions and allow earlier and quicker response to emergency situations. In addition to managing and monitoring the patients’ medical conditions, this system can contribute to assessment and improvement of ongoing treatments. The future works on this subject are suggested to model the system behavior by formal languages and then make necessary assessments on system deadlocks, divergence, and success in achieving targeted objectives. Other suggestion is to implement the system and then focus on a more specific topic like response times, security or other issues of the presented model.
11. 12. 13.
14.
15.
16.
17.
18. 19.
20.
21.
References 1. 2. 3.
4.
5.
6.
7. 8.
9.
10.
Goyal, J., Dadhich, A., Pervasive Computing. 4480(12):15–17, 2007. Satyanarayanan, M., Pervasive computing: Vision and challenges. IEEE Pers. Commun. 8(4):10–17, 2001. Vouyioukas, D., Maglogiannis, I., BCommunication Issues in Pervasive Healthcare Systems and Applications^, Pervasive and Smart Technologies for Healthcare: Ubiquitous Methodologies and Tools, ch010, 2010. Wilmini, N., BPervasive Computing and Healthcare^, Healthcare Delivery in the Information Age. Springer, New York, 2013. doi:10.1007/978-1-4614-4514-2_2. Singh, M., and Jain, N., A Survey on Integrated Wireless Healthcare Framework for Continuous Physiological Monitoring. Int. J. Comput. Appl. 86(13):37–41, 2014. Egbogah, E. E., and Fapojuwo, A. O., A Survey of System Architecture Requirements for Health Care-Based Wireless Sensor Networks. Sensors 11(5):4875–4898, 2011. Ghorbani, SH., Du, W., BPersonal Health Service Framework^, Procedia Computer Science 21, Elsevier B.V., 2013. Mandal, A. K., Sarkar, A., and Chaki, N., BFlexible Cloud Architecture for Healthcare Applications^, Intelligent Systems and Computing, vol. 304. Springer, India, 2015. doi:10.1007 /978-81-322-1985-9_8. Lupşe, O., Vida, M., M., Stoicu-Tivadar, L., BCloud Computing and Interoperability in Healthcare Information Systems^, INTELLI 2012 The First Int. Conf. Intell. Syst. Appl. Cloud Comput. Interoperability Heal. No. Figure 1, p. 81 to 85, 2012. Baig, M-M., and Gholamhosseini, H., Smart health monitoring systems: An Overview of Design and Modeling. J. Med. Syst. 37, no. 2, 2013.
22. 23.
24.
25. 26.
27.
28.
29.
30.
31.
Garlan, D., and Shaw, M., An Introduction to Software Architecture. Knowl. Creat. Diffus. Util. 1:1–40, 1994. Bass, L., Clements, P., Kazman, R., Software Architecture in Practice. vol. 2nd. 2003. Wu, H., Wang, Q., and Wolter, K., Mobile Healthcare Systems with Multi-cloud Offloading. Proc. - IEEE Int. Conf. Mob. Data Manag. 2:188–193, 2013. Koganti, K. T., Patnala, E., Narasingu, S. S., and Chaitanya, J. N., Virtualization Technology in Cloud Computing Environment. Int. J. Emerg. Technol. Adv. Eng. 3(3):771–773, 2013. Malhotra, L., Agarwal, D., and Jaiswal, A., BVirtualization in Cloud Computing^, Information Technology & Software Engineering, 2014. Int. J. Comput. Sci. Mob. Comput. 35(5):540–546, 2014. Shetty, R., and GS, TH, Design and Development of Mobile Phone Based Healthcare System for Emergency Situation. Int. J. Comput. Trends Technol. (IJCTT) 12(3):119–122, 2014. Malan, D., Thaddeus, F., J., Welsh, M., Moulton, S., BCode Blue: An Ad Hoc Sensor Network Infrastructure for Emergency Medical Care^, In Proceeding on the MobiSys 2004 Workshop on Applications of Mobile Embedded Systems, pp. 3–6, 2004. Mobihealth project’s web site: http://www.mobihealth.org/ Konstantas, D., Halteren, A., V., Bults, R., Wac, K., J., Val Widya, I., and Herzog, R., MOBIHEALTH: Ambulant Patient Monitoring Over PublicWireless Networks. Stud. Health Technol Inform 106: 107–122, 2004. Sachpazidis, I., B@HOME: telemedicine telemedicine system^, Mobile Computing in Medicine, Second Conference on Mobile Computing in Medicine, Workshop of the Project Group MoCoMed, GMDS-Fachbereich Medizinis Pervasive Systems in Health Care 345 che Informatik & GI-Fachausschuss 4, pp: 87–95, 2002. Kameas, A., Calemis, I., BPervasive Systems in Health Care^, Handbook of Ambient Intelligence and Smart Environment, DOI 10.1007/978-0-387-93808-0_12, 2010. TeleCARE project’s web site: http://www.uninova.pt/~telecare/ Camarinha-Matos, L., M., Afsarmanesh, H., BTeleCARE: Collaborative virtual elderly support communities^, Proceedings of the 1st Workshop on Tele-Care and Collaborative Virtual Communities in Elderly Care, TELECARE, Portugal, 13 April,, 2004. Camarinha-Matos, L., M., Castolo, O., Rosas, J., BA multi-agent based platform for virtual communities in elderly care^, ETFA2003, 9th IEEE International Conference on Emerging Technologies and Factory Automation Lisbon, Portugal, 16–19 September, 2003. MyHEART project’s web site: http://www.hitech-projects. com/euprojects/myheart/home.html. Habetha, J., and 117, The MyHeart Project: Fighting cardiovascular diseases by prevention and early diagnosis. Heal. 2008 Proc. First Int. Conf. Heal. Informatics 117:296–300, 2008. Amft, O., Habetha, J., BThe MyHeart project^, L. van Langenhove, editors, Book chapter in: Smart textiles for medicine and healthcare, pp. 275–297, Woodhead Publishing Ltd, Cambridge, England, February 2007. Poorejbari, S., Vahdat-Nejad, H., An Introduction to Cloud-Based Pervasive Healthcare Systems. Proc. 3rd Int. Conf. Context (ICCASA). Syst. Appl. 173–178, 2014. Doukas, C., Maglogiannis, I., BBringing IoT and cloud computing towards pervasive healthcare^, Proc. - 6th Int. Conf. Innov. Mob. Internet Serv. Ubiquitous Comput. IMIS 2012. Kafal, O., Bromuri, S., Sindlar, M., Weide, T., Aguilar Pelaez, E., Schaechtle, U., Alves, B., Zufferey, D., Rodriguez-Villegas, E., Ignaz Schumacher, M., and Stathis, K., COMMODITY: A smart e-health environment for diabetes management. J. Ambient Intell. Smart Environ. 0:1–25, 2013. Doukas, C., Maglogiannis, I., BManaging wearable sensor data through cloud computing^, in International Conference on Cloud Computing Technology and Science, Athens, 2011.
J Med Syst (2016) 40:270 32.
Jara, J., Zamora, M. A., and Skarmeta, A., F., G., An Internet of thingsbased personal device for diabetes therapy management in ambient assisted living (AAL). Pers. Ubiquit. Comput. 15(4):431–440, 2011. 33. Wan, J., Zou, C., Ullah, S., Lai, C., Zhou, M., and Wang, X., CloudEnabled wireless body area networks for pervasive healthcare. IEEE Netw. Mag. 27(5):56–61, 2013. 34. Ghorbani, S., Du, W., BPersonal Health Service Framework^, the 3rd International Conference on Current and Future Trends of Information and Communication Technologies in Healthcare (ICTH), DOI: 10.1016/j.procs.2013.09.045, 2013. 35. Moraes1, J., L., C., d., Souza1, W., L., d., Pires, L., F., Prado, A., F., d.,^ An Architecture for Health Information Exchange in Pervasive Healthcare Environment^, vol. 1, pp. 385–401.2014. 36. Rafe, V., Hajvali, M., BDesigning an Architectural Style for Pervasive Healthcare Systems^, J. Med. Syst., vol. 37, no. 2, 2013. 37. Zhou, F., Yang, H., Alamo, J. M. R., Wong, S., and Chang, C. K., Mobile Personal Health Care System for Patients with Diabetes. Aging Friendly Technol. Heal. Indep. 6159:94–101, 2010. 38. Pino, C., Salvo, R. D., A Survey of Cloud Computing Architecture and Applications in Health^, Proc. 2nd Int. Conf. Comput. Sci. Electron. Eng. (ICCSEE 2013), no. Iccsee, pp. 1649–1653, 2013. 39. Velte, A., T., Velte, T., J., Elsenpeter, R., Cloud Computing a Practical Approach. 40. KRUCHTEN, P. B., and Software, R., The 4 + 1 View Model of Architecture. IEEE Softw. 12(6):06, 2002.
Page 23 of 23 270 Kruchten, Ph., BArchitectural Blueprints-The B4 + 1^ View Model of Software Architecture^, IEEE Softw., vol. 12, no. November, pp. 42–50, 1995. 42. Basirati, M., R., Femmer, H., Eder, S., Fritzsche, M., Widera, A., BUnderstanding Changes in Use Cases: A Case Study^, 2015 I.E. 23rd Int. Requir. Eng. Conf., pp. 352–361, 2015. 43. Fowler, M., Kobryn, C., Booch, G., Jacobson, I., Rumbaugh, J., Uml Disitlled Third Edition.vol. 3nd, 2003. 44. Tanenboum, A., S., Steen, M., V., Distributed Systems Principles and Paradigms. 45. Lupşe, O., Vida, M., M., Stoicu-Tivadar, L.,^ Cloud Computing and Interoperability in Healthcare Information Systems^, The First International Conference on Intelligent Systems and Applications, 2012. 46. http://www.hl7.org/ 47. Spronk, R.,^ Transport Specification: MLLP, Release 1^, Edit or Minimal Lower Layer Protocol (MLLP). 2003:1–4. 48. https://www.ibm.com/cloud-computing/ 49. http://docs.aws.amazon.com/ 50. https://www.ibm.com/support/knowledgecenter/SSKM8N_7.0.0 /com.ibm.etools.mft.samples.healthcare.doc/doc/introduction.htm. 51. Mumbaikar, S., Padiya, P., Web Services Based On SOAP and REST Principles, Int. J. Sci. Res. Publ. 3(5): May 2013. 52. http://www.w3schools.com/xml/xml_xsl.asp. 41.
