Electronic Health Record Graduation Thesisaiellom/tesi/hoenderboom.pdf · a patient should be able...

Electronic Health RecordGraduation Thesis

Bart Hoenderboom

March 30, 2009

Electronic Health Record

Connecting the Patient to the AORTA

Graduation Thesis

Author: Bart HoenderboomLocation: GroningenDate: March 30, 2009Institution: Department of Mathematics and Computing Science,

Rijksuniversiteit GroningenIndustrial Partner: Logica, Working TomorrowSupervisors: Pieter Blaauw (Logica)

Prof. Dr. Ir. Marco Aiello (RuG, dept. Mathematics and Computing Science)

iii

Abstract

Early 2010, a national electronic health record (EPD) should be implemented inthe Netherlands. In the current EPD architecture (AORTA) the patient is notadopted as an actor in the system. The thesis outlines why and how a patientshould be connected to the AORTA.

With the Dutch law taken in mind, it can be concluded a patient should beable to examine his own medical file. A patient connection can also add extrafunctionality to an EPD, for example, a medical diary.

It is possible to connect a patient in different ways. A connection to differentcomponents in the AORTA are discussed. From the discussion it becomes clear,a new system should be designed, which is connected to the AORTA.

A solution is proposed and the architecture is evaluated with the architec-ture tradeoff analysis method. From the evaluation it is concluded that it is pos-sible to expand the AORTA architecture with the patient as an actor. However,it is argued if this results in the best solution for an electronic health record.

The proposed system contradicts with different design decisions taken inthe AORTA. Therefore, it is sensible to think a complete redesign of the EPDsystem is necessary.

v

Preface

The thesis is the result of my graduation trajectory for the master Software andSystem Engineering at the Rijksuniversiteit Groningen.

The initial motive for the subject of the thesis is the introduction of an elec-tronic health record by the end of 2009. The announcement of the introductionleads to a lot of criticism. One of the comments was the fact that it is initallyimpossible for a patient to connect to the system. I elaborate on the reason whya patient should be able to connect to an electronic health record, and if it ispossible to connect a patient to the current architecture.

The discussion and conclusions I wrote, may give the reader different in-sights into the current electronic health record system. Finally, the thesis canmake people aware of the necissity of the adoption of the patient as an activeactor in an electronic health record.

During my work on the thesis, different people supported me. I owe debts ofgratitude to all Logica colleagues who helped me during my work. I especiallythank P. Blaauw for reviewing the thesis, and for showing me around in theLogica organization during my work. Finally, thanks are owed to M. Aiello ofthe University of Groningen, who pointed me in the right direction of writing ascientific thesis.

Bart Hoenderboom

Groningen, March 2009

vii

Contents

1 Introduction 11.1 Electronic Health Record . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Research Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Contribution of the Thesis . . . . . . . . . . . . . . . . . . . . . . . 41.4 Organization of the Thesis . . . . . . . . . . . . . . . . . . . . . . . 5

2 Electronic Health Record 72.1 EPD description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Reasons to use EPD . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 Problems with EPD . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4 Patient demands towards EPD . . . . . . . . . . . . . . . . . . . . 92.5 Healthcare Provider demands towards EPD . . . . . . . . . . . . . 10

3 AORTA 113.1 AORTA description . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.1 Connection between healthcare providers . . . . . . . . . . 113.1.2 GBZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.1.3 ZSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.1.4 LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.1.5 Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.1.6 Connection between the facilities . . . . . . . . . . . . . . . 163.1.7 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2 Reasons for the AORTA architecture . . . . . . . . . . . . . . . . . 193.3 Pilots of EPD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

ix

Contents

3.3.1 WDH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.3.2 EMD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.4 Current problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4 Patient Connection 234.1 The Patient as an Actor . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.1.1 Reasons for Adopting Patients as an Actor . . . . . . . . . 234.1.2 Points of Interest . . . . . . . . . . . . . . . . . . . . . . . . 24

4.2 Connection Methods . . . . . . . . . . . . . . . . . . . . . . . . . . 264.2.1 Connection to the National Connection Point (LSP) . . . . 274.2.2 Connection to the Healthcare Provider (GBZ) . . . . . . . . 284.2.3 Connection to the closed network (DCN) . . . . . . . . . . 304.2.4 Connection to an External Database (PAS) . . . . . . . . . 304.2.5 Conclusion of Connection Methods . . . . . . . . . . . . . 32

5 Architecture Tradeoff Analysis Method 355.1 Architecture Tradeoff Analysis Method . . . . . . . . . . . . . . . 35

6 Expansion of the AORTA Architecture 396.1 Expansion of the Architecture . . . . . . . . . . . . . . . . . . . . . 39

6.1.1 Phase 1, Step 1 . . . . . . . . . . . . . . . . . . . . . . . . . 396.1.2 Phase 1, Step 2 . . . . . . . . . . . . . . . . . . . . . . . . . 396.1.3 Phase 1, Step 3 . . . . . . . . . . . . . . . . . . . . . . . . . 426.1.4 Phase 1, Step 4 . . . . . . . . . . . . . . . . . . . . . . . . . 446.1.5 Phase 1, Step 5 . . . . . . . . . . . . . . . . . . . . . . . . . 476.1.6 Phase 1, Step 6 . . . . . . . . . . . . . . . . . . . . . . . . . 506.1.7 Phase 2, Step 7 . . . . . . . . . . . . . . . . . . . . . . . . . 816.1.8 Evaluation Conclusion . . . . . . . . . . . . . . . . . . . . . 82

7 Discussion 857.1 Discussion of connection patient . . . . . . . . . . . . . . . . . . . 857.2 Discussion AORTA architecture . . . . . . . . . . . . . . . . . . . . 877.3 Discussion Expansion of the AORTA . . . . . . . . . . . . . . . . . 88

8 State of the Art 918.1 Medical Informatics . . . . . . . . . . . . . . . . . . . . . . . . . . . 918.2 Architecture Models . . . . . . . . . . . . . . . . . . . . . . . . . . 94

8.2.1 Three-Tier architecture . . . . . . . . . . . . . . . . . . . . . 94

x

Contents

8.2.2 Service-Oriented Architecture . . . . . . . . . . . . . . . . . 968.3 Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

8.3.1 IPsec VPN vs SSL VPN . . . . . . . . . . . . . . . . . . . . 98

9 Conclusion 1019.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1019.2 Research approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 1039.3 Future Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Abbreviations 105

Bibliography 107

A Technical Description 113A.1 Security Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

A.1.1 PKIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113A.1.2 Virtual Private Network . . . . . . . . . . . . . . . . . . . . 114A.1.3 Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115A.1.4 Secure Sockets Layer . . . . . . . . . . . . . . . . . . . . . . 115A.1.5 Transport Layer Security . . . . . . . . . . . . . . . . . . . . 116A.1.6 Internet Protocol Security . . . . . . . . . . . . . . . . . . . 117A.1.7 X.509 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118A.1.8 Certificate Revocation List . . . . . . . . . . . . . . . . . . . 119

A.2 Message Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . 119A.2.1 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119A.2.2 WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120A.2.3 WS-I Basic Profile . . . . . . . . . . . . . . . . . . . . . . . . 120A.2.4 HL7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121A.2.5 LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

xi

List of Tables

3.1 Communication protocols used in the AORTA.[11] . . . . . . . . . 18

4.1 Advantages and disadvantages of the different connection methods 33

6.1 EPD Quality Attributes of Interest . . . . . . . . . . . . . . . . . . 416.2 EPD Utility Tree with Priorities . . . . . . . . . . . . . . . . . . . . 506.3 Analyzing Scenario Se1.1 . . . . . . . . . . . . . . . . . . . . . . . . 516.4 Analyzing Scenario Se1.2 . . . . . . . . . . . . . . . . . . . . . . . . 526.5 Analyzing Scenario Se1.3 . . . . . . . . . . . . . . . . . . . . . . . . 536.6 Analyzing Scenario Se1.4 . . . . . . . . . . . . . . . . . . . . . . . . 546.7 Analyzing Scenario Se1.5 . . . . . . . . . . . . . . . . . . . . . . . . 556.8 Analyzing Scenario Se1.6 . . . . . . . . . . . . . . . . . . . . . . . . 566.9 Analyzing Scenario Se2.1 . . . . . . . . . . . . . . . . . . . . . . . . 576.10 Analyzing Scenario Se2.2 . . . . . . . . . . . . . . . . . . . . . . . . 586.11 Analyzing Scenario Se2.3 . . . . . . . . . . . . . . . . . . . . . . . . 596.12 Analyzing Scenario Se3.1 . . . . . . . . . . . . . . . . . . . . . . . . 606.13 Analyzing Scenario Se3.2 . . . . . . . . . . . . . . . . . . . . . . . . 616.14 Analyzing Scenario A1.1 . . . . . . . . . . . . . . . . . . . . . . . . 626.15 Analyzing Scenario A1.3 . . . . . . . . . . . . . . . . . . . . . . . . 636.16 Analyzing Scenario A1.4 . . . . . . . . . . . . . . . . . . . . . . . . 646.17 Analyzing Scenario A1.5 . . . . . . . . . . . . . . . . . . . . . . . . 656.18 Analyzing Scenario A1.6 . . . . . . . . . . . . . . . . . . . . . . . . 666.19 Analyzing Scenario R1.1 . . . . . . . . . . . . . . . . . . . . . . . . 676.20 Analyzing Scenario Sc1.1 . . . . . . . . . . . . . . . . . . . . . . . . 68

xiii

List of Tables

6.21 Analyzing Scenario Sc1.2 . . . . . . . . . . . . . . . . . . . . . . . . 696.22 Analyzing Scenario Sc1.3 . . . . . . . . . . . . . . . . . . . . . . . . 706.23 Analyzing Scenario Sc1.4 . . . . . . . . . . . . . . . . . . . . . . . . 716.24 Analyzing Scenario P1.1 . . . . . . . . . . . . . . . . . . . . . . . . 726.25 Analyzing Scenario I1.1 . . . . . . . . . . . . . . . . . . . . . . . . 736.26 Analyzing Scenario I1.2 . . . . . . . . . . . . . . . . . . . . . . . . 746.27 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826.28 Risks and non-risks in the architecture . . . . . . . . . . . . . . . . 84

7.1 Advantages and disadvantages of the different interaction methods 86

8.1 IPSec VPN vs. SSL VPN . . . . . . . . . . . . . . . . . . . . . . . . 99

xiv

List of Figures

1.1 Connection of the different healthcare providers [11]. . . . . . . . 2

3.1 Connection of the different healthcare providers[11]. . . . . . . . . 123.2 Connection of the different components . . . . . . . . . . . . . . . 17

4.1 Connection of the patient to the RF . . . . . . . . . . . . . . . . . . 274.2 Connection of the patient to the GBZ . . . . . . . . . . . . . . . . . 294.3 Connection of the patient to the ZSP . . . . . . . . . . . . . . . . . 304.4 AORTA elaborated with PAS . . . . . . . . . . . . . . . . . . . . . 31

5.1 Conceptual flow of the ATAM [53]. . . . . . . . . . . . . . . . . . . 36

6.1 AORTA elaborated with PAS . . . . . . . . . . . . . . . . . . . . . 42

8.1 Repository Model[60] . . . . . . . . . . . . . . . . . . . . . . . . . . 928.2 Shared Services Model[60] . . . . . . . . . . . . . . . . . . . . . . . 938.3 Three-tier Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 958.4 Service Oriented Architecture . . . . . . . . . . . . . . . . . . . . . 97

Chapter 1

Introduction

1.1 Electronic Health Record

In 2001 there was an idea by the former Minister of Health, Welfare, and Sport,Els Borst, of a system in which all different medical data available at the differ-ent healthcare providers are coupled together, the Elektronisch Patienten Dossier(EPD). A national electronic health record, which contains all medical informa-tion of a patient, has several advantages. First of all, the medical informationis always available. If information is needed, it is possible to look it up in thesystem. A second advantage is that it is only necessary to put all the informa-tion in the system once. Furthermore, it is possible for each hospital, generalpractitioner, or another healthcare provider to examine the medical data at anytime and any place. The advantages result in less errors and a more efficientway of dealing with patients. However, there are a lot of obstacles to overcome,before adopting an electronic health record.

After eight years, there still exist no national system in which all medicaldata is stored. The absence of an national electronic health record can be ex-plained by the delicacy of the data. Medical data should be securely stored andcommunicated and the privacy of the data should be guaranteed.

The national ICT institute in the healthcare (Nictiz), designed an architec-ture for the electronic health record (AORTA). According to Nictiz, the AORTAis the solution for storing and communicating all the information in a securefashion. However, the AORTA has a lot of opponents. One of the opponentsis the boards of the hospitals. The boards think that it should be possible forpatients to look at their own medical data file. Furthermore, the patient shouldbe able to see who has viewed or adjusted his file. The Dutch government sup-ports the argumentation. In the AORTA design the complete communication ofthe information is within a closed system, which only connects the healthcareproviders with each other.

2 1. Introduction

Figure 1.1: Connection of the different healthcare providers [11].

Figure 1.1 shows the national basic infrastructure. The architecture is basedon a connection of the healthcare providers with a central connection point(LSP). The connection is made through data communication networks (DCN),which are exploited by health service providers (ZSP). To connect to the LSP,the healthcare provider should have a good administrated health informationsystem (GBZ). For identifying patients, healthcare providers, and health sys-tems, different registers are implemented: The UZI-register (unique healthcareprovider identification) and the SBV-Z (Sectoral bulletin facility in the health-care of the BSN scheme). The registers are exploited and supervised by theCIBG. The CIBG is an organization which produces products and services forregistration and supervision of medical data.

The LSP takes care of the connection between the healthcare providers. Anindex in the LSP gives an overview of all the medical data and the location ofthe GBZ in which the data is saved.

Early 2010, the Minister of Health, Welfare and Sport, dr. A. Klink, wants tohave a connection between all the responsible healthcare providers. The health-

1.2. Research Questions 3

care providers, which should be connected, includes the hospitals, general prac-titioners, and pharmacists. However, security of the healthcare provider sys-tems can not be guaranteed in all cases yet.

Different parties concerning the EPD agree that the AORTA system shouldbe expanded with a connection of the patient to the AORTA. Though, one canquestion if it is possible to expand the AORTA architecture with new actors? Orare there better alternatives for the AORTA architecture?

The goal of the thesis is to clarify the necessity of the adoption of patientsin the AORTA architecture. Next to the clarification, a verification is made ofthe connection possibilities. The verification leads to an expansion of the cur-rent AORTA architecture, in which the role of the patient is taken into account.The expanded architecture is evaluated using the Architecture Tradeoff Analy-sis Method.

1.2 Research Questions

The current AORTA architecture lacks the ability for patients to connect to theEPD system. In fact, the architecture is designed without taking the role of thepatient into account. The necessity of patient interaction results in the followingresearch question:

Is it possible to expand the AORTA architecture, without any negative side effects onthe quality attributes of the current architecture, so it becomes possible for patients todirectly interact in the system?

To answer the main research question, different subquestions are answered. Theresearch questions are detailed next.

Is it necessary to adopt a national electronic health record?Before designing an architecture for an electronic health record, it is importantto discuss the reasons for a national electronic health record and the possibleproblems that can occur when adopting a national record.

Is it necessary to connect a patient to the current EPD architecture?In the current AORTA architecture, the patient is excluded from the system.However, different parties agree the patient should be adopted as an actor in

4 1. Introduction

the system. This opinion can be supported by different reasons.

Which technical possibilities are there for a patient to connect to the AORTA?There are different possible methods to connect a patient to the AORTA. Themethods differ from a direct connection to one of the existing components ofthe current AORTA architecture, to newly added components. The influence onthe AORTA architecture is evaluated for the most reasonable solution.

In which way the AORTA architecture restricts the actions of the patients?It is thinkable to give the patient different responsibilities concerning his ownmedical data file. However, an existing architecture can restrict these responsi-bilities. For example, there may be no facilities to fulfill the demands towards aresponsibility. In case of the AORTA architecture, the patient is not yet adoptedas an actor. Adoption of the patient, can result in unwanted results. Therefore,it is also important to think of the effects when giving different responsibilitiesto a new actor. As a consequence, it is necessary to think of the necessity andthe influences.

Which quality attributes are impacted, due to a patient connection?A connection of a new actor can have different influences on an existing sys-tem. The influences can change a good working system in a total disaster. Itis thinkable a patient connection to the AORTA impacts the quality attributesof the AORTA architecture. An answer on the research question results in anconclusion if it is an option to connect the patient to the AORTA, or if a totalnew design should be implemented for the EPD.

1.3 Contribution of the Thesis

The current electronic health record in the Netherlands is based on a closedsecure network of healthcare providers. However, it is argued by healthcareproviders, the Dutch government, and other stakeholders, that the patient shouldalso play a significant role in the architecture. The scientific contribution of thethesis is in the expansion of the current electronic health record of the Nether-lands, with the patient as an actor. A discussion on the possible connectionmethods, results in a possible solution for the expansion. The proposed expan-sion of the existing electronic health record is evaluated with the architecture

1.4. Organization of the Thesis 5

tradeoff analysis method.

1.4 Organization of the Thesis

The thesis consists of nine chapters. The first chapters give a description ofthe need of an EPD and the realization of the need. The subsequent chapterspropose and evaluate a possible solution for the expansion of the AORTA withthe patient as an active stakeholder in the system. The contents of the differentchapters are described below.

• Chapter 2; Electronic Health Record: Chapter 2 outlines a description ofthe EPD. A clear definition is stated, which is used throughout the the-sis. Furthermore, the reasons for an EPD are listed. There are, however,also different problems and points of interest accompanied with a nationalelectronic health record. Last focus in the chapter is on the different stake-holders in an EPD. The demands of the patients and the healthcare arediscussed.

• Chapter 3; AORTA: Chapter 3 discusses the AORTA. The chapter outlinesa description of the AORTA and each component is discussed in moredetail. Different design decisions are made to result in the AORTA. Thereasons for some design decisions are considered in the subsequent sec-tion. Last focus in this chapter is on the pilots of the EPD and the resultingproblems.

• Chapter 4; Patient Connection: Before discussing the connection methods,the reasons to adopt a patient as an active actor are described. The reasonsare of significance how to connect a patient. Each connection method, canhave different influences on the current AORTA architecture.

• Chapter 5; Architectural Tradeoff Analysis Method: Chapter 5 describesthe evaluation method used to evaluate the expanded AORTA architec-ture.

• Chapter 6; Expansion of the AORTA architecture: ATAM is used to evalu-ate the expansion of the AORTA architecture. After the evaluation a con-clusion is drawn.

6 1. Introduction

• Chapter 7; Discussion: The discussion is split up in three parts. First ofall, the connection of the patient is discussed. The discussion includes thereasons to connect a patient as well the connection methods. Secondly,the AORTA architecture is discussed. Different design decisions in theAORTA architecture are considered. The last discussion point is concern-ing the expansion of the AORTA.

• Chapter 8; State of the Art: Chapter 8 consists of the description of elec-tronic health records implemented in other countries. Furthermore, thechapter contains a section, which describes the state of the art in the areaof three-tier architectures and service oriented architectures. The last sec-tion describes the different techniques used in the AORTA architecture.The techniques are compared with possible alternatives.

• Chapter 9; Conclusion: The research questions are answered in the conclu-sion. The chapter contains also a conclusion on the research approach. Theconclusion ends with a section which describes possible future research.

Chapter 2

Electronic Health Record

2.1 EPD description

The electronic health record in the Netherlands is called Elektronisch PatientenDossier (EPD). EPD is a collective term for different ICT usages in the healthcaresector. These are ICT usages for supporting healthcare work, prevention, med-ical research, and health logistics. All information needed in those areas can beexamined, added and/or adjusted in the EPD. As the name EPD implies, theusages are related to patients.

Adding and/or adjusting information in a patient’s EPD results in a com-plete medical data file of the patient, containing all psychological, psychiatric,medical, and nursing data. The data is instantly available, which results in anup to date medical data record. The information in the EPD is only available forauthorized persons in the healthcare sector. The authorization is determined bythe patient.

The complete medical data file is not stored at a specific database. Relevantdata can be acquired from an information system located at a patient’s health-care provider.[3][10]

2.2 Reasons to use EPD

There are different reasons to use a national system in which it is possible toexchange medical data of a patient.

First of all, the medical data of a patient is always available. Availability isguaranteed by letting the connected GBZs be accessible twenty four seven. As aresult, the data can be requested by other healthcare providers at any place andat any time in the country.

Secondly, the data needs to be imported into the system only once. It is notnecessary for a healthcare provider to record medical data, once it is archived

8 2. Electronic Health Record

already by a colleague. As a consequence, the medical data file of a patientis not expanded with the same information, which results in a more clarifyinghealth record. Another advantage is that costly time is saved in which anotherpatient can be treated.

Time issue is another reason for the introduction of an EPD. With a nationalsystem, information can be requested in less time than with the conventionalsystem. Time profit results in a decrease of consult time. In case direct action isneeded, lives can be saved. To realize a time profit, it is important to guaranteedifferent performance issues in the EPD system.

Another positive aspect of an EPD is that a medical data file is always up-to-date. Every recent adjustments to the patients electronic health record, can beconsulted instantaneously by any authorized person. Direct availability of thedata is realized by a connection between the healthcare providers. An importantresult of the availability of the medical data is the reduction of mistakes. Forexample, when a patient becomes some kind of medicine, the medicine use isregistered and the information is directly accessible by the different authorizedpersons. The chance a patient becomes the wrong medicine in combination withanother medicine is reduced.[9]

2.3 Problems with EPD

Next to the reasons for implementing an electronic health record, there are alsosome problems or disadvantages concerning the EPD.

One of the issues with an electronic health record is security. Patient in-formation is private information and is only published to authorized persons.When making use of the EPD system, all information can be acquired at anyplace and any time. Availability makes it more easily for evil minded personsto come in possession of a great amount of medical data. As mentioned by JaapDijkstra [7], professor Law and ICT at the university of Groningen, hackers cansteal the medical data and bring the data to a foreign country and offer it to, forexample, employers or assurance companies.

The way in which the data is administrated can be another obstacle. Thedata a healthcare provider administrates are mostly interpretations. The in-terpretations are exchanged between the healthcare providers. The receivingparty interprets the interpretations, which can result in a wrong explanation ofthe data.[28] According to Mommers in the NRC [43] digital availability of data

2.4. Patient demands towards EPD 9

is not guaranteed to result in an actual, usable, and a consistent view of thehealthcare needs of a patient. Data can contradict and its availability is not asurety that the data is being read, understood or used. A short, clear referralletter with the most relevant information can be more effective.

Another problem is the contradiction of an EPD with the pledge/oath of se-crecy. A medical practitioner has a pledge/oath of secrecy. The pledge/oathof secrecy is recorded in the Dutch law, the Wet op de Geneeskundige Behan-delingsovereenkomst (WGBO). The WGBO mentions that the medical practi-tioner is obligated to keep the in faith notified information from a patient asecret. However, secrecy contradicts with the EPD. With the EPD it becomespossible for different people to consult the information a healthcare provideradministrates. Consequently, the medical practitioner is not able to keep hispledge/oath. [7]

2.4 Patient demands towards EPD

The EPD contains data based on the medical history of patients. In the futurethe patient should be able to consult the information stated in his EPD. The pa-tient becomes also responsible for protecting his own medical data file by givingauthorization to the different healthcare providers. Therefore, it is important tolook at the demands of the patients. TNO did a research on the patients viewof the flaws in medical data exchange[2]. In the research, TNO also mentionedthe idea of an EPD to the respondents. During the interview, different demandstowards an EPD can be concluded.[2][3]

• Good security of the medical data file.

• Possibility to make secure back-ups of the file.

• Good security against hackers and unauthorized persons.

• The privacy of the patients should be guaranteed.

• There should be a good registration of persons who are authorized to ac-cess the file.

• The patient should be able to read his own file.

• The language in which the file is written should also be readable for unini-tiated persons.

10 2. Electronic Health Record

• The file should be complete and flawless.

In general the respondents where very positive about an EPD. The respondentssee the EPD as a logical consequence of the technological growth.

2.5 Healthcare Provider demands towards EPD

Next to the demands towards an EPD from the patient’s point of view there arealso demands of the healthcare providers to take in mind.

The Vrije Huisarts (a foundation for general practitioners) is an opponent ofthe EPD. In their analyses of the current EPD plans [28] they mention differentpoints of interests when adopting the EPD system. They expect an increase ofsecurity concerning the medication use of patients and the effectiveness of refer-rals. Furthermore, they want to see a bottom-up approach when implementingan electronic health record. Good conditions for the exchange of medical datashould be realized on a local and/or regional scale first, before planning thenational EPD system. Other points of interest mentioned in the analyses areitemized below:

• Clear procedures; Who has access to the EPD and in which way is accessguaranteed?

• Security; Privacy of the data should be guaranteed.

• Money issue; There should be a good allowance for the healthcare providerswhen implementing the functional demands of an EPD.

Another aspect mentioned by the foundation of general practitioners is theresponsibility for technical flaws in the EPD. If data is not complete due to tech-nical or other reasons, it should be possible to point out the responsible persons.

The healthcare providers also demand the patient as an actor in the system.It should be possible for the patient to play an active role in the EPD system.The patient should become responsible for protecting his own data file. [7][4][3]Other reasons for adding the patient as an actor, is the ability for the patient toadd his own medical data. Medical data added by a patient can consist of,among other things, a self diagnosis and self medication.[3]

Chapter 3

AORTA

3.1 AORTA description

AORTA is the basic infrastructure of an electronic health record in the Nether-lands. The AORTA encloses common ICT facilities which are accessible for eachdifferent party in the healthcare. The ICT facilities are split up in two groups:

• ICT-facilities which form the basic infrastructure: the registers, the na-tional connection point and the different networks.

• ICT-facilities of the different parties: the local healthcare systems with thedifferent applications.

Another aspect of the AORTA architecture is ICT-technology. ICT-technology isused for communication, security, and performance issues. [11]

In the following sections each ICT facility of the AORTA architecture is dis-cussed. The discussion contains the functionality of each component, as wellthe position in the architecture and the connection with other components.

3.1.1 Connection between healthcare providers

The AORTA is based on a connection of the healthcare providers to a nationalconnection point (LSP). Figure 3.1 visualizes the connection between the com-ponents. The connection between the LSP and the healthcare provider is madethrough data communication networks (DCN). A DCN is exploited by a healthservice provider (ZSP). To connect to the LSP the healthcare provider needs agood administrated health information system (GBZ). For identifying patients,healthcare providers, and health systems, different registers are implemented:The UZI-register (unique healthcare provider identification) and the SBV-Z (Sec-toral bulletin facility in the healthcare of the BSN scheme). The registers are

12 3. AORTA

Figure 3.1: Connection of the different healthcare providers[11].

exploited and supervised by the CIBG. The CIBG is an organization which pro-duces products and services for registration and supervision of medical data.

The LSP takes care of the connection between the healthcare providers. Arouting index in the LSP gives an overview of all the medical data and the placein which it is saved. [11]

3.1.2 GBZ

A GBZ is a good administrated healthcare system of a specific healthcare provider.It contains an XIS application or a collection of those applications. An applica-tion needs to suffice different application demands to get adopted in the GBZ.Among other things, an XIS application contains the medical data files of thepatients. A medical data file can be exchanged on national scale. The data com-munication is provided by one unique IP address connected to the LSP. The IPaddress is provided by a health service provider (ZSP).

The GBZ needs facilities that guarantees only authorized persons get access

3.1. AORTA description 13

to a patient’s medical file. Therefore, card readers are installed to authenticatean user before using the GBZ. Authentication succeeds if the user uses a pass(UZI), provided by the CIBG for the specific user. The GBZ authenticates itselfby a server certificate also provided by the CIBG.

To become owner of an UZI pass, a careful registration and distribution pro-cess needs to be followed. An applicant for such a pass should be a provablehealthcare provider. The passes are created in a secure environment, after whichthe physical and legal identity of the applicant is verified. As a consequence, theUZI passes are connected with the registered owners.

A GBZ is provided with an UZI server certificate. If a GBZ suffices all thedemands to get connected to the ZIM, the owner can request an UZI servercertificate at the UZI-register. The certificate is installed in such a way, all theGBZ applications can use it. The use of authentication with certificates preventsmalicious systems from occuring as a GBZ.

Internal security of a GBZ is the responsibility of the healthcare provider.The NEN 7510 norm is about the information security within the healthcaresector. A healthcare provider who adopts the norm can guarantee the availabil-ity, integrity, and the confidentiality of his GBZ [31]. The NEN 7510 norm willbe probably obligated for the connected healthcare providers.

Another important aspect which makes a system a GBZ, is the way the dataexchange is realized. Data exchange is realized according Health Level 7 ver-sion 3 (HL7v3) standards. HL7v3 is a communication standard specified for thehealthcare. All data messages send to the LSP is in HL7v3 format. Finally, dif-ferent procedures of how to use and manage the system should be taken intoaccount when working with the GBZ.

In short, a GBZ is an accurate supervised system kept in a secure zone, inwhich one or more XIS applications are operating. [12] [11]

3.1.3 ZSP

A ZSP is a healthcare service provider. The provider is a person who is an au-thorized representative to deliver services to a GBZ and the LSP. The provisionof the connection for data communication between GBZ and LSP can be con-cluded as the most relevant task for the ZSP. To setup such a connection, theGBZ is provided with an unique IP address. It is only possible for the GBZ tocommunicate directly with the LSP with the unique IP address. The ZSP is pro-vided with a whole range of IP addresses by the LSP. The IP addresses that are

14 3. AORTA

released to the different GBZs, including the routing data, are returned to theLSP.

The network a ZSP manages is called a data communication network (DCN).A DCN is a network of data communication connections on a regional scale. Anetwork on regional scale can be a virtual private network (VPN) or a value-added network (VAN). A DCN also includes the necessary facilities at the con-nected parties. The connected parties consist of the different GBZs, which needto be connected to the LSP. It is also possible for the DCN to support other data-com needs for the healthcare providers. A DCN is exploited and supervised byonly one data communication service provider.

Different internet protocols are used for the data communication betweenthe GBZ and the LSP. For transport of the data the internet standards TCP/IP isused with HTTP as the communication protocol. Security is guaranteed by theSSL/TLS protocol. The protocols are expanded with SOAP 1.1, WSDL 1.1 andWS-I Basic Profile. [11][13]

3.1.4 LSP

The LSP is a national connection point which links all the GBZs together. Theprimary task is to deliver information and routing services. The LSP consists oftwo common facilities, the RF and the ZIM.

RF

The routing services are provided by the RF. RF makes IP traffic between GBZson different DCNs with different VPN techniques possible. Communicationbetween GBZs on different VPNs is necessary when a GBZ wants to exchangedata files directly with another GBZ. The data files to exchange exclude HL7messages. HL7 messages are exchanged by the ZIM. The connection providedby the RF is based on static routing.

For the present the RF is a common port to the public internet for all theGBZs connected to the LSP. Use of the public internet is reduced to a connectionto the certification authority (CA).

ZIM

The ZIM is a common facility which takes care of the communication of HL7messages between the GBZs. A patient’s medical file suffices the HL7v3 stan-


dard, so the ZIM is responsible for exchanging medical files between the GBZs.The ZIM consists of different software components. Each of the components hasits own function. Most interesting components are described in Section 3.1.6.

Access regulation by the ZIM comprises several steps. The first step enclosesthe determination of the identity and authenticity of the user. For determinationthe distributed UZI passes are used. After the user is granted access to the ZIMan authorization protocol determines which healthcare provider, based on thefunction, has access to which information. With the use of an authorization pro-tocol it is possible to exclude a specific specialism from specific data. Excludingspecific specialism can be very useful, when for example assurance companiesare connected to the AORTA. Authorization on a person level is handled by anauthorization profile. The patient can determine which persons have access towhich specific data. All the information requests at the ZIM are logged. To besure the requested data is of the right patient, the healthcare provider verifiesthe patient’s civilian service number (BSN) at the SBV-Z.

Internal security of the ZIM consists of preventing evil-minded people ac-cessing the ZIM facility and other physical measures. Security measures are ofgreat importance, because the ZIM acts as a central point in the whole AORTAarchitecture. The data the ZIM passes consists of HL7v3 messages. A HL7v3message is constructed of different parts. One of the parts is the payload, whichincludes the patient data. However, the payload is not viewed by the ZIM. So,internal security with only physical security suffices.

3.1.5 Registers

The CIBG is an organization which produces products and services for registra-tion and supervision of medical data. In the AORTA the CIBG provides differ-ent registers, the UZI register and the SBV-Z. The different registers the CIBGexploits are accessible through the public internet. Different communicationprotocols are used to communicate with either the UZI or the SBV-Z.

UZI register

The UZI register functions as a Public Key Infrastructure (PKI) for distributing,managing, and validating the identity certificates of the healthcare providers.The register is responsible for authenticating the healthcare providers and theirGBZs. To get connected to the LSP, the healthcare provider should be in pos-

16 3. AORTA

session of an UZI pass and his GBZ should have an UZI server certificate. Theowners of a pass or certificate are registered in the UZI register.

The GBZ communicates with the UZI-register by the LDAP and the HTMLprotocol. The ZIM uses LDAP for communication.

SBV-Z

Ever since 1 June 2008 a new law concerning the citizen service number (BSN)is active. It becomes possible for healthcare providers to verify a patient by itsBSN number instead of a random number.[16] Verification happens through aset of identifying data. It is possible to contact the SBV-Z through a websiteor by exchanging files. In case the ZIM is connected to the SBV-Z it becomespossible for GBZs to contact the SBV-Z through the ZIM. In the latter, the SBV-Zcan act as a national patient register.

Direct communication from GBZ to the SBV-Z happens through HL7v3 mes-sages, the HTML protocol and XML data transfer. The ZIM uses only HL7v3messages for communication. For a secure connection SSL/TLS is used.[11]

CA

Next to the CIBG a certificate authority (CA) is adopted in the architecture. TheCA is responsible for publishing PKI-certificates and keeping track of the re-voked certificates. The Certificate Revocation List (CRL) is stored in the CAregister. The GBZs and the ZIM need to contact the CA to download the CRLand to verify the validation of the certificates of the GBZs or ZIM, before com-municating with them. With the use of certificates authentication of the dif-ferent users can be guaranteed. The CA is connected to the public internet.Connection with a GBZ and the CA is realized through the RF.

3.1.6 Connection between the facilities

The GBZ and ZIM consist of different software components.


Figure 3.2: Connection of the different components

Figure 3.2 visualizes the most interesting components. The meaning of theabbreviations are itemized below.

• LOG; Log file

• DP; Data Port

• AU; Authentication

• LP; Link Point

• APT; Autorisation Protocol

• APF; Autorisation Profile

18 3. AORTA

• IA; Identification and Authentication

• RI; Routing Index

The LP is the central point in the architecture. It is the connection point withthe GBZs and the registers as well the linking point of different software compo-nents. One of the software components is the authorization profile. The profileis responsbile for the determination of authorization for accessing specific med-ical data.

To verify only authorized data access, the LOGs are implemented. The LOGsare local access logs. The log files keep track of the users, who request medicaldata.

The data port in a GBZ is a single access point, which is connected by a DCNto the RF of the LSP. Authorized persons get access to the XIS, through the DP.The XIS consist of the patient files, among other things.

The ZIM is the central point in most communication chains. Table 3.1 liststhe different communication protocols used between the different componentsin the AORTA architecture.

ZIM GBZGBZ HL7v3 DICOM

SBV-Z HL7v3 HL7v3, HTML, XML file exchangeUZI LDAP LDAP, HTML

Table 3.1: Communication protocols used in the AORTA.[11]

In the future it is possible for GBZs to exchange data with Digital Imagingand Communications in Medicine (DICOM). Together with HL7v3, these arebroadly used standards [58]. Consequently, interoperability is increased.

3.1.7 Security

Security plays a major issue in the AORTA architecture. Different levels withdifferent security measures can be distinguished in the architecture. Security inthe AORTA happens on the following levels:

• message level; Encryption and electronic signatures are used. Encryptionand signatures are realized by XML-encryption and XML-signature usingthe keys of the personal UZI passes.

3.2. Reasons for the AORTA architecture 19

• transport level; Encryption and authentication are realized by SSL/TLSusing the personal UZI passes and/or UZI server certificates.

• network level; Encryption and authentication on the network level can berealized by a connection of a GBZ to a Virtual Private Network (VPN) incombination with for example IPsec or SSL and the keys of the UZI servercertificates.

3.2 Reasons for the AORTA architecture

The medical data of an EPD is not located in a central database, but at localhealth systems of the healthcare providers. Making use of local databases wasa deliberate choice when designing the AORTA architecture. Different reasonsare mentioned for the design decisions. First of all, Nictiz wants to keep theresponsibility of the communication between the healthcare providers. The re-sponsibility for the medical data stays with the healthcare provider. The datashould be up to date and quickly accessible. In contrast to a central database,the legal owner of the data located at the GBZ can be determined easily. An-other advantage is the logging system. With the logging system it is possiblefor the data owner to keep track of the people who have accessed their data.

The AORTA architecture makes use of an index located at the national con-nection point (LSP). The index points to specific information located at one ofthe connected healthcare providers. With the use of an index, in contrast to acentral database, it is possible to deliver only the information that is needed.It is not necessary to deliver the whole medical file of a patient to the user.Sending only a part of a medical file reduces the information overhead, whichconsequently reduces lookup time.

With the current AORTA architecture it is possible to give an user differentauthorizations concerning accessing a medical data file of a patient. The autho-rizations can be determined by the patient and set accordingly. With the useof the authorization protocols it becomes possible to keep the medical data file,or parts of it, hidden for unauthorized users. To verify medical file access, it ispossible for the patient to request log files.

The exchange of messages in the AORTA architecture is based on HL7v3.Reasons for the choice of HL7v3 are the grow possibilities towards an electronichealth record and the connection with international developments. For trans-port of the HL7v3 messages Web Services Profile (WSP) is chosen. The choice

20 3. AORTA

for WSP is based on the possibilities for security of the messages and for theavailability of different tools for software development.

Web Service Messaging and the internet protocols used in the AORTA ar-chitecture are standardized by the international standardization institute W3C.The protocols are supported by all important system suppliers.[17][14]

3.3 Pilots of EPD

Before connecting all healthcare providers to the LSP, different pilots are imple-mented. The pilots are executed to evaluate parts of the AORTA architecture.The security, reliability, and the workability of the architecture is determined.The pilots started with a small amount of healthcare providers connected to theLSP. Consequently, flaws in the architecture are not affecting the total health-care community. After evaluating the pilot, the amount of users connected tothe LSP are increased slowly to determine the effect on the message flow, scala-bility, in the architecture.[25]

3.3.1 WDH

One of the target groups in the pilots are the general practitioners. On 1 Novem-ber 2006 the observer file for general practitioners (WDH) was launched. Withthe WDH it becomes possible for a random general practitioner in a centralpractice to exchange medical data of a patient with the patient’s general prac-titioner. The WDH pilot is evaluated in the period January 2007 till July 2008by researchers of the Telematica Institute and TNO. The evaluation consists of areview of about 30 interviews with general practitioners, healthcare providers,and suppliers.[18][20][21][23]

3.3.2 EMD

Mid 2007 another active pilot, the electronic medicine file (EMD), was launched.The EMD provides a facility for exchanging data between a pharmacist, hos-pital, and a doctor’s practice. The exchanged data concerns data about themedicine use of a specific patient. The EMD prevents the healthcare providersfor mistakes concerning medicine use of a patient.[19][22][23]

3.4. Current problems 21

3.4 Current problems

During different pilots, different evaluations are executed. The evaluations re-veal a lot of problems with the current architecture. Next to the evaluations,different antagonists have their doubts about the AORTA.

One of the problems with the AORTA is the dated architecture vision. Thewhole idea of introducing an EPD dated from early 2001. In that period, inter-net was not very common for the entire public sector. Most elderly where notconnected to the internet and ADSL was not widely scattered yet. After eightyears, the EPD is still not introduced. In those eight years there was a true ictand internet revolution. Nowadays, internet is used by almost everyone for themost divergent matters. However, the architecture design of the AORTA hasnot grown according the internet revolution. It is still impossible for the patientto be an actor in the EPD system. [4][6][5]

Different problems ocurred during the WDH and EMD pilots. One of theproblems that occurred during the WDH pilot is a money issue. The nationalassociation for general practitioners (LHV) needs more money to make all themedical patient files approvable for the EPD. The LHV and the general prac-titioners who are connected to the LSP, terminated their cooperation with theWDH pilot until more money is available. Termination of the cooperation re-sults in more delay for a national EPD.[26]

The vulnerability of the whole chain of GBZs is another problem. In theWDH pilot a relative small change like an update of the current software re-sulted in disruption in the chain. The disruption can occur in every automationlayer, which consequently affects the LSP. Replacement of a UZI pas owner alsoresulted in a disruption.[20][27]

With the use of UZI passes a lot of problems occurred. A lot of the problemsare abolished during the pilot. However, the UZI passes are still mentioned as apoint of interest. The appeal procedure for an UZI pas is an important obstacle.The appeal process should be simplified.[20]

Nictiz also mentions some restrictions due to the implementation of theAORTA architecture. The restrictions are a consequence of the minimal de-mands for a GBZ. The availability of the services is dependent on the avail-ability of the GBZ where the necessary data is located. The scattered data isgathered together to result in a complete overview of the medical data file. If aGBZ is not available, it becomes a problem to realize a complete medical datafile of a patient. Another problem that can occur concerns the response time.

22 3. AORTA

If a request for information is appealed, a response with the needed data is de-pendent on the slowest GBZ, containing a part of the data.

Next to the different problems that actually occurred, there are also differentdoubts and questions concerning the architecture.

In a letter from the KNMP to VWS [24], different points of interest are men-tioned. The KNMP requests a clarification of the responsibilities and liabili-ties. Another aspect that needs attention is the standardization of the internalinformation systems, GBZs. Different regulations according to registration ofmedical files and according the internal working of an information system arenecessary. In the letter, it is also mentioned that 95 percent of the patients, re-ceive healthcare within a single region. It can be questioned if the advantagesof a national system even matches with the disadvantages.

Chapter 4Patient Connection

4.1 The Patient as an Actor

Different reasons can be pointed out to adopt a patient as an extra actor in theAORTA architecture. Some of the reasons are based on the Dutch law. There isa law in which the medical treatment agreement is described (WGBO). The lawbecomes effective at the moment a patient visits a healthcare provider. Accord-ing the WGBO a patient is in control of his own treatment, so it is reasonablehe is also in control over his own medical data file. Adopting other actors in anarchitecture can influence different aspects of the current architecture. In caseof the AORTA, a patient connection leads to different points of interest.

4.1.1 Reasons for Adopting Patients as an Actor

The patient should be involved in the AORTA for different reasons. Some of thereasons are based on the Dutch law.

In article 456 of statute book 7 (Burgelijk Wetboek boek 7) is stated that itis the right of the patient to examine his own medical data record as soon aspossible. The patient has also the right to request a transcription of the record.To satisfy the duty it is possible for healthcare providers to provide access totheir systems to a patient. Subsequently, the healthcare provider needs to spendmore time for a consult. To relieve a healthcare provider of his obligations itwould be a better option to let the patient connect to the AORTA with his ownhome computer. As a result, consult time is reduced in which an extra consultcan be handled.

A patient has the right to determine who has access to his medical record.The right is described in article 457 of statute book 7. To comply to the law, itis possible in the AORTA architecture to authorize persons to acquire specificdata. Therefore, an authorization protocol and an authorization profile are im-plemented. With the latter it becomes possible for a patient to determine which

24 4. Patient Connection

persons can access his medical data file. The patient is responsible to setup hisown authorization profile. For data security reasons the ability to change theprofile should be limited by the patient only. However, in reality it is also pos-sible for the healthcare providers to change the profile. To be sure that grantingaccess to the medical record lives up with the authorization profile, all dataaccess is logged. With access to the logging data it becomes possible for thepatient to verify which users have acquired data from his record file. A patientshould be able to check the logging file at any possible time. It is impractible fora healthcare provider to handle each request for a logging file view. Therefore,a patient should be connected to the AORTA architecture.

In article 454 of statute book 7 is stated that a healthcare provider is obli-gated to attach a notification of a patient in case the patient has some remarkson the medical information as stated in his record. To comply with the law ahealthcare provider can reserve space on his system to add the data. As a resultof the annotation of the remarks, the scheduled time for a consult increases. Ifa patient is connected to the AORTA and storage space is reserved, it becomespossible for a patient to write his own comments at home. Next to commentson existing information it is also possible to enlarge the interactivity of a patientin his own record. The patient can add in his storage space, for example, hisown diagnosis, measurements, and the medication he is using without a recipe.Another interesting feature to mention is the possibility of healthcare on dis-tance. A healthcare provider can setup a trajectory in which interactive care isprovided.

4.1.2 Points of Interest

If an architecture is expanded with other components and/or actors, differentproblems can occur. The effects can change a very well designed architectureinto a complete failure. Therefore, it is important to think of the different as-pects which could be responsible for the negative effects. The different pointsof interest consists of technically aspects as well social aspects like money.

In the current AORTA architecture, the patient is excluded from accessinghis own medical record file. In fact, the patient is not even considered as an ac-tor in the system. If a patient wants to examine his medical data file or changethe authorization profile, a healthcare provider should act as a broker. In caseof an actor expansion in the AORTA architecture the effects on the existing ar-chitecture should be evaluated.

4.1. The Patient as an Actor 25

One of the most important quality attributes in the AORTA architecture is se-curity. The current AORTA architecture is a closed network with lawful health-care providers in possession of special qualified secure information systems(GBZ). To prevent healthcare providers from misusing the EPD system differentsanctions are proposed. Minister Klink mentions [45] in a parliamentary debatefinancial sanctions and even the possibility of losing their profession. Due tothe heavy sanctions, it is thinkable a healthcare provider is not eager to permitaccess to his GBZ to unqualified persons, like patients.

The restrictions of each actor should be determined clearly, as is done forthe healthcare providers. The healthcare providers are restricted by the autho-rization profile and by the different prescribed rules. A patient should also berestricted in his actions. It should not be possible for evil-minded people to un-dermine the EPD. Therefore, also special measures for a patient are necessary.

The national knowledge centrum for ICT and innovation in the healthcare,Nictiz, mentions in their technical architecture [11] the need for restrains for theZIM and the GBZs. In the AORTA architecture the ZIM can be classified as thebottleneck for the traffic of all HL7 messages. Each GBZ is connected to theZIM and each GBZ should setup a SSL session when communicating the HL7messages. Setting up an SSL session is laborious, due to the SSL handshake.Therefore, within one SSL session it is possible to realize more SSL connections.In case of load balancing it could be possible to setup a maximum of three SSLsessions between the GBZ and the ZIM, but in most cases the amount of SSLsessions is restricted to just one. In case a patient is connected to the AORTA, itcould be possible that the amount of SSL sessions grow enormously. Anotherrestraint the Nictiz mentions are the amount of HL7 request messages a GBZcan handle. If too many HL7 requests are send to a single GBZ, they foreseean abatement in performance. If a patient is also able to send requests in theAORTA architecture, the abatement increases.

From the pilots, EMD and WDH, Nictiz did a capacity estimation for theAORTA. The different estimations are itemized below:

• 20.000 connected GBZs,

• 50 connected DCNs,

• 10.000 simultaneous user sessions,

• 4.312.000.000 messages a year,


• an average of 5 kByte for each exchanged message.

The estimations are based on the interaction of the healthcare providers in thecomplete AORTA basic infrastructure. The interaction of the patient is notadopted in the capacity consideration. With a population of approximately 16million people, it is conceivable that an expansion with the patient has negativeinfluences on the system as a whole. Think for example at the quality attributesavailability and performance. In Section 4.1.1 different reasons are outlined toconnect a patient to the AORTA. The reasons are not immediately of such animportance that they are life threatening for the patient. In contrast to patients,healthcare providers are concerned with a system which performs well. With agood performance of the system the consult time can decrease. In some casesa good performance can even save lives. It can be concluded that the availabil-ity, reliability and the performance of the system are of more importance forthe healthcare providers than for the patients. However, a patient should ad-just his authorization profile when necessary to prevent unwanted healthcareproviders to examine specific medical data. So, a good tradeoff should be madewhen a patient is added as an actor.

In almost every project money plays an important role. In case of the EPDproject, the healthcare providers receive a subsidy from the government. Ac-cording to the general practitioners, the subsidy is too low to suffice the de-mands towards an certificated GBZ[26]. They withdrawn their cooperationwith the WDH pilot. If the costs for the healthcare providers concerning theEPD rises, it is conceivable the healthcare providers will not cooperate with thenew EPD.

Another important aspect are the techniques used to realize the new con-nection for the patient. The techniques should exist of proved protocols andstandards. Furthermore, the complete architecture should be adaptable to newtechniques that will be released in the nearby future.

4.2 Connection Methods

There are different ways to connect a patient to the AORTA architecture. First ofall, it is possible to connect a patient directly to the national connection point, towhich all the healthcare providers are connected. Another method is to connectthe patient to the workstation of his general practitioner. In the case of a connec-tion to the workstation, the workstation acts as some kind of service-hatch. The

4.2. Connection Methods 27

last component in the AORTA architecture, to which a connection is possible, isto the VPN to which the healthcare providers are connected.

Next to a connection to an existing component it is also possible to expandthe AORTA with extra components. The existing AORTA architecture shouldnot experience any negative side effects of an expansion.

4.2.1 Connection to the National Connection Point (LSP)

One of the options to connect a patient is a direct connection to the national con-nection point. The RF is a component in the national connection point, whichhas an access point to the public internet. The RF provides the access to thepublic internet for all the connected healthcare providers and for the AORTA toconnect to the registers. A patient is connected to the RF, as visualized in Figure4.1.

The design decision of a single access point to the public internet is made byNictiz to prevent extra costs for the healthcare providers and service providersof the VPNs. If a workstation or VPN has its own port to the public internet, itshould invest in security like firewalls and intrusion detection. Money plays anissue in the EPD realization. So, it is thinkable the general practitioners will notconsent to higher costs then expected.

Figure 4.1: Connection of the patient to the RF

Nictiz mentions, in their technical architecture [11], the limited capacity of


the RF. An important remark by the comment of Nictiz is the fact that theydid not take the patients connection to the RF into account. If a patient is alsoconnected to the RF, the possibility of a failing RF increases. As a consequence,a connection to the RF impacts scalability.

To relieve the RF from his tasks the service providers should provide a portto the public internet. A port to the public internet means an increase of costsfor the service provider. Another consequence of the extra connections is theincrease of security risks. Each connection means an extra entrance for an evil-minded person to the system. So, relieving the RF, by providing other ports tothe public internet, is not an option.

A request for medical information by a patient, means an increase of HL7requests on the AORTA network. In the AORTA, only data exchange betweenthe healthcare providers is taking into account. A connection of the patient,results in performance decrease.

With a connection of the patient to the AORTA, the advantages of the closednetwork of healthcare providers is vanished. Everybody is connected, so thesystem becomes more vulnerable for a possible attack.

4.2.2 Connection to the Healthcare Provider (GBZ)

Another option for a connection to the AORTA, is a connection to the worksta-tion of a healthcare provider (GBZ), as visualized in figure 4.2. A reasonablesolution is to connect each patient to his own general practitioner. A generalpractitioner has his GBZ online twenty four seven. So, it is possible for a pa-tient to connect whenever he wants. The general practitioner is expected tohave the most information about his own patients. The information is send di-rectly to the patient, without intervention of the ZIM. As a result, data traffic inthe AORTA is not impacted.

A general practitioner is responsible for his own information system. If theowner of a healthcare system does not suffice to the prescribed rules, deter-mined by the government, he can expect a fine or can even lose his authoriza-tions. To comply to the rules, a general practitioner should take extra securitymeasures to connect his patients to his system. Among other things, authen-tication of the patients should take place. In the current AORTA architecturea patient is identified by its citizen service number. Identification takes placein a register outside the closed network of healthcare providers. To contact theregister, the healthcare provider should access the public internet via a single


Figure 4.2: Connection of the patient to the GBZ

access point with the public internet (RF). The traffic to the register, via the RF,results in additional traffic over the corresponding VPN. As a consequence, theadvantage of less data traffic in the AORTA is cancelled.

A general practitioner does not have all the information of his patients storedin his GBZ. The AORTA architecture exists of a connection of all the differ-ent databases of all the different healthcare providers. The data in the otherdatabases are acquired by HL7 requests. A national connection point (ZIM)answers the requests with the required information. Therefore, an importantdisadvantage of a connection directly to the general practitioner is the increaseof HL7 requests from the specific healthcare provider. If a patient wants toexamine his own medical data file, the workstation of the general practitionersends out the HL7 requests. It is thinkable, patient requests are interfering withthe data requests from the general practitioner. Interference can result in per-formance, reliability, and availability decrease.


4.2.3 Connection to the closed network (DCN)

The last option to connect to is the closed network of healthcare providers,which is visualized in figure 4.3.

Figure 4.3: Connection of the patient to the ZSP

One of the strengths of the AORTA architecture is its VPN. The VPN looksafter a closed private network with only lawful healthcare providers connectedto it. Connecting all the patients to the network, and consequently allowingthem to connect to the VPN, means in fact the abolishing of the advantages ofsuch a VPN. Subsequently, new security techniques need to be used. In case ofthe AORTA architecture, which makes use of a provider-provisioned VPN, theQuality of Service (QoS) is also influenced negatively.

Among other things, the QoS guarantees a specific level of performance,reliability, and availability. Those quality attributes are stated to be very im-portant for the EPD. With the vanishing of the provider-provisioned VPN andthe increased amount of connected users, the QoS needs to be redefined, whichobviously result in less performance, availability, and reliability.

4.2.4 Connection to an External Database (PAS)

Next to a connection to existing components in the AORTA architecture it is alsoa possibility to expand the AORTA with extra components. One of the solutions


is visualized in Figure 4.4.

Figure 4.4: AORTA elaborated with PAS

In the current AORTA architecture, the quality attributes, performance, avail-ability, and reliability are guaranteed by the provider-provisioned VPN. It canbe argued that connecting a patient to the architecture affects the quality at-tributes in a negative way. As a result, big consequences for a healthcare provideroccur. Think for example at the increase of the average duration of a consult, orworse at the moment a patient is in a life threatening situation.

When recapitulating the importance of availability of the medical data andthe performance of the system, it can be stated that performance demands areless strict for the patients. Therefore, healthcare provider requests should havepriority in the system. To guarantee the priority without excluding the patientfrom interacting, a solution could be an alternative architecture for the patientnext to the existing AORTA architecture. To communicate the medical data andto set the authorization profile, there should be a communication line betweenthe two architectures.

A big advantage of connecting a new system to the AORTA is the unim-paired private network for the qualified healthcare providers. As a consequence,the SLA’s of the server provided VPN remains valid. The communication linewith the patients architecture is the only possible disturbance for the SLA. There-


fore, a communication protocol is used, which prevent the possible disturbance.Another solution to prevent the disturbance of the SLA is to limit the datas-

tream. Limiting the datastream is realized by implementing an external database.All the medical data stored at the healthcare providers is exported to the database.Patients interact with their own medical data file by accessing the database.

However, there are also some disadvantages to mention. First of all, theinconsistency of the data. There should be a design decision made, how im-portant the consistency of the medical data must be. Is it necessary the patientshould see the most actual version of his medical data file or is it possible toupdate the medical data once a day? In case of the latter the data is updated ata quiet moment of the day. Appropiately, the AORTA architecture experiencesno negative side effects of data requests.

Another problem concerning the consistency is the update of the authoriza-tion protocol. A patient should be able to grant persons the right to examinespecific parts of his medical data file. It should not be the case that initially allthe connected persons have access to newly added information. In life threat-ening situations, a healthcare provider should always be able to request vitalinformation, regardless of the authorization profile. Therefore, it is initially ra-tional to exclude every user from accessing newly added data. However, if ahealthcare provider add new data of the patient, he can, with approval of thepatient, adjust the authorization profile.

4.2.5 Conclusion of Connection Methods

Not all possible solutions for a patient connection are evaluated and compared.All the direct connections of the patient to the AORTA are discussed, but itis possible to make another design or another connection point for the newlydesigned system.

Table 4.1 summarizes the advantages and disadvantages of the different con-nection methods described in the previous sections. In comparison with an ex-ternal system, a direct connection to one of the components of the AORTA isoverall more cost effective.

A connection to the PAS results in no significant impact on the AORTA ar-chitecture. The VPNs to which the healthcare providers are connected can guar-antee the QoS as agreed on in the legacy system. The other connection methodsall have a negative impact on the relevant quality attributes.

With the use of an external database, which contains the same data as in


Connection Method Disadvantage AdvantageConnection to the national connectionpoint (LSP)

Scalability Overall costs

SecurityPerformance

Connection to the healthcare provider(GBZ)

Costs forhealthcareprovider

Overall costs

SecurityAvailabilityReliabilityPerformance

Connection to the closed network (DCN) Security Overall costsReliabilityAvailabilityPerformance

Connection to an External Database (PAS) Costs The AORTAis not affectednegatively

Inconsistency ofdataPerformance forthe Patient

Table 4.1: Advantages and disadvantages of the different connection methods

the AORTA, inconsistency between the databases can occur. A patient can notexamine newly added data directly. The data is only updated at uneventfulmoments of the day. Most data request, 80 percent, of the healthcare providersare between 8:00 and 17:00 [11]. So, updates at night, are a sensible option.

In the external connected system (PAS), security is pointed out as the mostrelevant quality attribute. Security measures are, however, impacting perfor-mance, e.g. due to the encrypted data, and the SSL/TLS sessions.

If there should be no impact on the relevant quality attributes in the AORTA,a connection to an external database should be realized.

Chapter 5

Architecture Tradeoff Analysis Method

5.1 Architecture Tradeoff Analysis Method

To be sure a system functions as it supposed to, the system should be analyzed.If the only measurement is on the final implementation, different flaws canoccur. Aspects in the architecture, which negatively influences the quality at-tributes, are detected too late and can cause excessive costs and possible risks.Flaws can be prevented when the architecture was evaluated in an early stage.

With the design of a software architecture, business goals are translated intoa software system. In the sequel of the thesis the definition of software architec-ture provided by Len Bass, Paul Clements and Rick Kazman is used.[51]

The software architecture of a program or computing system is the structure or struc-tures of the system, which comprise software elements, the externally visible propertiesof those elements, and the relationships among them.

An architecture evaluation can be applied at any stage of the architecture’s life-time. In the subsequent chapter an evaluation is applied to the expanssion of theAORTA architecture. The architecture is based on a legacy system, the AORTA,and a new designed system. So, an early evaluation as well a late evaluation isimplemented. The outcome of the evaluations result in the same, the evaluationtells the architect where he is at risk.

Nowadays, different evaluation methods can be used. In the thesis, the fo-cus is on the Architecture Tradeoff Analysis Method (ATAM). The purpose ofthe ATAM is described by Kazman, Klein and Clements as follows: [52]

The purpose of the ATAM is to assess the consequences of architectural decisions inlight of quality attribute requirements.

36 5. Architecture Tradeoff Analysis Method

On their website the Software Engineering Institute (SEI) lists proven benefitsof the ATAM[53]. The benefits applicable to the evaluations in the thesis are:

• clarified quality attribute requirements

• identified risks early in the life-cycle

The first item mentioned is concerned with the quality attribute requirements.Therefore, it is important to have a clear vision of the characterizations of eachquality attribute.

In Figure 5.1, a diagram is displayed, which shows a conceptual flow of theATAM.

Figure 5.1: Conceptual flow of the ATAM [53].

The Business drivers are acquired from different stakeholders. From thebusiness drivers the quality attributes are derived. The quality attributes arecivilized in different scenarios and listed in a quality attribute tree. A scenariodescribes the interaction of a stakeholder with the system. Three types of sce-narios can be described:

• use case scenarios; use case scenarios describe the user interaction withthe final system.

• growth scenarios; growth scenarios describe the possible future changesof the system.

5.1. Architecture Tradeoff Analysis Method 37

• exploratory scenarios; exploratory scenarios describe extreme changes,which can result in a risk for a good and predictable execution of the sys-tem.

Parallel to the above described flow of business drivers to scenarios anotherflow is displayed. In the flow the software architecture, which is also derivedfrom the different stakeholders, provides the architectural approaches. Fromthe architectural approaches the architectural decisions are determined.

After the analysis of the different scenarios and the architectural decisions,four different outputs are identified. Two of the outputs are concerned with therisks and non-risks of specific architectural decisions. In contrast to the non-risks, which are deemed to be safe, risks may lead to undesirable consequencesregarding the stated quality attribute requirements.

The other two outputs of the analysis are the sensitivity points and the trade-offs. A sensitivity point is a property which is necessary for achieving fair re-sponses of a specific quality attribute. A sensitivity point can, however, affectanother quality attribute in a negative way. The properties consists of one ormore components in an architecture. Sensitivity can also be created by relation-ships between different components. If a sensitivity point affects more than onequality attribute, the term tradeoff point is used [50][52].

The ATAM is divided into four different phases. Each phase consist of dif-ferent steps [52].

• Phase 0: Presentation

1. Present the ATAM

2. Present business drivers

3. Present architecture

• Phase 1: Investigation and Analysis

4. Identify architectural approaches

5. Generate quality attribute utility tree

6. Analyze architectural approaches

• Phase 2: Testing

7. Brainstorm and prioritize scenarios

8. Analyze architectural approaches

38 5. Architecture Tradeoff Analysis Method

• Phase 3: Reporting

9. Present results

In the subsequent chapter, the ATAM steps are applied to the expanded EPDarchitecture. The choice for ATAM is based on the ability of evaluating a legacyas well a new architecture, which is the case in the expanded EPD system. In theexpanded EPD system, the legacy system, AORTA, is expanded with a newlydesigned architecture, the PAS. Another reason for using ATAM is the analysisof the quality attributes. In the EPD system different quality attributes are im-portant. The evaluation, according to ATAM, reveals the grade of satisficationaccording to particular quality goals. The tradeoff between the quality goalsbecomes also clear.

During an ATAM evaluation all the stakeholders in the system are involved.During the evaluation in the thesis, the influences of the stakeholders are re-duced to the information gain from Nictiz documentation, a research by TNOon the demands for an EPD, and different other literature.

Chapter 6

Expansion of the AORTA Architecture

6.1 Expansion of the Architecture

For the evaluation of the expansion of the AORTA architecture the businessdrivers and the software architecture are obtained from the documentation ofNictiz. The documentation includes, among other things, a technical architec-ture of the AORTA. The stakeholders demands towards the different require-ments of an EPD, are gathered from different researches and documentation.Therefore, the evaluation in the thesis does not cover all the ATAM steps. Thesteps concerning the influence of the stakeholders is replaced by a vision gath-ered from different documentation. In the subsequent of the chapter, the differ-ent outputs of the steps are characterized by sections. The steps without outputare omitted from the evaluation description. The omitted steps include all thesteps from phase 0. In phase 0 a formal agreement is setup between the evalu-ating organization using ATAM and the client. The first six steps from phase 2,consists of the repetition of the steps of phase 1. The steps in phase 2 are alsonot outlined again.

6.1.1 Phase 1, Step 1

Step 1 of phase 1 involves the presentation of the evaluation technique, ATAM.ATAM is described in Chapter 5.


From the various documents concerning the AORTA a list of business goals andquality attributes of interest are identified.

First the major stakeholders in the architecture are listed and described.

• Patient; the patient demands are described in Chapter 2 section 2.4.

40 6. Expansion of the AORTA Architecture

• Healthcare provider; the healthcare providers are described in Section 2.5.

• Manager; a healthcare provider can also play a role as a manager. Thinkfor example at a general practitioner with his own doctor’s practice. Someof the points mentioned in the previous item, can also be applicable to themanager. One of the points of interest for a manager is the transparancyof the data. Transparancy results in an increase of the patient safety. How-ever, too much transparancy gives a rival practice an insight into the man-agement data.

• Service provider and developer of health systems; there is an emphasis onthe technical design decisions. The system must be technical feasible toimplement and maintain.

The business goals are divided in primary, secondary, and other business goals.

• Primary business goals:

– Healthcare providers should be able to exchange medical data of pa-tients in a secure fashion.

– Patients should be able to connect to the system, without negativeinfluences for the work progress of the healthcare provider.

– Medical data should be only available for authorized persons.

• Secondary business goals:

– New healthcare providers should be able to connect to the system.

• Other business goals:

– In the future, different other parties should also be participating inthe system.

Table 6.1 lists the quality attributes of interest. Corresponding scenarios arelisted to the right of the quality attributes.

Quality AttributeGoals

ID Attribute-Specific Requirements

Security Se1 Secure communicationSe2 Secure componentsSe3 Secure data

6.1. Expansion of the Architecture 41

Quality AttributeGoals

ID Attribute-Specific Requirements

Availability A1 Hardware failureA2 Maintenance

Reliability R1 Frequentie of hardware failureScalability Sc1 Maximal capacityPerformance P1 Data transfertimeInteroperability I1 Different systems are connected

Table 6.1: EPD Quality Attributes of Interest

Defenitions of the different quality attributes are outlined below:

Security

Security concerns the ability to resist unauthorized attempts of data manipu-lation and data usage (e.g. reading the data). The measures taken for securityshould not obstruct an authorized person to use the desired service.[32]

Scalability

Scalability is concerned with the ability to handle growing amounts of work.The ability of enlarging an existing network with other connected systems isanother feature of scalability. [32]

Availability

Availability is the opportunity of a system to perform correctly on a requestat a given instant in time. It can also be stated as the accessibility of a systemresource in a timely manner. [32]

Reliability

Reliability refers to a low downtime and a consistent output, i.e. run continu-ously without failure [32].


Interoperability

Interoperability is the ability of two or more implementations of systems to co-exist and work together [32].

Performance

The performance in a system is the degree to which a system or componentaccomplishes its designated functions within given constraints, e.g. speed, ac-curacy, or memory usage [66].


Step 3 of phase 1 describes the architecture to evaluate. Chapter 3 outlines anaccurate description of the AORTA. An extra addition to the AORTA architec-ture is the connection of the patient. For the expansion an external system isconnected to the AORTA architecture. The expanded AORTA architecture isvisualized in Figure 6.1.

Figure 6.1: AORTA elaborated with PAS

Connecting a new actor to an existing architecture can have a big impact onthe existing system. In case of the AORTA, the performance and security should


not be influenced by the connection of patients. Therefore, no changes are madein the current AORTA architecture. Another reason for leaving the AORTA asdesigned by Nictiz, is the current state of implementation of the system.

To be sure the AORTA is performing as expected, patient data requests areexecuted by a seperate system, the patient access system (PAS). The data is notacquired directly from the AORTA. The AORTA is a closed system in which alldata requests from the healthcare providers are routed via a national connectionpoint (LSP). If patient requests are also executed by the LSP, performance isdecreased heavily. Therefore, the medical data is stored in seperate databasesfrom where the patient gains access to his medical data.

Most important quality attribute in the additional system is security. Thesecurity consists of physical as well technological security measures.

The result of the seperate system is data duplication. Databases are updatedwith the data from the healthcare providers. As a result, data inconsistencyoccurs. However, consistency of the databases in the PAS with the data in theAORTA is not of great importance. It is acceptable to update the data oncein 24 hours. Therefore, data is updated on uneventful moments to relieve theAORTA. Performance of the legacy system is not affected.

Another aspect to take in mind is the autorisation profile. It is important thatthe autorisation profile is initially set in such a way, the patient can not expe-rience any negative influences. As a result, profile adjustments can be queuedand be managed at the moment the national connection point is not busy.

Next to storage space for medical data, there is also storage space reservedfor comments by patients. The reserved space is used for communication be-tween healthcare provider and patient. The patient can, for example, keep adiary of his healing progress. The database with comments is installed in thedata tier next to the medical databases.

To realize all the above mentioned the PAS consists of three layers. First ofall, a data layer. The data layer consist of different databases, which containthe medical data from the healthcare providers. Databases with medical dataof the whole population of a country is very delicate for attacks and intrusions.Therefore, all data is encrypted and can only be decrypted with a key only theresponsible patient possesses. The data consisting of the comments of patientsand/or healthcare providers is also encrypted. The patient and the responsiblehealthcare provider share a key to decrypt the data.

The second layer in the PAS is an application tier. The application tier ispositionated above the data tier. All incoming requests from the patient as well


data updates from the LSP are handled in a secure fashion by the tier. A patientrequest for data is responded with the appropiate data belonging to that patient.A patient can only receive data he is related to. Therefore, the application tier,determines the identity of the user and the data related to the person.

The data provided by the AORTA is encrypted by the application tier. Thedata is encrypted with a key, the application shares with the patient related tothe data. The encrypted data is stored in the appropiate database in the datatier.

Another security measure is the use of a demilitarized zone, a secure area.Within the zone resides the data tier and the application tier. The demilitarizedzone can only be accessed by a single access point secured with a checkpoint.Nictiz mentions a possible connection of the registers with the ZIM by a VPN.If that is realized, the demilitarized zone is also connected to the VPN.

The third layer of the PAS, the presentation layer, resides at the workstationof the users. Before using the application, the user needs to authenticate him-self to the presentation layer. The presentation layer contains the key to decryptthe medical data and provides a graphical user interface for the patient to com-municate with the PAS. Communication with the PAS occurs through securesessions.

In contrast to security, performance is not of great importance in the PAS.Therefore, a session is closed after one hour of use or 5 minutes of idleness. Thechance a malicious person misuses the system is decreased. Logging a sessionoff, also guarantees that all session garbage is collected.

Next to security, scalability plays an important role in the PAS. Each inhab-itant of the Netherlands should have his own account. To suffice scalabilityrequirements different application servers and databases are installed. As a re-sult, loadbalancing can be applied, so more data requests can be handled.


In step 4 of phase 1 the architectural approaches are identified. The architecturalapproaches consists of the most dominant architectural approaches.

• The system makes use of the Secure Channel pattern between the ZIM andthe PAS.

• A three-tiered layered approach is used for the patient access system.


• The Demilitarized Zone pattern is used to secure the logic tier and datatier of the patient access system.

• The ZIM has an single access point with the application tier of the newlyadded three-tier layer system.

• The connection between the application tier and the ZIM is making use ofthe Limited Access pattern.

• A central database is used for the storage of the medical datafiles of thepatients. The ZIM is the only one with write access to the database.

• A central database is used for the storage of the medical information addedby the patient. The database contains also the autorisation profile infor-mation.

• A distributed data repository is used. Each healthcare provider has itsown database with medical data of his patients.

• The Publisher-Subscriber pattern is used to update the central databasewith the changed data in the GBZs. It is also used to update the autorisa-tion profile in the ZIM.

• To access the logic tier in the patient access system, a checkpoint is used.

• A security session is setup with the user and the logic tier.

The different approaches listed above, have different influences on the ar-chitecture. There are different issues to think about.

• Secure channel pattern:

– Due to the encryption mechanism secure channels conflicts perfor-mance.

– Due to the server certificates, cost is increased and maintenance over-head is added.

– Scalability and Availability can be impacted if the encryption mech-anism causes server-affinity. Server-affinity leads to undermining ofeffective fail-over and load balancing.

• Three-tiered layer pattern:


– Performance is affected by the use of the three-tiered layer pattern.Before accessing the data tier, the logic tier needs to be passed.

• Demilitarized zone pattern:

– A single point of failure can influence availability.

– Cost is increased, due to extra elements that needs to be installed tobuild the DMZ.

– Extra network traffic filtering is necessary, which impacts performance.

• Single access point pattern:

– Entrance to the legacy system is slowed down.

– The single access point can become a single point of failure.

• Limited access pattern:

– The limited access pattern can give difficulties concerning retrofitting.

– The use of the limited access pattern, without other security tech-niques can carry the danger of someone in the middle tricking a backend.

• Central database:

– A disadvantage of a central database is the single point of failure.

– All the information should be required and stored at a single database,so congestion can occur.

• Distributed data repository:

– A data repository can become unreachable, which can result in anincomplete data file of a specific patient.

– All medical data needs to be gathered from different databases toresult in a complete patient’s medical data file.

• Publisher-Subscriber pattern:

– The publisher-subscriber pattern pushes changes in the data whenthe system is not heavily used. Therefore, some inconsistency canoccur within the data files.


• Checkpoint pattern:

– The checkpoint pattern can require complex algorithms to deal withinvalid access and malicious users.

• Security Session pattern:

– Performance can be influenced if there are too many large sessionobjects. Session timeouts are a possible solution.

– Session identifiers can be forged, so complicated session identifiersshould be designed.


The result of step 5 of phase 1 is an utility tree of specific quality attributes re-quirements that comprise system utility. The utility tree is build up as describedby Clements, Kazman and Klein [50]:

• Level 1: Utility

• Level 2: Quality attributes as mentioned in Section 6.1.2

• Level 3: Quality attribute refinement; The meaning of the quality attributesare described in more detail or in which way they can be measured.

• Level 4: Quality attribute scenario; Scenarios are used to capture in ana-lyzable detail what each quality attribute means.

• Priority: The priority is subdivided in importance and difficulty. Both areassigned a numerical value: 10 for low, 20 for medium and 30 for high.This results in a sum, which represents the priority of a specific scenario.

Table 6.2 lists the utility tree. Level 1, Utility, is omitted in the table.

Level 2: Qual-ity Attribute

Level 3: Quality At-tibute Refinement

Level 4: Quality At-tribute Scenario

Impo

rtan

ce

Dif

ficul

ty

Sum

Security Se1: Secure communica-tion

Se1.1: Security betweenZIM and registers

20 20 40





Impo

rtan

ce

Dif

ficul

ty

Sum

Se1.2: Security betweenGBZ application andZIM

30 20 50

Se1.3: Security betweenGBZ users and ZIM

30 20 50

Se1.4: Security betweenGBZ files and ZIM

30 20 50

Se1.5: Security betweenZIM and PAS

30 20 50

Se1.6: Security betweenPAS and presentationtier at the patient’s sys-tem

30 20 50

Se2: Secure components Se2.1: Internal securityof the ZIM

30 10 40

Se2.2: Internal securityof a GBZ

30 10 40

Se2.3: Security of thePAS

30 10 40

Se3: Secure data Se3.1: The data of thePAS is secured

30 20 50

Se3.2: The data re-quested by the patient issecured

30 10 40

Availability A1: Hardware failure A1.1: Occurance of asmall intrusion in thedifferent components orchain is repaired in lessthen 15 minutes.

20 10 30





Impo

rtan

ce

Dif

ficul

ty

Sum

A1.2: Occurance of a bigintrusion in the chainfrom DCN to GBZ is re-paired in less then 12hours.

20 20 40

A1.3: Occurance of a bigintrusion in a GBZ is re-paired in less then a day.

20 20 40

A1.4: Components inthe AORTA are notreachable

20 10 30

A1.5: Occurance of a bigintrusion in the ZIM cannever occur.

30 10 40

A1.6: Occurance of a bigintrusion in the chainbetween DCN and ZIMcan never occur.

30 10 40

A2: Maintenance A2.1: Maintenance ofa GBZ is performed onquiet moments.

20 10 30

Scalability Sc1: Maximal capacity Sc1.1: AORTA systemcan support 20.000GBZs.

20 10 30

Sc1.2: AORTA systemcan exchange more then4.312.000.000 messagesa year.

20 10 30

Sc1.3: AORTA systemcan have more then10.000 simulteanoususer sessions.

20 10 30





Impo

rtan

ce

Dif

ficul

ty

Sum

Sc1.4: The PAS systemshould have a capacityof 20.000.000 users.

10 10 20

Performance P1: Data transfertime P1.1: A request for pa-tient data should be pro-cessed in an average of 5seconds.

30 30 60

Interoperability I1: Different systems areconnected

I1.1: Patient can connectto the system with hishome computer.

20 20 40

I1.2: Different health-care systems are con-nected to the ZIM.

30 20 50

Table 6.2: EPD Utility Tree with Priorities


In step 6 of phase 1 the architectural approaches are analyzed. Different analysisquestions are generated associated with the architectural approaches. The ques-tions are answered and addressed to a quality attribute. Next to this analysis alist of sensitivity points, tradeoff points, risks, and nonrisks are identified.


Scenario # : Se1.1: Security between ZIM and registersSe1.1Attribute(s) SecurityEnvironment Normal operationsStimulus Acquiring information from registersResponse Secure communication line is setup between ZIM and registerArchitectural Decisions Risk Sensitivity Tradeoff NonriskAD 1: SSL/TLS is used for T2secure communicationAD 2: Attempts of the ZIM S12 NR1to acquire a CRL and theresult of that attempt,is logged at the ZIMAD 3: For acquiring a CRL, R3 S6,S7PKIO is usedAD 4: The ZIM has a R2 S8single point of accessAD 5: At the access S5 NR2point a checkpoint isinstalledReasoning • With the use of cryptography, SSL/TLS

guarantees data integrity and an end-to-end secure connection,prevented from eavesdropping, tampering and message forgery.

• To be sure a request for a CRL is succeeded, the attempt andresult is logged at the ZIM. This way, it can be guaranteed thelatest CRL is used.

• With the use of a PKI different security mechanisms are supported.These security mechanisms consist of confidentiality, integrity,authentication, and non-repudiation.

• With the use of SSL/TLS in combination with PKI, itis possible to identify clients as well servers.

• The ZIM is connected to the registers by the publicinternet. To make it more difficult for an intruder to connectto the ZIM a single access point is created. In combinationwith a checkpoint an effective identification and authenticationmethod is created.

ArchitectureDiagram

Table 6.3: Analyzing Scenario Se1.1


Scenario # : Se1.2: Security between GBZ application and ZIMSe1.2Attribute(s) SecurityEnvironment Normal operationsStimulus Connection of GBZ application to the ZIMResponse Secure communication line is setupArchitectural Decisions Risk Sensitivity Tradeoff NonriskAD 1: SSL/TLS is used for T2secure communicationAD 2: Two-side authentication T3 NR4between UZI servercertificateand ZIM certificateAD 3: RSA-WITH-RC4-128-MD5 or R4RSA-WITH-RC4-128-SHA is usedAD 4: 128 bit temporary S6 NR5(changes every 5 minutes)keys are usedAD 5: Maximum session NR3duration of 8 hoursAD 6: Maximum unused session R5duration of 15 minutesReasoning • With the use of cryptography, SSL/TLS


• Two-side authentication, the ZIM as wel GBZ are authenticated,makes it possible to identify an imposter.

• A cipher suite is used for key exchange, bulk encryption,and message authentication

• With the use of temporary keys replay attacks can be avoided.Furthermore, it is impossible to decrypt messages, encryptedby old temporary keys, gained by eavesdropping.

• A maximum session duration is determined to guaranteethe system is not accessible without authorized supervision.

ArchitectureDiagram



Scenario # : Se1.3: Security between GBZ users and ZIMSe1.3Attribute(s) SecurityEnvironment Normal operationsStimulus Connection GBZ user to ZIMResponse Secure communication line is setupArchitectural Decisions Risk Sensitivity Tradeoff NonriskAD 1: SSL/TLS is used for T2secure communicationAD 2: Two-side authentication T3 NR4between UZI pasand ZIM certificateAD 3: RSA-WITH-RC4-128-MD5 or R4RSA-WITH-RC4-128-SHA is usedAD 4: 128 bit temporary S6(changes every 5 minutes)keys are usedAD 5: Maximum session NR3duration of 8 hoursAD 6: Maximum unused session R5duration of 30 minutesAD 7: Maximum unused application R5duration of 15 minutesReasoning • With the use of cryptography, SSL/TLS


• Two-side authentication, the ZIM as wel GBZ user areauthenticated, makes it possible to identify an imposter.




ArchitectureDiagram



Scenario # : Se1.4: Security between GBZ files and ZIMSe1.4Attribute(s) SecurityEnvironment Normal operationsStimulus Connection GBZ files to ZIMResponse Secure communication line is setupArchitectural Decisions Risk Sensitivity Tradeoff NonriskAD 1: SSL/TLS is used for T2secure communicationAD 2: Two-side authentication T3 Nr4between UZI server certificateand ZIM certificateAD 3: RSA-WITH-RC4-128-MD5 or R4RSA-WITH-RC4-128-SHA is usedAD 4: 128 bit temporary S6(changes every 5 minutes)keys are usedAD 5: Maximum session NR3duration of 8 hoursAD 6: Maximum unused session R5duration of 15 minutesReasoning • With the use of cryptography, SSL/TLS


• Two-side authentication, the ZIM as wel GBZ are authenticated,makes it possible to identify an imposter.




ArchitectureDiagram



Scenario # : Se1.5: Security between ZIM and PASSe1.5Attribute(s) SecurityEnvironment Update operationsStimulus Data updates are necessaryResponse Data is updatedArchitectural Decisions Risk Sensitivity Tradeoff NonriskAD 1: Secure channel pattern T1 NR2is usedAD 2: The PAS has a single S8 NR6access pointAD 3: The PAS makes use of S11 NR2a checkpointReasoning • A secure channel pattern is used to setup

a secure channel, a SSL connection, between ZIM and PAS.• A single access point in combination with a checkpoint

is an effective way for identification and authentication.• Only a single access point need to be secured, which

makes it harder for an intruder to attack the system.ArchitectureDiagram



Scenario # : Se1.6: Security between PAS and presentationSe1.6 tier at the patient’s systemAttribute(s) SecurityEnvironment Data requests by patientStimulus The patient does a data requestResponse A secure session is setup and encrypted data is send to the patientArchitectural Decisions Risk Sensitivity Tradeoff NonriskAD 1: Security Sessionpattern is usedAD 2: A secure session is R5 NR7logged off after 5minutes of idlenessAD 3: A secure session is R5 NR7logged off one hour aftersetup.AD 4: The PAS has a Single S8Access Point patternAD 5: The PAS makes use of S11the Check Point patternReasoning • A secure session takes care of a secure

channel between the user and the PAS. To be sure a securesession is logged of after setup, it will automatically givea session timeout after one hour or 5 minutes of idleness.This will prevent the presence of too many unused sessionobjects.

• Interruption of a secure session improves security.the chance of unauthorized persons misusing the system isreduced.

• The PAS has only a single access point. In combinationwith a checkpoint, identification and authentication caneffectively be performed.

ArchitectureDiagram



Scenario # : Se2.1: Internal security of the ZIMSe2.1Attribute(s) SecurityEnvironment Normal operationsStimulus Unauthorized use of ZIMResponse Unauthorized person is denied to use the ZIMArchitectural Decisions Risk Sensitivity Tradeoff NonriskAD 1: Physical entrance NR8securityAD 2: Reliable maintenance NR9proceduresAD 3: Reliable personel R6Reasoning • The ZIM acts as a router; HL7 payload is

not observed. As a consequence, only physical securityin combination with reliable maintenance procedures are sufficientfor the ZIM.

ArchitectureDiagram



Scenario # : Se2.2: Internal security of the GBZSe2.2Attribute(s) SecurityEnvironment Normal operationsStimulus Unauthorized use GBZResponse Unauthorized person is denied to use the GBZArchitectural Decisions Risk Sensitivity Tradeoff NonriskAD 1: The healthcare provider NR11is personally responsible forthe securityAD 2: The NEN 7510 norm NR10should be applied.AD 3: Workspaces from where R7patient data is exchangedare physical secured.Reasoning • A GBZ differs for each healthcare provider.

It is diffult to determine general security rules for a GBZ.Therefore, each healthcare provider is responsible for thesecurity of his own GBZ.

• The NEN 7510 norm describes protocols about informationsecurity in the healthcare. To guarantee security, healthcareproviders should adopt this norm.

• Workspaces which exchange patient data and backupsshould be physical secured. This way, it is impossible foran unauthorized person to gain access to patient files.

ArchitectureDiagram



Scenario # : Se2.3: Internal security of the PASSe2.3Attribute(s) SecurityEnvironment Normal operationsStimulus Unauthorized use PASResponse Unauthorized person is denied to use the PASArchitectural Decisions Risk Sensitivity Tradeoff NonriskAD 1: For the PAS the S9demilitarized zone patternis used.AD 2: The stored data in T4 NR12the data tier is encryptedAD 3: The logic tier in S11 NR13the PAS gives onlyaccess to parts in thedata tier belonging tothe authenticated patient.Reasoning • A demilitarized zone places the PAS in a

secure area. With a single point of access, a demilitarizedzone reduces the possibilities for an intruder to attackthe system.

• The data should be encrypted in such a way that onlythe concerning patient can decrypt the data.

• The logic tier limits the access of the patientto the medical data. Only the data concerning theauthenticated patient can be requested. As a consequence,security of the data is improved.

ArchitectureDiagram



Scenario # : Se3.1: The data of the PAS is securedSe3.1Attribute(s) SecurityEnvironment Normal operationsStimulus Data exertion in the PASResponse Encrypted data is stored/requested in/from the PASArchitectural Decisions Risk Sensitivity Tradeoff NonriskAD 1: Patient data file T4 NR12is stored completelyin the data tier of thePAS in an encrypted wayAD 2: The patient is NR14the only possessor ofthe decryption keyReasoning • To reduce the load of the ZIM and GBZs, patient

data is encrypted and stored in a central database.• The data should be encrypted in such a way that only the

concerning patient can decrypt his own file. Therefore,the patient is the only possessor of the decryption key.

ArchitectureDiagram



Scenario # : Se3.2: The data requested by the patient is securedSe3.2Attribute(s) SecurityEnvironment Normal operationsStimulus Patient does a data request on the PASResponse Encrypted data is received by patientArchitectural Decisions Risk Sensitivity Tradeoff NonriskAD 1: The data is not R8cached/saved at thepatient’s systemAD 2: The patient is NR14the only possessor ofthe decryption keyAD 3: The user R5application logs theuser of after fiveminutes of idlenessAD 4: The patient is NR15responsible for themanagement of therequested medical dataReasoning • The data is not stored at the patient’s

system. Unless negligency of the patient, it is thereforeimpossible for an intruder to come in possesion of decryptedmedical data.

• The data is encrypted in such a way that only theconcerning patient can decrypt his own file. Thepatient is the only possessor of the decryption key.As a consequence, if an intruder got in possesion of theencrypted medical data file, he should also get inpossesion of the decryption key to read the data

• The application logs off after 5 minutes of idleness.Consequently, an extra burden is created for an intruderto make use of a workingstation of a patient.

• The patient is responsible for everything he doeswith the data.

ArchitectureDiagram



Scenario # : A1.1: Occurance of a small intrusion in the com-A1.1 ponents or chain of the AORTA is repaired in less then 15 minutes.Attribute(s) AvailabilityEnvironment Normal operationStimulus A small intrusion in the systemResponse The system is repaired in less then 15 minutesArchitectural Decisions Risk Sensitivity Tradeoff NonriskAD 1: Daily backups are R9 T5performedReasoning • If any problems occur with important

data, a backup should be available.ArchitectureDiagram

Table 6.14: Analyzing Scenario A1.1


Scenario # : A1.3: Occurance of a big intrusion in a GBZ is repairedA1.3 in less then a day.Attribute(s) AvailabilityEnvironment Normal operationStimulus A big intrusion in a GBZResponse Intrusion is repaired in less then a dayArchitectural Decisions Risk Sensitivity Tradeoff NonriskAD 1: It is not necessary R10,R11to use a fault tolerantplatform.AD 2: Patient data needs R9 T5to be backed upReasoning • A big intrusion should be fixed in 24 hours.

With professional system administrators, this should bepossible without the use of a fault tolerant platform.This reduces system costs.

• It should not be possible that patient files canbe erased due to an intrusion. Therefore, a backup shouldbe made and stored at a secure place.

ArchitectureDiagram



Scenario # : A1.4: Components in the AORTA are not reachableA1.4Attribute(s) AvailabilityEnvironment Normal operationsStimulus An unreachable componentResponse Components trying to contact the unavailable

component are informedArchitectural Decisions Risk Sensitivity Tradeoff NonriskAD 1: Users of an unavailable NR16,NR17GBZ or ZIM are informed aboutthe inaccessible component.AD 2: If an unreachable component NR16,NR18becomes available again,it will inform the users.AD 3: In the AORTA a R12 T6distributed data repositoryis used. Each GBZ has its owndatabase.Reasoning • To avoid unneccessary requests to an unavailable

GBZ, the GBZ is listed as unreachable.• Possible downtime can be logged and measures can be

taken if a GBZ has a longer downtime then prescribed.• With a distributed data repository not all the data

becomes unavailable when a GBZ can not be reached.• Storing the data locally on the GBZ of the composer,

makes it easier to point out the responsible person fofspecific data.

ArchitectureDiagram



Scenario # : A1.5: Occurance of a big intrusion in the ZIM canA1.5 never occur.Attribute(s) AvailabilityEnvironment Normal operationsStimulus A failure in the ZIMResponse ZIM functions are over taken by another ZIMArchitectural Decisions Risk Sensitivity Tradeoff NonriskAD 1: The ZIM has a fault S13 NR19tolerant platform.AD 2: There is a test/demo R13 S14,S15facility with a separate ZIM.AD 3: Daily backups of the R9 T5ZIM is made to an auxiliary ZIM.AD 4: Every DCN should be able S15 NR20to connect within a day withthe auxiliary ZIM.Reasoning • With a fault tolerant platform the ZIM can operate

properly in the event of a failure of some of its components.• Test and demo’s are proven on a test ZIM first. This way

only proven updates are revised to the original ZIM.• Before connecting to the original ZIM, a GBZ is first proven

on a test ZIM.ArchitectureDiagram



Scenario # : A1.6: Occurance of a big intrusion in the chainA1.6 between DCN and ZIM can never occur.Attribute(s) AvailabilityEnvironment Normal operationsStimulus A failure in the DCNResponse Communication goes over a redundant pathArchitectural Decisions Risk Sensitivity Tradeoff NonriskAD 1: A DCN has an active T7redundant connection with theoperational ZIMReasoning • If a connection path is interrupted, another

path to the ZIM is taken. As a consequence, the chance theZIM is not available is decreased.

ArchitectureDiagram



Scenario # : R1.1: In the ZIM and the chain between DCNR1.1 and ZIM no big intrusion are allowed.Attribute(s) ReliabilityEnvironment Normal operationsStimulus An intrusion occursResponse Intrusion is preventedArchitectural Decisions Risk Sensitivity Tradeoff NonriskAD 1: The ZIM has a fault S13 NR19tolerant platform.AD 2: A DCN has an active T7redundant connection with theoperational ZIMReasoning • With a fault tolerant platform the ZIM can operate

properly in the event of a failure of some of its components.• If a connection path is interrupted, another

path to the ZIM is taken. As a consequence, the chance aZIM is unreachable is decreased.

ArchitectureDiagram

Table 6.19: Analyzing Scenario R1.1


Scenario # : Sc1.1: System can support 20.000 GBZs.Sc1.1Attribute(s) ScalabilityEnvironment Normal operationsStimulus 20.000 GBZs are connected to the ZIMResponse No occurance of negative influences on the quality attributesArchitectural Decisions Risk Sensitivity Tradeoff NonriskAD 1: A ZIM can consist of T7different connection pointsexecuting on differenthardware platforms.AD 2: A GBZ can only have NR21a single SSL connectionto the ZIM.AD 3: The ZIM makes use of T8 NR22SSL offloadersReasoning • With different hardware platforms the

system load can be divided.• To prevent overburdening of the SSL connections

only a single SSL connection from ZIM to GBZ is possible.• Due to SSL offloaders the ZIM is relieved from SSL processing.

ArchitectureDiagram

Table 6.20: Analyzing Scenario Sc1.1


Scenario # : Sc1.2: System can exchange more then 4.312.000.000Sc1.2 messages a year.Attribute(s) ScalabilityEnvironment Normal operationsStimulus 4.312.000.000 messages are sendResponse No problems occurArchitectural Decisions Risk Sensitivity Tradeoff NonriskAD 1: A ZIM can consist of T7different connection pointsexecuting on differenthardware platforms.Reasoning • Most data exchange is within a region. With the

use of different connection points, each region can beassigned to one connection point. This way, the message streamcan be regulated and optimized.

ArchitectureDiagram



Scenario # : Sc1.3: The system can have more then 10.000Sc1.3 simulteanous user sessions.Attribute(s) ScalabilityEnvironment Normal operationsStimulus 10.000 simulteanous sessions are startedResponse No problems occurArchitectural Decisions Risk Sensitivity Tradeoff NonriskAD 1: In a SSL/TLS session NR21different other SSL/TLSsessions can be setupReasoning • Each GBZ can only have a single SSL/TLS session

with the ZIM. However, this session can consist of differentother SSL/TLS session. This way different simulteanous usersessions are possible.

ArchitectureDiagram



Scenario # : Sc1.4: The PAS system should have a capacity ofSc1.4 20.000.000 users.Attribute(s) ScalabilityEnvironment Normal operationsStimulusResponseArchitectural Decisions Risk Sensitivity Tradeoff NonriskAD 1:The PAS can consist S17of different connectionpoints executing ondifferent hardwareplatformsAD 2: The data tier S17consist of differentdatabases.Reasoning • With different connection points, users

can assigned to a specific hardware platform, whichperform user requests.

• With different databases, more data requests can behandled at the same time.

ArchitectureDiagram



Scenario # : P1.1: A request for patient data should beP1.1 processed in an average of 5 seconds.Attribute(s) PerformanceEnvironment Normal operationsStimulus Patient data is requestedResponse Within 5 seconds a respons is receivedArchitectural Decisions Risk Sensitivity Tradeoff NonriskAD 1: The user stays R5connected for 5 minutesafter removing the UZIpas.AD 2: A SSL/TLS session NR3can be open for amaximum of eight hours.AD 3: Publish-subscriber R14 NR23pattern is used to updatethe database andautorisation profileAD 4: The ZIM makes use of NR24loadbalancingAD 5: The ZIM and GBZs T8 N22make use of SSL offloading.Reasoning • Within a time interval of five minutes, the

user can take his UZI pas out of the reader and restarthis session on another workspace. As a result, the user doesnot have to log in each time, he leaves from his workspace.

• It is not necessary to setup a SSL/TLS session each timemessages need to be send. So, it is not necessary to executethe authentication procedure each time a SSL/TLS sessionis needed. As a consequence, performance will increase.

• With the use of the publish-subscriber pattern, newlyadded data can be pushed at times the system is not heavily used.

• Loadbalancing is used to divide work. This way,more work can be processed at the same time.

• With SSL offloading, SSL processing is taken care ofby an appliance or another computer exclusively installedfor this purpose. Consequently, the ZIM and GBZs are relievedof this obligation.

ArchitectureDiagram

Table 6.24: Analyzing Scenario P1.1


Scenario # : I1.1: Patient can connect to the system with hisI1.1 home computer.Attribute(s) InteroperabilityEnvironment Normal operationsStimulus Patient connects to the PASResponse Patient is connected to the PASArchitectural Decisions Risk Sensitivity Tradeoff NonriskAD 1: Three tier layer NR25,NR26pattern is usedReasoning • The presentation tier runs on the system

of the patient. As a consequence, only the presentation tiershould be compatible with different system platforms.

ArchitectureDiagram

Table 6.25: Analyzing Scenario I1.1


Scenario # : I1.2: Different healthcare systems are connectedI1.2 to the ZIM.Attribute(s) InteroperabilityEnvironment Normal operationsStimulus A GBZ is connectedResponse The GBZ is working without problemsArchitectural Decisions Risk Sensitivity Tradeoff NonriskAD 1: A healthcare system R15 S16should suffice therequirements of a GBZAD 2: A GBZ is initially R13 S14,S15tested on a test ZIMReasoning • By claiming a healthcare system should

suffice different requirements, it can be guaranteed ahealthcare system can connect to the ZIM.

• Before connecting a GBZ to the ZIM, it is tested ona test ZIM. Flaws can be detected and adjusted to operate in apredictable way. As a consequence, each healthcare system cantuned in such a way, it executes well in the AORTA.

•

ArchitectureDiagram

Table 6.26: Analyzing Scenario I1.2


The risks mentioned in the scenarios are described below:

• R1: With the use of SSL offloading, data is passed unencrypted from of-floader to client. This means the internal network should be guaranteedsecure.

• R2: A single point of failure is created. A single point of failure makes thesystem vulnerable for attacks to sabotage the working of the system.

• R3: A trusted third party is needed. This means a web of trust is needed.

• R4: The hash algorithms used for message authentication, SHA/MD5, isproven to be unreliable [56].

• R5: In the time a system is logged on and a session/application is openfor usage a malicious person can misuse the system.

• R6: How to determine if a person is reliable? People can make mistakesand can be influenced by other persons.

• R7: In life threatening situations, a physical secured environment can re-sult in dangerous consequences.

• R8: There is no option to save medical data. Caching of the data is alsonot possible. The possibility exists the patient is making print screens andsaves his own medical data file unsecured on his system.

• R9: With backups the risk of inconsistency occurs. It is possible data islost, due to inconsistency between the database and an obsolete backupversion. Data should be backed up each time new data is added.

• R10: Without a fault tolerant platform, it is possible the system is downfor a longer time. This can result in an incomplete overview of a patient’smedical file.

• R11: A system administrator, possible hardware and software, should beavailable twenty four seven.

• R12: Failure of a GBZ can result in an incomplete overview of a patient’smedical file. Unavailability of important information can result in lifethreathening situations.


• R13: To get reliable and complete results from the test ZIM, the auxiliaryZIM should be an exact copy of the operating ZIM. This also includes anidentical environment in which the ZIM runs. It is obvious to think, thisis not realizable for all circumstances.

• R14: The data in the PAS and the autorisation profile in the ZIM are up-dated on quiescent moments. This means the autorisation profile of theZIM and the data in the PAS is not up to date all the time.

• R15: It takes time and money to change a health system into a GBZ. Itis thinkable time pressure, to connect all health systems to the ZIM, willresult in flaws in the total system.

The sensitivity points mentioned in the scenarios are described below:

• S1: For encryption SSL uses single shared key for both encryption and de-cryption. Single shared keys are considered less secure than public keys.

• S2: Setting up a SSL connection can be very laborious, due to the SSL-handshake based on UZI passes with long PKI keys, RC4 with key lengthof 128 bit. As a result, the performance of the system is impacted.

• S3: Generation and checking of SSL keys takes relatively much process-ing time. In fact, setting up a secure SSL channel can reduce the numberof simultaneous users that the ZIM can support by a factor of 10. Conse-quently, scalability is negatively affected.[57]

• S4 : SSL offloading affects costs in a negative way.

• S5 : Performance is negatively influenced, due to the fact each user shouldbe authenticated before granting access.

• S6 : The generation of SSL/TLS keys is laborious. Consequently, perfor-mance is affected negatively. Especially in the case when temporary keysare used.

• S7: Computationally expensive.

• S8: Availability can be affected by the firewall, which can become a singlepoint of failure.


• S9: Costs are increased, due to extra elements that need to be procured tobuild a DMZ. Next to filtering routers, firewall software and firewall host,this also include different network equipment.

• S10: Patients can only watch their own medical data file. As a conse-quence, performance is negatively influenced.

• S11: Network traffic needs to be filtered, which have an impact on theperformance.

• S12: Acquiring a CRL and logging of this process has an impact on theperformance of the total system.

• S13: A fault tolerant platform increases costs.

• S14: An auxiliary ZIM increases costs due extra hardware, maintenance,and extra security measures.

• S15: There are extra paths necessary from the DCNs to an auxiliary ZIM.This increases cost.

• S16: Healthcare providers should change their systems to suffice the dif-ferent requirements of a GBZ. This increases cost for the healthcare provider.

• S17: Extra hardware results in an increase of costs.

The tradeoff points mentioned in the scenarios are described below:

• T1: A secure channel pattern affects performance and costs. Performanceis impacted by the encryption mechanism and cost is increased due tomaintenance overhead and server certificates.

• T2: For encryption SSL uses single shared key for both encryption and de-cryption. Single shared keys are considered less secure than public keys.Next tto the influence on security, performance is also affected. Setting upa SSL connection can be very laborious, due to the SSL-handshake basedon UZI passes with long PKI keys, RC4 with key length of 128 bit. Withthe use of SSL/TLS it is also possible that there is an impact on scalabil-ity. Generation and checking of SSL keys takes relatively much processingtime. In fact, setting up a secure SSL channel can reduce the number ofsimultaneous users that the ZIM can support by a factor of 10.[57]


• T3: With the use of certificates costs are rising. Next to cost, there is alsoan impact on the performance.

• T4: Data from the ZIM needs to be encrypted in the logic tier of the PAS.Performance is impacted. Next to performance, security is also at risk.Before encrypting data, the data is available in the PAS environment un-encrypted.

• T5: With the use of backups, security and performance are impacted. Abackup increases the amount of data and thus the possibility to give anintruder the probability to come in possession of the data. As mentionedperformance is also affected. More data needs to be stored, so more timeis needed.

• T6: A medical data file can consist of data from different databases atdifferent locations. The result of the complete medical datafile is as fast asthe slowest respons. Consequently, performance is influenced. Reliabilityplays also an important role in combination with a distrubuted database.The data is routed over different paths in the network. Different paths,means more possibility for feasible failures.

• T7: Extra redundant paths from DCN to ZIM, means extra connectionpoints ato the ZIM. Next to costs, this also increases security risks. Moreconnection points means more possibilities for an intruder to attack thesystem.

• T8: A SSL offloader increases costs, due to extra hardware. Another as-pect with SSL offloader is the risk of security decrease. Data is send unen-crypted from the offloader to the target system.

The non risks mentioned in the scenarios are described below:

• NR1: Logging of an attempt to acquire a CRL and the result of that at-tempt, means an extra security check. It is secured that always the latestCRL is used.

• NR2: Performance of the communication between PAS and ZIM is not ofgreat importance. Data should be updated once in a while, so the check-point pattern and secure channel pattern form no burden in the architec-ture.


• NR3: A healthcare provider does 80 percent of its request between 8:00and 17:00. Most of these requests, 70 percent, are performed between 8:00and 12:00. As a consequence, logging the system off after 8 hours is a rea-sonable measure. The chance a user is logged off while using the systemis tolerable low.

• NR4: After the ZIM and GBZ have authenticate eachother, a session isopen for at least 8 hours (when using the system). So, it is not necessaryto perform authentication each time a GBZ contacts the ZIM.

• NR5: When temporary keys are renewed by an idle or unengaged system,the performance is not affected.

• NR6: The PAS is a self operating system. The only PAS dependency isthe data updates from the ZIM. However, consistency of the data in thePAS and ZIM has no high priority. Consequently, there is enough timeto repair a single point of failure and the restore the connection with theZIM.

• NR7: Performance is not a key driver in the PAS system. Therefore, log-ging the patient off when he is connected to the PAS has no big conse-quences. Interruption of the session improves security.

• NR8: A building can be pysical secured in many ways. With the use of,for example, camera’s, fances, and guards an intruder can be kept outside.

• NR9: Reliable maintenance procedures and protocols can be determined.

• NR10: The NEN 7510 norm describes security measures a healthcare providershould adopt to suffice a secure GBZ and practice. When applying NEN7510 most security issues are taken care of.

• NR11: A GBZ owner is personally responsible for his own system. Due tothe fines and possibility of losing their proffesion, a healthcare provider iscompelled to pay attention to the security measures.

• NR12: Medical data files are stored in the PAS in an encrypted way. Thepatient is the only one who can encrypt this data. As a result, a databasewith amedical data becomes useless, without all the decryption keys of allthe patients.


• NR13: To make misuse of the system, a person needs to be able to imper-sonate another person. If this seemes possible, the intruder can only comein possession of the date of one specific patient. However, the data is en-crypted and without decryption keys from the specific patient the data isuseless.

• NR14: The only decryption keys for medical data of a specific patient, areavailable at the system of this patient.

• NR15: It is impossible to control the patient’s management of his owndata and system. The patient should be informed about the risks of beingcareless with his medical data.

• NR16: With the knowledge of an unreachable GBZ unnecessary attemptsto reach the GBZ can be avoided.

• NR17: With the knowledge of an unreachable GBZ, the owner of that GBZcan be contacted for the necessary information. This way, a complete med-ical data file can be generated.

• NR18: A GBZ gives notice of its availability after it was down. It is notnecessary for the ZIM to check the availability each time, so there is noimpact on performance.

• NR19: The ZIM is the most important component in the AORTA. Failureof the ZIM means failure of the whole system. It is important to keep theZIM available twenty four seven. To neutralize possible hardware failuresa fault tolerant platform is necessary.

• NR20: The lines from DCN and the auxiliary ZIM are already installed.With possible adversity it should be possible to connect an auxiliary ZIMwithin a day.

• NR21: Within one SSL connection other SSL sessions can be started. As aconsequence, a single SSL connection with the ZIM forms no burden fordata transfer.

• NR22: In case of the AORTA, the SSL offloader is installed together withthe ZIM in a demilitarized zone. Taken in consideration that the ZIM isphysical secured, unencrypted data send in this zone, forms no securityrisk.


• NR23: It is sufficient to update the data in the PAS once a day. Therefore,an outdated database in the PAS is not vital. The autorisation profile inthe ZIM should initially be adjusted in such a way, the patient is not neg-atively affected. So the outdated autorisation profile is also not a burden.

• NR24: The ZIM consist of different platforms with the possibility to con-nect different DCNs to each of them. This means loadbalancing is not aproblem in the AORTA.

• NR25: Performance plays no significant role in the PAS. Key driver in thissystem is security. A three layer architecture protects the data tier fromthe presentation tier by the logic tier. The logic tier routes the user to aspecific part of the data tier with his own medical data. It is impossible fora user to request information from other patients. The logic tier also takescare of encryption of the data from the ZIM.

• NR26: The presentation tier can be designed in such a way it is compatiblewith different platforms. Therefore, a patient is not obligated to adjust hishome system.


In step 5 of phase 1, Section 6.1.5, an utility tree is created. Based on the qualityattribute refinement in the tree different scenarios are listed. In this ATAM stepa larger set of scenarios should be identified by the different stakeholders. Inthis case, the most scenarios are already based on the experiences of the stake-holders. From the set of scenarios listed in phase 1 step 5, Section 6.1.5, the 30percent most important ones are listed below.


Sc. # Scenario Qualityattribute

Se1.2 Security between GBZ application and ZIM SecuritySe1.3 Security between GBZ users and ZIM SecuritySe1.4 Security between GBZ files and ZIM SecuritySe2.3 Security of the PAS SecuritySe3.1 The data of the PAS is secured SecurityA1.2 Occurance of a big intrusion in the chain from DCN to

GBZ is repaired in less then 12 hoursAvailability

A1.3 Occurance of a big intrusion in a GBZ is repaired inless then a day

Availability

A1.5 Occurance of a big intrusion in the ZIM can never oc-cur

Availability

A1.6 Occurance of a big intrusion in the chain betweenDCN and ZIM can never occur

Availability

P1.1 A request for patient data should be processed in anaverage of 5 seconds.

Performance

Table 6.27: Scenarios

6.1.8 Evaluation Conclusion

From the evaluation of the architecture, different conclusions concerning theimpact on quality attributes can be stated.

It is clear, the most important quality attribute of the system is security. TheAORTA is designed to be a secure system. However, there are different risks,which can prove the opposite. One of the possible risks that can occur is theuse of MD5 or SHA-1 as a cypthographic hashfunction. MD5 and SHA-1 isproven to be an unsafe security measure [56]. Other security problems that canoccur is due the fact an unused session is not closed immediately. Intruderscan misuse the system in the time the system stays connected to the ZIM, whilethe authorized person temporarily is away. The single point of access can alsobe mentioned as a security risk. The ZIM is via the RF connected with thepublic internet. If the connection fails, no contact to the registers and the PASis possible. Consequently, a failing connection results in a failing or an insecureAORTA system.


Connection of the PAS to the ZIM is secured with a secure channel. In thefuture it is possible to connect the PAS to the ZIM by a VPN. Most importantdata transfers between the ZIM and the PAS are the updates of the medicaldata files. In other words, not complete files are send, but only small medicalfile fragments. The biggest security issue concering the PAS is mentioned inscenario Se2.3, which handles the internal security of the PAS. Data receivedfrom the ZIM is encrypted in the application tier and stored in databases. Thedatabases form no direct security risk, because the data stored in it is encryptedand the patient is the only holder of the decryption key. The problem ariseswhen the data is encrypted, before storage. For a moment, the data residesunencrypted in the PAS. At this moment it becomes possible for an intruder tocome in possesion of unencrypted medical data.

Another quality attribute that plays an important role in the AORTA archi-tecture, is performance. With the addition of the patient as an extra actor, per-formance can decrease heavily. With the use of the publish subscriber patternit can be realized the PAS is only updated at uneventful moments. So, systemperformance has no noticeable impact for the healthcare provider. The draw-back of the use of a publish subscriber pattern is inconsistency of the data of thePAS compared to the GBZs. The question that rises is to what extent it wouldbe a surplus value for the patient to examine his medical data file instantly atthe moment new data is added to his file.

To have a good working EPD system, the GBZs in the AORTA should havea high availability rate. In case of the AORTA, availability means an increasein costs and an increase in security risks. Cost are increased due to redundanthardware, redundant paths, and maintenance. Redundant paths means extraconnection points to the ZIM, which results in more possibilities for an intruderto misuse the system. Security is also impacted by the different backups thatare made by the GBZs. The owner of a GBZ should store the backup in a secureplace.

With the implementation of the PAS cost rises. Not only due to extra databases,application servers and maintenance but also by the use of a DMZ. The extra se-curity certificates also increases costs.

In Table 6.28, the two different architectures are listed with the different risksand non-risks which can be concluded from the evaluation.


Architecture Risks Non-RiskAORTA security performance

availability scalabilityPAS costs performance

inconsistency availability

Table 6.28: Risks and non-risks in the architecture

It is just verified, that a possible expansion of the AORTA, with the patientas an actor, is possible without impact on the current system. It is thinkable,another solution for the PAS is possible, e.g. another connection point, or otherdesign decisions.

Chapter 7

Discussion

7.1 Discussion of connection patient

There are different reasons to connect a patient to an electronic health record.The most important reasons are the right to examine his own medical data fileand the right to determine who has access to the file. The reasons are based onthe dutch law, described in the WGBO. To meet the requirements of the WGBO,a connection of the patient to the AORTA is proposed. However, there are alter-natives, instead of a connection to an electronic health record, to suffice this law.Different perspectives are mentioned which concludes in a direct connection tothe EPD as to be the best option. When speaking of a connection to the AORTA,the connection of the patient to an external system (PAS), as proposed in Section6.1.3, is aimed at.

In the AORTA design, a request for medical data is logged. With the log-file, it is possible to see which healthcare provider requested specific data andhow often. It is possible for a patient to watch the logfile and complain in caseof unauthorized access. The logfile can also trigger the patient to adjust theautorisation profile belonging to his medical file. In other words, the patientis responsible for access authorization of his own medical file. A healthcareprovider can act as some kind of broker between the patient and the AORTA.To examine the logfile and autorisation profile a patient can visit his generalpractitioner. The biggest disadvantage of this solution is the increase of visitsfrom people with nonrelated medical issues. As a consequence, precious time ofa healthcare provider is attenuated. To avoid this, it is sensible to think to installa special location from where a patient can gain access to his EPD data. Due tothe fact, only limited IP adresses are providable to access the ZIM, the systemin this location should be connected to a GBZ. A connection to a GBZ can, how-ever, result in a heavily increase of data requests for the GBZ. In lifethreateningsituations, every second counts. If in lifethreatening situations a data request is

86 7. Discussion

delayed, unwanted scenarios can occur. Another problem with the decrease ofperformance is the increase of patients waiting for medical care.

Another problem is the accessibility of all the data. To bring a visit to a gen-eral practitioner can be a barrier for a lot of people. The barrier can occur dueto physical, mental as well transport problems. This way, a patient is deprivedfrom different rights.

In Table 7.1 the different advantages and disadvantages are outlined.

Connection option Disadvantage AdvantageDirect connection to AORTA Security Accessibility

Cost PerformanceNo impact onmedical caretime

Connection by healthcare provider Medical caretime decrease

Easy applicable

AccessibilityConnection by special installed system Cost No impact on

medical caretime

PerformanceSecurityAccessibility

Table 7.1: Advantages and disadvantages of the different interaction methods

It is clear that a connection to the healthcare provider is not a realistic optiondue to the impact on the medical care time decrease. A connection to a specialinstalled system, which is in contact with a GBZ, can also result in unwantedperformance decrease. In this case it is necessary to implement precedences inthe system. Healthcare provider requests should have priority over the requestsfrom the patients. Another problematic aspect could be the available facilitiesand the responsibilities concerning the facilities.

With a direct connection to the AORTA, the necessary facilities are installedat a central point. The facilities consist of the parts which are necessary for theimplementation of a PAS system. As mentioned, the PAS is situated in a DMZ.

7.2. Discussion AORTA architecture 87

This should increase the physical security, among other things.In summary, we argue that a direct connection to the AORTA is the best

option.

7.2 Discussion AORTA architecture

The AORTA architecture was designed in a time internet was not very commonin a household. Nowadays, the amount of internet connections has grown ex-plosively and almost everybody is active on the internet. As a consequence, itis very obvious to think a patient is able to examine his medical file at home.Unfortunately, the AORTA design is not evolved according to the internet de-velopment. The designers did not considered the patient as an active actor inthe system. A patient should still visit his healthcare provider to gain access tohis medical file or to adjust the autorisation profile. As concluded in Section 7.1,this is not the best solution for a patient connection.

As it become clear from Chapter 4, a connection of a patient to the AORTAis not self-evident. To prevent negative operating occurances for the AORTA, itseems necessary to design a complete new system, next to the AORTA. In thesystem, central databases are used for preventing the AORTA for an increase ofdata requests. The question rises, why also not using a central database for theAORTA, instead of the current distributed data repository. With the unavail-ability of a GBZ it is possible an incomplete medical data file is received. Aclaim for a GBZ is, among other things, that it can be unavailable at a maxi-mum of two times a year. Taken in mind that 20.000 GBZs can be connected tothe AORTA, this means it is rational to think of at least 100 unavailable GBZs aday. In case of a central database, with possible auxiliary databases, incompletemedical data files can be reduced extremely.

Another advantage of a central database is a cost decrease for the owner of aGBZ. It is not necessary to be online twenty four seven and security/ availabilitymeasures can be reduced.

Most reasons for the choice for a distributed database can also be appliedwith the use of a central database. With, for example, the addition of extrainformation to stored data, it can be determined who the legal owner of thedata is. It is also possible to store data from a specific healthcare provider to aspecific location within the database. With the use of a routing index, a completemedical data file can be generated. Nictiz also mentions the logging system at

88 7. Discussion

the GBZs as a reason to use distributed databases. However, this logging systemcan also be implemented with the use of a central database.

As a consequence, it can be argued if the use of distributed databases is anefficient design decision.

7.3 Discussion Expansion of the AORTA

The expansion of the AORTA, consists of the connection of the current archi-tecture to the newly designed PAS. With the expansion of the architecture, nonegative impact on the existing AORTA is created. The PAS is created in sucha way, it can operate independant of the AORTA. The only communication be-tween the two systems exist of an update of the medical data files and the au-thorisation profile. The communication can happen at uneventful moments, sothe AORTA does not experience a decrease of performance. Data requests are80 percent of the time performed between 8:00 and 17:00 [11]. So, data updatescan be executed by night.

Before resulting in the PAS/AORTA design different premises are made.First of all, the performance is not of great relevance for the PAS. No threatsoccur when requested data is slowed down by the system. Lack of occuringthreats due to unavailable data makes availability and reliability also not ofgreat importance. Real time consistency of a medical data file is also not a pri-ority in the PAS system. If the data is updated once a day, this would suffice.

For the PAS the main point of interest is security. With an insecure PAS, thewhole system fails. From the evaluation in Chapter 6, the most important se-curity risk is mentioned in scenario Se2.3 and Se3.1. Both scenarios include thetradeoff point T4. This tradeoff point mentions the availability of unencryptedmedical data within the PAS. This data resides within a DMZ. With good phys-ical and technological security, this should not be a big security issue. In theworst case situation, an intruder intercepts the unencrypted data. The unen-cryptyed data is only a small part of a medical data file. So, it may be concludedthat security is not impacted heavily.

The biggest disadvantage of the PAS is the increase of cost. Additional hard-ware, software and maintenance costs are necessary. However, some of the costsare also necessary when designing another architectural approach. The consid-eration to make is wheter the AORTA needs to operate as it is intended to, withan increase of cost as a consequence, or do a concession on the performance of

7.3. Discussion Expansion of the AORTA 89

the AORTA.

Chapter 8

State of the Art

8.1 Medical Informatics

Different countries around the world are putting efforts in implementing anelectronic health record. The Healthcare Information and Management SystemsSociety (HIMSS) investigated the efforts.[58] HIMSS categorizes the differentarchitectures into four models.

1. Fully Federated

• Patient data resides with source facility.

• Data remains in the source systems.

• EHR pulls patient data from carer systems.

• DWHS not clear.

2. Federated

• Patient data resides with source facility.

• Patient data consolidated in facility CDR.

• EHR is a process which pulls from local CDRs for updates to centralCDR as needed.

• DWHS works off CDR.

3. Service Oriented

• Patient data sent to EHR by message at end of care event.

• Local systems message enabled.

• EHR is a process which manages flow of messages.

• CDR holds care events within patient record.

92 8. State of the Art

4. Integrated EPR

• Single integrated hospital system.

• Embedded EHR capabilities.

From the research it can be concluded that most of the investigated countrieshave adopted the Service Oriented approach. This is in consensus, with thearticle of Ananda Mohan [60]. He mentions the central repository model andthe managed services model as the two most popular EHR approaches.

The central repository model is visualized in figure 8.1. In this model, thecentral database is filled with the data from the different healthcare providers.Data transport is established by SOAP Web services and ebXML as compelledby HL7.

Figure 8.1: Repository Model[60]

To route the data from the healthcare providers to the national data reposi-tory, different regions are provided with integration hubs. Those hubs can takecare of validation and verification of the sended messages. Data is retrievedfrom the repository by XML queries over secure channels. The secure channelscan exist of a high speed dedicated network or through secure encryption anddecryption mechanisms.

8.1. Medical Informatics 93

The other popular EHR solution is the shared services model, pictured infigure 8.2. In this model hosted applications are used to build a repository us-ing a shared database. It is also possible to provide a common user interfaceto these hosted applications. With a portal, provided with authentication andauthorisation mechanism, it is possible to extract data from the systems. In aregion the applications are consolidated in a single place. Service Oriented Ar-chitecture’s Enterprise Service Bus allows that such a regional managed centercan be accessed through the portal or by Web services.

Figure 8.2: Shared Services Model[60]

In contrast to the above described models, the EPD system of the Nether-lands can be categorized as the Federated model. Next to the Netherlands,Wales is the only other country which makes the decision to adopt this model.Wales made this choice based on the existence of variable legacy systems andthe cost/time to replace them.[58]

The chain of GBZs is a vulnerability of the AORTA architecture. This vulner-ability is argued by Ananda Mohan [59], as one of the disadvantages of a feder-ated system. He also mentioned that a federated system is appealing in theory,but in practice the system has different difficulties to overcome, like many im-plementation and performance difficulties. There are, however, also advantagesmentioned by Mohan. Those are, among other things, advantages mentioned inSection 3.2 as the reasons to adopt a federated model. First of all, data manage-ment can be done locally. Secondly, a decentralized data approach safeguards


privacy and security. Another advantage, is the relatively small infrastructure,which results in less capital and ongoing operating expense. However, in caseof the AORTA this advantage is diminished, due to elaboration with the PASsystem.

For supporting semantic interoperability between EHRs, HL7v3 and DI-COM is used. HL7v3 is an open system messaging standard. The HL7v3 andDICOM standard are also adopted in the AORTA architecture. An uniformstandard has different advantages. First of all, it becomes possible to commu-nicate with other EHRs in, for example, other countries. Another advantage isthe evolution of the standards. With a wide operational area, a flaw is detectedearlier and the standard can be adjusted appropiatly.

8.2 Architecture Models

In the thesis different architectures are mentioned. First of all, the three-tierarchitecture is proposed for the PAS. Another architecture revealed in the the-sis is the Service Oriented Architecture, which plays an important role in mostEHRs. In the following sections the state of the art concerning the architecturesare described.

8.2.1 Three-Tier architecture

For the PAS the three-tier architecture is proposed. This architecture is visual-ized in figure 8.3.

As been depicted the architecture consists of the following three tiers:

• Presentation tier: As the name suggests the first tier is responsible for pre-sentation and acts only as a client. The clients in the first tier, do not accessthe third-tier services directly. There is only secure interaction with thesecond tier.

• Logic tier: The second tier consists of different application servers. It co-ordinates the application processes. This tier is connected to the data tieras well the presentation tier. It acts as an client towards the data tier andas a server towards the presentation tier.

• Data tier: The third tier consists of a database(s) or filesystem(s). It actsonly as a server. It responds to requests from the logic tier. Data passed

8.2. Architecture Models 95

Figure 8.3: Three-tier Architecture

by the logic tier is stored and the data requests from the logic tier are re-sponded with the needed data.

Different reasons for adoption of a three-tier architecture can be mentioned.Modification or replacement of a tier does not affect other tiers. Furthermore,load balancing can be improved, due to the separation of the application anddatabase functionality. The different layers, provide also extra security to thesystem. It is not possible for a client to get direct access to sensitive data in thedata tier. Before getting to the data tier, the client should contact the logic tier.Within the logic tier, adequate security policies can be implemented.

As described in an article the layered approach in combination with SOA ischoosen for a hospital information system in Taiwan.[65] The article concludeswith the mentioning of a succesfull system.


8.2.2 Service-Oriented Architecture

Service Oriented Architecture (SOA) is a very popular model for implementingan EHR architecture. SOA is based on the communication between services.The communication can involve data passing or the coordination of some activ-ity by two or more services. The W3C describes a Service Oriented Architectureas a form of distributed systems architecture[61]. Different properties are men-tioned which typically characterizes a SOA. Those properties are outlined byW3C as follows:

• Logical view: The service is an abstracted, logical view of actual programs,databases, business processes, etc., defined in terms of what it does, typi-cally carrying out a business-level operation.

• Message orientation: The service is formally defined in terms of the mes-sages exchanged between provider agents and requester agents, and notthe properties of the agents themselves. The internal structure of an agent,including features such as its implementation language, process structureand even database structure, are deliberately abstracted away in the SOA:using the SOA discipline one does not and should not need to know howan agent implementing a service is constructed. A key benefit of this con-cerns so-called legacy systems. By avoiding any knowledge of the internalstructure of an agent, one can incorporate any software component or ap-plication that can be ”wrapped” in message handling code that allows itto adhere to the formal service definition.

• Description orientation: A service is described by machine-processablemeta data. The description supports the public nature of the SOA: onlythose details that are exposed to the public and important for the use of theservice should be included in the description. The semantics of a serviceshould be documented, either directly or indirectly, by its description.

• Granularity: Services tend to use a small number of operations with rela-tively large and complex messages.

• Network orientation: Services tend to be oriented toward use over a net-work, though this is not an absolute requirement.

• Platform neutral: Messages are sent in a platform-neutral, standardizedformat delivered through the interfaces. XML is the most obvious formatthat meets this constraint.

8.2. Architecture Models 97

In an article by Qusay H. Mahmoud [62], SOA is visualized as pictured infigure 8.4. In the model a service provider registers his service in a public reg-istry. If a consumer needs a specific service, he can request the service from theregistry. If the registry contains such a service, the consumer is provided with acontract and an endpoint address for the location of that service. At this point,an interaction between the consumer and provider is possible.

Figure 8.4: Service Oriented Architecture

SOA is not a new architectural approach. As described in an article in Com-putable by Kees Neven [63] early solutions for building a SOA are adopted,like Corba, J2EE, and Message Oriented Middleware. He concludes his articlethat nowadays, SOA is based on Web Services, different XML-based standards(WSDL, SOAP, UDDI), and the support of the industrie. Reflecting this infor-mation to figure 8.4, the services from the service provider are described usingWSDL. Subsequently, the registry could use UDDI to publish this service. Re-quests for a service are also realized by WSDL. All the messages send withinthis figure are using SOAP.

SOA is used widely, and is in practice proven to be a success. Joe McK-endrick mentions on his blog ten different companies where SOA made a differ-ence in 2006[64]. The companies mentioned, are operating in different sectors.


8.3 Techniques

In this section different techniques are described and compared with possiblealternatives. Techniques used in the AORTA are also described in appendix A.

8.3.1 IPsec VPN vs SSL VPN

In the AORTA architecture each actor is connected through a VPN. A VPN canbe accompanied with different security protocols. Traditional VPN’s rely onIPSec, where the rival uses SSL.

The exchange of patients data in the AORTA architecture happens on trans-port level secured with a SSL VPN. In his article, VPN’s: IPSec vs. SSL [46],Tony Bradley mentions different pro’s and con’s for IPSec VPNs as well for SSLVPNs.

First of all, IPSec VPN is examined. In contrast to the SSL VPN used in theAORTA architecture, the IPSec VPN works on the Network Layer of the OSIModel. This results in a secure data transport between two endpoints withoutan association to any specific application. Connected to an IPSec VPN, it ispossible for a client computer to see and access the entire network.

A pro as well as a con is the fact that third-party hardware and/or softwareis required before a connection to an IPSec VPN can be realized. The necessaryinstallation and configuration of IPSec client software applications result in anextra layer of security. However, this extra layer of security will result in extracosts. Licenses for the client software needs to be maintained and the softwareneeds to be installed and configured. All the client software should also beinstalled and configured on remote machines which can result in lots of workfor technical support.

The money issue mentioned with IPSec is not applicable to the SSL variantof VPN. To put it more strongly, the money issue is one of the largest pros forSSL. SSL is a common protocol, which capabilities are included in almost allweb browsers. With these capabilities build in, it becomes possible for mostcomputers to connect to a SSL VPN. Another pro of a SSL VPN is the possibilityof configuring access to a system. A connected peer can be tunneled to a specificapplication. As a consequence, not the whole local LAN is accessible.

As can be concluded from the article of J. Conover [47], full network accessis the domain of the IPSec VPN. SSL VPNs are developed to provide securityservices at the application layer and are particularly suited to mobile workers

8.3. Techniques 99

and extranet applications. Extranet applications are software data applicationsthat provides limited access to clients internal data. Combining the two differ-ent VPNs (i.e. combing application layer and network layer VPNs together) inan SSL VPN weakens both technologies.

In an article, IPSec or SSL? The Battle Begins [48], different factors are men-tioned to take into account when choosing one of the two technologies. Thequestions to think about are:

• What are the security risks involved?

• Is there scalability and flexibility?

• What are the protocols needed?

The article finishes with the remark that SSL VPN has significant advantagesover IPSec. However, there is an emphasis on the fact that a knowledgeableapproach of the requirements is necessary.

Despite of the remark SSL VPN has significant advantages over IPSec, theyboth offer many similar security techniques like, encryption and authentication.The differences between the two protocols are depicted in Table 8.1.

IPSec VPN SSL VPNType of connection Fixed connection Transient connection

Impact on cost Negative effect on Cost Positive effect on CostAccess Controls full network access limited data access

Applicability Special software and Common protocol inlicences are needed webbrowsers

Table 8.1: IPSec VPN vs. SSL VPN

Chapter 9

Conclusion

9.1 Conclusion

For the conclusion the research questions are answered. The questions are re-stated and the according answer is outlined below.

Is it necessary to adopt a national electronic health record?Different reasons are mentioned for using a national health system. First rea-son mentioned is the availability of the medical data. Availability twenty fourseven, means less mistakes in, for example, medicine proscription. Further-more, data import into the system is only needed once. Known medical relatedinformation do not have to be imported again. Time profit is another aspectmentioned. An EPD can reduce the waiting lists and can rescue lives in lifethreatening situations.

Is it necessary to connect a patient to the current EPD architectureWith the design of the AORTA, the architects did not reserve an active role forthe patient in the system. There are, however, different issues to mention, whya patient should be connected to the EPD system. The most important ones areexamining own medical data file, adjusting autorisation profile, checking log-files for medical data access, and the possibility for a special health treatmenton distance. There are different methods to fulfil the reasons for adoption of apatient. As outlined in the discussion, Chapter 7, the best option is to connect apatient to the AORTA. A direct connection increases accessiblitiy for the patientand the performance of the AORTA is not impacted. Medical care time is alsonot affected by a connection for the patient to the EPD.

Which technical possibilities are there for a patient to connect to the AORTA?The AORTA has different components to which a patient can connect. How-

102 9. Conclusion

ever, this can impact the AORTA in different ways. With a direct connection toone of the components of the AORTA, the impact on the quality attributes ofthe AORTA are affected in such a way, the whole system can fail. Therefore,a completely new system is designed (PAS) which is connected to the nationalconnection point of the AORTA. The PAS, connects the patient to his medicaldata file stored in central databases. The central databases are updated with themedical data from the AORTA.

In which way the AORTA architecture restricts the actions of the patients?The patient is not restricted in his actions. Expectations of a patient can be suf-ficed by the PAS. There are, however, several premises made, which influencesthe behaviour and output of the PAS. First of all, it is postulated that consistencyof the medical data is not of great importance for a patient. An update of hismedical data file, once a day should suffices. Resulting from this premise is thatperformance is also of no great importance. An accurate responds time can notbe guaranteed.

Which quality attributes are impacted, due to a patient connection?With the PAS system connected to the AORTA, no negative influences occur forthe execution of the AORTA system. Biggest disadvantage of the PAS system isan increase of cost.

Is it possible to expand the AORTA architecture, without any negative influences onthe current architecture, so it becomes possible for patients to be an actor in the system?With the PAS connected to the AORTA it is possible for a patient to access hisown medical data file. As mentioned before, there are different premises madeto result in an operative system. As a result, it can be concluded that there is nonegative impact on the current AORTA architecture.

The main research question concludes that an expansion of the AORTA ar-chitecture with the patient as an active actor is possible. The PAS/AORTA archi-tecture proposed in the thesis is a possible solution. However, it is also sensibleto think that in case of the patient connection the whole EPD system, includingAORTA, should be redesigned.

Different reasons for a redesign can be mentioned. First of all, the fact thatthe AORTA makes use of a distributed data repository. Each GBZ has its owndatabase, which contains the medical data of his patients. Unavailability of a

9.2. Research approach 103

GBZ, can result in an incomplete medical data file. Each day, an average of100 GBZs will be unavailable. With the use of a central database, with provenavailability and reliability measures, the amount of incomplete medical datafiles can be decreased drastically. With already the usage of a central database inthe PAS, it can also be a consideration to design a complete new EPD system, inwhich the healthcare poviders are also connected to a central database. Anotherreason can be cost. A new system next to the AORTA needs to be implemented.Putting the same functionality in a single system, can result in a decrease ofcost. Maintenance and redundancy can be diminished.

9.2 Research approach

The research approach in the thesis consists of a literature study in combinationwith a quantitative evaluation of the redesign of the AORTA architecture.

The AORTA architecture is an existing architecture, designed by Nictiz. Forthe thesis architectural documentation of the AORTA is used. This documen-tation is made publicly available by Nictiz. Each observation in the thesis con-cerning the AORTA is based on this documentation.

Different connection possibilities to the AORTA are assumed to be impossi-ble without impact on the system. These assumptions are not proven, but basedon logical understanding.

In the thesis the ATAM method is used to evaluate the redesigned EPD ar-chitecture. In the area of software architecture evaluation, ATAM is supposedto be the foremost method.

9.3 Future Research

As can be concluded, the connection of a patient to the AORTA is not self-evident. With the adoption of a new stakeholder in the system, it can be sensibleto review the complete EPD architecture. Future research needs to be done on apossible substitute EPD design, in which all the stakeholders are taken in mindfrom the beginning.

The EHR implementations of other countries can be examined and parts ofit can be applied to a new EHR design. From a research by the Healthcare Infor-mation and Management Systems Society [58] can be concluded, most countriesare using a service oriented approach. A service oriented approach can also be

104 9. Conclusion

an EHR solution for the Netherlands. With the use of, for example ATAM, itis possible to compare the service oriented solution with the current AORTAarchitecture.

In case the choice is made to implement the AORTA architecture, future re-search needs to be done on the connection possibilities of the patient. The fol-lowing points need to be taken in mind:

• A patient connection is not resulting in negative side effects for the AORTA.

• The patient is able to fulfil all the actions he is permitted to, according theDutch law (e.g. examining his medical data file)

• The different reasons for adoption of an EHR, are not negatively influ-enced.

Abbreviations

AH Authentication Header

ATAM Architecture Tradeoff Analysis Method

CA Certification Authority

CRL Certificate Revocation List

DCN Datacommunicatienetwerken

DNS Dynamic Name Server

EHR Electronic Health Record

EMD Elektronisch medisch dossier

EPD Elektronisch patienten dossier

ESP Encapsulating Security Payload

GBZ Goed beheerd zorgsysteem

HIMSS Healthcare Information and Management Systems Society

HL7V3 Health level 7 version 3

HTTP Hypertext Transfer protocol

IETF Internet Engineering Task Force

IKE IPsec Key Exchange

IP Internet Protocol

IPSec Internet Protocol Security

KNMP Koninklijke Nederlandse Maatschappij ter Bevordering der Pharmacie

LDAP Lightweight Directory Access Protocol

106 9. Conclusion

LHV Landelijke Huisartsen Vereniging

LSP Landelijk schakelpunt

PKI Public Key Infrastructure

PKI Public Key Infrastructure Overheid

QoS Quality of Service

RPC Remote Procedure Call

SA Security Association

SAML Security Assertion Markup Language

SBV-Z Sectorale berichtenvoorziening voor de zorgsector

SEI Software Engineering Institute

SLA Service Level Agreement

SOAP Simple Object Access Protocol

SSL Secure Sockets Layer

TCP Transport Control Protocol

TLS Transport Layer Security

UZI Unieke zorgverleneridentificatie

VAN Value Added Network

VPN Virtual Private Network

VWS Ministry of Volksgezondheid, Welzijn en Sport.

WDH Waarneemdossier huisartsen, observer file for general practioners.

WGBO Wet op de geneeskundige behandelingsovereenkomst

WSDL Web Service Definition Language

WS-I Web Services Interoperability Organization

WSP Web Service Profile

XIS XIS is a general term for a healthcare information systems.

XML eXtensible Markup Language

XSD XML Schema Definition

ZIM Zorginformatiemakelaar

ZSP Zorgserviceproviders

Bibliography

[1] dr. A. Klink, Invoering landelijk elektronisch Patientendossier, brief aan deVoorzitter van de Tweede Kamer, September 5, 2008

[2] Felix Hentenaar, Patieenten over fouten in medische informatie overdracht, Eenverkennend onderzoek, december 3, 2003

[3] Nictiz, Wat zijn de mogelijkheden van ICT in de zorg?https://www.nictiz.nl/?mid=102&pg=135

[4] Pim van der Beek, Ziekenhuizen zien EPD niet zitten, computable.nl,september 10, 2008http://www.computable.nl/artikel/ict topics/overheid/2700050/1277202/

ziekenhuizen-epd-niet-zitten.html?utm campaign=rss&utm medium=rss

[5] L. Ottes, O. van Rijen, Bij voorbaat achterhaald, Medisch Contact, Nr. 31/32augustus 1, 2008http://medischcontact.artsennet.nl/print.php?mod=DOS&conid=388228402

[6] Tweede Kamer, stel de patient centraal, NRC Handelsblad, september 9, 2008

[7] Patientendossier schendt eed van arts, NRC Handelsblad, september 15, 2008http://www.nrcnl/opinie/article1977493.ece/

Tweede Kamer, stel de patient centraal

[8] W.J. Jongejan, Het EPD als luchtkasteel, Medisch Contact, Nr. 33/34, augus-tus 15, 2008, link

[9] Ministerie van VWS, Elektronisch patientendossier (EPD), juli 21, 2008,http://www.minvws.nl/dossiers/elektronisch-patienten-dossier/

[10] Een zorg minder met een EPD, GGZ EPD onderzoek 2003, Amersfoort, mei28, 2003

108 BIBLIOGRAPHY

[11] Technische architectuur AORTA, NICTIZ, versie 3.0, mei 31, 2007

[12] Programma van Eisen voor een Goed Beheerd Zorgsysteem(GBZ), NICTIZ, ver-sie 2.0, mei 31, 2007

[13] Programma van Eisen voor een zorgserviceprovider (ZSP), NICTIZ, versie 2.0,mei 31, 2007

[14] Architectuurvisie AORTA, NICTIZ, versie 5.0, mei 31, 2007

[15] Implementatiegids HL73 Web Services Profile, NICTIZ, versie 1.2, augustus11, 2006

[16] Ministerie van VWS, Eerste Kamer stemt in met BSN in de zorg, april 9, 2008,http://www.minvws.nl/nieuwsberichten/meva/2008/

ek-stemt-in-met-bsn-in-de-zorg.asp

[17] Pim van der Beek, EPD is bewust geen dossier, Computable, september 9,2008

[18] A.J.M. de Bruijn, Onderzoek Landelijke Invoering Electronisch MedicatieDossier (EMD) en het Waarneem Dossier Huisartsen (WDH), Pricewater-houseCoopers, september 17, 2007

[19] Twente pleit voor beeindiging pilot WDH, www.ictzorg.com, april 15, 2008,http://www.ictzorg.com/home/id101-36804/twente pleit voor beeindiging

pilot wdh.html

[20] VWS-WDH-evaluatie, Eindrapportage van de evaluatie van de pilot WDH,Telematica Instituut & TNO, april 18, 2008

[21] I. Ruiter & M. van Hees Evaluatie pilot WDH Twente/Enschede, in-formatiepunt BSN in de zorg en landelijk EPD, juni 9, 2008,http://www.infoepd.nl/informatiepunt com/nieuws-evaluatie pilot wdh

twente enschede.php

[22] Softwareproblemen rond UZI-passen vertragen EMD-pilot Amsterdam, www.ictzorg.com, juli 1, 2008,www.ictzorg.com/home/id101-43607/softwareproblemen rond uzi-passen

vertragen emd-pilot amsterdam.html

[23] Steven van Eijck, LHV-voorzitter: Maak van ICT nu werke-lijk een zegen in de zorg, Medisch Contact, mei 2, 2008,http://medischcontact.artsennet.nl/content/dossiers/992177998/1363890803/

AMGATE 6059 138 TICH R209103498956627/?PHPSESSID=9d059bb51167f40a2f84486d7befa197

[24] Brief aan Tweede Kamer der Staten Generaal betreffende Elektronisch MedicatieDossier/AO ICT in de zorg 9 april 2008, KNMP, 7 april 2008

BIBLIOGRAPHY 109

[25] M.J. Boereboom, Brief aan KNMG, LHV, KNMP, VHN, NHG en KNGF betre-ffende Invoering EPD, Ministerie van VWS, mei 9, 2008

[26] Huisartsen leggen WDH-pilot stil, www.ictzorg.com, oktober 2, 2008http://www.ictzorg.com/home/id101-51709/huisartsen leggen

wdh-pilot stil.html

[27] Problemen EPD op werkvloer in schril contrast met politiekebeloftes Minister Klink, www.huisartsvandaag.nl, april 21, 2008,http://www.huisartsvandaag.nl/content/view/13289/121

[28] EPD? Nee!, de Vrije Huisarts, oktober 27, 2008,http://devrijehuisarts.org/stukkenpdf/LEPDnee271008.pdf

[29] http://www.pkioverheid.nl

[30] Joel Weise, Public Key Infrastructure Overview, Sun BluePrints Online, au-gust, 2001, http://www.sun.com/blueprints/0801/publickey.pdf

[31] http://www.nen7510.org

[32] Andrew S. Tanenbaum, Maarten van Steen, Distributed Systems, Principlesand Paradigms, Prentice Hall, 2002, eerste editie

[33] TLS Versus SSL, Microsoft Developer Network, september 25, 2008,http://msdn.microsoft.com/en-us/library/aa380515(VS.85).aspx

[34] RFC 2246, The TLS Protocol, Version 1.0, january, 1999,http://www.ietf.org/rfc/rfc2246.txt

[35] RFC 2828, Internet Security Glossary, may, 2000,http://www.ietf.org/rfc/rfc2828.txt

[36] Andrew S. Tanenbaum, Computer Networks, Fourth Edition, Pearson Ed-ucation International

[37] Don Box, David Ehnebuske, Gopal Kakivaya, Andrew Layman,Noah Mendelsohn, Henrik Frystyk Nielsen, Satish Thatte, DaveWiner, Simple Object ccess Protocol (SOAP) 1.1, W3C, may 8, 2000,http://www.w3.org/TR/2000/NOTE-SOAP-20000508/Toc478383512

[38] Erik Christensen, Francisco Curbera, Greg Meredith, Sanjiva Weer-awarana, Web Services Description Language (WSDL) 1.1, March 15, 2001,http://www.w3.org/TR/wsdl

[39] David Booth, Hugo Haas, Francis McCabe, Eric Newcomer, MichaelChampion, Chris Ferris, David Orchard, Web Services Architecture, Febru-ary 11, 2004, http://www.w3.org/TR/ws-arch

110 BIBLIOGRAPHY

[40] RFC 4158, Internet X.509 Public Key Infrastructure: Certification Path Building,September, 2005, http://www.ietf.org/rfc/rfc4158.txt

[41] RFC 2251, Lightweight Directory Access Protocol, December, 1997,http://www.ietf.org/rfc/rfc2251.txt

[42] RFC 4301, Security Architecture for the Internet Protocol,http://www.ietf.org/rfc/rfc4301.txt

[43] Laurens Mommers,Laurens Mommers: Patientdossier is overbodig en gevaar-lijk, NRC Handelsblad, juni 17, 2008

[44] http://wetboek.net/20080803/BW7/456.html?n=1

[45] Novum,Sancties bij fout in elektronisch patietendossier, September 13, 2007,http://www.elsevier.nl/web/Artikel/Sancties-bij-fout-in-

elektronisch-patintendossier.htm

[46] Tony Bradley, VPN’s: IPSec vs. SSL, http://netsecurity.about.com/cs/generalsecurity/a/aa111703.htm

[47] J. Conover, Current Analysis Report Summary: SSL VPN -IPSec Killer Or Overkill, TMCnet.com, September 12, 2003,http://www.tmcnet.com/tmcnet/articles/2003/091203ca.htm

[48] IPSec or SSL? The Battle Begins http://www.vpntools.com/vpntools articles/ipsec-ssl.htm

[49] All about SLL VPN http://www.vpntools.com/vpntools articles/about-sslvpn.htm

[50] Paul Clements,Rick Kazman, Mark Klein, Evaluating Software Architectures:Methods and Case Studies, Addison-Wesley, October, 2001

[51] Len Bass, Paul Clements, Rick Kazman, Software Architecture in Practice,Addison-Wesley, second edition, October, 2003

[52] Rick Kazman, Mark Klein, Paul Clements, ATAM:Method for Architecture Evaluation, August, 2000,www.sei.cmu.edu/pub/documents/00.reports/pdf/00tr004.pdf

[53] SEI,The Architecture Tradeoff Analysis Method (ATAM),www.sei.cmu.edu/architecture/ata method.html

[54] Markus Schumacher, Eduardo Fernandez-Buglioni, Duane Hybertson,Frank Buschmann, Peter Sommerlad, Security Patterns: Integrating Securityand Systems Engineering, Wiley, 2006

[55] Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Somerlad,Michael Stal, Pattern-Oriented Software Architecture: A System of Patterns,Wiley, Volume 1, 1996

BIBLIOGRAPHY 111

[56] Xiaoyun Wang, Dengguo Feng, Xuejia Lai, Hongbo Yu, Collisions for HashFunctions; MD4, MD5, HAVAL-128 and RIPEMD, August, 17, 2004

[57] Could encryption bottleneck be causing e-bank failures, September 7, 2000

[58] Electronic Health Records: A Global Perspective, HIMMS Enterprise SystemsSteering Committee and the Global Enterprise Task Force, August, 2008

[59] Ananda Mohan, EHR Patterns-Advantages and Challenges,Healthcare Informatics- A 3000 Feet View, March 3, 2007,http://healtcareinformatics3000feet.blogspot.com/2007/03/ehr-

patterns-advantages-and-challenges.html

[60] Ananda Mohan, National Electronic Health Record Models, Tata ConsultancyServices, 2007

[61] David Booth, Hugo Haas, Francis McCabe, Eric New-comer, Michael Champion, Chris Ferris, David Or-chard, Web Services Architecture, W3C, february 11, 2004,http://www.w3.org/TR/2004/NOTE-ws-arch-200040211/

service-oriented-architecture

[62] Qusay H. Mahmoud, Service-Oriented Architecture (SOA)and Web Services: The Road to Enterprise Applica-tion Integration(EAI), Sun microsystems, april, 2005,http://java.suncom/developer/technicalArticles/WebServices/soa

[63] Kees Neeven, De juiste manier om soa te implementeren, Computable, mei 13,2005

[64] Joe McKendrick, Ten companies where SOA made a difference in 2006, ZDNet,2006, http://blogs.zdnet.com/service-oriented/?p=781

[65] T.H. Yang, P.H. Cheng, C.H. Yang, F. Lai, C.L. Chen, H.H. Lee, K.P. Hsu,C.H. Chen, C.T. Tan, Y.S. Sun, A Scalable Multi-tier Architecture for the Na-tional Taiwan University Hospital Information System based on HL7 Standard.,IEEE, 2006

[66] Mario Barbacci, Mark H. Klein, Thomas A. Longstaff,Charles B. Weinstock, Quality Attributes, SEI, December, 1995,http://www.sei.cmu.edu/pub/documents/95.reports/tr021.95.pdf

Appendix A

Technical Description

A.1 Security Protocols

Security plays a major issue in the AORTA. Different security protocols are usedin the architecture. The protocols are described in the following sections.

A.1.1 PKIO

To manage different security mechanisms a good infrastructure is necessary. APublic Key Infrastructure (PKI) is an infrastructure which provides a foundationfor other security services. This foundation exists of the provision and usage ofpublic keys and certificates. Other applications and network security compo-nents are build on top of the PKI.[30] The IETF defines PKI as follows [35]:

A system of CAs (and, optionally, RAs and other supporting servers and agents) thatperform some set of certificate management, archive management, key management andtoken management functions for a community of users in an application of asymmetriccrypthograhpy.

In case of the AORTA architecture the UZI register plays the role of Registra-tion Authority (RA). All UZI passes are registered in the UZI register.

In the AORTA architecture the general PKI protocol is expanded with someextra features which result in the Public Key Infrastructure Overheid (PKIO)protocol. The extra features are described below [29]:

• One infrastructure with a single level of reliability; With a single electronicidentity of PKIO it is possible for users to make use of different electronicservices.

• A hierarchical structure of certificates; The certificate State of the Nether-lands is the root of a hierarchical structure of certificates.

114 A. Technical Description

• Based on the Dutch law and European standards; All legal demands andrules concerning those demands are elaborated on and stated in a docu-ment concerning PKIO.

• Distributors have to suffice the demands of PKIO; The distributors of thePKIO certificates should register themselves at the OPTA. The OPTA su-pervises the distribution.

• Qualified certificates for a electronic signature; A signature signed witha PKIO certificate is a qualified signature and has the same value as ahandwritten signature.

• The same distribution process for all certificates; The distributor of the cer-tificates should be registered at the OPTA. The OPTA keeps independentsupervision on the distribution process.

A.1.2 Virtual Private Network

A Virtual Private Network (VPN) is an overlay network on top of another net-work. In case of the AORTA architecture the VPN is build over the Internet.The rfc 2828 describes the VPN as follows[35]:

A restricted-use, logical (i.e., artificial or simulated) computer network that is con-structed from the system resources of a relatively public, physical (i.e., real) network(such as the Internet), often by using encryption (located at hosts or gateways), andoften by tunneling links of the virtual network across the real network.

In contrast to a dedicated network a VPN makes use of shared system resources.Where a dedicated network makes use of private or leased lines, a VPN uses anexisting network. This makes a VPN generally less expensive to build and op-erate. As described in rfc 2828 a VPN is tunneled across the real network.[35]Tunneling is described in subsection A.1.3.

In the AORTA a GBZ is connected with a provider-provisioned VPN. Aprovider-provisioned VPN is a complete package for a VPN service. This in-cludes a Service Level Agreement (SLA) in which, among other things, theQuality of Service (QoS) is described. QoS guarantees the quality, speed, avail-ability, capacity, stability and the restore time of the connection.

A.1. Security Protocols 115

A.1.3 Tunneling

A tunnelingprotocol is a protocol which makes it possible for different networksto interwork. Tunneling can be used when the different networks are of thesame type and a different network connects the both networks. The network,which transports the data of the communicating hosts, does not necessary sup-port the used protocol by the communicating hosts. The official definition ofthe IETF is outlined in RFC 2828 [35]:

A communication channel created in a computer network by encapsulating (carrying,layering) a communication protocol’s data packets in (on top of) a second protocol thatnormally would be carried above, or at the same layer as, the first one.

Tunneling in combination with firewalls, VPNs and IPsec with ESP is widelyused in practice [36]. IPsec and ESP are described in subsection A.1.6. In case ofthe AORTA architecture a provider-provisioned VPN is used (subsection A.1.2).With a provider-provisioned VPN, security is guaranteed till the front end of thecommunicating network. The security of the communication path to the actualclient hosts needs to be facilitated by other protocols. In the AORTA SSL, incombination with the provider provisioned VPN, is used to create end to endsecurity.[36][11] SSL is described in subsection A.1.4.

A.1.4 Secure Sockets Layer

The SSL protocol is suitable for tunneling. SSL is a cryptographic protocol. TheSSL protocol builds a secure connection between endpoints of the IP network-ing protocol (sockets). Building a SSL connection includes parameter negotia-tion between client and server, mutual authentication, secret communication,and data integrity protection. When the connection is setup, SSL is taking careof compression and encryption.[36] The official definition of the IETF is out-lined in RFC 2828 [35]:

An Internet protocol that uses connection-oriented end-to-end encryption to providedata confidentiality service and data integrity service and data integrity service for traf-fic between a client (often a web browser) and a server, and that can optionally providepeer entity authentication between the client and the server.

IETF mentions in RFC 2828 [35] that many Internet applications might be better


served by IPsec (described in subsection A.1.6).

A.1.5 Transport Layer Security

The successor of SSL is the TLS protocol. TLS is an application-independent se-curity protocol. For applications that require a high level of interoperability SSL3.0 or TLS should be chosen. There are some small differences between SSL 3.0and TLS. TLS has been formerly laid down in RFC 2246.[33] RFC 2246 describesthe differences between the two protocols as follows [34]:

The differences between this protocol and SSL 3.0 are not dramatic, but they are sig-nificant enough that TLS 1.0 and SSL 3.0 do not interoperate (although TLS 1.0 doesincorporate a mechanism by which a TLS implementation can back down to SSL 3.0).

According to Tanenbaum TLS is a slightly stronger protocol then SSL [36].

The TLS protocol is layered on top of a transport protocol and it is basedon TCP. It is divided into two layers. The lowest layer consists of the RecordProtocol. The Record Protocol implements a secure channel between a clientand a server

To setup a secure channel different messages need to be send between theclient and the server. The first message comes from the client, who informs theserver, which possible cryptographic algorithms it can handle. This messagealso includes the compression methods it supports. The server makes a choicebetween the algorithms and sends this back to the client. This communicationbetween the client and server can be seen as the first phase in the setup of a se-cure channel. The second phase is responsible for the authentication. The serverauthenticates itself to the client by passing a certificate containing its public key.This public key is signed by the Certification Authority. If necessary the clientsends a certificate to the server as well. Now the both parties are authenticatedto each other a session key is constructed. Therefore a client sends a randomnumber, encrypted with the server’s public key, to the server. If it is the casethat the client has authenticate itself to the server in step 4, the client signs therandom number with its own private key, as can be seen in step 5. The servercan verify the identity of the client now, which concludes in a setup of a securechannel. [32]

A.1. Security Protocols 117

A.1.6 Internet Protocol Security

Internet Protocol Security (IPsec) is a collective name for a specified securityarchitecture and different protocols.

Different security services can be distinguished. Most important are the twotraffic security protocols and the cryptographic key management proceduresand protocols. All those security protocols are designed to be crypthographicalgorithm independent, which results in a interoperable system.

The two traffic security protols are the Authentication Header (AH) and En-capsulating Security Payload (ESP). Both the AH and ESP protocol add a headerto a packet. The header can carry the security identifier, integrity control dataand other information. With the distribution of crypthographic keys by theIPsec Key Exchange (IKE) protocol and the management of traffic flows, it ispossible for the two protocols to offer access control. Both protocols and theIKE protocol are described below.[42][36][35]

AH

An Internet IPsec protocol designed to provide connectionless data integrity service anddata origin authentication service for IP datagrams, and (optionally) to provide protec-tion against replay attacks.[35]

As the IETF describes in their definition the AH provides integrity checkingand antireplay security. However, it provides no data encryption. This makesAH most useful when integrity checking is necessary but secrecy is not needed.

ESP

An Internet IPsec protocol designed to provide a mix of security services, especially dataconfidentiality service, in the Internet Protocol.[35]

In contrast to AH, the ESP protocol itself cannot protect IP header fields. Whenusing ESP, protection of IP header fields can only occur by encapsulating the IPheader fields by AH. Another difference between AH and EPS is the data confi-dentially service the EPS can provide. According to Tanenbaum [36] is the factthat ESP can do everything AH can do and more likely results in a disappear-ance of the AH protocol.


IKE2V

An Internet, IPsec, key-establishment protocol that is intended for putting in place au-thenticated keying material for use with ISAKMP and for other security associations,such as in AH and ESP.[35]

As described in the definition of the IETF IKE is used for performing mutualauthentication. IKE is also responsible for establishing and maintaining secu-rity associations (SA). SA is described in the following section.

SA

In RFC 2828 the IETF describes SA as follows [35]:

A relationship established between two or more entities to enable them to protect datathey exchange. The relationship is used to negotiate characteristics of protection mech-anisms, but does not include the mechanisms themselves.

In case of the AORTA, SA is used in context with IPsec. When SA is used inIPsec, SA is a simplex (uni-directional) connection. The protection mechanismsdescribed in RFC 2828 are responsible for the security services. The protectionmechanisms exist of the protocol selected, the IPsec mode, the endpoints andthe election of optional services within the protocol. If a secure connection inboth directions is needed, two SAs are neccessary.

A.1.7 X.509

For the format and the public storage of certification the X.509 and CertificationRevocation List (CRL) protocols are used (more about CRL in subsection A.1.8).The IETF defines in RFC 2828 X.509 as follows [35]:

X.509 defines a framework to provide and support data origin authentication and peerentity authentication services, including formats for X.509 public-key certificates, X.509attribute certificates, and X.509 CRLs.

In X.509 two levels of authentication are described. The first one is a simple au-thentication based on a password. The second level of authentication describedis a stronger authentication method based on a public-key certificate.[40]

A.2. Message Transport 119

A.1.8 Certificate Revocation List

The Certificate Revocation List (CRL) can be used to revoke a certificate. In RFC2828 the IETF describes the CRL as follows [35]:

A data structure that enumerates digital certificates that have been invalidated by theirissuer prior to when they were scheduled to expire.

A CA is responsible for publishing the CRL on a regularly base. When a clientwants to check the validity of a certificate, it needs to contact the CA to verifythe validation.[32]

A.2 Message Transport

The AORTA architecture is a Web Services architecture. Web Services is de-signed for various applications to interoperate with eachother regardless of theoperating systems, platforms, or programming languages used. To achieve thisinteroperability between the applications different standards are used for thetransport of the messages. In the AORTA those standards exists of SOAP 1.1,WSDL 1.1 and WS-I Basic Profile. [39][15]

A.2.1 SOAP

Simple Object Access Protocol (SOAP) is a lightweight protocol for exchancinginformation in a decentralized, distributed environment. The information mes-sages in SOAP are encoded with XML. SOAP consists of three parts:

• SOAP envelope; A framework which describes what is in a message andhow to process it.

• SOAP encoding rules; Defines a serialization mechanism to exchange dif-ferent datatypes.

• SOAP RPC representation; Defines a convention for remote procedurecalls (RPC) and responses.

In the AORTA architecture only the SOAP envelope is used. A SOAP envelopecan be split up in three parts:


• SOAP Envelope; The top element of the XML document representing themessage.

• SOAP Header; A generic mechanism for adding features to a SOAP messgein a decentralized manner without prior agreement between the commu-nicating parties.

• SOAP Body; Contains the actual message.

The SOAP header is not used in the AORTA architecture. The SOAP headerfunctionality will be delivered by HL7v3. [37][15]

A.2.2 WSDL

Web Services Description Language (WSDL) defines an XML grammar. ThisXML grammar can be used by applications to describe interfaces of webser-vices.

A WSDL document consists of different elements [38]:

• Types; A container for data type definitions using some type system. Inthe AORTA architectuur XML Schema Definition (XSD) is used.

• Message; The communicated data messages, build from elements and el-ementtypes from the Types container. In the AORTA the messages aredefined with XML.

• Operation; An action supported by the service.

• Port Type; An endpoint, port, which supports different operations.

• Binding; Connects a Port Type with a specific transport protocol.

• Port; Network endpoint, which connects a binding with a location.

• Service; Collection of endpoints.

A.2.3 WS-I Basic Profile

Web Services Interoperability Basic Profile is a document which describes howthe core web services specifications should be used to build interoperable webservices. Different guidelines and recommendations are described for usage ofprotocols, SOAP 1.1 and WSDL 1.1, used in the AORTA architecture.

A.2. Message Transport 121

A.2.4 HL7

Health Level 7 (HL7) is a communicationstandard for the healthcare sector. Inthe AORTA architecture the latest version is used, version 3 (HL7v3). HL7v3defines a spectrum of messages which can be used in a healthcare environment.The messages are messages for direct one to one communication between XISs.This standard is based on XML.

A HL7v3 message exists of different parts. Not all of those parts are neces-sary to create a correct HL7v3 message. The different parts are described below:

• Payload; The payload contains the actual patient information. Every mes-sage has such a payload.

• Control Act Wrapper; The control act wrapper contains information abouthow to handle a payload. It is not necessary to provide each message withthis wrapper.

• Transmission Wrapper; Contains meta data about the message. Each mes-sage contains such a wrapper to assure a good transportation of the mes-sage.

• Batch Wrapper; Can be used to wrap different messages in an XML docu-ment. This is an optional feature.

A.2.5 LDAP

Lightweight Directory Access Protocol (LDAP) is a directory service protocolbased on the OSI X.500 protocol. The IETF describes in RFC 2828 the LDAP asfollows:

LDAP is a client-server protocol that supports basic use of the X.500 Directory (orother directory servers) without incurring the resource requirements of the full Direc-tory Access Protocol (DAP).

In contrast to the original protocol, X.500, LDAP is carried directly over TCP.This results in less overhead. According to RFC 2251, LDAP is designed todeliver services to applications, specifically management and browser applica-tions, which provide read/write interactive access to directories. The LDAPprotocol makes use of authentication. Other security services can be providedby SASL mechanisms or by SSL/TLS. [36][41]

Date post:	15-Mar-2020
Category:	Documents
Upload:	others
View:	5 times
Download:	0 times

Electronic Health Record Graduation Thesisaiellom/tesi/hoenderboom.pdf · a patient should be able...

Documents