Chapter 3 Methodology

3.0 Introduction
This section gives an exhaustive portrayal of the exploration reasoning, research approach,
research technique, information assortment strategies and instruments, pre-testing
methodology and information examination, moral contemplations, restrictions and the work
plan.
3.1 Research Design
A research design is an overall framework identified by the researcher to merge the
different study components coherently and logically (Debor, 2018), hence, ensuring the
study problem is solved. It is also known as the blueprint for the collection, interpretation,
analysis, and discussion of data (Leavy, 2017). This study will adopt Saunders et al. (2019)
research Onion as the overall framework for the development of the research design
Saunders Research Onion is a layered approach that illustrates the different stages involved
in
the development of a research methodology (Saunders et al., 2019). While using the
research
onion, one must go from the outermost layers i.e., Research Philosophy, Research
Approaches,
Research Strategies, time horizons and lastly to the innermost layer which is Data Collection
Methods
3.2 Research Philosophy.
Twala and Kekwaletswe (2019) define a research philosophy as a bunch of convictions
concerning the peculiarities or the idea of the truth that is being investigated, and how
information about that specific peculiarity ought to be gathered, broken down and utilized.
Research Philosophy is generally examined as far as metaphysics and epistemology where
cosmology alludes to the credibility of the data and how one comprehends its presence and
epistemology alludes to the legitimacy of data expected for the examination and how one
can get it (Mosweu and Mosweu, 2020). Sounders research Onion recommends a few ways
of thinking that are mostly arranged into two broad paradigms namely; positivism and
constructionism. (Monette et al., 2014). These paradigms are sometimes described as
empiricism and interpretivism but the underlying assumptions are broadly similar (Bryman
2012). Manian, Jamporazmey and Sherkat, (2014) define positivism as the approaches that
apply scientific methods to human and social affairs. Based on Francis Bacon’s second way
of discovering the truth, positivism involves approaches that apply scientific methods to
human and social affairs which are conceived as belonging to a natural order that is open to
objective enquiry (Davoudi, 2012).
Interpretivism alludes to a humanistic methodology that accentuates the need to
comprehend or decipher the convictions, intentions, and reasons of social entertainers
(people) to get social reality (Scauso, 2020). The Interpretivism theory underscores the
utilization of subjective investigation over the quantitative examination to acquire the ideal
outcomes (Ryan, 2018)
The study will adopt the interpretivism paradigm because it enables understanding how
people perceive the world (individual or group) and the meanings and values that people
assign to a particular phenomenon (Briony 2006). Talk about the eHealth security and
privacy challenges for LMIC health facilities. These views will be used as inputs to the
development of an Information Security Governance Model for health facilities in LMICs

3.3 Research Approach

This research can be categorized as applied science: a discipline of science that applies
existing scientific knowledge to develop more (knowledge and) practical applications, such
as technology and inventions. Technology is of course supported by scientific knowledge,
but also “other organized knowledge to practical tasks by social systems involving people
and machines” (Cross, Naughton, & Walker,1981). For this reason, the engineering
Design Method (Ellwood Dieter, & Schmidt. (2013) (or Design Science (Monson, 2021))
was adopted as predominant research strategy, as an alternative approach to the Scientific
Method (Cross, Naughton, & Walker,1981). In short, the Design Method comprises eight
main steps, that cyclically iterate from one to another every time assumptions should be
redefined.

The Design Method starts with the problem definition, basically questioning: [Who] need(s)
[what] because [why]?. What is the problem? Who has the problem? Why is it important to
solve? So, rather than scientific curiosity, the design is actually driven by needs of society
(Monson, 2021). The second step is the background research, i.e., the state-of-the-art that
includes scientific knowledge, but it also includes devices, components, market and
economic conditions (Monson, 2021). These steps correspond to the problem
characterization and observations in the scientific method. After understanding the problem
and existing solutions, the third step is to specify requirements, i.e., the characteristics that
your solution should meet. Requirement’s specification is based on what is known from
other existing solutions, as well as by consulting users that need it. Again, this step would
correspond to the formulation of a hypothesis, or proposing an explanation. The fourth step
is to propose a solution. Researchers should brainstorm solutions within their group and
choose the one that better satisfies the project goals, meeting all (or most) requirements.
The fifth step, the solution is then further detailed and modeled, by means of modeling
languages, drawings, and so forth. This need of a model is important to predict the behavior
of the solution before prototyping (Monson, 2021). Similarly, the scientific method needs to
define the experiment and its procedures. Once researchers have a clear idea of what to do,
they start the sixth step, to build a prototype. In the scientific method this is the test of the
hypothesis by experimentation. The seventh step is the test and redesign of the prototype
by multiple iterations. Similar to the evaluation and improvement steps in the scientific
method. And at last, in both methods, researchers should communicate results, through
technical reports, publications and documentation.

A structured review of the literature was done to identify success factors that influence the
adoption of eHealth standards/technology. At the start of the study, we consulted seven
eHealth stakeholders drawn from the Ministry of Health, Ministry of ICT, Uganda Bureau of
standards, four top health system levels in Uganda. The decision was influenced by the
research field, that these stakeholders represent the views of problem owners and
therefore helped identify pertinent issues to the success of eHealth in Uganda. The
stakeholders helped conceptualise the context of success in the adoption of eHealth
standards. They refined the objectives to focus the study proper preparation mapping,
adoption process, and standards adoption outcomes.

Search strategy: To perform a full search, articles for this review were gathered from
PubMed and Google scholar. The choice of PubMed and Google scholar is based on the
argument that one, they provide free access allowing researchers to retrieve full papers of
all relevant publications. Two, almost all (very percentage) health informatics publications
are indexed in PubMed. Since 91% of all PubMed content is indexed in MEDLINE the
database of all medical publications and a study by [36], reveal that a combination involving
MEDLINE and Google scholar can achieve a recall of not less than 98.3%. Therefore, the
study believes that these two databases are suitable to retrieve relevant literature regards
factors that influence potential eHealth standards adoption. The search strategy included
three categories of keywords: (i) “adoption” OR “adoption success”; (ii) “electronic health”
OR “e-health”; and (iii) “standard” OR “technology” OR “innovation”. Synonyms of the
keywords were used to perform an exhaustive search of relevant literature.

3.3.1 Study Selection and Data Extraction: An article was included if it satisfied the inclusion
criteria: (1) peer-reviewed publication in English; (2) has a full-text status; and (3) discusses
success factors or enables of technology/standard adoption and or implementation in
health. Evaluation of the success factors is not a requirement for inclusion. After removing
duplicates, the studies were screened for inclusion/exclusion, and only nineteen peer-
reviewed publications remained to be used in the extraction of information that was used in
the analysis.

The following information was extracted into a spreadsheet: first author surname and year
of publication, type of study, type of study country, theory/model/standard, constructs of
the theory/components that guided the study, success factors that inform/influence
successful adoption/contextualization of standard, and for the standards: where they have
been implemented, and results of success (if evaluated). Analysis qualitatively explored the
concept of eHealth standards adoption success and success factors of eHealth standards
adoption.

3.3.2 Model of Innovation Adoption.

A summary of the constructs and pre-conditions to successful adoption of eHealth artefacts

is presented in Table 1. Various applications of technology adoption theories to assess
success have used organizational, human, technological diffusion/infusion constructs.
 Besides, these studies recommend readiness assessment, adoption process, organizational
and user acceptance and use as conditions to successful adoption of eHealth artefacts.

Table 1: Constructs for Assessing Successful Adoption of eHealth Artefacts

Constructs of the theory that inform Success Pre-conditions for Successful

successful adoption of eHealth artefacts Requirements Technology/standards adoption

Organizational, facility or community Diffusion and Readiness assessment focusing on health

dimension [2], [3], [7], [21], [28]–[30], [37] Infusion [23], [24], system as organisation, availability of the
[28], [35], [38] resources, willingness of healthcare providers
Human/User dimension [2], [21], [26], [37]
and users [3], [6], [20]
Technological context [21], [26], [29], [30],
Adoption environment and or adoption
[37]
process [24], [33]

Characteristics of the technology/standard

[33]

Organisations’ acceptance [2]

User acceptance and use [26]

The author used identified constructs to study the adoption of eHealth artefacts in the ratio
of 47%, 24%, and 29% of the time organizational, human dimension and technological
respectively. To attain full benefits of the eHealth artefact, then the technology, innovation,
or standard must diffuse and infuse into the healthcare work practices of the health system.
Besides studies have explored various pre-existing conditions that influence the success of
technology/standards adoption. The identified constructs were used to develop the model
in the Figure that can be used to assess the potential success of eHealth standards adoption.

Standards adoption success or worthiness can be determined by assessing the standards

adoption process and outcomes. The adoption process starts with a proper assessment of
the readiness of a health system to adopt standards for eHealth (the pre-adoption phase)
followed by actual adoption processes. Comprehensive assessment of standards adoption
success can be measured, One, by assessing readiness to adopt standards. Two, the
adoption phase where the success of adoption and use of innovation by most, or all, of the
adopting units (success of adoption) is evaluated. Three, the post-adoption phase where the
potentially lasting effects/benefits of innovation by the adopting units (success from
adoption) are measured.

3.4 General methodology for the implementation of e-health services in developing

countries
With respect to the foregoing consideration of factors leading to e-health project
success or failure, we may now discuss a general management approach. This
methodology is based on classical project management methods. These include project
lifetime and life cycle, feasibility study and implementation planning. The corresponding
instruments include risk management, total quality management, cost-effectiveness
studies and related assessments.

More often than not e-health projects have to be integrated within existing healthcare
processes and systems over which they have no direct mandate. There may be other e-
health projects planned or already under way. Furthermore, such projects comprise so
many variables those general solutions are not directly applicable and have to be
tailored to each case.

3.5 General Issues of mHealth and eHealth Security & Privacy

Essentially, mHealth and eHealth inherits problems from mobile computing and wireless
networks. The communication channels are more vulnerable due to their wireless
characteristics (e.g., network eavesdropping and spoofing) and mobile devices have more
constrained amount of processing power and memory (i.e., need for lightweight
cryptography). Devices can be shared among users, and they are more vulnerable to theft,
loss and damage, which may result in data breaches, data loss, and privacy infringements.
Regarding general issues linked to mHealth and eHealth security and privacy, some
interesting publications can be discussed. From a more technical perspective, in [38] the
authors proposed a number of security and privacy recommendations for mHealth and
eHealth developers. These recommendations were made based on a preliminary survey of
169 papers, resulting in the nine general recommendations listed below:

• Access control – Use of patient-centered access control mechanisms (e.g., role-based

access control), in which users should be able to allow or deny access to their information at
any moment.

• Authentication – Users should be able to authenticate with a unique ID and password (or
multi-factor authentication). Passwords should be kept in secrecy and should reach
appropriate levels of security.

• Security and confidentiality – Use of encryption mechanisms (e.g., AES) with proper
parameter configurations (i.e., key size).

• Integrity – Use of message authentication codes and digital signatures.

• Inform patients – Present privacy policy to users before collection of data that informs
about the user rights and specifies the purposes of data collection and processing.

• Data transfer – Use secure communication channels (e.g., TLS, VPNs) while transferring
data among entities. Notify user about data transfers.
• Data retention – Inform users about retention policy. The data should be kept only for the
necessary time to accomplish the initial purpose. User should be able to check when data is
deleted.

• Body Area Network communication – Use security mechanisms for authentication and key
distribution among sensors and smart-phones; establish secure communication channels
among devices.

• Breach notification – In case of data breaches, the competent authorities and users should
be notified. Entities should help users in order to relieve the consequences and restore
possible damages.

Overall, the recommendations help developers to have a glimpse about privacy and security
issues in mHealth and eHealth. However, they are incomplete if compared to existing
legislations on privacy and data protection, and thus, have limited practical use. In the case
of European Union (EU), the General Data Protection Regulation (GDPR) (EU Commission,
2015) is the upcoming regulation for personal data privacy and protection, replacing the EU
Data Protection Directive 95/46/EC (European Union, 2018)

Many countries (i.e., separate legal jurisdictions) however do not have specific legislation for
data privacy (Graham Greenleaf, 2012). This does not imply a legal void in the area, but
privacy rights might stem from the constitution or consumer rights; and in the case of
healthcare, from medical codes of conduct, and so on. Thus, from the legal perspective,
some publications help to bridge this gap between privacy and mHealth and eHealth
technologies. For example, (Hibah Hussain,2013) presents a list of five guiding principles
for mobile privacy in the context of developing countries ( that map to principles of the
GDPR):

Principle 1

Address Surveillance Risks – Projects should take steps to ensure that user data is secure
from third party surveillance, e.g., user discriminatory profiling can be made by mobile
operators and government.

Principle 2

Limit Data Collection and Use – Projects should limit data collection to what is absolutely
necessary for the project’s goal, e.g., by employing access control, data retention policy, and
not collect unnecessary data.

Principle 3

Promote and Facilitate Transparency – Projects should be transparent about what data is
collected, how it is shared, and how it might be used in the future, e.g., user notifications,
data transfer policies, audit trails of others that also have access to the data.

Principle 4
Incorporate User Feedback – Projects should give users the ability to access, amend, and/or
delete their data, e.g., create user interfaces, create communication channels to receive
feedback from users.

Principle 5

Assume Responsibility – Projects should assume accountability for potential risks and harms
incurred via their projects and platforms, e.g., perform risk assessment, plan incident
response, notify data breaches. The content of the recommendations (Martínez-Pérez, De
la Torre-Díez, & López-Coronado, 2014) and the guiding principles (Hibah Hussain,
2013) offer a good starting point for developers and project leaders. However, in practice,
security and privacy analysis should be done case-by-case, given the complexity, multiplicity
of actors, jurisdictions, and highly culture-specific dimensions of privacy (Thomson Reuters
Foundation,2013).

3.5.1 Security Mechanisms for mHealth and eHealth

Here we review some fundamental cryptographic mechanisms and protocols used in the
research, specifically for MDCSs. In brief, a Key Management Mechanism (KMM) is used to
provide Authentication and Key Exchange (AKE) between parties (user’s mobile and
application server). Authentication protocols and key derivation schemes for MDCSs usually
rely on symmetric cryptography, using password authentication. These protocols should
also give support for online and offline user authentication. Other mechanisms should cope
with confidentiality of stored and in-transit data, by means of encryption schemes for
secure storage and transmission. As a result, the security background herein presented
forms the building blocks of our solutions.

Authentication and Key Derivation

Authentication of users remains a challenging and crucial element in modern computer

security. Even though authentication mechanisms can be based on a combination of factors
– i.e., biometrics (“what the user is”), security tokens (“what the user has”), or passwords
(“what the user knows”) – the most widespread strategy still lies in secret passwords
(Pointcheval, & Zimmer, 2008). This happens because password-based authentication is
the most well-known, simple, cost effective and efficient method of maintaining a shared
secret between a human being and a computer system. Furthermore, the advantages of
using passwords tend to out shadow the disadvantages, i.e., problems of choosing strong
but easy-to remember passwords. Thus, it is likely that we will see passwords being used for
quite some time into the future (Schneider, 2013); by itself or as part of multi-factor
authentication schemes. Password-based systems normally employ Key Derivation
Functions (KDFs), cryptographic algorithms that allow the generation of a pseudo-random
string of bits from the password itself (Schneier, 2015).

Typically, the output of a KDF is employed in one of two manners: it can be locally stored in
the form of a token for future verifications of the password or it can be used as the secret
key for data encryption and/or authentication. Whichever the case, such solutions internally
employ a one-way function (e.g., hash), so that recovering the password from the KDF’s
output turns out to be computationally infeasible (Fujioka, et al.,2014). Nonetheless,
attackers can still use dictionary attacks (Schneier, 2015) and test many different passwords
combinations until a match is found (i.e., brute force). KDFs usually rely on two basic
strategies for preventing such brute force attacks. The first is to purposely raise the cost of
every password guess in terms of computational resources, such as: processing time and/or
memory usage. The second is to take as input not only the user-memorisable password, but
also a sequence of random bits known as salt 3 (Schneier, 2015). The presence of such
random variable thwarts several attacks based on pre-built tables of common passwords,
i.e., forces the attacker to create a new table from the scratch for every different salt. The
salt can, thus, be seen as an index into a large set of possible keys derived from the
password, that does not have to be memorized by users or kept in secret.

Password-based Remote Authentication and Key Exchange

In principle, KDFs could be used for data delivery: if the local and remote systems share the
same password, they could exchange data by revealing to each other the salt employed for
generating the key that protects such data. However, since this would allow attackers to use
the same salt in an offline dictionary attack, KDFs are usually employed only for local data
storage, establishing a secure channel between the human user and the local system. Data
delivery to remote locations usually employs Password Authenticated Key Exchange (PAKE)
protocols. Such schemes allow two or more parties who share a password to authenticate
each other and create a secure channel to protect their communication ( for example,
(Bellare, Pointcheval, & Rogaway, 2000). To be considered secure, a PAKE solutions
must ensure that an unauthorized party ( that fully controls the communication channel but
does not know the password) is unable to learn the resulting key and is, as much as possible,
unable to guess the password using offline brute force attacks. The Secure Remote
Password (SRP) project group (O'Brien et al., 2020). describes the following attacker model
for PAKE protocols: (a) attackers have complete knowledge of the protocol; (b) attackers
have access to a large dictionary of commonly used passwords; (c) attackers can eavesdrop
on all communications between client and server; (d) attackers can intercept, modify, and
forge arbitrary messages between client and server; and, (e) a mutually trusted third party is
not available. Looking briefly into the history of PAKE protocols, the Encrypted Key Exchange
(EKE) (Bellovin, & Merritt, 1992) was probably the first successful proposal. Although
several of the published methods were flawed, the surviving and enhanced forms of EKE
have effectively amplified the security of using passwords to establish shared keys for
confidential communication and authentication. Other provably-secure PAKE include the
schemes described in (Brusilovsky et al., 2010) (which uses the standard model4 ) and in
(Bellare, & Rogaway, 1993) (which uses the random oracle model5 ). This groups of EKE-
inspired proposals are commonly referred as EKE family of protocols.

Forward Secrecy Property

The security of computer systems rely on the condition that attackers cannot gain access to
an underlying secret (Itkis, 2004). In practice, however, achieving this condition can be
challenging. Most strategies used to minimize exposure of the secret keys end-up raising
costs and/or affect system’s usability (e.g., multi-factor authentication mechanisms).
Therefore, we must assume that a sufficiently motivated adversary may succeed in exposing
the system’s secrets (specially when using PAKE), and we should explicitly deal with such
events and elaborate strategies to minimize potential damages. One approach, is to use
(password-based) protocols that have the so-called forward secrecy (also called perfect
forward security) property (Muñiz, & Steinwandt, 2011). For PAKE schemes, this property
can be translated as follows: if the long-term secret information (e.g., the password) is
revealed to an attacker, this information cannot be used to obtain ephemeral keys (i.e.,
“session keys” derived from the long-term secret) from past communications, effectively
protecting all information previously exchanged (Qiu et al., 2018). That is, if the parties
participating in the protocol share a long-term secret S and run the protocol r times before S
is compromised by an attacker, that attacker is unable to determine the set of ephemeral
keys K1, . . . , Kr generated prior to this disclosure of S; only the subsequent keys Kr + i
where (i > 0) generated using the same S can be compromised by that attacker. This concept
is an integrating part of many modern security solutions, including pseudo-random
generators, digital signatures and public-key encryption (Itkis, 2004). It is usually employed
for securing data channels for limited/temporal interaction (i.e., keys expire and should
change). Nonetheless, it is also possible to employ the forward secrecy concept for securing
data storage, avoiding the encryption of large quantities of data with a single secret key
(e.g., as done in OpenPGP’s [9] e-mail encryption (Qiu et al., 2018)). Whichever the case, the
main drawback of applying forward secrecy is that such strategy incurs additional
operations and, most likely, a more complex key management/evolving scheme.

Secure Data Storage

At the time that user and server agree on a common shared key (e.g., the ephemeral keys
aforementioned) by means of a PAKE protocol, this key can be used to protect the data
stored in the mobile phone. This secure storage mechanism should encrypt all the sensitive
information that will reside in the mobile storage (e.g., configuration files, user’s data) and
the in-transit data that is temporarily stored and sent to the server. Hence, encryption
assures data confidentiality letting only authorized parties to read data. This mechanism
shall use sufficiently lightweight encryption algorithms owing to the device’s limited
processing and memory capacity. However, encryption carries the risk of making data
unavailable due to data transformation, or if anything goes wrong with the key
management process. In other words, developers should be aware that the key
management adds complexity since at least on the server-side its necessary to store partial
values to rebuild users’ keys in order to decrypt and to consolidate received data.

3.5.2 Privacy Impact Assessment (PIA)

 Privacy is not only personal data protection, as already mentioned, it has a broader
dimension and is more complex than security. For someone to understand privacy, it is
crucial to comprehend its technical aspects (e.g., user profiles, data flows, data holders), its
security implications, and also consider particular and cultural elements around privacy to a
given context. Privacy Impact Assessment (PIA) is a pragmatic manner to make such
analysis. This method was encouraged or made mandatory by various legal frameworks for
privacy and data protection in different regions (e.g., New Zealand, Canada, Australia, Hong
Kong, European Union). While there is no internationally accepted definition for PIA, we
consider the following two definitions:

[PIA is] “a process whereby the potential impacts and implications of proposals that involve
potential privacy-invasiveness are surfaced and examined.” (Clarke, 2019) Or a more
detailed construction: “a privacy impact assessment as a methodology for assessing the
impacts on privacy of a project, policy, programme, service, product or other initiative and,
in consultation with stakeholders, for taking remedial actions as necessary in order to avoid
or minimise negative impacts. A PIA is more than a tool: it is a process which should begin at
the earliest possible stages, when there are still opportunities to influence the outcome of a
project. It is a process that should continue until and even after the project has been
deployed.” (Clarke, 2019)

PIAs can be tailored to a specific technology and application. For instance, RFID PIA
Framework which was developed by industry players and endorsed by the Article 29
Working Party6 (Wright, 2012). Such approach creates a PIA template that is pertinent for a
specific industry sector. A PIA template establishes a four-stage process (Wright &
Hert, 2012). (1) a full description of the application and scenario; (2) identification of
privacy threats; (3) a proposal of technical and organizational mitigating measures; and, (4)
document the resolution (results of the analysis) regarding the application. In the same way,
mHealth and eHealth developers could benefit from PIA templates.

3.5.3 Data Anonymisation and Obfuscation

High quality healthcare requires sharing data. Access control is one of the straightforward
strategies to enforce confidentiality of patient’s information in health systems. However, we
believe that besides the typical binary decision of revealing or not a data value, access
control can be further improved with data obfuscation, i.e., to lower individual data item
accuracy in a systematic, controlled, and statistically rigorous way to guarantee patient’s
privacy while retaining its usefulness. For instance, instead of revealing the patient’s age
one can reveal a range of values. Or even, replace the of medical condition or disease by a
more general term (e.g., “Human Immunodeficiency Virus (HIV) infection” replaced by
“Infectious Disease”). Besides, individuals’ health information are also important to create
rich statistical databases for researchers and to support public health programs. In such
cases, data anonymisation should be employed, i.e., to protect privacy by making a number
of data transformations so that individuals whom the data describe remain anonymous. The
anonymisation process can have variable degrees of robustness (European Commission,
2018) depending on how likely is to: 1) single out an individual in the dataset; 2) link
records concerning the same individual; or, 3) infer the value of one attribute based on
other values. In essence, all these circumstances should be avoided, resulting in an
anonymised dataset. Therefore, anonymised data is not considered personal data, so that,
data privacy laws would no longer apply.

3.6 REQUIREMENTS FOR STANDARDIZING UGANDA’S DIGITAL HEALTH

In light of the various challenges to the standardization of digital health in Uganda’s health
system (Alunyu et al., 2021; Kiwanuka et al., 2021), we derived and validated requirements
to guide the development of the digital health standards and Enterprise Architecture (EA)
framework. These requirements were also informed by literature and success stories in
other countries. The requirements are presented under three broad categories as follows;

A. Digital Health Standards – are requirements that should be met by MoH when developing
standards/guidelines/SOPs for patient and health data, standards for the communication
infrastructure (ICT including devices, network and connectivity, and use), security and
privacy standards, and when conducting the activities of the digital health standardization
process.

B. Digital Health Architecture – are requirements that should be met by MoH, Health
Development Partners and other stakeholders to streamline digital health implementations
and governance in Uganda.

C. Digital Health Capacity Building – are requirements for building the human resources
required to implement and use digital health. These includes requirements for ICT skills
development and training, sensitization of healthcare professionals and health
informaticians on emerging digital health trends, adopted technologies, and
guidelines/SOPs, and training on the digital health standards itself and how to apply such
standards.

3.6.1 DIGITAL HEALTH STANDARDS

Requirements for the digital health standards shall cover the scope of data standards
(semantic and syntactic interoperability), the communication infrastructure that support
HIE, and the security and privacy of both the patient data that is collected, and the
components of the communication infrastructure. Table 2 presents the three main
categories of the digital health standards.

Table 2. Categories of Requirements for Digital Health Standards

Code Requirement What for?

Category
 DHS_DS Data Standards Ensure that all parties use similar formats, language and
approach to
code, store, share, and interpret health information to
support interoperability
DHS_CI Communication Standards / Minimum requirements to guide each
Infrastructure party implement
an electronic communication infrastructure that
support reliable patient data sharing and HIE
DHS_SP Security and Privacy Guidelines for security and privacy measures that need
to be taken into account during the implementation
and use of the digital health
communication infrastructure

Data Standards The following standards shall be applied to ensure that the patient (health)
data collected, information processed, shared, and stored are in formats that support both
semantic and syntactic interoperability.

Requirement DHS_DS01 DHS_DS01:

Develop contextual comprehensive standards (SOPs/ guidelines/ frameworks) for sharing

and exchanging electronic patient data; these should be based on the international
standards for HIE (e.g., syntactic - HL7, IHE, FHIR, DICOM, and semantics - SNOMED, ICD,
LOINC, MeDRA, etc.), and in alignment with the Uganda Data Protection and Privacy Act,
2019.

DHS_DS01 Requirement’s Specification

(i). The standards should be explicit about data sharing and exchange across the four
domains including business, data, applications, security and technology.

(ii). The standards should be implementable using the available resources (technical
expertise, technology, infrastructure, finance etc.).

(iii).The standards should be well documented and with a clear dissemination strategy.
Requirement DHS_DS02 DHS_DS02:

Adopt digital health standards for electronic sharing and exchange of patient data.

DHS_DS02 Requirement’s Specification

(i). Develop guidelines on what and how to (harmonize) adopt digital health standards.

(ii). Create regulatory frameworks that guide the adoption and implementation of digital
health data exchange standards in DHS_DS01.

(iii).Allocate resources for the adoption process for digital health standards.
3.1.2 Communication Infrastructure / Technology Standards

Four key requirements need to be met to realize the role of electronic health
communication infrastructure to support reliable and timely exchange of patient data for
the purposes of patient care and health information sharing for timely and informed
decision making. The requirements are;

Requirement DHS_CI01 DHS_CI01:

Develop minimum requirements for the acquisition and maintenance of ICT infrastructure
for digital health.

DHS_CI01 Requirement’s Specification

(i). Specify minimum requirements for health facilities and agencies for acquiring ICT devices
for digital health.

(ii). The minimum requirements for health facilities and agencies for acquiring
communication infrastructure for digital health should be contextual, ubiquitous and secure
to enable protection, privacy and confidentiality of shared data.

(iii).The guidelines should specify topologies, protocols, middleware, security and privacy
mechanisms.

(iv).The guidelines should specify a set of administrative, technical and managerial actions
that should be applied during the lifecycle of the digital health infrastructure.

Requirement DHS_CI02 DHS_CI02:

Establish Memoranda of Understanding (MoUs) with Internet Service Providers (ISPs) to

provide quality service.

DHS_CI02 Requirement’s Specification

(i). Specify the terms for zero rating of healthcare services by telecommunication service
providers. (ii). Specify the expected quality of service to support healthcare communication
in Uganda’s healthcare system.

Requirement DHS_CI03 DHS_CI03:

Develop a funding model for the digital health communication infrastructure for health
facilities.

DHS_CI03 Requirement’s Specification

(i). The model should specify critical areas of infrastructure to be funded, possible sources of
funding and the responsible authorities.

Requirement DHS_CI04 DHS_CI04:

Develop/operationalize a policy on cost effective energy alternatives like renewable
energies/solar for essential systems and equipment for digital health.

DHS_CI04 Requirement’s Specification

(i). The policy should emphasize the use of diverse sources of energy focusing on clean
energy (renewable energy) such as solar, wind, water (hydro), biomass, and geothermal.

3.6.2 Security and Privacy Standards

The scope of digital health security includes authentication, data integrity, system security
and network/Internet security. Therefore, for Uganda to ensure digital health security and
privacy of its data systems, the following requirements should be met.

Requirement DHS_SP01 DHS_SP01:

Adopt officially the digital health data security guidelines to support the core data security
elements of confidentiality, integrity, and availability. DHS_SP01

Requirement’s Specification

(i). The guidelines for digital health data security should be tailored towards the digital
health strategy for Uganda as well as the Uganda Data Protection and Privacy Act 2019, and
international information security standards such as ISO/IEC 2700 series among others;
outlining how the cardinal principles of confidentiality, integrity, and availability (CIA) should
guide policies/controls designed to protect health data.

(ii). The guidelines should specify a mechanism for monitoring implementation and
enforcing compliance with health data security controls.

Requirement DHS_SP02 DHS_SP02:

Develop a digital health information security and privacy standard/guideline to ensure all
health facilities deploy security and privacy measures that protect privacy and
confidentiality of electronic patient data.

DHS_SP02 Requirement’s Specification

(i). The security and privacy standard/guideline should outline how the cardinal principles of
confidentiality, integrity, and availability should guide policies/controls designed to protect
health data.

(ii). The standard should define the full scope of digital health security and data privacy
measures that goes beyond physical security to identifying health information and related
assets plus potential threats, vulnerabilities and impacts.

(iii).The security and privacy standard/guideline should have clear indicators for compliance
with the Uganda Data Protection and Privacy Act.
(iv).The security and privacy standard/guideline should outline how personal identifiable
data can be protected.

(v). The security and privacy standard/guideline should have an M&E plan specifying how
risks faced by health data residing on digital health systems can be mitigated.

(vi).Also, the guidelines for digital health data security should be tailored towards the digital
health strategy for Uganda as well as the Data Protection and Privacy Act 2019, and
international information security standards such as ISO/IEC 2700 series among others;
outlining how the cardinal principles of confidentiality, integrity, and availability (CIA) should
guide policies/controls designed to protect health data.

THE DIGITAL HEALTH STANDARDIZATION PROCESS

To keep abreast with developments in technology, standards are reviewed from time to
time. Also, it is important to ensure proper implementation and monitoring of
compliance with agreed-upon standards. The entire process that entails standards
determination, implementation, compliance monitoring and review is what is referred
to as the standardization process. The requirements for the process of standardization
of digital health in Uganda include the following.

Requirement DHP_SP01

DHP_SP01: Develop a framework to aid the development of digital health standards to

address interoperability of eHIS.

DHP_SP01 Requirement’s Specification The framework should;

Specify components of the digital health interoperability platform.

Specify criteria for determining suitable standards for syntactic (rules and format) and
semantic (shared meaning) interoperability.

Clearly define a systematic process to guide the MoH and stakeholders who are
selecting/determining the digital health standards.

Properly articulate the implementation plan for digital health standard. (v). Specify criteria
and tools for testing / validating the standards.

Have a clear M&E plan including who conducts it, frequency, and criteria.

Have a clear strategy for the selection and composition of stakeholders who participate
in the digital health standardization process.

Requirement DHP_SP02
DHP_SP02: Create a collaborative platform where all stakeholders can participate online
in the development, review and/or monitoring compliance with digital health
standards.

DHP_SP02 Requirement’s Specification

Avail centralized (online) resources and tools to support interaction and/or group decisions
when developing/reviewing digital health standards.

Develop a mechanism for determining stakeholders to participate in the development,

review and compliance monitoring process.

(iii). Identify and allocate financial resources to support the digital health standards
development and review process.

(iv). The collaborative platform should have guidelines on user involvement specifying how
users / stakeholders will be involved in initiation activities (readiness assessment,
requirements elicitation, capability assessment), adoption / adaptation / development
processes, and implementation of digital health.

3.7 DIGITAL HEALTH ENTERPRISE ARCHITECTURE

The purpose of the digital health (eHealth) EA is to support the deliberate development
of digital health technical architecture, technologies and operational capabilities of the
health system in a standardized and aligned manner. To achieve this purpose, two main
categories of requirements have been developed as see in Table 3.

Table 3. Categories of Requirements for the Digital Health Enterprise Architecture

Code Requirement Category What for??

DHA_I Digital health To ensurethat there is

M Implementations interoperable
implementations of the digital
health applications

that support HIE across the entire

health system

DHA_GSDigital health Governance To ensure that there are rules

Structures and stakeholders

play their roles and

 responsibilities to achieve national
digital health policy

Requirement DHA_IM01

DHA_IM01: Develop a digital health Enterprise Architecture (EA) framework to guide

standardized implementation of digital health in the country.

DHA_IM01 Requirement’s Specification

The EA Framework should;

Outline digital health EA vision and principles.

Outline the Business Reference Model (BRM), Service Reference Model (SRM), Data
Reference Model (DRM), Application Reference Model (ARM) and Technology
Reference Model.

Detail the digital health Information Security Architecture. (iv). Outline digital health
Interoperability profile.

Define a suitable HIE model.

Determine a suitable criterion for readiness assessment.

Outline the digital health implementation plan (Transition Architectures).and processes

(viii). Outline the digital health skills model for Uganda.

Outline digital health impact assessment criteria.

Be aligned (specify what and how) to the eGovernment EA for Uganda.

Requirement DHA_IM02

DHA_IM02: Develop guidelines on user involvement in the design, development and

implementation of digital health.

DHA_IM02 Requirement’s Specification

(i). The guideline on user involvement should specify how users / stakeholders will be
involved in initiation activities (readiness assessment, requirements elicitation,
capability assessment), adoption / adaptation / development processes, and
implementation of digital health.

Requirement DHA_IM03

DHA_IM03: Develop guidelines on digital health applications designing and

development to support the integration of the eHIS in order to ease seamless sharing of
patient health data.

DHA_IM03 Requirement’s Specification The guidelines should;

Specify a common structure for data capture

Specify modes for linking (sharing) health data from one digital health application with
anther applications

(iii). Clearly stipulate mechanisms for testing and evaluating digital health applications
before committing to use.

Requirement DHA_IM04

DHA_IM04: Develop a health data reference model to describe data from healthcare
processes independent of current indicator definitions.

DHA_IM04 Requirement’s Specification The health data reference models should;

Map all healthcare business processes to determine relevant data entities.

Include a class model of the main data items (the healthcare process data entities)
and their relationships.

Requirement DHA_IM05

DHA_IM05: Develop a strategy for migrating paper-based health records to electronic

formats that cannot only be easily stored but also accessible in an integrated manner.

DHA_IM05 Requirement’s Specification

The strategy should stipulate;

Acceptable digital formats for capturing patient health data.

Procedure to be followed to ensure that the quality of patient data is not compromised
during the migration process (i.e., process of transforming manual records to the digital
formats).

(iii). Acceptable forms of electronic health data storage devices (hard drive disk, Compact
Disc (CD), DVD and Blu-ray Discs, USB Flash drive, or tapes) and storage sites such as
cloud storage and offsite storage.

Requirement DHA_ GS 01

DHA_GS01: Develop and operationalize a digital health governance framework to

oversee the development and implementation of ICT at all levels of the health sector in
Uganda’s health system.

DHA_ GS 01 Requirement’s Specification

The digital health governance framework should specify;

(i). Roles and responsibilities of the digital health governance structure as well as the
governance processes

(ii). How the digital health governance teams are to be empowered and or provided
with resources to oversee development, and implementation of digital health
standards.

Requirement DHA_ GS 02

DHA_GS02: The responsible authority/unit should be empowered to monitor

compliance of digital health standards at all levels.

DHA_ GS 02 Requirement’s Specification

In addition to specification of requirements in DHA_GS01 (i) and (ii);

The responsible authority/unit should be provided with resources to monitor

compliance to digital health guidelines at all levels.
(iii). The technical capacity of the responsible authority/unit should be strengthened and
empowered to monitor compliance to digital health guidelines at all levels.

Requirement DHA_ GS 03

DHA_GS03: Develop a compliance framework for digital health standards.

DHA_ GS 03 Requirement’s Specification

The digital health standards compliance framework should;

Identify / specify stakeholders to the compliance monitoring process.

Have enforcement mechanisms for compliance to digital health standards.

(iii). Have criteria for assessing risk of non- compliance with digital health standards.

(iv). Provide a mechanism for monitoring and reviewing compliance with digital health
standards.

(v). Provide a procedure for reporting level of compliance with digital health standards.

Requirement DHA_ GS 04

DHA_GS04: Sensitize the health workers on the requirements for monitoring

compliance and structures for digital health.

DHA_ GS 04 Requirement’s Specification

(i). Develop a roadmap for sensitizing health workers on requirements for monitoring
compliance and structures for digital health.

3.8 DIGITAL HEALTH CAPACITY BUILDING

Being a developing field, healthcare practitioners require training in the use of digital
health technologies and the application of digital health standards. Ways in which skills
and knowledge regarding digital health and standards can reach the expected persons
are categorized into ICT skills and training, training in digital health standards, and
sensitization of stakeholders regards digital health applications, technologies and
standards (see Table 4).

Table 4. Categories of Requirements for Building Capacity to use Digital Health and
Standards

Code Requirement Category What for?

DHC_IT ICT skills & Training Equip practitioners with the required computer skills to
use digital

health technologies with level of comfort

DHC_ST Digital Health Equip practitioners with knowledge of digital health

Standards standards

Training adopted/contextualized for use in Uganda’s Health system

DHC_SN Digital Health Introduce, orient and or familiarize DH implementers

and users
Sensitisation
with new/emerging digital health applications and
technologies

Requirement DHC_IT01

DHC_IT01: Develop training guidelines for health workers on basic ICT Skills and
digital health Information management.

DHC_IT01 Requirement’s Specification

(i) The specialized digital health training may include short courses on electronic health
data coding, digital health applications development, digital health data security and
privacy, digital health standards, digital health EA and emerging digital health
technologies.

Requirement DHC_IT02
DHC_IT02: Advocate for digital health courses to be incorporated in health workers’
training curricula.

DHC_IT02 Requirement’s Specification

The in-service training curricula should incorporate short courses on electronic health
data coding, digital health applications, digital health data security and privacy, digital
health standards, EA, Emerging digital health technologies, etc.

The pre-service training curricular /training programmes may focus on technology

literacy and usage skills; literacy in medical and digital health terminologies; digital
health standards; information and data literacy; security and privacy Literacy; digital

communication; digital health products and services; regulation and compliance

(implementation); healthcare business processes; networking and programming; and
data analytics.

The MoH should work / collaborate / partner with HEI/Academia to review their health
sciences programmes to include / accommodate digital health courses for pre-service
health workers.

Requirement DHC_ST01

DHC-ST01: Develop training guidelines for health workers on basic ICT Skills and
digital health Information management.

DHC_IT01 Requirement’s Specification

(i) The specialized digital health training may include short courses on electronic
health data coding, digital health applications development, digital health data security
and privacy, digital health standards, digital health EA and emerging digital health
technologies.

Requirement DHC_SN01

DHC_SN01: Sensitize all relevant stakeholders at national and sub-national levels on

the data exchange and sharing standards in DHS_DS01.

DHC_SN01 Requirement’s Specification

(i). Develop a roadmap for nationwide sensitization and campaigns on data sharing.

Recommended approach to data security in healthcare

Quality IT at the foundation

For a health facility to have a strong information security posture, it requires quality
IT: at least a stable application base and IT infrastructure. This is especially diffi cult
to achieve in healthcare settings due to a lack in human resources, restraints in the
budget, a history of underinvestment, and the complex application space;
nevertheless, it is crucial.
Although there are no established models or tools for a health facility to use in
evaluating the quality of its IT, there are a few markers that can shed some light. For
ex- ample, a health facility with a stable application base does not have helpdesk call-
logs that are overwhelmed with break/fix requests and its IT staff is not pre-occu
pied primarily with repairing malfunctioning or broken applications.
Equally important to IT quality is the state of the IT infrastructure. The infrastructure
can include any related resources and services used to deliver and support IT services
(e.g., hardware platforms, software applications, operating systems, and networking
and telecommunication tools) (Fitz-Gerald, 2014). Information security requires
that the IT infrastructure has configuration management, change management, and
logging and monitoring in place. At its core, configuration management aims to
maintain an updated inventory of IT assets and the relationship be- tween different
components. According to the Information Technology Infrastructure Library (ITIL),
this involves identifying and reporting each assets’ version and its associated
components (Moeller,2013). Although it is a daunting task, well-maintained
configuration management boosts vulnerability management and patch
management. The SANS Institute states that “configuration management underlies
the management of all other management functions: security, performance,
accounting and fault” (Management Association; Information Resources, 2018). In
line with configuration management is change management that ITIL describes as a
systematic approach to handling all changes in a standardized method (Argaw et al.,
2020). Change management not only avoids unnecessary service downtime, but it is
also useful during an attack. An incident response plan can be a version of change
management. Similarly, strict audit logs and monitoring of logging records are IT
functions which are critical to quickly recognizing attacks and obtaining details on an
attack (Argaw et al., 2020).

Preventative and proactive stance

In the past, hospitals experienced difficulties with de- vices that refuse operating
system patches or that became functionally compromised when, for example,
Microsoft Windows was updated multiple times (Argaw et al., 2020). Consequently,
 hospitals had to delay or refrain from closing various security gaps in the operating
system. There has been a recent push to promote data security as a value
proposition among medical device and equipment manufacturers, shifting the
approach to data security by motivating them to value it and sell it as an asset
(Tanev, Tzolov, & Apiafi, 2015). Data security is not simply plugged in as an
afterthought but has become one of the prerequisites of the design (Moses &
Korah,2015). This has also been reinforced by the US Food and Drug Administration
(FDA), that expects manufacturers to implement on-going lifecycle processes and to
monitor continued safety post-market (F.D.A, 2018).
In 2017, the FDA began mandating that medical de-vice manufacturers show that
their devices are able to have updates and security patches applied throughout
their lifespan. Additionally, they must show that they have addressed any
undesirable issues that would affect the patients if the device was to be
compromised. As part of this same regulation, the FDA requires that a “bill of
materials” be shared with buyers of a medical de- vice. The bill of materials provides
transparency to the device buyer as to the source of each component (hard- ware
and software) contained in the medical device. These new rules will apply to
manufacturers, who must submit a 510(k)-pre-market submission package to the FDA
(Argaw et al., 2020).
These measures puts the onus on manufacturers, however, the call to approach
data security with a more engaged and proactive stance should not be limited to
manufacturers but should challenge health facilities as well. Hospitals ought to
invest in prevention by designating resources and budgeting early, rather than
depending on reactive approaches following attacks; this might be difficult in light
of historic underinvestment in human resources and funding in hospital
information security (Argaw et al., 2020).

Risk-based approach
Data security requires the highest level of security measures. However, as infallible
data security is nonexistent, a risk-based approach through enterprise risk
management is necessary. Even with quality IT infrastructure and practices, along
with a proactive stance and information security measures, the risk of an attack will al-
ways persist. Therefore, the framework for managing data security recommended by
the US National Institute of Standards and Technology (NIST) and the
recommendations of the European Union Agency for Network and Information
Security (ENISA) are rooted in a risk- based approach.
Risk assessment depends on the identification of at risk IT assets, stressed as the
first step by the NIST Cybersecurity Framework (CSF) for critical infrastructure, and the
identification of potential threats through methods such as vulnerability
management (Argaw et al., 2020). An asset’s value to the organization and its
exposure to risk should determine its priority in the protection processes. Quality IT is
important here, as configuration management will be integral to this identification
step. Risk analysis of these findings should consider tradeoffs between risks and
benefits, as well as between different risks (Soldatos, 2020). It should also evaluate
the potential consequences for patient safety and maintenance of operations (Argaw
et al., 2020). This requires the assessment of an incident’s impact on data and privacy
protection (confidentiality), availability of in- formation, and integrity of information.
The latter is especially important as the integrity of health data can have severe
consequences for the patient’s safety.
Health facilities can manage risks through various methods, from mitigating,
avoiding, or transferring to accepting the risks (Soldatos, 2020). The NIST CSF follows
this identification of risks step with Protect, Detect Incidents, Respond, and Recover
(CI Cybersecurity,2018)

Training and awareness

As humans are the weakest link in data security, health facilities’ approaches to data
security should take into account the need for raising awareness among all users
(Argaw et al., 2020). This, of course, does not guarantee security, but it is a step in
the right direction. End users, from clinicians to billing and scheduling staff, as well
as patients and caregivers who connect their personal devices with the hospital
network, can unintentionally—or intentionally—threaten the data security of the
health facility. Human error also poses risks as in the incident at Geneva University
Hospital (HUG) in October 2019 (Soldatos, 2020). In an effort to mitigate risk, the
ENISA’s Security and Resilience in eHealth publication among others recommend
providing data security training (Soldatos, 2020).
To offer relevant and effective trainings, health facilities should frequently assess and
identify gaps in know- ledge (Argaw et al., 2020). It is important for end users to
realize the risks they cause through inadvertent actions. For ex- ample, they should
be aware that storing data on their mobile devices can pose privacy and data-
integrity risks (O'Brien et al., 2020). whereas the use of connected devices or
removable storage devices can increase the risk of malware execution. Similarly, end
users should have a concrete under- standing of the threats (e.g., What is a
ransomware attack, what are the effects, and how is the attack initiated?). End
users are potential targets for social engineering methods, hence training programs
should explore how to handle unrecognized e-mails and avoid phishing tactics, while
encouraging basic digital-hygiene practices (e.g., strong passwords, not clicking on
un- known links).
Cyberattacks, such as the May 2017 worldwide WannaCry attack, serve as a wakeup
call, but it is in the best interest of organizations to keep up vigilance even when
threats are not in the headlines (Mattei, 2017), One way to do this is by enacting
mock exercises and simulating cybersecurity drills. Health facilities can approach this
in different ways: from having the information security team send users simulated
phishing e-mails, to setting up drills for IT officers such as locating and neutralizing
unauthorized devices on the network (Argaw et al., 2020). These exercises can even
evaluate the effectiveness of the organization’s current training programs (Mattei,
2017).

Recommended Data security measures

Vulnerability management, patch management

Exposure and vulnerability management involves the identification, evaluation,
and mitigation of IT vulnerabilities. It relies heavily on threat-monitoring
processes but also entails all the identification steps: risk assessment,
remediation or mitigation steps, and reevaluation (Mattei, 2017), In handling and
investigating attacks and post- infection remediation, Endpoint Detection and
Response (EDR) solutions should be used. In most cases, this risk assessment is
highly complex. Among the steps towards remediation or mitigation, there is also
patch management that can become complicated by a health facility’s need to
operate 24/7/365. Risk analysis is at the core of patch processes: weighing the
sensitivity of data on the server and an enterprise’s critical functions or assets vul
nerable to an attack (Argaw et al., 2020).

Organizations should actively search out vulnerabilities in their systems and

maintain ongoing vulnerability management with penetration testing (Mattei, 2017),
Early detection can help reduce exposure to a security risk. The identification of
vulnerabilities should also be followed with configuration hardening or patch
processes without an overemphasis on zero-day vulnerabilities. Gartner analysts
recently found that 99% of exploits are based on vulnerabilities that were known to
security and IT professionals for over six months (Hodson, 2019). In prioritizing the re-
mediation of different vulnerabilities, organizations should consider such findings.
As for the importance of maintaining quality IT infra- structure, configuration
management has the benefit of increasing ease in assessing vulnerabilities because of
a broader understanding of the facilities’ IT infrastructure and in running risk
assessments, as well as analyses required for patch processes. Patching should be
applied to all systems in the configuration (this includes the operating system and
third-party applications) and changes should be noted by change management
(Hodson, 2019).

Administrative privileges and administrative multifactorial authentication

The risks associated with granting administrative privileges to users in health facilities
are immense. According to Cyber Sheath’s APT Privileged Account Exploitation report,
the vast majority of large-scale attacks that caused significant damage and expenses
were initiated through the compromise of a privileged account such as that of a third-
party provider (Hodson, 2019). This was the case for the attack that took place at
Hancock Regional Hospital in January 2018, when the login credentials to a vendor’s
 account were compromised (Hughes, 2018).
Health entities should grant administrative privileges in a controlled and restrictive
manner, in order to minimize the number of such accounts to an enterprise-
dependent manageable sum (Hughes, 2018).These accounts should be inventoried,
monitored for abnormal use, and evaluated for log entries. To avoid malicious insider
threats, the health entity should also enforce local pass- word policy and revisit their
criteria for privileged access in addition to the vetting of users. A study revealed that
disgruntled employees account for 70% of computer- related criminal activity (Argaw
et al., 2020). Organizations should address the risk of such threats by closely
monitoring the lifecycle of user accounts and revoking client and user certificates
when no longer in use. Additionally, end users requiring administrative privileges
should have two accounts: one that has privileges limited to local ma- chines and
another with no administrative privileges to be used for routine tasks such as
browsing the internet or checking emails (Hughes, 2018). When necessary, direct
web-access on critical devices should be denied or the use of encapsulated browsers
should be enforced.
It is important to provide users who are granted ad- ministrative or privileged
accounts with additional training on the risks brought on by their privileges, as it is
important to equip them with the proper security measures. Among the most
important measures is the use of multifactorial authentication for all administrative
and privileged users—preferably for all users. The Center for Internet Security’s (CIS’s)
Critical Security Controls for Effective Cyber Defense lists the use of smart cards, One
Time Passwords, or biometrics, among the techniques to implement this vital step
(Hughes, 2018).

Incident response plan

As cyberattacks have become increasingly frequent and consequential in recent
years, health facilities should prepare an incident response and business continuity
plan. These plans should be regularly tested, exercised, and stored offline (Hodson,
2019). Plans should involve an agreed upon process with the appropriate
stakeholders identified. It is important to have a designated team and a cybersecurity
leader, or simply a designated person in cases where the organization does not
have a CISO (Argaw et al., 2020). The roles and responsibilities should be clearly
divided within the team. The organizations should also have an agreement on what
constitutes as a reportable incident and when to escalate (Argaw et al., 2020). Ideally,
plans should embed prevention training as well.

Incident response plans should also endorse post- incident steps. This can involve enforcing
organization- wide password resets after an attack, factory resetting, and replacing
compromised hardware and software as necessary. However, there needs to be an internal
plan for regrouping and implementing changes (CI Cybersecurity, 2018). The IT and data
security system and its management should then be adapted to the new needs and
requirements that were revealed by the incident (i.e., patching and beyond). A notification
system should be established between the health facility and the manufacturers (CI
Cybersecurity, 2018). A process can be built for those in the enterprise (e.g., clinicians,
business administrators, and IT staff) to report incidents directly to the manufacturers. In
fact, this type of sharing is also being mandated in the most recent FDA 510(k) pre-market
submission guidelines (Argaw et al., 2020).

Information sharing
The exchange of potential threats, indicators of com- promise, best practices,
vulnerabilities, lessons learned, and of mitigation strategies between stakeholders
across public and private sectors is an essential step in building the data security of
healthcare systems (Hodson, 2019). Information sharing facilitates situational
awareness and a solid understanding of threats and threat actors, their motivations,
campaigns, tactics, and techniques. Consequently, it better equips decision makers to
understand organizational exposure and to employ enterprise risk management
policies. Information sharing should include all stakeholders: providers,
manufacturers, suppliers, payers, and electronic record providers, as well as
government(s) where applicable.
There are organizations that exist specifically to facilitate collaboration between
institutions, for example, the National Health Information Sharing and Analysis Center
(NH-ISAC), a global, member-driven non-profit providing a forum for trusted sharing
amongst healthcare organizations. The EU adopted the Network and Information
System (NIS) Directive in 2016—the first EU law specifically focused on cybersecurity—
to be transposed by member states by 2018. The directive requires member states,
most notably, to adopt national data security strategies, to designate national
competent authorities, and to develop one or more computer security incident
response teams (CSIRTs). It also establishes security and incident notification
requirements for “operators of essential services,” such as healthcare organizations,
even requiring incidents of certain magnitudes to be reported to national
authorities. To promote swift and effective operational cooperation regarding threats
and incidents, the directive emphasizes coordination among member states, setting
up a CSIRT network (also to include CERT-EU), and a strategic NIS “cooperation group”
to support and facilitate cooperation and information ex- change among member
states (Hodson, 2019).

Privacy-conscious data sharing and processing

The sharing of medical and genomic data, across departments and institutions, is
necessary for both effective patient care and for meaningful research that advances
the state-of-the-art in personalized medicine. In fact, the re- cent increasing trend
towards P4 (Predictive, Preventive, Personalized and Participatory) medicine is called
to revolutionize healthcare by providing better diagnoses and targeted preventive
and therapeutic measures. How- ever, clinical and research data on large numbers of
individuals must be efficiently shared among all stakeholders. In this context, data
security is as relevant as it is in regular hospital operations, but the privacy risks that
 stem from disclosing medical and genomic data play a prominent role and have
become a barrier in the advancements of P4 medicine (Williams, & Woodward,2015).
This is further reflected in the evolution of stricter regulations (e.g. HIPAA in US and
GDPR in the EU (Williams, & Woodward,2015).
The challenges of privacy-conscious data sharing and processing can be addressed
through the use of advanced cryptographic mechanisms (such as homo- morphic
encryption (Argaw et al., 2020), trusted hardware (Costan, & Devadas,2016).
secure multiparty computation (Williams, & Woodward,2015)), and strong trust
distribution techniques (such as distributed ledger technologies). The use of these
technologies pro- vides security guarantees beyond those implemented by traditional
approaches against data attacks (Williams, & Woodward,2015), with the following
four direct advantages: (a) achieving a more fine-grained control on access
permissions, hence reducing or avoiding the need of privileged accounts to third
parties, (b) implementing minimization principles on the released data for the agreed
usage, in line with the latest and stricter data protection regulations and minimizing
the risk of breaches and intentional or unintentional data misuse, (c) keeping
individual and identifiable data within the confines of the security perimeter of the
medical institution that governs them, and (d) enabling dis- tributed logging and
access control management, hence avoiding single points of failure and greatly
reducing the effect of a breach and the risk of a successful attack, while allowing for
more advanced implementations of auditability, accountability and incident
recovery.

Consequently, privacy-conscious data sharing and processing approaches are aligned

with the aforementioned risk-based cybersecurity strategies, provide guarantees
that go beyond the latter, yet enables operations across medical institutions that
would otherwise be impossible.

Recommendations for connected medical devices

The FDA defines medical devices as

An instrument, apparatus, implement, machine, contrivance, implant, in vitro

reagent, or other simi- lar or related article, including a component part, or
accessory [ … ] intended for use in the diagnosis [
… ] cure, mitigation, treatment, or prevention of disease [ … ] (Williams, &
Woodward,2015)

This definition encompasses equipment such as beds, in-house treadmills,

intravenous pumps, and monitors, as well as implantable and connected devices
such as pacemakers and insulin pumps. Additionally, wearable devices (such as
Fitbits) that monitor, and record health and lifestyle data can now be connected to
clinicians’ de- vices. These devices can propagate flaws or incidents in data security
and act as weak elements in the security chain by which malware can spread. The
 diversity in de- vices can also make it difficult to enact strict security policy, but the
data security of these devices is critical. Medical devices are typically in direct contact
with patients and can increase risks to hospital operations and patient safety.
Advancements such as the Internet of Things enables remote medical care and
precision in healthcare delivery. However, clinical care utility and safety need to be
balanced with security and privacy. Devices are highly inter- connected in the hospital
network and large sums of collect clinical data that need to be securely transferred,
but these devices also have inherent limitations that ex- pose them to vulnerabilities.
They often do not have the proper security measures because they do not have the
battery power or the built-in resources to efficiently employ security measures such
as encryption and forensic processes, threat modeling activities, and malware
detection (Mattei, 2017), Devices designed to function in isolation often end up
integrated into the network, whereas physical security of the wearable devices is
nearly impossible as they do not typically have long life spans and their operating
system or relevant platforms become outdated relatively quickly (Mattei, 2017).
Decision makers should evaluate the expected lifetime of devices (e.g.,
manufacturer/vendor-support or operat ing system-support) before purchase. In
conjunction, equipment maintenance is critical to medical-device security.
Hospitals and manufacturers, with support from certifying authorities, should
develop a patching policy that minimizes equipment downtime and enables timely
updates through a collaboration with the external manu facturing community and
internal stakeholders. Collab- oration with manufacturers can allow facilities to
better monitor new alerts in order to keep up with critical or urgent patches and
updates. Facilities should also develop and budget for life-cycle management in
order to retire devices that cannot be replaced right away.
It is also essential for IT to maintain a regularly up- dated inventory of all devices on
the network (autho rized and unauthorized). Hospital networks often have numerous
personal devices that are integrated. Patients and physicians often connect external
mobiles and wearables, thus increasing exposure and complicating bring your own
device (BYOD) policies. The health organization should enact reasonable measures
and policies to block connectivity of unapproved personal de- vices (mobiles, tablets
…) (Mattei, 2017), even using mobile device management or software distribution
systems. Besides this, health facilities should enforce local data encryption, when
possible, in a preventative stance.

4.0 Conclusions and Future Work

While there is no universal approach when it comes to implementing e-health solutions

the guidelines presented here describe the basic process and components. The
situation should improve rapidly in the future thanks to the increasing numbers of users
who are familiar with computer technologies, to more user-friendly systems and to the
rapidly-increasing number of systems in place. In addition, countries are beginning to
evaluate e-health initiatives and to share these early results in order to inform new
projects.

Building the cyber resilience of a hospital is vital and it is a shared responsibility.

Users (i.e., clinicians and ad- ministration staff) should undergo training and should
practice digital hygiene, decision makers should enforce the proper policies and
consider data security in purchasing decisions, and manufacturers should equip their
products with the appropriate data security measures. The information security
teams of hospitals should also enact and upkeep the proper tools to safeguard the
hospital and patients.

Information security teams should equip users to counter social engineering

methods by, for example, filtering e-mail content, auto-checking suspicious URLs in e-
mails for linked malicious code, whitelisting trust- worthy websites and applications,
as well as blocking Flash, advertisements and untrusted JAVA code on the Internet, as
necessary Other tactics for reducing exposure should be used, such as intentionally
changing default passwords and regularly updating security configurations on
laptops, servers, workstations, firewalls, etc.. Antivirus software is also important,
along with penetration tests, control of physical access, and the maintenance of
regularly updated backups (which should be stored offline). The organization’s
website and the industrial control systems, including HVAC, cameras, fire alarm
panels, should be secure and locked down from attacks. EDR Software can also help
detect malware breaches and react properly to recorded infections. Finally, there
should be appropriate tools in place for protecting data shared across different
departments or medical institutions in a privacy-conscious way, there fore reducing
the risk of intentional or unintentional breaches through trust distribution (Mattei,
2017).

Health Informatics advance just as far as the individuals’ trust in it. Various applications have
been created with the hope to further develop healthcare as medical or public health
practice. Social development, however, is only real if in consonance with fundamental
human rights. Above all, is the right to freedom. Privacy, in turn, has precedence in the right
to freedom of opinion and expression, which includes freedom to hold opinions without
interference [2]. Without respecting such conditions, new technologies in HI – and other
fields – will not achieve their full potential, and may instead be harmful to its users. In this
paper we deal with the concepts of security and privacy as fundamental principles to
achieve high quality healthcare. The research has special focus on eHealth technologies,
that have been particularly successful in developing countries. We started with a
comprehensive literature review about mHealth initiatives. Among the various categories of
mHealth applications, the class of MDCSs attracted most attention, since such systems
handle large amounts of data, for surveillance of whole communities. This, along with the
vexing lack of security in existing solutions, provoked the researcher to continue research in
the topic.
Community Health Workers (CHWs) also play a crucial role in the deliver of basic health and
medical care worldwide. They are the first and often the only link between the community
and the health system. It is crucial to understand how CHWs make use of mHealth
technologies in their work environment in order to design systems that fit their needs.
MDCSs should be primarily made for empowering them. Besides, specially regarding
security and privacy, it is important to raise awareness among stakeholders, including the
CHWs, project managers, developers, nurses, doctors, and other users. Privacy by design
and by default, well-known in the literature and data protection laws, should be put in
practice. Health professionals should be conscious that privacy and data protection is a part
of their job; and, that its non-observance leads to inferior or inadmissible level of
healthcare. In this regard, this paper presents our implementation experience on secure and
privacy-preserving MDCSs. The privacy aspects of MDCSs should be nevertheless further
investigated. Therefore, for future work, the researcher plans to continue the research
already introduced in in this paper. Respectively, the completion of the PIA template for
MDCSs and additional investigations on medical data obfuscation and anonymisation. Thus,
heading towards the design of relevant security and privacy frameworks for MDCS, as well
as for mHealth systems in general. This document should therefore rapidly become
obsolete, having served merely as a stepping stone to the future.