Data-flow control using Jif in a health care system

Transcription

1 Data-flow control using Jif in a health care system Emilie Nodet Kongens Lyngby 2008 IMM-M.Sc

2

3 Summary Electronic health care systems are highly security-sensitive systems. Because they deal with private health information they have strong confidentiality and integrity requirements. In this thesis we study the French health care system and more specially a project of electronic national personal health record called DMP (stands for Dossier Médical Personnel ) and its confidentiality requirements. The decentralized label model and its application, the security-typed language Jif, allow controlling information flows according to confidentiality and integrity policies set by different entities. Two DMP systems are implemented in Jif in order to see if it is possible to ensure confidentiality in electronic health care systems thanks to this language. We then present an evaluation of the Jif usability to develop health care systems or other security-sensitive large systems and, thanks to the knowledge gained by our implementation experience, we give some advice to future Jif developers.

4 ii

5 Preface This thesis was prepared at the Department of Informatics and Mathematical Modeling of the Technical University of Denmark in partial fulfillment of the requirements for acquiring the Master of Science degree in engineering. The master thesis deals with ensuring security in a health care system thanks to Jif which is a programming language that permits to control data flows within a program. The main focus is on the confidentiality requirements of the French national system for electronic personal medical records. Lyngby, July 2008 Emilie Nodet

6 iv

7 Acknowledgments I thank my master thesis supervisor, Flemming Nielson, for his support and useful advice he gave me for my master thesis project. His help allowed me to keep my work focused on a precise subject and it encouraged me to persevere when I encountered many problems while programming. I would also like to thank Laura, Dafni, Marie, Laurent and Marton who took some time to read my report and correct my English mistakes and my brother, Rémi, for his support in Java programming.

8 vi

9 Contents Summary i Preface iii Acknowledgments v 1 Introduction Security of electronic health care systems The decentralized label model The Jif language A small Personal Medical Record example The French health care system and the Personal Medical Record project The French health care system Official requirements of the DMP

10 viii CONTENTS 2.3 Simplified requirements of the DMP system Implementation of the simplified DMP project DMP 1: Pure Jif code DMP 2: Integrating Java code in a Jif program Evaluation of the implemented DMP systems Programming in Jif Programming experience with Jif Jif development and related work Jif evaluation and software engineering advice Conclusion 87 A Jif code of the small Personal Medical Record example 89 A.1 EHR system.jif A.2 Doctor.jif A.3 Patient.jif A.4 DMP.jif A.5 Jif principals B File doctors.db 97 C Labels of attributes and methods of the classes of the DMP 1 system 99 D Labels of attributes and methods of the classes of the DMP 2

11 CONTENTS ix system 105

12 x CONTENTS

13 Chapter 1 Introduction Many countries are now developing national electronic health care systems. Because confidentiality and integrity are very important when it comes to information about citizens health, new ways to ensure security of such systems, and even better to prove it, would be welcomed. Jif is a security language that ensures that confidentiality and integrity policies independently defined by several entities are observed within a program written with it. In this thesis, we explain why confidentiality is a key point of electronic health care systems. Then, after introducing Jif and the decentralized label model on which it is based, we study the usability of Jif to develop an electronic health care system. The health care system studied in this thesis is the French one and a subset of it is implemented in Jif. Later, we discuss the advantages and drawbacks of Jif and give our feedback on programming with this language. To conclude, we also try to give some useful advice for people willing to use Jif to develop such systems. The aim of this thesis is to study a health care system and to see if developing it in Jif is an appropriate solution to ensure its confidentiality and integrity requirements. We particularly focus on confidentiality.

14 2 Introduction 1.1 Security of electronic health care systems Information technologies are more and more present in the health care domain and many countries are now developing electronic health care systems. In the UK the project Connecting for Health is meant to completely replace the current British health care system. Beside it, still in the UK, some other smaller but still ambitious e-health projects exist such as the Imperial College Healthcare NHS Trust one which brings together five hospitals and integrates them with Imperial College London [10]. Similarly as in the UK, the German national health IT project is about to connect hospitals, doctors, pharmacies and public health insurance companies thanks to a smartcard infrastructure [11]. We can also quote Portugal, France, Austria and Italy as European countries currently developing e-health systems [13]. In this thesis, we focus on the French health care system and more precisely on the DMP project of a national system for personal medical records [12]. Health care systems deal with different kinds of data that have different confidentiality levels. To illustrate that, let us describe what is a typical visit of a patient to his/her doctor in France, and more particularly the data which are exchanged. During a consultation, the doctor may read the personal medical record of the patient and add some information to it. Before leaving, in most of the cases, the patient must pay the doctor who, thanks to the public health insurance card of the patient, transfers data concerning the type and the cost of consultation to the public insurance provider (in France, the Sécurité Sociale ). Later, the patient gets some money back from the public insurance provider and then, most of the time, transfers the data about what he/she paid and got back to his/her private health-insurance. We can notice that during this process several types of data are exchanged between different parties. Indeed, data contained in the medical record of the patient are under the patient-physician privilege: they can be read only by the doctor and the patient. Whereas the data about the type and the price of the consultation can be known by the doctor, the patient and the public insurance provider. We can notice that the information contained in the type of consultation, which is necessary to take the decision of paying the patient back, is problematic. Indeed, what information can or cannot be given to the public insurance provider without going against the patient-physician privilege? And the private insurance provider receives even less information about the consultation than the public insurance provider does. To conclude, information about the amount of money given back by the insurance providers cannot be known by the doctor. Thanks to this example, we can see that health care systems deal with several types of data whose confidentialities are very different. Moreover, confidentiality is very important for medical data. Indeed the patientphysician privilege is really important in case of serious pathology such as AIDS, for example. Doctors of insurance companies or of the company hiring the pa-

15 1.1 Security of electronic health care systems 3 tient should not be able to access the personal health record of the patient. Thus the privacy of the patient has to be protected in order to prevent discrimination, among others. The government must ensure the strict confidentiality of medical data of all its citizens. Those data were traditionally kept secret by physicians but now that electronic versions of those data might become accessible by several doctors, new confidentiality problems arise. Indeed the more data are shared between entities, the more likely confidentiality leak will happen, especially if those data are exchanged through a hostile environment such as the Internet. In addition, as that data might spread much more easily, another problem has to be taken care of: citizens may feel that they cannot control the spread of their medical data anymore, which was not the case when each doctor kept in a closed environment data collected by himself/herself. It is the job of the government to ensure the privacy of its citizens and to convince them that it is the case. In France the CNIL (stands for Commission Nationale de l Informatique et des Libertés ) is the separate administrative authority which controls the respect of the citizens privacy in computer systems. Each database gathering data about citizens is checked by the CNIL. It verifies for which purpose those data are collected, that only useful data (relatively to that purpose) are collected, that citizens are aware of it and gave their consent and that those data are not used for something else that the declared purpose. It also ensures that citizens can access data gathered about them as well as change or delete them if they want to. It is important to keep in mind that, in France, citizens are the ones who own the data collected about them, and not the company which gathered them. Thus, two types of law have to be considered in the case of electronic health care systems: laws that concern medical data in general and laws that concern gathering of electronic data. The two make clear that the patient have the right to see which data are collected about him/her. Moreover, medical data have to stay purely confidential. An unauthorized person must not be able to access medical data and their owner should be able, depending on the case, to rectify, change, update, complete and erase those data. It is important to remember those facts when it comes to understand the security requirements of the French health care system. [25] This thesis focuses on one security aspect of electronic health care systems: confidentiality. Indeed, even if integrity is briefly discussed in this report, we prefer to detail the confidentiality aspect of such systems than to spread our time over too many security aspects and thus not being able to study them thoroughly.

16 4 Introduction 1.2 The decentralized label model Now that we have seen why we need to develop secure systems, we will see how this can be done. Access control is widely used to ensure confidentiality of information in ITsystems. Nevertheless access control does not ensure end-to-end security, that is to say it does not permit controlling to whom data can been transfered once it has been accessed. A solution to perform end-to-end confidentiality is to control information flows: confidentiality policies can be bound to all data used by a program and then this program can be checked as respecting those confidentiality policies. One way to do this is to ensure security at the level of the programming language. Thus, if written in a language controlling information flows, a program can be easily checked as respecting defined security properties. [28] The decentralized model for information control defined by Myers and Liskov [24] is based on this idea. It permits describing confidentiality and integrity policies and then to control information flows in systems with mutual distrust and decentralized authority. Myers and Liskov s model allows users to control the flow of their information without imposing the rigid constraints of a traditional multilevel security system [24]. All entities, called principals, which correspond to users, processes or user groups, can define their own confidentiality and integrity policy for data that they own or share with other entities. Within a program such policies are expressed thanks to labels which are associated to the piece of data they correspond to. Information flows occurring within a program are considered as secure if they do not go against those defined policies, unless explicitly expressed cases and under the authority of the principal owning the broken policy. Then Myers and Liskov explain how static analysis can be used to check that a labeled program allows only secure information flows to happen. [24] In this section we describe Myers and Liskov s decentralized model, first by explaining how confidentiality and integrity policies are expressed and then by presenting which information flows are secure Security policies and labels Confidentiality and integrity policies defined by principals are expressed thanks to labels. Within a program, each value is bound to a security label which expresses the confidentiality and integrity policies that concern this value. Act-for relationship: A principal can delegate its authority to other prin-

17 1.2 The decentralized label model 5 cipals: if Alice gives her authority to Bob, we say that Bob acts for Alice and write Bob Alice. The act-for relation is reflexive (Alice acts for Alice) and transitive (if Alice acts for Bob and Bob acts for Charlie, then Alice acts for Charlie). The relation can be used to create user groups or roles and is thus really useful. The principal who can act for everyone (or top principal) is written, whereas the principal for who everyone can act for (or bottom principal) is written. [4] In this section we suppose that act-for relations are fixed and do not change through the execution of a program. Confidentiality: A reader policy is written o r 1,..., r n where the principal o is the owner of the policy and the principals r 1,..., r n are explicitly specified readers. This policy means that o allows a principal q to read information only if q can act for o or for any of the readers r 1,..., r n. The notation readers(c) represents the principals allowed to read information according to the reader policy c and owners the owners(c) of the policy: [4] owners(o r 1,..., r n ) = {q q o} readers(o r 1,..., r n ) = {q q o i 1...n, q r i } Confidentiality policies can be single reader policies as well as joins of several reader policies. Thus several principals can express different reader policies for the same piece of data. Let c and d be confidentiality policies. A principal p can read information according to a confidentiality policy c if and only if p readers(c). The join operation means that the confidentiality policy c d enforces both confidentiality policies c and d. Thus the readers corresponding to the policy c d are readers allowed both by c and d (intersection of readers sets): [4] Join operator for confidentiality policies: owners(c d) = owners(c) owners(c) readers(c d) = readers(c) readers(c) When a value derives from others, the security policy of the new value is the join of the security policies of other values from which it derives: only principals that are allowed to read all used values can read the derived one. We can notice that joining is a restriction and thus does not leak information. A confidentiality policy c is considered as no more restrictive than another one d if c C d that is to say: [4]

18 6 Introduction Definition of c C d (ordering of confidentiality policies): owners(c) owners(d) readers(c) readers(d) Let us study an example of a confidentiality policy which is the join of two single reader policies and where the three principals Alice, Bob and Charlie involved do not have any act-for relationship between them. Alice Bob, Charlie Bob Charlie is the join of two reader policies owned by Alice (Alice Bob, Charlie) and Bob (Bob Charlie). According to the join rule, we have the following equations: readers(alice Bob, Charlie Bob Charlie) = readers(alice Bob, Charlie) readers(bob Charlie) = {q q Alice q Bob q Charlie} {q q Bob q Charlie} = {q q Bob q Charlie} and owners(alice Bob, Charlie Bob Charlie) = owners(alice Bob, Charlie) owners(bob Charlie) = {q q Alice} {q q Bob} = {q q Alice q Bob} The principals allowed by the policy to read information are thus the principals which can act for Bob or Charlie. The most restrictive confidentiality policy is, for which the set of readers contains only the principal which can act for all principals. The least restrictive policy is, for which the set of readers contains the principal for which every principal can act for. [24] Integrity: A writer policy is written o w 1,..., w n where the principal o is the owner of the policy and the principals w 1,..., w n are explicitly specified writers. This policy means that the principal o considers that only principals acting for him or for any of the principal w 1,..., w n could have influenced information. Integrity policies are the dual of confidentiality policies. Integrity policies can be single writer policies as well as joins of several writer policies (the join operation corresponds to an union of writers set)., where every principal could have influenced the piece of information, is usually considered as the most restrictive integrity policy. Indeed the piece of data is then completely untrustworthy and its use is thus very restricted. The least restrictive integrity policy is, because only the top principal could have influenced the piece of data which is then trustworthy and can be widely used. [4] As this project focuses on confidentiality and not on integrity, we do not present with more details how integrity policies are dealt with by the decentralized label model. Nevertheless we can notice that the program language we use in this

19 1.2 The decentralized label model 7 project, Jif, can implement integrity policies in addition to confidentiality ones. Labels: Labels permit binding confidentiality and integrity policies to data. If the confidentiality (resp. integrity) policy of a label is not specified, it is by default equivalent to the (resp. ) policy. If c is a confidentiality policy and d an integrity one, then {c; d} is the label containing them Information flows Now that we have seen how labels can be bound to values in order to express confidentiality and integrity policies defined by different principals, we present how those labels can be used to ensure security. First we explain what are information flows and then which ones are considered as secure. Explicit and implicit information flows: Information flows describe what can be learned by observing values or processes, which can have different confidentiality and integrity levels. Information flows can be explicit or implicit. In a program, the label binded to a value corresponds to an explicit flow whereas an implicit flow depends on the path taken (or not) during an execution of the program. In order to explain, let us consider the case of two variables x and b, where the label L x is associated to x and L b to b. In Figure 1.1, two flows have to be taken into account at the third line of code. The explicit flow corresponds to the label L x whereas the implicit one corresponds to the label L b. Indeed reaching this line of code during the execution of the program depends on the value of b and thus knowledge about b s value can be gained just by observing the value of x at the end of the execution of the program. To provide end-to-end confidentiality or integrity, both explicit and implicit information flows must be taken into account. Indeed both of them can leak information. Trace-based run-time analysis, unlike static analysis, cannot deal with implicit information flows because this kind of analysis can only deal with what happens during one execution of a program, which corresponds to only one possible path. Information flow created by the fact that one path is executed and not another one cannot be computed at run-time. Myers and Liskov show that static analysis can be used to determine the confidentiality and integrity levels associated to information flows in the decentralized model. [24] Non-Interference rule: The rule of non-interference is that information with high confidentiality level should not interfere with information with low confidentiality level. To respect this non-interference rule only information flows which are more and more restrictive regarding confidentiality are considered as secure. Thus information can be learned only by principals allowed to do

20 8 Introduction x := 0 if b then x:= 1 end Figure 1.1: Implicit information flow [24] so: the attacker cannot observe any difference between two executions [of a program] that differ only in their confidential input [28]. Within a program, re-labeling information from L 1 to L 2 should be possible only if it is a restriction that is to say if L 1 L 2 (L 1 not more restrictive than L 2 ). Nevertheless, the non-interference rule is too strict. Indeed in real systems secret information is sometimes released on purpose. A good example is the authentication processes one. Let us consider a program where authentication is done thanks to a password. A user wants to log on as Alice. Alice s password is stored under the label {Alice } which means that only Alice and the principals which can act for her can read the piece of data. When the user enters his/her guessed password, as anyone could have entered this value, it is labeled { }, i.e. all principals can read it. The result of the comparison between the two values is a boolean labeled {Alice }. Indeed, it depends on the value of the real password and then having access to it gives information about the password. But this result has to become public so the user can see if he/she can or cannot log on as Alice. Through this example we can see that, in some cases, real systems need to be able to go against the non-interference rule. That is why Myers and Liskov introduce the notion of declassification in the decentralized label model [24]. Downgrading of information: The explicit action of going, on purpose, against the non-interference rule is called downgrading of information. It is possible to downgrade confidentiality and integrity. A declassification is an explicit change of confidentiality policy which goes against the non-interference rule. In the example described in the previous paragraph, the result of the password-checking has to be declassified from the label {Alice } to the label { }. This change of policy goes against the non-interference rule because {Alice } is more restrictive than { }. The process doing this declassification has to act with the authority of Alice to be allowed to do so. Similarly, an unsafe change of integrity policy is possible. It is called an endorsement. [24] By the way confidentiality and integrity policies are defined and dealt with and by allowing downgrading of information only within the authority of the owner of the concerned policy, every principal can be ensured that information

21 1.3 The Jif language 9 Figure 1.2: The Jif compiler framework [23] flows respect their own confidentiality and integrity policies. That is why the decentralized label model fits decentralized systems with mutual distrust between principals. 1.3 The Jif language Jif, which stands for Java + Information Flow, is a security-typed extension of Java. Thanks to it, it is possible to write programs which contain only secure information flows. In fact the programming language Jif is the direct application of the decentralized label model for the Java programming language. Its ancestor, JFlow was developed by Myers during his PhD [23]. Jif is now developed within the Cornell university. Thanks to labels associated to values but also to methods, the Jif compiler performs a static analysis which ensures that a program is secure, regarding defined confidentiality and integrity policies. We can notice that some few checks, notably concerning dynamic labels, are done dynamically [24]. As we can see in Figure 1.2, the output of the Jif compiler is a Java source code which is secure regarding the analysis done by the Jif compiler. If the Jif code is not secure, it cannot be compiled. Otherwise, the generated Java source code is then compiled by a normal Java compiler. In this section we quickly present the main Jif features of the Jif version [6]. We suppose that the reader has some basic skills in Java or in another objectoriented programming language.

22 10 Introduction String{Alice:Bob} secret; Figure 1.3: Example of declaration in Jif DLM symbol Jif syntax Top principal * or Bottom principal or Disjunctive principal p,q p,q Reader policy o r o:r or o->r Writer policy o r o!:r or o<-r Policies join p 1 p 2 p 1 ;p 2 Labels {c; d} {c;d} Table 1.1: Label syntax in Jif [6] Labels Jif labels correspond to the DLM ones. We can notice that whereas confidentiality was implemented from the beginning, integrity has been added to Jif only from the version. In this section, integrity features are presented very quickly because they are almost not used in this project. Labeled types: In Jif each value has an associated label in addition to its type, as we can see in Figure 1.3. The label {Alice Bob, Charlie Bob Charlie; Alice Bob Bob Charlie} is written {Alice:Bob,Charlie ; Bob:Charlie ; Alice!:Bob ; Bob!:Charlie} in Jif. We can notice that if only the confidentiality (resp. integrity) policy is explicitly written in a label, the integrity (resp. confidentiality) policy is by default (resp. ). The top principal is written in Jif, whereas the bottom principal is written. The label {} is thus equivalent to { : ;!: } and means that every principal can read information and could have influenced it. For more details, please refer directly to tables 1.1 and 1.2. We can notice that labels do not have to be written for all expressions and can be inferred automatically by the Jif compiler. The label of a value can not be changed during the execution of a program but a new copy of a value can be labeled differently than the original value. Method s header: A lot of method calls are done in Java programs and thus in Jif ones as well. Therefore it is important to see how information flows are handled when a method is called. Figure 1.4 shows that the explicit and implicit flows going in and out a method can be described by five types of label. Two of

23 1.3 The Jif language 11 Jif shortcut Meaning {o:} {o ; } {o!:} { ; o } {} { ; } Table 1.2: Jif abbreviations [6] public String{L return } methodexample {L begin }(String{L arg } a):{l end } throws Exception{L ex } { body of the method } Figure 1.4: Example of method s header in Jif them correspond to obvious explicit flows: L arg is the upper-limit of what can be the label of an argument of the method (the value given in argument must have a label not more restrictive than L arg ) and L return is the upper-limit of the label of the value returned by the method (the value returned by the method must have a label not more restrictive than L return ). The begin and end labels correspond to implicit flows. The begin label L begin represents the highest implicit flow that the caller of the method can have when the method is called. Therefore it represents the implicit flow at the beginning of the method. Similarly the end label L end represents the implicit flow at the end of the method which goes to the caller of the method. The label L ex corresponds to the label of an exception thrown by the method. Exceptions give information about the execution of a program and thus have to be correctly labeled and handled. For more details about how exceptions can be handled, please refer to Chapter 4. The labels L arg ), L return, L end and L ex have to be written within a method s header as shown in Figure 1.4.[6] Downgrading of information and principals management After having presented how labels are associated to values and methods in Jif, we now describe how information can be downgraded. Declassification and endorsement: According to the decentralized model, Jif allows principals to downgrade their security policies. Figure 1.5 presents how information flows can be declassified from the label L to the label L. Endorsement can be done similarly thanks to the endorse keyword. Downgrading of information requires the authority of the principal owning the concerned policy.

24 12 Introduction For an explicit flow: exp = declassify(exp,{l} to {L }); For an implicit flow: declassify({l} to {L }) { block of code in which the implicit flow is initialized to {L } } Figure 1.5: Declassification in Jif Within the header of a class: public class Example[Principal P] authority (P) { body of the class } Within the header of a method: public void function() where authority (P) { body of the method } Within the header of a method: public void function() where caller (P) { body of the method } Figure 1.6: Authority in Jif Authority: In Jif, the authority of a principal P has to be explicitly given to classes and methods so they can use it. Figure 1.6 shows how the authority of the principal P can be given to a class and to methods within a class having this authority. The expression where caller(p) can be used within the header of a method to specify that the caller of the method must have the authority of P to call this method. In this case, it is not necessary that the class corresponding to the method has P s authority. In order to create an object having P s authority a method must have this authority itself. Polymorphism: Polymorphism means that the type of commands or expressions may be generic, i.e., may depend on the context [28]. In Jif, polymorphism allows the implementation a class which takes, for example, a principal as a parameter. The parameter of the class is in fact a variable of type principal. The parameter has to be instantiated when constructing an object of this class, i.e. a real principal is given as parameter to the class in order to construct an object. Polymorphism is very practical in Jif. Thanks to it, classes do not have to be re-written for each principal or label they can deal with but can be adjusted to whatever confidentiality or integrity policies. Figure 1.7 shows the header of a class which takes a principal and a label as parameters. Principals: The main method of a program (i.e. the method which is exepublic class ClassExample[Principal P, Label L] authority(p) { body of the class } Figure 1.7: Example of class header to illustrate polymorphism in Jif

25 1.3 The Jif language 13 Figure 1.8: Example of Jif code for password checking cuted first when the program is launched) can take Jif principals as parameters. In this case principals are written as Jif classes. The main method also permits taking the current user of the operating system as a principal. Finally, it is possible to create principals within a Jif program. The act-for relationship between principals exists in Jif. In order to test if a principal acts for another one or to be able to use the authority of a principal by having the authority of a principal which can act for it, the expression if (P actsfor P ) can be used, where P and P are principals Training example of a Jif class Figure 1.8 presents a basic example of a Jif class which permits checking a password. This example corresponds to the one introducing the need of declassification in Section It is provided here in order to give an insight of what Jif code looks like. The class Example takes a principal Alice as parameter and has the authority of this principal thanks to the expression authority(alice) within the class header. The class contains a constructor and a method checkp assword. The implicit flow at the beginning and at the end of the constructor are {}. Indeed the header of the constructor is public example {}():{} where the first pair of brackets corresponds to the implicit flow at the beginning of the method and the second pair to the implicit flow at the end of the method. The beginning label precises that this method can be called only if the implicit flow of the caller is not more restrictive than {} (i.e. is {}) whereas the end label means that the execution of the method does reveal information about confi-

26 14 Introduction dential data. Two strings are defined within the body of this method. The first one, guess, is labeled {} which means that everyone can read it whereas the second one, pwd, is labeled {Alice:}, which is equivalent to {Alice:*} and means that only principals which can act for Alice can read it. The boolean b can be read by everyone because it is labeled {}. The checkpassword method s implicit flows at the beginning and at the end of the method are both {}, as the constructor s ones. The method checkpassword takes two strings in argument. One is labeled {} whereas the other is labeled {Alice:} which means that the arguments can be instantiated with strings with labels not more restrictive than {}, for the first argument, and {Alice:}, for the second one. In our case, the method s arguments are instantiated with strings which are labeled {} and {Alice:} when the method is called. The method uses the authority of Alice. It can do so only because the class has this authority. The use of the authority within the method is specified by the where authority(alice) expression within the method s header. The method returns a boolean whose label cannot be more restrictive than {}. In the body of the method, we can see that the boolean answer is labeled {Alice:}. Indeed its label has to be at least as restrictive as {} {Alice :} = {Alice :} because it depends on the two strings guess and pwd which are labeled {} and {Alice:}. This boolean is declassified so a boolean equal to it but labeled {} can be returned by the method. The declassification is done thanks to the declassify(answer,{alice:} to {}) expression, which means that answer is labeled {Alice:} but that the created copy of this boolean is labeled {}. To perform the declassification the authority of Alice is needed. That is why the expression where authority(alice) is necessary within the method s header. The aim of this thesis is to see how Jif can be used to implement a health care system. Indeed patients, doctors and insurance providers can be seen as different principals that have different confidentiality and integrity requirements. Allowing those different principals to have separate security policies and then combining them thanks to the decentralized model seems a natural way to design a health care system. In the following section, a small and simple health care system is implemented in Jif in order to show how Jif can be used to ensure confidentiality within a program. 1.4 A small Personal Medical Record example This section presents a small health care system implemented in Jif. This system example is presented in order to give an overview of Jif before dealing with

27 1.4 A small Personal Medical Record example 15 bigger systems. Moreover, during the development phase of this project, it also allowed me to progressively learn how to code in Jif. The systems presented in Chapter 3 can be seen as extensions of this small one. The health care system discussed in this section is a small Personal Medical Record system. The idea corresponding to it is the following one: a medical record is associated to a patient, who can read it. When the patient goes to the doctor, the doctor writes in the medical record. The doctor can also read the medical record of the patient. Security requirements are defined in Section Then an overview of the implementation is given in To conclude Section shows how confidentiality is ensured in this system. The system is not persistent and thus changes made on a health record are not available during other executions of the program Security policy In this small implementation of a Personal Medical Record system, there is only one patient and one doctor. The patient has a health record which belongs to him/her but which can also be read and modified by the doctor. Confidentiality: The health record and the information contained in it is owned by the patient who determines whether the doctor may read them or not. Integrity: Integrity is not ensured by the system implemented in this example. Thus everyone could have written in the health record. We can also imagine a system where the doctor is the only one who could have written in the record of the patient Implementation overview The electronic health care system presented here is implemented in Jif. It includes four classes named Doctor, P atient, EHR system and DMP. EHR system: EHR system stands for electronic health record system. This class contains the method main. After creating a patient and a doctor, it simulates the visit of the patient to the doctor i.e. the doctor writes in the patient s health record. Then the patient and the doctor read this record. Doctor: This class represents a doctor. A doctor has a name and is

28 16 Introduction associated to one patient only. The doctor can receive the visit of his/her patient thanks to the method take patient. When this method is called, the doctor asks the patient the access of his health record and then writes in it. He does not read the record at this point. The doctor can read the patient record with the method read DMP. Patient: This class represents a patient. The corresponding attributes are a private number (HCS num, for health care system number) and a private health record called DMP. A patient is associated to one doctor only. A patient can read his/her own record. This is implemented with the method read DMP where the information read by the patient is printed on the console. A patient can also give access to his/her own record through the give access method. In our case it always gives access to who asks for it, that is to say transmits the record whoever made the request. DMP: A DMP object (DMP stands for Dossier Médical Personnel, French for personal health record) has two attributes that correspond to the date and the subject of a consultation. This DMP class has a method write which permits setting the date and the subject of the DMP and a method read which returns the two. The Jif code of this implementation of a Personal Medical Record system is in Appendix A Security implementation in Jif Principals This Jif implementation example deals with only two principals, P atient1 and Doctor1. Those principals are defined in Jif by two different classes (cf. Appendix A.5). The class EHR system runs with the authority of the two principals, P atient1 and Doctor1, which are respectively the patient and the doctor of the system. The method main written in this class uses their authorities to construct an object of type P atient which has the authority of P atient1 and an object of type Doctor which has the authority of Doctor1. The method also uses the authority of P atient1 to carry out a declassification (cf. Section ). The classes Doctor and P atient are given the two principals as parameters. Moreover the class Doctor has the authority of Doctor1 whereas the class P atient has the authority of P atient1. The class P atient uses this authority to perform a declassification of data (cf. Section ).

29 1.4 A small Personal Medical Record example 17 class attribute label DMP date {P:D} subject {P:D} Patient hcs num {P:} DMP {P:D} Doctor name {} Table 1.3: Labels of the class fields In the following section, we use the formal parameters P and D (for patient and doctor respectively) in order to keep a general meaning. Those formal parameters are used in the Jif implementation of classes P atient, Doctor and DMP. In the scenario depicted in this small electronic health care system, they correspond to the principals P atient1 and Doctor1. We can notice that the class DMP is given the parameters P and D but has no authority Labels and informal security proof Jif labels are associated to every class attributes, according to Table 1.3. The labels associated to the different methods are shown in Table 1.4. Those labels will help us to show that this implementation of a small health care system ensures the confidentiality requirements defined in Section Let us remember that the begin-label of a method corresponds to the upper bound of the program counter label (implicit flow) when the method is called. The arguments labels are also upper bounds. The end-label of a method is an upper bound on information that may be learned from the observation of the normal termination of the method. Thus it is the program counter (label of the implicit flow) at the end of the method. Exceptions labels are upper bounds on what can be learned from the abnormal termination of the method. For more information, please consult Section or the Jif reference manual [6]. A DMP is created at the same time that the patient that owns it (i.e. in the constructor of the class Patient). The label {P:D} is then associated to it which means that the patient P binds a confidentiality policy to the DMP object. This policy is that only the doctor D can read the DMP, together with the patient P (and principals acting for them). The attributes of a DMP are labeled {P:D} too. It is important to keep in mind that only confidentiality is ensured. The doctor does not need to be in the readers list of the DMP to be able to write in it. Indeed everyone is allowed to write on the patient s DMP. The DMP label {P:D} prevents principals from reading it, not writing in it. The interesting methods regarding confidentiality are the methods where the

30 18 Introduction class method begin end arguments returned raised label label labels value exceptions date {P:D} write {P:D} {} DMP subject {P:D} none none read {*:} {} none string {P:D} none constructor hcs num {P:} {} {P:} none none Patient read DMP {} {} stream {} none {} give access {*:} {} none DMP {P:D} none constructor {*:} {} name {} none none patient {P:D} Doctor take patient {P:D} {} date {P:D} none none subject {P:D} read DMP {P:D} {} patient {P:D} string {P:D} none name {*:} {} none name {} none EHR system main {} {} {} none {} Table 1.4: Labels of the methods fields of a DMP are read, that is to say appear on the right hand side of a declaration. The only places where this happens are in the methods read DMP of the classes P atient and Doctor. We can notice that when the method read DMP of the class P atient is called, the patient P declassifies the information so it is readable on the console. In the method read DMP of the class Doctor, the doctor cannot do so and thus transmits the information to the method main that is able to declassify the piece of data. Those declassifications are done just in order to verify that the program works correctly. If those two unnecessary declassifications are removed from the program, data contained in a DMP are never declassified and thus only the patient and the doctor can read them. We can add that a doctor cannot make them readable by someone else than the patient without the patient s approval. Indeed, only principals which can act for the patient can declassify those data. Thus confidentiality as it is defined in Section is ensured by the system. This example of a small health care system showed us how Jif can be used to provide confidentiality of data. In the next chapter we describe a real system and its security requirements in order to implement it later in Jif.

31 Chapter 2 The French health care system and the Personal Medical Record project In the previous chapter we introduced the security problems raised by electronic health care systems in general and we showed that the programming language Jif based on the decentralized label model could be useful to provide security in such systems. We will now study the information flows of a real health care system. For practical reasons (I speak French and thus was able to read all the necessary documents) we will study the French health care system, and more specially the French project of a Personal Medical Record system and its security requirements. A quite important subset of this system will then be implemented in Jif in Chapter 3, in order to check that it is possible to implement such a big real world system in Jif.

32 20 The French health care system and the Personal Medical Record project 2.1 The French health care system Overview of the health care system The example presenting the different confidentiality requirements corresponding to data exchanged during the visit of a patient to his/her doctor (cf. Section 1.1) illustrates the information flows of a health care system. We will now detail those flows in the case of the French health care system. Nowadays each doctor has only access to the medical records he/she collected himself/herself. Indeed medical records are not shared between doctors, except in hospitals or clinics. Nevertheless this is going to change in a few years. Every patient will have a single electronic record that doctors will share. This project of a national system for medical records is studied in details in the rest of this chapter. When such a system will be widespread in France the information flows due to the visit of a patient to his/her doctor will be the following ones: 1. The doctor reads the medical record of his/her patient. 2. The doctor writes in the medical record of the patient. 3. The patient gives his/her VITALE card, which is provided by the public insurance provider (the Sécurité Sociale ), to the doctor. Based on information contained in the card, the doctor tells the patient if this one should pay him/her on the spot or not. Most of the time the patient has to pay the doctor right away but it can happen that the public insurance provider does it for the patient if this one has a very low income. 4. Thanks to the VITALE card and once the patient has paid the doctor if necessary, the doctor sends information about the price of the visit to the public insurance provider. He also gives some little information about the type of the visit, so the insurance provider can properly decide which amount of money will be given back to the patient (in the case of the patient paying the doctor himself/herself). All those data can be known by the doctor, the public health insurance provider and the patient. 5. Then, if the patient paid the doctor himself/herself, the public insurance provider gives some money back to the patient. If the patient has a private insurance provider, the public insurance provider (or the patient) sends to the private insurance provider information about the type and the price of the visit, how much has been paid by the patient and how much has been paid by the public insurance provider. Those data are used by the private insurance provider to determine its refund rate (to the patient).

33 2.1 The French health care system 21 Information Data exchanged Allowed readers Writer flow 1 general data P,D D 2 general medical data P,D D 3 information about refund P,D,PUBLICP PUBLICP 4 information about visit: cost, type P,D,PUBLICP D 5 refund amount and type of visit P,PUBLICP,PRIVATEP PUBLICP 6 refund amount P,PRIVATEP PRIVATEP Table 2.1: Security requirements of the French health care system 6. If the patient has one, the private health insurance provider pays the patient back (more or less). The amount is known only by the private insurance provider and the patient. In case of specialist doctors, the information flow can be a bit different, as when a patient buy some medicine. We do not describe those cases in order to keep our description clear and simple. As we can see, information flows which take place correspond to different confidentiality and integrity requirements. In Table 2.1, which presents those security requirements, P stands for patient, D for doctor, PUBLICP for public insurance provider and PRIVATEP for private insurance provider. The rest of this document focuses on the personal medical record system and on data exchanged through it The project of a Personal Medical Record system Five years ago, the French government started a project of a national system for medical records. The idea is that every person who has the right to get the public health insurance would have his/her own personal medical record called DMP (for Dossier Médical Personnel, French for Personal Health Record). This DMP would be accessible from anywhere (with an Internet connection), what would make it very practical for the patient. The point is to share the record between doctors, which would allow them to have a better knowledge of the patient s health. Thus it would provide continuity of treatments done by different doctors and avoid the prescription of incompatible medicines by different doctors. It can also avoid the redundancy of acts and thus permit reducing the cost of the public health care provider. Moreover, again in order to save money, the patient refund rate decided by the public insurance provider

34 22 The French health care system and the Personal Medical Record project for medical acts will most probably depend on the fact that the doctor was able or not to access the patient s DMP. The two scenarios presented just below are examples of use of the DMP system. Scenario A: Alex is on holidays in southern France. At the end of a walk, he hurts himself at a tree branch crossing the path. He is not badly injured but, as the branch kicked his head, he is bleeding quite a lot. Thus he decides to go to the doctor of the nearest village in order to check that he does not need to get any stitches. The doctor examines Alex and sees that the wound is small. Nevertheless, by checking Alex s Personal Medical Record through the Internet, he notices that Alex s anti-tetanus vaccine is not up-to-date. Due to the infection risk, he vaccinates Alex and tells him that he will have to do two other booster doses soon and another one in one year. The doctor describes her intervention in Alex s Personal Medical Record. When Alex goes back home a week later, he goes to his usual doctor to get his anti-tetanus booster doses. His doctor can read the information written by the other doctor in Alex s Personal Medical Record and then he can give Alex the booster doses at the appropriate dates. Scenario B: Mathilde bikes everyday to go to work. One rainy morning, the road is very slippery and she fells down. An ambulance takes Mathilde to the hospital. She is badly injured and unconscious. At the emergency room, a doctor reads through her Personal Medical Record thanks to an emergency procedure and quickly checks that she has no known allergies to any medicine or that there is no special recommendation in case of emergency treatment. There is nothing special. Mathilde receives the appropriate treatment and is well taken care of. Then the doctor of the emergency room describes her injuries and what has been done about them in Mathilde s Personal Medical Record. The radiology pictures are also put in her record. Thus Mathilde s usual doctor can access them after she left the hospital and follows her remission. The two scenario described just above are examples of situation where a DMP can be very useful. Our system should implement them. 2.2 Official requirements of the DMP In this section we present the requirements defined by the French government for the DMP project, at the time of writing this thesis. After introducing which information can be stored in a DMP, we analyze its security requirements.

35 2.2 Official requirements of the DMP General requirements A DMP is associated to each patient. The official organization of the DMP has not been totally decided yet but it will certainly be divided in six parts: [25] 1. general data: surname, first-name, date of birth, identifier, means of contact (in our case the address), primary care physician 2. general medical data: medical certificates, consultations history, allergies, vaccinations, prostheses, data about treatment: reports about diagnostic or hospital visit, prescribed treatments, data about prevention: individual risk factors, reports about preventive acts, vaccination schedule, pictures: radiology pictures, self expression: this space is reserved for whatever the patient wants to put in his/her personal medical record like the name and address of the person to contact in case of accident, the patient s willing about organ donation,... Each patient (and his/her DMP) is associated to a national health identifier called NIS ( Numéro Identifiant de Santé, French for health identifier number ). We can notice that this number is not the same as the NIR which is the patient s social security number. The social security number cannot be used for the DMP for privacy reasons. Indeed it leaks private information concerning the patient such as his/her gender or age because of its construction. The NIS is meant to be use as an identifier, not for authentication. [25] In the French project, the patient and his/her doctors will be able to access the DMP through the Internet. DMPs will be host by different hosts accredited to do so by the State. All DMP access attempts, granted or not, should be logged so a patient can check who wants to see his/her DMP Security requirements Here are the official requirements for the DMPs.

36 24 The French health care system and the Personal Medical Record project Authentication: The authentication step is important from a security point of view. It has not yet been decided how doctors and patients would be authenticated but the main proposition is to do it as described below: [25] Patient Authentication: The online access of his/her DMP by a patient would be granted via the patient NIS, a password of 4 digits and a onetime password sent by or SMS. The NIS in itself is not sufficient to grant access: it can be used as an identifier only and is not confidential. Doctor Authentication: To access a DMP, a doctor would have to present his CPS ( Carte de Professionel de Santé which can be translate in English by Health-related Professional Card ) together with the VI- TALE card of the patient which would contain the NIS of the patient (the VITALE card is the card provided by the public insurance provider to all its clients). The CPS permits the authentication of the doctor. Thus the doctor can be authorized (or not) to access the DMP corresponding to the given NIS, according to the confidentiality policy set by its owner. Confidentiality: Each patient owns his/her DMP, can read all data contained in it and controls which doctors can or cannot access them. In order to read the DMP of a patient, a doctor has to get the patient authorization. Thus a doctor can read the DMP only if the patient added him/her in the list of authorized doctors of his/her DMP. Moreover, the doctor can access the DMP only when he/she has the VITALE card of the patient (cf. the authentication description), which implies that he/she has the authorization of the patient to read it at this specific time. [25] Only doctors can access DMP. Another person, even authorized by the patient, cannot. Of course the hosts of the DMPs cannot as well. In France, a patient has the right to control data concerning him/her (cf Section 1.1). Thus it has been decided that a patient must have the possibility to decide which part(s) of his/her record a doctor is(are) allowed to read. Of course a doctor must always be able to read what he/she wrote himself. As hiding medical information can go against the interest of the patient, the patient will be discouraged to do so alone and encouraged to do it together with his/her primary care physician. It has not been decided yet if, in case of hidden information, doctors should be informed that some information is hidden from them or not, but they will probably not be aware of it. [25]

37 2.2 Official requirements of the DMP 25 This confidentiality policy has an exception. Indeed, an unauthorized doctor should be able to see the DMP of a patient in case of medical emergency. The procedure allowing a doctor to force the access of a DMP is called bris de glace in French (literally ice breaking, which comes from the little glass that has to be broken on an emergency alarm device in order to set it in motion). In this document, we call it emergency procedure. Emergency procedures are logged and communicated to the concerned patient. Doctors have to justify themselves when they use it. Nevertheless, a patient who explicitly asks, beforehand, that this emergency procedure cannot be used should be satisfied and doctors should then be unable to use the emergency procedure. [25] The patient has the right to access all data contained in his/her DMP, expect in case of hospitalization without consent (e.g. mental illnesses) and information provided by a third person. [25] The primary care doctor of a patient must have access to the DMP of the patient. According to the notations presented in Section 1.2.1, the confidentiality policies corresponding to the different parts of a DMP are: 1. general data: P D 1,..., D l. D 1,..., D l are doctors authorized to read at least one part of the DMP. All of them can read information contained in this part of a DMP. 2. general medical data: P A, D 1,..., D m. For each piece of data contained in this part of a DMP, its author A can read it as well as the doctors D 1,..., D m that the patient choose as being allowed to read the specific piece of data. 3. data about treatment: P A, D 1,..., D n (idem than for general medical data) 4. data about prevention: P A, D 1,..., D o (idem than for general medical data) 5. pictures: P A, D 1,..., D p (idem than for general medical data) 6. self expression: P D 1,..., D q. For each piece of data contained in this part of a DMP, the doctors that the patient choose as being allowed to read the specific piece of data are D 1,..., D d. where P is the patient owning the DMP.

38 26 The French health care system and the Personal Medical Record project Integrity: According to [25], doctors and pharmacists are the only ones allowed to write health information in the DMP of a patient. A patient can write only in the self-expression part. The integrity policies corresponding to the different parts of a DMP are: [25] 1. general data: H. The third party H (cf. later in this section) is the only one allowed to write in this section of the DMP. Indeed the patient nor a doctor should be allowed to change the NIS of the DMP, for example. 2. general medical data: A. All data of this section can have been influenced only by their author A. The authors have to be doctors or pharmacists. It has not yet been decided if they need to be explicitly authorized by the patient in order to write in the DMP. 3. data about treatment: A (idem than for general medical data) 4. data about prevention: A (idem than for general medical data) 5. pictures: A (idem than for general medical data) 6. self expression: P. This part of the DMP is reserved for what the patient writes. Delegation of trust: A third person should be able to act for the legitimate owner of the DMP in case of underage children, some elderly or dead persons (the DMP would still exit ten years after the death of its owner) [25]. We do not develop this issue in this report but we can notice that, Jif allowing act-for relationships to take place between principals, the implementation of such delegations of trust seems straightforward. Trust third party: A third party would maybe be necessary in case of hospitalization without consent, for example. This third party could be something like the Law or an Health Authority. 2.3 Simplified requirements of the DMP system As the aim of this work is to see if it is possible to implement a health care system such as the DMP one, we will implement a significant subset of the

39 2.3 Simplified requirements of the DMP system 27 requirements previously described. Nevertheless the solution chosen should be able to be developed to incorporate all the official requirements or to be adapted to small changes of the requirements (specially for what has not been decided yet). In this section we present the requirements that our implementation must fulfill. We can notice that not all sections of the DMP have to be implemented. Indeed they have very similar security requirements. The only one we will implement are: 1. general data This part is interesting because it appears only in one exemplary in the DMP. 2. general medical data Contrary to the general data part, this one can be composed of many different parts whose number is not known in advance. The other categories are very much alike the general medical data one from a confidentiality point of view. We do not deal with authentication in our system. Indeed it has not been decided yet how it should be done and we want to focus on information flows and more specially on confidentiality. Integrity is not ensured by our system. The simplified DMP system does not have to deal with trusted third party, delegation of trust, the possibility for patients to refuse the emergency procedure, the fact that patients should be discouraged to hide information or the possibility of hospitalization without consent. All attempts of doctors to log on to a DMP do not have to be recorded, except for the ones corresponding to the call of the emergency procedure. All those requirements can been seen as details regarding to confidentiality and thus as possible extension works. Similarly, we decide that doctors can be aware of the existence of pieces of information of the DMP hidden from them. This solution allows us to simplify the debugging part of the program implementation (because we will know why no information is visible) and can be changed easily later if necessary. The simplified DMP system presented in this document should be designed such that patients can choose which doctor(s) can access which part(s) of their DMP, in order to show that such confidentiality policies can be implemented in Jif. Nevertheless it will be enough to provide only methods permitting adding or removing a doctor as a reader for the whole DMP. The emergency procedure must be implemented. The scenarios described in Section should be possible to implement with the Jif system. Thus, according to those scenarios and the security requirements, the following actions should be possible:

40 28 The French health care system and the Personal Medical Record project 1. a patient can authorize a new doctor to access his/her DMP (scenario A) 2. a patient can deny the access to his/her DMP to a previously authorized doctor (except for data written by the doctor himself/herself) 3. a patient can read his/her own DMP 4. a patient is notified of a doctor using the emergency procedure on his/her DMP 5. a doctor can read the DMP of a patient, if authorized (scenarios A & B) 6. a doctor can write in the general medical data part of the DMP of a patient (scenarios A & B) 7. a doctor can use the emergency procedure to read a DMP, if necessary (scenario B) Those actions are represented in the use case diagram shown in Figure 2.1. Simplifying the requirements allows us to focus on confidentiality enforcement. After the implementation of a system fitting those requirements, we should be able to know if implementing a real-world DMP system in Jif is possible and which problems arise when doing so.

41 2.3 Simplified requirements of the DMP system 29 Figure 2.1: Use Case Diagram of the simplified DMP system

42 30 The French health care system and the Personal Medical Record project

43 Chapter 3 Implementation of the simplified DMP project Two different programs fulfilling the simplified requirements presented in Section 2.3 have been developed in Jif. Even though the two implementations have some differences, they are very much alike. In fact they correspond to two ways of writing and reading text files. The first version, DMP 1, is written entirely in Jif. The second one, DMP 2 contains some Java code that is used together with some Jif code. Thanks to this implementation we show how Java code can be integrated into some Jif one, which can be very useful in future work. Indeed it permits using Java libraries or classes already defined in Java in Jif code without having to rewrite them. For each implementation, we will present its structure and shows that it fulfills the requirements defined in Section 2.3. To conclude, we will evaluate and compare the two solutions.

44 32 Implementation of the simplified DMP project 3.1 DMP 1: Pure Jif code Presentation of the program The Jif code of the DMP 1 system contains 11 classes. The class EHR system contains only the main method of the program. It allows the user to choose if he wants to log on as a doctor or as a patient. The classes PatientProgram and DoctorProgram correspond to the actions that a patient or a doctor can do once they have been logged on. We can notice that a doctor session corresponds to a doctor logged on to a specific DMP. Thus if a doctor wants to access another DMP that the one he is currently logged on to, he has to log out before being able to log on to the other DMP. The classes Doctor and Patient represent patients and doctors. Their methods correspond to their possible actions. The class DMP is the most important one. An object of type DMP represents, of course, a DMP and contains objects of type GeneralData and GeneralMedical- Data. More details about the Jif classes are given in Section As the aim of this study is just to see if Jif is suitable for such a health care system, the DMP 1 program is not complete. For example, the user interface is quite basic and not graphic. Indeed, it is more interesting at this point of development to work on the confidentiality properties of the program, than on its usability by a user that does not really exist (yet). We can also notice that only one patient or doctor can use the program at the same time, and that the data contained in DMPs have simple formats: e.g. text, digits (no picture can be recorded for now). Moreover those data are recorded directly in text files. In a real system, data contained in a DMP - that is to say the general data, the general medical data, but also the information about which doctor is allowed to read which part of the DMP - would be saved within a database. Indeed, data within a Jif program are not persistent (they are not available anymore once the programs ends). Thus security, and more precisely confidentiality in our case, has to be ensured by the database too. In DMP 1 and DMP 2 systems, information is stored in text files. This solution offers two advantages: it is simpler to code than the one with a database and we can check easily what is written in a file. It is not secure because the text files can be read by any user of the system, in our case. But this is not important because recording data in text files is not a proper solution anyway. This solution was chosen not as a long term one but in order to provide a simple way to test the other parts of the Jif program. It should also be mentioned that in real life the communication between the user and the system is done over the Internet. Thus the data should maybe be encrypted before being sent. They should also be stored encrypted, so that the

45 3.1 DMP 1: Pure Jif code 33 Figure 3.1: Simplified Class Diagram of DMP 1 DMPs hosts would not have access to them. Authentication is not performed either because it is not included in this study. We could have done a simple file with a password checking system but anyway this is not the solution that would be kept at the end. We preferred not performing authentication at all than doing something not secure anyway. The DMP 1 and DMP 2 systems focus on ensuring confidentiality Structure of the program Figure 3.1 shows the class diagram corresponding to DMP 1. Here are more details on the classes: EHR system: EHR stands for Electronic Health Record. This class contains only the method main, which is the method that is called when

46 34 Implementation of the simplified DMP project the program is launched. When it is executed, it allows the user to log in as a patient or a doctor. Indeed, if the user presses the key 1 and then enters an existing NIS, the user is considered as logged-on as the patient corresponding to the NIS. There is no authentication check. Similarly, if the user presses 2 and then enters an existing doctor identifier and a NIS, the user is considered as logged-on as a doctor and can access the DMP of the patient corresponding to this NIS. PatientProgram: this class contains only one method, its constructor, which is called when a patient is logged on. Thanks to this method, the patient can choose to read his/her DMP (the DMP s data are displayed on the console), add or remove a doctor as a reader to his/her whole DMP and read the emergency procedure log of his/her DMP. He can also decide to log out. DoctorProgram: this class is similar to the PatientProgram one. When a doctor is logged on to a DMP, he/she can perform several actions: read the DMP or more exactly what he/she is allowed to read of it, add general medical information to it, or use the emergency procedure in order to force the access of the DMP. To do so he/she has to give a justification which will be recorded in the DMP log. He can also decide to log out. Patient: This class represents a patient. An object of type DMP is associated to every Patient object. The class Patient has several methods. The methods read DMP and read log are used by PatientProgram. They call themselves methods of the DMP class. The method get dmp is used within the DoctorProgram and Doctor classes. When a new Patient object is created, its DMP object is also created, as well as the GeneralData object linked to it. Doctor: This class represents a doctor and its methods correspond to actions that a doctor can perform. The constructor of DoctorProgram uses its methods write DMP, read DMP and emergency read DMP. DMP: This class, which represents a DMP, is the most important one of the program. It is composed of an object of type GeneralData and of several GeneralMedicalData objects. It is presented in Figure 3.2. It contains methods that are meant to be called by doctors and others that are meant to be called by patient. Let us study more the case of the methods add reader and remove reader. For obvious security reasons those methods should be called only by the patient owning the DMP. Indeed they add (or remove) the specified doctor as a reader for the whole DMP. This is done by calling the method add reader (or remove reader) of each GeneralData or GeneralMedicalData object linked to the DMP.

47 3.1 DMP 1: Pure Jif code 35 GeneralData: This class corresponds to the General Data part of the DMP, as it was presented in the requirements of the program. It has several attributes like surname, address, primary care physician, and also an array of readers, which are the doctors allowed to read the information contained in this class. GeneralMedicalData: An object of this class corresponds to a piece of general medical information as it is described in Section In our case it is composed of a date and a string. For example, it can correspond to a visit to a doctor. The list of the authorized readers of these data as well as their author are also attributes of this class. The author of such an object is always considered as an authorized reader, even if he/she is not in the readers list. Parser: This class is used to read and write text files which contain information about DMPs, their logs or the list of existing doctors. It creates new Patient and Doctor objects when a patient or a doctor wants to log on. PrincipalDMP: This class allows creating new Jif principals within the Jif program. The principal given in parameter to its constructor will be able to act for the new PrincipalDMP object created. Reader: This class is used to record which doctors are allowed to read a piece of information. It contains only the identifier of a doctor but is necessary in order for IDs to be stored within an array object. It implements the JifObject class. Indeed only JifObject objects can be stored in arrays. We can notice that signatures are used in the DMP system in order to make some classes of the java.util library available, for example the StringTokenizer class. Those signatures have been written by other Jif developers and have not been coded during this project (cf. Section 3.2.5). Signatures are explained in Section The code corresponding to those classes can be found on the CD given with this report. The text files associated to the DMP system and used by the Parser class are the following: nis.dmp: This type of text file contains the information of the DMP of the patient whose NIS is nis. We built 10 files of this type, corresponding to 10 patients whose NISs go from 1 to 10. An example of such a file is shown in Table 3.1.

48 36 Implementation of the simplified DMP project Figure 3.2: Attributes and methods headers (without authority requirements) of the DMP class nis.log: This type of text file contains the log of emergency procedure calls which gave access to the DMP whose NIS is nis. Such a file exists for each existing DMP file. An example of such a file is shown in Table 3.2. doctors.db: This text file contains the list of 10 doctor identifiers and their names. This file is shown in Appendix B Principals and labels Only three principals, DOCTOR, PATIENT and p, interfere in the system. The principals DOCTOR and PATIENT are created within the Jif program thanks to the PrincipalDMP class. They do not correspond to any user outside the Jif program. The principal p corresponds to the operating system user of the session in which the program is executed. It is taken as a parameter by the method main for the execution time of the program. By construction of PA- TIENT and DOCTOR, p can act for them. We explain in Section why

49 3.1 DMP 1: Pure Jif code 37 Categories DMP as written in the text file General Data: Last name Jensen Name Sarah Date of birth Address Aarhus Primary care physician d1 Allowed readers readers: d1 d2 General Medical Data: Date Author d1 Subject Sarah has a pneumonia, she has to take some antibiotics. Allowed readers d2 d3 Table 3.1: DMP of Sarah Jensen whose NIS is p1 On the 21 May 2008, Doctor Mortensen(d4): Car accident Table 3.2: Log corresponding to the DMP of the patient p2 this is necessary. Only the main method uses directly PATIENT and DOCTOR. Thanks to polymorphism, the classes DMP, Doctor, DoctorProgram, GeneralData, Parser, Patient and PatientProgram are able to receive any principals as parameters. The parameters which correspond to doctors principals are written D, whereas the parameters which correspond to patients principals are written P. The parameters corresponding to the current operating system user is written p, as it is in the main method. DOCTOR is then given as principal to all parameters D and PATIENT to all parameters P. Polymorphism is used in the code so several principals could correspond to doctors or patients. Indeed it would be interesting that every patient and every doctor correspond to different principals, instead of all patients corresponding to PATIENT and all doctors corresponding to DOCTOR. But dealing with as many principals as patients and doctors existing in the system, which correspond to all patients and doctors of France in our case, is quite problematic. A solution would be to create the principal corresponding to a patient, for example, at the same time as creating the Patient object corresponding to the patient, that is to say just after having collected the required information in the database of DMPs and after authentication. Thus the principal corresponding to the patient whose NIS is p1 could simply be P1. But the construction of new principals after parsing or after receiving information from a database requires dealing with integrity. Indeed, when the constructor of the class PrincipalDMP or of any Jif class creating new principals is called, the current implicit flow has

50 38 Implementation of the simplified DMP project to meet some integrity requirements that cannot be reached easily at any point of the program except at its very beginning. This is why our system does not deal with as many principals as there exist doctors and patients but just with one corresponding to all patients and one corresponding to all doctors. Nevertheless, in a real system, a more appropriate solution should be found for this problem. We introduce a solution in Section The principals PATIENT and DOCTOR allow distinguishing doctors from patients and thus is used to avoid confidentiality conflicts between a doctor and a patient. As, in our program, several patients or several doctors can not use the system at the same time, it is not possible to be confused between two patients or two doctors. As for principals, the choice of labels is an important step for ensuring the security requirements of our system. NIS, other identifiers, as well as the Patient and Doctor objects are not confidential and can be known by everyone. This is also the case for a DMP object in itself. Indeed, only information contained in a DMP has restrictive confidentiality policies. Here are the labels ensuring the confidentiality of data contained in a DMP: General data: the label of an object of type GeneralData is {P:}. The attributes of such an object are labeled {P:} as well. Those attributes are the name and the surname of the patient, his/her date of birth, his/her NIS, his/her address, the identifier of his/her primary care physician and the identifiers of the doctors allowed to read of this information. We can notice that the NIS of a patient could have been labeled {}. Indeed the NIS of a patient is not confidential. But as a GeneralData object is labeled {P:}, a declassification would have been necessary to make the NIS accessible to everyone anyway. According to the Section of this report, the confidentiality policy required for this information is P D 1,..., D l, with D 1,..., D l the doctors allowed to read the information. Even if all doctors had their own corresponding principals, it is not possible to have such a label in Jif. Indeed the doctors allowed to read can change whereas Jif labels associated to objects can not be changed once they have been defined. The solution is to label data so only the patient can read them and to declassify them when allowed readers ask for it. The list of identifiers of the doctors allowed to read the general data is thus recorded outside the labels. This list is also necessary to record and store the confidentiality policy between two executions of the program. General Medical Data: all objects of type GeneralMedicalData as well as the attributes of such objects are labeled {P:}. The attributes are the identifier of the author of the piece of medical information, the date, the

51 3.1 DMP 1: Pure Jif code 39 piece of information in itself and the allowed readers. The confidentiality requirement for this piece of information is P A, D 1,..., D m where D 1,..., D m are the doctors allowed as readers and A the author. As with general data, general medical data are labeled {P:} and allowed doctors can read those data thanks to declassifications made by the patient when doctors asked for a piece of data. A doctor is allowed to read a piece of data if he/she is in the list of allowed readers or if he/she is the author of the medical information. Log: the log of the emergency procedure use is labeled {P:} but, contrary to general data and general medical data, it is never declassified and can be accessed only by the patient owning the corresponding DMP. GeneralData and GeneralMedicalData objects could also be labeled {}, because the information contained in them is labeled {P:} anyway. The labels presented in this section are the most important ones. Labels of methods and attributes of the class DMP can be seen in Figure 3.2. For all the other classes, please refer to the Appendix C Authorities and declassifications Now that principals and labels of the system have been presented, we have to check that authorities of principals are not misused and that no unwanted declassification takes place. Table 3.3 shows the authorities given to the different classes: only the classes DMP and PatientProgram have P s authority whereas only DoctorProgram has D s. This seems secure. Nevertheless, all those classes have also p s authority whereas this principal can act for both P and D. This was not the case in the first stage of development of DMP 1, when the system was not persistent and the class Parser was not done yet. In addition, in order to be able to use the class Parser (to create an object of type Parser, to be more precise), classes need to have p s authority. The reason for this is explained in Section Therefore the classes DMP, PatientProgram and DoctorProgram need p s authority. We can assure that they do not misuse this authority because the key word actsfor is not used in the Jif code of any of those classes. Thus the classes DMP and PatientProgram do not use D s authority and DoctorProgram does not use P s. Many methods of the DMP 1 classes require that their caller has some authority. This has been done sometimes to use the authority of the caller of the method and sometimes to ensure that the caller of the method is a patient or a doctor and thus to make clear which methods are meant to be used by patients or by doctors. The only methods for which it is really important to check that the caller has P s authority are the methods which permit adding or removing

52 40 Implementation of the simplified DMP project Class Parameter Authority DMP [principal p, principal P, principal D] P,p Doctor [principal p, principal P, principal D] - DoctorProgram [principal p, principal P, principal D] D,p EHR system - - GeneralData [principal P] - GeneralMedicalData [label L] - Parser [principal p, principal P, principal D] p Patient [principal p, principal P, principal D] - PatientProgram [principal p, principal P, principal D] P,p PrincipalDMP - - Reader [label L] - Table 3.3: Parameters and authorities of classes in DMP 1 readers to DMP, GeneralData or GeneralMedicalData objects. In this case the condition where caller(p) placed in methods headers is vital to ensure the confidentiality requirements of the system. We now present where those authorities are used to perform declassifications, which are the sensitive security points of the system. The declassifications performed are shown in Table 3.4, except for the ones done in the Parser class. Those are discussed in Section The 13 declassifications presented in Table 3.4 can all been justified. We are going to discuss them according to the number associated to them in Table 3.4. The first declassification (1) makes the NIS of a patient public, which is authorized because NIS are identifiers and are supposed to be known by everyone from the beginning. The declassifications 2 and 3 concern general data and general medical data that a patient accepts to declassify so an authorized doctor can read them. Declassification 4 corresponds to the declassification of all information contained within a DMP so a doctor can read them within an emergency procedure call. Declassifications 5, 8, 9, 10, 11 and 13 concern data entered through the keyboard such as identifiers and choices made by the user about which action he/she wants to perform. These data are declassified to avoid the creation of implicit flows due to the fact that the path taken by the program depends on the value of the piece of data. These data can be declassified without any security risk. Declassifications 6 and 7 correspond to data given by a doctor through the keyboard and that have to be readable by the patient. They have to be declassified before being re-labeled {P:}. Doctors have no right concerning these data, except that they will be considered as the authors of the general medical ones. Declassification 12 concerns an output stream which permits displaying on the screen information labeled {P:D} within the

53 3.1 DMP 1: Pure Jif code 41 DoctorProgram class. As we can see all declassifications done do not go against the security requirements of our system and can thus be considered as secure.

54 42 Implementation of the simplified DMP project Method Labels Object Authority In the DMP class: 1 identifier {P:} to {} nis P: class 2 doctor read general data {P:} to {P:D} general information P: class 3 doctor read all general medical data {P:} to {P:D} medical information P: class 4 doctor emergency read DMP {P:} to {P:D} general and medical information P: class In the DoctorProgram class: 5 constructor {D:;D!:} to {D!:} choice made D: class 6 constructor {D:;D!:} to {D!:} new medical information D: class 7 constructor {D:;D!:} to {D!:} justification for emergency reading D: class In the EHR system class: 8 main {p:;p!:} to {p!:} choice made p: caller 9 main {p:;p!:} to {p!:} nis asked for p: caller 10 main {p:;p!:} to {p!:} id asked for p: caller 11 main {p:;p!:} to {p!:} nis asked for p: caller 12 main {p:} to {} output stream p: caller In the PatientProgram class: 13 constructor {P:;P!:} to {P!:} choice made P: class several declassifications are done to make this information available to doctors Table 3.4: Declassifications in DMP 1 and DMP 2 systems

55 3.1 DMP 1: Pure Jif code Accessing text files with Jif During the first development step of this system, DMP 1 was not persistent and data were not recorded into text files. The class Parser was created in order to be able to record DMPs and changes made to them. When writing the class Parser I discovered that Jif requires the authority of the user of the operating system session where the files are stored in order to read or write in them. This principal is denominated p within this chapter and the DMP 1 system. Thus the class Parser needs p s authority to read and write in text files. Therefore methods creating a Parser object must have this authority too. This is why the classes DMP, DoctorProgram and PatientProgram have p s authority: they need to be able to create an object of type Parser in order to record the changes made to DMPs by doctors and patients. The class jif.runtime.runtime, which is included in the Jif code given with the Jif compiler, contains methods which permit reading and writing in text files. We can notice that the explanations for these methods are in the Java file corresponding to this class (in the directory rt-src/jif/runtime of the Jif source code) and not in the Jif class which is just a Jif signature (cf. Section for explanation about signatures). A file can be read only if the label L given to the method openfileread, which returns an input stream, is at least as restrictive as the label derived from the Access Control List of the file to be read. This label is {o: r} where o is the owner of the file and r the allowed readers, according to the Access Control List of the file. In our case the label of the files is {p: }. In Parser, in order to read the files, the label L given to openfileread and thus attached to the input stream is {p:}, which is more restrictive than {p: }. Therefore all data read from the files are labeled {p:} and have to be declassified before being relabeled {P:} in the case of DMPs and their logs, and {} in the case of the doctors.db file. To write in a file, the label L attached to the output stream has to be no more restrictive than the one derived from the file in which we want to write. In our case the label L is {}. The authority of p is needed in order to create a stream which can write into a file owned by the operating system user p. Data that we want to write in text files are labeled {P:} and thus have to be declassified to {} before being written. Many declassifications are done in the class Parser. Nevertheless this should not been seen as a problem because storing data in text files is not an end solution anyway. We should keep in mind that the class Parser has been written in order to test the rest of the program. The methods of the class Parser and their labels are shown in Figure 3.3.

56 44 Implementation of the simplified DMP project Figure 3.3: Attributes and methods headers of the Parser class Tests In this section we present tests that have been done to check that the system implemented works. First we verify that every actions described in the use case diagram shown in Figure 2.1 can be performed. Then we implements the scenarios A and B described in Section Functionality checks Each time that the user of the program can choose between different actions, a sentence like Please enter 1 if you are a patient, 2 if you are a doctor and 0 if you want to exit the program: is displayed on the console. We can notice that if another number than 0, 1 or 2 is entered the question will be re-asked and that if another character is entered the program stops. If the user logs on as a patient, he/she can enter one of the already defined NISs (p1, p2,..., p10). If another NIS is entered an error is raised. This error is unfortunately not one of the program but a Jif bug, which is probably due to the inability of the Jif Runtime class to handle the non-existence of a file looked for. That is why this error cannot be handled by the program. When the error occurs a message such as Error: user is not found, for example, is displayed on the screen. Once the patient is logged on, he/she can perform several actions: Read his/her DMP: when the patient p1 reads her DMP, the following line is displayed on the screen: General data: Jensen Sarah 8 January 1984 p1 Aarhus d1 General Medical Data: 18 January 2006: Sarah has a pneumonia, she

57 3.1 DMP 1: Pure Jif code 45 Category Original DMP After adding d4 After removing d1 and d3 General Data: Last name Knudsen Knudsen Knudsen Name Lars Lars Lars Date of birth Address Skagen Skagen Skagen Primary care physician d1 d1 d1 Allowed readers readers: d1 d2 d3 readers: d1 d2 d3 d4 readers: d2 d4 General Medical Data: Date Author d1 d1 d1 Subject Lars is coughing Lars is coughing Lars is coughing a lot. a lot. a lot. Allowed readers d2 d2 d4 d2 d4 Table 3.5: Changes in the DMP of patient p10 when he adds or removes doctors as readers has to take some antibiotics.; Add or remove a doctor as a reader: when the patient p10 adds the doctor d4 as a reader and then removes the doctors d1 and d3, the text files corresponding to his DMP is changed as shown in Table 3.5. Read his/her DMP log: When the patient p1 asks for the log of her DMP, this line is displayed on the screen: The log of the DMP emergency access is, followed by nothing else, which means that the log is empty. When patient p2 does the same, the following words are displayed on the screen: The log of the DMP emergency access is: On the 11 April 2008, Doctor Mortensen(d4): bike accident, which means that the doctor d4 used the emergency procedure to access her DMP. We can see that a patient can perform all the actions he/she is supposed to be able to. Let us now check that the doctor can too. Ten doctors (d1, d2,... and d10) can log on to all existing DMPs. If the NIS entered does not correspond to any DMP, the same error as the one described before is raised. However, if it is the doctor that does not exist, the user is just not able to log on and can read the following line on the screen: Sorry, your demand cannot be fulfilled. Once a doctor is logged on a DMP, he/she can perform several actions: Read the DMP: Let us take the case of patient p1 whose DMP is shown in Table 3.1. If the doctor d1 tries to read her DMP, he can read this:

58 46 Implementation of the simplified DMP project General data: Jensen Sarah 8 January 1984 p1 Aarhus General Medical Data: 18 January 2006: Sarah has a pneumonia, she has to take some antibiotics.;. Indeed he is an allowed reader. But if the doctor d3 does the same, he can read only this: General data: non-authorized non-authorized non-authorized non-authorized non-authorized General Medical Data: 18 January 2006: Sarah has a pneumonia, she has to take some antibiotics.; because he is not an authorized reader for the whole DMP. We can notice that he is informed that some data that he cannot read exists. Add general medical data: When the doctor d4 chooses to add a new general medical data in the DMP of the patient p8, this line is displayed on the console: Write in the DMP a general medical information (one line max.). The doctor can write Allergy to paracetamol detected., for example. The DMP of the patient p8 is then changed as shown in Table 3.6. Use the emergency procedure: Figure 3.4 shows how a doctor can use the emergency procedure to read a DMP he/she does not have access to. At the end, the line On the 21 May 2008, Doctor Madsen(d9): Car accident. is added to the log of the DMP of the patient p Scenario realization Scenario A: This scenario, which is presented in Section 2.1.2, can be divided in actions performed by patient or doctor, as the ones described just before. The actions are presented in the order in which they happen: 1. Alex (p1) goes to the doctor Smith (d1) during his holidays. As he wants this doctor to be able to read his DMP, he adds him as a reader. Figure 3.5 corresponds to this part of Scenario A. Alex (p1) logs on his DMP. Alex adds the doctor d1 as a reader to his DMP. Alex (p1) logs off. 2. Doctor Smith (d1) reads Alex s DMP, sees that Alex s anti-tetanus vaccine is not up-to-date and thus gives him a dose. Figure 3.6 corresponds to this part of Scenario A. The doctor (d1) logs on Alex s DMP.

59 3.1 DMP 1: Pure Jif code 47 Category Original DMP After adding a piece of general medical data General Data: Last name Larsen Larsen Name Mathilde Mathilde Date of birth Address Esbjerg Esbjerg Primary care physician d3 d3 Allowed readers readers: d1 d2 d3 readers: d1 d2 d3 General Medical Data: Date Author d3 d3 Subject Mathilde is allergic to Mathilde is allergic to pollen of oak tree. pollen of oak tree. Allowed readers General Medical Data: Date Author Subject Allowed readers d4 Allergy to paracetamol detected. Table 3.6: DMP of patient p8 before and after that a doctor adds a new general medical information to it

60 48 Implementation of the simplified DMP project Please enter your ID (CPS): d9 Please enter the NIS of the DMP you want to access to: p1 The doctor d9 is connected to the DMP of the patient p1 Enter 1 if you want to read the DMP, 2 if you want to add a medical information to it, 3 if you want to use the emergency procedure to read the DMP or 0 if you want to log off: 1 General data: non-authorized non-authorized non-authorized non-authorized non-authorized General Medical Data: non-authorized; Enter 1 if you want to read the DMP, 2 if you want to add a medical information to it, 3 if you want to use the emergency procedure to read the DMP or 0 if you want to log off: 3 Justify your demand (one line max.): Car accident. General data: Jensen Sarah 8 January 1984 p1 Aarhus General Medical Data: 18 January 2006: Sarah has a pneumonia, she has to take some antibiotics.; Figure 3.4: Use of the emergency procedure on the DMP of patient p1 by the doctor d9 The doctor reads the DMP. Its content is displayed on the screen: General data: Poulsen Alex 14 July 1989 p3 Viborg d3 General Medical Data: 2 December 1995: Alex has a cold.; The doctor adds a new piece of general medical information to the DMP, with the comment Alex hurts himself at a tree branch. His anti-tetanus vaccine is not up-to-date, so I give him a dose. He ll need three other booster doses later.. The doctor logs off. 3. Alex adds his usual doctor (Doctor Green, d3) as a reader for his DMP so he one can read the new general medical information. Figure 3.7 corresponds to this part of Scenario A. Alex (p1) logs on his DMP. Alex adds the doctor d3 as a reader to his DMP. Alex (p1) logs off. 4. Doctor Green (d3) reads Alex s DMP and sees what Doctor Smith wrote in it. Figure 3.8 corresponds to this part of Scenario A. The doctor (d3) logs on Alex s DMP.

61 3.1 DMP 1: Pure Jif code 49 Please enter 1 if you are a patient, 2 if you are a doctor and 0 if you want to exit the program: 1 Please enter your NIS: p3 The patient p3 is logged on Enter 1 if you want to read your DMP, 2 if you want to add a doctor as a reader, 3 if you want to remove one, 4 if you want to read the DMP log, or 0 if you want to log off: 2 Enter the ID if the doctor you want to add as a reader (for the whole DMP): d1 The doctor d1 will be added as a reader. Enter 1 if you want to read your DMP, 2 if you want to add a doctor as a reader, 3 if you want to remove one, 4 if you want to read the DMP log, or 0 if you want to log off: 0 The changes made concerning DMP readers have been recorded. The patient p3 is logged off Figure 3.5: Implementation of the scenario A with the DMP 1 system - Part 1 The doctor reads the DMP. Its content is displayed on the screen: General data: Poulsen Alex 14 July 1989 p3 Viborg General Medical Data: 2 December 1995: Alex has a cold.; 21 May 2008: Alex hurts himself at a tree branch. His anti-tetanus vaccine is not up-to-date, so I give him a dose. He ll need three other booster doses later.; As we can see, the DMP 1 system corresponds to this scenario: all described actions can be performed within it. Figure 3.5, 3.6, 3.7 and 3.8 show the lines displayed on the console when the program is tested with this Scenario A. The scenario B can be as well divided into actions which can be performed with the DMP 1 system. Because the DMP 1 and DMP 2 systems are very similar, the implementation of the scenario B is presented only for the DMP 2 system in Section The DMP 1 system is evaluated in Section 3.3, after the presentation of the DMP 2 system.

62 50 Implementation of the simplified DMP project Please enter 1 if you are a patient, 2 if you are a doctor and 0 if you want to exit the program: 2 Please enter your ID (CPS): d1 Please enter the NIS of the DMP you want to access to: p3 The doctor d1 is connected to the DMP of the patient p3 Enter 1 if you want to read the DMP, 2 if you want to add a medical information to it, 3 if you want to use the emergency procedure to read the DMP or 0 if you want to log off: 1 General data: Poulsen Alex 14 July 1989 p3 Viborg General Medical Data: 2 December 1995: Alex has a cold.; Enter 1 if you want to read the DMP, 2 if you want to add a medical information to it, 3 if you want to use the emergency procedure to read the DMP or 0 if you want to log off: 2 Write in the DMP a general medical information (one line max.): Alex hurts himself at a tree branch. His anti-tetanus vaccine is not up-to-date, so I give him a dose. He ll need three other booster doses later. The information added to the DMP has been recorded. Enter 1 if you want to read the DMP, 2 if you want to add a medical information to it, 3 if you want to use the emergency procedure to read the DMP or 0 if you want to log off: 0 The doctor d1 is logged off. Figure 3.6: Implementation of the scenario A with the DMP 1 system - Part 2

63 3.1 DMP 1: Pure Jif code 51 Please enter 1 if you are a patient, 2 if you are a doctor and 0 if you want to exit the program: 1 Please enter your NIS: p3 The patient p3 is logged on Enter 1 if you want to read your DMP, 2 if you want to add a doctor as a reader, 3 if you want to remove one, 4 if you want to read the DMP log, or 0 if you want to log off: 2 Enter the ID if the doctor you want to add as a reader (for the whole DMP): d3 The doctor d3 will be added as a reader. Enter 1 if you want to read your DMP, 2 if you want to add a doctor as a reader, 3 if you want to remove one, 4 if you want to read the DMP log, or 0 if you want to log off: 0 The changes made concerning DMP readers have been recorded. The patient p3 is logged off Figure 3.7: Implementation of the scenario A with the DMP 1 system - Part 3 Please enter 1 if you are a patient, 2 if you are a doctor and 0 if you want to exit the program: 2 Please enter your ID (CPS): d3 Please enter the NIS of the DMP you want to access to: p3 The doctor d3 is connected to the DMP of the patient p3 Enter 1 if you want to read the DMP, 2 if you want to add a medical information to it, 3 if you want to use the emergency procedure to read the DMP or 0 if you want to log off: 1 General data: Poulsen Alex 14 July 1989 p3 Viborg General Medical Data: 2 December 1995: Alex has a cold.; 21 May 2008: Alex hurts himself at a tree branch. His anti-tetanus vaccine is not up-to-date, so I give him a doses. He ll need three other booster doses later.; Figure 3.8: Implementation of the scenario A with the DMP 1 system - Part 4

64 52 Implementation of the simplified DMP project 3.2 DMP 2: Integrating Java code in a Jif program Presentation of the program This system is very much like the DMP 2 system. The main difference is that the parser is not implemented by a Jif class but by a Java one. Using Java code in Jif requires the use of signatures and communicating data between Java and Jif classes requires the use of interfaces. This implementation is interesting because it shows how Java code can be used within a Jif program. The DMP 2 system was coded after DMP 1 and thus presents some improvements, like the suppression of the class Patient which is quite useless in the DMP 1 system Structure of the program Figure 3.9 shows the class diagram corresponding to the DMP 2 system. Classes placed in the upper part of Figure 3.9 are written in Jif whereas interfaces and classes of the bottom part are written in Java. We can notice that there is no class Patient in DMP 2. Indeed, as in DMP 1 the class Patient is not really useful because all its methods refer to DMP ones, the class Patient has been removed from DMP 2 and DMP is used directly in DMP 2 where Patient is used in DMP 1. Here are more details on the Jif classes: EHR system: This class is very similar to the homonym one of DMP 1 system. It also contains the main method and allows the user of the program to connect himself/herself as a doctor or a patient to a specified DMP. After launching the parser and getting back the DMP object and, depending on the case, the Doctor one, it launches the PatientProgram s or DoctorProgram s constructor. PatientProgram: This class has the same function as the PatientProgram class of DMP 1 but instead of dealing with a Patient object it deals directly with a DMP one. DoctorProgram: This class has the same function as the DoctorProgram class of DMP 1 but instead of dealing with a Patient object it deals directly with a DMP one. Doctor: This class implements the IDoctor interface. Apart from this

65 3.2 DMP 2: Integrating Java code in a Jif program 53 Figure 3.9: Simplified Class Diagram of DMP 2

66 54 Implementation of the simplified DMP project point, the methods of this class are the same as the ones of the Doctor class of DMP 1. DMP: This class implements the IDMP interface. Its functions are the same as in the DMP 1 system. GeneralData: This class is exactly the same as the DMP 1 one. GeneralMedicalData: This class is exactly the same as the DMP 1 one. JifCreator: This class implements the Creator interface. It is used by the Parser class to create DMP and Doctor objects. PrincipalDMP: This class is exactly the same as the DMP 1 one. Reader: This class is exactly the same as the DMP 1 one. The Java classes and interfaces can be integrated into Jif code thanks to Jif signatures. This is explained in Section Here are the different Java classes and interfaces that are used in DMP 2: Creator: This interface is used to give a JifCreator object (coded in Jif) to the Parser, which is written in Java. IDMP: This interface is used so DMP objects can be dealt with by Java ones. IDoctor: This interface is used so IDoctor objects can be dealt with by Java ones. Parser: This class reads text files and writes in them, like the Jif class Parser of DMP 1. Signatures are also used for using some classes of the java.util library, as for the DMP 1 system (cf. Section 3.1.2). The code corresponding to the DMP 2 system is on the CD given with this report Principals and labels Principals and labels are the same as DMP 1 ones (cf. Section 3.1.3): General data: General data are labeled {P:} and declassified to {P:D} when an authorized doctor asks for it.

67 3.2 DMP 2: Integrating Java code in a Jif program 55 General medical data: General medical data are labeled {P:} and declassified to {P:D} when an authorized doctor asks for it. Log: The log is labeled {P:} and is never declassified. Labels of methods and attributes of the Jif classes and interfaces of the DMP 2 system are shown in Appendix D Authorities and declassifications Concerning authority use, the difference between the DMP 1 and DMP 2 systems is that, in DMP 2, the principal p which corresponds to the operating system user of the program is not used in other classes than EHR system which contains the main method. Indeed p is used in DMP 1 to create Parser objects (cf. Section 3.1.5) but, as Parser objects do not need p s authority in DMP 2 (cf. Section 3.2.5), p is not needed to create Parser objects in DMP 2. Thus DM P, DoctorProgram, PatientProgram and Parser do not have p s authority. Table 3.7 presents the parameters and authorities linked to all classes and interfaces of the system. We can notice that, as PatientProgram and DMP classes do not have p s authority, there is no possibility for them to use the PATIENT s authority and that DoctorProgram cannot use DOCTOR s authority either (p can act for DOC- TOR and PATIENT as in DMP 1). This was not the case of the DMP 1 system. The declassifications done in the DMP 2 system are presented in Table 3.4. The declassifications of DMP 2 are exactly the same as DMP 1 ones, except for the ones done in the Parser class of DMP 1. Indeed as Parser is written in Java in DMP 2, no declassifications are necessary to read or write text files. Declassifications made in the DMP 1 system have already been checked in Section Thus we can conclude that no unwanted declassifications are done in DMP 2 either Integrating Java code into a Jif program: signatures It is possible to integrate Java code into Jif thanks to signatures. A signature is a Jif class (or interface) where only headers of the methods of the corresponding Java class (or interface) are defined. The bodies of those methods are not defined in the Jif signature but only in the Java code. The idea is that a signature

68 56 Implementation of the simplified DMP project Class Parameter Authority Jif classes DMP [principal P, principal D] P Doctor [principal P, principal D] - DoctorProgram [principal P, principal D] D GeneralData [principal P] - GeneralMedicalData [label L] - JifCreator [principal P, principal D] P Main - - PatientProgram [principal P, principal D] P PrincipalDMP - - Reader [label L] - Jif signatures Creator [principal P, principal D] - IDMP [principal P, principal D] P IDoctor [principal P, principal D] - Parser [principal P, principal D] - Table 3.7: Parameters and authorities of classes in DMP 2 specifies the labels associated to methods that are defined in a Java class. Signatures thus replace the Java classes during the Jif compilation where security analysis takes place. Indeed Jif signatures contain all information about method names or labels needed by other Jif classes to be compiled. The Java class files containing Java bytecode which are used to execute the system are the ones resulting of the compilation of Java classes or interfaces, not the ones coming from the signatures compilation. Thus signatures are based on the substitution of Java class files by others after the Jif compiler checks the security properties of the code. We can notice that it is not verified whether the labels declared in the signature of a class correspond to the security provided by the corresponding Java class. Thus the use of Java code inside a Jif program can permit security leaks. [6] In the DMP 1 and 2 systems, signatures are used for some classes of the Java library util in order to be able to use the StringTokenizer class which permits separating a string into several ones. The signatures for those basic classes have been written by programmers of the Pennsilvania University for a project called JPMail (cf. Section 4.2.3). [16] Apart from those, several signatures and their Java files are used by the DMP 2 system. The interfaces Creator, IDMP and IDoctor allow the parser to indirectly create Jif objects of type JifCreator, DMP and Doctor. The class Parser is written in Java. Thus the access of text files is not limited like in the DMP 1 system and no authority is required by the class. Let us now explain how a DMP object is created by an object of type Parser, as an example of how Jif and Java classes can interact. The Parser method readdmp receives an object

69 3.2 DMP 2: Integrating Java code in a Jif program 57 implementing the Creator interface as parameter. In practice it is always a Jif object of type JifCreator. The Parser method reads the file corresponding to the DMP asked for and retrieves in it all necessary information (name, address...). It then transmits this information to the object implementing the Creator interface. This object returns an object implementing the IDMP interface to the Parser method which then transmits it to its caller. In practice objects implementing the Creator interface are of type JifCreator and creates DMP objects which implement IDMP. Thus Jif objects are created by Java classes thanks to interfaces. Let us now verify that the signatures of the used Java classes and interfaces are well labeled. The methods headers of the Jif signature of the Parser class are shown in Figure We can see that they are very much like the ones of the Parser class of the DMP 1 system shown in Figure 3.3. In the Parser signature, IDMP and IDoctor objects created are labeled {}, which does not leak any information (a DMP can be accessed by everyone, only what is inside should be protected). The log of a DMP is labeled {P:} so only a patient can read it. The boolean {P:} confirming that a DMP has been written without any error in a text file, the boolean {D:} confirming that a general medical data has been added to a DMP, and the boolean {P:} confirming that the use of the emergency procedure has been logged correctly are labeled as they are in the Parser class of DMP 1 (i.e. resp. {P:}, {D:} and {P:}). Not only do all those labels seem appropriate but they correspond as well to what was checked as secure by the Jif compiler in the DMP 1 system. The interfaces IDMP, IDoctor and Creator are labeled as the Jif classes DMP, Doctor and Creator are. As the labels of those classes are checked by the Jif compiler according to what they are doing we can deduce that those labels are secure. We can deduce from this discussion that the signatures seem to respect the confidentiality requirements of the DMP 2 system. The DMP 2 system contains an example of how Java code can be used to create Jif objects or simply how it can interact with Jif code. This is interesting because it shows how already existing Java libraries, among others, can be used in Jif Tests The DMP systems 1 and 2 are very similar. All functionalities tested in Section for DMP 1 also work with DMP 2. As the two systems are almost indiscernible from the user point of view, we present only the tests which shows a difference.

70 58 Implementation of the simplified DMP project Figure 3.10: Attributes and methods headers of the Parser signature We can notice that contrary to the DMP 1 system, the DMP 2 system does not raise any error when a patient or a doctor whose NIS or ID are asked for does not exist. Indeed if the NIS or ID e3, for example, is entered by the user, the system displays a message like those ones: The NIS e3 does not correspond to any DMP and The ID e3 does not correspond to any doctor. The user can then try to log in again. When a patient log on he/she can do several actions: Read his/her DMP: when the patient p9 reads her DMP, the following lines are displayed on the screen: Johansen Emma Aalborg d8 readers: d2 d d2 Emma fell while biking. Her wrist is now painful. d8 We can notice that this function is slightly different than the equivalent one of DMP 1 from the way it presents the information and by the fact that the allowed readers for the different parts of the DMP are readable by the patient. Nevertheless this can be considered as a detail. Add or remove a doctor as a reader: This functionality is the same as with the DMP 1 system. Read his DMP log: This functionality is the same as with the DMP 1 system.

71 3.2 DMP 2: Integrating Java code in a Jif program 59 When a doctor logs on a DMP, he/she can perform the following actions: Read the DMP: This functionality is the same as with the DMP 1 system. Add a general medical data: This functionality is the same as with the DMP 1 system. Use the emergency procedure: This functionality is the same as with the DMP 1 system. Scenario A is presented with the DMP 1 system (cf. Section 3.1.6). As the two systems are very much alike from the user point of view, we present only the execution of scenario B in this section. Scenario B: This scenario can be divided into actions performed by the system. These actions are: 1. Mathilde (p8) has an accident. Doctor O Brien (d6), who is at the emergency room, reads her DMP thanks to the emergency procedure and takes care of her. Figure 3.11 shows what is displayed on the screen during the execution of the following actions: The doctor (d6) logs on Mathilde s DMP. The doctor uses the emergency procedure to read the DMP. He justifies himself with the words: Had a bike accident. Is unconscious.. The content of the DMP is displayed on the screen: General data: Larsen Mathilde 21 August 1974 p8 Esbjerg General Medical Data: 12 May 1985: Mathilde is allergic to pollen of oak tree.; The doctor adds new general medical information to the DMP, with the comment Mathilde hurt her head on the road during a bike accident. She was unconscious for some time. The scanner is good but she broke her left arm.. The doctor logs off. 2. Mathilde adds her usual doctor (doctor Green, d3) as a reader for her DMP so he can read the new general medical information. Figure 3.12 shows what is displayed on the screen during the execution of the following actions: Mathilde (p8) logs on her DMP. Mathilde adds the doctor d3 as a reader to her DMP.

72 60 Implementation of the simplified DMP project Mathilde (p8) logs off. 3. Doctor Green (d3) reads Mathilde s DMP and sees what Doctor O Brien wrote in it. Figure 3.13 shows what is displayed on the screen during the execution of the following actions: The doctor (d3) logs on Mathilde s DMP. The doctor reads the DMP. Its content is displayed on the screen: General data: Larsen Mathilde 21 August 1974 p8 Esbjerg General Medical Data: 12 May 1985: Mathilde is allergic to pollen of oak tree.; 10 June 2008: Mathilde hurt her head on the road during a bike accident. She was unconscious for some time. The scanner is good but she broke her left arm.; The DMP 2 system corresponds to this scenario: all described actions can be performed with it. 3.3 Evaluation of the implemented DMP systems Now that the DMP 1 and DMP 2 systems have been presented and that we have tested them we evaluate and compare them Evaluation of the implementations Even though the DMP implementations presented in this chapter are quite basic concerning the functionalities, the user interface or the way data are recorded (i.e. in text files), they are sufficient reveal whether real electronic health care systems can be implemented in Jif and how confidentiality can be ensured. The conclusions about the Jif language driven from the implementations are presented in Chapter 4. The DMP 1 and DMP 2 systems fulfill all the requirements made in Section 2.3. Indeed all the functionalities presented in the use case diagram shown in Figure 2.1 are implemented by the systems, as well as the scenarios A and B, as shown by the tests (cf. sections and 3.2.6). We can notice that even though patients can add or remove doctors as readers only for their whole DMP, the structure of the DMP would permit the easy creation of new Jif methods allowing patients to add and remove doctors as readers for one section at a time.

73 3.3 Evaluation of the implemented DMP systems 61 Please enter 1 if you are a patient, 2 if you are a doctor and 0 if you want to exit the program: 2 Please enter your ID (CPS): d6 Please enter the NIS of the DMP you want to access to: p8 The doctor d6 is logged on the DMP of patient p8 Enter 1 if you want to read the DMP, 2 if you want to add a medical information to it, 3 if you want to use the emergency procedure to read the DMP or 0 if you want to log off: 3 Justify your demand (one line max.): Had a bike accident. Is unconscious. General data: Larsen Mathilde 21 August 1974 p8 Esbjerg General Medical Data: 21 May 2008: Mathilde is allergic to pollen of oak tree.; Enter 1 if you want to read the DMP, 2 if you want to add a medical information to it, 3 if you want to use the emergency procedure to read the DMP or 0 if you want to log off: 2 Write in the DMP a general medical information (one line max.): Mathilde hurt her head on the road during a bike accident. She was unconscious for some time. The scanner is good but she broke her left arm. The information added to the DMP has been recorded. Enter 1 if you want to read the DMP, 2 if you want to add a medical information to it, 3 if you want to use the emergency procedure to read the DMP or 0 if you want to log off: 0 The doctor d6 is logged off the DMP of patient p8. Figure 3.11: Implementation of the scenario B with the DMP 2 system - Part 1

74 62 Implementation of the simplified DMP project Please enter 1 if you are a patient, 2 if you are a doctor and 0 if you want to exit the program: 1 Please enter your NIS: p8 The patient p8 is logged on. Enter 1 if you want to read your DMP, 2 if you want to add a doctor as a reader, 3 if you want to remove one, 4 if you want to read the DMP log, or 0 if you want to log off: 2 Enter the ID if the doctor you want to add as a reader (for the whole DMP): d3 The doctor d3 will be added as a reader. Enter 1 if you want to read your DMP, 2 if you want to add a doctor as a reader, 3 if you want to remove one, 4 if you want to read the DMP log, or 0 if you want to log off: 0 The changes made concerning DMP readers have been recorded. The patient p8 is logged off. Figure 3.12: Implementation of the scenario B with the DMP 2 system - Part 2 Please enter 1 if you are a patient, 2 if you are a doctor and 0 if you want to exit the program: 2 Please enter your ID (CPS): d3 Please enter the NIS of the DMP you want to access to: p8 The doctor d3 is logged on the DMP of patient p8 Enter 1 if you want to read the DMP, 2 if you want to add a medical information to it, 3 if you want to use the emergency procedure to read the DMP or 0 if you want to log off: General data: Larsen Mathilde 21 August 1974 p8 Esbjerg General Medical Data: 12 May 1985: Mathilde is allergic to pollen of oak tree.; 10 June 2008: Mathilde hurt her head on the road during a bike accident. She was unconscious for some time. The scanner is good but she broke her left arm.; Figure 3.13: Implementation of the scenario B with the DMP 2 system - Part 3

75 3.3 Evaluation of the implemented DMP systems 63 Indeed readers lists are independent for each GeneralData or GeneralMedical- Data object. Readers lists are a sensitive point of the system. Indeed, a patient declassifies a piece of information if the doctor asking for it is in the corresponding readers list. Thus, only patients have to be able to change readers lists. In the implemented systems this is ensured by requiring the PATIENT authority to call methods influencing readers lists but in a later version integrity of those lists could be ensured by Jif integrity labels. The Jif compiler ensures that the Jif classes of the systems do not go against the confidentiality policies set, except when explicit declassifications are performed. As we have checked that the confidentiality labels correspond to the requirements and that no illegal declassification happens (without taking I/O into account), we are ensured that the Jif programs are secure concerning data confidentiality. The way data are stored does not fulfill the confidentiality requirements. Indeed, text files can be read outside the Jif program by all operating system s users. Storing data in text files permits keeping track of DMPs and changes made to them but cannot be considered as a solution for real health care systems. Moreover, no authentication is done when a doctor or a patient logs on, which should be changed in future versions of DMP systems. We can wonder how much work would be required by a change of policy. In general, we can expect that a change of policy influencing the principals involved in the systems would require more work than if the change does not influence the principals. But in any case a change of policy represents a considerable amount of work. DMP 1: In the DMP 1 system the Parser class is written in Jif and thus obeys the security rules checked by the Jif compiler. Unfortunately many declassifications from {p:} to {P:} or {} are necessary to read and write text files. This makes the code less clear and could lead to a confidentiality leak. The fact that p s authority is given to many classes and that p can act for DOCTOR and PATIENT is also a bad point of the system. Even if it does not leak security because the authorities are not misused, it is an inconvenient because it makes it easier for a programmer to perform an unwanted declassification. We can also notice that an attempt to read a text file which does not exist raises a Jif bug. The bug does not leak more information than the DMP 2 system does under the same circumstances because the system tells the user anyway when a NIS does not exist, but such a bug would not be acceptable in a real system. DMP 1 implementation includes lines of code (in Jif). DMP 2: In the DMP 2 system the Parser class and some interfaces are written in Java. The Jif compiler does not verify that the Jif labels defined in the Jif signatures correspond to the security provided by the Java classes or interfaces. Thus, the use of Java code is secure only if our hand verification has been well

76 64 Implementation of the simplified DMP project done. This goes against the concept of Jif, which is to provide a way of ensuring that a code is secure. We can notice that principals authorities are not given to classes which could misuse them, as in the case of the principal p in the DMP 1 system. In fact the whole DMP 2 system can be seen as an improvement of DMP 1. For example the Patient class has been removed compared to the DMP 1 system because it is not indispensable. Nevertheless the main point of DMP 2 is not to improve DMP 1 but to show how Java code can be used in Jif code. DMP 2 includes lines of Jif code and 230 lines of Java code Comparison of the implementations and future work In DMP 1 the Parser class was hard and long to debug because of errors in it and that finding the source of an error is difficult. Moreover this class requires a lot of declassifications to be done, because of the authority needed to read or write in a text file. We can also notice that the principal p is used a lot and known by most of the DMP system classes. Its authority is given to some classes which need it only to use the Parser class. This could lead to the misuse of authority, especially if several programmers work on the project. In the DMP 2 system, p s authority is not necessary to use the Parser class. This is much more secure. Moreover the number of declassifications done in the system is smaller and thus it is more clear that the system observes the security requirements. The Parser code is easier to check and was much easier to write in DMP 2. Nevertheless the parser is written in Java and thus the Jif compiler cannot check that it is secure. For all these reasons we cannot conclude that one DMP system is better than the other. Both of them have advantages and drawbacks, as listed above. The two DMP versions are not final. Indeed, in a real system text files would not be used, but data would be recorded, probably encrypted, in a database. Providing continuity of confidentiality outside the Jif program would not have a meaning in DMP 1 and 2 because the text files solution would not be used anyway. Nevertheless, storing data in text files allows us to see the advantages and drawbacks of Jif, how Java code can be integrated into Jif one and how difficult it is to deal with Input/Output flows in Jif. A more detailed evaluation of Jif is presented in Chapter 4. Apart from changing the way to store data, another improvement of the DMP systems could consist of performing authentication and adding more principals. Those two ideas go together because authentication should allow the user of the system to log on as a specific principal. It would ensure that there is no confidentiality leak between two patients or two doctors. Improving principals

77 3.3 Evaluation of the implemented DMP systems 65 management is indispensable for developing a large scale system. The solution developed by the Pennsilvania State University to bind principals to private keys could be appropriate for a health care system (cf. Section 4.2.3). Another very interesting way to improve the security of the DMP systems is to add integrity checks. It would also permit seeing if coding in Jif to ensure both confidentiality and integrity is do-able and what problems it raises.

78 66 Implementation of the simplified DMP project

79 Chapter 4 Programming in Jif In this section, we speak about the experience acquired in Jif thanks to the development of two DMP systems. We also present the work of other Jif programmers. To conclude we discuss the advantages and disadvantages of Jif and give some advice that may be useful for any future work with Jif. 4.1 Programming experience with Jif The Jif implementations presented in Chapter 3 were done with the Jif version In this section we explain why this version, which is not the latest one, was chosen. We also present two different and instructive problems encountered while programming in order to make the Jif experience acquired during this project beneficial to future real world system projects. The first problem concerns the coding of a simple parser in Jif while the second concerns integrity.

80 68 Programming in Jif Choice of a Jif version and JifClipse In this project, the Jif compiler version used is the one. This version was not the last released one when this project began (it was Jif 3.1.0) but was nevertheless chosen for two reasons. First this project deals only with confidentiality and not with integrity, whereas Jif requires taking care of integrity when performing declassification. This is explained in more details in Section The second and main reason for choosing the Jif version is that the Eclipse plug-in for Jif, JifClipse 2.0.0, requires the use of this Jif version. JifClipse is a plug-in for the integrated development environment Eclipse. Eclipse is used by a lot a Java developers to help them coding. It permits programmers to code much faster and to organize their code. Coding a big Java system without using an integrated development environment is quite unrealistic. JifClipse has been developed by the Systems and Internet Infrastructure Security Laboratory of the Computer Science and Engineering Department of The Pennsylvania State University (US) in order to make programming in Jif easier. They are currently working on a JifClipse update which will support the latest Jif version, Jif 3.2.0, which was released in April [20] JifClipse provides several useful features. Its constraints view permits us to see the confidentiality and integrity constraints applied to an expression at one point of the program, such as the arguments of a method, and thus helps to decide which label should be associated to this expression. The PC label view is very convenient too. Indeed it permits us to see what is the implicit flow linked to each line of the Jif code. The outline view provides an overall view of a class, its attributes, and its methods with the security labels corresponding to them. The figures 3.2, 3.3 and 3.10 and the ones in Appendices C and D are screen captures of this view. Figure 4.1 shows JifClipse with its PC label and constraints views. The quick help feature can be used to quickly debug a program. Indeed it suggests labels that fulfill security constraints or downgrading expressions. JifClipse can be downloaded on its web-page [19]. [20] The parser In this section we present the problems encountered while developing a simple parser for the DMP system as well as the solutions found. In order to make the system persistent without using a real database as it would be in a real system I chose, for simplicity reasons, to store data about patients, DMPs and doctors in text files (cf. Section 3.1.1). Those files are meant to be read or re-written by the Jif system. For example, the file p1.dmp corresponds to the DMP of the

81 4.1 Programming experience with Jif 69 Figure 4.1: JifClipse