Challenges in software development of mobile apps in e-health

(1)

Teknik och samhälle

Datavetenskap och medieteknik

Master Thesis-VT20

Challenges in software development of mobile apps in e-health

(2)

Abstract

Throughout the development process within organizations, various complications can ap-pear that can reduce the quality of a software or contribute to immense costs to organi-zations. This is especially true for organizations that operate in fields such as the health industry where stern rules and requirements are often a fact. This paper explores chal-lenges that can arise during the development process of health applications as well as what effects these can have on the applications and organizations. The paper then examines how these difficulties can be prevented or mitigated. The intention is that this thesis should help organizations and developers to be able to go through a development process effectively without being overwhelmed by difficulties that can arise during the development process of health applications.

(3)

4.2 Survey Research . . . 22 4.2.1 Pilot Study . . . 22 4.2.2 Survey respondents . . . 22 4.2.3 Regulations . . . 23 4.2.4 Requirements . . . 27 4.2.5 Development methods . . . 30 4.2.6 Security . . . 33 5 Discussion 39 5.0.1 Regulations . . . 39 5.0.2 Requirements . . . 40 5.0.3 Development methods . . . 40 5.0.4 Security . . . 41

(4)

5.1 Limitations . . . 45 5.2 Future work . . . 45

(5)

1 Introduction

The health sector is the subject of extensive research because of its great value to society in the form of new and often vital information [1]. This paper identifies and examines the current challenges that developers face as they strive to deliver health technology solutions to their customers and stakeholders. The paper points out challenges that are common in their environment and that negatively affect their work. Finally, it addresses guidelines on how to prevent and mitigate the challenges.

1.1 Motivation

Information and communication technologies (ICTs) in the health sector have increased dramatically since the 2000s [2]. This, coupled with a trend towards ubiquitous computing, has brought improved connectivity and digital solutions in the health industry. However, as the health industry shifts towards a more digital environment developers working on health applications often face challenges that in some cases are only relevant to the development of health applications such as security requirements, regulations, and laws [3, 4]. The motivation for this article comes from the attempt to understand these challenges and thus improve the predictability of future encounters with these challenges, or in some cases, even to try to eliminate these challenges from the outset by summarizing the challenges discovered.

1.2 Goal

The thesis aims to examine challenges that may arise within organizations in the health care industry through a literature review. Based on the literature review, a survey will be conducted and sent out to several organizations working in the health care sector to validate the results of the literature review and to investigate additional challenges. The aim is then to use the results of the literature review and the survey to establish the challenges and analyse how the findings can be prevented or mitigated.

1.3 Expected Results

The main result of this work should be a summary of the challenges that frequently occur in software development of eHealth for mobile application in the form of new knowledge for developers and project managers in the sector. While it is true that software development is a complicated process involving many factors and variables, this study should aim to categorize the most common challenges in eHealth and provide an understanding of how to prevent known and recognized threats.

• Provide a list of key factors influencing a software development of eHealth mobile apps

• Deliver a summary which should help developers to understand and prevent neg-ative obstacles and benefit from a gaining a knowledge of those factors and their implications to processes

(6)

1.4 Research Questions

RQ1: What common challenges are part of software development of health-tech solutions? RQ2: How to prevent challenges in software development of health applications?

2 Research Methodology

This section presents the research approach and research methods used in order to answer the questions presented in section 1.4.

2.1 Research Approach

The research approach utilized for the study is a quantitative procedure. The quanti-tative research strategy is a scientific study involving experiments and other systematic methods that emphasizes properties that can be represented as a quantity of value [5, 6]. A quantitative research approach can help researchers establish the truth or proven facts and abstain from subjective bias which is more prevailing in a qualitative study [7]. The reason for taking a quantitative research approach in this study is that the desired outcome of this research is to accumulate data using a literature study and then, through a survey, verify findings from the literature review and present data that directly influ-ence the software development of health applications, which depicts quantitative elements. Quantifying data can help us derive patterns and statistics about the data to generate knowledge and understanding of challenges that affect development procedures of health applications. The collected data can then be used further to build guidelines and recom-mendations based on the findings.

2.2 Research Methods

2.2.1 Literature Review Study

The study consists of two research methodologies, a literature review study, and a survey. The literature collection will be collected through Malmö University library portal and Google scholar as they support libraries such as IEEE Xplore and ACM Digital Library which are one of the top journals in the world [8]. The focus of the literature study will be a collection of documents that are related to current challenges and problems that occur within companies developing health-tech solutions.

The reason for using a literature study in this research is because one of the categories in a literature study is the identification of a problem associated with a subject. Conducting a literature study can help recognize gaps and predicaments in an area of research [9] which makes a literature review pertinent to our research as it concerns seeking challenges that transpire in the development of health-tech solutions. The conduct of a literature review must, however, be approached with caution, [9] states that conducting a literature review may be more susceptible to subjective bias in the selectivity in the literature review as re-searchers may only seek to find documents that fit the theory. To avoid such bias, we will

(7)

clearly state how the documents were identified, interpreted, synthesized and summarized, the study will also cover documents that may oppose the main result. Finally, the key-word selection will be verified by independent parties through a pilot-test of the literature review results. Questions formulated through the literature study will be tested through a company called InjuryMap which is an organization within the health industry located in Copenhagen. Through the organization the feasibility and relevance of the study will be tested. If the pilot-test produces information that can be valuable for the research and that the organization can verify the relevance of the study, the study will proceed into moving on towards other established organizations within the health industry.

2.2.2 Survey

After completing a literature review, a survey follows. The survey is a systematic way of gathering data from multiple entities to analyse such data [10]. This research method can verify gathered knowledge from the literature review and even uncover new challenges, not known or listed in literature. The survey method was chosen as it manages to gather data from sources in a more efficient way compared to traditional on-site or even remote real-time communication with surveys. Sending out the survey to companies outside of our narrow reach has a benefit of reducing validity threats of limited respondents pool. Even though surveys are not qualitative, compared to traditional interviews, their ability to gather data from almost anywhere in a reasonable time frame makes it an excellent way of understanding a human perspective into the matter [11]. Rather than creating a custom survey tool, an online form available through a well-known web service that is already established and has its reputability, was used. Evaluating results is then much easier and quicker and helps focusing time for more significant parts of this study. Creating a survey that is not too detailed and time-consuming for a survey to fill out but at the same time detailed enough to gather relevant data is a balancing act. The goal regarding the time difficulty of filling out a form was set to approximately 10 minutes. Understandably, an individual time to complete a form can differ due to external factors such as willingness to participate, think about questions and answers, and answer ques-tions truthfully.

Most questions focus on rating survey experiences regarding experiencing issues in software development. Possible challenges are chosen from a literature review and asked surveys to grade their experience with it. An example of such a question is: “How often are requirements changing during development phase?”. Following options would be offered:

• Never • Occasionally • Often • Always

These answers can then be reused for other similar questions to get a better overview of respondents’ experience. At the end of the survey, there will be an optional field to

(8)

describe freely any other challenges that weren’t mentioned or possibly explain into more depth a respondent experience. Surveys will be sent as a link to the web service to select software developers. Those will be mostly contacted through a professional social network Linked In, an easy way to find developers working with software medical solutions. 2.2.3 Alternative Methods

Alternative research methods that could be applied in the research are regulated interviews in replacement of using questionnaires which could have been done using a quantitative or qualitative approach. A quantitative interview procedure could narrow down the selection of organizations and offer more personalized interactions with organizations. A qualitative interview approach could potentially contribute to get an understanding of why potential challenges transpire within an organization, using open-ended questions during an inter-view could also provide a better understanding of both the organization and the challenges they experience.

However, conducting an interview of a quantitative or qualitative nature over the use of questionnaires could potentially limit the data gathered for the research which could lead to ethical issues such as misrepresentation in the result [5]. Using questionnaires, the selection of companies can be broadening as it can be expanded into working with organizations both within the vicinity and organizations situated abroad and get multiple different perspectives. Quantifying data in this research is also vital to help establish the challenges that occur within organizations in the health industry accurately.

2.3 Threats To Validity

There are several threats to the validity of this research. Beginning with the literature review, the actual collection must be sufficiently thorough to present valid evidence of the current state of knowledge for the targeted research objective. The collection has to be consisted of high-quality articles or studies and screen out irrelevant articles. Threats related to the method of investigation were to obtain a reasonable number of surveys completed by actual software developers working with medical software and to correctly identify the data received. The questions themselves are another common threat. They must be well defined, easy for respondents to understand and ask relevant questions about the study.

3 Literature Review

To answer RQ1 in section 1.4 a section is included which provides an overview of the latest literature on the most common challenges that transpire today in the context of eHealth, the findings will be used as a guideline to construct an inclusion, exclusion criteria and concept-matrix to filter out extraneous papers before continuing into conducting an in-depth literature review study on how these challenges correlate and affect the development of mobile health applications.

(9)

3.1 Identifying core concepts

3.1.1 Regulations

The health industry is one of the most regulated industries in the world [12]. Understand-ably, health is one of the most closely treasured parts for any person. Strict regulations apply for both professionals in the sector, as well as tools used in the sector. While dif-ferent genetic attributes difdif-ferentiate people, one’s focus on a health factor remains the same for everyone. Therefore, governing bodies are under big pressure to control health and medical markets. McHugh et. al [13] look at how regulations impact software de-velopment. The study begins with explaining the European union directive identifying medical software as a medical device. Being a medical device, it needs to follow rigorous requirements set by authorities in charge of medical development. This ensures a high quality of a software product but on the other hand, creates substantial complications for a business by increasing the cost of development and delaying the time to market period which indirectly influences the innovation aspect of a business and industry overall. 3.1.2 Requirements

A factor closely related to regulations. A study on software professionals [14], all with experience with working on medical information systems, conducted number of interviews with a goal of understanding main challenges in a development. Engineering requirements were the main challenge with a strong 60 percent of asked respondents stating it as the main issue in their work. These requirements are challenging due to strict regulations and overall complexity of developing a solution for a health tech market.

A research by N. Carroll [15] understands challenges and risks of high-quality require-ments as not always there is a match between a tool’s purpose and capabilities and user’s needs. The research suggests putting a big emphasis on understanding the problem a software solution should provide. Proposed design thinking is a reputable way of creat-ing well-defined requirements. Such requirements then should be properly tested after developing a first prototype.

3.1.3 Development methods

Understanding core principles underlying different methods of software development en-ables development teams incorporate benefits of such methods. A paper [16] by J.Bosch et al. defines three types of development: requirement driven, data driven, and AI driven development. While each type has its benefits and drawbacks, the paper brings evidence that wrongly selected method can result in wasted resources and inefficiency. Hence, a careful examination and selection of a software method is a crucial step at the beginning of a design process. To reiterate once more, one method can’t be suited to every project, requiring developers to understand situation and choose appropriate method for it. 3.1.4 Security

The importance of keeping sensitive data safe and away from unauthorized parties is a great challenge in any type of software development. However, handling health data of

(10)

customers brings the importance to even higher level. A research article conducted by S. Lipner [17], a member of Security Engineering Unit at Microsoft, describes three factors of a secure development: a repeat ability of processes, a developer’s background and an accountability in a form of statistical data. The article focuses on the first mentioned by implementing a model with key important attributes in mind: a safe design accompanied with a detailed processes and tools as a final check of a development cycle.

Even though the main focus of this thesis is to look at factors in a close connection to software development, article [18] done by W. A. Yasnoff et. al argues that creators of digital products in public health informatics need to take into consideration possible limitations caused by a human factor of users and their limited knowledge with regards to data security. In their case, an argument for educating users of such digital tools should be clearly understood by designers and developers of a system.

Researchers from University of Limerick, Ireland explored [19] software being a medical device and presented following key processes regarding data management:

• Transmit - network and devices responsible for data delivery • Store - any sort of storage used for persisting data

• Convert - services for transforming yet disallowed from any sort of alteration of original data

• Display - tools which role is to be an interface between a system and a user

Each part has its significance in an overall picture of the final output, combining the key principles to have in mind while building a software solution.

3.2 Inclusion and Exclusion criteria

The literature review will consist of two criteria, inclusion and exclusion criteria based on previous academic research papers in section 3.1 If the paper does meet two or more of the inclusion requirements the paper will be included and if it meets one or more exclusion criteria’s it will be excluded. The inclusion and exclusion criteria are:

• Inclusion 1 - The paper presents regulations in mobile health application develop-ment

• Inclusion 2 - The paper presents security and privacy in mobile health application development

• Inclusion 3 - The paper presents requirements and development methods in mobile health application development

• Inclusion 4 - The paper originates from the database it was found • Exclusion 1 - Papers with same results as previous papers.

• Exclusion 2 - Paper does not contain information related to health-tech develop-ment.

(11)

3.3 Literature Review Concept Matrix

The findings from section 3.1 were used to create a concept matrix to collect sources that correlate to regulations, requirements, development methods and security. The concept matrix may help to determine the relevance and rigor of the sources in the literature re-view study.

Sources Concepts

Regulations Requirements Development methods Security Y. T. Yang and R. D. Silverman [20] X X

K. Kamnoore et al. [21] X X X FDA regulation [22] X Regulation (EU) 2017/745 [23] X Zema et al. [24] X X Albrecth et al. [25] X X X Holubova´ et al. [26] X U.S Food and Drug Administration [27] X

Hrgarek [28] X X Bosch et al. [29] X Fernandes et al. [30] X McCall et al. [31] X Bøegh [32] X Sommerville [33] X X Boston. [34] X X Fulton et al. [35] X Berenbach et al. [36] X Beck el al. [37] X Abrahamsson et al. [38] X Janzen et al. [39] X Mäkinen et al. [40] X Limburg et al. [41] X Mitchell et al. [42] X Bhuyan et al. [43] X Strigkos et al. [44] X Morera et al. [45] X Kotz et al. [46] X Hussain et al. [47] X Singh et al. [48] X GDPR [49] X X Peréz et al. [50] X Lau et al. [51] X X Dennison et al. [52] X X Atienza et al. [53] X

(12)

4 Result & Analysis

4.1 Literature Review Study

The literature review addresses potential factors that lead to challenges in the software world of health applications. To fully understand the current state of development in the health sector, several categories have been defined in section 3.1. The state-of-the-art review centers around design, regulations, security, and development process and the fac-tors that influence them. Subsequently, there is a focus on how the categories correlate to internal factors within a development team/organization with a focus on medical devices. 4.1.1 Development of Mobile Health Applications - Regulations

Health care applications proceed to reverberate across the health care industry and in 2018 it was estimated to be roughly 3.4 billion downloaded mobile health applications. As applications blend into health care, regulations have converted into an augmented com-plexity and developers need to assure they comply with regulations to avoid any legal meshes. To do this, developers of healthcare applications often seek legal guidance to avoid complications [20].

In the context of health-applications there are two types of health-care applications: health applications used by health care providers to keep track of patient information or analyses of laboratory results, and health applications used for private purposes, such as fitness applications [20]. The content of this study is focused on health applications created for the general public rather than users such as doctors and surgeons. The regulatory litera-ture review will focus primarily on regulations for mobile medical applications in the EU, US and China, as these countries represent the majority of the mobile medical application markets (See Figure 1). Many countries in Asia Pacific, Africa and Latin America also follows the regulations of EU, USA and China [21].

Figure 1: GSMA. (n.d.). Global Mobile Health Market Opportunity by Regions, Us Billion and Share of Overall Market, 2017E.

One challenge that can arise when developing a mobile medical application is to determine whether the application created is actually a medical device that requires regulation.

(13)

According to [22] a mobile medical application is determined by the use case of the appli-cation, i.e. an application used for the diagnosis, treatment or prevention of a disease or, according to the FDA ”mobile medical app [...] that is either used as an accessory to a reg-ulated medical device or transforms a mobile device into a regreg-ulated medical device” [20]. FDA regulations stipulate that applications that are generally ancillary to regulated med-ical devices are applications used to control blood perfusion, blood pressure, implantable simulators for neuromuscular or cochlear implants. Applications that use a medical device to collect data on the condition of patients are also normally considered medical devices. Finally, devices that are converted into medical devices are usually applications that are transformed into a device, such as a stethoscope [22]. Applications that are not generally considered as medical devices are generally applications that provide recommendations to users based on references to books, dictionaries, training videos or educational informa-tion. However, usually, it comes down to the actual use case of the application, having an application to set diagnosis or prevent a medical condition are medical devices [22]. Similarly to FDA regulations the EU defines a medical device as any software intended to be used for diagnosis, monitoring, prediction, prognosis, and treatment of a condition or disability, or used in combination therewith [23].

Regulations may also alternate depending on the country in which manufacturers wish to apply. In the United States, Food and Drug Administration (FDA) directives should be followed and documented, while in Europe the requirements provided by European Union (EU), Regulation 2017/745 shall be followed in order to obtain a CE marking if required [24],[20],[25]. Examples of regulations for medical devices, when supplied in the EU, include certain requirements that fall under the general safety and performance requirements of Annex 1, which includes :

1. Provide and document a risk management plan for the device. [23]

2. Recognize and analyze known risks that are associated with the device. [23]

3. Relevant information for safety such as warnings/precautions should be provided to users. And where relevant, training should be provided if needed for users. [23] Both EU and US classifies a medical device into specific classes according to the risk it exposes to users of the application, in the EU according to [26] a medical device consists of the following classes: Class I, Class IIa, IIb and Class III - each class is dependent on the risk of harm when the application is used and all medical devices are required to be classified. All medical devices that falls under one of the classes provided by EU are also required to get a CE mark. An example of a Class I device can be an application with measuring functions, one of the requirements that needs to be full filled for medical devices with measuring functions are according to [23], to prepare technical documentation for the declaration of conformity which is documentation consisting of essential standards that needs to be followed in EU [23]. In the United States under FDA a medical device can be classified into three different classes and the class of a developed health application listed below needs to be determined in order to follow regulations accordingly.

(14)

CLASS I

Health applications with low risk of causing harm to users. No premarket notifacation required for applications falling under this category. [27]

CLASS II.

Health application with moderate risk of causing harm to users.[27] CLASS III.

Healthcare applications pose an extreme risk of harm to users and may be life sustaining or life-supporting applications.[27]

FDA also consists of main requirements (See list) that must be followed by all medi-cal devices and medimedi-cal applications.

1. All medical devices must register and list their medical devices.

Launching a mobile health application classified as a medical device will require the manufacturer of the application to register under FDA. Developers of the application must also be included in a list of medical devices provided by the FDA [21].

2. Medical devices that fall under category II and III requires approval by premarket notification.

Manufacturers must follow FDA’s notification 510(k) and provide risk classi-fication (See CLASS I-III) of their application to determine which class their application falls under.[21]

3. Quality system regulation

Manufacturers must follow quality regulations provided by the FDA. This means that manufacturers must formulate safe methods for how to proceed with design, producing and distribution. Subsequently, the application must be validated in order to be approved.[21]

4. Labelling the product.

Labelling of the application depending on which class it falls under must be followed. The labelling requirements are provided by FDA.[21]

5. Reporting of adverse advents.

All inconveniences to the users such as privacy exposure or injuries of the ap-plication before or after the launch of the apap-plication must be submitted as a written report to the FDA for scrutiny.[21]

If the application does not comply with regulations, e.g. not keeping design history, make changes without pre-market notification, or not maintaining documentation of changes made to the application, the FDA may issue a warning or even withdraw the application from the market altogether [28]. Not following appropriate requirement may also reduce reliability of an application, doctor’s may be unable to recommend the application to their patients as they can be held accountable if the application they recommend causes inconve-niences to the patient, especially if the application developers has not followed regulations.

(15)

In China a medical device is regulated through State Food and Drug Administration (SFDA) and all medical devices outside of China that wants to market their medical de-vice in china needs to undergo thorough testing in laboratory in order to live up to the standards provided by SFDA [21].

4.1.2 Development of Mobile Health Applications - Requirements

An outcome of software development may not always represent the expected product from a client perspective. While this may be blamed on an ever-growing complexity of technical solutions [29] the main question should be how were requirements set in the first place. Developing any type of mobile app, whether focused on eHealth or any other category requires setting the right expectations from the start of the project. Requirements are those expectations in often binding agreements between stakeholders and developers.

There are two main categories of requirements:

1. Quality (non-functional) - Fernandes & Machado [30] define quality requirements as a set of restrictions which the software should fulfill or consider. They are usu-ally created by analysts or stakeholders. When talking about a quality, a question of how quality of a software can be defined does not provide any clear or obvious answers. Nevertheless there are many known quality requirement models including one done by McCall et al. [31] where almost 60 different quality factors were gath-ered with an aim to narrow them into unambiguous categories. The result of the study by [31] are 11 different factors as seen in a Table 2. Together they repre-sent a guideline of important factors stakeholders and developers need to evaluate by considering of their importance to a project prior to setting quality requirements.

Product operation Product revision Product transition Usability Maintainability Reusability

Integrity Testability Portability Efficiency Flexibility Interoperability Correctness

Reliability

Table 1: Quality factors categorization

Bøegh explains [32] a standard ISO/IEC 25030 which represents a system model for identifying and specifying quality software requirements. A term ”fit-for-purpose” is explained as a situation where stakeholders aren’t interested how the system will be implemented - on a hardware, software or a manual level. Stakeholders are only in-terested whether their needs are fulfilled or not. This gives developers more freedom by delegating decisions into their hands but on the other hand it puts a pressure on a correct identification of requirements. The standard itself looks solely on setting

(16)

correct requirements, not processes surrounding it. It gives multiple useful guidelines such as defining stakeholder requirements and more importantly, defining software requirements in a form of measures that are assigned concrete and verifiable, usually numeric, targets.

Sommerville [33] on the other hand proposes a categorization of how different quality requirements can be classified into three types based on their attributes and relation to a project:

• Product Requirements - what should the outcome be. A quality of a soft-ware can be specified as mix of multiple factors such as: reliability, availability, usability, readability, testability etc.

• Organizational Requirements - how should the process of creating the out-come look like. This can be anything related to operational execution from which language needs to be used, which framework, what is a testing strategy etc.

• External Requirements - what other factors need to be considered and fol-lowed. While these may not be closely related to software development itself, requirements of laws and ethical standards to follow are still significant in their nature.

Product Requirements

As mentioned earlier, product requirements closely describe the quality of the soft-ware looking at technical aspects that are easily quantified and verified. They present a substantial core of expectations from a client and are hugely important. They are to a big extent dependent on a hardware where a software will be run, as in this case - a smartphone. Other considerations may include an operating system, network capabilities or back-end infrastructure.

Current smartphones are showing a clear trend of becoming more and more powerful with each new generation [34], usually unveiled every 12 months. Coupled with an innovative software application that can utilize this power lying in hands of a user, the only obstacle is figuring a way how to design all necessary requirements to reflect diversity of smartphones used throughout a target user group and bring an enjoyful experience to every user.

Organizational Requirements

Software development is infrequently done by one person, especially in the field of eHealth. With such complexity and workload, one person simply cannot keep up. However, the more people you include, the harder it is to ensure that essential elements such as transparency, development style, and communication are well ex-ecuted throughout the organization. One of the main challenges identified in this document is called development methods and it is related to organizational require-ments because choosing the right development method can pay off in a perfectly executed project.

(17)

External Requirements

A subsubsection 4.1.1 of this paper is dedicated to effects of regulation. Exter-nal requirements are tightly related to regulations in eHealth software development. Once again it is of a great importance to be aware of strict regulations in the industry and all duties and laws relevant to the development of a software.

Combined they make non-functional requirements which need to be understood by developers and stakeholders in order to deliver what is expected. Not setting them or not understanding them represents a significant threat to the success of a project. Also, often changing these requirements throughout the process brings delays and raised costs.

2. Functional requirements - ”a functional requirement defines a function of a sys-tem or its component, where a function is described as a specification of behavior between outputs and inputs”[35]. Such requirements are produced by architects and expert in order to meet very well defined goals. A part of functional requirements are detailed descriptions of expected behaviour - inputs and outputs of a system and a behavioral connection between them. They are much simpler to create and understood by developers as the outcome of their expected work is clear. Compared to non-functional requirements they are less business-critical in cases when they are not designed well or fulfilled. A user may find a way how to get what he or she wants even if functions of the app are not designed it that way. An example is a meditation app that allows users to meditate 30 minutes per session. That may not fulfill wishes of users if they want to meditate for different amount of time. Wrongly set functional requirements in this case are unfavorable but users can close a session at any point by themselves, or even start a new session if 30 minutes are not enough for them. Failing to fulfill quality requirements, on the other hand, such as relia-bility and availarelia-bility, in this example, by producing low-quality code with defects could result in app that is unstable and may crash during meditation and severely affecting user’s experience potentially leading to a loss of customers.

Sommerville [33] defines two quality indicators for functional requirements: a com-pleteness and a consistency. Such requirements should be complete, include all user requirements, and consistent in their nature by not allowing contradiction among several different requirements.

In conclusion, functional requirements can be easier to create and understand com-pared to a non-functional requirements as they don’t contain so many quality factors that often may be subjective to one’s opinion if they are not described in such a de-tail. Nevertheless, they have their own challenges one should be aware of.

A common problem between creating functional and quality requirements is the fact [36] they are often handled by different teams.

A success of designing both functional and quality requirements for eHealth mobile appli-cations is dependent on solid identification and understanding of inputs and outputs.

(18)

Setting up requirements in a software engineering is an uneasy task but with a solid understanding of a value behind requirements the task becomes crucial in order to de-velop a high-quality software. All parties involved - stakeholders, analysts, architects and developers need be on the same page and well-defined requirements make sure it is the case.

4.1.3 Development of Mobile Health Applications - Development methods Deciding and setting the most suitable development method for the given project is an essential part in a software development. It starts with an understanding of what value the right method can bring to a project. Each software development project is different. Requirements, as described in the section 3.4.2, put each project into a unique situation. Therefore, making claims for one method in a style of one-style-fits-all must not be the correct way how to approach selecting a method. Specific requirements demand a selection of an appropriate development approach in order to satisfy and fulfill given requirements. Different factors also apply. Business circumstances, previous history with different meth-ods and maybe the most impactful of them - the composition of the team itself. This section investigates unique characteristics of most known development methods with a goal of recognizing pros and cons of each method, enabling to understand their possible attribution towards overall success of a project.

Prior to investigating each method, let’s explain what such methods represent in the first place. They are part of specific approaches towards development containing a set of methods and best practices. There are two main approaches - an older waterfall and a recent, more dynamic agile development.

• Waterfall - a traditional approach where a process is divided into separate tasks and is based on a linear flow - meaning one task has to be completed before starting with a next task. Tasks are structured and well defined. They have their hierarchy what means an integrity of the process is taking a precedence over flexibility. Developers may considered this approach outdated and not adapted to the current world of software development but there is a good reason why waterfall has survived for so long since its introduction in 1970. Transparency, predictability and setting the goal in the beginning of the project. These key characteristics allow teams to be always aware of the current and the next step of the process.

• Agile - a popular approach that got introduced in 2001 by group of seventeen practitioners which were frustrated by current traditional approach of slow delivery windows and big lags between them. They published a proposal in their work ”Agile manifesto” [37]. The manifesto presents 4 core values and 12 principles that should guide a software process by putting a focus on developers and customers while not sacrificing a quality, on the contrary, putting a big focus on a quality - an important factor for overall user experience. An agile represents a rapidly evolving world of IT and provides solutions for effective, reactive and ultimately successful software development.

Abrahamsson et. al. did a study [38] of eight different agile methods. Following are the most used their brief description and characterization:

(19)

1. Extreme Programming - the process is split into 6 consecutive stages, each re-quiring a customer approval before proceeding to the next stage. Stages involved: exploration, planning, iterations to release, production, maintenance and lastly a death stage. It is characteristic for a close relation to a customer and short cycles. 2. Scrum - a subset of the agile that is without a doubt the most recognized one. Its

popularity keeps growing thanks to simplicity and understandability. The core of scrum are sprints. They are durations of time, usually a week or two weeks, for which the team put all of its focus on selected user story from a backlog. A user story describe requirements from a perspective of a user.

3. Feature Driven Development - FDD uses characteristics of different agile ap-proaches such as: iterative time frames, connection with a stakeholder and a user’s stories concept called features. The main focus are features. The framework is de-signed for planning and building a feature but can be used throughout of the whole development process. Its unique characteristic is a top-down decision making not frequently used by other agile frameworks.

With so many different approaches it is easy to get lost or be afraid from not selecting the best method. Whenever making a decision, taking time to think about what a project and more importantly - people in it, need will result in going for a method which will ”pay for itself” at the end. While choosing the right development method is a solid foundation of a project, the work does not stop there. An approach for how this method should be executed is another challenge to deal with. A development approach or strategy describes what should be put as a priority during development to achieve the best result possible. These strategies are well known in a software industry. Some are present from early stages of computing while others are recent entries created to provide solutions to emerging trends in software development.

• Test driven development (TDD)

a strategy that makes testing a priority during the process of a development. TDD is known for separating a workload into smaller iterations, usually described as units [39]. There are different approaches as to when should tests be created. Whether a test-first or a test-last. The test-first approach dictates to create tests prior to developing. This enables a team to focus on making tests work by implementing a feature that needs to succeed a test and to create a software that fulfills requirements given in a design phase.

The test-first approach will bring inefficiency if a project’s requirements are not clearly given prior to implementation phase or requirements are often changing. In such situations a last approach may be more suitable. It is an opposite of test-first. It dictates to create tests once the feature is near to completion or completed. This prevents from rewriting tests once requirements change but on the other hand it may cause to a product that does not meet the requirements and has to be modi-fied and re-implemented. There is also a human’s tendency to write tests in order to get their work verified while not implementing the ideal testing scenarios. There are clear advantages of TDD. A study [40] of 19 scientific publication discovered clear

(20)

benefits by exploring real-life scenarios of companies that transitioned into TDD and achieved a great reduction in a number of defects - a key quality parameter TDD aims to reduce. The study showed a reduction of 50 to 90 percent in a number of defects - software bugs that reach a production phase.

Despite the benefits of TDD, the result will always be eventually based on a de-termination and enforcement of creating and maintaining tests. Writing tests takes time and effort. Developers and companies have to comprehend a fact that TDD can greatly improve a quality of a software but only once the quality will be put in front of strict deadlines.

• Behavior Driven Development (BDD)

an enhancement to agile methodologies. It aims at bridging the gap between all parties involved - developers, testers, stakeholders etc. Software requirements may be often hard to understand for a person without a background in a computer sci-ence. BDD solves this by making description of a system in a human-readable form without going into specifics of technical implementation.

An approach like this has great benefits in eHealth where medical consultants may be a part of a team for designing requirements and testing of their execution. A de-velopment in eHealth should focus on a context and not in-depth technicalities[41]. In such scenario a BDD is a great way how to make sure the time is not wasted by constant translating user’s requirements and technical implementation.

BDD builds on iterative processes typical to Agile but recognizes priorities. Features with a high priority are executed first, another characteristics important in software development of eHealth application.

This section briefly summarized current methods available to provide an overview of dif-ferent options at one’s disposal. Development methods provide frameworks for executing a project as efficiently as possible. Every project is unique with its requirements, people and other countless factors involved but the goal always remains the same - to create a reliable and useful software. In eHealth where customers are often patients and the differ-ence between a good software and a software filled with defects or requirements that were not met may cause a significant problems to both a customer and a business.

(21)

4.1.4 Development of Mobile Health Applications - Security

For this section 12 primary sources (See matrice 42-53) from ScienceDirect, PubMed, IEEE Xplorer, Google scholar and Malmö university search panel were collected with keywords: privacy AND security AND apps AND smartphone AND mHealth AND development AND e-health to point out the main privacy and security concerns in mobile e-health and the biggest challenges that comes with implementing security and privacy protocols in mobile e-health applications.

Developers of mobile health applications may face many requirements and legal obligations when handling sensitive data that often occur in health applications. The requirements for putting a e-health application on the market can according to [42] be categorized as;

• iTunes - Developers must follow national or international laws concerning privacy and security policies.

• Google Play - Developers must ensure that sensitive user data is stored in a secure way. No legislations are however listed.

• Blackberry World - All sensitive user data must be encrypted by using the best-effort approach, meaning developers must do their best to ensure this is achieved. Developers must comply with all relevant laws.

• Windows Phone Store - If developers are collecting or transporting user data they must forward this information directly to the user that owns the right to the data. Developers must comply with all relevant laws.

[42] did also put up a guideline for how to create privacy and security safer health ap-plications which was based on having: providing information of the application, provide information of how patients data is being handled, collect as little information about a patient that is possible, get consent from user by providing detailed information on how their information will be used and why, explain ownership of the user data, delete all data of a patient if they remove the application, data storage should be kept encrypted and there should be analyses of weaknesses in the application to identify them early.

Though there are requirements for how privacy and security measures should be taken in regards to privacy and security laws, regulations are sometimes incapable of covering all privacy and security measures as the technological landscape is frequently changing [20]. Many application providers in the United States also express concerns of how to interpret federal legislation’s, an example is legislation’s provided by Health Insurance Portability and Accountability Act (HIPAA), a study conducted by [43] shows that providers state that they are unaware of how to interpret and follow the legislation’s as they are am-biguous. Therefore, following requirements provided by organizations can be difficult and being able to implement stern security protocols is not an easy task and in many scenarios, developers in mobile e-health applications fail to implement the most basic security for users and lack security for collecting user data [44], [45]. This is a main concern as in 2015 alone there were approximately over 250 million credential leaks and in the US alone they had over 111 million people who were hacked in relation to health [45].

(22)

[46] Explains that the reason why e-health applications have become a major challenge in regards to privacy and security is because of the following points: healthcare systems are are looking for cheaper ways to provide care for users, mobile explosion has led to an overflow of users of health application which means that it has become difficult to protect user data as technology is advancing too fast.

[47] Describes the main challenges in security and privacy of mobile e-health applications as being: Users of mobile health applications are more likely to be affected by threats such as side-channel attacks and privilege escalation attacks, leakage of information, stor-ing unencrypted data and use third party services to share data about health. [42] Gives a more general overview of the main issues that needs to be addressed, these are: Data security, access control, policy and confidentiality.

These challenges is something that was shown by [44] who ran a General Data Protection Regulation (GDPR) compliance test and a general security/privacy test on 20 of the most popular applications on Google Play that are related to medical or health. Table 2 shows the security and privacy concerns that had the highest percentage of failures on the general security test by [44].

Test Percentage

No reference to policy page 10 Transmit user password over GET 45 Transmitting data over HTTP 40 Transmitting geolocation to third parties 44 Storing user data locally 18 Sending data to third parties 50 Table 2: Quality factors categorization

[48] also conducted a qualitative study where 137 applications were identified from iOS store, Google play, society websites and telephone interviews. In their results they found out that the main concerns regarding the investigated applications was that 66 percent of the applications allowed sharing of health information through email and 12 percent allowed sharing of information through text messages. 46 percent of the applications also lacked privacy policy [48]. Similar to [48], [43] conducted a literature study on security and privacy concerns of applications related to e-health found that only 29 out of 154 android applications had a reference to a policy page. Table 3 shows a summarized collection of considerations when developing health application based on this literature study which also point to poor implementation in the applications as well as using third-party services insecurely.

(23)

Definition Description

Insecure data storage Storing unencrypted data

Insecure SSL protocol Data exchange between client-server without the use of SSL/TLS.

Poor Authorization/Authentication Health applications Sending user information in an inse-cure way.

Third party services Sharing health information with third parties can open up to potential leaks. Especially if using third-parties such as e-mail or text message service to share data. If using third-party for data analyzis it’s important to understand their security measurements.

Privacy policy Many applications does not carry a reference to policy pages. This means users are not well informed of their data usage.

Anonymization Many e-health application share Geolocation data, this data can be used for bad intents such as disclosing private information if not encrypted.

Table 3: Summarized collection of security concerns

Many of the findings in Table 2 goes against many of the General Data Protection Reg-ulation (GDPR). According to the study in [44] 11 out of 19 applications in their study provide privacy policy, this can be compared to GDPR Art. 7 (I) GDPR which states: be able to present that the data subject has consented to processing of their personal data [49]. According to Art. 7 (III) users also have the right to withdraw their consent [49] and according to study [44] only 7 out of the 19 applications had an option to withdraw consent. According to Art. 28 GDPR which states: provide complete confidentiality and that appropriate technical approaches are used to protect user data [49] can also raise concerns when data is exchanged using HTTP. Art. 7 (II) states that there should be a request for consent [49], only one of the applications in study [44] requested for consent. Not complying with the GDPR can lead to serious fines [28].

In many scenarios there may also be a lack of knowledge when it comes to privacy and security by the intended users of the medical device app, these can be medical students or physicians [50]. Although there can be diminished knowledge and involvement with privacy and security it is still many times concern for the users, in a survey provided by [44] 16 out of the 28 EU member states stated that they were concerned of how data is being collected within mobile health applications, thus the enforcement of GDPR. [51] designed an app for surgical rehabilitation and qualitative study including an evaluation of the app and the preponderance of clinics using the app expressed concerns over privacy and sharing of information. In a qualitative study by [52] who had 19 participants from the ages of 18 and above who were all frequent users of smartphone apps. In the study the participants explained their experience with health applications and one of the main concerns they had was how data was used and many were worried the data would get in the hands of third-parties which is something that can clearly be shown in Table 2 where 50 percent of the applications use third-parties.

(24)

A study by [53] who conducted a interview study with 256 participants shows that some-times the functionality of the application can outweigh the privacy and security concerns, however some participants mentioned that they are uncomfortable when providers store personal information. According to Table 2 it also shows that many users might not even be aware of how their data is used as 10 and 45 percent in the test by [44] and [48] had no reference to policy pages. Table 4 shows a summarized gathering of user concerns when it comes to privacy and security in e-health applications. The summarizing is based of three studies [53], [52], [51].

Preference Description

Data Storage Not knowing how the data that is collected is stored. Little control Users prefer having control over all app settings as

many users are concerned what the application is al-lowed to do.

Trust It should be clear why personal or sensitive data should be stored.

Sending data to third parties Concerns about third-parties having access to their data without their consent.

Table 4: Summarized collection of security concerns

It is essential for mobile health application designers to recognize privacy and security in their design but also ensure that adequate information is presented about the quality and safety of the application [25] which was missing in many of the applications. Bypass-ing this can cause not only legal matters but also reduced reliability to the provider of the health app. A study by [53] shows that users of e-health applications is an important factor for using a e-health application, despite privacy and security concerns.

(25)

4.2 Survey Research

In this chapter we will present the process and results from the survey. All survey ques-tions have been created based on the findings from the literature review, however several questions related to regulations and security have been formulated in a non-intrusive way due to sensitivity and secrecy that many company have to stand by.

4.2.1 Pilot Study

In order to formulate questions that companies are able to answer we decided to send out our first survey draft as a pilot study to see how relevant our questions are and if companies find them appropriate to use. We sent out our first draft to a company in Copenhagen who develops a medical app consisting of exercises targeted at muscle and joint areas. The company has less than ten employees and can be described as a small startup. It has thousands of users and is on the market since 2017. Respondents were a software developer and a CPO. The responses from employees will be addressed as Em-ployee 1 and EmEm-ployee 2.

Employee 1: ”I think you cover a lot of interesting and relevant topics with the multiple-choice questions. Maybe adding ’free text’ fields with more open questions could spread a more nuanced light on the topic”.

Employee 2: ”For feedback. I personally had some difficulties answering some of the questions. For example the one with programming technique. [...] Also this question is difficult for me to understand: ’Do you believe volatility of requirements during develop-ment present a challenge?’”.

4.2.2 Survey respondents

The survey includes responses from 14 people from various eHealth organizations with great experience in developing eHealth applications, as shown in Figure 2. Respective roles of all respondents can be found in Figure 3 as well. The collection of respondents and answers was done using LinkedIn, e-mailing organizations, and meeting directly with the company. The organizations were carefully scrutinized by ensuring the organization is in the eHealth sector, the respondents are appropriate to answer the survey questions provided and that the company has at least one or several developed eHealth applications to ensure the relevance to the research. Due to strict secrecy policies within the organiza-tions, names will not be mentioned in the research.

(26)

Figure 2: Respondents years of experience

4.2.3 Regulations

In section 4.1.1 of the regulatory literature review, several significant points were ad-dressed. We addressed that organizations may have difficulty following regulations, as they may vary depending on the country for which they are developed. The description of a medical device may also differ depending on the country and, the medical device may be categorized into several classes. The first question in regards to regulations is based on that a medical device can have different definitions depending on which country it is being developed in which we addressed in section 4.1.1. In the survey, we observed that eHealth organizations appear to have a moderately fair understanding of the definition of a medical device. In Figure 3, we observe that 14.3 percent of respondents report that they consider the definition of a medical device to be clear, while 7.1 percent and 21.4 percent state that they are unsure or do not find the definition to be clear. As many as 57.1 percent state that the definition is moderately clear.

(27)

Next question in Figure 4 is based on that a medical device can be divided into multiple different classes depending on which risk it exposes. Most of the organizations appeared to be well aware that a medical device can be classified into multiple classes, as many as 64.3 percent reported that they are aware of the classes a medical device can be classified into in both US and the EU.

Figure 4: Medical device classes.

Throughout the literature review in section 4.1.1, several findings point to an unclear in-terpretation of the regulations for a medical device as regulations may alternate depending on which country or class they belong to, hence the relevance of the question in Figure 5. The challenge of interpreting regulations is evident in this survey. According to Figure 5, as many as 78 percent of the respondents in the survey indicate that regulations are difficult to interpret, which indicates that e-Health regulations are a difficult part of the development phase.

Figure 5: Regulation interpretation.

An interesting observation in the study is that regulations may not simply be challenging to understand but regulations are also something that organizations are confronted with regularly which is an important question as directives from multiple countries contain

(28)

multiple different requirements. In Figure 6, we observe that only 7.1 percent of compa-nies never encounter regulations, while 35.7 percent frequently or continuously encounter them, additionally, 57.1 percent occasionally encounter regulations in the development phase.

Figure 6: Regulation occurrence

The question in Figure 7 is relevant to gain knowledge as to which approach companies take when they are faced with regulations in order to interpret the regulations appropri-ately.

Figure 7: Handling regulation

42.9 percent of the organizations replied that they use guidance documents when con-fronted with regulations and in total 57.1 percent of the organizations also reported that they use a combination of both guides and experts.

(29)

Referring to RQ1 in section 1.4, organizations in the e-health industry seem to be aware to some extent of the definition of a medical device, although it has several meanings depending on the country for which you are developing the application. It is, however, important for organization to have a clear understanding of the definition as failure to fully understand the definition of a medical device can result in being taken off the mar-ket if the health care application is misinterpreted [28]. Organizations also seem to be aware of the classes that a medical device can be divided into. The observation that can be made from Figure 6 and Figure 7 is that organizations seem to encounter regulations most of the time during development and according to Figure 6 when organizations en-counter these regulations, they face regulations that are difficult to interpret. Seeing as organisations turn to guidance documents and experts when confronted with regulations could be an indication that dealing with regulations can be a very time-consuming task for organizations in the e-Health field, as the organization may need to make an effort to find guidance documents regularly and as mentioned in section 4.1.1, regulations may vary from country to country or from class to class, which means that organizations may need to search for several different guides that correspond to the correct regulations depending on the country for which they are developing. Dealing with regulations can also be a very costly task for organizations, as many organizations report that they use a combination of guides and expert advisors to help them with the regulations that arise.

In regards to RQ2 in section 1,4, the findings in this section may be of great help to companies, especially companies who are unfamiliar or new to the industry of creating health application. The findings from the survey point to organisations not being fully aware of the definition of a medical device which can cause severe consequences such as being taken off the market [28]. From section 4.1.1 it was explained that, obtaining a better understanding of the definition can be done by understanding the use case of the application.Being aware of the medical device definition may also help with other difficul-ties, establishing the definition of a medical device may also help organisations to easily establish the class it belongs to which in turn, may help organisations to have a more clear picture of what regulations they will be confronted with which can be useful to prepare guidance documents in advance and possibly avoid hefty expenses of hiring in experts. Doing research of regulations could also lead to a less time-consuming development phase as regulations occur often during the development according to the survey result, hence why having knowledge of the regulations may help reduce the time taken to interpret the regulations and could help reduce usage of guidance documents or experts for each regulatory interpretation.

(30)

4.2.4 Requirements

Section 3.4.2 investigated the influence of requirements and concluded the fact require-ments were indeed presenting a challenge for software development of eHealth. The survey brought additional evidence from respondents and their work experience.

When asked about how often are requirements involved in respondent’s work not a single respondent answered never encountering them. Same percentage of 35.7 percent was for both ’occasionally’ and ’often’ options. Requirements being a constant part of one’s work was answered by 28.6 percent of respondents. This findings clearly confirm that require-ments are present everywhere and must be accepted as a part of software development. Obviously, one’s frequency of coming across of requirements in the development is influ-enced on a size of a company and selected development methods.

Figure 8: Frequency of requirements

To get an overview on whether requirements are well defined prior to development the survey asked respondents to answer simply yes or no. The purpose was to understand relations between setting clear requirements and possible effect of it on the overall process as explored in the literature review. The responses were equal for both options - 50/50. Once again, these answers can be highly dependent on the structure of development pro-cesses in companies. Nevertheless, it can still provide a valuable and quick overview on how is the current landscape in software development of eHealth mobile applications when it comes to defining requirements. As described earlier, development of medical devices, which mobile apps are part of, is a complicated and time-consuming process. Not having requirements well defined or understandable enough presents a serious challenge and can result in major negative impacts on a project.

(31)

Figure 9: Defining clear requirements

Requirements can be well defined and clear before starting a development but unexpected business changes or technical obstacles forcing requirements to be adjusted or even dis-carded and added may also strongly influence the overall process. To see how often these situations happen respondents were asked to choose one of possible frequency options. Once again there was no answer indicating situation of never changing. 50 percent marked occasional change while 28.6 percent choose ’often’. Finally, requirements being changed all the time was answered by 21.4 percent of respondents. Requirements do change, that is simply how life is - unpredictable things happen and various factors change. This ques-tion adds to already created evidence of requirements being dynamic and possibly quite problematic as a consequence of it.

Figure 10: Changing requirements during development

To really verify whether requirements play important role in eHealth development re-spondents were asked a question if they experienced major problems in their work after requirements have changed. These problems could be delays, financial loses, increased workload etc. Majority - 64.3 percent of answers indicated changing of requirements dur-ing development phase can actually lead to substantial risks as documented in the section 3.4.2.

(32)

Figure 11: Consequence of changing requirements

Finally, the last question in the section of survey focused on requirements asked respon-dents whether external requirements are affecting them. Under external requirements the survey means laws, ethical standards, non-disclosure agreements and others possible fac-tors that are not directly tied to typical business requirements even though there may be a certain overlap between them. Answers to this question were equally split for both ’yes’ and ’no’ questions. A possible explanation could be outsourcing handling of exter-nal requirement to other team members while software developers focus on developing a product.

Figure 12: Influence of external requirements

Analyzing data from this section of the survey in regards to answering RQ1 brought a solid evidence that requirements may significantly affect development process as discov-ered in section 3.4.2. Not only that, it can present answers for RQ2 as well. Requirements are without a doubt a crucial for projects in software development of mobile eHealth ap-plications. They present a way of setting correct project goals and making sure everyone

(33)

involved understands them. Nevertheless, as seen in this data analysis they also entail a risk. If not set properly - vague, missing relevant details and being hard-to under-stand, they can result in delays, additional costs, more workload etc. Based on answers from respondents it is clear that requirements are sometimes not clear or change during development. They are always present in one way or another. No respondent marked never encountering requirements or them never being changed during development. The fact that every person in the survey is working in a team that changes requirements at least once during development is something to think about. While changing requirements during development does not necessarily mean the project is badly-managed and will be unsuccessful but it proposes a question whether requirements can’t be created better in a first place. External requirements can be outsourced to project managers or even non-developers. There are solid frameworks for creating and managing requirements [32]. Developers and their project managers should be aware of these tools which can greatly reduce obstacles encountered during development.

4.2.5 Development methods

A section 3.4.3 explored characteristics of different development methods and how can they bring benefits when chosen correctly. A development method and approach are set in the beginning and provide different frameworks for the best utilization of resources. The survey’s goal was to identify current trends in software development of eHealth mo-bile applications in terms of development methods and selected approaches. Respondents were asked to characterize their current development methods and given a chance to rate their methods.

When asked about which development method were respondents using in their work there was a clear winner. As seen in Figure 13 - agile methodology has been very popular in soft-ware development and overwhelming number of respondents do confirm this for eHealth development as well. Only 7.1 percent responded ’Waterfall’ plus another 7.1 percent chose to use custom option and write ”As agile as possible but some external integrations

require more of a waterfall approach”. Interestingly, one answer indicated they use ”Chaos disguised as agile” suggesting agile not being correctly implemented.

(34)

Figure 13: Development method

The next question then asked respondents to rate their current method in a sense of believing whether they are utilizing the best method available or not. A figure 14 states 64.3 percent responded ’yes’ while other 35.7 percent said ’no’. This shows there is a way for improvement and that maybe agile is not always the right tool for the job.

Figure 14: Opinion on selected method

Responses in figure 15 to selected development approach brought yet another clear winner, even though answer ’Combination of multiple choices’ isn’t as clear. When choosing from test-driven, data-driven, behavior-driven approach or their combinations more than two thirds of respondents chose the mentioned combination of multiple approaches. Combining different approaches and utilizing their benefits shouldn’t incorporate any major threats if those approaches and their unique characteristics are understood. In the section 3.4.3 they have been well-documented and the evidence shows eHealth companies are aware of different approaches with their particular aspects.

(35)

Figure 15: Development approaches

To see the level of testing in a software development of eHealth respondents were asked to rate the current level of test coverage. Benefits of testing described in the section 3.4.3 are apparently understood by companies as every answer selected chose at least small level of code coverage. 21.4 percent chose ’Few tests’ and the majority - 71.4 percent selected ’Comfortable level of coverage’. A room for improvement is obvious from the number of people that answered ’Very high level of coverage’, only 7.1 percent. There are obvious drawbacks to having a high level of code covered by automated tests. Or better said, there is only one drawback - a need to dedicate resources ( time and effort) in order to execute testing strategy. Once again, there is a need to highlight the fact that having no tests in software development of eHealth is not acceptable and companies are embracing that.

Challenges in software development of mobile apps in e-health

Challenges in software development of mobile apps in e-health

Abstract

Contents

1

Introduction

2 Research Methodology

3

Literature Review

4

Result & Analysis