=Paper=
{{Paper
|id=Vol-2753/paper33
|storemode=property
|title=A Study on Cloud Computing Architectures for Smart Healthcare Services
|pdfUrl=https://ceur-ws.org/Vol-2753/short12.pdf
|volume=Vol-2753
|authors=Dalia Rizk,Hoda Hosny,El-Sayed El-Horbaty,Abdel-Badeeh Salem
|dblpUrl=https://dblp.org/rec/conf/iddm/RizkHES20
}}
==A Study on Cloud Computing Architectures for Smart Healthcare Services==
https://ceur-ws.org/Vol-2753/short12.pdf
A Study on Cloud Computing Architectures for Smart
Healthcare Services
Dalia Rizka, Hoda Hosnya, El-Sayed El-Horbaty b and Abdel-Badeeh Salemb
a
The American University in Cairo, Cairo, Egypt
b
Ain Shams University, Cairo, Egypt
Abstract
Cloud computing in healthcare services is gaining a wide interest across the world due to
its affordable cost and enormous data storage capabilities. Smart healthcare is also
another growing area of interest to researchers and governments due to the increasing
development of new smart cities. However, there is no current standard practice to
format the cloud computing infrastructure. In order to assist the smart healthcare system
architect in designing a comprehensive solution for the basic services that are required by
the healthcare users. Architects need to take into consideration a balanced approach
towards their specific functional and non-functional needs such as openness, scalability,
concurrency, interoperability and security factors. The integration of smart healthcare
services based on cloud computing architecture is considered a new field of interest and
research. The main objective of this paper is to provide a brief analysis of the cloud
computing architectures in healthcare services.
Keywords 1
Cloud Computing, Reference Architecture, Smart Healthcare Services
1. Introduction
Healthcare services have been exponentially increasing worldwide [1] as there is a significant
volume of data generated on a daily basis by medical and clinical organizations [2]. This data is
important and vital for decision-making [3] and the lack of access to medical information may
negatively affect the delivery of the best care for patients [4]. Storing the records of patients
electronically [5] facilitates the exchange and availability of information for healthcare processes [6]
and hence increases the productivity of any patient care system that takes a central position and
provides easy accessibility and usage [5]. The introduction of the most recent technological
innovations in cloud computing for the healthcare sector [5] is becoming a pressing requirement in
order to optimize the resources in terms of computational and storage capabilities [2]. Cloud
computing is a cost-effective means for facilitating data collection, data storage and exchange
between healthcare communities [3].
Moreover, the enhancement of the Information and Communication Technology (ICT) enlightens
the ideology of Smart–Health Framework as suggested by Al-Azzam et al. [7] in their study which is
about combing mobile health (m-health) with smart cities. They presented the development of a
health lifecycle starting from the doctor’s visits to the patients with simple tools, moving on to the
electronic health (e-health) which requires the usage of databases and electronic health records (EHR)
to keep patients’ medical information. Al-Azzam et al. [7] then moved to the introduction of m-health
where patients can access their medical data and prescriptions from their mobile phones. They
emphasized the importance of smart health (s-health) in the sense of giving information to the patient
such as regarding different places accommodated with different types of pollution that patient has
allergy from and accordingly the patient can avoid these places. Finally, Al-Azzam et al. [7] explained
IDDM’2020: 3rd International Conference on Informatics & Data-Driven Medicine, November 19–21, 2020, Växjö, Sweden
EMAIL: drizk@aucegypt.edu; hhosny@aucegypt.edu; sayed.horbaty@yahoo.com; abmsalem@yahoo.com
©️ 2020 Copyright for this paper by its authors.
Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR Workshop Proceedings (CEUR-WS.org)
the last phase of health lifecycle which is the amalgamation of m-health with s-health by giving an
example about a cyclist who is wearing an accelerometer and accident monitoring capability band. If
he/she falls off the bicycle, a notification to the city smart system will be sent and accordingly traffic
lights will be adjusted to help the ambulance reach the cyclist through the shortest and fastest route
[7].
Reference Architectures offer a special type of software solution as they are reusable artifacts
designed by experts [8] to increase the software quality by developing, standardizing and evolving the
best practices in the software development process [9]. According to Khaled et al. [10], given the
dozens of challenges in any domain, generating this kind of architecture is considered one of the most
difficult tasks. Therefore, it is very important to have a unified and common architecture to pave the
road for quick and mature implementations.
Section 2 summarizes some of the related research work. Section 3 cites examples of different
reference architectures for healthcare. We discuss our survey findings and analyze them in Section 4.
Finally, the conclusion of the paper and the future work are discussed in Section 5.
2. Related Research Work
Garcés et al. [11], believed in the importance of Ambient Assisted Living (AAL) for the elderly
people as it provides them with approaches, products, facilities, and software systems required for
their daily lives. Hence, they introduced a reference architecture for Healthcare Supportive Home
(HSH) systems. Moreover, Gracés et al. [11], criticized the present HSH systems as they are of high
level of abstraction and accordingly characteristics, as interoperability, integrability, and usability are
not being addressed. They, also believed that these systems are expensive and need a lot of time and
resources.
According to Devata et al. [12] functional requirements are very important for the software
development projects. On the other hand, Non-Functional Requirements (NFRs) which sometimes are
regarded as a second-class requirement [12], and accordingly disregarded till the end of the
development cycle. NFRs which are considered expensive in some cases are gaining more attention
with cloud architectures because the concurrent load and response latency are weaker when using
public networks.
Devata et al. [12] included NFRs to their model, so that their software can be able to provide
usability of the current standards along with the functional requirements associated with the product.
Their non-functional requirements included performance, system operation, needed resources and
costs, verification, documentation, security, portability, and reliability. It is important to address the
NFRs at the design phase in addition to the functional requirements so that to avoid not using the
software product because it is not useful. Non-functional requirements can be very challenging to the
developers during the development cycle; accordingly, it is best to model and implement them on an
individual basis. NFRs are the ones that supply the rules when implementing the code [12].
The lists in Figure 1 and Figure 2 depict the most relevant functional and non-functional
requirements for the Healthcare Reference Architecture that we collected in our survey:
Functional capabilities provide a foundation for the analysis of the relations between infrastructural
drivers and architectural selection [13]. Moreover, functional requirements can be divided into two
main parts based on the executive, administrative, and managements at one side; and the doctors or
researchers who need to process, store, manage, analyze and diagnosis patient data at the other side
[2]. The following is a list of the most essential functional requirements for cloud computing
architecture for healthcare:
1. Access control of health data including privacy and security [13].
2. Health data integration with patient health records [13].
3. Interoperability and data exchange [13].
4. Data availability at the point-of-care, especially emergency [13].
5. Audit management [13].
6. Information sharing on demand for research or statistical purposes [13].
7. Accessibility of information (knowledge) / Help for medical, health and computer readability /
Health behavior management [13].
8. Secure communication [13].
9. Fault tolerance (Robust operation) [13].
10. Data management, storage, sustainability, backup and recovery [13].
11. System upgrade / maintenance [13].
12. Increased speed in IT operations management, configuration, reconfiguration of infrastructure,
applications and services [2].
13. Automation of simple repetitive health specific tasks, freeing those who manage the
infrastructure for small and continuous interventions [2].
14. The reduction of errors and resources problem, during the use of each specific health
applications [2].
15. Self-Service: the user (physician or nurse) must be able to request the services (bandwidth,
computing power, applications) on their own, without the intervention of infrastructure
managers [2].
16. Global Accessibility: the services must be accessible from multiple devices, from more places
and at all times ensuring privacy and encryption of sensible data [2].
17. Elasticity: the resources must be able to climb (upwards and downwards) quickly and, in some
cases, automatically [2].
Figure 1: Functional Requirements
Non-functional requirements are the criteria that need to be fulfilled by the system such as:
availability, reliability, performance and security [6]. The following list identifies the essential non-
functional requirements for PHR in details:
1. Availability: refers to how much the Information and Communication Technology (ICT)
system is accessible for the processes in the hospital. The higher the percentage value, the
higher the availability. Unscheduled system outage is the main factor that affects the
availability of ICT systems [6].
2. Security: privacy-sensitive information stored digitally in hospitals, require a powerful security
system in order to avoid improper use or breaches of this information. It is essential to pay a
great attention to both information security (need-to-know) as well as access control (need-to-
access) [6].
3. Performance: processes in the hospitals need different reaction speed of ICT systems in order to
be accomplished correctly. System performance determines the level of user satisfaction and
therefore all systems in a chain should conform to the required performance [6]. According to
[14], performance requirements could be furtherly sub-divided to:
a. Low power b. Small form factor
c. System reliability d. Quality of service
e. Higher efficiency f. Interoperate through different platforms
g. Ample connectivity h. Ambient intelligence
i. Ease of deployment
4. Scalability: it is the ability to change the scope of an ICT system, without affecting the
hardware nor software of that system [6]. According to [14], it is the upgrade of a system to a
higher version or technology.
5. Adaptability: the ICT infrastructure lifecycle should be long enough to meet the adaptability of
the requirements of ICT systems over a period of 10-15 years [6].
6. Maintainability: it is the importance of the creation of ICT facilities to be easily maintained,
whilst preserving the availability and reliability of the system [6].
7. Response time: which is one of the performance measures and can be expressed as the measure
of time where the system obtains during the processing of a received request. Accordingly, the
response time is the difference in time between sending and receiving a request. The calculation
is done by measuring the response time for each request per each user, then averaging the
whole response time for the whole system. According to the algorithm, the server rollbacks any
uncompleted work done as soon as the client timeout [12].
8. Concurrency: is a measure of the strength of an application. Requests are handled by the server
as a queue, then a thread is being assigned to work on the request. The latency is the difference
between the time before sending the request to the server and immediately after receiving the
response. The problem with concurrency occurs when the number of threads is less than the
number of requests to the server [12].
9. Response time requirement: is the time taken by the user to respond, but he/she does not. The
lock time needs to be checked continuously while the user is taking the correct amount of time
to perform the required task. Delay in the response time of the user should be reported by a
message informing that their lock time is released [12].
Figure 2: Non-Functional Requirements
3. Reference Architectures for Healthcare
Our literature survey in this area reveals that there are many reference architectures for healthcare
that have different points of view. There are also, many applications for healthcare based on cloud
computing. For example, Amanatullah et al. [15] proposed a new Cloud Computing reference
architecture based on combining both reference architectures of NIST and IBM as discussed earlier
while adding a new actor to the NIST’s actors list. This actor is the Cloud Developer which according
to their work [15], could be an individual or an organization for developing Cloud services to be
deployed on the Cloud provider’s system. Accordingly, this will help the Cloud consumer to use
services without paying for mounted hardware resources.
Sundaravadivel et al. [14] discussed the features of a smart healthcare architecture. They first
talked about the requirements of the architecture and divided it to functional requirements which
should be specific per component, and non-functional requirements that include performance
requirements and ethical requirements. The components of the smart healthcare architecture from
Sundaravadivel’s et al. [14] point of view are sensors or actuators, computing devices, data storage,
and networking components. The three categories for classifying the characteristics of smart
healthcare are: App-oriented, Things-oriented, or Semantics-oriented. Sundaravadivel et al. [14]
secondly discussed the configuration, the organization and the framework of the smart healthcare
network where the appropriate connection of physical elements is the main interest for the
configuration part. While the organization means the interoperability of the architecture across
different technologies. The framework for the smart healthcare architecture means the libraries and
environments being used. Finally, Sundaravadivel et al. [14] talked about the importance of services
and applications that could be used with the smart healthcare architecture for example the context-
aware services that can provide the users with additional information based on their wearable devices.
On the other hand, Pino et al. [2] carried out a survey about existing solutions of the Cloud usage
of different aspects in health. The following table is a summary of the actual health needs from Pino’s
et al. [2] point of view versus the existing solutions that they found in their survey:
Table 1
Actual Health Needs vs Existing Solutions [2]
Health Needs Existing solutions
Medical Images 1. A prototype of Image archive based on Cloud and includes a Digital
archive solutions in the Imaging and Communications in Medicine (DICOM) server.
Cloud 2. A system called MIFAS (Medical Image File Accessing System) for
Medical Images processing across different hospitals.
3. A PACS cloud Gateway to access PACS Cloud archive.
4. A study about the security of data storage and sharing through
Cloud.
Data management in 1. A proposed automated solution to utilize computing with wireless
Health care institutions sensor networks to be available on the Cloud.
using Cloud Computing 2. An E-Healthcare model that includes Wireless Sensor Networks for
solutions management issues using the Cloud Services Architecture (CSA).
Health Support 1. A Cloud-based service-oriented architecture (SOA) for electronic
System emergency patient record system (E-EPR).
2. A proposed Patient Health Records (PHR) based on Emergency
Medical System (EMS) using Cloud Computing.
3. A telemedicine-oriented Emergency Health Support System (EHSS)
that provides healthcare services being deployed on the Cloud.
Specific Application 1. Information retrieval (Medical Image retrieval, Clinical Data
retrieval).
2. Data processing (bioinformatics applications, data mining, etc.).
3. Patient monitoring.
4. Cloud Resource Broker.
In the following section we discuss 3 different reference architectures for healthcare in details.
3.1. The Reference Architecture for Healthcare
Sultanow et al. [16], proposed a digitalization reference architecture (RA) for all participants of the
healthcare system where digitalization is considered to be an essential value enabler in different
disciplines. It shows the existence of digital solutions and their relation to different actors’ capabilities
where it covers the overall healthcare from two perspectives: the business and the information
technology (IT). The presented reference architecture by Sultanow et al. [16] consists of three main
components: therapeutic segments, pharma-specific functions, and generic functions. The authors’
[16] incentive for their reference architecture is to collect all subdomains – of pharma, healthcare, and
life sciences – along with their relationships and their business capabilities including the software
applications and technologies required for these capabilities. They carried out a survey for different
architectural solutions to find the variety of standards for the combined domain of pharma, healthcare,
and life sciences. The authors [16] examined nine architectural solutions and found out that while
most of the RAs are built upon common standards, yet these standards are non-interoperable due to
the loyalty of the RAs to the organizations adopting them and therefore, they are not vendor neutral.
The logic of the proposed RA by Sultanow et al. [16] is divided into therapeutic segments – which
is further divided into the disease areas and their corresponding drug solutions – and an internal
structure which is divided into a pharma-specific domain and a general domain. According to
Sultanow et al. [16], the therapeutic segments are responsible for the classification of values. The
pharma-specific domain is for the functions that are industry specific while the general domain is for
the functions that are similar across industries.
Their RA describes the related capabilities (Track and Trace), data (location, temperature / cold
chain characteristics, shock, etc.), applications (XQS, Gemalto, etc.), and technologies (RFID, Data
matrix, various sensors, GPS systems, etc.) [16]. From a cross-functional perspective, the Distribution
process provides relevant insights for other functions, such as Regulatory Affairs and identifies the
relevant point of actions, such as Good Distribution Practices (GDP). Furthermore, relevant data can
be evaluated retrospectively and analyses can be conducted by various patient segments. This might
create valuable insights for targeting activities in the Life Science Research function to specific
patient problems. Therefore, their RA [16] is capable of describing concrete, end-to-end digital
technology solutions that are relevant for various actors in the healthcare system. Each actor can set
up priorities and requirements with regard to digital technologies, and use the RA to develop a
customized solution for their situation. From an organizational point of view, the vertical slices
represent a static description of elements that organizations require for value creation. It is the
definition of vertical slices in their RA that is helping to capture different industry perspectives.
According to the authors [16], there are three limitations to their proposed RA which are:
1. They are providing representative solutions only.
2. They did not present the interfaces among applications.
3. They did not give details about the processes in the RA.
Although Sultanow et al. [16] clearly stated their limitations and gave reasons for each one, yet the
paper lacked an important factor that they did not discuss nor mention as a limitation. They did not
validate nor verify their RA and accordingly they missed a significant phase in the process that they
defined.
3.2. The Business Architecture Model for Healthcare
This section describes the second Reference Architecture for healthcare, but from another point of
view which is the Business aspect. The research relates healthcare to Life Science as a whole.
In [17] Boyd e. al. defined the Business Architecture Models (BAMs) as follows: “describe what a
business does, who performs the activities, where and when activities are performed, how activities
are accomplished and which data are present [17].” Boyd et al. [17] believed that the importance of a
BAM is to have the main resource for understanding business functions and requirements in order to
lead the software development. Furthermore, the authors [17] borrowed the definition of Business
Architecture from the BASIG which is “a blueprint of the enterprise that provides a common
understating of the organization and is used to align strategic objectives and tactical demands [18].”
Boyd et al. [17] considered the business models to “(i) identify gaps, dependencies or redundancies in
personnel, procedures and software; (ii) standardize how enterprises operate and train people who
lack domain expertise; (iii) define business rules and logic; and (iv) prioritize business goals and
match business priorities with information technology solutions.”
They [17] further defined the platform-independent interoperability as “software communication
independent of operating system and computer language,” and that its importance lies in generating a
network of collaborative information to help in data exchange without the knowledge of who
collected the information or how they are saved.
Moreover, the research group of the cancer Biomedical Informatics Grid (caBIG) [17] has
developed the Life Science Business Architecture Model (LS BAM) documents which consist of the
people, organizations, goals and processes. These documents are represented as use cases and actors.
The definition of use cases according to Boyd et al. [17] are “textual descriptions of tasks that are
performed to achieve specific goals”, while actors are “the entities that carry out or are otherwise
associated with the goals defined in the use cases”. The LS BAM represents the use cases and their
relation with the actors in a Use Case Diagram and Activity Diagrams. Boyd el al. [17] believe that
the LS BAM they executed consists of all common goals of the LS research that can be helpful for
different disciplines of software development, validation and training. They were able to develop 90
use cases and 61 actors for their LS BAM. The major goals’ use cases were:
1. Plan Research
2. Perform Research
3. Analyze & Synthesize Results
4. Disseminate Results & Artifacts
These 4 main use cases have many other descending use cases that are more specifically related to
the caBIG. Boyd et al. [17] added a supporting use case which was “Establish Permissions” that was
organization oriented. The LS BAM contains 61 actors who are categorized as: Organizations, People
and Systems. Furthermore, Boyd et al. [17] presented in their LS BAM documents the Activity
Diagrams which graphically represent the chronological and logical arrangement of goals conducted
by certain actors.
The LS BAM [17] was validated and verified by implementing it at:
1. The cancer Laboratory Information Management System (caLIMSv2) used the LSBAM to
help in designing their interoperable laboratory information management system (LIMS).
2. Another usage of the LS BAM is to evaluate the National Cancer Institute (NCI) Enterprise
Services (NES) which offers software services for any LS application to facilitate
interoperability.
3.3. Targeted Healthcare Architecture
Our last studied architecture for healthcare system is the one introduced by Ouradi et al. [19] to
implement all the data associated with the ministry of health of Morocco where they wanted to benefit
from the advantage of cloud computing such as cost and flexibility, without trading off information
security. Of course, the medical field has an exponential number of information that has a high
stockpiling and documenting capacity, which leads to slowness in the preparation of the patient's data
and can sometimes return incorrect outcomes. Accordingly, Ouradi et al. [19] proposed an
architecture which is based on the utilization of a cloud broker open source in an inter-Cloud setting.
This will decrease the access time required by the client to achieve a service, the dispersal of energy,
and the number of installed datacenters. They used CompatibleOne for their architecture which is an
“Energy Efficient Open Source Cloud Broker”. They built up a java module named “DMS” that is
liable for presenting the various services with the best Quality of Service (QoS) to the client. The
main task of this module is to search for the appropriate service with the ideal settings from the
providers. They integrated this module at the PaaS4Dev level of the CompatibleOne. Further on, they
used the CloudSim which is an open source simulator for modelling and simulation of a cloud-based
Datacenter environment. They used it to operate the instantiation and execution of the basic entities.
Moreover, Ouradi et al. [19] developed java classes to demonstrate the cloud broker of the datacenter
architecture and assigned the datacenters to support the transfer of VM. Then they chose two methods
for transfer; the first is: first come first serve, and the second is: controlled by the cloud Broker
through registering the state and characteristics of each data center. They also, tracked the power
consumption in the datacenters and found that the CPU is the most energy consumer. Finally, they
developed an algorithm to test their solution which is the usage of federation of clouds. Their posted
results showed that using the algorithm of federation helps in the reduction of execution time along
with reduction in energy consumption which leads to a net gain in cost.
4. Discussion
From the above analysis, we arrived at the following observations:
Sundaravadivel et al. [14], mentioned that “functional requirements are specific to each
component used in that healthcare system based on their application.” This idea was
supported practically by Sultanow et al. [16] where they specified the functional requirements
for their pharma-specific domain into: 1-Life-Sciences Research, 2-Regulatory Affairs, 3-
Production, 4-Distribution, and 5-Application/Treatment.
Furthermore, Boyd et al. [17] emphasized the importance of the Business Architecture
Model as the main source for understanding both the business functions and requirements of
a product. This idea was also reinforced by the implementation conducted by Khaled et al.
[10] where in order to have a complete computing reference architecture, they first built their
business reference architecture before moving to their technical reference architecture. Their
business architecture consisted of eleven quality features and three business domains. Their
eleven quality features were also considered as non-functional requirements by the ATOS
project [6] which are: 1-Adaptive behavior, 2-Context sensitivity, 3-Experience capture, 4-
Fault tolerance, 5-Heterogeneity of devices, 6-Invisibility, 7-Privacy and trust, 8-Quality of
service, 9-Safety, 10-Security, and 11-Service omnipresence.
Both Pino et al. [2] and Ouradi et al. [19], gave examples about running health
applications on the cloud. Pino et al. [2] cloud applications were the output of a survey that
they conducted based on their point of view of which health needs are important to the health
care organizations. Therefore, they surveyed many applications for each health requirement.
On the other hand, Ouradi et al. [19] presented only one complete application based on the
cloud. Their architecture was specific to the Morocco Health Ministry.
Table 2
Features and gaps to be addressed for each studied architecture
Architecture Features Gap to be addressed
Solution
Amanatullah They presented the requirements of The proposed requirements were not
et al. [15] the Cloud service management field specific. In other words, they didn’t
which is helpful to Cloud providers verify if the proposed requirements
for accomplishing their business suites the health sector or not.
aims.
Gracés et al. They conducted a reference The reference architecture needs to be
[11] architecture model for AAL along based on the Cloud in order to coop with
with a quality model specifically for the up-to-date technology.
the HSH.
Sundaravadivel This was a huge survey about smart How security issues can be handled at
et al. [14] healthcare services along with its either side of the customer or the
positive and negative point of view. software side.
Sultanow et al. They offered a reference They missed the verification and
[16] architecture of digital solutions for validation step for their reference
every concerned person in the architecture along with some limitations
healthcare system. they mentioned.
Boyd et al. [17] They presented a business This business architecture needs to be
architecture model that contains the addressed from a Cloud Computing point
business functions and of view
requirements. They also validated
their architecture
Ouradi et al. They developed a module to be The architecture needed to be verified
[19] included at the Broker level of the that it suites different countries not only
Cloud structure for choosing the for the Morocco health ministry.
optimal services.
Al-Azzam et al. It is how to mingle mobile health The same concept was proposed earlier
[7] with smart cities to get a smart in 2014 by Solanas et al [20].
health framework.
5. Conclusion and Future Work
To date and based on the reported efforts in the Related Research Work Section, it is noticeable
that reference architectures that have been studied used tailored components and features based on the
requirements for each sectors’ point of view. There is currently no concrete methodology that can
guide software architects as they attempt to develop sound architectures for the smart healthcare
services in cloud computing that cater for the user’s specific requirements. Moreover, this survey
showed that there is no standard reference architecture for healthcare that covers the most essential
and basic components. The survey is a preliminary step towards our current research work whose aim
is to create a cloud computing reference architecture for smart healthcare services that captures the
best practices and that introduces innovative features to suit the target users. The ultimate goal of this
research is to provide the medical community with the accurate and timely information about the
patients in order to take the right decision at the right time. This research acknowledges the
importance of time and security for critical cases and hence, the data offered to physicians should also
satisfy the main non-functional requirements of accuracy, punctuality, and confidentiality.
6. References
[1] N. Chondamrongkul and P. Chondamrongkul, “Secure Mobile Cloud Architecture for Healthcare
Application,” International Journal of Future Computer and Communication, vol. 6, no. 3, 2017.
[2] C. Pino and R. Di Salvo, “A Survey of Cloud Computing Architecture and Applications in
Health,” Proceedings of the 2nd International Conference on Computer Science and Electronics
Engineering (ICCSEE), 2013.
[3] H. Aziz and A. Guled, “Cloud Computing and Healthcare Services,” Journal of Biosensors &
Bioelectronics, vol. 7, issue 3, 2016.
[4] M. Kyazze, J. Wesson, and K. Naude, “The Design and Implementation of a Ubiquitous Personal
Health Record System for South Africa,” Global telehealth, 2014.
[5] G. Reddy and G. Reddy, “Study of Cloud Computing in HealthCare Industry,” International
Journal of Scientific & Engineering Research, vol. 4, issue 9, 2013.
[6] “IT Reference Architecture for Healthcare,” ATOS, 2011. [Online]. Available:
https://atos.net/wp-content/uploads/2016/06/atos-itah-architecture-for-healthcare-whitepaper.pdf
[7] M. Al-Azzam, and M. Alazzam, “Smart City and Smart–Health Framework, Challenges and
Opportunities,” International Journal of Advanced Computer Science and Applications, vol. 10,
no. 2, pp. 171–176, 2019.
[8] L. Garcés, A. Ampatzoglou, P. Avgeriou, and E. Nakagawa, “A Comparative Analysis of
Reference Architectures for Healthcare in the Ambient Assisted Living Domain,” 2015 IEEE
28th International Symposium on Computer-Based Medical Systems, Sao Carlos, pp. 270–275,
2015.
[9] J. Santos, M. Guessi, M. Galster, D. Feitosa, and E. Nakagawa, “A Checklist for Evaluation of
Reference Architectures for Embedded Systems,” SEKE, Boston, USA, pp. 1–4, 2013.
[10] O. Khaled, H. Hosny, and M. Shalan, “Towards A Futuristic Pervasive Computing Reference
Architecture: The Vision and Approach”, Fourth International Japan-Egypt Conference on
Electronics, Communications and Computers (JEC-ECC), IEEE, pp.121–122, 2016.
[11] L.Gracés, A.Ampatzoglou, P.Avgeriou, E. Nakagawa, “A Reference Architecture for Healthcare
Supportive Home Systems,” 2015 IEEE 28th International Symposium on Computer-Based
Medical Systems, Sao Carlos, pp. 358–359, 2015.
[12] S. Devata, and A. Olmsted, “Modeling Non-Functional Requirements in Cloud Hosted
Application Software Engineering,” Cloud Computing 2016: The Seventh International
Conference on Cloud Computing, GRIDs, and Virtualization, pp. 47–50, 2016.
[13] R. Steele, K. Min, and A. Lo, “Personal Health Record Architectures: Technology Infrastructure
Implications and Dependencies,” Journal of the American Society for Information Science and
Technology, 63(6):1079–1091, 2012.
[14] P. Sundaravadivel, E. Kougianos, S. Mohanty, and M. Ganapathiraju, “Everything You Wanted
to Know about Smart Health Care: Evaluating the Different Technologies and Components of
the Internet of Things for Better Health,” IEEE Consumer Electronics Magazine, vol. 7, no. 1,
pp. 18–28, 2018.
[15] Y. Amanatullah, C. Lim, H. Ipung, and A. Juliandri, “Toward Cloud Computing Reference
Architecture: Cloud Service Management Perspective”, ICT for Smart Society (ICTSS) 2013
International Conference, IEEE, pp. 1–4, June 2013.
[16] E. Sultanow, A. Chircu, K. Schroeder, and S. Kern,“A Reference Architecture for Pharma,
Healthcare & Life Sciences,” Workshops der Informatik 2018 – Architekturen, Prozesse,
Sicherheit und Nachhaltigkeit, Berlin, Deutschland, September 2018.
[17] L. Boyd, S. Hunicke-Smith, G. Stafford, E. Freund, M. Ehlman, U. Chandran, R. Dennis, A.
Fernandez, S. Goldstein, D. Steffen, B. Tycko, and J. Klemm, “ThecaBIG® Life Science
Business Architecture Model,” Bioinformatics, vol. 27, no. 10, pp. 1429–1435, 2011.
[18] Object Management Group (2010) The Business Architecture Group (BASIG). Object
Management Group, Needham, MA, USA.
[19] A. Ouardi, A. Sekkaki, and D. Mammass, “Towards an inter-Cloud Architecture in Healthcare
System,” International Symposium on Networks, Computers and Communications (ISNCC),
2017.
[20] A. Solanas, et. al. “Smart health: A context-aware health paradigm within smart cities,” IEEE
Communications Magazine, vol. 52, no. 8, pp. 74-81, 2014.