Secure Handling of Electronic Health Records for ...1229377/FULLTEXT01.pdf · Medical record systems are used whenever caregiving is practiced. The medical records serve an important

IN DEGREE PROJECT COMPUTER SCIENCE AND ENGINEERING,SECOND CYCLE, 30 CREDITS

, STOCKHOLM SWEDEN 2018

Secure Handling of Electronic Health Records for Telemedicine Applications

FREDRIK LJUNG

KTH ROYAL INSTITUTE OF TECHNOLOGYSCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE

Secure Handling of ElectronicHealth Records forTelemedicine Applications

FREDRIK LJUNG

Master in Computer ScienceDate: June 29, 2018Supervisor: Sonja BucheggerExaminer: Mads DamSwedish title: Säker hantering av elektroniska patientjournalerSchool of Computer Science and Communication

iii

Abstract

Medical record systems are used whenever caregiving is practiced.The medical records serve an important role in establishing patientsafety. It is not possible to prevent honest-but-curious doctors fromaccessing records since it is legally required to allow doctors to ac-cess health records for emergency cases. However, it is possible tolog accesses to records and mitigate malicious behaviour through ratelimiting. Nevertheless, many of the records systems today are lackinggood authentication, logging and auditing and existing proposals forsecuring medical records systems focus on the context of multiple dif-ferent healthcare providers. In this thesis, an architecture for an elec-tronic health records system for a telemedicine provider is designed.The architecture is based on several requirements from both the le-gal perspective and general security conventions, but also from a doc-tor’s perspective. Unlike the legal and general security conventionsperspective, doctor requirements are more functionality and usabilityconcerns rather than security concerns. The architecture is evaluatedbased on two main threat models and one secondary threat model,i.e. insider adversaries. Almost all requirements are satisfied by thesolution design, but the two main threat models can not be entirelymitigated. It is found that confidentiality can be violated by the twomain threat models, but the impact is heavily limited through auditlogging and rate limiting.

iv

Sammanfattning

Journalsystem är en central del inom vården och patientjournaler haren stor roll i att uppnå bra patientsäkerhet. Det är inte möjligt att för-hindra läkare från att läsa särskilda journaler eftersom läkare behö-ver tillgång till journaler vid nödsituationer. Däremot går det att loggaläkarnas handlingar och begränsa ondsint beteende. Trots det saknarmånga av dagens journalsystem bra metoder för autentisering, logg-ning och granskning. Befintliga förslag på att säkra journalsystemenfokuserar på sammanhang där flera olika vårdgivare är involverade.I den här rapporten presenteras en arkitektur för ett patientjournalsy-stem till en telemedicinsk leverantör. Arkitekturen utgår från flerta-let krav baserade på både ett legalt perspektiv och generella säker-hetskonventioner, men även läkares perspektiv. Arkitekturen är eva-luerad baserat på två huvudsakliga hotmodeller och en sekundär hot-modell. Arkitekturen uppfyller så gott som alla krav, men de två hu-vudsakliga hotmodellerna kan inte mitigeras helt och hållet. De tvåhuvudsakliga hotmodellerna kan bryta sekretessen, men genom flö-desbegränsning och granskning av loggar begränsas påverkan.

v

Acknowledgements

I would like to thank Kry for giving me the opportunity to do my the-sis project with them and especially my supervisor at Kry, Calle Svens-son, for his continuous great feedback and suggestions throughout thewhole project.

I would also like to thank my supervisor at KTH, Sonja Buchegger,for her help and advice from start to finish.

Finally I would like to thank my family and friends for their greatsupport.

Contents

1 Introduction 11.1 Research Question . . . . . . . . . . . . . . . . . . . . . . 21.2 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Background 72.1 Electronic Health Record . . . . . . . . . . . . . . . . . . . 72.2 EHR System . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 EHR Users . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4 Laws & Regulations . . . . . . . . . . . . . . . . . . . . . . 9

2.4.1 Sammanhållen journalföring & NPÖ . . . . . . . . 92.4.2 Patientdatalagen . . . . . . . . . . . . . . . . . . . 102.4.3 General Data Protection Regulation . . . . . . . . 10

2.5 Access control . . . . . . . . . . . . . . . . . . . . . . . . . 102.5.1 Identification and Authentication . . . . . . . . . 102.5.2 Authorization . . . . . . . . . . . . . . . . . . . . . 11

2.6 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.6.1 AES . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.6.2 RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.7 End-to-End Encryption . . . . . . . . . . . . . . . . . . . . 132.7.1 Hyker . . . . . . . . . . . . . . . . . . . . . . . . . 132.7.2 Signal . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.8 Cryptographic Anchor . . . . . . . . . . . . . . . . . . . . 142.8.1 Hardware Security Module . . . . . . . . . . . . . 14

2.9 Audit Logging . . . . . . . . . . . . . . . . . . . . . . . . . 142.9.1 Emergency Situations . . . . . . . . . . . . . . . . 15

2.10 Formal Specification . . . . . . . . . . . . . . . . . . . . . 15

vi

CONTENTS vii

3 Requirements 163.1 Law Requirements . . . . . . . . . . . . . . . . . . . . . . 16

3.1.1 Literature . . . . . . . . . . . . . . . . . . . . . . . 163.1.2 Interview . . . . . . . . . . . . . . . . . . . . . . . 18

3.2 Security Requirements . . . . . . . . . . . . . . . . . . . . 193.2.1 The Parkerian Hexad . . . . . . . . . . . . . . . . . 203.2.2 ISO/IEC 27001 . . . . . . . . . . . . . . . . . . . . 21

3.3 Doctor Requirements . . . . . . . . . . . . . . . . . . . . . 213.4 Summary of Requirements . . . . . . . . . . . . . . . . . . 223.5 Adversarial Models . . . . . . . . . . . . . . . . . . . . . . 233.6 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 Architecture Proposals 264.1 Architecture 1 . . . . . . . . . . . . . . . . . . . . . . . . . 264.2 Architecture 2 . . . . . . . . . . . . . . . . . . . . . . . . . 274.3 Architecture 3 . . . . . . . . . . . . . . . . . . . . . . . . . 284.4 Architecture 4 . . . . . . . . . . . . . . . . . . . . . . . . . 29

5 Solution Design 305.1 High-level Design . . . . . . . . . . . . . . . . . . . . . . . 30

5.1.1 Cryptographic Functions . . . . . . . . . . . . . . 315.2 Workflows/Operations . . . . . . . . . . . . . . . . . . . . 32

5.2.1 Read Record . . . . . . . . . . . . . . . . . . . . . . 325.2.2 Write Record . . . . . . . . . . . . . . . . . . . . . 335.2.3 Add New Patient . . . . . . . . . . . . . . . . . . . 355.2.4 Direct Access to Database or Log . . . . . . . . . . 36

5.3 Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.4 Specification . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.4.1 Event-B . . . . . . . . . . . . . . . . . . . . . . . . 395.4.2 Formal Modelling with Event-B: Read Record . . 40

6 Security Analysis 446.1 Must-have Requirements . . . . . . . . . . . . . . . . . . . 44

6.1.1 Fully achievable requirements . . . . . . . . . . . 456.1.2 Partially Achievable Requirements . . . . . . . . . 48

6.2 Nice-to-have Requirements . . . . . . . . . . . . . . . . . 526.2.1 Classification and Policy . . . . . . . . . . . . . . . 526.2.2 Secure Key Management and Log Tamper Resis-

tance . . . . . . . . . . . . . . . . . . . . . . . . . . 53

viii CONTENTS

7 Conclusion 557.1 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

7.1.1 Ethics and sustainability . . . . . . . . . . . . . . . 567.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 567.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Bibliography 59

A Interview questions 65

CONTENTS ix

Acronyms

EHR Electronic Health Record

EMR Electronic Medical Record

PHR Personal Health Record

RBAC Role Based Access Control

PDL Patientdatalagen

GDPR General Data Protection Regulation

NPÖ Nationell Patientöversikt

CWE Common Weakness Enumeration

AES Advanced Encryption Standard

RSA Rivest Shamir Adleman

2FA Two Factor Authentication

CRUD Create, Read, Update, Delete

ACL Access Control List

NIST National Institute of Standard and Technology

PKCS Public Key Cryptographic Standards

E2EE End-to-End Encryption

HSM Hardware Security Module

BTG Break The Glass

PdS Patient-data-Service

AWS Amazon Web Services

ECDHE Elliptic-curce Diffie-Hellman Ephemeral

GCM Galois/Counter Mode

PSS Probabilistic Signature Scheme

x CONTENTS

OCSP Online Certificate Status Protocol

PKI Public Key Infrastructure

KDS Key Distribution System

RNG Random Number Generator

Chapter 1

Introduction

Within healthcare doctors need to perform record keeping of their pa-tients. In the beginning this was done by paper, today it is done elec-tronically and most medical record systems are adapted to fit the op-erations of traditional physical medical centres. Lately, however, wehave seen an uprise in digitalization of healthcare. For example, Ap-ple announced that they want to increase the accessibility of medicalinformation by introducing a new functionality where it will be pos-sible to store your personal records in your iPhone [43]. In Sweden,primary healthcare applications like Kry and Min Doktor are growingin popularity [9]. Letting people interact with doctors and psychol-ogists or access their health records via their smartphones opens upgreat possibilities in regards to accessibility. Healthcare applicationslike these have the potential of reaching out to hundreds of thousandsof patients. On the other hand it has incurred security and privacy is-sues. The nonprofit organisation privacy rights clearinghouse reportsthat in January 2018 there have been 15 security breaches disclosingover 390.000 medical records in the US alone. Since 2005, the numberof disclosed records in the US is over 228 million [13]. Since patientdata is so sensitive there are several laws and regulations caregiversneed to abide by. In Sweden there is the Patient Data Act (Patient-datalagen, PDL) and the regulations set up by The National Board ofHealth and Welfare (Socialstyrelsen). For countries in the EuropeanUnion the General Data Protection Regulation (GDPR) will come intoeffect in May 2018. Having such a large amount of patients and thou-sands of doctors involved with tight regulations and possibly devas-tating consequences requires a more modern way of handling medical

1

2 CHAPTER 1. INTRODUCTION

records.This thesis will investigate if a secure medical records system can

be built for a telemedicine based healthcare provider. Relevant laws,regulations and security conventions will be identified and from themrequirements set up. Under three different insider threat models asystem architecture aiming to mitigate them while still fulfilling therequirements will be proposed.

1.1 Research Question

Can an architecture which satisfies suitable security criteria for atelemedicine based electronic health records system with multiplestakeholders practically be implemented?

1.2 Objective

The desired outcome of the thesis is to first identify and classify a setof requirements to be able to define and judge the security level of theelectronic health record (EHR) system. The requirements are to be rea-sonably well arranged based on current regulations and laws, but alsobased on established security conventions. Additionally, observationsand experience from the doctors at Kry will be taken into account. Thedoctors viewpoint will mostly be requirements in the context of func-tionality and usability in a telemedicine environment. Based on theserequirements, an architecture aiming to fulfill them will be iterativelyidentified before concluding a solution design. Finally, the architecturewill be evaluated based on the requirements set up and how well thethreat models are mitigated.

1.3 Related Work

The major EHR systems in Sweden, TakeCare, Cosmic, VAS and Sys-team Cross were analyzed on usability in [33]. The background of thework was that up to 70% of clinical workers operating time is put onwork outside of caregiving and there is a strong will to standardizecaregiving into one IT-system. It was concluded that all systems arebuilt-up in a similar way and that they all need to develop to increase

CHAPTER 1. INTRODUCTION 3

the usability. Also, connections between usability and patient safetyhave been made. In [28], it is stated that the patient security is at riskwhen incorrect patient data is presented for the clinical workers, whenthe data is transferred incorrectly between different systems or whenthe data is insufficient. If the right patient data about the right patientwas presented at the right time it would solve 70% of incorrect medica-tion. It is not possible to completely disregard usability when buildinga secure system, but the connection to information security becomesmore clear with the findings in [7]. There, the EHR system TakeCarehas been evaluated from an information security perspective analyz-ing four information security requirements. The requirements werelisted as the possibility to block parts of a medical record, clinical workersonly getting access to medical records they should have access to, a systemdesign that supports its users to follow existing laws and regulations andsigning of all medical record entries. It was found that TakeCare meetsmost security requirements but still allows for abuse of unauthorizedaccess. Since a clinical worker must actively choose to access a pa-tient’s medical record it is not possible to do so by accident, but thereis no authentication method in place. Moreover, it was found that therisk of abuse by an uncertified clinical worker would increase if thesystem is deemed too user-friendly. TakeCare aims to partly solve thisby logging every user action.

In [29], the Cross Enterprise Document Sharing (XDS) system isinvestigated. Through both automated and manual testing it was con-cluded that authentication was at a poor state, where anyone couldauthenticate knowing only the username of a user. Additionally, anyuser account on the intranet had access to the entire XDS database andfixing the authentication procedure would require the cooperation ofmultiple EHR vendors.

In [18], 49 research articles on the information security and pri-vacy of EHR systems were studied. It was found that various differ-ent encryption algorithms were used with the conclusion that whichone does not matter as long as it is an easy-to-use efficient encryp-tion scheme with scalability in regards of including new EHR records.Furthermore, over half of the EHR systems used Role-Based AccessControl (RBAC) as their access control model. The effectiveness ofauditing was not investigated, but only half of the systems practiceauditing. Finally, it was concluded that it is fairly uncommon to havepreventative measures in place for unauthorized access to patient data


in transit.Studies on why accesses to EHRs occur were made in [17]. Al-

though most accesses occurs for a legitimate reason, they are not al-ways recorded in logs. Over 90% of accesses can be explained usinginformation already contained within the EHR system. Automatingthe process of logging the reason for an access, as opposed to lettingclinical workers manually enter their reason, would leave fewer logentries without a reason for access. For misuse detection this is ben-eficial since essentially it would mean less material for an auditor toanalyze.

In [27], the logging mechanisms of the EHR systems OpenEMR,OSCAR, Tolven eCHR and WorldVistA were analyzed. Although withvarying results, through black-box testing it was found that all ex-pected log output, i.e. all CRUD accesses, was not stored in the logof any of the four EHR systems. This was for example due to mis-match of event descriptions, e.g. update recorded as a new entry, ormissing a description of why an event occurred. In three of the fourEHR systems, separation of privilege was not practiced. Essentially, adoctor could have admin rights and tamper with existing log entries inthe database. With separation of privilege in place, another conditionwould have to be satisfied to be granted access to the log database. Ad-ditionally, three common weaknesses related to logging from the Com-mon Weakness Enumeration (CWE) dictionary was found present inthe EHR systems. It was found that log entries contains sensitive data,critical events are not sufficiently logged and overall too much data islogged.

OpenEMR was also analyzed in [53]. There it was found that thelogs of OpenEMR are insufficient for detecting information privacy vi-olations and the auditing mechanism does not assure non-repudiation.Furthermore, it is not possible to differentiate in the logs whether anaccess to a record was made through an emergency or not. Continuing,log formulation and analysis are problematic in existing EHR systems.This means that privacy violations are difficult to detect due to insuf-ficient logs and auditing becomes difficult due to logs being scatteredacross the system.

It is clear that authentication, logging and auditing is severely lack-ing in EHR systems today. Logs are insufficient, can be tampered withand poorly addresses emergency situations.

Several different approaches have been attempted in trying to se-

CHAPTER 1. INTRODUCTION 5

cure the handling of EHRs, electronic medical records (EMRs) and per-sonal health records (PHRs). In short, EHRs and EMRs are recordscreated by the doctor, while PHRs are created and managed by the pa-tients themselves. One example of securing medical records is tryingto leverage blockchain, both permissioned [5, 8, 32] and permission-less [4, 5, 19]. In permissioned, also known as private blockchains,only invited entities can validate blocks while permissionless lets any-one participate. Other examples includes using attribute based en-cryption for PHRs [31] or patient controlled encryption for EMRs [25].Autonomic security frameworks have been presented to provide riskassessment, prevention mechanisms and intrusion detection againstoutside attackers [11, 12]. An intelligent healthcare security system toprotect against viruses and Denial-of-Service (DoS) attacks leveraginga firewall, network Intrusion Detection System (IDS) and web filterwas presented in [42]. Generally, previous work focuses on the han-dling of medical records on a national level between multiple differ-ent healthcare providers. Additionally, in most cases several differentrecord keeping systems are forced to interact with separate proprietarysystems.

This project will differ in the way that there will only be one recordkeeping system which is owned by a single care provider, as opposedto different record keeping systems in different geographical regionsof Sweden. Furthermore, emphasis will be put on the multiple stake-holder environment. A large number of people with different roleswill be involved, such as doctors, psychologists, developers, patientsupport, doctor support, medical operations group, analysts, externalcaregivers and the patients themselves. Read and write access dif-fers for each stakeholder and the access rights can also change overtime. An additional difference is that this thesis will focus on a na-tional telemedicine service, as opposed to physical healthcare centers.Considering that there are no geographical limitations, more doctorsand patients will be involved as opposed to a physical center whichonly attracts patients within its vicinity. One can conceive that in aphysical healthcare center it is more likely that a clinical worker haslegitimate access to a patient record than not having access. This com-pared to a large-scale telemedicine service where it is the opposite, i.e.it is more likely that a clinical worker should not have access.

For this work, the blockchain solutions do not fit since they eitherdo not preserve confidentiality and can infringe upon patients privacy,


or are better suited for collective healthcare between multiple differenthealthcare providers. The former because permissionless blockchainslets anyone participate in the validation of the blocks and the latterbecause of blockchains being based on the distributed trust principle,achieving e.g. tamper resistance by letting different healthcare entitiesverify blocks before adding them to the chain.

Chapter 2

Background

Chapter 2 covers relevant background information within healthcareand security.

2.1 Electronic Health Record

Although similar, the EHR is not entirely the same thing as the EMR.The EMR is a medical record that is created and managed by the doctoror other healthcare staff and contains various patient data such as labresults or allergy information. It is designed for internal use within onecaregiver. The EHR, on the other hand, is a wider term where morepatient data is stored and includes different EMRs as a data source aswell as additional patient health data from different clinics. Parts ofthe data stored in the EHR is shared between different care providers,specialists and the patients themselves [51]. While the EMR and EHRare something the clinicians control, the personal health record (PHR)is created and managed by the patient [49]. This, and any other patientdata created by the patient, such as symptom forms, are out of scope ofthis paper. Nevertheless, it should be noted that securing most PHRsshould not differ much from securing EHRs.

2.2 EHR System

A medical record consists of one or more record entries belonging tothe same patient. In turn, a record entry is any description of the pa-tient’s health status or planned care issues created at the time of care-

7

8 CHAPTER 2. BACKGROUND

giving. Medical records keeping shall be done whenever caregiving ofpatients is performed. The main goal with medical records keeping isto contribute to a safe and fair treatment of the patient. It also serves asan information source for the doctor, patient or any other stakeholderinvolved [45]. The information and expressions in a medical recordneeds to be unambiguous which is preferably achieved by using theclinical standards ICD-10-SE, KVÅ, ICF and Snomed CT when possi-ble. Additionally, information shall be entered into the record as soonas possible. There are plenty of information that a medical record shallcontain. Some of them are the patient’s identity, background infor-mation of the caregiving, noted diagnosis and planned arrangements.Furthermore it shall include the patient’s contact information, nameand position of personnel who account for a record entry and the timefor every contact between patient and caregiver [45].

2.3 EHR Users

In Sweden anyone who is licensed to work in a healthcare related pro-fession shall do record keeping. Furthermore, those who assist a li-censed professional shall perform record keeping as well. Since recordkeeping is required whenever a patient is treated, sometimes also un-licensed personnel needs to do record keeping [45].

At Kry several different stakeholders are interacting with the EHRsin different ways. How they interact has been identified through writ-ten open-ended questions with an employee from each role. The ques-tions can be seen in the appendix.

• Doctors and psychologistsDoctors and psychologists falls under the category of licensedprofessional and shall thus perform record keeping of patientsthat are being treated by them.

• Customer SupportThe support team needs access to medical records in variousways to assist in helping the patient after a care meeting. Theysend referrals, add comment letters, add test answers and regis-ter free card numbers amongst other tasks.

• Medical OperationsThe medical operations group uses the EHRs to educate new

CHAPTER 2. BACKGROUND 9

doctors and to assist the support team and doctors about ques-tions regarding the medical records.

• AnalystsAnalysts, or data scientists, aggregates data from medicalrecords to create compiled reports used for medical followups.The goal is for example to get a clear picture of how often antibi-otics are prescribed. These types of quality followups cover allaspects and thus access to all parts of the EHRs is required.

• DevelopersDevelopers might need access to medical records when there is aneed for technical support or troubleshooting.

• PatientThe patient has, with a few exceptions, the right to read theirmedical record. This is to let the patient receive necessary in-formation about for example the diagnosis, why a certain treat-ment has been assigned and who has made the record entries.The exceptions happens when there are strong medical reasonsto not allow access or when another person might be affectednegatively if the information is dispensed. [26].

2.4 Laws & Regulations

When dealing with patient data and data related to health there aresome laws and regulations healthcare providers need to abide by. Thelaws and regulations can differ between countries and this section willonly focus on laws and regulations applicable to Sweden. Neverthe-less, it should be noted that to a large part it can be generalized tomany other countries with similar systems. This section gives an in-troduction to sammanhållen journalföring (coherent record keeping),patientdatalagen (the Patient Data Act) and the general data protec-tion regulation. Chapter 3 gives more detail and analyzes how theyconcretely affect healthcare.

2.4.1 Sammanhållen journalföring & NPÖ

"Sammanhållen journalföring" means that caregivers allow some pa-tient data to be accessible by other caregivers. The goal is to better


protect patients during treatment and reduce the workload for clini-cal workers. Only authorized clinical workers get access to medicalrecords this way and consent is required from the patient [50]. Na-tionell patientöversikt (NPÖ) is the swedish web tool for samman-hållen journalföring [23].

2.4.2 Patientdatalagen

Patientdatalagen (PDL 2008:355) [37] is a Swedish law that came intoeffect in 2008. The objective of PDL is to protect patients personal in-tegrity and increase patient safety. Additionally, PDL also regulatesthe possibility for shared access of patient records between differentcaregivers through sammanhållen journalföring [44].

2.4.3 General Data Protection Regulation

The general data protection regulation (GDPR) is set out to be usheredin from 25 May 2018. The aim of the regulation is to protect individ-uals living in the EU from privacy and data breaches [16]. The GDPRenforces the concepts of consent, breach notification, right to accessand right to be forgotten, data portability and privacy by design. Theimportance to follow the GDPR is high due to the hefty fine if a breachof the regulation occurs. Organizations will be fined up to 4% of theirannual global turnover or 20 million euro, whichever is the highest[40]. The regulation is general and thus not limited to healthcare.

2.5 Access control

Access control is the means of allowing, denying, limiting and revok-ing access. To perform these tasks, a user needs to provide some meansof identification and then authenticate, before being authorized to usecertain parts of the system [6].

2.5.1 Identification and Authentication

Identification is claiming to be someone. Concretely, the concept ofidentification can for example be done by providing a name, user-name, ID card or fingerprints. Due to many identification methods


being shared, are subject to change and can easily be spoofed, authen-tication is required. Authentication is the method or set of methodsused to confirm a claim of identity to be true. Multifactor authentica-tion is using two or more methods belonging to different categories orfactors. Two factor authentication (2FA) based on, for example some-thing you know and something you have, is commonly used [6].

Electronic identification

Electronic identification is a way to provide identification online. Itcan be used for both authentication and for signing, using a digitalsignature. BankID1 is "the leading electronic identification in Sweden"developed by large banks such as Nordea, SEB and Danske Bank. Itis used for both identification and signing. Due to its large popularityin Sweden it will be considered as the digital signature scheme for therest of this thesis [1]. Technical details on how the BankID API works,such as authentication and signing, can be found in the relying partyguidelines2.

2.5.2 Authorization

After authentication has taken place authorization will specify whatthe authenticated party is allowed to do. It can be the right to create,read, update or delete (CRUD). Managing the authorization level isdone through access control. When setting the authorization level itis desired to follow the principle of least privilege, i.e. allow as lit-tle access as possible. Access control is often implemented as accesscontrol lists (ACLs) but can also be capability-based. The advantageof capability-based security is that it mitigates attacks based on theconfused deputy problem3, something ACLs are vulnerable against.Several different access control models exist, discretionary, manda-tory, role-based and attribute-based access control. Furthermore, somemodels are combinations of the previous, known as The Bell-LaPadulamodel, The Biba model and The Brewer and Nash model [6]. Discre-tionary access control allows end users to decide access rights of ob-jects. A disadvantage with that is that the owner of a resource does

1https://www.bankid.com/en/2https://www.bankid.com/assets/bankid/rp/bankid-relying-party-

guidelines-v3.1.pdf3https://en.wikipedia.org/wiki/Confused_deputy_problem


not have full control over the information flow. Disadvantages withmandatory access control includes not being able to dynamically alteruser access and requires predetermined planning for it to be imple-mented effectively. On the other hand, RBAC, the most commonlyused access control method in current EHR systems, maintains the re-lation between a user and its role. As such, it is not possible to changethe access rights without altering the roles [48].

2.6 Encryption

Encryption is the transformation of plaintext into ciphertext, whichcan only be read if decrypted. There are two types of encryptionschemes, namely symmetric and asymmetric. In a symmetric encryp-tion scheme the same key is used for encryption and decryption, whilein an asymmetric scheme one key is used for encryption and anotherkey for decryption. The encryption key is often referred to as the pub-lic key, and the decryption key as the private key [6].

2.6.1 AES

Advanced Encryption Standard (AES) is a symmetric block cipher thatwas developed for the National Institute of Standards and Technology(NIST). The block size is always 128 bits but the key size can differ be-tween 128, 192 and 256 bits. The algorithm is based on a substitution-permutation network and several cycles of substitution, transpositionand mixing is performed before the ciphertext is produced [3]. In gen-eral, there are no known practical attacks against AES, but some vul-nerabilities have been found. For example, a nine round AES with 256bit keys can be broken in 239 time [41]. One could conceive that morevulnerabilities will be found in the future.

2.6.2 RSA

RSA is an asymmetric cryptosystem and probably the most wellknown such. Public Key Cryptographic Standards (PKCS) #1, [30],is a standard published by RSA Laboratories which defines how RSAshould be implemented. The strength of RSA lies in the difficulty offactoring two large prime numbers. Key lengths are usually 2048 or


4096 bit, which makes it considerably slower than symmetric algo-rithms.

2.7 End-to-End Encryption

End-to-End Encryption (E2EE) is the property of only letting the endclients get access to the plaintext data. Essentially this means that con-fidentiality is preserved even over an untrusted channel [36]. This isin contrast to for example the TLS protocol, where data is decrypted atevery intermediate node [21].

2.7.1 Hyker

Hyker is an E2EE proprietary developed by SAAB4 and Combitech5

where the access control of data is separated from the sending pro-cess, making it suitable for a publisher-subscribe system model. Datais encrypted by the sender and key sharing happens retroactively. Es-sentially, data is encrypted at rest and in transit, and recipients canbe added long after an encrypted message has been sent. Access isdecided by the sender upon receiving requests for access, but dele-gated access control is also supported. The sender can then choose todelegate the permission of key sharing to another entity [22]. Hykeruses AES-Galoic/Counter Mode (GCM) as the cryptographic functionfor symmetric keys and RSA-Probabilistic Signature Scheme (PSS) forasymmetric keys. Hyker symmetric keys can be subject for renewal.Updating the symmetric key excludes previously authorized recipi-ents.

2.7.2 Signal

The Signal Protocol is an E2EE messaging protocol used in WhatsAppand Facebook Messenger that can be described as "a ratcheting for-ward secrecy protocol that works in synchronous and asynchronousmessaging environments" [14]. The protocol uses short-lived sessionkeys for every message sent, meaning that if a key is compromised itcan not be used to decrypt previously sent messages [52]. In [14], a

4https://saab.com/5http://www.combitech.com/


security analysis was performed on the Signal Protocol. It was con-cluded that Signal satisfies several standard security properties withno major flaws, but fully predicting the random number generator(RNG) could make it possible to compromise future communications.

2.8 Cryptographic Anchor

A cryptographic anchor, or crypto anchor, can be seen as a module ina security architecture used to provide exfiltration resistance. Manyattacks are based on exfiltrating sensitive data and then operating onthe data in the adversary’s own environment, i.e. an offline attack. Byusing a crypto anchor an adversary is forced to operate within the at-tacking infrastructure. Combining this with logs and rate limiting theattackers capabilities are limited and their chances of going undetectedare reduced [35]. A great way of creating a crypto anchor is by usingHardware Security Modules (HSMs) for key storage [15].

2.8.1 Hardware Security Module

A hardware security module is a physical tamper-resistant device thatcan perform cryptographic operations. These include, but are not lim-ited to, both symmetric and asymmetric key generation as well as pri-vate key storage [47]. An HSM can also perform Card VerificationValue (CVV) and Personal Identification Number (PIN) generationand verification or certificate management. Whenever an attempt topenetrate an HSM is made, it will immediately delete all stored secretinformation. It also supports physical security in the form of defenseagainst low temperature attacks and power analysis attacks [34].

2.9 Audit Logging

Logging is the method of storing actions or events in a log. Logs arealmost always generated automatically and are highly customizable inwhat and how much they store. Logs are often not very useful withoutreviewing them, which is why auditing is practiced [6].

In EHR systems, logging should capture all CRUD accesses to beable to trace user activity and identify unauthorized access [27]. In [27]


a set of principles to follow when designing logging for an EHR sys-tem is proposed. Each log entry should be sufficient enough such that"who, what, when, where, why and how an event occurred" can be an-swered. Audit reports should contain a clear description of what ac-tion occurred for every log entry and the reports should be presentedin a human-readable way. Finally, a single user should not be able totamper with existing log entries. [53] proposes the following attributesfor every event recorded in the log: timestamp, user id, status of au-thentication, access device, type of action, outcome, source of access,identification of the information that is accessed, reason for access.

2.9.1 Emergency Situations

In case of emergency a doctor might need access to a medical recordwithout being able to get consent from the patient in danger. Gettingaccess this way can be considered a Break The Glass (BTG) scenario.For a BTG event to trigger a patient must be in danger, the responsi-ble doctor must be unavailable and there must be an urgent need fora doctor. When an emergency happens it should be recorded in a logthat the previously three conditions have occurred preceded by theinitialization of a BTG session and authentication of emergency staff[53]. While a BTG scenario is unlikely and even more so in the case oftelemedicine it can not be entirely neglected. For example one couldimagine mentally unstable or suicidal patients to call in and due totheir mental state not be in a position to be able to give consent. Addi-tionally, telemedicine providers might cooperate with physical healthclinics in the future.

2.10 Formal Specification

Formal methods refers to a collection of techniques that use mathe-matical notation to represent software. One of the techniques includedis formal specification. A formal specification is defined as a specifi-cation where vocabulary, syntax and semantics are formally defined.They can be used to discover specification errors or present a specifi-cation in an unambiguous way [46]. An example of a formal methodis Event-B, which is described in detail in section 5.4.1.

Chapter 3

Requirements

Chapter 3 presents all requirements the architecture shall sought tofulfill. The requirements comes from a legal, general security anddoctor perspective respectively. Unlike the legal and general securityperspective, doctor requirements are more functionality and usabilityconcerns rather than security concerns.

3.1 Law Requirements

The identified law requirements are based on Swedish law and regu-lation documents, but also compiled through an interview with a li-censed lawyer at Kry.

3.1.1 Literature

The following section is based on the official PDL documentation pub-lished by the Swedish Parliament and the handbook published bythe National Board of Health and Welfare. Both publications are inSwedish and have been translated for this thesis. Relevant laws andregulations have been identified and are rendered in a summarizedfashion.

PDL

In PDL chapter 3, [37], it is stated that the EHR shall include who madean edit or note in the record as well as when it was done. Also, if accessto a record is given through a copy it shall be noted who and when got

16

CHAPTER 3. REQUIREMENTS 17

this access in the EHR, but this is not required if direct access is given.Furthermore, an EHR shall be kept for at least 10 years since the lastrecord entry was made.

Chapter 4 states that a person working at a caregiver has the rightto access a patient record if he or she participates in the treatment ofthe patient or the information for another reason is needed in his orher work within health care. Access to patient data that is added to therecord partially or fully automated shall be limited to what is neededto perform the work task. Additionally, there shall be logs of whoaccesses a patient record. Parts of the EHR, that is made accessiblethrough electronic access to another caregiver, can be blocked by thepatient. The blockade can be revoked if the patient gives consent to doso or in the case of an emergency situation.

Chapter 6 mentions that information shall be accessible to othercaregivers, but as previously mentioned, less information if patientchooses to block access. In chapter 8 it is stated that a patient shallget access to their EHR, and shall also be able to see who has accessedtheir record.

The National Board of Health and Welfare

Chapter 3 in the handbook [45] by the National Board of Health andWelfare talks about how confidentiality, integrity and availability (theCIA-triad) and non-repudiation shall be ensured. It also recommendsthat the caregiver should use Swedish standards for information se-curity, e.g. ISO/IEC 27000-series. Moreover, it mentions that backupcopies shall be stored separately from the original patient records andthat confidentiality shall be ensured when transferring patient dataover the Internet. Whenever patient data is accessed this way 2FAshall be used. Invitations or reminders can be unencrypted and sentvia SMS or E-mail if the patient has given consent and no details abouthealth status or other personal links are disclosed.

Chapter 4 talks about access control and access to patient data. Ev-ery user/employee shall have an individually configured authoriza-tion level. Following, it is always implied that a user is authorized.Within the same caregiver it shall be possible for a user to see if thereare patient data about a patient at another care unit, but not at whichcare unit. To see at which care unit the patient data is located theuser must perform two active choices, meaning that the user has to

18 CHAPTER 3. REQUIREMENTS

take a standpoint whether he or she is entitled to this information.The chapter then continues with regulations regarding sammanhållenjournalföring. A user who wants access to non-blocked data is respon-sible that certain requirements mentioned in PDL are met and mustperform an active choice to get access. Information about which care-giver has blocked patient data shall only be made accessible to a userafter an active choice. There shall be logs including both user’s and pa-tient’s identity, which care unit and when it was accessed. Logs shallbe saved for at least 5 years. Direct access to one’s own data shall bepreceded by 2FA.

Chapter 6 talks about handling of patient data and how to preventunauthorized access. Healthcare personnel shall be responsible for notletting passwords or computers which handles patient data get lost orin the hands of other people. It shall be clear in the documentation thatthe patient has chosen to block data. Medical records shall be signedunless there are very strong reasons not to. Medical records shall neverbe modified or destroyed unless there is support to do so from PDL.

3.1.2 Interview

The interview was carried out in Swedish with a licensed lawyer. Per-forming the interview in the native language of the interviewee en-sures that the interviewee can express and formulate sentences flu-ently and naturally with minimal risk of misusing words. The goalwith the interview was to get a clear picture of how GDPR and PDLcorrelates, as well as when and which one of them overrides the other.The interview was carried out as a semi-structured interview. Choos-ing this qualitative method is motivated by having a single intervie-wee and an exploratory nature in the research question. The semi-structured interview method is further motivated with that it avoidsderivation and bias from the interviewer [20]. The rest of the section isbased on the interview with the aforementioned lawyer.

When understanding the relationship between GDPR and PDL,one can conceive GDPR as a minimum legislation. GDPR is compre-hensive and absolute, meaning that it pertains as long as nothing elsedoes. Whenever there is a specific legislation in place, like PDL, thenthat legislation pertains before the minimum legislation.

PDL come into effect whenever there is a "care relationship" withthe patient, i.e. whenever caregiving is performed. For a company to


process data under the legislation of PDL, they must prove that thedata is necessary for the caregiving of the patient. As a concrete exam-ple, this means that e.g. the right to be forgotten of GDPR does not applyfor data that is needed for the treatment, or correlates to the caregiving,of the patient.

A different case is if a caregiver were to also include PHRs. Con-sidering that case, where a patient chooses to store personal data likeweight to be able to track their health, it would fall under GDPR. How-ever, if the caregiver would choose to undertake responsibility for theperson’s health then PDL pertains. In the end it is the purpose be-hind the processing of data that decides which legislation that shall becomplied with.

Choosing when to take responsibility is up to the owner of the ap-plication. For the telemedicine case it is reasonable to assume that justdownloading the app is not enough. However, whenever a request fora meeting with a doctor starts, then the caregiving relationship starts.This makes sense when compared to a physical clinic. Just entering thewaiting room is not enough, while approaching the front desk askingfor treatment is.

Anonymisation or pseudonymisation are two disputed concepts inGDPR. As of right now they could be used as loopholes to be ableto process data without taking responsibility. Anonymisation beforeprocessing data should be used whenever possible, but that doesn’tmean that the data can be used freely, since it is often possible to de-anonymize.

It is allowed, in quality assurance purposes, to have a general in-sight into patient records, but it is not allowed to look up a healthrecord of a specific person.

In short, any data that is needed for the caregiving of the patientfalls under the legislation of PDL. A solid principle for both GDPRand PDL is that no data should be processed without a reason.

3.2 Security Requirements

This section talks about security requirements based on general con-ventions within information security.


3.2.1 The Parkerian Hexad

The CIA triad is well established within information security. It is amodel introducing the primary concepts confidentiality, integrity andavailability [10]. A more extensive model of the CIA triad is the Park-erian hexad, see Figure 3.1. It includes, except for the three concepts ofCIA, the principles of possession, authenticity and utility.

Figure 3.1: The Parkerian hexad.

The possession principle aims to involve the security of the physi-cal device. Different from availability, data can be stored on multipledevices and losing possession of such a device can pose a threat with-out denying availability.

Authenticity deal with the owner of the data. Violation of authen-ticity can be seen as claiming someone else’s identity. Authenticity canbe ensured by using digital signatures.

The concept of utility refers to the usefulness of the data in ques-tion. More useful implies higher utility. A concrete example would bethat encrypted data has lower utility than unencrypted data [6].

Not included in the Parkerian hexad is accountability. Accountabil-ity provides the possibility to trace activities back to their source and


is accomplished through auditing. Tools that allows for accountabil-ity also enables non-repudiation and intrusion detection. For auditingto practically work, there needs to be logs of activities that has takenplace [6]. Audit logging will be seen as the method to perform moni-toring of the activities within the EHR system and therefore having anaudit log will be a requirement.

3.2.2 ISO/IEC 27001

The international standard ISO/IEC 27001 provides requirements foran information security management system [24]. Sections 8-13 in ta-ble A.1 are relevant for this thesis.

Section 8 describes that all information should be classified in termsof value and sensitivity and that media shall be disposed of securely.

Section 9 talks about access control and that an access control policyshall be established. There should be a process for user access rightsand access to systems shall be preceded by a secure log-on procedure.In section 10 secure key management is described and how crypto-graphic keys should be protected through their whole lifecycle.

Section 11 touches upon physical security and that equipmentshould undergo maintenance to ensure availability and that unat-tended equipment should be protected.

Section 12 talks about logging and that all events should be logged.The logs should be protected against tampering and unauthorized ac-cess and be regularly reviewed. Finally, section 13 describes how allcommunication should ensure confidentiality.

3.3 Doctor Requirements

From the doctors perspective it is a must to be able to read and writeto medical records belonging to patients they are involved in the care-giving of. For the doctors to be able to support and help each otherin their work, it is of high importance to be able to share patient databetween each other. This patient data can be anonymized and can con-tain anything from written explanations of symptoms but also digitalphotographs.


3.4 Summary of Requirements

A summary of all requirements, compiled down to exclude overlap-ping requirements, can be seen in Figure 3.2. The first 26 are basedon laws, regulations, general security conventions and doctor require-ments and are presented in bold. For identification purposes the re-quirements are marked with letters explaining where the requirementcomes from and what type of requirement it is. Requirements fromthe legal perspective are denoted as L, general security requirementsas G and doctor requirements as D. Furthermore, S stands for securityrequirement while F stands for functionality requirement. The last 4are based on ISO/IEC 27001.

Figure 3.2: Summary of requirements, must-haves in bold.


3.5 Adversarial Models

Two main threat models and one secondary will be considered. Themodels have been identified and produced based on the current re-search gap. There are currently not any good countermeasures in EHRsystems against doctors going beyond their legal rights. Furthermore,there are still breaches happening frequently which discloses thou-sands of records despite all countermeasures in place aiming to keepintruders out. With that in mind, the focus is shifted to limit an adver-sary’s capabilities after getting access, rather than before. Neverthe-less, weaker adversaries which do not have entire access to the EHRsystem can not be disregarded, motivating the need for a secondarythreat model, i.e. the insider passive adversary.

• Honest-but-curious. This adversary is an employed doctor orother clinical worker who is authorized to use the EHR system.The adversary follows every protocol faithfully but might readmedical records he/she should not, i.e. not allowed to.

• Outsider malicious. This adversary is not authorized to use theEHR system, but manages to authenticate as a doctor. The ad-versary now has the same access rights as a doctor. Essentially,the adversary can read medical records to profile patients, addnew fake record entries about patients or update existing medi-cal records.

• Insider passive. This adversary passively listens to network traf-fic. The attacker is not authorized to the EHR system, but canmonitor all communication on the internal network. The adver-sary is mainly interested in sensitive patient data.

3.6 Scenarios

The solution design will be evaluated in regards to how well the threatmodels are mitigated and how well the sought criteria are satisfied. Tobe able to evaluate how well the two main threat models are mitigated,case scenarios will serve as a standpoint to evaluate the implementa-tion. Although all scenarios can not be reasonably covered withoutlisting every single one explicitly, the following four case scenarios aim


to cover highly probable and frequent scenarios in a telemedicine en-vironment.

The case scenarios are structured to first introduce the involvedusers. Case scenarios A contains a scenario describing a legitimateway of accessing the EHR, followed by an access considered as unau-thorized. Case scenarios in category B contains scenarios describingtwo legitimate ways of accessing the EHR.

Case Scenarios A

In the first two case scenarios the following users are involved:

• Patient P: This patient has not used the application before.

• Doctor A: This doctor is a generic doctor at the telemedicine ap-plication and has no previous relationship with Patient P.

• Doctor B: Another generic doctor at the telemedicine application.

Scenario 1A: An acceptable scenario

Patient P opens the telemedicine application and logs in using BankID.P decides to book a meeting with a doctor and fills out the symptomform. Patient P is assigned to doctor A, who now has legal rights toaccess patient P’s EHR. Doctor A can read the EHR of patient P andalso write new record entries into the EHR of P.

Scenario 2A: An unacceptable scenario

Patient P opens the telemedicine application and logs in using BankID.P decides to book a meeting with a doctor and fills out the symptomform. Patient P is now assigned to doctor A. Doctor A creates a recordentry and adds it into the EHR of patient P. Doctor B is not involvedin the caregiving of patient P but since P is a politician, the media isinterested in knowing personal information about P. A media repre-sentative offers doctor B a considerable amount of money in exchangefor the full EHR of patient P. Doctor B looks up the EHR of patient Pin the EHR system and shares it with the media representative.

Case Scenarios B

Case Scenarios B involves the following users:


• Patient P: This patient has used the application before. A previ-ous meeting has been held with doctor A.

• Doctor A: This doctor is a generic doctor at the telemedicine ap-plication. A previous meetings has been held with patient P.

• Doctor B: This doctor is a generic doctor at the telemedicine ap-plication and has no previous care relationship with Patient P.

Scenario 1B: An acceptable scenario

Patient P decides to book a revisit to follow up on how well the eczematreatment have worked. Patient P is assigned doctor A since A was thedoctor that patient P had the previous meeting with. Not long beforethe meeting, doctor A becomes sick and can not attend the meeting. Tocover up for doctor A, doctor B is assigned to handle the meeting withpatient P. Doctor B is now involved in the caregiving of P and thereforehas the right to read and write to the EHR of patient P. Although doctorA is not assigned the patient for this meeting, doctor A still has anongoing care relationship with P and is also allowed to access P’s EHR.

Scenario 2B: An acceptable scenario

In the previous meeting with doctor A, patient P had called about hazystomach pain. Due to the hazy symptoms, doctor A recommendedpatient P to book a revisit. Patient P schedules a revisit and is assigneddoctor B. Shortly after the revisit has concluded, doctor A wants to doa follow up quality check to see if the evaluation of the patient wasdone correctly. Doctor A reads the EHR of patient P and notes thatdoctor B has made a record entry stating that patient P is now freefrom discomfort.

Chapter 4

Architecture Proposals

When discovering the solution design architecture we want to haveas few components as possible. The idea behind that reasoning isthat fewer components means fewer components where somethingcan go wrong. In other words, we want to find the simplest archi-tecture that satisfies all requirements and mitigates the threat models.Chapter 4 presents four architecture proposals. The first proposal isthe most simple one, with the following ones iteratively adding one ora few components before leading up to the solution design presentedin chapter 5.

4.1 Architecture 1

A basic web application can be seen in Figure 4.1. The app communi-cates with the database directly and this proposal clearly does not ful-fill all requirements. One of them is availability, since if the databaseis overloaded or otherwise obstructed in any way, neither the EHRs orthe logs will be accessible. Note that the EHR app depicts both fron-tend and backend.

26

CHAPTER 4. ARCHITECTURE PROPOSALS 27

Figure 4.1: Architecture 1.

4.2 Architecture 2

The following architecture, seen in Figure 4.2, separates the patientdata and the logs in two different databases. While this increases avail-ability, it is still vulnerable to an adversary who compromises the EHRapp. Such adversary could download all data, extract the decryptionkey from the EHR app and then operate on the data offline.


28 CHAPTER 4. ARCHITECTURE PROPOSALS

4.3 Architecture 3

Architecture 3 effectively reduces the capabilities of an adversary whocompromises the EHR app by introducing a crypto anchor. In Figure4.3 the crypto anchor is depicted as the Patient-data-Service (PdS). ThePdS contains all the keys and is thus required to decrypt the data. Anadversary who compromises the EHR app would now be forced tooperate online, within the infrastructure. This way, every time anydata is accessed it is logged by the PdS. Furthermore, through ratelimiting, the amount of data that can be accessed within a certain timeframe is limited. Although the PdS is not entirely freed from attacks, itworks as an isolated component which effectively separates the attacksurface. However, architecture 3 does not have any backup storagethat is separated from the original.


CHAPTER 4. ARCHITECTURE PROPOSALS 29

4.4 Architecture 4

The architecture in Figure 4.4 introduces backups for EHRs and logs.One of the requirements are that backup copies shall be stored sepa-rately from the original. Whenever an EHR is stored in the database,another operation is done to store a backup copy. The backup copy isencrypted with another key and all keys to the content in the backupdatabase is stored in a separate HSM. Basically, all write operationsby the PdS is done to two different systems. Read operations, on theother hand, is done to only one system. Architecture 4 satisfies therequirement of having backups which is important for availability incase of database failure. Nevertheless, although backups increases thedegree of availability, availability is still not considered enough for thepurpose of a telemedicine application. At this stage, the databases arestill locally stored.


Chapter 5

Solution Design

Chapter 5 presents the solution architecture. In section 5.1, anoverview of the design is presented. Section 5.2 presents ordinaryworkflows and operations together with an explanation of how theywork. Section 5.3 gives an in-depth explanation of the logging mecha-nism. Section 5.4 gives a formal specification of the read record work-flow.

5.1 High-level Design

The solution design is proposed in Figure 5.1. Hyker is implementedas an E2EE service to encrypt all patient data in the EHRs before stor-ing them in the cloud. Except for the properties that comes with E2EE,Hyker is used for its property of retroactive access. Retroactive accessmeans that recipients does not need to be known at the time of en-cryption. Every key used for encryption is assigned a KEY_ID and anonce counter initialised to zero. To grant retroactive access, KEY_IDis used to identify the key used to encrypt the requested EHR andthen given to the user. In a medical records system the recipients cannot be known beforehand, and the employed doctors can change overtime making retroactive access highly suitable for this environment.The EHRs and logs are for availability purposes stored separately inthe cloud using Amazon Web Services (AWS). It would not be feasiblewith local storage due to the decentralized workstation for the doctors.Although AWS does not have any servers in Sweden, there are serversin Germany, and GDPR and the eighth Data Protection Principle onlyrestricts data transfers to countries outside EEA [40]. The E2EE makes

30

CHAPTER 5. SOLUTION DESIGN 31

sure that no sensitive data is stored unencrypted in the cloud, since itis assumed that the cloud can not be trusted. All communication withthe cloud goes via the PdS, which is also where all cryptographic oper-ations happens. Furthermore, since all traffic is happening via the PdSit is also responsible for logging every action. Each log entry containsthe properties presented in Figure 5.6.

Figure 5.1: Solution Architecture.

5.1.1 Cryptographic Functions

Hyker makes use of ECDH(E)-RSA key agreement to establish sessionkeys. When a session key has been established, it is used in an AES-256-GCM cipher to encrypt data. The session key is marked with akey ID, which is used to provide retroactive access. Moreover, RSA-2048-PSS is used as the asymmetric key algorithm. Doctors using theEHR app are identified by a user ID. Through certificates issued by thePdS, user IDs are bound to their respective public key. Public key re-vocation in Hyker works similarly to Online Certificate Status Protocol(OCSP) 1. For each lookup of a public key there is a forced in-line revo-cation check, making the public key revocation process instantaneous.

1https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol

32 CHAPTER 5. SOLUTION DESIGN

Symmetric keys can be renewed as explained in section 2.7.1.

5.2 Workflows/Operations

Important workflows for the proposed solution design are reading arecord, writing to a record, adding a patient and getting direct ac-cess to the database/logs respectively. Reading and writing to recordsis something doctors do continuously and frequently in their work.Adding a patient and direct access to database/logs are especially sen-sitive operations.

5.2.1 Read Record

Figure 5.2 shows the workflow when reading a record. The user firsthas to authenticate using a generic digital signature scheme, such asBankID. If the user is a patient, the patient is presented with the pa-tient’s own health record. For doctors, or any other clinical worker,they first make a request to read a record. Then, the PdS service iden-tifies the key that was used to encrypt the requested EHR, gives it tothe user who can then decrypt the EHR and read it. Simultaneously,the PdS makes sure to store a new log entry.


Figure 5.2: Workflow when reading a record.

5.2.2 Write Record

In Figure 5.3 the workflow when writing to a record is visualized.First, a doctor must authenticate using BankID. If the patient is us-ing the telemedicine application for the first time, the patient has tobe added to the database (explained in section 5.2.3). If the patientalready exist, the doctor will view the corresponding record and startwriting a new record entry. At the same time, the PdS performs a rekeyoperation, i.e. generates a new session key. The doctor can then usethe fresh key to encrypt the new record entry, and access control is au-tomatically delegated to the PdS. The PdS in turn stores the new entry


in the EHR database and logs the action. The doctor must then elec-tronically sign the new entry. The doctor makes sure that everythinglooks correct and signs the entry using BankID. The PdS once againstores that the entry has been signed and adds a log entry. The doctorcan then continue with the next patient or exit the application.

Figure 5.3: Workflow when writing to record.


5.2.3 Add New Patient

When a patient uses the application for the first time, a new EHR hasto be created, Figure 5.4. The EHR app fetches baseline patient datafrom when the patient authenticates through BankID. A new EHR iscreated, encrypted and then stored. The PdS makes sure that a newlog entry is added into the logs.

Figure 5.4: Workflow when adding a new patient.


5.2.4 Direct Access to Database or Log

In Figure 5.5 the workflow for direct access to the database or logs ispresented. Direct access to the database or logs is preceded by the prin-ciple of separation of privelege. Before accessing the database or logs,consent is required from the other party, i.e. if the admin makes therequest, consent is required from the head of activity and vice versa. Ifthe asked party approves the request, a signature is required throughBankID before access is granted to the initiator. Upon approval, theinitiator gets direct access to the database or logs. When making thedecision to approve or deny access one should follow the policy offirst talking to the initiator, either physically or through a phone call.The design can easily be extended to let other groups of users makesuch a request as well. In that case, consent is required from either theadministrator or the head of activity.


Figure 5.5: Workflow when getting direct log/database access.

5.3 Logs

In Figure 5.6 every attribute for a log entry is listed, what question theyanswer and what type of information they can contain.

Timestamp denotes the time when a record was accessed and isused to answer the question of when. User id and status of authenti-cation helps answer the question of who accessed the record. User idis a positive integer that is unique for every doctor and is used as themeans of identification. Status of authentication shows the authentica-tion level of the user. The authentication level is based on the role andcan be set to admin, caregiver, support, medops, analyst, developer, orpatient.


Figure 5.6: Attributes for every log entry.

The attributes access device and type of action are used to answerthe question of how the access was made. Access device containsthe platform delimiter of the User-Agent header, e.g Windows NT 6.1Win64 x64 rv47.0 for a windows computer or iPhone CPU iPhone OS10_3_1 like Mac OS X for an iPhone. Type of action explains what wasdone to the record. It can be an addition, deletion or edit. If the recordonly was viewed the type of action is set to view. In the rare case ofemergency, the type of action is set to BTG.

Outcome and reason for access helps answer why the record wasaccessed. Outcome explains if the action succeeded or not, denoted astrue or false. As the attribute entails, reason for access contains justthat. It can be either caregiving, quality work, administration, statis-tics, planning or unknown. What reason of access is set to dependson the role of the user. For a support employee the reason for accesswill be set to administration, and for a data scientist it will be set tostatistics. Doctors reason for access is set to caregiving if the EHR apphas identified an ongoing care relationship between the patient andthe doctor, i.e. the patient has been assigned the doctor for a meeting.If there is no ongoing care relationship, the reason for access is set tounknown. This enables effective separation of EHR accesses which aremade with an obvious care relationship or not in place. The unknowntag works as a flag for suspicious accesses and facilitates the auditorswork.

Source of access answers from where the access was made by sav-ing the name of the care unit.

Lastly, what was accessed is answered by the identification of the


information that is accessed and patient id attributes. The former con-tains the part or parts of the EHR that was accessed. The latter is thepersonal identity number of the patient the EHR belongs to.

5.4 Specification

A full implementation of the architecture would be out of scope for thisthesis. However, a formal specification is presented such that anyonewho wants to implement the solution design can verify it and checkthat the implementation follows the specification. The read recordoperation is chosen as a representative since the specification for thewhole system would be too large.

5.4.1 Event-B

Event-B [38] is an extension of the B formalism which uses set theoryas a modelling notation, refinement to represent systems at differentabstraction levels and mathematical proofs to verify consistency.

In Event-B a system model is specified as an abstract state ma-chine [2]. An abstract state machine contains the model state whichis a collection of variables and the state operations which describes thedynamic system behaviour. Variables are defined as model Invariantsand the dynamic system behaviour is defined by a selection of events.Events are generally of the form:

e = any a where Ge then Re end,where e is the event’s name, a is the list of local variables, Ge is the

event guard and Re is the event action. The guard is a state predicatethat defines under which conditions the event is enabled. If there areseveral events enabled at the same time any of them can be chosen forexecution non-deterministically and if no event is enabled the systementers a deadlock. Additionally, a machine is often connected to an-other component known as the Context, which contains sets, constantsand model axioms. The axioms are the properties of the machine thatshould always be true [2].

Event-B comes with tool support in the form of the Rodin Platform.Rodin is based on the Eclipse Platform and allows Event-B models tobe created with an editor. Moreover, Rodin supports automatic gen-eration and proving of proof obligations. A proof obligation is some-thing that needs to be proven to show that e.g. a theorem is correct.


There are various extensions available to Rodin. One of them is ProBwhich is a model checking tool that allows for automated consistencychecking and detection of invariant violations and deadlocks [39].

5.4.2 Formal Modelling with Event-B: Read Record

The read record operation introduced in section 5.2.1 is used by differ-ent stakeholders for different purposes. The requirements of the readrecord operation is summarized below.

There are two roles in the system, patient and doctor. At this ab-straction level the doctor role depicts all telemedicine employees.

• Every doctor and patient is associated with a user id

Functionality associated with the users:

• A patient can read his own record.

• A doctor can read any record.

Functionality associated with the records:

• Each record has a corresponding symmetric key.

Record access policies:

• Several users can read the same record at the same time.

• Whenever an access is made, it is stored in a log.

• Before a user can get access, the decryption key needs to be iden-tified and given to the user.

• A doctor can only access 10 records per hour.

An abstract specification is created in Event-B to the correspondingactivity diagram presented in Figure 5.2 which describes the workflowassociated with the described functions.

The variable system_state is used to describe whether the system isidle, or currently busy. This is used to depict the authentication step ofthe workflow since the workflow can not occur without a user beingauthenticated. The flag variable is used to move the machine throughthe different phases of the workflow. Initially, the system is idle and


the current phase is set to authenticate. Then, when a user is authenti-cated the system moves to the request_record phase. When the requestfor access is made, the system moves to fetch_key before finalizing atthe add_to_log phase. The log variable contains tuples of the user id andthe record accessed, i.e. log ∈ P(USER_ID_SET × RECORDS). When-ever an access to a record is made, a log entry is appended to the logas modeled in the event add_to_log.

For the rate limiting, a variable number_records_counter is in-troduced. It is defined to be a total function from the DOC-TORS_ID_SET to the natural numbers, i.e. number_records_counter ∈DOCTORS_ID_SET→ N.

The rate limiting is further specified by an invariant indicating thatthe counter should never exceed 10 in the following way,∀ iu · iu ∈ DOCTORS_ID_SET⇒

number_records_counter(iu) ≤ 10.The counter is incremented for the active user at the time of access.

However, to avoid deadlock, it is also required to reset the counterafter 1 hour has passed. Since it is not possible to model time in Event-B, a non-deterministic event is used instead. For this the booleanvariable time_out is used. It is non-deterministically set to TRUE inthe time_is_out event. Continuing, the reset_counter event resets thecounter by making sure that the time_out variable is indeed TRUE andthat the role of the active user is a doctor. The whole Event-B specifi-cation is presented in Figure 5.7.


Machine readRecordMacSees readRecordContextVariablesactive_record, active_user, system_state,flag, current_key, log,number_records_counter, time_outInvariantsactive_record ∈ RECORDSactive_user ∈ USER_ID_SETsystem_state ∈ {idle, busy}flag ∈ {authenticate, request_record,

fetch_key, add_to_log}current_key ∈ KEYS_SETlog ∈ P(USER_ID_SET × RECORDS)number_records_counter ∈

DOCTORS_ID_SET→ N∀ iu · iu ∈ DOCTORS_ID_SET⇒

number_records_counter(iu) ≤ 10time_out ∈ BOOLEventsnew_user =

where system_state = idlethen system_state := busy

active_user :∈ USER_ID_SETflag := request_record

endrequest_to_read_record_p =

where flag = request_recordid_role(active_user) = patient

then active_record :=id_rec(active_user)

flag := fetch_keyend

request_to_read_record_d =

any record

where flag := request_recordid_role(active_user) = doctorrecord ∈ RECORDSnumber_records_counter(active_user) < 10

then active_record := recordflag := fetch_keynumber_records_counter(active_user) :=number_records_counter(active_user) + 1

endfetch_the_key =

where flag = fetch_keythen current_key :=

record_key(active_record)flag := add_to_log

endadd_to_log =

where flag := add_to_logthen log := log ∪

{active_user 7→ active_record}system_state := idleactive_user := noneactive_record := void

endreset_counter =

where flag 6= authenticatetime_out = TRUEid_role(active_user) = doctor

then number_records_counter := 0end

time_is_out =where time_out = falsethen time_out :∈ BOOLend

Figure 5.7: Event-B specification of the read record operation.

The context of the read record operation is presented in Figure 5.8.The id_rec relation is specified as a partial function from the user id


set to the records, i.e. id_rec ∈ USER_ID_SET 7→ ROLES since onlyusers with the role patient should have records. The relation is thenfurther defined by the id_rec_relation_1 axiom which states that everyuser which has a record is a patient, i.e. ∀ iu · id_role(iu)=patient⇒ iu∈ dom(id_rec). The DOCTORS_ID_SET is defined by the axioms doc-tors_relation_1 and doctors_relation_2 which states that all users in thedoctors id set are users with the role doctor.

The correctness of the models were verified by running 27 proofobligations which are proved automatically by the Rodin platform.

Context readRecordContextSets USER_ID_SET, KEYS_SET, RECORDS, ROLES, STATES, FLAGSConstants doctor, patient, record_key, id_role, id_rec, idle, busy, authen-ticate, request_record, fetch_key, add_to_log, log_entry, number_records,none, void, null, DOCTORS_ID_SETAxiomsrecord_key_relation : record_key ∈ RECORDS→ KEYS_SETid_role_relation : id_role ∈ USER_ID_SET→ ROLESid_rec_relation : id_rec ∈ USER_ID_SET 7→ ROLESrole_type : partition(ROLES,{doctor},{patient})state_type : partition(STATES,{idle},{busy})flag_type : partition(FLAGS,{authenticate},{request_record},{fetch_key},{add_to_log})log_type : log_entry ∈ P(USER_ID_SET × RECORDS)id_rec_relation_1 : ∀ iu · id_role(iu)=patient⇒ iu ∈ dom(id_rec)axm3 : none ∈ USER_ID_SETaxm4 : void ∈ RECORDSaxm5 : null ∈ KEYS_SETdoctors_relation_1 : DOCTORS_ID_SET ⊆ USER_ID_SETdoctors_relation_2 : ∀ iu · iu ∈ DOCTORS_ID_SET⇔ id_role(iu)= doc-tor

Figure 5.8: Event-B context of the read record operation.

Chapter 6

Security Analysis

Chapter 6 covers the security analysis. The security analysis is dividedinto analyzing the must-have and nice-to-have requirements sepa-rately. Each section is in turn divided into two. The first section an-alyzes all requirements that are directly supported by the architectureitself. The second part evaluates the remaining requirements based onhow well they mitigate the threat models. Must-have requirements areeither required by law or regulations, or required by general securityconventions to be considered secure. Should a must-have requirementnot be fulfilled, the solution design is deemed insufficient in that re-gard. Nice-to-have requirements are considered as additional perkswhich adds more value to the solution design. Not fulfilling a nice-to-have requirement does not deem the solution design insufficient.

6.1 Must-have Requirements

In total, 26 must-have requirements have been identified, see Figure3.2. They have been categorized into two groups depending on howthey are evaluated. Section 6.1.1 analyzes requirements which areevaluated in a “fulfilled” or “not fulfilled” fashion and explains howthey are supported by the solution design itself. Section 6.1.2 con-tains security requirements which are evaluated based on how wellthey mitigate the threat models. Given the threat model and the le-gal and functional constraints these requirements cannot be fulfilledcompletely.

44

CHAPTER 6. SECURITY ANALYSIS 45

6.1.1 Fully achievable requirements

Integrity is maintained if data has not been altered with after encryp-tion. This requirement is a direct property supported by using Ga-lois/Counter Mode (GCM). As previously stated, AES with GCM asthe mode of operation is used as the symmetric key algorithm. InGCM, the ciphertext is combined with an authentication code to pro-duce an authentication tag. This tag can be used to verify the integrityof the data. As per defined by Hyker, the authentication tag size usedis 128 bits, which is considered enough for several years ahead.

Authenticity, meaning that a record entry was legitimately enteredby the doctor in question, is also achieved through the use of GCM asdescribed above.

Non-repudiation, meaning that a user submitting a record entrycan not deny having done so, is achieved by using digital signatures.Through Hyker, a 2048 bit asymmetric key pair is generated usingRSA-PSS. A 2048 bit key size is considered secure for many yearsahead. Although a smaller key size, like 1024 bit, is considered se-cure for at least a few years ahead it would mean that new keys wouldhave to be generated more often than with a 2048 bit key size. Gener-ating new key pairs for every user is considered a more burdensomeprocess than just going with the 2048 bit key size from the beginning.Every keypair belongs to a doctor in the EHR app where the privatekey is only known to the corresponding doctor. Before a record entryis added to the EHR, the doctor encrypts the entry with a freshly gen-erated session key and then signs it using his private key. The PdS canthen use the public key of that key pair to validate the digital signature.Since the private key is only known to that doctor it can not have beensigned by anyone else. Furthermore, Hyker uses certificates in a pub-lic key infrastructure (PKI) fashion which ensures that key pairs arebound to identities through the key distribution system (KDS) whichenables any entity to get ahold of public keys. It is assumed that theKDS is secure and any possible vulnerabilities in the KDS are thereforenot accounted for.

Utility as a requirement will be considered fulfilled if all sensitivedata is encrypted. Although encrypting all sensitive data only implieslow utility it is something that is desirable for this somewhat abstractconcept. All patient data is encrypted at rest using AES-GCM gener-ated 256 bit symmetric keys. Longer keys means higher security but

46 CHAPTER 6. SECURITY ANALYSIS

less performance, which is why the symmetric session keys are signif-icantly shorter than the long term asymmetric keys.

Accountability is achieved through auditing as described in section3.2.1. For auditing to be effective it also requires complete logs. Thelog in the solution design makes sure to capture all CRUD accesses andeach entry contains enough information such that who, what, when,where, why and how an event occurred can be answered.

Two factor authentication should be used as the authenticationmethod. It is achieved by using BankID which demands a user topossess a certain device and insert a PIN code to authenticate to theEHR app. Note that while different 2FA methods may vary in the se-curity they provide, any other way of enforcing 2FA is also consideredenough for the sake of fulfilling this requirement. Being the leadingeID in Sweden, BankID is considered to be secure. Furthermore, thechoice of BankID is further motivated by that most people in Swedenalready have it.

Configuring the authentication level of each user is done at cre-ation time. This is done using RBAC, where permissions are basedon the role that has been assigned to a user. RBAC is very commonin previous EHR systems and is deemed a good fit for the healthcareenvironment. The different roles are presented in section 2.3.

The PdS makes sure that backup copies are stored in a separatedatabase. The keys to the backup copies are stored in a separate HSM.This means that if the main HSM were to break down or get destroyedin any way, there would be another HSM available that can be used toretrieve the backup copies. Since EHRs contain sensitive data and areupdated on a daily basis the backup frequency needs to be quite highin case of issues.

Being able to block parts of one’s own record as a patient is simplya functionality requirement. A patient can do this by logging in to theEHR app using BankID.

The EHR app lets doctors see if a patient exist at another caregiver.The app forces doctors to undergo two active choices before providinginformation regarding which caregiver the patient is present at. In asimilar way the EHR app requires doctors to perform an active choicebefore granting them access to NPÖ.

The logs include everything listed in Figure 5.6. Timestamp anduser id fulfills the requirement of including who and when an edit oraccess was made. Since identification of the information that is ac-


cessed covers the parts of the EHR that was accessed and not the pa-tient identity, the logs are extended to also include a patient id. Thepatient identity is recognized as the personal identification number ofthe patient the EHR belongs to. Source of access contains the care unitfrom which the access was made.

The requirement that a clinical worker has right to access an EHR ifthey are involved in the caregiving of the patient or for any other rea-son, such as quality assurance, administration or for statistical reasonsis fulfilled by not having any strict technical blockade in place in theEHR app. Due to the abstractness of understanding when a clinicalworker has access or not, having a strict blockade in place is not prac-tical. Solutions like having a head of activity approve every request foraccess is not scalable and allowing access upon assignment of patientdoes not include regulations for changes in care relationships. Again,the difficulty lies in determining when there is an ongoing care rela-tionship and when there is not.

Legally, as long as a doctor is contributing with their knowledgein connection with caregiving it is considered as a care relationship.Although this implies that anonymization of the patient data is notrequired, applying anonymization would increase the privacy of thepatient. Doctors need to be able to share patient data between eachother in their work, but not the identity of a patient. The solutiondesign allows doctors to share anonymized patient data by strippingoff all information that can identify the patient. However, this does notnecessarily mean that it is impossible to re-identify the patient. Again,anonymization is not a requirement and thus analysing the level ofprivacy it achieves is out of scope.

The EHR app allows for patient data to be accessible to other care-givers through NPÖ. Patient data made publicly available throughNPÖ is end-to-end encrypted from the EHR app to the NPÖ ser-vice using Hyker. Other healthcare providers do not connect to thetelemedicine EHR app directly, but instead gets access to EHRs viaNPÖ. Essentially, E2EE is ensured between the EHR app and all doc-tors, as well as between the EHR app and NPÖ. The EHR app isnot responsible for the security from NPÖ to the other healthcareproviders. Furthermore, a patient can access their own record by log-ging in through BankID. Since all accesses are stored in the logs it isalso possible for a patient to see who has accessed their record.

Lastly, the EHR app requires a doctor to sign a record entry before


continuing. The signature is given using BankID. Before signing, adoctor should make sure that everything looks correct. As per the law,there are exceptional cases where a signature is not required. This hap-pens when it is practically impossible to do so which is not expectedto happen in a telemedicine environment.

6.1.2 Partially Achievable Requirements

Confidentiality is achieved by using E2EE. This effectively mitigatesthe insider passive adversary. This adversary can monitor all trafficon the internal network, but since E2EE is used, the data is useless.Should the adversary manage to additionally compromise a networkhub or any other intermediate node, the data would still be uselessfor the adversary. This is as opposed to if IPSEC or TLS would havebeen used as the encryption protocol. In that case the data wouldbe in plaintext at every intermediate node. With that said, perfectforward secrecy is not a property Hyker supports and could thus beabused. If the insider passive adversary records all encrypted commu-nication, and then later manages to compromise a long-term privatekey, the adversary could decrypt all recorded data that is connected tothe same doctor. This type of attack would not be possible if an E2EEprotocol with PFS, like Signal, was used. However, Signal does notprovide retroactive access which is required for a healthcare systemwhere accesses to EHRs can not be known beforehand. The impact ofa compromised private key by the insider passive adversary becomesgreater depending on how long the adversary has been able to recorddata. Furthermore, by compromising the private key, the adversarycould masquerade as the doctor it belongs to and compromise futurecommunication. A single session key can only decrypt data whichhave been encrypted under that session key and thus does not comeclose to the impact of historical attacks where hundreds of thousandsof records have been disclosed. Should several session keys belong-ing to different doctors be compromised the insider passive adversarywould be able to decrypt more data, but still a limited amount in com-parison. Also, although it can not be completely disregarded, such anevent is deemed unlikely. Continuing, assuring confidentiality againstthe honest-but-curious and the outsider malicious adversaries requiresmore than just encrypting data.

There is no blockade in place in the EHR app which denies access


for a doctor. The honest-but-curious doctor can theoretically accessany EHR he or she wants. Although there are strict policies in placewhich forbids doctors to access records of patients whom they do nothave an ongoing care relationship with, more is required to further de-motivate an honest-but-curious doctor. This is where the logs and au-diting come into effect. Having complete logs with effective auditingdecreases the probability that any deviate behaviour goes unnoticed.Another goal of having logs is that by informing all employed doctorsthat audit logging is practiced they should be further de-motivated toperform such unethical and illegal actions.

The outsider malicious can, in a similar way as the honest-but-curious adversary, access any EHR record in the system. However,the crypto anchor both enforces the adversary to operate within thesystem environment and applies rate limiting. Each doctor account,i.e. user id, is limited to 10 EHR accesses every hour. Since the averagemeeting length for a doctor’s appointment is around 15 minutes it isnot expected that much more than four EHR accesses per hour has tobe made. There can be cases where more accesses are required, thereofthe soft upper limit. This strictly and effectively limits the capabil-ities of the outsider malicious adversary. Without the rate limiting,the adversary could download and disclose hundreds of thousands ofpatient records in the matter of minutes. Similarly to the honest-but-curious, effective audit logging further limits the capabilities of theoutsider malicious adversary. Note that even if the limitation of 10 ac-cesses per hour proves to be too strict, doubling it to 20 still is nowherenear the impact an adversary could have without rate limiting in place.

Availability is ensured by making use of cloud storage, as opposedto local storage. As long as a doctor has internet access and authenti-cates to the EHR app, the doctor will have access to the EHRs. In cloudstorage, the servers are located in geographically different areas. Thisway, data is not lost if a natural disaster would occur. The honest-but-curious adversary has no interest in disrupting the availability of thesystem. However, the outsider malicious could threaten the availabil-ity by modifying existing EHR records. Nevertheless, since all edits arelogged and no data is completely erased upon a deletion event, it canbe restored back to normal if the outsider malicious adversary wereto try to disrupt the availability. Although, if there is an emergencyand the record has not been restored back to normal the consequencescould potentially be devastating. However, it is deemed highly un-


likely that an event of that sort would occur. Nevertheless, it could bemotivated to introduce additional security measures to prevent suchan event from ever happening.

Since possession concern the protection of the physical device itis not directly covered by the proposed solution architecture. How-ever, managing to violate the possession requirement is one way forthe outsider malicious and the insider passive to get the access theydo. If an adversary manages to authenticate as a doctor with 2FA inplace, it is more likely that the adversary possesses the doctor’s device(and knows the passcode) rather than using an exploit to bypass thedigital signature scheme, in this case BankID. Although how the threatmodels manages to get access generally is out of scope of this thesis,doing so by violating the possession requirement will be considered.Preventing loss of devices such as computers and phones is mainlyachieved through company wide policies. First of all, every deviceshall be encrypted and login preceded by a strong password. Secondly,it shall be ensured that every device is locked when not used. This isdone by having a short time frame, like 60 seconds, before the com-puter is automatically locked and a policy stating that no laptop shallbe left unlocked if unsupervised. Additionally, countermeasures suchas denying unauthorized people physical access to the office while stillallowing guests to visit further decreases the probability of a devicegetting in the wrong hands. Should someone manage to get past thefirst perimeter and walk around freely in the office, the automatic lock-ing policies just described makes sure that the adversary is unlikely tofind any unlocked computers.

The logs makes sure to answer all the necessary questions of who,what, when, where, why and how an event occurred. It also makessure to cover emergency cases by capturing such accesses as BTG sce-narios. The case scenarios serve as a standpoint to how well the log-ging mechanism will mitigate the honest-but-curious adversary butwith that also the outsider malicious adversary. For auditing to beefficient, the case scenarios considered as legit accesses must be differ-entiated from the case scenario describing an illegal access.

Although every attribute of every log entry is required and servesits purpose, the most important to consider when evaluating the casescenarios is the attribute reason for access. This attribute is what pro-vides a first type of warning to the auditor. Considering case scenario1A the reason for access will be set to Care relationship since doctor A


has been assigned patient P. In the context of the log entry, when theuser id of doctor A accesses the EHR belonging to the personal identi-fication number of patient P there is an ongoing care relationship andthus the reason for access is automatically set to that.

With that in mind, the log entry for doctor A in case scenario 2Awill be similar to the one above. However, since doctor B has no on-going care relationship with patient P, the reason for access will be setto Unknown when doctor B accesses the EHR of patient P. When an ac-cess is made for an unknown reason, a warning flag is raised for theauditor who will be able to review the actions of doctor B. Upon re-viewing, the auditor will get the answers to all necessary questions tobe able to identify if the action was indeed illegal and who the doctorwas that acted inappropriately. The doctor will then be up for hearingand appropriate actions can be taken accordingly.

Case scenarios 1B and 2B are very similar to case scenario 1A inthe context of log entries. In case scenario 1B patient P is assigned todoctor B and from that point on there is legally an ongoing care rela-tionship and can thus be noted as such in the log entry as reason foraccess. Scenario 2B is a little bit different in the sense that doctor Adecides to access the EHR of patient P although patient P was reas-signed to doctor B. However, since this is often done for quality workthe reason for access will be noted as such.

The requirement that logs shall be saved for a minimum of 5 yearsis ensured by the workflow presented in Figure 5.5. Only the adminis-trator or the head of activity is allowed access, although the separationof privilege is the largest safety mechanism in place. Neither of thethreat models could access or modify the logs in any way. Addition-ally, should the outsider malicious adversary manage to authenticateas the head of activity, the adversary still would not be able to modifythe logs. Since the logs are stored in the cloud there is no control overthe physical servers. This requires that some trust is put in the cloudservice provider that they do not go ahead and delete data on theirown.

Records shall never be modified or destroyed unless there is sup-port from PDL. That exception essentially means that the Health andSocial Care Inspectorate can, upon request from an individual, decideto have a record destroyed. Since this exception can not be reasonablyabused it will be mostly disregarded for the sake of this thesis. Further-more, records shall be kept for a minimum of 10 years after the last


record entry was made. Having backup copies of the health recordsmakes sure that if one database gets compromised, destroyed or ob-structed in any way there is another one to back it up. However, therecould be some issues with backups. For example, by having anotherbackup copy around it could be tampered with and thus endanger therestoring process.

The outsider malicious adversary could pose a threat to this re-quirement. Since this adversary has managed to authenticate as a doc-tor, the adversary is able to edit and can therefore modify records.However, since a record shall never be destroyed, the only way todelete a record would be through direct access to the database asshown in fig 5.5. Although the adversary can not destroy an EHR inits entirety, it would be possible through the editing function to erasedata in EHRs. Still, since every action is logged, it would be possibleto recover the data that was erased. Nevertheless, this could have con-sequences up until the point it is noticed and the records are restoredback to normal again.

To include the unique cases of when records can be destroyed, therecords are not completely gone upon decision of removal. First, therights to access are revoked, meaning the record itself still exists. Firstafter some time has passed, the record is completely destroyed andrendered irrecoverable. This enables the possibility to regret the deci-sion for some time.

6.2 Nice-to-have Requirements

Requirements classified as nice-to-have have been identified from theISO/IEC 27001 standard. Some nice-to-have requirements are alreadycovered by must-have requirements and thus overlap. For this rea-son, the nice-to-have requirements can be narrowed down to the fourrequirements plainly written in Figure 3.2.

6.2.1 Classification and Policy

All information should be classified in terms of value and sensitivity.This requirement is only about classifying information and not aboutclassifying in a certain way. The proposed solution treats all patientdata as sensitive and thus the requirement is fulfilled.


Having an access control policy is nothing more than it entails. Aslong as an access control policy is in place the requirement is fulfilled.The solution design uses RBAC as the access control policy. Note thatany other access control model still fulfills the requirement.

6.2.2 Secure Key Management and Log Tamper Re-sistance

Secure key management involves the protection of the cryptographickeys during their whole lifecycle. The HSM is responsible for man-aging the keys. As per the properties of an HSM, any penetration at-tempt causes the HSM to delete all stored keys, although it can dependon the security level of the HSM used. The Federal Information Pro-cessing standard 140-21 is a standard for cryptographic modules. Thestandard defines four different security levels that an HSM can have,where level 4 is considered to provide the highest level of security andlevel 1 the lowest. Leveraging an HSM in the cloud provided by e.g.AWS, the validated security level would be 2 overall and level 3 forsome categories2. An issue with HSMs is that one can not take backupcopies of the keys inside an HSM. However, by making use of a secondHSM, which contains all the keys for the backup copies, these keys arenot lost if the first HSM is destroyed or compromised in any way.

Defense against tampering of logs is achieved by applying separa-tion of privelege as described in Figure 5.5. So far, only the administra-tor and the head of activity can get direct access to the logs. Wheneverone of the parties wants access, consent is required from the oppos-ing party. The opposing party makes sure that the request is legit byorally consulting the initiator, either physically, through a phone callor VoIP. Although it can be considered as quite a burdensome process,it is not expected that frequent direct access to the logs is required. Thedesign effectively mitigates the honest-but-curious adversary since thedoctor login has no way of getting access. Same goes for the outsidermalicious adversary, and even if the adversary would manage to au-thenticate as an admin, it still wouldn’t be enough. The admin can notsolely get direct access to the logs. When such an adversary makes arequest to get access, the head of activity would consult with the real

1https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf2https://csrc.nist.gov/projects/cryptographic-module-validation-

program/Certificate/3139


administrator and realize that it is a malicious request and thus denyit.

Chapter 7

Conclusion

Chapter 7 draws conclusions based on the security analysis andpresents what is left to investigate for future work.

7.1 Evaluation

Hyker has supposedly been evaluated by Combitech who through asecurity analysis achieved great results. Since it has not been possibleto access the analysis in any way, it is difficult to be convinced thatHyker is as secure as it states. While the cryptographic algorithmsused are recommended by NIST with no known attacks that are com-putationally feasible, it is unknown whether parts of Hyker, like theKDS, has any vulnerabilities. This lowers the credibility of Hyker, butfor this thesis it is assumed that the security analysis can be trustedand that Hyker has no vulnerabilities. Essentially, this means that it isassumed that the Hyker KDS has secure public key distribution anda secure revocation client. Also, it is assumed that the client standarddevelopment kit and the symmetric key broker service are secure.

While the exact number can not be provided, the largesttelemedicine provider in Sweden today is far away from 1000 meet-ings an hour, which basically means one meeting every 3.6 seconds.Arguably, evaluating the performance of the architecture becomesimportant when there are several EHR accesses every second. Forthis reason, performance is not important to consider at this stage oftelemedicine applications.

55

56 CHAPTER 7. CONCLUSION

7.1.1 Ethics and sustainability

The requirements identified for this thesis comes from the perspectiveof establishing a high patient security. However, it could be justified tolook beyond the strict requirements set up by the government. Froman ethical viewpoint, a patient may be concerned about keeping theirhealth information private. For this reason, the honest-but-curiousthreat model is highly relevant when designing an architecture for anEHR system.

From a technical standpoint there could be unethical installationssuch as backdoors in Hyker. A private company implementing a back-door could pose a large threat but is also considerably unethical.

The importance of a secure EHR system for a telemedicine provideris of high importance for the society to not lose trust in the care-givingas a whole. In Sweden, and in many other countries, a lot of tax moneyis put into creating a good care-giving environment and it is thus ex-pected that the healthcare delivered is of high standards.

7.2 Conclusion

The conclusion is that almost all requirements are fulfilled in their en-tirety. Although confidentiality is deemed fulfilled in the context ofa law and regulation requirement, confidentiality can not be fully en-sured under the given main threat models. The insider passive ad-versary is effectively mitigated through the use of encryption, but itis still possible for the honest-but-curious and the outsider maliciousadversaries to violate confidentiality by accessing records they are notallowed to. For the outsider malicious adversary it happens when theadversary manages to impersonate a doctor, by for example findingan unprotected device or by hijacking BankID. Basically, the extent towhich confidentiality can be fulfilled is limited by the legal require-ment of emergency access. However, audit logging, crypto anchor-ing and rate limiting combined limits the capabilities of the two mainthreat models, so that the number of records that can possibly be dis-closed is heavily confined. Also, audit logging and crypto anchoringincreases the probability of noticing abnormal behaviour and thus de-creases the time an adversary can operate before getting caught andevicted from the system.

Availability and protection against destruction of logs and records

CHAPTER 7. CONCLUSION 57

reach a high degree of security. Through cloud storage and separationof privilege it is extremely unlikely that any abuse would be possibleand definitely not under any of the three threat models.

Although this work considers the outsider malicious adversary asone of the main threat models, it is of course desired to prevent anadversary from even getting access to the system. However, there al-ready exist a substantial amount of previous work regarding preven-tative measures against such adversaries and is thus out of scope ofthis thesis.

Doctors and clinical workers are known to often live strongly bytheir values. By making use of effective audit logging, doctors are fur-ther demotivated to perform any illegal actions since the risk of gettingcaught is significantly higher than when auditing is not practiced.

All nice-to-have requirements which do not already overlap withmust-have requirements are fulfilled. The crypto anchor provides se-cure key management and there is a high degree of resistance againsttampering of logs. The separation of privilege rule enforces access todepend on two separate instances of users.

7.3 Future Work

For future work it would be interesting to test the performance of thearchitecture and especially the performance of Hyker when used forencryption of EHRs with hundreds of thousands of patients. It wouldbe interesting to see the scalability as the telemedicine grows withmore clinical workers and patients involved. The number of keyscached by the PdS for retroactive access could be reduced by lettingthe session key used for the last record entry encrypt the whole EHR.However, that could create some computational overhead and inves-tigating that could be interesting.

Since it was not possible to access the security analysis one shouldmake sure to get access to all the information needed about Hyker sothat the security assumptions made for this thesis can be verified. Ifit is possible, one should first make sure to evaluate Hyker by doinga formal analysis of the protocol before implementing it. If that is notpossible, Hyker should probably be replaced by another encryptionservice or protocol. No other protocol with the E2EE and retroactiveaccess properties could be found for this thesis. Also, most E2EE pro-

58 CHAPTER 7. CONCLUSION

tocols are aimed towards messaging services, such as Signal, ZRTP orTox. However, since E2EE is not a required property, Amazon Rela-tional Database Service and Key Management Service with a hop-by-hop encryption protocol like TLS could be used instead. Then again,this would leave the data unencrypted at intermediate nodes.

While Signal is unfeasible for encryption of EHRs it could be inter-esting to see how it would work as the E2EE protocol when doctorsshare patient data between each other. It could potentially strengthenthe security of such an architecture by enabling perfect forward se-crecy for that workflow.

A better approximation of the rate limiting could be analyzed.Looking at the average number of patients per doctor the number issomewhere around three to four patients per hour. Setting a lowerboundary on the number of accesses, without interfering with doctorwork, could enhance the confidentiality of the patient data even fur-ther.

Investigating the effectiveness audit logging has on the honest-but-curious adversary could be interesting. Analyzing the effect of auditlogging could further strengthen the need for even better auditing.Also, finding additional improvements or fine-tuning of the loggingmechanism would further reduce the overhead and false positives forthe auditor.

It would be interesting to analyse the design using other honest-but-curious adversaries based on different stakeholders. In what waycan customer support, medical operations or developers abuse theirrole? Is the audit logging sufficient enough to capture abuse of qualitycheckups from other roles? Analysing the solution design based onthese questions could be interesting.

Bibliography

[1] Finansiell ID-Teknik BID AB. This is BankID. URL: https://www.bankid.com/en/om- bankid/detta- ar- bankid(visited on 05/02/2018).

[2] Jean-Raymond Abrial. Modeling in Event-B: System and SoftwareEngineering. 1st. New York, NY, USA: Cambridge UniversityPress, 2010. ISBN: 0521895561, 9780521895569.

[3] Advanced Encryption Standard (AES). Standard. National Instituteof Standards and Technology, Nov. 2001. DOI: https://dx.doi.org/10.6028/NIST.FIPS.197.

[4] Abdullah Albeyatti. Medicalchain. White paper 2.1. Tech. rep.Medicalchain, 2018.

[5] Z. Alhadhrami et al. “Introducing blockchains for healthcare”.In: 2017 International Conference on Electrical and Computing Tech-nologies and Applications (ICECTA). Nov. 2017, pp. 1–4. DOI: 10.1109/ICECTA.2017.8252043.

[6] Jason Andress. The Basics of Information Security. Understandingthe Fundamentals of InfoSec in Theory and Practice. Second. Syn-gress, 2014.

[7] Ida Aspnor and Elin Sandell. Journalsystemet TakeCare - En studieav funktioner utifrån ett informationssäkerhets- och användarperspek-tiv. Tech. rep. Södertörn University, 2012.

[8] Asaph Azaria et al. “Medrec: Using blockchain for medical dataaccess and permission management”. In: Open and Big Data(OBD), International Conference on. IEEE. 2016, pp. 25–30.

[9] Towe Boström. Kry ska bredda vården - tar in 200 miljoner kronor.June 2017. URL: https : / / www . breakit . se / artikel /8115 / kry - ska - bredda - varden - tar - in - 200 -miljoner-kronor (visited on 02/12/2018).

59

https://www.bankid.com/en/om-bankid/detta-ar-bankid

https://www.bankid.com/en/om-bankid/detta-ar-bankid

https://doi.org/https://dx.doi.org/10.6028/NIST.FIPS.197

https://doi.org/https://dx.doi.org/10.6028/NIST.FIPS.197

https://doi.org/10.1109/ICECTA.2017.8252043

https://doi.org/10.1109/ICECTA.2017.8252043

https://www.breakit.se/artikel/8115/kry-ska-bredda-varden-tar-in-200-miljoner-kronor



60 BIBLIOGRAPHY

[10] Tony Campbell. Practical Information Security Management.Springer, 2017. ISBN: 978-1-4842-1685-9.

[11] Q. Chen and J. Lambright. “Towards Realizing a Self-ProtectingHealthcare Information System”. In: 2016 IEEE 40th Annual Com-puter Software and Applications Conference (COMPSAC). Vol. 1.June 2016, pp. 687–690. DOI: 10.1109/COMPSAC.2016.264.

[12] Q. Chen, J. Lambright, and S. Abdelwahed. “Towards Auto-nomic Security Management of Healthcare Information Sys-tems”. In: 2016 IEEE First International Conference on Con-nected Health: Applications, Systems and Engineering Technologies(CHASE). June 2016, pp. 113–118. DOI: 10.1109/CHASE.2016.58.

[13] Privacy Rights Clearinghouse. Data Breaches. URL: https://www . privacyrights . org / data - breaches (visited on02/01/2018).

[14] Katriel Cohn-Gordon et al. “A formal security analysis of thesignal messaging protocol”. In: Security and Privacy (EuroS&P),2017 IEEE European Symposium on. IEEE. 2017, pp. 451–466.

[15] Facebook Developers. Exfiltration Resistant Infrastructure, Square -Security @ Scale 2014. Presentation by Diogo Monica and NathanMcCauley. Feb. 2014. URL: https://www.youtube.com/watch?v=lrGbK6fE7bI (visited on 02/22/2018).

[16] eugdpr.org. GDPR Key Changes. URL: https://www.eugdpr.org/key-changes.html (visited on 02/09/2018).

[17] Daniel Fabbri, Kristen LeFevre, and David A. Hanauer. “Ex-plaining Accesses to Electronic Health Records”. In: Proceedingsof the 2011 Workshop on Data Mining for Medicine and Healthcare.DMMH ’11. San Diego, California, USA: ACM, 2011, pp. 10–17.ISBN: 978-1-4503-0843-4. DOI: 10.1145/2023582.2023585.URL: http://doi.acm.org.focus.lib.kth.se/10.1145/2023582.2023585.

[18] José Luis Fernández-Alemán et al. “Security and privacy in elec-tronic health records: A systematic literature review”. In: Journalof Biomedical Informatics 46.3 (2013), pp. 541–562. ISSN: 1532-0464.DOI: https://doi.org/10.1016/j.jbi.2012.12.003. URL: http://www.sciencedirect.com/science/article/pii/S1532046412001864.

https://doi.org/10.1109/COMPSAC.2016.264

https://doi.org/10.1109/CHASE.2016.58

https://doi.org/10.1109/CHASE.2016.58

https://www.privacyrights.org/data-breaches

https://www.privacyrights.org/data-breaches

https://www.youtube.com/watch?v=lrGbK6fE7bI

https://www.youtube.com/watch?v=lrGbK6fE7bI

https://www.eugdpr.org/key-changes.html

https://www.eugdpr.org/key-changes.html

https://doi.org/10.1145/2023582.2023585

http://doi.acm.org.focus.lib.kth.se/10.1145/2023582.2023585


https://doi.org/https://doi.org/10.1016/j.jbi.2012.12.003

https://doi.org/https://doi.org/10.1016/j.jbi.2012.12.003

http://www.sciencedirect.com/science/article/pii/S1532046412001864

http://www.sciencedirect.com/science/article/pii/S1532046412001864

BIBLIOGRAPHY 61

[19] Gideon Greenspan. MultiChain Private Blockchain. White paper.Tech. rep. Coin Sciences Ltd, 2015.

[20] Anna Hedin and C Martin. “En liten lathund om kvalitativmetod med tonvikt på intervju”. In: Klerfelt, Anna & Qvarsell, Bir-gitta (red.)(2012). Kultur, estetik och barns rätt i pedagogiken 1 (1996).

[21] Hyker. End-to-End Lifecycle Encryption. URL: https://hyker.io/e2ee (visited on 02/26/2018).

[22] Hyker. Hyker Data Lifecycle Security. URL: https://hyker.io/(visited on 02/22/2018).

[23] Inera. Nationell patientöversikt. URL: https://www.inera.se/tjanster/nationell- patientoversikt- npo/ (visitedon 02/09/2018).

[24] Information technology - Security techniques - Information securitymanagement systems - Requirements (ISO/IEC 27001:2013 includingCor 1:2014 and Cor 2:2015). Standard. International Organizationfor Standardization, Mar. 2017.

[25] Eric Horvitz Josh Benaloh Melissa Chase and Kristin Lauter.“Patient Controlled Encryption: Ensuring Privacy of ElectronicMedical Records”. In: Cloud computing security. ACM. Chicago,Nov. 2009, pp. 103–114.

[26] Ingemar Karlsson Gadea. Din Journal. Jan. 2015. URL: https://www.1177.se/Stockholm/Regler-och-rattigheter/Patientjournalen/#section-9 (visited on 02/22/2018).

[27] Jason King and Laurie Williams. “Log Your CRUD: Design Prin-ciples for Software Logging Mechanisms”. In: Proceedings of the2014 Symposium and Bootcamp on the Science of Security. HotSoS’14. Raleigh, North Carolina, USA: ACM, 2014, 5:1–5:10. ISBN:978-1-4503-2907-1. DOI: 10.1145/2600176.2600183. URL:http://doi.acm.org.focus.lib.kth.se/10.1145/2600176.2600183.

[28] Sabine Koch. “Säkra den elektroniska journalen! Bättre e-journalsystem kan bidra till bättre patientsäkerhet”. In: Läkartid-ningen (May 2014;111;CU39).

https://hyker.io/e2ee

https://hyker.io/e2ee

https://hyker.io/

https://www.inera.se/tjanster/nationell-patientoversikt-npo/

https://www.inera.se/tjanster/nationell-patientoversikt-npo/

https://www.1177.se/Stockholm/Regler-och-rattigheter/Patientjournalen/#section-9



https://doi.org/10.1145/2600176.2600183



62 BIBLIOGRAPHY

[29] Johan Kvastad. “ICT Security of an Electronic Health RecordSystem: an Empirical Investigation. An in depth investigation ofICT security in a modern healthcare system”. MA thesis. KTHRoyal Institute of Technology, 2016.

[30] RSA Laboratories. PKCS #1 v2.2 RSA Cryptographic Standard. Oct.2012. URL: https://www.emc.com/collateral/white-papers / h11300 - pkcs - 1v2 - 2 - rsa - cryptography -standard-wp.pdf (visited on 04/27/2018).

[31] Ming Li et al. “Scalable and secure sharing of personal healthrecords in cloud computing using attribute-based encryption”.In: IEEE transactions on parallel and distributed systems 24.1 (2013),pp. 131–143.

[32] Laure A. Linn and Martha B. Koo. Blockchain For Health Dataand Its Potential Use in Health IT and Health Care Related Research.Tech. rep. 2016. URL: https://www.healthit.gov/sites/default/files/11-74-ablockchainforhealthcare.pdf.

[33] Cecilia Lundberg. “Hur fungerar vårdens IT-system egentligen?Jämförelse av elektroniska patientjournalsystem”. MA thesis.Uppsala Universitet, Feb. 2011.

[34] Stathis Mavrovouniotis and Mick Ganley. “Hardware SecurityModules”. In: Secure Smart Embedded Devices, Platforms and Ap-plications. Ed. by Konstantinos Markantonakis and Keith Mayes.New York, NY: Springer New York, 2014, pp. 383–405. ISBN: 978-1-4614-7915-4. DOI: 10.1007/978-1-4614-7915-4_17. URL:https://doi.org/10.1007/978-1-4614-7915-4_17.

[35] Diogo Monica. Crypto Anchors: Exfiltration Resistant Infrastruc-ture. Oct. 2017. URL: https://diogomonica.com/2017/10/08/crypto- anchors- exfiltration- resistant-infrastructure/ (visited on 02/12/2018).

[36] Mohamed Nabeel. “The Many Faces of End-to-End Encryptionand Their Security Analysis”. In: Edge Computing (EDGE), 2017IEEE International Conference on. IEEE. 2017, pp. 252–259.

[37] Sveriges Riksdag. Patientdatalag (2008:355). 2008. URL: http://www.riksdagen.se/sv/dokument-lagar/dokument/svensk - forfattningssamling / patientdatalag -2008355_sfs-2008-355 (visited on 02/05/2018).

https://www.emc.com/collateral/white-papers/h11300-pkcs-1v2-2-rsa-cryptography-standard-wp.pdf



https://www.healthit.gov/sites/default/files/11-74-ablockchainforhealthcare.pdf



https://doi.org/10.1007/978-1-4614-7915-4_17

https://doi.org/10.1007/978-1-4614-7915-4_17

https://diogomonica.com/2017/10/08/crypto-anchors-exfiltration-resistant-infrastructure/



http://www.riksdagen.se/sv/dokument-lagar/dokument/svensk-forfattningssamling/patientdatalag-2008355_sfs-2008-355




BIBLIOGRAPHY 63

[38] Rodin: Event-B platform. URL: http://www.event-b.org/(visited on 05/18/2018).

[39] Rodin User’s Handbook v.2.8. URL: http://www3.hhu.de/stups/handbook/rodin/current/html/index.html(visited on 05/18/2018).

[40] James Mullock Ruth Boardman and Ariane Mole. Bird&Bird&guide to the General Data Protection Regulation. URL: https://www.twobirds.com/~/media/pdfs/gdpr-pdfs/bird--bird-- guide- to- the- general- data- protection-regulation.pdf?la=en (visited on 02/09/2018).

[41] Bruce Schneier. Another New AES Attack. 2009. URL: https :/ / www . schneier . com / blog / archives / 2009 / 07 /another_new_aes.html (visited on 06/21/2018).

[42] M. A. Al-Shaher, R. T. Hameed, and N. Tapus. “Protect health-care system based on intelligent techniques”. In: 2017 4th Inter-national Conference on Control, Decision and Information Technolo-gies (CoDIT). Apr. 2017, pp. 0421–0426. DOI: 10.1109/CoDIT.2017.8102628.

[43] Natasha Singer. Apple, in Sign of Health Ambitions, Adds MedicalRecords Feature for iPhone. Jan. 2018. URL: https://mobile.nytimes . com / 2018 / 01 / 24 / technology / Apple -iPhone-medical-records.html (visited on 01/30/2018).

[44] Socialstyrelsen. Frågor och svar om patientdatalagen. URL: http:/ / www . socialstyrelsen . se / fragorochsvar /patientdatalagen (visited on 02/07/2018).

[45] Socialstyrelsen. Journalföring och behandling av personuppgifteri hälso- och sjukvården. 2017. URL: https : / / www .socialstyrelsen . se / Lists / Artikelkatalog /Attachments / 20494 / 2017 - 3 - 2 . pdf (visited on02/05/2018).

[46] Ian Sommerville. Formal Specification. 2009. URL: https : / /ifs . host . cs . st - andrews . ac . uk / Books / SE9 /WebChapters/PDF/Ch_27_Formal_spec.pdf (visited on05/24/2018).

http://www.event-b.org/

http://www3.hhu.de/stups/handbook/rodin/current/html/index.html

http://www3.hhu.de/stups/handbook/rodin/current/html/index.html

https://www.twobirds.com/~/media/pdfs/gdpr-pdfs/bird--bird--guide-to-the-general-data-protection-regulation.pdf?la=en




https://www.schneier.com/blog/archives/2009/07/another_new_aes.html



https://doi.org/10.1109/CoDIT.2017.8102628

https://doi.org/10.1109/CoDIT.2017.8102628

https://mobile.nytimes.com/2018/01/24/technology/Apple-iPhone-medical-records.html



http://www.socialstyrelsen.se/fragorochsvar/patientdatalagen



https://www.socialstyrelsen.se/Lists/Artikelkatalog/Attachments/20494/2017-3-2.pdf



https://ifs.host.cs.st-andrews.ac.uk/Books/SE9/WebChapters/PDF/Ch_27_Formal_spec.pdf



64 BIBLIOGRAPHY

[47] Laurent Sustek. “Hardware Security Module”. In: Encyclopediaof Cryptography and Security. Ed. by Henk C. A. van Tilborg andSushil Jajodia. Boston, MA: Springer US, 2011, pp. 535–538. ISBN:978-1-4419-5906-5. DOI: 10.1007/978-1-4419-5906-5_509. URL: https://doi.org/10.1007/978-1-4419-5906-5_509.

[48] A Ubale Swapnaja, G Modani Dattatray, and S Apte Sulabha.“Analysis of dac mac rbac access control based models for secu-rity”. In: Analysis 104.5 (2014).

[49] Mohammad Al-Ubaydli. Personal Health Records: A Guide forClinicians. John Wiley & Sons, Mar. 2011.

[50] Vårdgivarguiden. Sammanhållen journalföring. 2015. URL:https://www.vardgivarguiden.se/globalassets/avtal-uppdrag/it-stod-och-e-tjanster/sjf---sammanhallen - journalforing / information _vardpersonal _ sjf _ sll . pdf ? IsPdf = true (visitedon 02/05/2018).

[51] Lidong Wang and Cheryl Ann Alexander. “Applications of Au-tomated Identification Technology in EHR/EMR”. In: Interna-tional Journal of Public Health Science 2 (2013), pp. 109–122.

[52] WhatsApp. WhatsApp Encryption Overview. Technical white paper.Tech. rep. Dec. 2017.

[53] C. Wickramage et al. “Challenges for Log Based Detection ofPrivacy Violations during Healthcare Emergencies”. In: GLOBE-COM 2017 - 2017 IEEE Global Communications Conference. Dec.2017, pp. 1–6. DOI: 10.1109/GLOCOM.2017.8254433.

https://doi.org/10.1007/978-1-4419-5906-5_509

https://doi.org/10.1007/978-1-4419-5906-5_509

https://doi.org/10.1007/978-1-4419-5906-5_509

https://doi.org/10.1007/978-1-4419-5906-5_509

https://www.vardgivarguiden.se/globalassets/avtal-uppdrag/it-stod-och-e-tjanster/sjf---sammanhallen-journalforing/information_vardpersonal_sjf_sll.pdf?IsPdf=true




https://doi.org/10.1109/GLOCOM.2017.8254433

Appendix A

Interview questions

65

66 APPENDIX A. INTERVIEW QUESTIONS

User questionsThe questions used to identify how each EHR system user interactswith the EHRs were asked in Swedish. Below are the translations.

1. What is your role?

2. How do you use EHRs and what do you use them for?

3. Is there another role that is similar to yours, but differs a bit andthat you can talk more about?

www.kth.se

Documents

Secure Handling of Electronic Health Records for ...1229377/FULLTEXT01.pdf · Medical record systems are used whenever caregiving is practiced. The medical records serve an important