Bachelor Thesis Master's Programme in Computer Science, 300 Credits

Bachelor Thesis Master's Programme in Computer Science, 300 credits

EnterMedic, an E-health application for telemonitoring and health status feedback

Development of a mobile healthcare tool and research about its usage in the field of E-health

Computer Science and Engineering, 15 credits

Halmstad 2020-06-07 Sebastian Larsson, Leif Sulaiman HALMSTAD UNIVERSITY

Acknowledgements

We want to start our thesis by thanking our supervisor Taha Khan who helped us immensely by making sure we got off on the right foot, providing us with knowledge about engineering combined with healthcare and answering any questions we had.

Also, we would like to thank Cyrus Daneshmir, Roger Bergstrand and the development team of Entergate for helping us when we encountered issues, supplying us with endless amounts of coffee, for playing table tennis with us during their afternoon break and for keeping in touch with us during the rough times of the COVID19 outbreak.

Regards, Sebastian Larsson & Leif Sulaiman Halmstad, Sweden 2020-05-10

i ii Abstract

Digital tools are being implemented in every area of society. Digital healthcare, or E-health, is an area that is increasing in popularity with various mobile applications and online services available. Entergate, a company based in Halmstad, has developed a service called EnterMedic. It is a cloud service that collects data from patients through online questionnaires. Once submitted, the service can directly forward data from these questionnaires to patient journals. EnterMedic also helps researchers with data to develop effective work methods in healthcare. The service was however limited to the web. This thesis consists of developing a mobile version of the service as it is more convenient to use compared to a web-based one and research contributing to what E-health applications can be used for. Interactivity is a desired feature for applications. EnterMedic will provide the users with feedback after questionnaire submissions, to help them track their state of health.

Sammanfattning

Digitala verktyg blir implementerade i alla omraden˚ av samhallet.¨ Digital halsov¨ ard,˚ eller E-halsa,¨ ar¨ ett omrade˚ som okar¨ i popularitet¨ med olika mobiltelefon applikationer och online tjanster¨ tillangliga.¨ Entergate, ett foretag¨ baserat i Halmstad, har utvecklat en tjanst¨ som heter EnterMedic. Det ar¨ en moln-tjanst¨ som samlar data fran˚ patienter genom online formular.¨ Nar¨ dessa skickas in kan tjansten¨ direkt vidarebefodra datan fran˚ formularen¨ till patient journaler. EnterMedic hjalper¨ aven¨ forskare med data for¨ att utveckla mer effek- tiva arbetsmetoder inom halsov¨ arden.˚ Tjansten¨ ar¨ dock begransad¨ till webben. Det har¨ examensarbetet bestar˚ av att utveckla en mobil version av tjansten¨ da˚ det ar¨ mer bekvamt¨ att anvanda¨ jamf¨ ort¨ med en webb-baserad tjanst¨ och forskning som bidrar till vad E-halsa¨ applikationer kan anvandas¨ for.¨ Interaktivitet ar¨ en onskad¨ funktion for¨ applikationer. En- terMedic kommer forse¨ anvandare¨ med aterkoppling˚ efter att ett formular¨ har skickats in, som i sin tur hjalper¨ dem folja¨ sitt halsotillst¨ and.˚

Keywords: Telemonitoring, E-health, Telehealth, Self Assessment Questionnaire, Digital Healthcare Tool, Healthcare Mobile Application, Cross-Platform

iii iv Contents

1 Introduction 1 1.1 How EnterMedic works ...... 1 1.2 Purpose ...... 1 1.3 Problem speciﬁcation ...... 2 1.4 Contributions ...... 3 1.5 Application speciﬁcations ...... 4

2 Background and theory 5 2.1 General ...... 5 2.2 Explanation of keywords ...... 5 2.2.1 Platform ...... 5 2.2.2 Cloud service ...... 6 2.2.3 Self assessment questionnaire ...... 6 2.2.4 Standard disease rating scales ...... 6 2.2.5 Telemonitoring ...... 6 2.2.6 HTTP and web requests ...... 7 2.2.7 GDPR ...... 7 2.3 API ...... 8 2.3.1 EnterMedic API ...... 8

3 Method 11 3.1 Hardware and Software Used ...... 11 3.1.1 Postman ...... 11 3.1.2 BankID ...... 11 3.1.3 Xamarin ...... 12 3.1.4 DB Browser for SQLite ...... 12 3.2 Method description ...... 13 3.2.1 Questionnaires ...... 13 3.2.2 Feedback ...... 13 3.2.3 Local database ...... 13 3.2.4 Web request and authentication ...... 14 3.2.5 Notiﬁcations ...... 15 3.2.6 User Interface ...... 16 3.2.7 Testing ...... 17 3.2.8 Expenses & resources ...... 17 3.3 Result analysis ...... 17

4 Results 19

5 Discussion 23 5.1 Ethics ...... 23 5.2 Issues encountered ...... 23 5.2.1 Hardware faults ...... 23 5.2.2 Development tools ...... 24 5.2.3 The impact of a global pandemic ...... 24 5.2.4 Focus group ...... 24 5.3 Usage ...... 25

v 5.4 Improvements and plausible extra-features ...... 26 5.4.1 External connections ...... 26 5.4.2 Feedback improvements ...... 27 5.4.3 Notiﬁcation improvements ...... 27 5.4.4 Alternative login ...... 27

6 Conclusion 29 6.1 Experience ...... 29 6.2 Future implementations ...... 29

vi 1 Introduction

This bachelor’s thesis is done in cooperation with Entergate, a company based in Halm- stad, Sweden. Entergate has a web-based E-health application called EnterMedic. It is a cloud service that makes it possible to directly send data to patient journals and has been used daily since 2016 by Kristianstad University, Region Varmland¨ , and Region Halland. EnterMedic was co-developed with CKF (Centrum for¨ Klinisk Forskning i Vaster¨ as˚ ). CKF works a substantial amount with questionnaires within healthcare and aims to, while collecting information for research, help develop effective work methods in healthcare. En- terMedic encourages patient-integration and better communication between the patient and the care-taker which makes the experience better for both parties.

1.1 How EnterMedic works

The service is divided into three types of authorizations: admins, units, and respondents. An admin could be a medical board of a county. A part of what they do is to create questionnaires for patients to answer. The admins send it out to units which could be hospitals or health centers in the county. These are then provided to the respondents, who are patients, to ﬁll out and submit back to their attending doctor in the unit. This makes it easier for the doctor to diagnose a patient. It is very important to note that this is not a tool that can diagnose, but instead eases the diagnostic process and pre-visit perception of the patient for the doctor.

1.2 Purpose

The purpose of the project is to create an E-health application to assist the healthcare system and the doctors by acting as a tool of telemonitoring patients, with the hope that it will play a part in decreasing the queues of healthcare in the future.

It is important to note that this thesis was written during the outbreak of COVID-19. As a consequence of this pandemic, telemonitoring increases in importance as it can prevent risk- groups, such as elderly or individuals with an underlying illness or compromised immune system[1], from contracting the disease by visiting hospitals and other healthcare centers.

The process of E-health can be summarized: E-health applications collect data using self- assessment questionnaires submitted by the patient. Then, from the server, transmits a disease proﬁle of the patient as a quantiﬁed form to a doctor who uses a standard clinical rating scale to make a clinical assessment[2].

The EnterMedic application is to be considered a telemonitoring application since the patient’s state of health can be reviewed remotely through questionnaires. It is important that the UI (User Interface) is appealing and simple to use so that less technical people, such as elderly or disabled individuals, can understand it.

1 1.3 Problem speciﬁcation

As awareness for mental illness increases, more people feel conﬁdent in seeking aid. This is visible, not least among the younger population. From 2016 to 2018 there was a 24% increase in visits to BUP (Barn- och ungdomspsykiatrin), a Swedish institute helping chil- dren and teenagers with their mental issues[3]. While doctors and nurses hired were also increased during this time, it was only by 9% and 3% respectively. However, the number of psychologists decreased by nearly 9%, making the total staff decrease in size since they represent the largest portion of the staff. There is a clear pattern here, which is that an increasing number of people need help but the availability is decreasing.

The thesis was written during the global pandemic of COVID-19. In Sweden, the national protocol regarding preparations for a pandemic does not directly implement a telemonitoring system through a mobile application[4]. A study dating back to 2015 states that telemonitoring systems show great potential during pandemic outbreaks, but require more research to be applied fully in situations similar to the COVID-19 pandemic[5].

Digitization has helped many areas of society, such as shopping for food through internet services, but also healthcare. There is a rise in the use of medical applications such as Kry and Min Doktor which had an increase in digital visits of 500% in one year[6]. This points to that patients are willing to get help through an application as an alternative to physical help when possible. Figure 1 shows that a relatively high percentage of the Swedish population already use digital tools existing in the healthcare industry. A noticeable deviation is the elder population in comparison to the population as a whole. They tend to not use these tools as much as the younger population.

Figure 1: Percentage of the Swedish population (16+ years) using the healthcare system’s digital tools (blue) and healthcare apps instead of a normal visit (red), the year 2019[7]. The leftmost bars display the whole population.

2 Certain cases regarding BUP and the regular healthcare system can be time-sensitive. A patient must get to see a doctor or healthcare worker on time. Studies have shown that in 2019 approximately 1 in 3 patients seeking care within BUP had to wait for more than 30 days[8], at which point according to Sweden’s national care-guarantee, everyone who was seeking help should have gotten it. Sweden strives to reach this goal regarding BUP and the rest of its healthcare system and simply hiring more personnel does not seem to be enough.

1.4 Contributions

This project contributes the following to the ﬁeld of E-health:

• A more convenient and simple version of an already existing E-health service in the form of a functioning application for mobile devices. It is created with the inten- tion and purpose of easing data-collection of patients for doctors, enable doctors to telemonitor patients, and reduce healthcare queues.

• Information about how E-health applications can be used, especially in a situation of a global pandemic (high relevancy as the COVID-19 outbreak was ongoing at the time of the development).

• Information about future features likely to be relevant for E-health applications, as technology in areas such as machine learning and artiﬁcial intelligence advances.

• A simple algorithm that categorizes questions from questionnaires and generalizes feedback for users.

3 1.5 Application speciﬁcations

The development of the EnterMedic application for mobile devices follows these speciﬁca- tions:

• One way to login, using BankID, with a consent form to sign on the ﬁrst login where new users agree to personal data being stored (GDPR).

• Questionnaires should be one of three types: single choice, multiple-choice, and open text. This excludes all other types of questions that the EnterMedic API supports.

• Full implementation of support for push notiﬁcations for Android platform only. The iOS platform has many requirements that are beyond development control and have to be met by Entergate. If they do meet the requirements within the time-frame of the project, push notiﬁcations for iOS will not be implemented.

• The app is to implement a smart feedback system by showing a graphical representa- tion of how a patient has answered speciﬁc questions from different questionnaires, tracking the disease by displaying the answers from different dates. Doctors should also be able to send messages which are visible to the patient through the app.

• The entire application is to be coded using Xamarin Forms with Visual Studio IDE.

• Xamarin Forms supports cross-platform development for Android, iOS, and UWP (Universal Windows Platform)[9] with additional support for some more platforms of which the status is not completely stable. The EnterMedic app will only support iOS and Android, not UWP and the other platforms.

Furthermore, the actual calculations of different disease rating scales with the corresponding questionnaire are not done through the app as this is purely medical and not relevant in the area of engineering. Should this be requested, it is to be implemented on the doctor-side of the service.

4 2 Background and theory

This section will explain some of the general knowledge needed for a project along with an in-depth analysis of working with an API.

2.1 General

Currently, EnterMedic is used by researchers to create better treatments for chronic illnesses such as depression, insomnia, asthma, pain, anxiety, and ADHD[10]. All these illnesses can be traced by subjective ratings where the patient ﬁlls out a self-assessment questionnaire. When a patient submits a questionnaire, a rating can be calculated on how far the illness has progressed. The accuracy of the method is not deﬁnitive. For example, if a patient gets a high rating on a depression scale, it does not necessarily mean said person has depression. A questionnaire can yield false-positive results. Further research has to be conducted if the method is to be used to fully diagnose a patient. Collecting self-assessed data from a patient could still be useful to a doctor, who can use it to draw conclusions before a visit by a patient.

When the task is to develop a cross-platform mobile application there are a couple of choices of integrated development environments (IDE’s), development languages, and frameworks. After some research, it seemed that there were two superior choices: React Na- tive[11], which is a JavaScript framework owned by Facebook and Xamarin Forms[12] which is an open-source UI framework based on their .NET framework Xamarin and is owned by Microsoft. Though React Native is very quick when converting source code to native elements, Xamarin Forms has platform-specific hardware acceleration. Hardware acceleration, in computing terms, is the act of offloading certain computing tasks onto al- ternate hardware to run an application more efficiently. A native element is built using a specific programming language. Native iOS is programmed using Swift or Objective-C, and native Android is programmed using Java. Xamarin Forms utilizes C# and raw XAML coding as opposed to JavaScript. The reason Xamarin Forms was chosen is because of its cross-platform capabilities.

2.2 Explanation of keywords

2.2.1 Platform

When mentioning platforms in this report, it is referring to different mobile platforms. There are several platforms but the largest ones are iOS and Android. As of January 2020 iOS and Android make up 99.19% of the market worldwide[13] and in Sweden, it is 99.79% of the market[14].

5 2.2.2 Cloud service

A cloud service is provided by a cloud computing company through their server, as opposed to through a customers own on-premises server. These services are designed to be both scalable and easy and are fully managed by the provider.

2.2.3 Self assessment questionnaire

The act of self-assessment is an act in which a person looks at him- or herself to come to some conclusion. In a self-assessment questionnaire, a person answers questions about themselves to enhance their understanding of their current situation regarding the topic of the questionnaire. In the case of EnterMedic, a patient answers the questionnaire to get a medical assessment of their health. With the data from the questionnaires, a doctor can more easily track the disease.

2.2.4 Standard disease rating scales

Many diseases have standard rating scales. These have different names depending on the disease they are rating. ADHD, for example, has many scales for different ages and groups of people and one of these scales is Barkley Adult ADHD Rating Scale-IV(BAARS-IV)[15]. ADHD is one of the diseases this project will help diagnose. The scales are used to more easily give a proper diagnosis of its respective disease. This could be displayed to a user as feedback but is currently not used by the application coded for the project.

2.2.5 Telemonitoring

Collecting data from a patient remotely is called telemonitoring. The data gets sent to either a patient supervisor or a doctor who then processes the information.

6 2.2.6 HTTP and web requests

HTTP, short for ’hypertext transfer protocol’, is a communication protocol originally only intended for raw data transfer. This version is referred to as HTTP/0.9 and only had one type of request: GET[16]. In 1996 a new version of HTTP was introduced with the name HTTP/1.0[17]. It introduced new request methods, including HEAD and POST in addition to the already existing method GET. The requests also contained metadata which among other things included status codes. These are familiar to anyone who has encountered a 404 error while trying to access a website. The status code 404 simply means that the site either does not exist or it has been hidden for security reasons. Another common status code is 200, which simply means OK and that the request was successful.

HTTP/1.1, a version of HTTP still widely used today, was introduced in 1999[18]. It improved on HTTP/1.0 by adding more request types, including, but not limited to, PUT and DELETE. It also increased performance and extended the number of status codes.

2.2.7 GDPR

GDPR[19], The General Data Protection Regulation, is a regulation passed on the 14th of April 2016 and went into effect on the 25th of May 2018. Its purpose is to protect the data of individuals. For companies to abide by the regulation they must show they have a lawful reason for holding the data and prove that it is stored securely. Because this project deals with a lot of sensitive and personal information, GDPR has to be abode if the project is to be published.

Examples of relevant clauses from GDPR:

• Article 5 clause 1b: ”Personal data shall be collected for speciﬁed, explicit and legit- imate purposes and not further processed in a manner that is incompatible with those purposes; further processing for archiving purposes in the public interest, scientiﬁc or historical research purposes or statistical purposes shall, in accordance with Ar- ticle 89(1), not be considered to be incompatible with the initial purposes (‘purpose limitation’);”[20]

• Article 5 clause 1f: ”Personal data shall be processed in a manner that ensures ap- propriate security of the personal data, including protection against unauthorized or unlawful processing and against accidental loss, destruction or damage, using appro- priate technical or organisational measures (‘integrity and conﬁdentiality’)”[20]

7 2.3 API

Essentially, an API is a computing interface that can interact between multiple software nodes. It deﬁnes what calls and/or requests that can be made, how to structure them, and what format/content type to use[21].

An API can be used in various ways. The way it was used for the service EnterMedic is called a web API. These have interfaces where the application and the server can communicate. These usually contain the communication protocol HTTP and content type which is usually in XML or JSON format. [22]

There are more types of APIs such as libraries, operating systems, and remote APIs which are not relevant to the thesis.

2.3.1 EnterMedic API

For the EnterMedic application to work, the data submitted when a patient ﬁlls out a questionnaire has to be sent to the EnterMedic database. This is done by using web requests to the web-oriented EnterMedic API. Note that the application never communicates with the EnterMedic database directly as shown in ﬁgure 2.

Figure 2: General overview of the communication between application and API

The same principle applies to authentication. The method of authentication chosen for the project was BankID, which has an API of its own. The application requests the EnterMedic API to initiate a login process, which in turn requests it from the BankID API.

8 A web request to the EnterMedic API follows a predeﬁned set of rules. The content type is always in JSON format and headers are required to include a key. The data to be sent is called a body, which follows the content type format restriction. These requests also have to be routed to the correct method using a URL. To simplify, a made-up sample of a web request in pseudo code is shown in ﬁgure 3 below:

The web request below can be interpreted as an attempt at an HTTP POST web request creating a taco, using the made-up TacoAPI. The EnterMedic API functions similarly but is not shown for security reasons. An HTTP GET web request does not require a body. The data returned, however, will also be in JSON format and look like the body in the web request above.

URL: http://TacoAPI/Feature/Method/OptionalData Headers: { "key": "SampleKey", "ExtraHeader": "Sample" }

Body: { "Meat": "Beef", "Sauce": "Hot", "Portions": 10, "Salads": [ { "Salad_1" = "Tomato" },

{ "Salad_2" = "Corn" } ] }

Figure 3: A sample of a web request in pseudo code following the JSON format.

9 10 3 Method

In this section, it is explained what hardware and software were used, how different elements were implemented, and how the result can be analyzed.

3.1 Hardware and Software Used

Here, all software and hardware used for the project are explained in terms of what it is and how it was implemented.

3.1.1 Postman

To retrieve the information about patients, EnterMedic’s existing API was used. Before any web requests could be implemented into the application itself, they needed to be tested to see what kind of information each one returned. The web requests are done through HTTP using GET and POST commands, while also including certain information and security tokens. There is a client tool called Postman which can be used to test API’s and send HTTP web requests.[23] Postman allows the user to include both tokens and information in the web requests. When a web request has been made the user will receive a response code and typically a JSON formated response containing information. The response code tells the user what might have gone wrong with a web request, e.g. wrong formatting or insufﬁcient access privileges.

3.1.2 BankID

Privacy is necessary when working with medical information. It is very important that the user (in the case of The EnterMedic app, a patient) feels comfortable using the service and trusts that the information provided will not be misused. To ensure the user of privacy two specifications were made. The first one of these two is the mode of logging in to the app. In general, the Swedish population is positive towards the chosen method, which is BankID[24]. They also feel like it is a secure service. In 2019, Internetstiftelsen conducted a large report, mapping internet behaviors of Swedish citizens. They found that 84% of the Swedish population (over 16) uses BankID and that 94% of internet users in Sweden use BankID[25]. This means a potential user of the EnterMedic app will have no problem logging in. The second specification that was made to ensure security and privacy is made following GDPR (General Data Protection Regulation). With GDPR the user can feel safe that his or her data will not be given to anyone unauthorized.

11 3.1.3 Xamarin

The project followed a standard app development method, using Xamarin C#. It is a cross- platform implementation of CLI (Common Language Infrastructure) and Common Lan- guage Speciﬁcations, also known as Microsoft.NET. Development of Xamarin applications is done through Microsoft Visual Studio IDE (Integrated Development Environment) and in this project, both the 2017 and the 2019 versions of Visual Studio were used. Visual Studio has GitHub[26] implementation, which is the version-control software of choice for the EnterMedic application. Using GitHub, it is possible to divide work in the project and test different versions of the app.

Xamarin exists as a cross-platform implementation called Xamarin Forms. It is also possible to implement both iOS and Android natively with Xamarin iOS and Xamarin Android respectively. This project, however, was developed using Xamarin Forms. While cross- platform development is good from a time and effort perspective, it is notably slower than native implementation. A survey from 2019 shows that 62% of respondents believed that ”[o]verall loss in performance compared to native apps” was a common issue with cross- platform mobile development[27]. On the same question, the respondents answered that UX and UI both were sub-optimal in cross-platform development tools. The speciﬁcations of the project originally intended for both iOS and Android devices to be supported and therefore Xamarin Forms was the optimal choice, considering time was a limiting factor.

3.1.4 DB Browser for SQLite

For the feedback part of the application, a local database was needed to save the feedback- related data generated after the completion of a questionnaire. For this, DB Browser for SQLite (DB4S) was used. It is an open-source tool that allows the developer to create the database, tables, and indexes[28]. It also enables the developer to display the data from all existing tables, to check that it has been inserted correctly into the database ﬁle.

12 3.2 Method description

3.2.1 Questionnaires

The most substantial feature of the EnterMedic application is that patients can answer questionnaires provided by their attending. A web request fetches all questionnaires available to the user once they have logged in. Pressing one questionnaire in the designated menu will send another web request which fetches all questions and alternatives along with their types (single-answer, multiple-answer, and open text). To display the questionnaire to the patient, a layout is created for every question, containing their alternatives. The layout also contains a button that is activated when the requirement for the question type has been ful- ﬁlled, such as choosing your answer for the single answer questions or selecting at least one answer for multiple answer questions. Pressing this button will automatically scroll the screen to the next question. It is also possible to scroll normally. Once all questions have been answered, the questionnaire submission button located at the end of the questionnaire is enabled. Pressing this will, through a web request, post the questionnaire along with the patient’s answers to the EnterMedic API.

3.2.2 Feedback

A feedback system is a way for the application to interact with the user. The system pro- vides the patient with data that tracks their health. Once a questionnaire has been submitted by the patient, an algorithm ﬁnds a suitable category for each question. These questions are changed to the category name and inserted into the feedback table in the local database along with their answers. These categories are then fetched from the database and shown to the user as a graph in percentile form, sorted by date. Some questions are not suited to be used in the feedback system, as they do not ﬁt any subcategory, and are not stored in the database.

It is important to point out that, for now, only single-answer questions are implemented to use for the feedback system. This system can be improved immensely, and will be discussed further under the section ’Discussion’.

3.2.3 Local database

A local database is created for every device once the EnterMedic application is installed. The application will open a read and writable ﬁle of the database which can then be manipulated. The database ﬁle is an SQLite database[29]. It was created using DB Browser for SQLite which allows one to create tables, attributes, and schemes for an SQLite database[28]. The database is used exclusively for the smart feedback system.

Since the database connection package provided by Xamarin supports database queries, it was utilized for inserting and fetching data.

13 3.2.4 Web request and authentication

Communication to and from the EnterMedic API is done using web requests. These consist of data that is to be sent for storage and a web URL (Uniform Resource Location) or web address to which the data will be sent and manipulated before the insertion to the Enter- Medic database. There are more parameters such as what ﬁle standard (Content-Type) the data is structured after, an authorization token to determine if the current instance is eligi- ble to send or retrieve data at the current time and a key for the API which is used in every request.

In majority, all parameters except for the data to be sent are inserted as headers, and the data is called a body. To ease the communication with the API a general web request class was created, called MakeRequest. This class uses the .NET library Newtonsoft, a ”high performance JSON framework for .NET”, which can take strings, objects, and lists or arrays of objects to serialize or de-serialize them to a JSON ﬁle structure[30]. There are generally many types of requests, however, the EnterMedic API uses two: Post and Get HTTP requests. Post requests often require the data in the form of a body to post the data in the database. Get requests do not require a body and are used to retrieve data from the database as opposed to posting data.

Authentication is necessary when all data in and out of the application is personal. The way of authenticating with the application was chosen to be BankID. The back-end of this type of authentication is based on web requests. When authenticating, the application communicates with the EnterMedic API which forwards the data to the BankID API. To start authenticating through BankID, the login process has to be initialized through a web request. This returns a session id and a token which is used to open the BankID application on the user’s device. Once the BankID application has been launched, a continuous web request is established to determine whether the user has logged in or not. Continuous web requests using time intervals are called polls. The web request is polled every second, which returns the status of the login. Once the user has logged in, the polling continues to check if the session is still valid or not using the session id integer[31]. For security reasons, the login time is limited by the main EnterMedic server.

There are additional web requests used throughout the application, such as retrieving or posting questionnaires and their answers. These web requests will not be explained further for security and integrity reasons.

14 3.2.5 Notiﬁcations

Push notifications were first implemented into the app without the EnterMedic API since they needed to update their system to use an FCM (Firebase Cloud Messaging) token instead of the old system which used a GCM (Google Cloud Messaging) token. As soon as the system started using FCM, the project implemented notifications using the EnterMedic API. Both these tokens essentially do the same thing but FCM is for the newer system which uses firebase to send out the notifications. FCM was the token type used in the application and it is a unique identifier for the device. Along with the device token, a device type is required. If the device is an Android it is represented as a ”1” and a ”0” if it is an iOS device. To get the device token and type, a NuGet package had to be included in the project. NuGet is a package manager for Visual Studio which makes it easy to add, remove or update external libraries. The NuGet package needed for Firebase is called Xa- marin.Firebase.Messaging[32]. The first time an application is launched with this package included, the method OnNewToken is called, taking an FCM token as a parameter. This token has to be pushed to the EnterMedic database if it is to be used. The token will change from time to time for security reasons so it is important to update the database when this happens.

Android devices using version 26 or later needs a Notification channel. These are for cus- tomizing the notifications[33]. All notifications that pass through the same channel will have the same features. One of the most notable features of this is the Channel Importance Levels. The importance of the channel used for the notifications in this application was set to urgent, which will make a sound and appear as a heads-up notification when a notification is received. If the device uses an Android version older than 26, no channel is needed and will not be created.

Once a notification has gone through the system described in Figure 4, the notification is handled by FirebaseMessagingSer- vice which is responsible for handling the notifications. A subclass of FirebaseMessagingService was needed and overrides a method called OnMessageReceived. This method gets called each time a notification arrives and takes the notification as an argument. Af- ter this information is retrieved the notification gets displayed. On- NewToken is located in the same subclass and is also an override of Figure 4: Notification lifecycle its original method.

15 3.2.6 User Interface

The EnterMedic mobile application applies different navigation types. The base of the application was built on hierarchical navigation. Xamarin Forms has two separate stacks for its navigation, both of which are last-in, first-out (LIFO). The first stack handles page pushes and pops and the second one handles modal pushes and pops. The difference between a modal and a normal page is how they appear. A page is simply navigated to, but a modal is loaded on top of an existing page and encourages the user to perform some self- contained task or cancel it. The modal stack, however, was not used in this project, as no feature required it. After logging in, the primary navigation form is through a TabbedPage. A TabbedPage can be navigated by either swiping left, right, or pressing the corresponding tab which is located either on the top or bottom of the page. A TabbedPage is easily navigable and can display a lot of information at once. The alternative would have been a MasterDetailPage, which displays the tabs on an extendable menu, shown in Figure 5. The benefit of a MasterDetailPage is that it is very clear where each tab leads, but it is not as seamless as a TabbedPage.

Figure 5: Xamarin navigation types

A few coloring schemes were considered before deciding that the app should be bright as a base, and use Entergate’s signature blue color as a complement. Along with this, a dark grey color was included for text and other details. The colors and their corresponding hexadecimal values are shown in ﬁgure 6.

Figure 6: Primary colors of the EnterMedic app

16 Another aspect of the design regards what is known as a WebView in Xamarin Forms. A Webview displays content written with HTML and CSS and can display both linked web- sites and HTML strings[34]. The EnterMedic application needed to implement Webview twice, one for a home page, which displays personalized information to the user, and one for a contact page, which contains contact information relevant to the patient. Both of these WebViews get their content using the EnterMedic API, which returns the users personalized information as an HTML string. The HTML code is generated on the EnterMedic website using a tool of theirs. For security reasons, pressing a URL in the Webview will not redirect the patient.

3.2.7 Testing

Testing the EnterMedic application was split into two parts. The ﬁrst one consists of veri- fying that the web requests behave as expected and that all outcomes are covered to avoid application crashes. Primarily, the application Postman was used to see the outcomes of different web requests. The class MakeRequest swallows exceptions and returns the HTTP status code for the requests so the rest of the app can adapt accordingly. The class has been tested for all different requests used and produces the expected values every time.

The EnterMedic application contains many classes. For the app to work as intended these have to work properly with a minimal amount of errors. These classes have been tested using various methods ranging from something as trivial as command line prints to program comprehension and code review.

3.2.8 Expenses & resources

Entergate provided a workspace at their ofﬁce. For development, private PC’s were brought. They were able to provide an iMac for debugging iOS versions of the app. They also pay for the servers on which the data is stored. This was not a new expense for them as the servers are already used for the web version of EnterMedic.

3.3 Result analysis

The results produced by the application and its implementation will be studied to see whether the speciﬁcations were met or not. In the case of an uncompleted speciﬁcation, it is important to get an understanding of why this was the outcome. External factors will be considered when making the assessments.

With the project completed, it will be possible to look back on the development to judge whether or not the choice of development tool was correct. Xamarin Forms speciﬁcally can be compared to other programming environments and frameworks. It will also be possible to judge the performance of individual methods and functions. Likely there will be other implementation alternatives that are suited better for certain cases.

17 18 4 Results

The EnterMedic application has been developed and is ready to be published as a functional E-health application in the Google Play Store. A patient can submit a questionnaire and get instant graphical feedback after it has been submitted. To retrieve a patient’s data the application needs to communicate with the EnterMedic database through their API. The API has been fully integrated for all parts of the application requiring it. The requests have been run several times each and work as long as there are no server errors or internet connection issues. The requests were extensively tested through Postman in which it was made sure that each request would return an HTTP status code of 200 in every case in which no external problems are encountered. The user navigation process is described in the ﬂow chart in ﬁgure 7.

Figure 7: Flow chart for the EnterMedic application

19 A user can log in to the app using the service BankID. The login will only be successful if the user has been added remotely by his or her unit (healthcare station). The left side of Figure 8 shows what the login page looks like. If the button is pressed the user will be redirected to the BankID app if it is installed. If not the user will be sent to the Google Play store where they can install BankID. Once the user has authorized the EnterMedic application they will be logged in. The first time the user signs in they will first be redirected to a GDPR consent form after BankID authorization. The user needs to accept if he or she wishes to use the app. The form is shown on the right side of figure 8. Accepting the GDPR form will enable the user to access the application, and disables the GDPR form from being shown on subsequent logins. This is done by inserting the GDPR form status into the database and retrieving it every time a user logs in. Logging in will display the main navigation. Here, three tabs are shown on the bottom of the screen. These tabs are: the questionnaire and feedback tab, a home tab, and a notifications tab. Pressing a tab will show the corresponding page. The home page is always shown directly after logging in.

Figure 8: Login page on the left side and consent form on the right

20 If a user wishes to respond to a questionnaire he or she presses the corresponding questionnaire title on the questionnaire list page as seen on the leftmost device in figure 9. When the user does this they get redirected to the questionnaire itself. The center device in figure 7 shows what a typical single-answer question can look like. When a selection is made it is indicated by a highlighted label and an arrow bouncing up and down to urge the user to move on to the next question. Once the questionnaire has been completed and the user has clicked send, the page on the rightmost side of figure 9 gets shown briefly before redirecting to the page where the user first clicked on the questionnaire.

Figure 9: From Left to right; questionnaire selection page, questionnaire sample, response conﬁrmation page

Submitting a questionnaire will save the feedback data to the database. The results of what the user has answered are shown in the feedback tab. The user can navigate to the feedback tab by clicking the leftmost tab on the main navigation page as seen in the flow chart in figure 7. Similar questions get grouped to form one graph. The graphs are sorted by date and displayed as shown in figure 10. The graphs are displayed in a CarouselView, meaning if the user swipes to either side, a different graph will be displayed if there is more than one.

Figure 10: Feedback page

21 Push notifications have been tested and work on Android devices. These are shown showing a banner on the users screen while not using the application. They also get displayed in a list as can been seen in figure 11. If a user clicks on a notification and it has a questionnaire attached to it, the user will be redirected to that questionnaire and can respond to it right away. After the user submits the questionnaire, the application returns to the notification page. The time since the notification was sent can be seen on the top right corner of each notification. As of now, there is no way of telling if a notification has been previously viewed or opened. Neither is it possible to see if there is a questionnaire attached to the notification.

Notifications are sent in one of two ways. Both use the EnterMedic web interface. They can be either scheduled or sent right away and the one sending the notification, usually someone from a unit, can choose to just send a message or attach a questionnaire to it. Figure 11: Doctors should be able to send a one-way notification message to Notification page the patient and that is entirely possible. As of now, it can only be a short message as it will not fit within the notification box in figure 11 otherwise. The notification is also limited to 160 characters.

Two more pages are part of the application, which are the contact page and home page. These vary drastically in appearance as they are made through the EnterMedic web service. The home page contains information about the unit of which the user belongs. There can be current information displayed here, or it can be general information. The contact page is supposed to contain contact information to the healthcare unit, the user’s doctor, or any other healthcare advisor, whichever is relevant to the user. To Access the contact page, the user clicks on the contact icon at the top right corner, present on every tab of the main navigation.

22 5 Discussion

In this section, the different parts of the project will be discussed. The project meets most requirements and integrates all desired features. The one speciﬁcation that has not been met is the iOS implementation, which will be discussed in section 5.2.1.

5.1 Ethics

When handling medical information it is of utmost importance that the data is being treated carefully and with high security. When the project was initiated with Entergate it became clear that they treat their customers’ data with high conﬁdentiality and security.

The rapid improvements in technology have affected many areas of society and healthcare is one of them. When writing this report there is a growing interest in telemonitoring and remote healthcare. As mentioned in section 1.3, digital health centers have highly increased in popularity. With the increase in demand, the guidelines also need to become more clear. Making proﬁts off a patient’s medical data is highly unethical but is now illegal unless consented to by the person in question. The data handled by the EnterMedic app is mostly done through a secure API handled by the team at Entergate. The only data stored locally is data that cannot be traced back to a speciﬁc person and it is also protected by operating system level security. The EnterMedic application does not collect any data which is not strictly necessary and does not track the user at any capacity.

5.2 Issues encountered

Since the start of the project, some issues have been encountered. These have implicitly changed the state of some speciﬁcations. Also, the project relied signiﬁcantly more on the state of external sources than initially speculated.

5.2.1 Hardware faults

Some hardware issues concerning the iOS part of development have occurred. To debug the application for iOS devices a MAC is needed, which was not available during development. The company had MAC computers, but the software needed was not downloadable on the them as they were slightly outdated. To not slow down the entire project, all the focus has shifted into finishing the application on Android. Theoretically, the application should work on iOS even now. However, there are some Android-specific files/methods which the iOS device will not run. This includes, for example, the auto-launching of the BankID application for authentication.

23 5.2.2 Development tools

Given that the application only will be available for Android devices, the development environment is not optimal. Xamarin Forms is quite weak when it comes to creating platform- speciﬁc features and a better option would have been Xamarin.Android, which is native. Technically the application should for the most part work for iOS, but since there is no way to launch the application on an iOS device as of now, it is impossible to know.

With a development tool such as React Native, it would be possible to write code that can instantly be tested on both Android and iOS devices. Using a tool called Expo[35], made for React Native, it is possible to deploy an app instantly (and wireless) if there is an internet connection available. Whenever an app is to be deployed using Xamarin Forms, on the other hand, it needs to download the application before it can be launched. Using Xamarin Forms has not been all bad, as future development can be done which utilizes the current code. Expanding the application to also work for iOS would not take a signiﬁcant amount of time, likely less than a month.

5.2.3 The impact of a global pandemic

Shortly after the development stage of the project (in the middle of March 2020), the outbreak of the pandemic COVID-19[36] resulted in safety actions both from Halmstad Uni- versity and Entergate. The development was no longer to continue in the ofﬁce space provided by the company. What this meant to the project was that the iOS testing permanently stopped since the hardware to execute it was now inaccessible. The hardware mentioned consisted of computers running Mac OS X with Xcode 11 and Microsoft Visual Studio software installed, iPhones to debug the application, and the charging cable connecting them. As the equipment was not owned by either of the developers, it was not possible to debug the iOS part of the project.

The situation made it more difﬁcult to communicate issues encountered with the API. Be- fore the lockout, having an API issue was dealt with by simply asking them in person. After the lockout, both parties resorted to communicating by e-mail, which slowed the process of getting help signiﬁcantly.

5.2.4 Focus group

The original plan was to have a focus group provided by Halsoteknikcentrum¨ Halland but due to recommendations by the government, this had to be canceled. The idea was to meet up with the focus group in person and let them use the app to see if everything is easily understandable. They would also have given their thoughts and ideas which would have been valuable information. Having them use the application remotely would not have yielded the same results. As a substitute, an Art Director was hired by Entergate to give design feedback and suggestions.

24 5.3 Usage

The application and its functionality can be fully used for telemonitoring a patient, tracking their disease. If a questionnaire associated with a standard disease rating scale is provided to ﬁll out, it can be calculated on the doctor-end of the service. An API web request should be liable for providing the data if the standard disease rating scale is to be displayed to the patient since it involves both parties (doctor and patient).

As the global pandemic COVID-19 unfolds, the usage of the application can be considered to be in its prime time. Providing a questionnaire to individuals nation-wide through the application is possible. Should this be initiated, the EnterMedic service can map and trace the spread nationally by simply implementing an algorithm and enabling the collection of location data of patients once the questionnaire has been submitted. As it turns out, this is not only a pair of students’ thoughts. In Sweden, an application doing exactly this has been created by Lund University. Its name is COVID Symptom Tracker, created with the purpose to:

• Calculate what parts of Sweden the risk of contracting the disease is high

• Find what factors increase the risk of getting very ill and how the risk is affected by possible underlying diseases

• Calculate how quickly the disease is spreading in different parts of the nation

It is important to note that the COVID Symptom Tracker application does not diagnose patients, it is merely a tool of telemonitoring and research[37].

COVID Symptom Tracker and the previously stated EnterMedic implementation during pandemics is one of many implementations that can be applied during a pandemic outbreak. A study from 2015, also mentioned in 1.3, conceptualized ﬁve different implementations for similar situations that have been or could be applied in the future. One of the applications that have been used was during the 2014 Ebola virus outbreak in Africa, where they telemonitored asymptomatic contacts of diseased individuals.

25 The EnterMedic mobile application can assist in making assessments of teenagers seeking aid at BUP. The most common diagnosis given to people after seeking help at BUP is anxiety, depression, ADHD, trauma-related condition, and an autism spectrum disorder[38]. Their respective percentage of occurrences are stated in table 1. Using the EnterMedic application to assist in diagnosing each of these conditions is possible. If a patient was to answer a questionnaire before the ﬁrst meeting, it is likely that the meeting with a healthcare provider or psychologist would take a shorter amount of time, as the healthcare provider or psychologist is more prepared. This also helps reduce the overall queue time as the healthcare provider does not have to spend as much time at each meeting. As false negatives are possible, no one should be rejected an initial meeting based solely on the questionnaire.

Condition Percentage Anxiety 35 Depression 31 ADHD 21 Trauma related conditions 19 Autism spectrum disorder 13

Table 1: The most common diagnoses among teenagers with concluded contact with BUP in 2014

Another use for the application is telemonitoring elderly individuals who are home-based. As statistics show, elders are more likely to get a heart attack[39]. Should they live at their own residence, it is vital to monitor their health. Some cases cannot be prevented by telemonitoring, as some cases of heart issues can appear suddenly. Not all cases are sudden, an example of this is heart infarction which is when blood ﬂow is partially restricted through the heart. A symptom for this is chest pain[40]. As an individual may not always know that this situation is critical, they might not call emergency services. Should an elder be telemonitored by answering a questionnaire every day, such pain ought to be acted on by a healthcare provider analyzing the questionnaires. In turn, emergency services can be called to the elder’s home immediately.

5.4 Improvements and plausible extra-features

In this section, improvements of existing features and additions of new features are discussed.

5.4.1 External connections

During the initiation of the project, there was an idea to connect external health applications to EnterMedic. The idea was scrapped as it was deemed unnecessary since a doctor’s response to a questionnaire is more valid than a subjective judgment of one’s health through an app such as a step counter.

26 5.4.2 Feedback improvements

Currently, the feedback only displays data from question groups, such as sleep habits, to the patient. It could also be relevant to display the current standard disease rating scale depending on what illness the patient is suffering from.

5.4.3 Notiﬁcation improvements

The notifications in its current form function as intended and in accordance with the project specification. However, they could be improved in a couple of ways. The first and most important feature would be to add a way to see whether a notification has been viewed and/or interacted with. As of now, a user has no way of telling, except by their memory. The implementation of this was initiated but the deadline was too close to finish it. All that is missing is an API PUT web request which tells the EnterMedic database that the notification has been viewed by using a boolean value. Through an ObservableCollection, which is a list that observes changes to its members in real-time, this would then be displayed to the user in real-time.

Another useful feature for the notiﬁcations would be deleting them. This feature existed at one point during the development but a change in design led to the temporary removal of it. The work needed before implementing it would be deciding the user interaction required to delete the notiﬁcation.

5.4.4 Alternative login

The login method using BankID is a secure way to connect to the app and it is something people are already used to using. The problem that might occur is when a person lacks a BankID. The user is then unable to connect to the application. The application will mostly be aimed at the younger population, of which 98,7% has a BankID[41]. However, the application would not suffer from implementing an alternative method of logging in. This could be done through a username and a password, or personal number and a password. Giving the user more choice can often be beneﬁcial.

27 28 6 Conclusion

The project resulted in a fully functioning E-health application which can be used for telemonitoring and ease data collection for doctors pre- and post-visit. This fulﬁlls the goal, and will hopefully decrease the healthcare queues in Sweden. The application could improve with more research on how to use digital tools for healthcare.

As shown in section 4, the structure of the application is simple, navigate to the desired tab by swiping or pressing on it and then execute an action such as reading relevant information or answering a survey. The simplicity is of high importance, as telemonitoring elderly with a residency at home, as stated in section 5.3, is a desired feature. Considering that the goal of simplicity is fulﬁlled, the application is ready for the implementation of telemonitoring elderly individuals.

6.1 Experience

Working on this project has led to useful insights into how development is conducted over a moderately long period. Hurdles are to be expected and should be accounted for when planning. The worst thing that could happen is that the project is ahead of schedule. Staying consistent is necessary to keep focus. Having ﬁxed deadlines sets clear goals and will drive the project forward.

6.2 Future implementations

The EnterMedic mobile application has laid an important foundation on which more com- plex features can be implemented. A machine learning program could take data from other apps such as the step counter or pulse meter from a smartwatch. The data could be used and processed to give the user information about their behavior. An increase in heart rate from a user with heart problems could send out a signal to a connected healthcare worker and warn them in time.

As the foundation was made so that extra features could be implemented easily, the application can easily adapt to crises such as the current pandemic. Applying the functionality of the COVID Symptom Tracker to EnterMedic would not take a signiﬁcant amount of time.

29 30 References

[1] Information till riskgrupper om COVID-19. 2020. URL: https://www.folkhalsomyndigheten. se/smittskydd- beredskap/utbrott/aktuella- utbrott/covid- 19/rad- och-information-till-riskgrupper/ (visited on 05/09/2020). [2] Taha Khan. Phd, Postdoctoral Research Fellow. [3] Uppdrag Psykisk Halsa.¨ Psykiatrin i siffror 2018 – Barn- och ungdomspsykiatri. 2018. [4] Planering for¨ beredskap mot pandemisk inﬂuensa. 2020. URL: https : / / www . folkhalsomyndigheten.se/contentassets/7d7d21797e264e72972629c35ba0fae1/ planering-beredskap-pandemisk-influensa-15106.pdf (visited on 05/09/2020). [5] Robin Ohannessian. “Telemedicine: Potential applications in epidemic situations”. In: European Research in Telemedicine / La Recherche Europeenne´ en Tel´ em´ edecine´ 4 (Oct. 2015), pp. 95–98. DOI: 10.1016/j.eurtel.2015.08.002. [6] Vivianne Sprengel, Dagens medicin. “Digitala vardcentraler˚ blir allt popularare¨ bland storstadsbor”. In: (2018). URL: https://www.dagensmedicin.se/artiklar/ 2018/01/15/digitala- vardcentraler- blir- allt- popularare- bland- storstadsbor/ (visited on 05/05/2020). [7] Internetstiftelsen. Svenskarna och internet 2019, p. 41. [8] Sveriges Kommuner och Regioner. Startade utredningar och behandlingar inom 30 dagar i barn- och ungdomspsykiatri. 2020. URL: https://vardenisiffror.se/ (visited on 05/06/2020). [9] Xamarin Forms platforms. URL: https : / / docs . microsoft . com / en - us / xamarin/get-started/supported-platforms?tabs=windows. [10] Entermedic. URL: https://entergate.se/products/entermedic/. [11] React Native. URL: https://reactnative.dev/ (visited on 05/08/2020). [12] Xamarin Forms. URL: https://docs.microsoft.com/en-us/xamarin/get- started/what-is-xamarin-forms. [13] statCounter. Mobile Operating System Market Share Worldwide. URL: https:// gs . statcounter . com / os - market - share / mobile / worldwide (visited on 03/06/2020). [14] statCounter. Mobile Operating System Market Share Sweden. URL: https://gs. statcounter.com/os-market-share/mobile/sweden (visited on 03/06/2020). [15] Russel A. Barkley. Barkley Adult ADHD Rating Scale-IV (BAARS-IV). 2011. [16] The Original HTTP as deﬁned in 1991. URL: https://www.w3.org/Protocols/ HTTP/AsImplemented.html (visited on 05/01/2020). [17] Tim Berners-Lee, Roy T. Fielding, and Henrik Frystyk Nielsen. Hypertext Transfer Protocol – HTTP/1.0. RFC 1945. RFC Editor, May 1996. URL: http://www.rfc- editor.org/rfc/rfc1945.txt (visited on 05/08/2020). [18] Roy T. Fielding et al. Hypertext Transfer Protocol – HTTP/1.1. RFC 2616. RFC Editor, June 1999. URL: http : / / www . rfc - editor . org / rfc / rfc2616 . txt (visited on 05/08/2020).

31 [19] GDPR. URL: https://gdpr.eu/tag/gdpr/ (visited on 05/08/2020). [20] Official GDPR document. 2016. URL: https://eur- lex.europa.eu/legal- content/EN-SV/TXT/?uri=CELEX:32016R0679&from=SV (visited on 05/09/2020). [21] Sharon Fisher. InfoWorld. Google Books, 1989. [22] DSI Principal Architect Charu Rudrakshi et al. API-FICATION. Core Building Block of the Digital Enterprise. HCL Tech, 2014. [23] Postman. URL: https://www.postman.com (visited on 03/06/2020). [24] Andreas Dahlin Sandered, Max Engberg, and Hano Sabir. Mobilt BankID: En veten- skaplig studie om attityder kopplat till den tekniska losningen¨ . 2019. [25] Internetstiftelsen. Svenskarna och internet 2019, p. 53. [26] Github. URL: https://github.com/ (visited on 05/08/2020). [27] Andreas Biørn-Hansen et al. “An Empirical Study of Cross-Platform Mobile De- velopment in Industry”. en. In: Wireless Communications and Mobile Computing (2019). DOI: https://doi.org/10.1155/2019/5743892. URL: https://www. hindawi.com/journals/wcmc/2019/5743892/ (visited on 04/28/2020). [28] DB Browser for SQLite. URL: https://sqlitebrowser.org/ (visited on 05/05/2020). [29] SQLite. URL: https://www.sqlite.org/index.html (visited on 05/05/2020). [30] Newtonsoft. URL: https://www.w3.org/Protocols/HTTP/AsImplemented. html (visited on 05/04/2020). [31] BankID. URL: https://www.newtonsoft.com/json (visited on 05/04/2020). [32] Xamarin.Firebase.Messaging. URL: https://www.nuget.org/packages/Xamarin. Firebase.Messaging/ (visited on 05/02/2020). [33] Notification channels. URL: https : / / developer . android . com / training / notify-user/channels (visited on 05/03/2020). [34] Xamarin Forms WebView. URL: https://docs.microsoft.com/en-us/xamarin/ xamarin-forms/user-interface/webview?tabs=macos. [35] Expo. URL: https://expo.io/ (visited on 05/08/2020). [36] Folkhalsomyndigheten¨ . 2020. URL: https://www.folkhalsomyndigheten.se/ smittskydd-beredskap/utbrott/aktuella-utbrott/covid-19/bekraftade- fall-i-sverige/ (visited on 05/07/2020). [37] Sara Liedholm. COVID Symptom Tracker. 2020. URL: https : / / www . lu . se / article / appen - covid - symptom - tracker - lanseras - i - sverige - och - forskarna-behover-din-hjalp (visited on 05/07/2020). [38] Fakta om BUP - Tema tonaringar˚ . URL: https://www.bup.se/globalassets/ bilder/om-bup/publicerat/fakta-om-bup/rapport_bup_slutgiltig.pdf (visited on 05/10/2020). [39] Sveriges officiella statistik Socialstyrelsen. Statistik om hjartinfarkter¨ . 2018. URL: https://www.socialstyrelsen.se/globalassets/sharepoint-dokument/ artikelkatalog/statistik/2019-12-6490.pdf (visited on 05/10/2020). [40] What Are the Signs and Symptoms of Coronary Heart Disease? 2014. URL: https: //web.archive.org/web/20150224034615/http://www.nhlbi.nih.gov/ health/health-topics/topics/cad/signs (visited on 05/09/2020).

32 [41] BankID users. 2020. URL: https : / / www . bankid . com / om - oss / statistik (visited on 05/07/2020).

33 Studying for a master's degree in computer science at Halmstad University. My interests are chess (beating Leif by 32-23 so far this year) and reading. My favorite author is Haruki Murakami.

Currently studying the master's programme in computer engineering. I like to program applications and play chess in my spare time. I also enjoy tinkering with my car, but this has not gone well lately.

PO Box 823, SE-301 18 Halmstad Phone: +35 46 16 71 00 E-mail: [email protected] www.hh.se