Lillian Røstad Access Control in Healthcare Information Systems Thesis for the degree of Philosophiae Doctor (PhD) Trondheim, January 2009 Norwegian University of Science and Technology Faculty of Information Technology, Mathematics and Electrical Engineering Department of Computer and Information Science NTNU Norwegian University of Science and Technology Thesis for the degree of Philosophiae Doctor (PhD) Faculty of Information Technology, Mathematics and Electrical Engineering Department of Computer and Information Science c Lillian Røstad ISBN 978-82-471-1259-5 (printed ver.) ISBN 978-82-471-1260-1 (electronic ver.) Theses at NTNU, 2009:24 Printed by NTNU Trykk Logic will get you from A to B. Imagination will take you everywhere. (Albert Einstein) Abstract Access control is a key feature of healthcare information systems. Access control is about enforcing rules to ensure that only authorized users get access to resources in a system. In healthcare systems this means protecting patient privacy. However, the top priority is always to provide the best possible care for a patient. This depends on the clinicians having access to the information they need to make the best, most informed, care decisions. Care processes are often unpredictable and hard to map to strict access control rules. As a result, in emergency or otherwise unexpected situations, clinicians need to be able to bypass access control. In a crisis, availability of information takes precedence over privacy concerns. This duality of concerns is what makes access control in healthcare systems so challenging and interesting as a research subject. To create access control models for healthcare we need to understand how healthcare works. Before creating a model we need to understand the requirements the model should fulfill. Though many access control models have been proposed and argued to be suitable for healthcare, little work has been published on access control requirements for healthcare. This PhD project has focused on bridging the gap between formalized models and real world requirements for access control in healthcare by targeting the following research goals: RG1 To collect knowledge that forms a foundation for access control requirements in healthcare systems. RG2 To create improved access control models for healthcare systems based on real requirements. This PhD project has consisted of a number of smaller, distinct, but related projects to reach the research goals. The main contributions can be summarized as: C1 Requirements for access control in healthcare: Studies performed on audit data, in workshops, by observation and interviews have helped discover requirements. Results from this work include methods for access control requirements elicitation in addition to the actual requirements discovered. C2 Process-based access control: The main conclusion from the requirements work is that access control should be tailored to care processes. Care processes are highly dynamic and often unpredictable, and access control needs to adapt to this. This thesis suggests how existing sources of process information, both explicit and implicit, may be used for this purpose. C3 Personally controlled health records (PCHR): This thesis explores the consequences of making the patient the administrator of access control and proposes a model based on these initial requirements. From a performed usability study it is clear that the main challenge is how to keep the patient informed about the consequences of sharing. ii Contents Contents iii Preface vii I Introduction 1 Introduction 1.1 Background and motivation 1.1.1 Legal considerations 1.2 Research focus . . . . . . . 1.2.1 Research goals . . . 1.3 Publications . . . . . . . . . 1.4 List of terms . . . . . . . . 1.5 Thesis outline . . . . . . . . 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3 5 6 7 7 10 12 2 Research process and contributions 13 2.1 A shift of focus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.2 Research approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3 Publications and contributions . . . . . . . . . . . . . . . . . . . . 17 2.3.1 C1: Requirements for access control in healthcare . . . . . . 17 2.3.2 C2: Process-based access control . . . . . . . . . . . . . . . 20 2.3.3 C3: Access control for Personally Controlled Health Records 21 3 Results 3.1 Requirements for access control in healthcare . . . . . . . . . . . . 3.1.1 Paper A: Access Control in Healthcare Applications . . . . 3.1.2 Paper B: A Study of Access Control Requirements for Healthcare Systems Based on Audit Trails from Access Logs . . . 3.1.3 Paper C: An extended misuse case notation: Including vulnerabilities and the insider threat . . . . . . . . . . . . . . . 3.1.4 Paper D: The iAccess Handbook: A Methodology for Access Control Integration . . . . . . . . . . . . . . . . . . . . . . . 23 24 24 25 26 27 iv Contents 3.1.5 3.2 3.3 Paper E: Access Control and Integration of Health Care Systems: An Experience Report and Future Challenges . . . . 3.1.6 Summary of contributions . . . . . . . . . . . . . . . . . . . Process-based access control . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Paper F: MG-RBAC: Using Medical Guidelines as a Source of Contextual Information to Activate and Deactivate Roles and Permission . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Paper G: Towards Dynamic Access Control for Healthcare Information Systems . . . . . . . . . . . . . . . . . . . . . . 3.2.3 Summary of contributions . . . . . . . . . . . . . . . . . . . Personally controlled health records . . . . . . . . . . . . . . . . . 3.3.1 Paper H: An Initial Model and a Discussion of Access Control in Patient Controlled Health Records . . . . . . . . . . 3.3.2 Paper I: Personalized Access Control for a Personally Controlled Health Record . . . . . . . . . . . . . . . . . . . . . 3.3.3 Paper J: Patient-Administered Access Control: a Usability Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.4 Summary of contributions . . . . . . . . . . . . . . . . . . . 28 29 30 30 31 31 33 33 34 35 35 4 Discussion 4.1 C1: Requirements for access control in healthcare . . . . . . . . . . 4.2 C2: Process-based access control . . . . . . . . . . . . . . . . . . . 4.3 C3: Personally controlled health records . . . . . . . . . . . . . . . 37 38 39 40 5 Concluding remarks 5.1 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 42 References 45 II 47 Papers A Access Control in Healthcare Applications 49 B A Study of Access Control Requirements 67 C An extended misuse case notation 79 D The iAccess Handbook 93 E Access Control and Integration of Health Care Systems 101 F MG-RBAC 111 G Towards Dynamic Access Control 117 Contents v H An Initial Model and a Discussion of Access Control 125 I 135 Personalized Access Control J Patient-Administered Access Control: a Usability Study 145 Bibliography 153 vi Contents Preface This thesis is submitted to the Norwegian University of Science and Technology (NTNU) in partial fulfillment of the requirements for the degree Philosophiae Doctor (PhD). The work has been conducted at the Department of Computer and Information Science (IDI), NTNU, Trondheim, Norway, under supervision of Associate Professor Øystein Nytrø. Acknowledgements I would like to thank my advisor Associate Professor Øystein Nytrø and co-advisor Professor Svein Johan Knapskog for all their help. I would also like to thank my colleagues at SINTEF ICT for their support and help. A special thanks to my coauthors Per Håkon Meland, Inger Anne Tøndel, Ole Andreas Alsos and Ole Edsberg for their contributions. I would also like to thank Thomas Brox Røst, Heine Kolltveit and Maria Bartnes Line for help with reading and reviewing. Thanks are also due to Associate Professor Kenneth Mandl of the Children’s Hospital Informatics Program and Professor Pete Szolovits at MIT for allowing me to spend six months working with their team. The work presented in this thesis has been funded by The Research Council of Norway as part of the project “Cross-Faculty Research Programme in Information Security Organized within the Strategic Focus Area of ICT Established at NTNU” grant no.: 158597/V30. Lillian Røstad January 9, 2009 viii Preface Part I Introduction Chapter 1 Introduction It’s a job that’s never started that takes the longest to finish. J. R. R. Tolkien 1.1 Background and motivation Healthcare is information-intensive – vast amounts of information is created in the course of a treatment process and access to this information is important in the continuing care for the patient. Over the last decade, Electronic Health Records (EHR1 ) have become increasingly common and widespread. However, the EHR is not the only clinical information system in use. In any single hospital one can often count more than a hundred separate clinical information systems, ranging from common systems like the EHR to specific X-ray or lab systems. In addition to these systems, much information is still only available on paper. Even if healthcare is very technologically advanced in areas such as surgical equipment and patient monitoring, in many aspects healthcare information systems are still in their infancy. Most healthcare information systems are local to a hospital or a doctor’s office, but patients are not. Patients move, become ill while traveling, or simply choose to use a different healthcare provider. Patients with long-term illnesses and/or a complex diagnosis may receive services from many providers. There is a disconnect between the way information is managed and the needs for access to that information. Information remains in one place but patients do not. The explanation for this disconnect is not simply the technological challenges of integrating systems and information, but can be found in the legal frameworks regulating how sensitive 1 Also often referred to as Electronic Patient Records (EPR) 4 Introduction clinical information may, or may not, be shared. There is a strong, current focus on resolving these issues, based on the fact that availability of correct, up-to-date and complete information is crucial to make the best, most informed care decisions. In 1997, the Norwegian government published a report named The patient first! [1] outlining visions for a more patient-centric healthcare. “Openness”, “availability” and a more “coherent care process” are among the ten goals listed in the report. To fulfill these goals, availability of information needs to be improved for healthcare personnel as well as for the patient and next of kin. The goals put forth in this report are consistent with the current focus in healthcare worldwide. Since the publication of the report in 1997 many projects have focused on improved availability through information and systems integration, while other projects have chosen the path of improved availability through new systems where the patient manages access to information. Healthcare systems may be categorized as security-critical systems. Other systems often described as being security-critical include railroad signaling systems, nuclear plant control systems, air traffic control systems as well as financial systems such as the online banking systems most of us use. Access control is an important feature of all of these systems, but healthcare systems are different in one important aspect. Access control is about making sure information is accessible only to authorized users. Whereas in most other security-critical systems the default access control rule is “when in doubt – deny”, for healthcare it will always be “when in doubt – allow”. Protecting patient privacy is important, but the most important goal is to provide the best possible care for patients, which depends on the clinicians having access to information. Hence, access control is a balance between confidentiality and availability. This is what makes access control in healthcare systems so challenging – and interesting as a research subject. To ensure availability in emergencies or otherwise unexpected situations, mechanisms that allow a user to override the access control is included in many healthcare systems. Allowing access control to be overridden implies including functionality in a system that may be misused. To minimize security risk, retrospective controls such as extensive auditing are usually employed. In [2] this is described as “optimistic security”. An example illustrates what may happen, from a patient perspective: JD has been suffering from abdominal pains for a while. As the pains seem to become more frequent and severe he makes an appointment to see his primary physician. The physician orders a number of tests but finds nothing wrong. He decides that JD should be admitted to the gastro2 ward at the hospital for further testing. When JD arrives at the hospital the staff queries him about his medical history, what tests his 2 Gastroenterology is the medical specialty devoted to the study, diagnosis and treatment of disorders of the digestive system (www.medterms.com). 1.1 Background and motivation 5 doctor performed and what the results were. They take blood samples from JD to send to the lab for further testing. When the tests are done the results are entered into the EHR via the lab system. The clinicians treating JD at the gastro ward then log onto the EHR system and review the test results. The tests reveal a very high white blood cell count. They suspect that JD may have leukemia and decides to transfer him to the cancer ward immediately for further testing. The clinicians can transfer JD physically but cannot change his “admitted to” status in the system and JDs record is only accessible to people working at the gastro ward where he is currently admitted. The clinicians at the cancer ward are aware of this, so rather than using the EHR to prepare for JDs arrival they ask the gastro ward to print a summary of their findings so far and send it with JD. After having performed several more tests they log onto the EHR by overriding the access control to enter their findings (...) This example illustrates what frequently happens to patients: they are given an initial diagnosis that may change several times before the real problem is identified. As the diagnosis, tests and treatment change they are transferred back and forth and often asked to recount their medical history and treatment so far. The override mechanisms are often used to handle common, recurring events that are not allowed by the access control rules. The existence of override mechanisms, and even the invention of the term “optimistic security”, indicates that there is room for improvement on access control in healthcare. It is also clear from the previous discussion that access control for healthcare systems faces challenges that are unique and still unresolved. 1.1.1 Legal considerations As mentioned, any healthcare system is bound by the legal framework of the country it resides in. In Norway, the most prominent legal frameworks for healthcare information are: The Health Personnel Act (Helsepersonelloven), The Personal Data Act (Personopplysningsloven) and The Personal Health Data Filing System Act (Helseregisterloven). The Health Personnel Act [3] regulates the conditions under which healthcare personnel are allowed access to health information. This act also contains the secrecy obligation (§21) that healthcare professionals are bound to. The secrecy obligation is sometimes used as an argument against the need for heavy security mechanisms in healthcare systems. The Personal Data Act [4] defines what personal data is, and what rules regulate the management of personal data. According to the Personal Data Act, healthcare 6 Introduction information is considered “sensitive personal information” and there are strict rules for who can create and manage records containing this type of information. The Personal Health Data Filing System Act [5] is specific to records of health information. It defines who may be responsible for the management of health records (the data controller3 ), and also the conditions under which this management may be performed by some other entity (the data processor4 ) on behalf of the controller. Of particular interest is §13: Only the data controller, the data processors and persons working under the instructions of the controller or the processor may be granted access to personal health data (transl.). In Norway the public health service is organized in four health regions: north, central, west, and south-east. Within each health region there are several health enterprises. Current legal interpretation prohibits the direct sharing of healthcare information on a level higher than the health enterprise, with an argumentation founded on §13 in the Personal Health Data Filing System Act. This means that while it may be desirable from a user viewpoint, and possible form a technical viewpoint, it is currently not legal to have systems for shared electronic patient records across organizational boundaries. The only legal way to share data across borders, organizational or national, is if the patient gives his/her informed consent. This consent is normally only valid for one sharing instance and there is also an ongoing discussion about the requirements for an informed consent. The legal situation is no less complicated in other countries which implies that legally sharing health data across national borders is close to impossible. Resolving the legal issues for enabling shared care is one of the most important challenges for the future and something that will affect the development of future IT systems for healthcare. Legal considerations also affect the requirements for access control in healthcare. However, this PhD project has a technical focus and therefore will not discuss legal considerations in-depth. 1.2 Research focus Current research on access control largely tends toward a theoretical approach. A quick search on google, or skimming the bibliography of this thesis, reveals a large number of scientific papers presenting diverse access control models. Many of them use healthcare as a motivating example, but very few are based on empirical studies that support the selection of model properties or explain in more detail why the models are suitable for a healthcare setting. Research on access control 3 no: 4 no: databehandlingsansvarlig databehandler 1.3 Publications 7 may be viewed as a continuum from theoretical via implementation-centric to user- and problem focused. Research so far tends toward the former while little has been done on the latter. Motivated by this fact, this PhD project has taken a practical approach to access control in healthcare. The focus has been on increasing our understanding of information and access needs to be able to create access control models that are better tailored to reality. Only when we have a better understanding of the everyday reality of healthcare workers and their patients does it make sense to propose solutions in the form of access control models for healthcare information systems. The main goal is to create access control models that minimize the need for use of override mechanisms and “optimistic security”. 1.2.1 Research goals To summarize, the research goals for this PhD project are: RG1 To collect knowledge that forms a foundation for access control requirements in healthcare systems. RG2 To create improved access control models for healthcare systems based on real requirements. 1.3 Publications The research performed as part of this project has resulted in the publication of a number of scientific papers that are listed here. The papers can be placed in three groups based on area of contribution: C1 Requirements for access control in healthcare C2 Process-based access control C3 Personally controlled health records The papers in the requirements group present methods for access control requirements elicitation created in this project and results of using these methods. The main conclusion from the requirements elicitation studies was that access control models need to be more dynamic, and able to adapt to and support care processes. The papers grouped under the heading process-based access controls present access control models that are motivated by the findings in the requirements work. Finally, the group of papers on personally controlled health records takes a different viewpoint where the responsibility for access control administration is shifted from a skilled administrator to the patient. This work was motivated by a research stay 8 Introduction in Boston in 2007 working with the team at the Children’s Hospital Informatics Program5 that develop the Indivo6 personally controlled health record. At the time of writing nine of the papers have been published. The last paper has been accepted for publication at a workshop taking place in March 2009, and the final, camera-ready, version of the paper is included here. The papers are listed here in the order they appear in the second part of the thesis. Rather than using chronological ordering by publication date, the papers have been grouped according to topic as explained in the previous section. Requirements for access control in healthcare • Paper A: Lillian Røstad, Access Control in Healthcare Applications, NOKOBIT05, ISSN: 1504-1697, ISBN: 82-8033-026-7, p. 2441-253, Bergen 22.-23. November 2005. • Paper B: Lillian Røstad and Ole Edsberg, A Study of Access Control Requirements for Healthcare Systems Based on Audit Trails from Access Logs, Annual Computer Security Applications Conference (ACSAC), ISSN: 10639527, ISBN: 0-7695-2716-7, p. 175-186, Miami, December 11-15 2006. • Paper C: Lillian Røstad, An extended misuse case notation: Including vulnerabilities and the insider threat, The Twelfth Working Conference on Requirements Engineering: Foundation for Software Quality (REFSQ’06), Essener Informatik Beitrage, ISBN: 3-922602-26, p. 33-43, Luxembourg, June 5-6 2006. • Paper D: Per Håkon Meland, Lillian Røstad, Inger Anne Tøndel, Øystein Nytrø, The iAccess Handbook: A Methodology for Access Control Integration, Medinfo 2007: Proceedings of the 12th World Congress on Health (Medical) Informatics – Building Sustainable Health Systems, IOS Press, ISSN: 09269630, p. 2015-2016, Brisbane, August 20-24 2007. • Paper E: Lillian Røstad, Per Håkon Meland, Inger Anne Tøndel and Øystein Nytrø, Access Control and Integration of Health Care Systems: An Experience Report and Future Challenges, Second International Workshop “Dependability Aspects on Data WArehousing and Mining applications” DAWAM 2007, in conjunction with The International Conference on Availability, Reliability and Security (ARES 2007), IEEE Computer Society 2007, ISBN: 0-7695-2775-2, p. 871-878, Vienna, April 10-13 2007. 5 www.chip.org 6 www.indivohealth.org 1.3 Publications 9 Process-based access control • Paper F: Lillian Røstad, MG-RBAC: Using Medical Guidelines as a Source of Contextual Information to Activate and Deactivate Roles and Permissions, Medinfo 2007: Proceedings of the 12th World Congress on Health (Medical) Informatics – Building Sustainable Health Systems, IOS Press, ISSN: 09269630, p. 1741-1743, Brisbane, August 20-24 2007. • Paper G: Lillian Røstad and Øystein Nytrø, Towards Dynamic Access Control for Healthcare Information Systems, Medical Informatics Europe (MIE 2008), IOS Press 2008, ISBN: 978-1-58603-864-9, p. 703-708, Gøteborg, Sweden, May 26-28 2008. Extended edition invited to be submitted to the journal Methods of information in medicine. Personally controlled health records • Paper H: Lillian Røstad, An Initial Model and a Discussion of Access Control in Patient Controlled Health Records, The International Workshop on Privacy and Assurance (WPA-2008), in conjunction with The International Conference on Availability, Reliability and Security (ARES 2008), IEEE Computer Society 2008, ISBN: 0-7695-3102-4, p. 935-942, Barcelona, March 4-7 2008. • Paper I: Lillian Røstad and Øystein Nytrø, Personalized Access Control for Personally Controlled Health Records, The 2nd Computer Security Architecture Workshop (in conjunction with 15th ACM Conference on Computers and Communication Security), ISBN: 978-1-60558-287-0, p. 9-15, George Mason University, Fairfax, Virginia, October 31st 2008. • Paper J: Lillian Røstad and Ole Andreas Alsos, Patient-Administered Access Control: a Usability Study, accepted for publication at Security and Usability (SECUSAB) 2009, in conjunction with The International Conference on Availability, Reliability and Security (ARES 2009), Fukuoka, March 16-19 2009. 10 1.4 Introduction List of terms This list includes terms that need to have a clear definition within the context of this thesis. Security-related terms All definitions are from RFC 4949 Internet Security Glossary (Version 2) [6]. RFC 4949 sometimes provides several definitions for one term. In this list, only the definition regarded most appropriate for this thesis is included. Information security Measures that implement and assure security services in information systems, including in computer systems and in communication systems. Availability The property of a system or a system resource being accessible, or usable or operational upon demand, by an authorized system entity, according to performance specifications for the system; i.e., a system is available if it provides services according to the system design whenever users request them. (Data) Confidentiality The property that data is not disclosed to system entities unless they have been authorized to know the data. (Data) Integrity The property that data has not been changed, destroyed, or lost in an unauthorized or accidental manner. Privacy The right of individuals to control or influence what information related to them may be collected and stored and by whom and to whom that information may be disclosed. Access control A process by which use of system resources is regulated according to a security policy and is permitted only by authorized entities (users, programs, processes, or other systems) according to that policy. Authorization An approval that is granted to a system entity to access a system resource. Authorized user A system entity that accesses a system resource for which the entity has received an authorization. Permission An authorization or set of authorizations to perform security-relevant functions in the context of role-based access control. Tutorial: A permission is a positively stated authorization for access that (a) can be associated with one or more roles and (b) enables a user in a role to access a specified set of system resources by causing a specific set of system actions to be performed on the resources. 1.4 List of terms 11 Role-based access control (RBAC) A form of identity-based access control wherein the system entities that are identified and controlled are functional positions in an organization or process. Tutorial: Administrators assign permissions to roles as needed to perform functions in the system. Administrators separately assign user identities to roles. When a user accesses the system in an identity (for which the user has been registered) and initiates a session using a role (to which the user has been assigned), then the permissions that have been assigned to the role are available to be exercised by the user. Healthcare informatics related terms All definitions are from prEN 13940-1 Health Informatics - System of Concepts to Support Continuity of Care - Part1: Basic Concepts [7]. Health care (healthcare) Services, or supplies related to the health of an individual. Health care organisation Organisation involved in the direct provision of health care activities. Health care professional Person authorised by law or official regulations to be involved in the direct provision of health care activities. Health care provider Health care professional or health care organisation involved in the direct provision of health care activities. Subject of care Person, or other living subject, seeking to receive, receiving or having received health care activities. Health record Repository of information regarding the health of a subject of care. Electronic Health Record (EHR) 7 Repository of information regarding the health of a subject of care, in computer processable form. Clinical information Information regarding the health of a subject of care, recorded, or meant to be recorded, in some health record. Clinical guideline Set of systematically developed statements to assist the decision of health care parties about health care activities to be provided with regard to a health issue in specified clinical circumstances. 7 Or Electronic Patient Record (EPR). In the context of this thesis the terms EHR and EPR are used interchangeably. 12 Introduction Encounter/patient contact Contact in the course of which health care activities are delivered to a subject of care in her or his presence, and her or his health record is accessed to and managed. Episode of care Situation during which health care activities are performed by one health care provider to address one health issue. Period of care Situation during which one or more contacts occur between a subject of care and one or several health care professionals, in the framework of a care mandate held by a health care provider. Shared care Organisational principle where two or more health care providers jointly co-operate to provide health care activities to a subject of care for a continuing health issue. Note: in this thesis the terms “care” and “treatment” are used frequently. In the context of this thesis a “treatment” is a specific step, or set of steps, performed as part of a larger care process. Patient “care” is used in a wider context including all services provided for a patient and may include several treatments. 1.5 Thesis outline This thesis is divided into two parts: the introduction and the published papers. The first part includes motivation and background for the project, a summary of the research process and contributions, summaries of the papers in part two, and concluding remarks including suggestions for future work. The second part of the thesis contains the papers that constitute the main results of this PhD project. At the end of the thesis a bibliography of all references used in the papers is included. Chapter 2 Research process and contributions “If you keep at it, one day something which at first appeared impossible will become merely something very difficult indeed.” Danny Paradise (American Yoga instructor, b.1943) This chapter describes the research process and how the results of this PhD project came to be what they are. 2.1 A shift of focus - from solving to understanding Albert Einstein is frequently quoted to have said: “If we knew what it was we were doing, it would not be called research, would it?” This quote illustrates why research projects are hard to plan. Re-planning research projects as new knowledge is discovered is very common and often necessary. This is also true for this PhD project. The project started out with a brief problem description that was refined into a more detailed project plan over the first year of the project. The original title of this PhD project was Context- and Role-Based Dynamic Access Control in Distributed Healthcare Information Systems and the intention was to 14 Research process and contributions develop access control models that were “context-aware”, “more dynamic” and overall better suited to the needs of healthcare. However, it quickly became clear that the information needed to design such models simply did not exist. As a result, the main focus of this project shifted towards eliciting requirements for access control in healthcare and exploring how this knowledge may be used to create improved access control models. The research goals, as stated in section 1.2.1, have been: RG1 To collect knowledge that forms a foundation for access control requirements in healthcare systems. RG2 To create improved access control models for healthcare systems based on real requirements. 2.2 Research approach A number of different research methods have been used on the different subprojects that have been part of this PhD project and several studies have been performed. Figure 2.1 provides an overview of the different studies - linking them to contribution area1 , research goals2 and what papers the results have been published in. Not all published papers are directly linked to studies because the thesis also includes position papers and papers on developed methods. In the figure these papers have been placed close to, or in the transition between, studies that they have inspired or been inspired by. As figure 2.1 shows, the different studies may be classified as quantitative or qualitative depending on the sample size (number of participants). Most of the studies performed in this project have been qualitative and only the log study qualifies as quantitative. The following studies have been performed: Quantitative studies: • Investigation of access control audit trails: in healthcare systems all access to information is registered in the audit log. As part of this PhD project a study of access log data for one month collected from eight hospitals in Central Norway was performed. The collected logs contained a total of 1 794 153 entries. The study revealed that the use of the override mechanism for access control constituted 17% of all accesses to patient records. The study focused on the reasons why the users needed to override the normal access control. The findings from the study are presented in paper B: A Study of Access 1 C1 Requirements for access control in healthcare, C2 Process-based access control and C3 Personally controlled health records as explained in section 1.3 2 as presented in section 1.2.1 2.2 Research approach 15 RG1 C1 Case study: Paper A Access control in healthcare 2004/2005 Paper C RG1 RG2 C1 Log data study 2006 C2 Paper B Paper H RG1 RG2 RG1 C1 Semi-structured interviews: Experiences with integration 2005 RG1 Paper E Paper I C3 Paper J Usability studies: PCHR sharing interface 2008 Paper F RG1 RG2 C2 Observation: Clinicians’ use of information Paper G 2005 (2007) C1 Paper D Workshops: Requirements for integration Paper E 2005 April 2004 October 2008 Quantitative study Paper Research goal Qualitative study Contribution Input Figure 2.1: Research studies, contributions and papers 16 Research process and contributions Control Requirements for Healthcare Systems Based on Audit Trails from Access Logs. Findings from this study inspired the study of observational data to examine access needs from an internal and external viewpoint. Qualitative studies: • (Semi-) structured interviews were performed on a small user base to gather feedback about user experiences related to information access for a portal that integrates several healthcare systems. The interviews were performed in an organization where workshops were also performed. • Workshops: tailored workshops were used to elicit requirements for access control in a healthcare system integration context. The output of the workshops was summarized in extended UML activity diagrams. The workshops and diagrams are described in paper D: The iAccess Handbook: A Methodology for Access Control Integration. The results from interviews and workshops are presented together in paper E: Access Control and Integration of Health Care Systems: An Experience Report and Future Challenges. • Observation: paper G Towards Dynamic Access Control for Healthcare Information Systems utilizes data from observational studies of healthcare professionals’ use of different information sources in their clinical work. The observations were performed by summer students in 2005 and the data they collected was analyzed with a focus on identifying information sources used by clinicians in specific situations and interpreted from an access control viewpoint in 2007. • Case studies: paper A Access Control in Healthcare Applications is based on an informal case study of access control mechanisms in the dominant electronic health record systems used in Norway. Performing these studies of existing systems was necessary to understand the research challenges for access control in healthcare. These case studies were very important for the understanding of shortcomings of access control in healthcare as it is implemented and in use today, and as figure 2.1 shows, these case studies inspired many of the studies to be performed later in the PhD project. • Usability studies: paper J Visualization for Patient-Administered Access Control: a Usability Study presents findings from a usability study where the goal was to observe and analyze the user’s reaction when presented with a system where it was obvious that they could, in detail, determine the access they wanted to give others to their health information. Three different designs were tested for usability, and card-ranking was utilized to get feedback from the users on which design they preferred and why. 2.3 Publications and contributions 2.3 17 Publications and contributions This PhD project has consisted of a number of smaller projects resulting in a total of ten scientific papers. All papers are included in their final version. At the time of writing nine of these papers have been published, while one has been accepted for publication at the ARES workshop Security and Usability (SECUSAB) taking place in March 2009. Figure 2.2 provides an overview of the written papers, how they fit together and which papers inspired or led to others. The papers are grouped by contribution area, C1-C3, as explained in section 1.3. Additionally, group C1 (requirements) has been further subdivided into papers presenting methods for requirements elicitation, and papers presenting results of applying those methods. The figure also illustrates that two of the requirements papers have a special focus on system integration. The next sections present the papers and contributions in more detail. 2.3.1 C1: Requirements for access control in healthcare As illustrated in the figure, and as mentioned in the previous sections, a major focus has been on better understanding of requirements for access control in healthcare and three of the published papers focus mainly on requirements. The first paper Access Control in Healthcare Applications was written very early on and published in 2005 at The Norwegian Conference on Organizations’ use of Information Technology (NOKOBIT). The paper is based on a case study of electronic health record (EHR) systems in use in Norway and presents a generalized access control model for healthcare. The model comprises common properties of the access control models in the systems that have been studied. This generalized model illustrates how access control is static (define once - use many) in many systems, and also explains how access in exceptional circumstances, such as emergencies, is handled by allowing the user to override access control. This is often referred to as “exception access”. Learning about the use of exception access mechanisms inspired the study of audit logs presented in the paper A Study of Access Control Requirements for Healthcare Systems Based on Audit Trails from Access Logs. The study revealed that the use of exception access mechanisms triggers extensive logging of the users’ activities from that point on and that users have to provide a reason for using exception access. The idea for this paper was to examine how common the use of these access mechanisms was, and to see if the information in the audit logs could reveal requirements for access control. The assumption was that any frequently occurring event may be a candidate for inclusion as an allowed access control rule. The study revealed that exception access was used to access the EHRs of about 50% of the 18 Research process and contributions PhD start 2004 2005 2006 Paper A Access Control in Healthcare Applications NOKOBIT 2005 C1: REQUIREMENTS Paper B A Study of Access Control Requirements for Healthcare Systems Based on Audit Trails from Access Logs ACSAC 2006 METHOD Paper C An extended misuse case notation: Including vulnerabilities and the insider threat REFSQ 2006 2007 Paper D The iAccess Handbook: A Methodology for Access Control Integration MedInfo 2007 INTEGRATION Paper E Access Control and Integration of Health Care Systems: An Experience Report and Future Challenges DAWAM 2007 C2: PROCESS-BASED ACCESS CONTROL Paper F MG-RBAC: Using Medical Guidelines as a Source of Contextual Information to Activate and Deactivate Roles and Permissions MedInfo 2007 2008 Paper G Towards Dynamic Access Control for Healthcare Information Systems MIE 2008 C3: PERSONALLY CONTROLLED HEALTH RECORDS Paper H An Initial Model and a Discussion of Access Control in Patient Controlled Health Records WPA 2008 Paper I Personalized Access Control for a Personally Controlled Health Record CSAW 2008 2009 Paper J Visualization for Patient-Administered Access Control: a Usability Study SECUSAB 2009 Figure 2.2: Papers grouped by topic 2.3 Publications and contributions 19 patients in the study period and 17% of all accesses were performed using exception access. We found that a relatively small number of similar reasons were provided for using exception access, including out-patient clinic encounters and physician referrals. Clearly, these are events that should be handled by the access control. Methods for access control requirements elicitation Requirements elicitation requires the use of appropriate methods, which sometimes leads to creation of new methods or adaptation of existing ones. Two papers presenting new or adapted methods for requirements elicitation have been published as part of this project. The paper An extended misuse case notation: Including vulnerabilities and the insider threat presents an extension of the misuse case notation. The misuse case notation is itself an extension of UML use cases. Use cases describe desired functionality in a system and misuse cases extend the UML use case notation by adding negative use cases and negative actors (colored black) to illustrate threats and attackers respectively. The main contribution of the extended misuse case notation is adding notations to represent threats from insiders and vulnerable system functionality. That is, desirable system functionality that may be exploited by an attacker. This notation was created to be able to represent and illustrate the threat posed by exception access mechanisms in healthcare systems. Integration Information and system integration is among the most important challenges faced by healthcare today. Currently, the reality is that there are hundreds of disconnected clinical systems in use at any hospital, and most systems are local to a ward, clinic, or hospital. Access control is tightly coupled with information and depends on knowledge of information structure. This means that when integrating systems and information, access control integration is a major challenge. One of the papers on requirement elicitation methods has a special focus on integration of healthcare information systems and access control. The paper, The iAccess Handbook: A Methodology for Access Control Integration, presents a handbook consisting of two parts: relevant reference information and a set of methods to collect, analyze, structure and represent relevant information for access control integration. The handbook focuses on the legal, technical, and organizational aspects of integration and should serve as an aid in the access control integration process. At the time of writing, the handbook can be found online at http://iaccess.idi.ntnu.no. The paper, Access Control and Integration of Health Care Systems: An Experience Report and Future Challenges, reports findings from a study of one such integration 20 Research process and contributions effort with a focus on access control. It turns out that in the system under study access control is not integrated at all. A portal has been created to offer a common access point to several subsystems. An access control mechanism implemented in the portal decides what subsystems a user can access through the portal, but deciding what access the user has to information is left to the different subsystems by forwarding the user’s credentials from the portal. This study illustrates a practical approach taken on the path towards integration and provides insight into the difficulties of access control integration. 2.3.2 C2: Process-based access control From the requirements work it became clear that many access control mechanisms implemented in existing systems are too static, in the sense that access rules rarely change or are updated after a patient is admitted. Access usually depends on what ward a patient is admitted to, where a user is working and the profession (doctor, nurse etc.) of the user. However, the care process for a patient is dynamic and individual. To improve access control, and minimize the use of exception access mechanisms, access control should be process-based – tailored to workflows in healthcare and dynamic in the sense that access rules change or are updated as the care process changes. Medical guidelines are idealized representations of the treatment process for a patient with a specific diagnosis. The paper MG-RBAC: Using Medical Guidelines as a Source of Contextual Information to Activate and Deactivate Roles and Permissions presents how the information in medical guidelines may be utilized in process-based access control. This is illustrated with an example medical guideline on treatment of Gestational Diabetes Mellitus (GDM)3 . The guideline includes instructions on how often the patient should see her doctor. This could be used to open the EHR for access for the doctor around the next scheduled appointment, rather than it being accessible all the time. According to the GDM guideline the patient is to monitor her glucose level and if it exceeds a certain limit she needs to see her doctor. If access to the EHR was linked to the GDM guideline the EHR could be made accessible to the patient’s doctor in the event of a too high glucose level measurement. Using information in medical guidelines as a foundation for access control necessitates a tight coupling between the computerized guidelines and the healthcare information system. This will be a challenge as today there are not that many guidelines that have been encoded in a computerized format and the knowledge base would be incomplete. Access control can therefore not be based on guidelines alone, but the existing guidelines may serve as a valuable addition to the access control ruleset. 3A form of diabetes found in pregnant women. 2.3 Publications and contributions 21 The study of audit logs led to a realization that the logs in healthcare systems contain information that could be used as a valuable source of work process knowledge. Data mining techniques could be applied to historical log data to extract usage patterns. The techniques to be used would be similar to the ones used in anomalybased Intrusion Detection Systems (IDS). Anomaly (or abnormality) based intrusion detection was described by Dorothy Denning in [8] as a technique where one attempts to train the system to recognize normal use and detect intrusions based on deviations from what is considered normal use. In [9] Lee and Stolfo discuss their experiences in using data mining approaches for intrusion detection and suggest an approach using classification, association rules, and frequency episodes to discover patterns in audit data and also to guide the audit data gathering process. Other studies have focused on slightly different techniques, but common to them all is the attempt to extract usage patterns from audit data by data mining techniques. However, existing anomaly-based IDSs are focused on detecting anomalies in logs of use encoded in network protocols. Taking this to the application level, where use is not encoded in a standardized protocol and much more unpredictable, is a very challenging task. Usage patterns from audit logs could form the basis for access control rules. Continuous monitoring and mining of the logs would allow access rules to adapt as the care process evolves. The paper Towards Dynamic Access Control for Healthcare Information Systems suggests a model where audit data, in combination with medical guidelines and knowledge gathered by observation, may be used for more dynamic, process-based, access control in healthcare. Using the audit data in combination with observational data and guidelines enables us to tap into knowledge from three different viewpoints: the user, the system and the idealized version. Combining several viewpoints hopefully leads to a more complete understanding of information access needs. 2.3.3 C3: Access control for Personally Controlled Health Records Three of the papers that are part of this thesis focus on access control issues related to Personally Controlled Health Records (PCHRs). PCHRs may contribute to solving the challenges of information sharing and exchange because the patient is able to take his clinical information with him and decide who gets access. From an access control viewpoint, PCHRs are interesting mainly because the patient is made the administrator of access control. The work presented in these papers was initiated during a six month (February – July) research stay in 2007 at the The Harvard-MIT Division of Health Sciences and Technology (HST) working with the team at the Children’s Hospital 22 Research process and contributions Informatics Program (CHIP)4 that is developing the Indivo5 PCHR. The paper An Initial Model and a Discussion of Access Control in Patient Controlled Health Records presents an overview of issues related to access control in PCHRs. The paper highlights transparency as one of the main concerns for access control in a PCHR. When the patient is administrator it is important that the system is transparent in the sense that the consequences of sharing are obvious and immediate to the patient. The goal is to make sure that the patient is informed when sharing. The paper presents a sketch of a model for access control in a PCHR with a focus on important issues that need further investigation. The paper Personalized Access Control for a Personally Controlled Health Record presents a more detailed model suggesting how these issues may be handled in an access control model for a PCHR. The model is semi-formally defined. Core properties of the model are the two sets of access policies (common and personal) and the definition of policy adaption hierarchies stating how policies may be combined. As a patient could be anybody, very little can be assumed about the user in terms of technical skills, computer literacy etc. Therefore, the usability of the sharing interface (where access rights are assigned) becomes crucial to keep the patient informed about consequences of sharing. The last paper, Visualization for Patient-Administered Access Control: a Usability Study, reports findings from a usability study where three different sharing interfaces for a PCHR were evaluated and compared. The demos were built using a mock-up of the Indivo user interface and the people participating in the testing were familiar with the Indivo system and the PCHR concept. All the demos allowed the user to either select a predefined access policy when sharing or create a new policy, based on an existing one or from scratch. The contents (permissions on information) of the policies were visualized in the interface using different styles in three different demos: list, cube and rainbow. The study resulted in some valuable insights. One particularly interesting thing was that once the patients realized that they could change the policies to fit what they wanted exactly, all of the users almost always did make some changes. Another interesting point that came up is the fact that system-defined access policy templates have a lot of authority. If the users trust the system then they may implicitly trust the suggested policies and assume that they are correct. Therefore, creating these policies is a major responsibility. 4 www.chip.org 5 www.indivohealth.org Chapter 3 Results There is no spoon. (The Matrix) This chapter presents the papers that have been published as part of this PhD project. The papers are presented in groups: section 3.1 presents the papers related to requirements for access control in healthcare, section 3.2 presents the papers on process-based access control, and section 3.3 presents the papers on access control in personally controlled health records. For each paper a short summary is provided, consisting of the original abstract, publication details, author contributions and remarks including any errors discovered after publication. At the end of each section is a brief summation of the combined results and contributions of papers in that group. 24 3.1 Results C1: Requirements for access control in healthcare This section presents papers related to contribution area C1 requirements. 3.1.1 Paper A: Access Control in Healthcare Applications Abstract Healthcare personnel are dependant on access to relevant information to be able to provide the best possible health care for their patients. Designing access control for healthcare information systems is tricky, because of the dynamic nature of the organizations and the tasks performed. Most existing implementations solve this need through the use of access control exception mechanisms: if the normal access control mechanism won’t grant a user legitimate access it is possible to use some exception mechanism to gain access to required information - for example in the case of an emergency. This paper discusses the special needs of access control in healthcare information systems and presents how these needs have been solved, or attempted solved, based on a study of a selection of clinical healthcare systems in use that has resulted in a generalized access control model. Rolebased access control (RBAC) is the common principle for designing these access control mechanisms, and this article concludes with a discussion on how these implementations deviate from the RBAC principle and discusses if RBAC is indeed sufficient to fulfill the requirements of healthcare systems or if we need extensions to RBAC or an entirely new access control principle. Remarks This paper was written very early on. It presents a summary of the author’s understanding of access control in healthcare based on a limited study of existing systems. Author contributions This paper was written entirely by Lillian Røstad. Publication details This paper was published in the proceedings of NOKOBIT 2005 (The Norwegian Conference on Organizations’ use of Information Technology) and presented at the 3.1 Requirements for access control in healthcare 25 NOKOBIT conference in Bergen, Norway in November 2005. 3.1.2 Paper B: A Study of Access Control Requirements for Healthcare Systems Based on Audit Trails from Access Logs Abstract In healthcare, role-based access control systems are often extended with exception mechanisms to ensure access to needed information even when the needs don’t follow the expected patterns. Exception mechanisms increase the threats to patient privacy, and therefore their use should be limited and subject to auditing. We have studied access logs from a hospital EPR system with extensive use of exceptionbased access control. We found that the uses of the exception mechanisms were too frequent and widespread to be considered exceptions. The huge size of the log and the use of predefined or uninformative reasons for access make it infeasible to audit the log for misuse. The informative reasons that were given provided starting points for requirements on how the usage needs should be accomplished without exception-based access. With more structured and fine-grained logging, analysis of access logs could be a very useful tool for learning how to reduce the need for exception-based access. Remarks Some minor errors in the numbers were discovered after publication. They do not affect any of the conclusions, but are presented here for completeness purposes: • In Table 2 the number of users with actualization permission should be 12289, not 12298. • In Table 3 the number of EPRs accessed using emergency access should be 48 not 67. 67 was the total number of emergency accesses. 48 was the number of patients whose records were accessed using emergency access. • In Table 4 the total number of accesses using actualization should be 275762, not 297742. This is due to an error in the query. This means that the average number of accesses of one EPR within one actualization period should be 2.06 and not 2.31. 26 Results Author contributions This paper was written by Lillian Røstad and Ole Edsberg. Røstad wrote the main parts of the paper. Edsberg contributed on data analysis. Publication details This paper was published in the proceedings of the 22nd Annual Computer Security Applications Conference (ACSAC 06), IEEE Computer Society, ISBN 0-7695-27167. The paper was presented at ACSAC in Miami, Florida, December 2006. 3.1.3 Paper C: An extended misuse case notation: Including vulnerabilities and the insider threat Abstract Misuse cases are a useful technique for eliciting and modeling security requirements and threats. In addition they may be very useful in a risk analysis process, particularly as part of the system development process. The original misuse case notation adds inverted use cases to model threats and inverted actors to represent attackers. However, an attack is usually performed by exploiting a vulnerability in a system and it would be useful to be able to represent vulnerable functions in a model. In addition, it should be possible to discern between insiders and outside attackers in a model, as they have very different abilities and potential for attacking a system. This paper therefore proposes an extended misuse case notation that includes the ability to represent vulnerabilities and the insider threat, and discusses the use of this extended notation in the system development and risk analysis processes. Remarks The creation of the notation presented in this paper was motivated by the fact that access control mechanisms in healthcare often includes break-the-glass mechanisms that clearly can be misused. We needed a notation to be able to express the risk represented by these mechanisms. However, the notation has proved useful on a more general basis. Creating misuse cases is an important activity when performing risk analysis of software systems. This extended notation helps highlight what functionality in a system may be misused and makes it easier to link countermeasures directly to the vulnerable functionality. 3.1 Requirements for access control in healthcare 27 Author contributions This paper was written entirely by Lillian Røstad. Publication details This paper was published in the proceedings of REFSQ 2006 (The Twelfth International Working Conference on Requirements Engineering: Foundation for Software Quality) and presented at REFSQ in Luxembourg, June 2006. 3.1.4 Paper D: The iAccess Handbook: A Methodology for Access Control Integration Abstract Health care information about a patient is usually scattered among several clinical systems - potentially more than a hundred separate systems just within one hospital. System integration and interoperability is difficult to achieve, and various strategies for integration exist. However, one topic that has not received much attention is how to integrate system specific security mechanisms such as access control. This paper presents the iAccess handbook, which is a tool to aid this process. It consists of a repository of reference information and a set of methods for collecting information and presenting results, and concerns the legal, organizational and technological aspects of integrated access control for health information systems. The methods have been applied on two separate integration efforts in Norway, which affect ten hospitals in total. Remarks The original five-page paper is included in this thesis. After acceptance the paper had to be reduced to a 2-page summary and resubmitted. The original version is included here because it provides more detail. Author contributions This paper is based on work performed in the iAccess project. iAccess was funded by the The Research Council of Norway and project participants included the Norwegian University of Science and Technology and the independent research organization SINTEF. This paper was co-authored with Per Håkon Meland and Inger Anne Tøndel from SINTEF and Øystein Nytrø. All authors contributed 28 Results equally to the work presented in the paper. The paper was written mainly by Meland, Røstad and Tøndel. Nytrø contributed with comments and refinement of the paper. Publication details This paper was presented as a poster at MedInfo 2007 - 12th World Congress on Health (Medical) Informatics, Brisbane, Australia, August 2007. 3.1.5 Paper E: Access Control and Integration of Health Care Systems: An Experience Report and Future Challenges Abstract Health information about a patient is usually scattered among several clinical systems, which limits the availability of the information. Integration of the most central systems is a possible solution to this problem. In this paper we present one such integration effort, with a focus on how access control is handled in the integrated system. Although this effort has not yet solved all the issues of access control integration, it demonstrates a practical approach for creating something that works today and serves as input to the discussion on future challenges for access control when integrating multiple systems. Remarks This paper illustrates how hard integration of access control is. The effort described here is far from a solution, but serves well as an illustration of a practical approach and to highlight challenges. Author contributions This paper is based on work performed in the iAccess project. iAccess was funded by the The Research Council of Norway and project participants included the Norwegian University of Science and Technology and the independent research organization SINTEF. This paper was co-authored with Per Håkon Meland and Inger Anne Tøndel from SINTEF and Øystein Nytrø. The paper was written mainly by Røstad, Meland and Tøndel. Nytrø contributed with comments and refinement of the paper. 3.1 Requirements for access control in healthcare 29 Publication details This paper was published in the proceedings of The Second International Conference on Availability, Reliability and Security (ARES 2007), IEEE Computer Society, ISBN 0-7695-2775-2. The paper was presented at the Second International Workshop “Dependability Aspects on Data WArehousing and Mining applications” (DAWAM 2007) in conjunction with ARES in Vienna, Austria, April 2007. 3.1.6 Summary of contributions The papers in this group are related to research goal RG1 and contribution area C1 as presented in chapter 1. The contributions of the papers related to access control requirements are twofold: some papers (A, B and E) report on actual requirements for access control while others (C and D) present method for access control elicitation. Very little previous work exists on access control requirements for healthcare. One notable exception is a paper by Evered and Bögeholz [10], but even this paper has a very limited scope, basing the requirements on a study of the use of one healthcare information system in a small aged care facility. The purpose of the paper is to illustrate the complexity of the resulting permissions and constraints even for a relatively simple system and setting. In this project the initial approach was to understand existing healthcare systems; what works well and what does not work about access control mechanism that are implemented and in use. A combination of studies has led to the conclusion that the main problem is that existing access control is enforced as a set of static rules, while the access needs in healthcare are dynamic and unpredictable. The next step in the PhD project therefore was to create methods and models for more dynamic access control that is based on real and realistic requirements in correspondence with research goal RG2. 30 3.2 Results C2: Process-based access control This section presents papers related to contribution area C2 process-based access control. 3.2.1 Paper F: MG-RBAC: Using Medical Guidelines as a Source of Contextual Information to Activate and Deactivate Roles and Permission Abstract Controlling access to information is a key concern in healthcare systems. Some form of Role-Based Access Control (RBAC) is implemented in most healthcare systems. A problem with existing RBAC models used in healthcare is their static nature which doesn’t capture the dynamic needs of healthcare providers. In this paper we propose an enhanced access control mode combining RBAC with the use of Medical Guidelines, MG-RBAC. Medical guidelines contain temporal and contextual information that may be used to make more informed, dynamic access control decisions. Remarks The original four-page paper is included in this thesis. After acceptance the paper had to be reduced to a 2-page summary and resubmitted. The original version is included here because it provides more detail. Author contributions This paper was written entirely by Lillian Røstad. Publication details This paper was accepted for poster presentation at MedInfo 2007 - 12th World Congress on Health (Medical) Informatics, Brisbane, Australia, August 2007. 3.2 Process-based access control 3.2.2 31 Paper G: Towards Dynamic Access Control for Healthcare Information Systems Abstract Access control is a key feature of healthcare information systems to protect the privacy of patients and to ensure access to information as required by healthcare professionals. A problem with many existing access control mechanisms is their static nature. In this paper we propose combining workflow information from medical guidelines, observations and audit logs to create dynamic access rules that are adapted to the actual workings of a hospital. Our aim is to help minimize the use of “break the glass” access. Remarks This paper is important for the thesis in that it proposes future work. Unavailability of the required audit data unfortunately made it impossible to investigate the proposed approach in further detail within the scope of this PhD project. After the MIE conference, we have been invited to submit an extended edition of this paper to be published in the journal Methods of information in Medicine. Author contributions This paper was written by Lillian Røstad and Øystein Nytrø. The main parts of the paper were written by Røstad. Nytrø contributed to the discussion and provided feedback. Publication details This paper was published in the proceedings of The XXIst International Congress of the European Federation for Medical Informatics (MIE), IOS Press 2008, ISBN 978-1-58603-864-9. The paper was presented at MIE 2008 in Gothenburg, Sweden, May 2008. 3.2.3 Summary of contributions The papers in this group are related to research goal RG2 and contribution area C2 as presented in chapter 1. The first paper (F) proposes using context information available in computerized medical guidelines to make access control more dynamic. The limitations of this approach is that there does not exist a complete catalogue of 32 Results computerized medical guidelines and that medical guidelines are idealized versions of treatment processes. As seen in the work on requirements, care processes are unpredictable and often do not conform to any standard. Also, a care process may be very complex and involve several treatment processes. The second paper in this group (G) outlines how several sources of contextual information (guidelines, observations and audit logs) may be combined to be able to predict access needs in a more dynamic, intelligent access control that is able to learn from previous use of the system. A significant amount of work, including, but not limited to [11], [12], [13], exists on combining access control policies and how to refine policies. However, they all take a formalized approach to the problem focusing on how access control policies may be specified in a formal language so as to enable automatic combination and refinement. The approach presented here (paper G) is different in that it is motivated from a usage-based requirements perspective, while previous work focuses on solving a problem from a technical and theoretical viewpoint assuming that the access policies that exist are sound and correct. 3.3 Personally controlled health records 3.3 33 C3: Personally controlled health records This section presents papers related to contribution area C3 personally controlled health records. 3.3.1 Paper H: An Initial Model and a Discussion of Access Control in Patient Controlled Health Records Abstract Health information about a patient is usually kept local to the hospital or clinic where the patient was treated. Patient Controlled Health Records (PCHR) has been proposed as a means to collect all this information and make it available to the patient. In a PCHR the patient is in control and determines who gets access to his health information. In this paper we present a set of usage scenarios to explore the concept of a PCHR. From the scenarios we deduce a set of concerns of relevance when designing an access control model for a PCHR. Finally we outline an initial access control model for a PCHR. Remarks This paper is primarily a discussion paper and serves as background for the next two papers on personally controlled health records. Author contributions This paper was written entirely by Lillian Røstad. Publication details This paper was published in the proceedings of The Third International Conference on Availability, Reliability and Security (ARES 2008), IEEE Computer Society, ISBN 0-7695-3102-4. The paper was presented at The International Workshop on Privacy and Assurance (WPA-2008) in conjunction with ARES in Barcelona, Spain, March 2008. 34 3.3.2 Results Paper I: Personalized Access Control for a Personally Controlled Health Record Abstract Access control is a key feature of healthcare systems. Up until recently most healthcare information systems have been local to a healthcare facility and accessible only to clinicians. Currently there is a move towards making health information more accessible to patients. One means for achieving this is the Personally Controlled Health Record (PCHR) where the patient is in charge of deciding who gets access to the information. This poses new challenges for access control. In the PCHR the patient is the administrator of access control. While it certainly is possible to create roles representing people most patients would want to share with, like primary physician, it is also likely, and desirable, to afford the patients a high level of control and freedom to be able to create specialized access policies tailored to their personal wishes. We entitle this personalized access control. In this paper we present a semi-formal model for how we believe personalized access control may be realised. The model draws on and combines properties and concepts of both Role-Based Access Control (RBAC) and Discretionary Access Control (DAC) to achieve the desired properties. Throughout the paper we use the PCHR as a motivating example and to explain our reasoning and practical use of the model. Remarks This paper presents a semi-formalized model for access control in PCHRs. The presented model addresses key aspects of access in PCHRs and explains how this differs from traditional access control for healthcare. Author contributions This paper was written by Lillian Røstad and Øystein Nytrø. The main parts of the paper were written by Røstad. Nytrø contributed to the discussion and provided feedback. Publication details This paper was published in the proceedings of the 2nd ACM Computer Security Architecture Workshop (CSAW). The paper was presented at CSAW (in conjunction with 15th ACM Conference on Computers and Communication Security) at George Mason University in Fairfax, Virginia on October 31st 2008. 3.3 Personally controlled health records 3.3.3 35 Paper J: Patient-Administered Access Control: a Usability Study Abstract Patient-Controlled Health Records (PCHRs) allow patients complete control over their health information. They decide who to share their information with, which makes the patient the administrator of access control. While PCHRs have a great potential for patient empowerment, they have an equally great risk for breach of privacy if consequences of sharing are not completely clear to the patient. This paper presents results from a usability evaluation study that compares three different visual interfaces for sharing in a PCHR. The goal of this study was to investigate how users understand and react to the concept of sharing. The study found that when given the opportunity to do so the users wanted to exercise detailed control. The study also indicated that defined templates for sharing in a PCHR has a lot of authority as users assume them to be created by experts and therefore “correct”. Remarks This paper is included in its final version to be published by IEEE in the proceedings of SECUSAB. Publication details This paper has been accepted for publication and will be presented at the International Workshop and Usability (SECUSAB 2009) in conjunction with ARES 2009 taking place in Fukuoka, Japan, March 2009. The workshop proceedings is published by IEEE. Author contributions This paper was written by Lillian Røstad and Ole Andreas Alsos. Alsos contributed on study design and interpretation of results. 3.3.4 Summary of contributions The papers in this group are related to both research goals (RG1 and RG2) and contribution area C3 as presented in chapter 1. As such, this group of papers is parallel to both the other groups as it incorporates both requirements and proposed models. The papers are presented in a separate group because personally controlled 36 Results health records, which are primarily a tool for, and controlled by, the patient is so different from healthcare systems made for clinicians in terms of access control requirements. The personally controlled health record (PCHR) is a relatively new concept and previous research [14] has not focused on access control. In the context of this thesis a model (paper I and J) has been proposed for access control in a PCHR. However, as PCHRs are not common in use yet, the requirements basis for this model is limited and it should be expected to evolve as PCHRs are taken into use and more information on access control experiences and requirements becomes available. As the viewpoint of this thesis is on access control from the user side, it became clear that the main challenge for access control in a PCHR is how to ensure that the patient is aware of the consequences when sharing sensitive health data. The final paper of this thesis (J) reports on findings from a usability study exploring patients’ reactions when faced with the opportunity to decide what to share and with whom. The most important feedback from this study is that the users perceived the system as having a lot of authority. If a suggestion was made by the system for what to share, the users usually assumed that the system was right. This implies that policies, or policy templates, for PCHRs need to be very carefully designed. Chapter 4 Discussion “If you can keep your head when all about you are losing theirs, it’s quite possible you haven’t grasped the situation.” (Jane Seabrook, www.furrylogicbooks.com) The studies performed within this PhD project have been many and diverse, but limited in scope and number of participants. Rather than studying access control in healthcare in-depth from one viewpoint, several approaches have been attempted. This has been intentional and has served the purpose of providing a broader, more complete overview. A more focused, or narrow, approach may have led to more detailed knowledge and results, but it would have been at the risk of not exploring other angles that could be valuable. This discussion focuses on exploring the validity of results presented in this thesis, based on the apparent limitations present. Results in each of the main contribution areas are discussed with respect to validity in terms of: • Reliability and completeness - these terms are used to discuss confidence in that the results are reproducible, correctly interpreted and to what extent the results cover all relevant aspects of access control in healthcare. • Flexibility, extensibility, scalability - these terms are often used to discuss favorable properties of access control models. In this context flexibility of a model means that the model adapts well to changes in e.g. the organization that affects the premises for access control, extensibility is related to the ability to add to the model e.g. by adding new roles or policies and scalability is concerned with the model’s ability to adapt to changes in the size of the user base. • Generalizability - this term is concerned with the extent to which results 38 Discussion RG1: requirements C1: requirements C2: process-based access control RG2: models C3: PCHR Figure 4.1: Research goals related to contributions from this project are also applicable in a broader context - be it a wider range of healthcare systems or even in other domains with similar properties as healthcare. Figure 4.1 illustrates how the research goals are related to the contribution areas. The goal related to discovering requirements is clearly related to the requirements contribution area, but also to the PCHR contributions that include discussion on requirements for a model for access control in a PCHR. The contribution areas PCHR and process-based access control both include new, proposed models for access control and are therefore related to research goal RG2. Figure 4.1 shows that there is a close connection between the research goals and contributions, as there should be and which indicates that the goals of the project have been met. The remainder of this chapter discusses the validity of results and contributions in more details. 4.1 C1: Requirements for access control in healthcare Reliability and completeness The requirements discovered within this project are by no means a complete set of requirements for access control in healthcare. Healthcare systems are so many, and diverse, that it is unrealistic to map even every common requirement within the limited scope of a PhD project. However, the studies performed in this project have the advantage of approaching the problem from several viewpoints (observation, user experiences, traces of user actions in audit logs), supporting the claim that the deduced requirements are reliable, and valid for healthcare as a whole, if not necessarily complete. Compared to previous, published work, the results presented 4.2 C2: Process-based access control 39 here on access control requirements for healthcare are substantial in content and effort. Flexibility, extensibility and scalability As stated, the requirements identified within this thesis is not a complete set and therefore it is fundamental that it is possible to add onto this base. No limitations or conditions have been placed on the requirements set. Generalizability Healthcare systems, and the context they need to function in, are complex and ever-changing and at the same time have to be secure in terms of protecting privacy, integrity and availability of data. It may be argued that healthcare as a study subject for access control is so complex that any solutions created that works for healthcare will have a high likelihood to also be satisfactory for other, similar, but expectedly less complex, application domains. This is a claim however, that though reasonable, is not verified within this thesis. 4.2 C2: Process-based access control Reliability and completeness The main conclusion from the requirements work is that access control for healthcare needs to be tailored to the dynamic, unpredictable care process. A suggestion on how to do this is proposed in paper G “Towards Dynamic Access Control for Healthcare information Systems”. However, there was not time within the project to verify this proposed model. It is clear that the model is not complete as is, but represents a promising starting point for future work. Flexibility, extensibility and scalability As the model is only described superficially, few limitations are placed on how it may evolve. It is however, as seen from the requirements work, important in itself that the model is flexible, extensible and scalable even in a more developed state to be suitable for healthcare. The very problem with existing methods for access control is their complete lack of these properties. 40 Discussion Generalizability The proposed model for process-based access control is general in some aspects and not in others. One of the suggested information sources, medical guidelines, is specific to healthcare and thus is not directly transferable. However, it is likely the case that in other domains there exist other types of guidelines that can be used. As healthcare is very unpredictable it may even be the case that in other domains there exist guidelines that may be more usable for access control in that they are more often applicable, and the processes are more predictable. The conceptual model of having process-based access control using several information sources to predict access needs should be transferable to many other domains where users cooperate on tasks. 4.3 C3: Personally controlled health records Reliability and completeness Personally controlled health records are, as mentioned, a relatively new concept. It is therefore unrealistic to believe that the requirements and models presented in this thesis are complete. However, they are based on knowledge from the most experienced people working on PCHRs and as such should represent a good starting point. Flexibility, extensibility and scalability The proposed model is based on the role-based access control (RBAC) concepts and many attributes and features are borrowed, or extended, from RBAC. Extensibility and scalability are among the most commonly argued attributes of RBAC. In the proposed access control model for a PCHR these features of RBAC are reflected. Specifically the model is designed to handle an increasing number of policies. Generalizability PCHR is a new, and in many aspects, a unique concept. However, it is becoming increasingly common for people to be members of online applications containing personal data, e.g. Facebook and PatientsLikeMe.com, where they decide what they want to be visible to whom. The challenges and principles for access control in a PCHR should be transferable to that of social communities on the web. Chapter 5 Concluding remarks “Security is the art of making sure certain things does not happen. A thankless task, because when something doesn’t happen, there will always be someone who claims that the security measures were exaggerated and unnecessary.” (Salman Rushdie) This thesis consists of a total of ten scientific papers. The papers range in focus from requirements engineering for access control, to proposed models based on those requirements. This PhD project started out with a narrow focus on creating dynamic, contextaware access control models for healthcare. Upon realizing that we did not have the knowledge to create meaningful models the scope was widened and the focus shifted from creating solutions to gaining a better understanding of the problem. As a result the main contributions of this PhD project are on knowledge about how existing access mechanisms function, what works well and what could be improved. Studies performed in this project indicate that access control in healthcare should be more dynamic and adaptable to be able to support the unpredictable, dynamic and individual care process. The results suggest that a step towards dynamic access control would be to utilize contextual knowledge, such as medical guidelines and audit data, to allow access rules to change as the context changes. The consequence of focusing on requirements elicitation, and taking a broad approach, is that while some access control models have been suggested they are not complete and need more work and refinement both on the requirements as well as on the models. Therefore directions for future work is an important contribution from this project. 42 Concluding remarks 5.1 Future work There are two main directions for future work based on the findings presented in this thesis: process-based access control and access control for personally controlled health records. Process based access control The work on access control requirements for healthcare has resulted in a proposed model that suggests using knowledge in the form of observations, medical guidelines and mining of audit logs in access control. A logical next step would be to create a more detailed model and implement a proof-of-concept that could be used for evaluation purposes. However, before this can be done work remains on how to extract, represent and combine this knowledge. In particular, further work should focus on: • Extracting usage patterns: Data mining of logs to extract usage patterns is a non-trivial task. A precondition for performing this work is the availability of sufficiently large amounts of high-quality log data. High-quality in this context means that the logs contain sufficiently detailed information to construct meaningful usage patterns. Usage patterns may be simple or more complex and may include information on location, responsibility and roles of the present users, time and situation. It is necessary to perform research on a large corpus of data to gain knowledge on the structure and composition of meaningful usage patterns. • Rules for creating permissions: That a usage pattern is common does not necessarily mean that it should be included as an access rule. Likewise, that an event is uncommon does not necessarily imply that it should be disallowed. Studies and experiments should be performed to create rules for when a usage pattern is a candidate for an access control rule. • Misuse detection: Usage patterns may also be used to create applicationlevel Intrusion Detection Systems (IDS) for healthcare. Realizing that mechanisms to override access control will always exist in healthcare systems to handle emergencies means accepting that there will always be a need for retrospective access control. An IDS is a system that helps automate the process of misuse detection. An IDS is either based on signatures of known attacks, or on learning common usages. Misuse is suspected when there are deviations from normal use, represented by the usage patterns. 5.1 Future work 43 Access control for PCHRs A model for access control in PCHRs has been proposed, but this model requires further refinement. Also, a model is only useful if it gets implemented and evaluated which is the next logical step. But a correctly implemented model is not sufficient for access control in a PCHR. Further studies should focus on: • Usability: As the patient becomes the administrator, the usability of the systems in the way it communicates consequences to the user is important. Further usability studies and tests on the sharing interface and how the users respond to that should be performed to realize the potential for patient empowerment in a PCHR. • Common policies: A very interesting comment made in the usability study performed in this PhD project was on how the user perceived the authority of any suggestions made by the system. If the system suggests an access profile it seems likely that users will trust the system and accept that suggestion without any closer examination. It would be interesting to confirm if this is true and explore the consequences. Should there be common policies or not? • Creating common policies based on the most common personal policies: Granting users the power to create their own access profiles means that over time we get a collection of access profiles representing who users share with and what they share. This dataset could be used to create better common profiles that are based on actual use rather than assumptions. 44 Concluding remarks References [1] Nou 1997:2 pasienten først (the patient first). Technical report, Ministry of Health and Care Services, 1997. [2] D. Povey. Optimistic security: a new access control paradigm. Proceedings of the 1999 workshop on New security paradigms. ACM Press, Caledon Hills, Ontario, Canada, 2000. ISBN: 1581131496. [3] “The Health Personnel Act,” Ministry of Health and Care Services, 1999, http://www.lovdata.no; Last accessed October 6th, 2008. [4] “The Personal Data Act,” Ministry of Justice and The Police, 2001, http: //www.lovdata.no; Last accessed October 6th, 2008. [5] “The Personal Health Data Filing System Act,” Ministry of Health and Care Services, 2002, http://www.lovdata.no; Last accessed October 6th, 2008 [6] R. Shirley, “RFC4949 Internet Security Glossary, Version 2,” Internet Engineering Task Force, August. 2007, http://tools.ietf.org/html/rfc4949; Last accessed October 3rd, 2008. [7] European Comittee for Standardisation (CEN), “Health informatics – System of concepts to support Continuity of care – Part 1: Basic Concepts,” European Standard 13940-1, March 2005. [8] D.E. Denning, “An Intrusion-Detection Model,” IEEE Transactions on Software Engineering, vol. 13, issue 2, p. 222-232, ISSN: 0098-5589, February 1987. [9] W. Lee and S. Stolfo, “Data Mining Approaches for Intrusion Detection,” Proceedings of the 7th Usenix Security Symposium, 1998. [10] M. Evered and S. Bögeholz, “A case study in access control requirements for a Health Information System,” ACSW Frontiers ’04: Proceedings of the second workshop on Australasian information security, Data Mining and Web Intelligence, and Software Internationalisation, p. 53-61, Australian Computer Society, Inc., 2004. 46 References [11] P. Bonatti and S. De Capitani di Vimercati and P. Samarati, “An algebra for composing access control policies,” ACM Transactions Information Systems Security, vol. 5, issue 1, p. 1-35, ISSN: 1094-9224, 2002. [12] V.G. Bharadwaj and J.S. Baras, “Towards Automated Negotiation of Access Control Policies,” Fourth IEEE International Workshop on Policies for Distributed Systems and Networks (POLICY’03), p. 111, IEEE, 2003. [13] D. J. Dougherty and K. Fisler and S. Krishnamurthi , “Specifying and reasoning about dynamic access-control policies,” Lecture Notes in Computer Science, p. 632–646, Springer, 2006. [14] K. D. Mandl, P. Szolovits, and I. S. Kohane. Public standards and patients’ control: how to keep electronic medical records accessible but private commentary: Open approaches to electronic patient records commentary: A patient’s viewpoint. BMJ, 322(7281):283–287, 2001. Part II Papers Paper A Access Control in Healthcare Applications 50 Paper A Paper A: Access Control in Healthcare Applications 51 Access Control in Healthcare Applications Lillian Røstad Norges teknisk-naturvitenskapelige universitet (NTNU) Sem Sælands vei 7-9 7491 Trondheim [email protected] http://www.idi.ntnu.no/~lilliaro Abstract Healthcare personnel are dependant on access to relevant information to be able to provide the best possible health care for their patients. Designing access control for healthcare information systems is tricky, because of the dynamic nature of the organizations and the tasks performed. Most existing implementations solve this need through the use of access control exception mechanisms: if the normal access control mechanism won’t grant a user legitimate access it is possible to use some exception mechanism to gain access to required information - for example in the case of an emergency. This paper discusses the special needs of access control in healthcare information systems and presents how these needs have been solved, or attempted solved, based on a study of a selection of clinical healthcare systems in use that has resulted in a generalized access control model. Role-based access control (RBAC) is the common principle for designing these access control mechanisms, and this article concludes with a discussion on how these implementations deviate from the RBAC principle and discusses if RBAC is indeed sufficient to fulfill the requirements of healthcare systems or if we need extensions to RBAC or an entirely new access control principle. Introduction Access control is the process of determining which users are allowed to perform what operations on which objects in a computer system. Healthcare information systems contain sensitive information about patients that is vital in the treatment process. As such access control in the healthcare sector is about protecting the patient’s right to privacy, while ensuring that healthcare personnel get access to the right information at the right time in order to be able to provide the best possible treatment for their patients. Healthcare is one of the most information intensive sectors in the society. As more and more of the clinical information about a patient is recorded in information systems, it becomes increasingly important to have sound and sufficient mechanisms for providing and restricting access to this information. The old paper-based record is becoming a thing of the past, and as all this information about a patient is being transferred into digital and networked systems the risk scenario changes. Earlier, in order to gain access to information, one had to physically locate where the information could be found and track down the actual papers. Now this is only a matter of searching through a database of available information. Adding to this the fact that digital information can be easily 52 Paper A multiplied and transferred while papers have to be copied one by one - the potential for privacy breaches has definitely increased. This potential for much easier access, and also replication, has lead to an increased focus on information security in healthcare. Access control is at the heart of this focus as it is the key issue to be able to protect and make efficient use of this vast amount of digitally stored sensitive information. Access control has two different dimensions that sometimes are in conflict. While the primary objective for applying access control is restricting access to information and functions, usability is an equally important feature. Access control designers need to understand how the organization functions as well as the access requirements of the system users. The result of applying too strict, or simply wrong, access control mechanisms will be users finding other ways of obtaining the information they need. Access control mechanisms implemented in health care information systems today has not proven entirely successful on the usability aspect, namely to support the working procedures of healthcare personnel. As a result, they have had to rely on allowing exceptions from the normal access control mechanisms to be able to satisfy the needs of their users. From an information security point of view exceptions are bad because it results in loss of control over information flow. The goal of the work described here is to study existing mechanisms, and comparing them with the standards the claim to comply with, in order to gain knowledge that may help in designing an improved access control model for healthcare applications. Access control implementation in healthcare applications The information about implemented access control mechanisms presented her is based on a study of access control mechanisms in a variety of clinical healthcare information systems. Although the specific details of implementation and chosen technologies may differ, they all have a lot in common. These common traits can be summarized in a generalized access control model for healthcare that is visualized in Figure 2. This model, forms the basis for our discussion. Before moving on we will explain the model in detail. THE GENERALIZED ACCESS CONTROL MODEL FOR HEALTHCARE All the systems that have been studied have the one thing in common that they claim to support role-based access control (RBAC). A majority of the systems have chosen an approach based on the concepts of roles and responsibilities in combination with contextual information like place of work. The underlying assumption is that any specific healthcare profession has a well-defined set of responsibilities and should be able to perform these responsibilities for patients currently under their supervision - namely patients admitted to the ward that is their primary place of work. In other words role is equal to healthcare profession and each hospital has a list of possible roles and in each separate healthcare information system this role is mapped to the related permissions. Paper A: Access Control in Healthcare Applications 53 ROLE Wards registered in Professions/job function Permissions (systems) Human Relation (HR) System Patient Management (PM) System user profession/job function and place of work patient admitted to Healthcare Information (HI) System Permissions assigned User (hospital employee) registered in Role-related (normal) Identityrelated (exception) on on Information owns Patient Figure 1 - This figure illustrates the generalized access control model for healthcare information systems. This list of roles may also include non-healthcare professionals that are employed at a hospital, like secretaries. Information is associated with a patient, meaning that for an employee to have access to information about a patient in accordance with his/her role, the patient has to be admitted, and registered, to the ward at which he/she is currently employed. The information needed to construct permissions for a user is typically retrieved from the human-relations (HR) system that contains information about job position and place of work for a user, and combined with information about the patient’s current location in the hospital from the patient-management (PM) system. Note that while role and place of work are system-independent properties registered externally, the permissions for a role in a specific system is enforced by the system itself, utilizing this external information, and may vary from one system to another. Notice also that in the figure a role is associated with organizational-level permissions in addition to specific permissions within one healthcare information (HI) system. These permissions determine which systems users associated with this role will be able to log on to. Typically, only systems in this list for a particular role will be available in a customized desktop for users assigned to this role. One other thing worth noting is the division of system-specific permission in those related to role and those related directly to the user’s identity. Rolerelated permissions is part of what we may call the normal access control mechanism - 54 Paper A this is supposed to handle most access requests. The exception access permissions have been added to deal with access in emergency and unexpected situations. Exception access permissions are linked directly to identity because only a small and manageable number of users should have this permission as allowing exceptions raises the level of risk for privacy breaches. We will now move on to explain the functioning of this generalized model in more detail through examining access control administration and the use of exceptions. The use of exceptions is a key issue as it illustrates the shortcomings of the generalized model for access control in healthcare. ACCESS CONTROL ADMINISTRATION Access control administration is about assigning and withdrawing permissions for authorized users. Administering access control in the generalized model for healthcare have two aspects: administering access rights (role, place of work, permissions) for users and tracking patients. There are generally five events that trigger the need for manual administration of access control related information: • Hiring a new employee. • An employee changing job function and/or place of work. • An employee quitting. • A patient being admitted to a ward. • A patient being transferred from a ward. Access right administration today is largely a manual process governed by the filling-out, signing and filing of specific forms. For example, to assign permissions to a newly-hired employee, the manager of the ward where the employee is going to work fills out and signs a form stating the job function (role) and name of the ward. This form also contains information about assigning the user exception access rights in specific systems, if any. The form is then sent to the IT-department where the information is entered into the HR system. Through this process the user is granted access to a set of systems that are part of the permissions for his/her role. The information from the HR system will then be used by each of these systems to determine what the user should be allowed to see and do in each particular system. If an existing employee changes job function or place of work, this triggers the filling-out and filing of another form equal to the first one. At any time the most current form is the one used by the IT-department for entering access rights. This form has a from-date and a to-date, and what happens when an employee is quitting is that the to-date is filled in and the form re-signed. Setting the to-date in the HR system means deactivating access to all systems for this user. As for patient tracking, information about planned patient admissions are received from the patient’s primary physician and the date and ward of the patient’s expected arrival entered into the PM system. When the patient is discharged a letter summarizing the treatment and results is sent to the patient’s primary physician and this triggers the setting of an admission date in the PM-system. Setting the admission date means cutting of access to information about this patient. All this sounds fairly simple, even if work-consuming. However, there are some complications: • A lot of the times a patient’s arrival is not planned. Patients often get admitted due to minor or major acute emergencies. These patients are not registered in the PM system at Paper A: Access Control in Healthcare Applications 55 the time treatment begins. Often, in case of minor injuries, the patient has already been discharged when the information is finally entered into the PM system. • Sometimes information flow where patient’s do not, for example in the case of lab tests, or one doctor requesting a second opinion from another doctor. • It is not practical to close access to information about a patient immediately when he or she gets discharged or transferred to another ward. As mentioned earlier there may still be information that need to be documented after the patient have departed - for example test results or notes in the patient record about treatment and observations. Documentation is often done, or completed, post-treatment. • It is not practical to simply close access when an employee quits - the responsibilities of this employee need to be transferred to someone else first. In order to be able to handle these complicating situations, and other unexpected situations, the base access control philosophy for healthcare systems has been extended with the ability to handle exceptions from normal or predicted treatment and information flow. As a result, while in most information systems there are only two possible outcomes of an access request (granted or denied), in healthcare systems there are four possible outcomes: • Normal access granted. • Normal access denied. • Exception access granted (normal access denied). • Access denied. Normal access here means the built-in access control policy of a system that is meant to handle most access request. When an employee has a legitimate need for access to information, but the normal access control mechanism denies access due to some complications described earlier, exception access may be utilized. However, often there exists information about patients that is considered extra-sensitive and that therefore even exception access cannot be used to access. Examples of such information are psychiatry records. Therefore access denied is always a possible outcome of an access request. Access control exceptions have been added as a response to specific needs, with little regard to the effect on the overall access control model or policy of a system. The result is a generalized model that is not directly based on one access control principle, but is a combination of several strategies. This adds to the complexity and difficulty of having an overview of which users have what access rights at any given time as permissions is not only linked to role but also directly to identity. Exception access is powerful concept that may result in broad access rights and to gain knowledge about what a specific user has actually had access to, one need to examine each separate use of exception access. Understanding why exceptions are necessary is the key to understanding the improvement potential for access control in healthcare, and we will therefore examine what triggers the use of exceptions in more detail. ACCESS CONTROL EXCEPTIONS Exception mechanisms were initially designed to handle access in emergency situations thereby dealing with unexpected, but legitimate, access requests. Realizing that emergency situations do occur in healthcare, the access control designers constructed a mechanism to handle this called blue-light access. This permission was not related to jobfunction/role, but was designed as a special permission linked directly to a specific user. 56 Paper A The reasoning for this was that only a limited number of users should be assigned this access, and they should be selected on a personal basis not just based on profession. It should also be possible to trace the use of blue light on an identity basis. Typically only a few persons at a ward have this permission. Blue light access was only supposed to be used in emergencies, when a patient arrives and there is no time for the time-consuming process of registering the information necessary for access control to function. But as the access control designers realized that blue light access may be misused, they added some extra security measures. The measures may vary slightly from one system to another, but the most common ones include: • Requiring the user to re-enter his/her password. • Requiring the user to provide a reason for using blue light access. • The use of blue light access grants access only to a smaller to subset of the available information about a patient, not the entire patient record. To gain access to other parts of the record, the user has to use blue light access again. • Enforcing time-constraints - information accessed using blue light will only remain accessible for the user for a short time period, defined by the organization. Re-gaining access requires yet another use of blue-light access. • The use of blue light access triggers extensive auditing of the users access from that point on. The purpose of these measures is to raise the user’s awareness that the mechanism is indeed only meant to be used in emergency situations. Making the mechanism less easy to use also reduces the risk for unintended use. This is important because this mechanism is essentially a built-in backdoor mechanism. It can be misused. The purpose of extensive auditing is twofold: as a preventive measure by letting users know that all their actions are traceable, but also as a means of controlling and being able to detect if the mechanism is misused. If blue light is misused the audit logs provides the evidence needed to take the appropriate actions, Blue light was only intended as a mechanism for handling access in emergency situations. However, as pointed out in the previous section, there are a number of other situations where the normal access control mechanism fails. The most common examples are referrals, second opinions - generally un-planned treatments. And it turns out (surprisingly - for the developers) that a major part of treatment at a hospital is unplanned. In fact at some hospital wards most admissions are not planned. As we have seen, planning is a crucial for the normal access control mechanism to function as patient’s need to be registered in the system, and linked to the right ward, in order for health care personnel to be allowed to access their information. As this is often not the case, there are situations when exception access needs to be used although the situation is not really an emergency. In some systems blue light access is used also in these situations. However, some other systems have constructed yet another exception access mechanism to be able to handle these situations. This exception access mechanism is quite similar to blue light access, an a lot of the same prevention and detection mechanism are used. The main difference is that while blue light is only meant to be used in specific (emergency) situation that will always occur at hospitals and need to be handled, the general exception mechanism was constructed to handle all access that are legitimate and normal from a user’s point of view, but that the normal access control mechanism of the system is not able to handle. Some other differences between blue light and the generic exception mechanism is: Paper A: Access Control in Healthcare Applications 57 • Exception access is also assigned directly to users, not through roles, but generally exception access is assigned to quite a few more users than blue light access is. • Exception access generally results in access to a broader set of information - often the entire patient record, and often for a longer time period than blue-light access. Blue light access is only meant as a temporary mechanism because the normal one takes time to function due to all the manual updating required. Exception access may be used in situations where normal access is never expected to function - like entering information in a patient’s record at a lab the patient never visits himself. • As the hospitals have identified the most common reasons for using exception access, they have often constructed a drop-down list of common reasons, and associated time intervals, that the users may choose from when activating blue light access. The reason is to make the mechanism easier to use, which one may argue against from a security viewpoint but this is mainly a result of usability requirements. One may also discuss whether the users then will provide the correct reason, or simply the first one in the drop down list - or the one with the longest time interval for convenience reasons. Constructing this exception access mechanism may be considered as admitting defeat for the access control designers. It was invented in a realization that the normal access control mechanism is not capable of handling all normal access. CONCERNS But is this a good, long-term solution? Shouldn’t the main/normal access control model be able to handle all access requests? Figure 3 illustrates the use of access control mechanisms in three different situations that requires the use of both normal, blue light and exception access. 58 Paper A Planned admission Normal access includes Legitimate read in EPR Doctor A Unplanned transfer Exception access includes Legitimate read in EPR Patient includes Emergency admission Blue light access includes Doctor B includes Provide reason/ password prevents prevents Illegitimate read in EPR Awareness detects Doctor C Auditing Figure 2 - This figure illustrates the three kinds of access and potential for misuse related to reading a patient's electronic patient record (EPR). The figure is a combination of use-case and misuse-case where the left-hand side represents three different situations and the right-hand side illustrates actions taken by doctors when reading the patient’s electronic patient record (EPR) in response to the situation on the left-hand side. The notation of misuse-cases is defined in (Sindre and Opdahl, 2005). The notation used here has some slight extensions. All white elements are ordinary use-case elements with their ordinary meaning. The includes-relationship means one use-case relying one another to perform its task. The black figures and the prevents and detects relationships are part of the misuse-case definition. Black elements symbolizes illegal or unwanted actions - in this context that means intentional illegitimate access by users, i.e. users accessing information without any medical reason or responsibility that justifies doing so. This is a potential consequence of blue-light and exception access that we want to avoid. The grey elements are not part of any published definition. They are used here to visualize the grey-zone areas of using exception access to perform legitimate access. As the figure shows, there is the possibility of a user (doctor B - the grey one) unintentionally obtaining illegitimate access. This may be due to share ignorance - the doctor simply does not know that what he is doing is wrong, for example accessing the EPR of a patient simply because he/she has heard from another doctor that it is an interesting case. This is not allowed according to the policy for normal access control that defines that there should be a relationship, in the form of a common organizational location, between a patient and a doctor for the doctor to be allowed access. The result is violating the patient’s privacy rights, the hospital policy and probably also the country’s laws and regulations - even if it was not deliberately. This illustrates how the introduction of exception access mechanisms increases the importance of awareness-raising measures. Responsibility for privacy-protection is shifted from the Paper A: Access Control in Healthcare Applications 59 system to the users. Making sure that everybody knows when exception access may and may not be used, and are aware of the possible penalties is an important preventive measure. The users need to be made aware, and reminded, of how the system is allowed to be used - and also what not to do. From a security point of view exceptions is a bad thing. Exceptions means loosing control of information flow. Exceptions mean unexpected behavior. Security is about having control and as such exceptions are bad. That said exceptions in the form of emergency access probably will always be part of access control for healthcare. Emergencies are a unique feature of this sector. But one should aim at minimizing the need for exceptions. And any required exceptions should be handled as part of the standard access control mechanism, to allow maximum possible control. It is probably not possible to not have exceptions at all - but a better suited access control model would minimize the need for using exceptions (leaving only emergencies). The remainder of this paper examines if the requirements of healthcare systems discussed here could be implemented through an access control mechanism based solely on the RBAC principle, without the need for exceptions or with support for handling exceptions incorporated into the model, not as an add-on. Rbac in healthcare: theory versus practice Role-based access control (RBAC) is considered to be state of the art for access control in healthcare systems today as we have seen. The generalized access control model for healthcare presented in this paper uses a variant of roles as part of its foundation. Before we can compare the generalized model with RBAC we need to take a closer look at the RBAC principle. KEY CONCEPTS OF ROLE-BASED ACCESS CONTROL (RBAC) The concept of RBAC was formalized in the paper Role-based access control (Farraiolo and Kuhn, 1992). The key concept in RBAC is to define roles that correspond to job titles and responsibilities within an organization. Each role is associated with a set of access rights. Employees holding the same job within an organization are assigned to the same role - thus the number of roles is considerably lower than the number of employees in an organization. As RBAC evolved from the original proposition into being implemented in commercial systems, the need for standardization arose. Different vendors started implementing RBAC in their security products, but there was no common understanding of what the main RBAC features are, and how they should be implemented. (Essmayr, Probst and Weippl, 2004) gives a thorough overview of RBAC implementation in commercial systems today. Having a common standard to use as a base specification is important to enable interoperability of the different implemented solutions. In response to this need the National Institute of Standards and Technology (www.nist.gov) in USA proposed a standard (Ferraiolo, 2001) for RBAC. The RBAC standard presents the core RBAC model, which encompasses the most important RBAC features. Figure 4 presents an overview of the core RBAC model. 60 Paper A Figure 3 - Core RBAC model. A permission is a set of allowed operations on objects. An object may be an information element or a Fig. 4. The core RBAC model - adapted from the NIST RBAC standard resource in a computerized system. A role is associated with a set of permissions. Users are assigned a set of (one or more) roles, and hence the access rights for one user are defined by the set of roles currently assigned to that user. In addition the core RBAC model uses the term session. The set of roles assigned to a user through the User Assignment (UA), defines the total set of roles a user can possibly have at any given time this is a static relationship. However, all of these roles are not necessarily activated at one single time. The relationship between users and sessions and sessions and roles indicates that in any given session a subset of the total possible set of roles for a user may be activated. That means that in a session the user may be assigned to the total number of possible roles for him/her, or only a subset. In addition to the core RBAC model, the standard defines rules for separation of duty and the concept of role hierarchies and inheritance relationships. The purpose of separation of duty is to enable constraint enforcement, and maintain role-role relationships and interdependencies. Some roles may contain conflicting permissions, meaning that it should not be possible for the user to be assigned to both roles simultaneously. For this purpose, the RBAC standard defines two mechanisms for separation of duty: • Static separation of duty (SSD) - enforces constraints on which roles may not at the same time be part of the static set of roles for any user. • Dynamic separation of Duty (DSD) - enforces constraints on which roles may not be activated simultaneously in one session. A role hierarchy in the RBAC standard reflects how the level of access rights corresponds to the level of responsibility within an organization. The roles at the top pf the hierarchy contain the most access right and the level of access decreases as one traverse the hierarchy downwards. Role hierarchies also enable the specification of role specialization. A specialization of a role means that one role inherits all the permissions of its predecessor, with added extra permissions. For example one may define a hierarchy where the parent role is named secretary and contains permissions to perform all the tasks that is normally part of a secretary’s job, and the roles secretary-sales and secretary-legal inherits all the permissions of the secretary role, but in addition contains permissions that are specific for these kinds of secretaries. RBAC IN HEALTHCARE Paper A: Access Control in Healthcare Applications 61 RBAC is considered to be suitable for healthcare as it is designed specifically for commercial applications serving organizations with a high number of employees, but relatively smaller number of job functions (”roles”) and where flexibility and scalability of the access control mechanism is key requirements. Why is it then that access control mechanisms implemented for healthcare systems, claiming to provide role-based access control fail? This question is investigated further in the next section by comparing the main shortcomings of existing access control mechanisms for healthcare identified earlier, with the capabilities of the core RBAC model. Healthcare access control requirements mapped to RBAC The main problems with the generalized access control model for healthcare is it’s inability to adapt to changes. The model is designed with a static basis and relies on manual procedures for update. In order to add flexibility exception mechanisms have been added. This results in shifting responsibility for information protection and privacy to the users of the system. The generalized access control model is centered around entities (users, patients, organizational units) while in fact work performed in the health sector is process-oriented and dynamic in its nature. The generalized access control model for healthcare consists of two main parts: normal and exception access. We will examine and compare each mechanism separately to se how or if it relates to the RBAC standard, before examining the possibility of combining the two in one RBAC-based model. Normal access mapped to RBAC We first compare aspects of the normal access mechanism to RBAC: • The set of roles is flat - no hierarchy, no inheritance. • No inter-role dependencies are defined, so separation of duty constraints specified. • A user may only be assigned to one role. No set of roles, no activation of roles in sessions. • A list of permissions is associated with each role - on a top level (permissions for access to systems) and in each separate system (permissions for information in a system). To conclude the normal access control maps to RBAC in its simplest form. It does conform to the principle of relating roles to permissions, and users to role, thereby benefiting from the ease of administration due to only having to assign a pre-defined role to a new user instead of having to construct a new set of permissions for each user. Exception access mapped to RBAC Exception access in the generalized model is not realized as roles. The reason for this is the need to be able to restrict these permissions to small set of users, and the roles defines ad part of the normal access control are to few and to broad in their definition thereby encompassing too many users. A generalized RBAC model for healthcare 62 Paper A Keeping the key concepts and taking advantage of all the features of RBAC as defined in the standard (Ferraiolo, 2001), the generalized access control model based on RBAC for healthcare could be constructed by: • Adding the concept of role sets - allowing a user to have multiple roles. • Adding the concept of sessions would allow only a subset of roles to be activated in a session – this could be used to handle a user having several places of work. Only roles related to the currently active (this information could be retrieved from the roster) place of work would be activated in a session. • Role sets also enable the definition of very specific roles that is only assigned to some users. Instead of adding permissions directly, these users would have an extra role in their set for handling exceptions. This explains how the generalized model can be easily transformed to be entirely based on RBAC. But is this an improvement? Would it be perceived by users as an improved access control mechanism? Is it an improvement for the designers? For security people? Or should the entire model be re-designed? Limitations of RBAC for healthcare The main problem of the exception mechanisms in the general model is that they are used for handling a variety of situations. Simply mapping the exception mechanism to RBAC does not solve the real problem. Our goal is to minimize the need for exceptions. In short we need to extend the normal part of the generalized access control model to be able to handle situations like: 1. Unplanned admissions and transfers. 2. Post-discharge and pre-treatment access to information. 3. Referrals. 4. Second opinions. 5. Laboratory tests. Situation number 1 and 2 are examples of processes taking unexpected turns. Handling this is not a matter of roles. However, contextual information (for example the current geographical location of a patient, or the bed he/she is in, health care personnel present etc.) could possibly be used in combination with roles to handle these situations. Contextual RBAC has been discussed in several papers (Thomas, 1997), (Georgiadis, Mavridis, Pangalos and Thomas, 2001), (Kumar, Karnik and Chafle, 2002), (Wilikens, Feriti and Masera, 2002), but some work remains on figuring out what constitutes relevant contextual information for access control in healthcare. Also, the main problem here is that healthcare is process oriented, and so should the access control mechanism be. Exploring process-oriented access control remains to be done. Situation number 3, 4 and 5 on the other hand are examples of events. This could possibly be achieved through delegation and revocation of roles as proposed in (Na and Cheon, 2000). Delegation of roles is triggered by the user who delegates some of his or her permissions through delegating a role to another user - or possibly to another role. Revocation of delegated roles can be either based on a timestamp of validity, automatic when a task is completed or user-initiated. The use of role delegation shifts some responsibility for preserving the access control policy onto the system users. However, there is the possibility to place constraints on role delegation, to regulate which roles may be delegated to who by whom Paper A: Access Control in Healthcare Applications 63 thereby minimizing the probability and possibility of errors. The who and whom mentioned here are roles - not individual users. If an access control mechanism is based on RBAC all access should be based on the notion of roles to avoid unnecessary and riskincreasing complexity. Conclusion and future work In this paper we have discussed requirements for access control in healthcare in relation to implemented access control mechanisms in existing healthcare systems. It is clear that the implemented mechanisms are not ideal. The strongest indication of this is the use of exceptions in addition to the normal access control mechanism. The implemented mechanisms are based on a combination of role- and identity-based access control. Redesigning to a pure role-based model does not immediately help minimizing the need for exceptions. The main problem to be solved is to move from an access control model based on static properties to a model that adheres to the dynamic nature of healthcare organizations. In other words we need to design an access control model that is processoriented and is able to adapt to unplanned events. This model may or may not be based on roles. That remains to be investigated. We intend to continue research on how to construct an access control model better suited for healthcare applications. To do so we will work on identifying and formalizing processes that should be supported, and see how these may be incorporated into a process-oriented access control model. Bibliography Lillian Røstad received her master’s degree on the topic “Securing healthcare information in distributed systems” from the Norwegian University of Science and Technology in 2002. Currently she is working part-time as a research scientist at SINTEF ICT, as well as working on a PhD. The topic for the PhD-thesis is: ”Dynamic and context-sensitive access control for distributed healthcare applications”. 64 Paper A References David Ferraiolo and Richard Kuhn (1992), “Role-Based Access Control”, Proceedings of 15th National Computer Security Conference, USA. Ferraiolo et. al (2001) , “Proposed NIST Standard for Role-Based Access Control”, ACM Transactions on Information and System Security, Vol. 4, No. 3, pp. 224-274. Mark Evered and Serge Bgeholz (2004), “A Case Study in Access Control Requirements for a Health Information System”, Proceedings of Australasian Information Security Workshop 2004 Marc Wilikiens, Simone Feriti, Alberto Sanna and Marcelo Masera (2002), “A ContextRelated Authorization and Access Control Method ased on RBCA: A case study from the health care domain”, Proceedings of ACM Symposium on Access Control Models and Technologies. Wolfgang Essmayr, Stefan Probst and Edgar Weippl (2004), “Role-Based Access Controls: Status, Disseminatio ,and Prospects for Generic Security Mechanisms”, Electronic Commerce Research, No. 4/2004, pp. 127-156. Rattapoom Tuchinda (2002), “Access Control Mechanism for Intelligent Environments”, Bitstream: The MIT Journal of EECS Student Research. Cambridge, MA. Roshan K. Thomas (1997), “Team-based Access Control (TMAC): A Primitive for Applying Role-based Access Controls in Collaborative Environments”, Proceedings of ACM Symposium on Role-Based Access Control. Christos K. Georgiadis, Ioannis Mavridis, George Pangalos and Roshan K. Thomas (2001), “Flexible Team-Based Access Control Using Contexts”, Proceedings of ACM Symposium on Access Control Models and Technologies. Arun Kumar, Neeran Karnik and Girish Chafle (2002), “Context Sensitivity in Rolebased Access Control”, ACM SIGOPS Operating Systems Review, Vol. 36 , No. 3, July 2002, pp. 53-66. Marc Wilikens, Simone Feriti, and Marcelo Masera (2002), “A Context-Related Authorization and Access Control Method Based on RBAC: A case study from the health care domain”, Proceedings of ACM Symposium on Access Control Models and Technologies. SangYeob Na and SuhHyun Cheon (2000), “Role Delegation in Role-Based Access Control”, Proceedings of ACMWorkshop on Role-Based Access Control. Paper A: Access Control in Healthcare Applications 65 Guttorm Sindre and Andreas L. Opdahl (2005), “Eliciting Security Requirements with Misuse Cases”, Requirements Engineering Journal, Vol. 10, No. 1, January 2005, pp. 3444. 66 Paper A Paper B A Study of Access Control Requirements for Healthcare Systems Based on Audit Trails from Access Logs 68 Paper B Paper B: A Study of Access Control Requirements 69 A Study of Access Control Requirements for Healthcare Systems Based on Audit Trails from Access Logs Lillian Røstad and Ole Edsberg Norwegian University of Science and Technology (NTNU) Department of Computer and Information Science Trondheim, Norway {lilliaro,edsberg}@idi.ntnu.no Abstract In healthcare, role-based access control systems are often extended with exception mechanisms to ensure access to needed information even when the needs don’t follow the expected patterns. Exception mechanisms increase the threats to patient privacy, and therefore their use should be limited and subject to auditing. We have studied access logs from a hospital EPR system with extensive use of exception-based access control. We found that the uses of the exception mechanisms were too frequent and widespread to be considered exceptions. The huge size of the log and the use of predefined or uninformative reasons for access make it infeasible to audit the log for misuse. The informative reasons that were given provided starting points for requirements on how the usage needs should be accomplished without exceptionbased access. With more structured and fine-grained logging, analysis of access logs could be a very useful tool for learning how to reduce the need for exception-based access. 1 Introduction Security is a key concern for healthcare systems that contain sensitive data, like the Electronic Patient Record (EPR). Access control is at the heart of this concern. While healthcare personnel need access to the right information at the right time to provide the best possible care, it is also important to ensure patient privacy. Over the last few years, we have seen a development in access control research towards more dynamic, workflowbased and user-centered models [1]. However, the state of the art in existing healthcare systems appears to be the traditional Role-Based Access Control (RBAC) model [2], where roles correspond to job functions and administration is centralized. These systems are not well-suited for handling unplanned and dynamic events like patients being transferred between wards, doctors asking for second opinions from colleagues or simply unplanned patient arrivals. Consequently most such systems have exception mechanisms in place in addition to the normal role-based access control for handling these situations. Use of these exception mechanisms typically triggers additional logging of the user’s actions. Including these mechanisms makes the systems much more convenient to use. However, from a security viewpoint the use of exceptions leads to added complexity and a need to perform regular auditing to ensure that the mechanism is not misused. With an exception mechanism in place that allows the users to override the normal access control mechanism, technical measures alone cannot ensure privacy and security. This increases the need for manual control mechanisms and awareness training for users to limit the use of the exception mechanisms. However, studying how these access control mechanisms are used - in what situations, to cover what needs - may teach us something about how normal access control mechanisms should be changed to better suit the needs of the users, thereby eliminating or at least minimizing the use of exception mechanisms. Also, it is interesting to investigate if the audit logs contain the necessary information to trace any misuse of such exception mechanisms, or if not - what information is lacking. In this paper we will examine access logs from an installation of DocuLive EPR1 , a system with extensive use of exception-based access control. Doculive EPR is used by many of the largest hospitals in Norway. We have pulled information from the access logs from all eight hospitals in the Central Norway Health Region (CNHR). The aim of this work is to investigate if the audit trails may uncover information about the real user needs that will be helpful in designing better access control mechanisms for healthcare and also to examine if the logs contain the information needed 1 DocuLive is Proceedings of the 22nd Annual Computer Security Applications Conference (ACSAC'06) 0-7695-2716-7/06 $20.00 © 2006 a product of Siemens Medical Solutions 70 to uncover misuse. Additionally we aim to explore if any of the principles set forward in access control research in recent years may be applied to create better-suited access control mechanisms for healthcare systems. 2 Related work To our knowledge there has been no previous work published on investigating audit trails from EPR systems to extract access control requirements for healthcare systems. However some work has been done on eliciting access control requirements for healthcare systems by other means. Evered and Bögeholz in 2004 published a paper [3] describing how they performed a detailed case study on a small aged-care facility in Australia that at the time of study only used paper-based records. The study illustrates that even for such a small example, the access control requirements are very complex. In a short (one page) paper from 1998 [4] Beznosov discusses requirements for access control in the US healthcare domain and states that it should be based on role, affiliation, location, time and relationship. It is however not clear from the one-page paper what these conclusions are based on. In a classic paper [5] from 1996 R. J. Anderson presents a general security policy model for clinical information systems, which includes access control. He bases the motivation for this policy on a number of identified threats towards healthcare systems. Based on his experience and involvement in international EPR architecture and security standards, Blobel in 2004 [6] published a paper describing a set of models for authorization and access control in healthcare systems. 3 The subject of study Norway is divided into five health regions: north, south, east, west, and central. Each region has a regional health authority and several health enterprises. Each health enterprise encompasses one or more hospitals, and together the health enterprises in one region encompass all hospitals within the region. In the Central Norway Health Region (CNHR), which was the object of this study, there are four health enterprises and eight hospitals. All of these hospitals use DocuLive EPR. Norwegian laws prohibit sharing of medical records between health enterprises. Medical information may be transferred based on a specific request, but not shared in real-time, e.g. through a common EPRsystem. As Figure 1 shows there are therefore separate installations of the EPR-system for each hospital. However, there is one common organization, CNHR IT, which is responsible for the daily operation and maintenance of the EPR-systems for all hospitals in the region. Because they all use the same EPR-system, DocuLive, it is possible to extract and compare log data across hospitals. Paper B Figure 1 also illustrates how the EPR system for one hospital is divided into three domains: somatic, psychiatry and child and youth psychiatry. Information in the patient record is assigned to a domain. Domains are used to protect information that is considered ”extra sensitive”. This means that a user working on a ward in the somatic domain does not have access to parts of a patient’s EPR that belong to any of the other two domains - even if the patient currently is at this user’s ward. Only users working in psychiatry or child and youth psychiatry can access parts of the EPR that are assigned to these domains. In DocuLive access decisions are based on a user’s role (e.g. doctor, nurse, secretary), current place of work (ward) and the type of information being accessed. The role determines which documents in the EPR a user is allowed to access. At any given time a user has access permissions according to his or her role for the patients that are currently registered at the ward where he or she works. Note that a user may be assigned to several roles and places of work. In addition, there are two exception mechanisms for access: • Actualization - allows a user to open the EPR of a patient that he/she does not have access to through the normal access control mechanism. The user is granted access to the EPR as though the patient was registered at the ward where he/she works. The permission to use the actualization mechanism is not part of a user’s role, but is granted on an individual basis. When using actualization the user has to provide a reason for doing so, and the action is recorded in a separate log for use of actualization and emergency access. The EPR is then opened for a specific time period, which depends on the reason provided. In CNHR there are currently eight predefined reasons for using actualization which are shown in Table 1 with corresponding time intervals. There is also the option for entering a self-defined reason and time interval. Actualization is also used as an automatic mechanism by the system for opening EPRs for users who are assigned an approval-task (signing) for documents in the EPR and for opening the EPR of patients who are scheduled to arrive at the hospital soon, but have not been admitted yet. The time-period for automatic actualization is set to 7 days. • Emergency access - allows a user to open a single document in a patient’s EPR that he/she does not have access to through the normal access control mechanism. The emergency mechanism is stricter than actualization in that it has to be used on every single document that the user wants to open. In CNHR only some of the hospitals use emergency access - most make due with only actualization. However - where in use - emergency access is used to access EPR documents across Proceedings of the 22nd Annual Computer Security Applications Conference (ACSAC'06) 0-7695-2716-7/06 $20.00 © 2006 Paper B: A Study of Access Control Requirements 71 Hospital 3 Hospital 2 Hospital 1 Hospital 4 Somatic Psychiatry C&Y Psych* Common EPR services Hospital 5 Hospital 8 Hospital 7 Hospital 6 *Children and youth psychiatry Figure 1. EPR Hospital model domains within one hospital. That is: some use it as a way for users in the somatic domain to access information in the psychiatry and child and youth psychiatry domains. As for actualization, when using emergency access control the user has to provide a reason and the action is recorded in the same log as use of actualization log. Note that there are no predefined reasons for using emergency access; the user always has to manually provide a reason. Also note that the time interval where the document remains accessible after using emergency access is firm. In CNHR this time interval is set to 10 hours. Not all documents in the EPR are accessible through emergency access, only those specifically labeled so, and only some users have the permission to use emergency access. Emergency access is assigned to users much in the same way as roles - meaning that the permission to use emergency access is linked to a ward or hospital. 4 This record also contains information about the provided reason and time interval. Note that it is only the action of actualization or emergency access that is recorded in a separate log. Any subsequent use of the EPR within the time interval is recorded in the normal access log. Therefore we had to extract and combine information from the two logs to get a complete view of use of EPRs within an actualization or emergency access period. The IT-unit in CNHR was very helpful in creating anonymized versions of the logs - removing names of users and patients and replacing with anonymous, but unique indexes. In addition to the log-extracts, we also collected an anonymized listing of users in the region including their assigned access permissions. The log-extracts we received consisted of: • All records: – Anonymous user ID Methods and materials – Users’s place of work - hospital and ward In this study we collected access log data from the EPRsystem from all eight hospitals in CNHR for one month (March 2006). There are two separate logs: • Access log - every time a document is opened an entry is created in the access log containing information about the user, the patient and the document being accessed. • Actualization and emergency log - an entry is created in this log whenever an EPR is opened using actualization or a document is opened using emergency access. – Anonymous patient ID – Patient location - hospital and ward • Only in records from access log: – Time stamp – Document ID – Document type – Document code • Only in records from actualization/emergency log: Proceedings of the 22nd Annual Computer Security Applications Conference (ACSAC'06) 0-7695-2716-7/06 $20.00 © 2006 72 Paper B Reason Healthcare - provide/plan/consider User support Research project Write/complete EPR documents Scan Quality assurance - administrative/professional Obliteration/editing/deletion/blocking/merging Control committee Other (self-defined) T ime(hours) 48 3 24 48 2 48 1 24 - Table 1. Predefined reasons and time intervals for use of actualization – Start time – End time – Reason 4.1 No. users actualization perm. No. users emergency access perm. No. DocuLive users (total) Research questions % 74 0.25 100 Table 2. Number of users and permissions After reviewing the type of information available, we constructed a set of research questions to structure our work. The questions were selected to collect information that we hope will contribute to uncovering access control requirements for healthcare systems. The questions we aim to investigate and hopefully answer are: Actualized EPRs EPRs accessed using emergency Number of patients (total) Count 54 095 67 99 352 % 54 0.07 100 Table 3. Overall use of actualization • Q1: Is actualization/emergency access used sufficiently infrequent to be considered an exception? • Q2: Which users (role) use actualization/emergency access the most? Count 12 298 41 16 723 5.2 Q1: Is actualization/emergency access used sufficiently infrequent to be considered an exception? • Q3: Which wards use actualization the most? • Q4: What reasons are provided for using actualization/emergency access? • Q5: What kind of information is most often accessed using actualization/emergency access? • Q6: What information should be recorded in access logs to be able to investigate misuse? 5 5.1 Results Some basic numbers Table 2 contains an overview of basic user data: how many users in total, how many have actualization permission and how many have emergency access permission. The table shows that out of a total of 16723 DocuLive users in the health region, 74% have been assigned the permission to actualize EPRs, but only 0,25% have the permission to use emergency access. Note that emergency access is only used by two of the hospitals in the region. The others use only actualization. As Table 3 illustrates, in March 2006 a total of 99 352 distinct patients were in contact (i.e. their EPR’s were accessed in some way) with the hospitals in the region. Of these patients 54% had their EPR accessed using actualization. This fact combined with the fact that 74% of all users are assigned the permission to use actualization indicate that use of actualization is indeed not an exception. This motivates further investigations as to how actualization is used. Emergency access is, by comparison, only used 67 times and only very few users are assigned this permission. The numbers are therefore so low that they are difficult to use as a basis for any reasoning. We will therefore focus on the use of actualization, and only return to emergency access in the discussion - as in the true meaning of it’s name this mechanism will probably always need to be present. However the way this mechanism is used in the hospitals in this study, as we have explained earlier, does not really reflect on the name emergency access. Table 4 illustrates the proportions of use of actualization and emergency access compared to the total number of accesses in EPR. One access corresponds to opening of one Proceedings of the 22nd Annual Computer Security Applications Conference (ACSAC'06) 0-7695-2716-7/06 $20.00 © 2006 Paper B: A Study of Access Control Requirements Accesses using actualization Accesses using emergency Total number of accesses Count 297 742 67 1 794 153 73 % 17 0.004 100 Table 4. Number of accesses in total and using actualization or emergency access EPR or a folder or document inside an EPR. Based on these numbers we find that 17% of the accesses are based on actualization. On average there were registered 2.31 accesses in an EPR within one actualization period. 5.3 Q2: Which users (roles) use actualization access the most? Table 5 presents an overview of defined roles, number of users assigned to this role in total, percentage of users within each role who are assigned actualization permission, and percentage of users within each role who have used actualization in the period. Note that we have removed the roles where no users are assigned actualization permission, which were a total of three roles: perfusionist, dental health secretary and acupuncturist. If we assume that the percentage of actualization assignment for one role reflects the current perceived need or requirement for use of this functionality for users within this role (and possibly also a level of trust in users within this role) - then it is interesting to take a closer look at the differences between actualization assignment and use. DocuLive has been in use since 1998 (from 2002 for the entire region) so it is reasonable to assume that the distribution of roles and permissions are fairly stable now. We may then assume that the percentage of use of actualization reflects the actual needs or requirements of users within a role. If we examine Table 5 more closely we see that on average the actual percentage of use of actualization is significantly lower than the percentage of assignment of actualization. This may lead to the interpretation that actualization is in fact assigned to many users that do not need this functionality - at least not on a regular basis. For instance it seems to be the rule that all doctors should have permission to actualize - but only 52% of doctors did in fact need to do so within this period. Of the nurses, who represent the largest group of users by far, only 22% used actalization - while 61% has the permission to do so. Thus it would be interesting to further investigate who of these users, in what situations actually do require the functionality provided by actualization. However the log-data does not provide sufficient information, and would have to be supplemented with other information - possibly from questionaires, interviews, observations etc. Role Nurse Doctor Health secretary Enrolled nurse Physiotherapist Midwife Psychologist Ergonomist Social worker Educationist Consultant Social educator blank/incompr. Radiation therapist Audiometrist Radiologist Speech therapist Nutritionist Bioengineer Activator Pharmacist Welfare worker Orthopaedy engineer Dentist Genetic advisor Orthoptist Occupational hygienist Optician Child welfare consultant Ambulance personnel Dental mechanic Count 9 234 2 957 1 934 799 411 382 196 150 128 101 80 79 48 34 31 26 25 21 16 15 9 9 7 7 4 4 2 2 2 1 1 %act 61 99 97 31 93 83 99 84 95 96 56 84 75 100 97 96 80 100 94 67 11 44 100 100 100 100 100 100 100 100 100 %use 22 52 51 5 52 17 57 38 59 47 30 28 25 44 65 35 40 71 6 7 0 11 14 14 100 100 0 100 50 0 100 Table 5. Overview of roles with % assigned and use of actualization permission. Proceedings of the 22nd Annual Computer Security Applications Conference (ACSAC'06) 0-7695-2716-7/06 $20.00 © 2006 74 Paper B W ard Medical ward (18) Surgical ward (21) Anaesthesia ward (8) Emergency ward (10) Out-patient clinics (43) U sers 2 834 2150 629 482 473 %act 86.9 75.2 99.5 71.1 99.7 %use 49.8 33.2 30.3 27.6 62.6 Table 6. Overview of users employed at ward types with % assigned and use of actualization permission. The number of wards of a type is given in parentheses. Wards that were not covered by a major type were excluded. 5.4 Q3: Which wards use actualization the most? From Table 6 we can see that actualization is used rather frequently at the medical ward 2 . According to [7], 90-95% of the patients who are admitted to the medical ward need immediate help. Only 5-10% are planned patient encounters. As such, the high number of actualizations for this ward is unsurprising. It is interesting to note that for the surgical, anaesthesia and emergency wards the percentage of users assigned actualization permission is significantly higher than the percentage of actual use. Out-patient clinics represent the wards with the highest count of actualization use. This is probably due to the fact that patients are not admitted to these wards, they are just there for a short time in the day, and as such it would make sense to have an access mechanism in place to handle this. 5.5 Q4: What reasons are provided for using actualization/emergency access? Table 7 shows that out of all uses of the actualization functionality, a self-defined reason was only entered in 1.76 % of the cases. We investigated this number further and found that out of all the users who had used actualization functionality in the period only 8% had, at least one time, provided a self-defined reason for doing so. Actualization was used a total of 133 918 times, and a self-defined reason was only provided in 2 357 of these actualization occurrences. Several reasons were provided multiple times, so these 2 357 reasons again map to 730 unique reasons. These numbers tell us a couple of interesting things. First of all: the availability of predefined reasons means less specific information about why actualization was used. The predefined reasons are so broadly defined that they convey very little information about the user’s needs. What we can 2 The medical ward mainly offers internal medicinal treatment. see is that signing information in the EPR is a common task, that should be included in the normal access control regime. Although the 730 unique reasons provided are too few to base any quantitative conclusions on, we nevertheless decided to take a closer look, working from the hypotheses that when users took the trouble to manually enter a reason they felt that the predefined reasons did not apply to their situation or did not describe their need accurately. If some of these manually entered reasons are recurring then this implies a need shared by several users. 730 entries are so few that it was possible to examine them one by one and attempt manual classification to see if we could create categories of recurring reasons or types of reasons. We found that the most commonly provided reasons are: • Out-patient clinic patient encounters. • Physician referrals. • Hand over patient information to other hospital/health personnel on request. • Request for information from a patient or next of kin. • Release information to other external entity: insurance, legal, complaints. • Patient not registered correctly in admin system (results in access denied, even though patient is physically present at ward). As such, these should be considered as candidates for inclusion in the normal access control regime and constitute access control requirements that are not fulfilled. 5.6 Q5: What kind of information is most often accessed using actualization/emergency access? Table 8 shows how the rate of actualization usage varies with the document category. The high rate of the top entry might be explained by the fact that it includes second opinions, where the provider of the opinion might often need access to the patient record across ward boundaries. The same type of need could also explain the high rate of the second entry, which covers reports from physiotherapists, psychologists and other non-physician specialists. The relatively low rate of the nursing-related entries might be due to the fact that nurses mostly work with the patients admitted to their working ward. We also see that image-related lab results have almost twice the actualization rate of tissue and fluid-related lab results, perhaps because specialists from other wards are often called upon to interpret images. With a more fine-grained and well-structured category hierarchy, we might have been able to construct a more Proceedings of the 22nd Annual Computer Security Applications Conference (ACSAC'06) 0-7695-2716-7/06 $20.00 © 2006 Paper B: A Study of Access Control Requirements 75 Reason Healthcare - provide/plan/consider User support Research project Write/complete EPR documents Scan Quality assurance - administrative/professional Obliteration/editing/deletion/blocking/merging Control committee Automatic for signing Automatic from planned patient list Sum predefined and automatic reasons Manually provided, self-defined reasons % 32.87 0.03 1.64 41.27 2.02 2.83 0.88 0.11 10.33 6.26 98.24 1.76 Table 7. Actualization reasons: usage in percent. Documentcategories External correspondence Reports from other disciplines Lab results: Image diagnostics Physician’s journal Declarations etc Summaries, not further classified Observation and treatment Lab results: Tissue and fluids Own discharge summaries Lab results: Organ function Nurses’ summaries Nurses’ documentation Other Patient orientation T otalaccesses 218381 60431 24438 503496 13664 83810 22883 69046 106968 26342 10688 482919 154326 12005 %withactualization 32.80 25.81 23.64 23.09 19.96 18.49 18.28 13.09 12.50 12.04 7.81 6.37 5.51 5.30 Table 8. Percentage of accesses performed within actualization periods, for different categories, as classified in the EPR system. The category Other collects accesses to documents without category or in categories with fewer than 10000 accesses. Proceedings of the 22nd Annual Computer Security Applications Conference (ACSAC'06) 0-7695-2716-7/06 $20.00 © 2006 76 Paper B informative chart of actualization rates. If a decision was made to reduce the usage of actualization, such a chart could be used to detect the best possibilities for reduction. 5.7 Q6: What information should be recorded in access logs to be able to investigate misuse? Exception access in some form will always have to be present in healthcare systems to handle emergencies. Therefore it is important to have sufficient and usable mechanisms to trace any misuse. It is clear from the work presented here that the DocuLive logs do not present sufficient information to effectively investigate suspicions of misuse. We had to combine data from two separate logs and the user database to be able to do this work, and still we believe that more information is required. The main shortcoming is the predefined reasons for using actualization that mask the real intent. For an audit trail to be usable it should: • be available through a usable interface for the administrators, and • contain sufficiently detailed information to get a picture of what has happened. 6 Discussion The system under study here in many ways conforms to the ideas of optimistic security put forward in [8]. However, this study illustrates how difficult it is to trace events in such a system. Being able to trace events is essential to provide adequate security for systems containing sensitive health information. Therefore we believe that healthcare systems require a stricter form of access control, where the usage of exceptions is minimized. Having examined the audit logs we have found some recurring events fulfilled with actualization, that should be candidates for inclusion in requirements for an access control model that is better suited for the real needs of the users. Thus this should aid in minimizing the use of actualization. We would also like to point out that when exception mechanisms are introduced, it is important to have regulations on who should be assigned this permission and to ensure that these regulations are followed. It should be easy to obtain an overview over which users, or roles, have the permission to use exception mechanisms. Minimizing risk includes minimizing the user base that has the potential for exploiting exception mechanisms. Based on this study, we have not been able to conclude on a firm set of requirements for access control in healthcare systems. However, we have identified some initial requirements that we intend to explore further. Most of what we have seen indicates the need for a more dynamic and usercontrolled access control solution. We believe that RBAC should be the foundation, but with added ability for handling dynamic events, workflow and collaboration. Several papers, including [9] [10] [11] have been written on the concept of role delegation which allows a user to delegate his/her role to another user. This may be used as a mechanism to handle referrals, second opinions and transfer of patients. To be able to do this we should introduce the notion of health personnel-patient relationship, meaning that they are linked by something more than just a common ward. We also think the notion of Team-Access Control [12] centered around a cooperating team seems promising. Based on our findings of provided reason, we believe that the notion of tasks and related responsibilities and duties provides a promising platform for access control decisions in healthcare systems. 7 Conclusion and future work Although we have been able to identify some requirements, or initial requirements, in this study, more work needs to be done. We intend to continue our investigation by supplementing with data from other systems from the same period (including admission/discharge dates) to see when actualization is primarily used. In addition we hope also to be able to observe healthcare personnel’s information needs in situations where common tasks need to be performed. For that purpose, interviews are another possibility we hope to explore. Acknowledgements The authors would like to thank the people at Central Norway Health Region who helped make this study possible. We would also like to thank our advisors Øystein Nytrø and Svein Johan Knapskog, as well as our fellow PhDstudent Thomas Brox Røst, for valuable input and help. References [1] W. Tolone, G.-J. Ahn, T. Pai, and S.-P. Hong. Access control in collaborative systems. ACM Comput. Surv., 37(1):29–41, 2005. [2] D. F. Ferraiolo, D. R. Kuhn, and R. Chandramouli. Role-Based Access Control. Computer Security Series. Artech House Publishers, Boston, 1 edition, 2003. ISBN: 1580533701. [3] M. Evered and S. Bögeholz. A case study in access control requirements for a Health Information System. Proceedings of the second workshop on Australasian information security, Data Mining and Web Proceedings of the 22nd Annual Computer Security Applications Conference (ACSAC'06) 0-7695-2716-7/06 $20.00 © 2006 Paper B: A Study of Access Control Requirements Intelligence, and Software Internationalisation - Volume 32. Australian Computer Society, Inc., Dunedin, New Zealand, 2004. [4] K. Beznosov. Requirements for access control: US Healthcare domain. Proceedings of the third ACM workshop on Role-based access control. ACM Press, Fairfax, Virginia, United States, 1998. ISBN: 1581131135. [5] R. J. Anderson. A security policy model for clinical information systems. Proceedings of the 1996 IEEE Symposium on Security and Privacy. IEEE Computer Society, 1996. [6] B. Blobel. Authorisation and access control for electronic health record systems. International Journal of Medical Informatics, 73(3):251–257, 2004. ISSN: 1386-5056. [7] St. Olavs Hospital - medical ward. URL: http://www.stolav.no/stolav/Virksomhet/behandling/ medisin/index.htm. Last accessed: May 28th 2006. [8] D. Povey. Optimistic security: a new access control paradigm. Proceedings of the 1999 workshop on New security paradigms. ACM Press, Caledon Hills, Ontario, Canada, 2000. ISBN: 1581131496. [9] L. Zhang, G.-J. Ahn, and B.-T. Chu. A role-based delegation framework for healthcare information systems. Proceedings of the seventh ACM symposium on Access control models and technologies. ACM Press, Monterey, California, USA, 2002. [10] S. Na and S. Cheon. Role delegation in role-based access control. Proceedings of the fifth ACM workshop on Role-based access control. ACM Press, Berlin, Germany, 2000. [11] E. Barka and R. Sandhu. Framework for role-based delegation models. In Annual Computer Security Applications Conference (ACSAC), pages 168–176, 2000. [12] R. K. Thomas. Team-based access control (TMAC): a primitive for applying role-based access controls in collaborative environments. Proceedings of the second ACM workshop on Role-based access control. ACM Press, Fairfax, Virginia, United States, 1997. Proceedings of the 22nd Annual Computer Security Applications Conference (ACSAC'06) 0-7695-2716-7/06 $20.00 © 2006 77 78 Paper B Paper C An extended misuse case notation: Including vulnerabilities and the insider threat 80 Paper C Paper C: An extended misuse case notation An extended misuse case notation: Including vulnerabilities and the insider threat Lillian Røstad1 Norwegian University of Science and Technology, Trondheim, Norway [email protected] Abstract. Misuse cases are a useful technique for eliciting and modelling security requirements and threats. In addition they may be very useful in a risk analysis process, particularly as part of the system development process. The original misuse case notation adds inverted use cases to model threats and inverted actors to represent attackers. However, an attack is usually performed by exploiting a vulnerability in a system and it would be useful to be able to represent vulnerable functions in a model. In addition, it should be possible to discern between insiders and outside attackers in a model, as they have very different abilities and potential for attacking a system. This paper therefore proposes an extended misuse case notation that includes the ability to represent vulnerabilities and the insider threat, and discusses the use of this extended notation in the system development and risk analysis processes. 1 Introduction Security is being increasingly recognized as an important quality of IT-systems. Much of the reason for this can be explained by the evolution of IT-systems towards what Gary McGraw in [13] defines as the trinity of trouble: connectivity, extensibility and complexity. While these three properties typically improves the possibilities of what a system can do, they also significantly increases the risks. Being secure means having control and being able to keep the bad guys out - but the more complex a system is the harder it is to manage, and the possibility of third-party extensions only adds to the complexity. Connectivity is seductive as it greatly increases the potential use of a system, but it also greatly increases the number of attackers that can have a go at breaking into or otherwise harm the system. In some systems, like health care, defence and banking, security has always been considered an important property. But as the system’s operational environment changes, so does the threat scenarios and need for defence mechanisms. Where isolation previously has been considered an appropriate defence, this is no longer an option. An excellent example of this, and the original motivation for the work presented here, is access control in healthcare systems. In healthcare systems protecting the patient’s privacy is a major concern - however it always has to be balanced against the need for access to information to make sound medical decisions and provide the best possible care. The current state-of-the art is Role-Based 81 82 Paper C Access Control (RBAC) [8] and a role in existing systems is typically a rather static structure combined of a user’s profession (doctor, nurse etc), place of work (ward) and where the patient is currently admitted (ward). There is currently a move towards making the systems more dynamic and user centric and enabling information sharing. As patients are able to select hospital or place of care more freely there is a need to be able to make a patient’s medical information available to those providing care. This significantly adds to the complexity and changes the requirements for the access control mechanisms - static structures are no longer sufficient. Also, most existing systems include mechanisms that allow a user to override the access control mechanism in emergency situations. In such situations there is no time to register the patient at the correct ward to enable the normal access control mechanism to function. Emergency access control effectively constitutes a vulnerability in the system that may be exploited by insiders - that is; legitimate system users that may misuse the functionality. As systems become connected the user bases grow, thereby increasing the potential risk for exploitation. To be able to design secure solutions in a changing threat scenario one needs to be able to perform risk analysis [21] based on system requirements and design [13]. UML use cases [1] have become a widely used technique for elicitation of functional requirements [7] when designing software systems. One of the main advantages of use cases is that they are easy to understand with only limited introduction to the notation, and therefore are a very well-suited tool for communicating and discussing requirements with system stakeholders. A use case model illustrates required usage of a system - i.e. expected functionality. In risk analysis it is equally important how one should not be able to use a system - i.e. potential threats and exploitation. Misuse cases [18] have been proposed as an approach to identifying threats and required countermeasures. The notation is very simple and complements the UML use case notation. However, the usability of the notation or the ability to give a more complete risk overview could be significantly improved by adding some minor extensions enabling the specification of vulnerabilities and the insider threat in misuse case models. The remainder of this paper presents such an extended misuse case notation and discusses potential use in system development and risk analysis. 2 Related work The notation proposed here builds upon work done on how to utilize use cases as a tool for eliciting and modelling security requirements. John McDermott [11] and Chris Fox [12] used the term abuse cases in their approach where they explored how threats and countermeasures could be expressed using the standard UML use case notation. In their approach they kept the abuse cases in separate models. Later, in a series of papers [15], [16], [17], [19], [14], [18], Guttorm Sindre and Andreas L. Opdahl have proposed, and elaborated on, the concept of misuse cases including both graphic and textual description. Misuse cases [18] extends Paper C: An extended misuse case notation 83 the UML use case notation by adding inverted use cases to model misuse and inverted actors to model attackers. Sindre and Opdahl [18] define misuse cases and misusers as: – Misuse case - a sequence of actions, including variants, that a system or other entity can perform, interacting with misusers of the entity and causing harm to some stakeholder if the sequence is allowed to complete. – Misuser - an actor that initiates misuse cases, either intentionally or inadvertently. Misuse cases are created by extending a use case model and thus provide the ability to regard system functions and possible attacks in one coherent view. In the initial work on misuse cases two additional relationships were defined [15]: prevents and detects and it was pointed out that the UML use case relationships include and extend may also be used to connect misuse cases. They also pointed out that the include-relationship may be used between a misuse case and use case to illustrate that an attack utilizes system functionality. This in fact corresponds to exploiting a vulnerability, but they did not provide a tailored notation for this. Ian Alexander has written several papers discussing misuse cases as a tool [6] [5] and experiences from application of misuse cases [2]. He has also discussed misuse cases in relation to goal-oriented requirements engineering [3] [4]. In this case Alexander stays true to the graphic notation of inverted use cases proposed by Sindre and Opdahl, but he defines four different relationships: threatens, mitigates, aggravates and conflicts with. It is interesting to note that in their latest (at the time of writing this paper) [18] publication on misuse cases, Sindre and Opdahl have refined the relationships in the misuse case notation adopting threaten and mitigate as suggested by Ian Alexander. By their definition a use case mitigates misuse case and misuse case threaten use case. Exchanging the prevents and detects with the softer mitigate makes sense as it is unlikely that any countermeasure applied will entirely eliminate a threat. <<threaten>> Store private info Steal info User Attacker <<mitigate>> Encrypt info Fig. 1. Simple use and misuse case illustrating the notation Donald G. Firesmith has discussed the concept of security use cases [9] where a security use case represents functionality needed to protect a systems assets 84 Paper C from identified threats. The idea of security use cases as a way of representing specific security functionality, or countermeasures, has been adopted by Sindre and Opdahl [18] and linked directly to the mitigate relationships. Security uses cases have not been given a specific graphical notation, but are represented as ordinary use cases in the models. Figure 1 depicts a very simple misuse case that illustrates the current notation. In this figure encrypt info is a security use case added to protect against the threat (steal info) identified as a potential misuse case. 3 Extended misuse case notation This paper proposes an extended misuse case notation to enable visualisation of vulnerabilities and the insider threat. The original misuse case notation only defines outside attackers [18]. However, inside attackers also pose a serious threat. An insider, to an organisation or a system, usually has much easier access to a system and thereby may perform other attacks and exploit other weaknesses than an outside attacker. As such it is useful to be able to model insiders as a separate actor type in order to get a comprehensive and complete overview of possible threats and attacks. In the original misuse case notation misuse cases are linked directly to use cases that they threaten. In other words attacks are linked to system functionality that may be disabled or otherwise damaged as a consequence of a successful attack. However it would be useful to be able to visualize what vulnerabilities are exploited to perform that attack. Threats towards a system may only be realized in an attack if the system contains vulnerabilities that can be exploited. It is important to be able to illustrate vulnerabilities to be able to identify all possible threats and attacks. We define an insider and a vulnerability as: – Insider - a misuser that is also member of an authorized group for the entity being attacked - e.g. an authorized user of a system, a member of the development team, an employee of an organization. – Vulnerability - a weakness that may be exploited by misusers. Figure 2 presents a combined overview of the notation for use cases and extended misuse cases. In addition to actors representing insiders and misuse cases representing vulnerabilities an additional relationship exploit is defined. The exploit relationship is used to link a threat to a vulnerability. Insiders and vulnerabilities have been given the same grey colour in this extended notation. This choice of colour indicates that both represent weaknesses in a system that may or may not be exploited. Either way it is important to have knowledge about the weak spots of a system as this constitutes the systems attack surface that may be exploited. The remainder of this section presents examples of how to use the extended notation. We have included three examples that illustrates different situations and systems where the notation will be useful. Paper C: An extended misuse case notation 85 Authorized user Insider Outside attacker Use case Vulnerability Threat <<extend>> <<exploit>> <<threaten>> <<mitigate>> <<include>> Fig. 2. Extended misuse case legend 3.1 Examples of use of the extended notation Emergency access control in healthcare systems Figure 3 depicts an example misuse case model using the extended notation proposed in this paper. The model illustrates use and misuse of the access control mechanism in an Electronic Patient Record (EPR) system. As explained in the introduction, such healthcare systems often have emergency access control mechanisms designed to be able to override the standard access control mechanisms in situations where access to information is of vital importance but there is no time to register the patient in the system and link him/her to a specific ward - which is necessary for the standard access control to function properly. In these situations healthcare personnel are authorized, by their organization and the law, to use the emergency access control mechanism to gain access to information that they have a legitimate need and right to view. However, for such an emergency mechanism to be useful, it has to be available at all times. This effectively leads to a backdoor into the system that may be misused by insiders to snoop around when they should not. Most system users will not attempt misusing this mechanism although it is possible. But, it is important to be able to consider the possibility and map out potential consequences and apply proper countermeasures if the consequences are grave. And that is the reason why this addition to the misuse case notation is important. You cannot get a complete overview of potential risks and threats towards a system if you do not consider the complete picture. By identifying emergency access as a vulnerability we are also able to consider proper countermeasuers to apply in order to minimize the risk for misuse - in this case auditing (enables traceability and detection of misuse) and awareness training (e.g. making sure that system users are aware of the consequences of misuse - and what is considered misuse). 86 Paper C Access Control (AC) <<extend>> <<extend>> <<include>> Read EPR Normal AC Emergency AC Authorized user <<exploit>> <<include>> Emergency read EPR Auditing <<mitigate>> Unauthorized read EPR Awareness training <<mitigate>> Insider Fig. 3. Extended misuse case example: access control User input in web-enabled systems In an IT-system all input, from users or other systems, should be handled with caution. Figure 4 illustrates a generic login procedure for a web application - the user has to enter a username and password to log in. Identified attacks include (but are definitely not limited to): – Injection - for instance sql-injections to tamper with database content or override password check. – Overflow - entering unexpected or large quantities of data in the input fields to observe system reaction or possibly take control over the system. Input validation is identified as a countermeasure that helps mitigate these threats. This model illustrates how the extended notation helps highlight vulnerabilites that may be exploited. An insider is not inlcuded because these attacks are typically performed by outside attackers. Highlighting vulnearbilities in this way may be particularly helpful in a risk analysis process, where the customers are involved. By visualizing vulnerabilities, attacks and what may happen it will hopefully be easier to get acceptance and resources to apply security measures. An insider on the system development team This example illustrates how the extended notation may be used not only on a system level, but also on a business- or organizational level. An insider may exist inside a development Paper C: An extended misuse case notation <<exploit>> Enter username <<exploit>> 87 Injection attack <<mitigate>> Input validation Authorized user Enter password <<exploit>> <<exploit>> Attacker <<mitigate>> Overflow attack <<threaten>> <<threaten>> Use system Fig. 4. Extended misuse case example: user input team or an organization. For example a disgruntled employee working on a development project may inject code into a system that opens up a backdoor that attackers may exploit like Figure 5 illustrates. Implement system System developer Inject backdoor Insider <<mitigate>> Code audit <<mitigate>> <<mitigate>> Inject bug <<mitigate>> Security testing Fig. 5. Extended misuse case example: insider in development team 3.2 A step-by-step approach: how to apply the extended notation In [15] Sindre and Opdahl propose guidelines, a set of steps, to perform when using misuse cases to elicit threats and countermeasures. The approach described 88 Paper C here for applying extended misuse cases is based on their guidelines, but refined to include the necessary activities to consider the insider threat and uncover vulnerabilities. 1. Identify actors and use cases for the target system. Only with an overview of what the system is supposed to do, and who will use it, is it possible to start identifying potential attackers, weak spots and threats. Create UML use case models. These will serve as input to the subsequent steps. 2. Identify potential outside attackers. With knowledge about the system discovered in step 1 one should be able to identify who might target the system for attack purposes from the outside. This may include a wide range of persons with a wide variety of motivations - from the unskilled hacker using downloaded tools to jam the system using a DoS1-attack, to highly skilled industrial spies. At this point it is important to create as complete a list as possible of potential attackers. Later, in the risk analysis process one can eliminate attackers that are deemed unlikely or that will probably not be able to cause any harm. 3. Identify potential insiders. As with outside attackers there may be a variety of insiders. For example there are the people developing a system - who may intentionally inject backdoors - and there are different kinds of users of the operational system that have different rights and thereby differ in the harm they are capable of inflicting on the system. On this point as well, the main concern is to generate as complete a picture as possible. 4. Identify threats. Having identified potential misusers who may harm the system, the next step is to identify what types of harm they may want to inflict on the system - i.e. potential threats and attacks. To be able to do this one should consider what might be the goal of the identified misusers what would they want to achieve? 5. Identify vulnerabilities. This step means analysing how threats and attacks may be performed. Given the identified threats - how may an outside attacker, or insider, do this? This means examining the systems functionality identified in step 1 and consider each use case carefully to decide if it may be exploited for malicious purposes. When a potential vulnerability is identified it should be labeled accordingly in conformance with the extended misuse case notation. 6. Identify security requirements. Having identified misusers, threats and vulnerabilities - in this step the focus is on countermeasures. This is done by adding security use cases (as earlier mentioned these use the notation of ordinary use cases) to the models and adding the mitigate relationship to the threats or vulnerabilities they protect against. 7. Revise findings so far. This is of course an iterative process that may be carried out several times before one is satisfied that the result is reasonably sound and complete. Creating a 100% complete overview of all risks is infeasible but applying a structured risk-based approach and using the right 1 Denial of Service Paper C: An extended misuse case notation 89 people with the required knowledge [13] should help ensure the best possible result. Note that the steps need not necessarily always be carried out in exactly this order. Specifically steps 2 through 5 may be intertwined as it may be hard or possibly not beneficial to completely separate these steps. 4 Relation to risk management in system development Risk analysis, and risk managed development processes, is a well known technique for making decisions in many engineering fields. Building secure systems is about managing risks. It is not possible to build a system that is absolutely secure against all attacks, known in the present or that may be invented in the future [22]. Risk managed system development is about creating systems that are reasonably protected against known attacks and with a robust build using design principles that will hopefully make the system able to withstand future attacks. What is reasonable protection and what risks should be handled is for the system stakeholders to decide - i.e. the customer. To decide what risks to handle one needs to rank the identified risks and this requires assigning a value. A risk value is calculated as: Risk = P robability × Consequence (1) Misuse cases provide an overview of information that is very useful in a risk analysis process [10]. However, misuse cases only provides an overview and should be a starting point for creating attack trees [22] and doing threat modelling [20] to get a complete view of the threats and vulnerabilities in a system. Adding notation for expressing vulnerabilities and the insider threat makes the misuse case notation richer and adds more detail which should provide a better starting point for the continuing risk management process. 5 Discussion Although not all vulnerabilities may be represented in a use case or misuse case model, it is important when considering adding functionality to a system to examine if it represents a vulnerability that can be exploited. Only then is it possible to make a risk-based decision whether to not include that functionality or apply the necessary countermeasures to ensure protection. The possibly greatest power of use and misuse cases is that they are so graphical and easy to understand, and work very well as a basis for discussion with system stakeholders. Typically customers are not eager to spend money on security as it does not directly add to the value of the product. Misuse cases can help convince customers that security is important. Extending the misuse case notation helps this process as it enables: 90 Paper C – Visualisation of effects of adding functionality that might seem desirable, but actually represents vulnerabilities. The extended misuse case notation enables explicitly stating how vulnerable functions may be exploited. – The insider threat should not be neglected. Insider attackers have very different possibilities from outsider attackers and by using a separate notation for insiders one is able to emphasize this. The extensions proposed here are simple, in accordance with the original misuse case notation. The idea is to keep close to the UML use case notation and only add what is needed to include security concerns, while keeping the models very easy to understand. 6 Conclusion and further work This paper has presented and shown examples of an extended misuse case notation including notation for expressing vulnerabilities and insider attackers. This adds to the expressiveness of misuse cases while still keeping the notation very straightforward and easy to understand. The extended notation enables expressing a richer and more complete picture of security threat considerations for a system which is useful when using misuse cases in risk analysis. To further investigate the ideas presented here, it would be useful to create a textual representation of extended misuse cases. Also, security functionality is currently represented as ordinary use cases. It might be useful to create a specific notation for security functionality, or countermeasures that have been added to mitigate vulnerabilities and threats. 7 Acknowledgements The ideas described in this paper was inspired by the project on case studies of access control in healthcare performed by Julie-Marie Foss and Nina Ingvaldsen at the Norwegian University of Science and Technology (NTNU) in the fall of 2004 which I had the pleasure of supervising. Misuse cases was used in that project to model findings and some alterations, initiated by very useful comments and suggestions from Guttorm Sindre, to the notation had to be made to be able to express all findings. These alterations were the starting point of the extended notation described in this paper. References [1] Unified modeling language: Superstructure. Technical report, Object Management Group (OMG), August 2005. http://www.omg.org. [2] I. Alexander. Initial industrial experience of misuse cases in trade-off analysis. In IEEE Joint International Conference on Requiremenst Engineering, Essen, Germany, 2002. IEEE. Paper C: An extended misuse case notation [3] I. Alexander. Modelling the interplay of conflicting goals with use and misuse cases. In Goal-Oriented Business-Process Modeling (GBMP) 2002, volume 109, London, UK, 2002. CEUR Workshop Proceedings. [4] I. Alexander. Modelling the interplay of conflicting goals with use and misuse cases. In International Workshop on Requirements Engineering: Foundation for Software Quality (REFSQ) 2002, Essen, Germany, 2002. [5] I. Alexander. Misuse cases help to elicit non-functional requirements. Computing & Control Engineering Journal, 14(1):40–45, 2003. [6] I. Alexander. Misuse cases: Use cases with hostile intent. IEEE Software, 20(1):58– 66, 2003. [7] I. Alexander and N. Maiden. Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle. John Wiley & Sons, 2004. ISBN: 0470861940. [8] D. F. Ferraiolo, D. R. Kuhn, and R. Chandramouli. Role-Based Access Control. Computer Security Series. Artech House Publishers, Boston, 1 edition, 2003. ISBN: 1580533701. [9] D. G. Firesmith. Security use cases. Journal of Object Technology, 2(3):53–64, 2003. [10] P. Hope, G. McGraw, and A. I. Anton. Misuse and abuse cases: Getting past the positive. IEEE Security & Privacy, 2(3):90–92, May/June 2004. [11] J. McDermott. Abuse case models for security requirements analysis. In Symposium on Requirements Engineering for Information Security (SREIS), Indianapolis, USA, 2001. [12] J. McDermott and C. Fox. Using abuse case models for security requirements analysis. In Annual Computer Security Applications Conference, Phoenix, Arizona, 1999. [13] G. McGraw. Software Security - Building Security In. Addison-Wesley Software Security Series. Addison-Wesley (Pearson Education), Boston, 1 edition, 2006. ISBN: 0321356705. [14] G. Sindre, D. G. Firesmith, and A. L. Opdahl. A reuse-based approach to determining security requirements. In 9th International Workshop on Requirements Engineering: Foundation for Software Quality (REFSQ’03), Klagenfurt/Velden, Austria, 2003. [15] G. Sindre and A. L. Opdahl. Eliciting security requirements by misuse cases. In 37th International Conference on Technology of Object-Oriented Languages and Systems (TOOLS-Pacific 2000), pages 120–131, Sydney, Australia, 2000. [16] G. Sindre and A. L. Opdahl. Capturing security requirements through misuse cases. In Norsk Informatikkonferanse (NIK), Tromsø, Norway, 2001. [17] G. Sindre and A. L. Opdahl. Templates for misuse case description. In Seventh International Workshop on Requirements Engineering: Foundation of Software Quality (REFSQ’2001), Interlaken, Switzerland, 2001. [18] G. Sindre and A. L. Opdahl. Eliciting security requirments with misuse cases. Requirements Engineering, 10(1):34–44, 2005. [19] G. Sindre, A. L. Opdahl, and G. F. Brevik. Generalization/specialization as a structuring mechanism for misuse cases. In 2nd Symposium on Requirements Engineering for Information Security (SREIS’02),, Raleigh, NC, USA, 2002. [20] F. Swiderski. Threat Modeling. Microsoft Press U.S., 2004. ISBN: 0735619913. [21] D. Verdon and G. McGraw. Risk analysis in software design. IEEE Security & Privacy, 2(4):79–84, 2004. [22] J. Viega and G. McGraw. Building Secure Software: How to Avoid Security Problems the Right Way. Addison Wesley, 2001. ISBN: 020172152X. 91 92 Paper C Paper D The iAccess Handbook: A Methodology for Access Control Integration 94 Paper D Paper D: The iAccess Handbook 95 The iAccess Handbook: A Methodology for Access Control Integration Per Håkon Melanda, Lillian Røstadb, Inger Anne Tøndela, Øystein Nytrøb b a SINTEF, Software Engineering, Safety and Security, Norway Department of Computer and Information Science, NTNU, Norway Abstract Health care information about a patient is usually scattered among several clinical systems - potentially more than a hundred separate systems just within one hospital. System integration and interoperability is difficult to achieve, and various strategies for integration exist. However, one topic that has not received much attention is how to integrate system specific security mechanisms such as access control. This paper presents the iAccess handbook, which is a tool to aid this process. It consists of a repository of reference information and a set of methods for collecting information and presenting results, and concerns the legal, organizational and technological aspects of integrated access control for health information systems. The methods have been applied on two separate integration efforts in Norway, which affect ten hospitals in total. Keywords: Access to Information, Information Protection, Computer Security, Medical Records Introduction Health care information about a patient is usually scattered among several clinical systems - potentially more than a hundred separate systems just within one hospital. To get a clear understanding and overview of a patient's medical problems, health care personnel need access to all relevant information in a uniform view, but this can be difficult to achieve today. Therefore, system and information integration is one of the current key issues in health care. One topic that has not received much attention yet is how to integrate security mechanisms that are specific to each system, like access control, when systems are integrated. Access control and access decisions are closely linked to knowledge about information in a system, available operations in a system and the users of the system. A sound and sufficient access control scheme is critical in health care systems both to protect the patient's right to privacy, but also to make efficient use of information. When information is integrated - resulting in even larger repositories of information - enforcing access control becomes all the more difficult. In this paper we present the iAccess (Integrated Access Control for Health Care Information Systems) handbook which is a tool to be used during planning, designing and describing access control for integrated health care solutions. The handbook consists of a repository of reference information and a set of methods for collecting information and presenting results. The methods have been applied on two separate integration efforts in Norway, which affect ten hospitals in total. Due to confidentiality agreements, it is not possible to present direct results from each hospital, but we have created generalized examples of results by combining findings for illustration purposes. We will also discuss and share the general experiences from each of the applied methods. Both the feedback and results have been very positive and useful. With this paper, we wish to encourage similar activities in other countries based on the structure and methods of the handbook. Related work As far as we know, little research has been done on the topic of access control in system integration. However, some relevant work has been done on the topic of combining access control policies. Jajodia et al [1] introduced in 1997 the flexible authorization manager (FAM) for enforcing multiple access control policies. In [2] Jajodia et al introduced a language to define decision rules to resolve conflicts among authorizations. Also relevant is the work done by Hu et al and Ferraiolo et al on using what they call a Policy Machine (PM) [3,4]. The PM is a standardized access control mechanism that should require changes only in its configuration to be able to enforce different access control policies. They claim that the PM is also able to support combinations of policy instances e.g. Role-Based Access Control and Multi-Level security. In addition the work of Siewe et al [5] is of interest. They have created a language, Interval Temporal Logic (ITL), which allows for formal specification of access control policies and can handle the enforcement of multiple policies through policy combination. The potential for specification of temporal dependencies in access control rules using ITL is of particular relevance for health care as a collaborative and dynamic environment. 96 The iAccess handbook The purpose of the iAccess handbook is to serve as a collection of information and methods that are useful and appropriate when integrating the access control of heterogeneous health care information systems. The handbook itself is webbased, and both readable and editable for registered users, such as people from health care organizations, researchers and students (doctoral fellows primarily). The handbook has been created using the free MediaWiki software package1, which allows easy publication and development of content in a collaborative setting. The following sections will briefly explain the main contents from each of the three parts of the handbook. Handbook part 1: Reference information For the reference part of the iAccess handbook, we have borrowed the concept of viewpoints from the software architecture field - specifically from IEEE 1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems [6]. We have defined three viewpoints; legal, organizational and technical. These viewpoints were selected in recognition of the fact that access control is not merely a technical issue. Organizational measures are important in enforcing access control and ensuring patient privacy. The legislation defines if, how and when sharing of sensitive health information can take place. Legal viewpoint This viewpoint gives an overview of relevant paragraphs in the Norwegian legislation, a dictionary of legal terms from the selected texts and definitions of legal terms that are used but not formally defined in the legal texts. The purpose of the definitions of terms is to create a common basis and understanding when discussing legal issues and possible interpretations of regulations. It is not so much the legal texts themselves, but rather the current interpretation of them, that limits sharing of health information. The handbook makes this information available to people who need to understand these rules, but who do not necessarily have any formal juridical background. The information has been grouped into six categories for easy lookup and cross-linking: • Limitations on managing health information. • Orders, permissions and conditions regarding sending, receiving and exchange health information. • Information quality. • Ensuring confidentiality, integrity and availability of health information. • Internal control. • Particular technical, physical or organizational requirements for managing health information. 1 MediaWiki is a free software wiki package originally written for Wikipedia, see http://www.mediawiki.org. Paper D Organizational viewpoint This viewpoint concentrates on the organizational aspects that influence access control. The goal is to give an overview of how an organization and different work processes can influence access to health care information. Aspects related to system purpose are organized as follows: • The users of the system: Some systems are used only by some individuals while others are used by all hospital employees. • How the system is used: Different systems are used in different ways; e.g. for reading or writing, in emergencies, for a long or short period of time. • Type of patient treatment in relation to the system: Patients can be treated by one fixed health care professional, by a fixed group, a dynamic group or by everyone on a ward, to name a few alternatives. Aspects related to the organization are organized in this way: • Written policies related to access control and information security behavior. • Informal policies: This is what is considered acceptable behavior among colleagues, and will not always be the same as what is stated in the written policies. • Acceptable risk: A health care organization will always be subject to risk requirements, both from the authorities and the general public. • Relevant organizational measures, e.g. routines, awareness-building and training. Technical viewpoint This viewpoint contains information that is closely related to the technical concepts of access control. No assumptions are made about the prior technical knowledge of the users of the handbook, and this section has a twofold purpose; providing users that are newcomers to the field with sufficient information to get an overall grasp of access control concepts, models and mechanisms; and equally important, provide a structure of properties of access control models and mechanisms that can be used for classification of systems. The information is structured as follows: • Reference models: Definition and description of different access control models, such as discretionary or mandatory [7], role-based [8], task-based [9], teambased [10] and domain-based [8]. • Access control regimes: Systems can have no access control at all, it can be an integral part of the system or access control can be enforced by some entity external to the system itself. • Attributes that can be used for access control decisions: Group [11], role, ward affiliation, physical location, time/shift, relation to information owner (patient), security clearance level. Paper D: The iAccess Handbook • Dependency on other systems: The access control mechanism in a system can e.g. depend on information from other systems, like a user database or human-relations system, for making access control decisions. • Additional measures: These are not a direct part of the access control mechanism, but can provide information that allows detection of misuse. Examples are logging and surveillance. Handbook part 2: Survey methods This part of the handbook defines a set of survey methods, and we will here briefly present the main ones and discuss our experiences with them. Study of documentation From studying documentation you can learn a lot about an organization and/or a system that will be useful when working with access control integration, and also for planning workshops and interviews (see the following sections). There are certain kinds of documentation with relevance for access control, which should be present in a health care organization, and we recommend focusing on the following: 97 Process workshops Our process workshop is based on the methodology defined by Dingsøyr et al in [12]. The purpose of the process workshop is to get input from a heterogeneous group of people that are involved in a given process. In other words: While documentation can provide information about how something is supposed to be done - the process workshop conveys information about how it is actually done. During a process workshop, the participants are presented a scenario, and then each one writes down keywords related to activities, participating roles, documentation and tools that are used to solve the scenario. This is done in the same way as a traditional brainstorming session. After this, the workshop participants gather around a process map and eliminate/add/reorganize the notes on the map until they have reached a version of the process description that they can all agree upon, as shown in Figure 1. • Organizational information security policies. • Organizational structure - including roles and responsibilities for information security. • Organization-level access control policy. • Strategies - for instance integration strategy. • High-level system documentation. • Description of implementation and use of access control mechanisms. • Requirements with respect to identification, authentication and authorization. • Risk analysis based on system security and patient safety. Different organizations have different types of documentation. The results from a documentation study greatly depend on the organizations studied. It can be just as interesting to see what kind of documentation exists, as to study the actual content. If the anticipated documentation does not exist, asking for it still serves a purpose by making the organization aware of what information could be expected to be present. Our experiences were that a lot of the information that actually existed was outdated. As systems develop and routines change, documentation is not always updated accordingly. Also, information can be scattered across many documents, with varying level of details and target groups, making it difficult to get a clear understanding and overview. In many cases, system documentation was considered to be sensitive, and some organizations were reluctant to give that kind of information. Specifically, this was a concern for the systems that the organizations had designed and built themselves to fit their needs. Figure 1 - Creating the process map by using sticky notes and active discussions. According to the participants, the process maps give a correct and clear view of the real-life situation; that is how things are done, conflicting elements and possible improvements. During the workshops, the participants raise and answer questions such as: What is done, why it is done like this, why not like this, what can be improved and what is most important. The maps are useful as basis for discussion, and give insight into something that is scattered throughout the organization in documents, intranet pages and people's knowledge. A typical two-hour workshop will usually result in high-level process descriptions, and seldom detailed technical information about the access control mechanisms. 98 Paper D Workshop Head of department Interview User (employee) Check health care personnel authorisation Central administrator Local sysadm <<documentation >> Contracts: declaration of confidentiality, terms of use for IT-systems <<challenge >> Only one person is responsible for this . Sign contracts Create UserId Identify access needs based on responsibilities <<documentation >> Forms : access rights centralized systems, access rights local /department -specific systems Fill in access rights forms Assign access rights to user for centralized systems <<elaboration >> The user has to be authorized for access to the hospital network and assigned access rights to each relevant clinical system. Assign access rights to user for local /department specific systems Send letter containing username and password Order UserId and systems access Figure 2 - Sample UML activity diagram including documentation and comments from interviews showing the process of assigning access rights to a new employee. Semi-structured interviews Handbook part 3: Combining and presenting results Semi-structured interviews [13] are used to gather detailed information to complement and elaborate the process descriptions obtained in the workshops. This is be done by using a set of pre-defined questions (an interview guide), but allowing the interviewees to answer freely - there are no categories to select from and the interviewees are allowed to ask questions. An interview guide should start by explaining the interview motivation, and briefly explain the relevant terms. The interview guide should be based on the process maps. This part of the handbook describes how to combine and present the results from the survey methods. The most promising technique is the use of an extended version of UML 2 activity diagrams for modeling the process descriptions and information related to processes. An UML activity diagrams is well suited for describing processes and activities, both related to human and system behavior, because of a visual organization that is easily understandable by most people. An example activity diagram can be found in Figure 2, which describes assigning access rights to a newly employed person. In this diagram, the activities are organized in swim lanes, depending on who has the main responsibility for performing the activity. Shadowed boxes represent documentation relevant for the described activities. Attached to the activities are also other types of comments. Four such stereotypes have been defined, two of which are shown in the example diagram. These are: <<challenge>>, <<suggestion for improvement>>, <<user experience>> and <<elaboration>>. We found it valuable to be able to interview end-users with different professions and from different wards. The challenges related to physicians are not necessarily the same challenges as those experienced by nurses, who have other experiences than secretaries. The access control solution should consider this. In most cases, the experiences of the end-users coincided with the opinions of the decision makers and system developers/maintainers, but they also disagreed on several matters, for instance on routine efficiency. The interviewees talked a lot about physical access to computers and login routines, while workshop participants concentrated more on size of logs and details related to the possibilities of better technical solutions. At the end of the interviews we asked the participants how they felt about being interviewed about access control related issues. The response was only positive. Some said that they had never really thought about access to information before, others said that they were glad to be able to tell someone about their experiences with getting access to information, and hoped that things would be better in the future. We have found that the extended UML activity diagrams represent the combined findings of the surveys in a very clear way. It is easy to get a grasp of the overall process, at the same time as more detailed information is readily available. However, keep in mind that if too many comments are added, the diagrams may become messy and incomprehensible. Balancing the detail of information and ease of understanding is both a science and an art. 2 The Unified Modeling Language, see http://www.uml.org Paper D: The iAccess Handbook General discussion The original reason for creating the iAccess handbook was to have an instrument for surveying and documenting real-life access control integration efforts of health care systems in Norway. The results so far have mainly been used by the health care organizations themselves and by doctoral fellows researching how technical, legal and organization challenges should be solved. A survey gives a snapshot of today’s situation, what has improved from the past and what is planned in the near and distant future. Just as interesting, some improvements may be negative for the majority of the users, and it is important to share that kind of information with the rest of the community in order to avoid reoccurrence. There exists a myriad of clinical health care systems in most hospitals today. Systems that individually are not very suitable will probably not be improved by integration, and the way systems are used in real-life must be properly examined. It is our firm belief that research on legal, organizational and technical matters will be important to achieve integrated access control solutions that actually fit the context in which they are used, and in the end – improve health care while protecting the privacy of the patient. Conclusion We have presented the iAccess handbook, which consists of three parts relevant for analyzing planned or existing efforts for access control integration for health care systems. Representing multiple views from various stakeholders in unified diagrams eases the understanding on how things are and what should be done. The methods in this paper are first and foremost qualitative, and our future work will add methods that provide more quantitative results. Acknowledgments The project Integrated Access Control for Health Care Information Systems (iAccess) is funded by the Norwegian Research Council. The research performed in this project would not be possible without the cooperation and effort of the participating hospitals and organizations. We would also like to thank Professor Dag Wiese Schartum and his associates from the University of Oslo for their valuable contributions. References [1] Jajodia S, Samarati P, Subrahmanian VS, Bertino E. A unified framework for enforcing multiple access control policies. In: Proceedings of the 1997 ACM SIGMOD international conference on Management of data; 1997; Tucson, Arizona, United States: ACM Press; 1997. p. 474-485. 99 [2] Jajodia S, Samarati P, Sapino ML, Subrahmanian VS. Flexible support for multiple access control policies. ACM Trans. Database Syst. 2001;26(2):214-260. [3] Hu VC, Frincke DA, Ferraiolo DF. The Policy Machine for Security Policy Management. In: Proceedings of the International Conference on Computational Science-Part II; 2001: Springer-Verlag; 2001. p. 494-506. [4] Ferraiolo DF, Gavrila S, Hu V, Kuhn DR. Composing and combining policies under the policy machine. In: Proceedings of the tenth ACM symposium on Access control models and technologies; 2005; Stockholm, Sweden: ACM Press; 2005. p. 11-20. [5] Siewe F, Cau A, Zedan H. A compositional framework for access control policies enforcement. In: Proceedings of the 2003 ACM workshop on Formal methods in security engineering; 2003; Washington, D.C.: ACM Press; 2003. p. 32-42. [6] IEEE Std 1471-2000 IEEE Recommended Practice for Architectural Description of Software-Intensive Systems: IEEE; 2000. [7] Gollmann D. Computer Security. 1st ed: John Wiley & Sons; 1999. [8] David F. Ferraiolo DRK, Ramaswamy Chandramouli. Role-Based Access Control: Artech House Publishers; 2003. [9] Thomas RK, Sandhu RS. Task-based Authorization Controls (TBAC): A Family of Models for Active and Enterprise-oriented Authorization Management. In: IFIP WG11.3 Workshop on Database Security; 1997 1997; Lake Tahoe, California: Chapman & Hall; 1997. [10] Thomas RK. Team-based access control (TMAC): a primitive for applying role-based access controls in collaborative environments. In: ACM Workshop on Role Based Access Control; 1997; Fairfax, Virginia, United States: ACM Press; 1997. p. 13-19. [11] Sandhu R. Roles Versus Groups. In: ACM RBAC Workshop; 1996: ACM Press; 1996. p. 25-26. [12] Dingsøyr T, Moe NB. The Process Workshop: A Tool to Define Electronic Process Guides in Small Software Companies. In: The Australian Software Engineering Conference; 2004 13-16 April; Melbourne, Australia: IEEE Computer Society Press; 2004. p. 350-357. [13] Fontana A, Frey JH. Interviewing: The Art of Science. In: Norman K. Denzin YSL, editor. Handbook of Qualitative Research. 2nd edition ed: SAGE Publications; 2000. p. 361-376. Address for correspondence Per Håkon Meland, SINTEF ICT, NO-7465 Trondheim, Norway. E-mail: [email protected], Web: http://www.sintef.com/ict 100 Paper D Paper E Access Control and Integration of Health Care Systems: An Experience Report and Future Challenges 102 Paper E Paper E: Access Control and Integration of Health Care Systems 103 Access Control and Integration of Health Care Systems: An Experience Report and Future Challenges Lillian Røstad, Øystein Nytrø Norwegian University of Science and Technology Department of Computer and Information Science N-7491 Trondheim, Norway [email protected], [email protected] Inger Anne Tøndel, Per Håkon Meland SINTEF ICT N-7465 Trondheim, Norway [email protected], [email protected] Abstract Health information about a patient is usually scattered among several clinical systems, which limits the availability of the information. Integration of the most central systems is a possible solution to this problem. In this paper we present one such integration effort, with a focus on how access control is handled in the integrated system. Although this effort has not yet solved all the issues of access control integration, it demonstrates a practical approach for creating something that works today and serves as input to the discussion on future challenges for access control when integrating multiple systems. 1 Introduction In order to ensure patient safety, rapid access to relevant, correct and consistent health information is crucial for healthcare personnel in many situations. Even though electronic patient records (EPR) are becoming more and more prevalent, the patient information is usually scattered over several clinical systems since the clinical information is local or specific to wards. A patient may easily have hundreds of separate, overlapping records in various systems. This limits the availability of the information. A typical solution to this problem is integration of the most central clinical systems, such as the laboratory, X-ray and EPR systems. However, it is vitally important that the advantages of information integration are not achieved at the sacrifice of patient privacy. Access control is therefore one of the key issues to handle in order to be able to success- fully merge and make efficient use of these large quantities of information. Information flow between systems should not compromise the access control rules for the information in any of the systems, and this can be a challenge to achieve if not properly planned and implemented. In this paper we describe an ongoing integration effort at a Norwegian hospital, with a focus on the implemented access control strategy. This effort serves as background for a discussion of unresolved matters for access control in integrated healthcare systems. 2 Rikshospitalet and the Clinical Portal Rikshospitalet University Hospital 1, founded in 1826, represents the highest level of specialist care in Norway and is one of the largest Norwegian hospitals. The hospital has about 4000 employees including 500 medical doctors and 1500 nurses. Each year the hospital handels 160 000 outpatient clinic consultations and 50 000 patients are hospitalized for one day or more. A myriad of IT systems of varying age and technological sophistication are used in the everyday treatment of patients. They estimate that a total of approximately 160 clinical systems exists and are in use at the hospital. At Rikshospitalet they recognize the need to integrate these systems to make better use of the clinical information. Access to all relevant information about a patient should aid healthcare personnel in providing the best possible treatment for their patients. Rikshospitalet has chosen an integration approach based on a web portal solution called the Clinical Portal. Through Second International Conference on Availability, Reliability and Security (ARES'07) 0-7695-2775-2/07 $20.00 © 2007 1 Rikshospitalet (http://www.rikshospitalet.no) 104 Paper E this portal they are currently able to provide integrated access to information from the following systems: PiMS/PAS (patient administrative information), DocuLive (EPR system), RIS-Web (Radiology), Symphathy (Pathology), Miclis (Microbiology) and NetLab (Clinical biochemistry, Immunology and Pharmacology). The Clinical Portal offers three different desktops to its users: The results obtained from using these methods were combined in UML activity diagrams, slightly adapted for this purpose. For more information on the methods used, see [3]. • My desktop: Provides access to e-mail, calendar, contacts, and general news from the hospital. In this section the Clinical Portal is described, from a technical, administrative and user perspective. The focus will be on the access control solution. We begin this section by introducing the overall architecture of the clinical portal. • Clinical desktop: Provides access to information on activities at the user’s ward and is the entrance point to all clinical information in the hospital. Through the clinical desktop one can get access to an overview of all patients belonging to one’s own ward, and search for patients not currently admitted to this ward. • Patient desktop: Provides access to information on a specific patient, e.g. lab results, orders made (e.g. for new test) and plans. It is also possible to create new orders for this patient. 3 4 Case Study Results: The Clinical Portal and Access Control 4.1 System Architecture Figure 1 shows the overall architecture of the Clinical Portal. The architecture is founded on the middleware platform J2EE. We have attempted to keep the layer descriptions on a level of detail sufficient for our discussion of access control in the clinical portal, without getting into too much detail. Research Methods Our goal in the case study was to gather as much information as possible about the clinical portal: technical information about the system itself, about the decisions and choices made when implementing the system, the reasoning behind these decisions, and experiences from use of the system so far. To be able to grasp both technical and administrative information, as well as user experiences, the following methods were chosen for our study: • Documentation study: Two different types of documents were studied: Written policies and routines, and documentation of IT systems that play an important part in enforcing access control. • Process workshops: Two creative workshops were arranged, focusing on different aspects of how access control are handled in the organization and in the IT systems. The workshops were directed towards two different focus groups: Decision makers and system developers/maintainers. The methods used during the workshops were based on [2]. • Semi-structured interviews: Interviews were conducted with clinical personnel (e.g. physicians, nurses, nutritionists) and administrative personnel (e.g. secretaries), to get information on how the current access control scheme influences their work day. Interviews were performed in accordance with [1]. Second International Conference on Availability, Reliability and Security (ARES'07) 0-7695-2775-2/07 $20.00 © 2007 • The Portal Layer: The portal layer is the interface to the users. Portlets2 handle the users’ requests, and interacts with the service layer. • The Service Layer: The service layer provides services for accessing merged information from the source systems either from the Operational Data Store (ODS) which contains merged information from source systems, or by talking to the Hub which connects the source systems. • Integration Layer: The integration layer handles communication between applications and systems. This layer consists of the Hub and a set of adapters that facilitates communication with each source system. To avoid direct changes in the source systems, the individual source systems’ data formats are used for fetching and storing data. The data is translated to XML-format by the adapter and transferred from the source systems to the clinical portal. The ODS is also part of the integration layer. The Data Warehouse (DW) contains historical data from the ODS and source systems, and is used to facilitate report generation. Also part of the integration layer is the MetaCatalogue and the OID (Oracle Internet Directory) which is the basis for access control in the clinical portal. We will discuss these in more detail next. • The Source System Layer: This layer consists of the source systems feeding data into the clinical portal. 2 Java based Web component. Paper E: Access Control and Integration of Health Care Systems 105 provide a reason for using actualization, and this triggers extensive logging of the users actions. The Clinical Portal adopts this approach and additionally requires the user to re-enter his/her password when using actualization. The Clinical Portal offers context-based login, meaning that the users return to the context from which they last logged out. In addition, the portal has a fixed login time, meaning that users are logged out if they have not been active for the last 30 minutes. Users authenticate themselves to the portal by presenting a username and password. The MetaCatalogue does not contain any information on the passwords of users. The association between usernames and passwords are found in the OID, which is the second LDAP server, and it is only the OID that is involved in authentication. The MetaCatalogue and the OID are continuously synchronized. 4.2.2 Accessing Subsystems Figure 1. Architecture 4.2 Access Control in the Clinical Portal 4.2.1 Accessing the Main Portal Figure 2 presents the overall security architecture of the Clinical Portal with a focus on access control. As can bee seen from the figure, access to the portal is role-based. A user gets a different view of the portal depending on his/her role as defined in the MetaCatalogue (an LDAP-server that is part of the Meta directory). A role consists of a user’s profession (nurse, doctor etc) and place of work (department, ward). The role also determines information from which source systems are avilable and also which patients (e.g. only those currently admitted to the ward where tue user is working). In additon to pure roles, Rikshospitalet has adopted the concept of actualization in the portal. Actualization is a mechanism defined by Siemens Medical in their DocuLive EPR system. Briefly explained, actualization is an exception mechanism that allows a user to ovverride the rolebased access control and gain access to information about a patient. This mechanism is intended for use in situations where there is a user-patient contact that is not known to the MetaCatalogue and therefore access is denied based on roles. Examples of situations where actualization is used include referrals or second opinions, situations when the patient is moved from one ward to another and the MetaCatalogue is not updated when the patient arrives, a patient not currently hospitalized calling in to ask questions about previous treatment and so on. In DocuLive a user has to The Clinical Portal pulls information from six different subsystems. Access to the subsystems are handled by the portal, meaning that the portal stores the username and password and forwards these to gain access to information form the differen subsystems. This procedure is enabled by the fact that at Rikshospitalet all users have the same username and password to the Clinical Portal and the six subsystems. This is a first step towards Single Sign-On for all systems at Rikshospitalet. However, for now, this solution requires manual maintenance of identical username/password-pairs in the different systems. What information is made available is left up to the subsystems to determine. In other words the Clinical Portal simply logs a user onto a subsystems and requests information through an adapter. The subsystem returnes information allowed for this user according to the system’s own, internal access rules and returns these to the adapter, who wraps the information in XML and forwards to the Clinical Portal. It processes the information received, from several subsystems, and presents in to the user in a unified fashion. 4.3 Access Control Administration It is not only the technological solutions that influence how well an access control solution will work in an organization. In the process workshops we therefore also considered the administrative view of the solution, with a special focus on two issues: Second International Conference on Availability, Reliability and Security (ARES'07) 0-7695-2775-2/07 $20.00 © 2007 • Assigning access rights to a new employee. • Detection of misuse of the actualization access mechanism. 106 Paper E D octor N urse H ealth provider Practitioner N onclinical em ployees Patient Authenticating – role based access My desctop Clinical desktop Patient desktop Intranet My journal Extranet Mail Calendar Today's patients ADT EPJ Outpatients Inpatients Waiting lists Day program Lab results X-rays Common dictionary Provisioning Clin 1… Clin n LAB ADM RIS PACS Meta directory Authorisation – role and context based access Hardware / Infrastructure Figure 2. Security architecture We focused on capturing information about formal and informal procedures, who were involved in the operations performed, and what documentation was used. 4.3.1 Assigning Access Rights to a New Employee Figure 3 illustrates how a new employee is assigned access rights to all relevant systems. This process involves quite a lot of people from different parts of the hospital. Key components are the paper based access rights assignment forms. There is one form that states which systems a user should have access to - in other words which systems should show up on the desktop when the user logs on the hospital network. Additionally there is a separate form for assigning access to the main electronic record system (DocuLive), which has a rather complex access control solution. The ward leader is responsible for completing these forms and issuing them to the technical staff. Sometimes the user participates in this process, and sometimes office personnel assist the ward leader. The user also has to sign a confidentiality agreement and read and accept the rules for use of the hospital’s IT systems. This is a step to ensure security awareness among users. The access forms are sent to the IT-department which takes care of the practical issues involved in assigning access. Some of the systems may have separate administrators, and in these cases the central IT-department forwards the task of access rights assignment for these systems to them. 4.3.2 Detection of Misuse Figure 4 depicts the process of discovering and handling misuse. Misuse is not detected automatically, nor are there routines in place for regular auditing of the actualizaton logs from the EPR-system. However, sometimes the logs are checked based on suspicion presented by someone, or possibly motivated by the fact that a highly public figure or celebrity has been hospitalized. If the information found in the logs provide grounds for suspicion of misuse of a patient’s record, this is discussed with the patient’s primary physician to uncover if it is indeed misuse. The hospital has procedures in place for handling these kinds of incidents. This includes for the ward leader to consider punitive actions in cases of detected misuse. 4.4 Clinical Portal: User Experiences When introducing a new solution one should always focus attention on user experiences. So far we have only inerviewed a small set of clinical users (only 7), but they did provide some interesting feedback that we have summarized here. 4.4.1 General Experiences with Access Control in the Clinical Portal Users have experienced that access to information can be cumbersome when systems are not integrated. All users have stories about how they had to log on and off systems several times to get what they want. They are therefore satisfied with the Clinical Portal, where information from several systems is presented together. Most users can only Second International Conference on Availability, Reliability and Security (ARES'07) 0-7695-2775-2/07 $20.00 © 2007 Paper E: Access Control and Integration of Health Care Systems 107 Figure 3. Assigning access rights think of things that have improved after the introduction of the portal, including access control, the amount of information available electronically and the way the information is presented to the users. When it comes to the access control mechanisms and challenges, the one thing users really react to is that they are, as they put it, ”thrown out of the systems” after some limited time. Integration of systems results in more information being available at the same time, something that may result in information overflow if the information is not presented in a good and flexible way. However only very few users indicate that they sometimes get too much information. Another issue is patient privacy, but no one thinks it is a problem that they get too much information from a patient privacy point of view, though this is an issue they have given little thought before. They feel that this is taken care of by the system, since the most sensitive information can be blocked. They also feel that availability of information is for the patients’ own best - it is needed to provide the best care for the patients. When users are asked which factors should control what information you are allowed to access, many users mention position and place of work, and the patients they are working with. This corresponds well with the factors that are used today - role and ward. Other factors that are mentioned are the needs of the patients and care givers. Strict access control should not reduce service to the patient and the effectiveness and quality the provided care. The use of actualization is not problematic for users. They are not uncertain of their right to access patient records using this mechanism. Actualization is perceived as necessary and a natural part of their work, though some comment that it could be sensible to have some limitations as to which patients one is allowed to actualize. Finding these limitations is however not easy. Misuse of access to information, and misuse of actualization in particular, is not a problem, according to the users. Their typical workday is very busy, and there is no time for accessing patient records that are not needed. They are also well aware that access to patient records and the use of actualization is registered in logs. Some of the users have rather high expectations as to what is detected when it comes to misuse. One user even said that if you access a patient record by mistake, you could call the IT-department and say that it was a mistake. Another said that they think the system registers misuse if it recurs. But though misuse is not experienced as a problem, users are generally acknowledging that checking for and prevent- Second International Conference on Availability, Reliability and Security (ARES'07) 0-7695-2775-2/07 $20.00 © 2007 108 Paper E Figure 4. Detection of misuse ing misuse of information is an important task, and they think it is important that someone in the hospital is working with this. 5 Discussion and Future Challenges The Clinical Portal represents a step towards integration of clinical systems. However, in the existing portal the access control mechanisms remains unintegrated. A separate access control mechanism has been created for the portal, and the source systems use their own access control to extract information for a given user. This approach works for now, but it is desireable to be able to develop a more closely integradet solution in the future. However this is certainly not trivial. Access control is closely tied to information. The more fine-grained the access control mechanism is, the more closely it depends on knowledge about information and structure of data. A completely different approach would be to integrate information from all six subsystems, creating an access control scheme tailored to this ”new” system. However, this approach requires an enormous intial effort to integrate information from all subsystems and create a new interface to the information. Other disadvantages includes scalability it would not be straightforward to include information from more systems without considerable effort. Backwards compatibility and historical data is also problematic. It is important to have access to historical clinical information about a patient, so all existing data would have to be incorporated in the new system. Also, the access control models may differ considerably between the different source systems. Though many systems may use role-based access control, the concept of a role may be very differently defined. Some systems may be using simpler access control models where access is based on e.g. a user’s clearance level and/or information category. Some systems may not have any access control at all - if you provide a valide username/password pair you gain access to all information and functions in the system. Some work has been done on the combination of different access control policies, e.g. in the policy machine [4][5] but there is still a lot of work that remains to be done on this topic. A key question is if it is even feasible to do or if one should settle for an approach like the one in the Clinical Portal. Another issue worth discussing is the increased risks related to information exposurer and patient privacy in an integrated system. The more information is made available through one system, the greater is the risk of serious consequences if security is compromised. This concern is taken very seriously by the Norwegia government; the result being that sharing of clinical information between hospitals belonging to different organizations is not allowed in Norway. This leads us to a general discussion of what type of access control model is suitable and sufficiently secure for healthcare systems. As risks related to information exposure increases, so does the need for an access control mechanism that is sound and precise: which is able to provide healthcare personnell with the required information at the required time - no more and no less. important that is should be no less than required either. The previously mentioned actiualization mechanism is a direct result of the inability of the main access control mechanism to fulfill the users information requirements. Actualization is supposed to be an exception. A study of use of this mechanism in the DocuLive EPR system at 8 Norwegian Hospitals showed that 74% of the 16 723 registered DocuLive users were assigned the permission to use actualization. The study also showed that 54% of the patients had had their EPR accessed using actualization. In fact 17% of all accesses to EPRs were performed using actualization. Based on these numbers use of actualization can hardly be consideres an exception, it is in regular use. Allowing use of this mechanism in an integrated solution is probably not a good idea. We should rather strive towards creating an access control model, that is suited for the user’s real needs. The more information is included in a healthcare information system, the greater the risk for exposure and need for appropriate protection. Second International Conference on Availability, Reliability and Security (ARES'07) 0-7695-2775-2/07 $20.00 © 2007 Paper E: Access Control and Integration of Health Care Systems 6 Conclusion and Future Work The shift towards integration and interoperability of clinical systems will continue. In the future inter-hospital integration will also become an issue. Information integration and accessibility offers potentially great benefits for healthcare personnel and patients, but it also greatly increases the risks for patient privacy. As such it is important to focus on sound security mechanisms for authentication, access control and auditing in integrated systems. Even though Rikshospitalet, in their approach so far, has taken some steps towards integration, the issue of access control integration still remains largely unresolved. References [1] Norman K. Denzin, Y.S.L.: Handbook of Qualitative Research. 2nd edn., SAGE Publications 2000 [2] T. Dingsøyr, N. Moe: The Process Workshop: A Tool to Define Electronic Process Guides in Small Software Companies, ASWEC2004 2004 [3] P. H. Meland, L. Røstad, I. A. Tøndel: How to mediate between information security and patient safety, Proceedings of the Eight International Conference on Probabilistic Safety Assessment and Management (PSAM8) 2006 [4] Vincent C. Hu, Deborah A. Frincke and David F. Ferraiolo: The Policy Machine for Security Policy Management, In: Proceedings of the International Conference on Computational Science-Part II p.494-506 Springer-Verlag 2001 [5] David F. Ferraiolo, Serban Gavrila, Vincent Hu, D. Richard Kuhn: Composing and combining policies under the policy machine, Proceedings of the tenth ACM symposium on Access control models and technologies, ACM Press, p.11-20 2005 [6] Lillian Røstad, Ole Edsberg: A Study of Access Control Requirements Based on Audit Trails from Access Logs, Proceedings of the 21st Annual Computer Security Applications Conference (ACSAC), IEEE Society Press 2006 Second International Conference on Availability, Reliability and Security (ARES'07) 0-7695-2775-2/07 $20.00 © 2007 109 110 Paper E Paper F MG-RBAC: Using Medical Guidelines as a Source of Contextual Information to Activate and Deactivate Roles and Permissions 112 Paper F Paper F: MG-RBAC 113 MG-RBAC: Using Medical Guidelines as a Source of Contextual Information to Activate and Deactivate Roles and Permissions Lillian Røstada a Department of Computer and Information Science, Norwegian University of Science and Technology, Norway Abstract Controlling access to information is a key concern in healthcare systems. Some form of Role-Based Access Control (RBAC) is implemented in most healthcare systems. A problem with existing RBAC models used in healthcare is their static nature which doesn’t capture the dynamic needs of healthcare providers. In this paper we propose an enhanced access control mode combining RBAC with the use of Medical Guidelines, MG-RBAC. Medical guidelines contain temporal and contextual information that may be used to make more informed, dynamic access control decisions. Keywords: Access to Information, Computer Security, Privacy Introduction Access control is a key concern in healthcare systems. In order to ensure privacy of patient data, the systems has to provide suitable mechanisms to control access to information. Access control in healthcare has two rather different perspectives: • • at the one hand privacy protection and ensuring that no one gets access to more information than they need, and at the other hand patient safety and making sure that healthcare personnel gets access to all information they need to provide the best possible healthcare. Many existing healthcare systems use some form of RoleBased Access Control (RBAC). Access decisions are typically based on a user’s role (e.g. nurse, medical doctor etc) and workplace (department, ward). A user is granted access according to his/her role’s permissions for patients that are admitted the ward where he/she is working. However, these static properties are often incapable of capturing the dynamic needs of healthcare personnel. Patients are transferred and moved more rapid than the systems are updated, resulting in incorrect information forming the basis for incorrect access decisions. To work around these issues, most healthcare systems provide exception mechanisms that allow users to override the access control when they consider their information needs to be legitimate, even if the system thinks otherwise. Using these mechanisms typically requires providing a reason, maybe re-enter your password, and triggers extensive logging of the user’s actions. These mechanisms are only supposed to be used in a minority of situations – thereby the name exception mechanisms. However, a study of usage of one such system [1] for one month at eight hospitals in Norway shows that: • 74% of the users were assigned the permission to use this exception access mechanism • the exception access mechanism was used on the EPR of 54% of the patients during this period • in fact 17% of all EPR-accesses were performed using the exception access mechanism. Looking at these numbers it is clear that usage of this mechanism is in fact not an exception but a common event. This implies that there are situations commonly occurring that should be included in the normal access control mechanism, so the exception mechanism could be left for actual exceptions. The study concludes that there is a need for an access control model for healthcare that is able to handle dynamic events and support workflow and collaborations. In this paper, present a model for using Medical Guidelines (MG) as a source of information for access control decisions as a way of creating more dynamic access control for healthcare. MGs (or clinical practice guidelines) are defined by [2] as: “Practice guidelines are systematically developed statements to assist practitioner and patient decisions about appropriate health care for specific circumstances.” In other words an MG for a given diagnose contain information about best-practice course of treatment developed by experts in the field. Guidelines may exist both as an informal collection of information and in a more formalized, structured manner. There exist several formalized notations for computer-interpretable MGs. MGs may include temporal and event information that implies information needs and therefore may be used in access control. 114 Paper F The next section of this paper provides background information on RBAC and computer-interpretable MGs necessary for the discussion of MG-RBAC. We then move on to some motivating examples explaining how information form MGs may be used for access control. Finally, the general MG-RBAC model is presented before we move on to discussion of potential use, conclusion and our plans for future work on taking MG-RBAC from an idea and a model to testing it out. Role-Based Access Control (RBAC) RBAC [3] has become widely popular over the last decade. RBAC is based on the concept of assigning permissions to roles and roles to users. Roles often correspond to positions in an organization. In other words a role represents the permissions needed to perform the responsibilities of a specific position. RBAC has become so popular because of it’s: • Simplicity and ease of administration – there are relatively few roles in an organization compared to the number of users. With RBAC a role has to be defined only one time and can be assigned to many users. • Flexibility – changing responsibilities for a job position only requires updating permissions for one role, and the update is reflected for all users assigned to that role. • Scalability – as the organization grows the number of roles may remain unchanged if there are no new positions. New roles may easily be created and assigned to users as needed. RBAC has been implemented in many commercial systems. Therefore an RBAC-standard [4] has been created to ensure that the main principles remain equal across different implementations. The RBAC standard includes the core RBAC model as shown in Figure 1. Figure 1- Core RBAC Figure 1 illustrates how a role is linked to permissions (PRMS). A permission set consists of a set of allowed operations (OPS) on objects (OBS). The Core RBAC model also illustrates that users are assigned to roles either through a static or dynamic (session) link. Through these links the user has a constant set of roles through the static link, and a potential set of roles through the dynamic/session link. Any subset of the roles assigned through the dynamic link may be activated at any given time through a session. The RBAC standard additionally defines the notion of role hierarchies and permission inheritance, and static (SSD) and dynamic (DSD) separation of duty. Static separation of duty places constraint on the assignment of users to role. Dynamic separation of duty places constraints on the activation of roles in a given session. Computer-Interpretable Medical Guidelines Studies [5] have shown that MGs may be effectively used for computer-based decision support – aiding clinicians in making the best decisions. There exist a number of different formats for computer-interpretable MGs and they have several common properties [6] including the organization of treatment plans in decisions and action tasks. A key feature is also the possibility of directly linking the MGs with patient data which enable patient-specific decision support. Asbru [7] is only one example of such an MG specification language, and many of the others available may be used for informed access control decisions. Asbru has been chosen as the notational example used in this paper because it contains constructs for defining periodic and event-triggered clinical tasks that suits our demonstration needs, and because Asbru MGs are encoded in XML (eXtensible Markup Language1) which is a widely used format for exchange of data. The Asbru Language Asbru is a time-oriented, intention-based, skeletal planspecification representation language [8]. A skeletal plan specified in Asbru consists of a name and a plan body and may additionally contain (optional): a set of arguments, a time annotation, preferences, intentions, conditions and effects. The plan body contains a set of plans (child plans) and information about how/in which order these plans should be executed and also conditions on which child plans must be completed in order to complete the parent plan. An Example MG in Asbru An example of use of Asbru for encoding a guideline for treatment and observation of Gestational Diabetes Mellitus (GDM – a form of diabetes found in pregnant women) is available at [8]. Use of the guideline is initiated if a glucose tolerance test in the third trimester shows a blood sugar level between 140 and 200 mg/dl. The guideline consists of three main parts: • Glucose monitoring: measurements performed by the patient herself and/or by the physician. Check to verify that glucose level kept below a limit of 130 mg/dl for 1-hour post meals, < 100 mg/dl fasting and preprandial. • Nutrition: treatment is based on teaching patient a diet. The goal is to manage GDM with diet and without insulin therapy for as long as possible. Regular follow-ups (every 1-4 weeks) are recommended and should be scheduled individually for each patient. • Insulin therapy: initiated if blood sugar consistently > 100 mg/dl fasting and/or one hour postprandial con- 1 http://www.w3.org/XML/ Paper F: MG-RBAC sistently higher that 130 mg/dl and attempts at diet modification has failed. Note that this is only a short excerpt of the information contained in the guideline. MG-RBAC The Asbru guideline for GDM contains both temporal and contextual information that may be used for access control: • Periodic information needs: visits to physician while under treatment every 1-4 weeks (specific value set for a patient). The EPR does not need to be accessible to the physician in-between visits. • Events that trigger information needs: when blood sugar readings are too high the patient needs to visit her physician and review treatment. The EPR should be made accessible to the physician when too high readings occur. 115 all times. The physician might need to prepare for an appointment and enter some information after the appointment, but it should be sufficient for the EPR to be accessible to the physician e.g. two days prior to and two days past the next scheduled visit for a patient. Figure 3 illustrates how this may be done. The physician will have an assigned role that includes permissions to this patient’s EPR as he has a responsibility for this patient. But the role providing access rights do not need to be activated at all times as explained in the section on the Core RBAC model. The doctor should receive an alert, through role membership, that the EPR has been made available. Motivation – examples of use A set of UML use cases have been created to illustrate the envisioned use of medical guidelines in access control for healthcare systems. First of all a guideline has to be selected for treatment based on a diagnosis as shown in Figure 2. Figure 3 - Guideline: periodic access The third example of use of guideline information for access control decisions is the occurrence of events that trigger information needs. A typical example of such an event is a measurement of some sorts, made manually or by a sensor, which triggers further actions. For the GDM example the glucose monitoring illustrates such an event. The patient is to measure her own blood sugar level 4 times a day. If the measured level is above some specified limit further action needs to be taken. To determine further actions the physician needs access to the patient’s EPR. Figure 4 illustrates how roles are activated if the guideline specifies that a measure results in an action that requires access to the EPR and the relevant role (or roles) is activated. Access Event Figure 2 - Guideline selection In the GDM example the condition for diagnose and guideline selection was a blood sugar measurement of 14-200 mg/dl. A guideline contains generalized treatment advice, and has to be tailored by the physician to treatment of this specific patient. One example of such tailoring is the periodic consultations that are part of the guideline for GDM. The advice in the guideline only states that there should be regular consultations every 1-4 weeks. A specific time interval has to be selected for a specific patient – e.g. every 4 weeks. From a privacy viewpoint it is desirable to limit accessibility to the patient’s EPR as much as possible. Even if the physician is regularly seeing the patient he/she does not need access to the EPR at <<System>> Evaluate against guideline limits Patient Perform measurements <<System>> Determine actions <<System>> Activate/deactivate roles for access to EPR Enter result into EPR system Physician <<System>> Alert Roles Figure 4 - Guideline: event trigger 116 Paper F The MG-RBAC Model Using these examples of use as input a preliminary MGRBAC model, shown in Figure 5, has been created, showing in a bit more detail how this would work in a system. in creating a dynamic and context aware access control model for healthcare. We intend to continue to explore this idea further by creating a more detailed model and developing a proof-of-concept implementation. Acknowledgments I would like to thank my supervisors Øystein Nytrø and Svein J. Knapskog for always being ready to discuss my ideas and for challenging me. References [1] Røstad L., Edsberg O., A Study of Access Control Requirements for Healthcare Systems Based on Audit Trails from Access Logs, In Proceedings of the Annual Computer Security Applications Conference (ACSAC), Miami, 2006. Figure 5 - The MG-RBAC model A Guideline Monitor would be responsible for receiving events like sensor data or manual measurements and track time for the next periodic event. When a triggered or periodic event occurs the Guideline Monitor would request that the Access Control Monitor activates the appropriate roles. The Access Control Monitor would then be responsible for alerting the users assigned these roles and for evaluation of subsequent access request. Discussion The model presented here for MG-RBAC is only very preliminary and serves to inform about a promising idea that requires further work. The examples presented are based on a guideline representation in the Asbru language. Certainly for such a model to be useful it should be able to use guidelines in many different notations. One possible solution would be to integrate a guideline translation engine in the Guideline Monitor module. Work remains as to examine in details information contained in other guideline specification languages and how they may be translated. The examples presented here only illustrate triggered and periodic events. There may be additional information contained in guidelines that could be utilized in access control, but this has not been fully explored yet. [2] Field M.J, Lohr K.N., Clinical Practice Guidelines: Directions for a New Program, The National Academy of Sciences, 1990. [3] Ferraiolo D.F., Kuhn D.R., Chandramouli R., Role-Based Access Control, Artech House Publishers, 2003, ISBN 158053-370-1. [4] American National Standard for Information Technology: Role Based Access Control, ANSI INCITS 359-2004, American National Standards Institute, 2004. [5] Shiffman R.N., Liaw Y., Brandt C.A., Corb G.J., Computer-based Guideline Implementation Systems: A Systematic Review of Functionality and Effectiveness, JAMIA, 1999, v. 6, p. 104-114. [6] Peleg M, Tu S., Bury J., Ciccarese P., Fox J., Greenes R.A., Hall R., Johnson P.D., Jones N., Kumar A., Miksch S., Quaglin S., Seyfang A., Shortliffe E.H., Stefanelli M., Comparing Computer-Interpretable Guideline Models: A Case-Study Approach, JAMIA, 2003, v. 10, p. [7] Miksch S., Shahar Y., Johnson P., Asbru: A Task-Specific Intention-Based, and Time-Oriented Language for Representing Skeletal Plans, 7th Workshop on Knowledge Engineering: Methods and Languages (KEML-97), 1997. [8] The Asgaard Project, http://www.asgaard.tuwien.ac.at (last accessed: December 2006). Address for correspondence Lillian Røstad Conclusion and Future Work In this paper we have presented an idea and a preliminary model for using medical guidelines as input to access control. The idea is that guidelines contain information that can assist Department of Computer and Information Science Norwegian University of Science and Technology N-7491 Trondheim Norway Paper G Towards Dynamic Access Control for Healthcare Information Systems 118 Paper G Paper G: Towards Dynamic Access Control Towards Dynamic Access Control for Healthcare Information Systems Lillian Røstada, Øystein Nytrøa Department of Computer and Information Science, Norwegian University of Science and Technology, Trondheim, Norway a Abstract. Access control is a key feature of healthcare information systems to protect the privacy of patients and to ensure access to information as required by healthcare professionals. A problem with many existing access control mechanisms is their static nature. In this paper we propose combining workflow information from medical guidelines, observations and audit logs to create dynamic access rules that are adapted to the actual workings of a hospital. Our aim is to help minimize the use of “break the glass” access. Keywords. Security, Data protection, Evidence based guidelines Introduction Access control is one of the key features of health care systems. Access control is about restricting as well as ensuring access to information. These are two inherently different viewpoints. For privacy it is important that access is only granted when there is a legitimate need. For availability it is equally (some would argue more) important that access is granted to all information required to provide the best possible care. The goal of the work presented here is to narrow the gap between these viewpoints, by proposing a method for dynamic access control rules that adheres to the actual flow of work and responsibilities in a hospital setting. 1. Access Control Concepts Access control is about enforcing rules on which operations a user is allowed to perform on a resource (eg. information) in a system. There are several different access control models. The most common ones are mandatory access control (MAC), discretionary access control (DAC), and role-based access control (RBAC) [1]. RBAC is the preferred model used in many implemented access control mechanisms in health care systems and serves as the foundation for the ideas presented here. 1.1.Role Based Access Control The concept of Role Based Access Control [1] has gained increasing popularity over the last decade. In RBAC a set of roles is created that corresponds to job functions in 119 120 Paper G an organisation. Each role consists of a set of access rules. Rather than assigning access rules directly to a user, a user is linked to the role and thus has all the access rules associated with that role. Several users may be assigned to the same role, and one user may take more than one role. A typical RBAC role in a health care system would be that of a nurse. The nurse role consists of access rules that correspond to the information access a nurse needs to perform his job. The main advantages of RBAC are ease of administration, flexibility, and scalability. RBAC is considered a good fit when there are considerably fewer roles than employees in an organisation. When a new nurse is hired there is no need to create a specific access profile for him – he can simply be assigned to the existing nurse role. This scales well as it is easy to add more nurses as an organisation grows, and it is flexible because changing the access rules for all nurses only requires changing one role. Some health care systems [2] combine a role with the user’s place of work to make access decisions. In short, this means that a nurse only has access to users that are currently admitted to the ward where he works. Dynamic RBAC is extended to assign roles temporarily, according to work shifts or work processes. 1.2.Optimistic security In [3] Povey proposes the concept of optimistic security. The key feature in an optimistic security mechanism is the use of retrospective control. There are no access rules that are enforced when a request is made. The concept relies on the ability of someone to examine the logs later and determine if the access was legitimate. Auditing and traceability therefore are keys to enforcing optimistic security. Povey argues that optimistic security is well suited for systems such as healthcare where there may be situations when a user needs to exceed his normal privileges. Optimistic security exists in many healthcare systems as a “break the glass” mechanism intended to be used in emergency situations. A study [2] has looked into use of the “break the glass” mechanism in a system where normal access control is enforced as a combination of role and workplace as explained earlier. In the study audit data was collected for one month’s use of the system at eight hospitals. The study found that 54% of the patients admitted in this time period had their record accessed using the “break the glass” mechanism. Out of all accesses made in this period, 17% were performed using the “break the glass” mechanism. These findings strongly suggest that the rather static approach to access rules (role and ward) does not perform very well in a dynamic hospital setting. The 17% accesses resulted in almost 300 000 entries in the audit logs. The study also found that there were no automatic audit analysis tools in place. The amount of audit trails and the absence of tools make the task of analyzing audit trails for retrospective control impossible. A condition for optimistic security to work, is that the amount of use is minimal so manual review is realistic. In health care there will always be situations where availability of information is crucial and “break the glass” mechanisms are needed. One example is emergency situations when there is no time to properly register the patient in the administrative systems, which often is a requirement for normal access rules to apply. The goal is therefore not to completely eliminate the use of “break the glass”, but to reduce the use to an amount where it is feasible to perform retrospective control. One approach towards this goal is developing access control mechanisms that are better adapted to the Paper G: Towards Dynamic Access Control actual workings of a hospital and are dynamic in the sense that they are able to change and adapt as situation and context change. We will explore this idea further in this paper. 1.3.Dynamic access control – related work As stated earlier, a problem with many access control rules in health care is the “define once – use always” approach and the lack of dynamic properties and adaptability. Several extensions to RBAC have been proposed to include dynamic properties. Examples include role delegation [4] and context-sensitivity [5]. Role delegation allows a user to delegate her role to another user to transfer responsibilities either permanently or time-limited. In the proposed context-sensitive RBAC models, context is used to activate and deactivate roles. A user may have a large pool of assigned roles and only a subset of these may be activated at any given time. Context properties may be used to regulate the activation of a role. E.g info about work schedule may be used to activate roles depending on time and place of work. Though some propositions have been made on how to make RBAC more dynamic, a discussion of exactly what properties or values may be used remains. In the remainder of this paper we propose combining established best practices (medical guidelines), collected observational data, and audit data to learn patterns of information used in healthcare and apply these patterns to create access control rules that will help minimise use of «break the glass» access. 2. Workflow knowledge Medical guidelines, work plans, observed behaviour, and audit data all contain information about workflow in healthcare. While medical guidelines are the idealised version of the medical activities related to a problem, observational and audit data reflects what actually happens [6]. Moreover, guidelines do seldom assign roles or resources. However, by combining theses sources of knowledge we can create a coherent view of enacted workflows in healthcare, with an emphasis on information access requirements that may be utilized for access control. In this section we discuss medical guidelines, observation data and audit logs separately and provide motivational examples of how this information may be used for access control purposes. 2.1.Medical Guidelines A medical guideline (MG) for a given diagnosis contains information about best practice course of treatment developed by experts in the field. Guidelines may exist both as an informal collection of information and in a more formalised, structured manner. MGs often include temporal and event information that implies information needs that may be utilized for access control purposes. An example of a guideline for treatment and observation of Gestational Diabetes Mellitus (GDM – a form of diabetes found in pregnant women), encoded in the Asbru language for computer-interpretable medical guidelines, is available at [7]. Use of the guideline is initiated if a glucose tolerance test in the third trimester shows a blood 121 122 Paper G sugar level between 140 and 200 mg/dl. The guideline consists of three main parts: glucose monitoring, nutrition, and insulin therapy. The Asbru guideline for GDM contains both temporal and contextual information that may be used for access control: • Periodic information needs: visits to physician while under treatment every 14 weeks (specific value set for a patient). The EPR does not need to be accessible to the physician in-between visits. • Events that trigger information needs: when blood sugar readings are too high the patient needs to visit her physician and review treatment. The patient record should be made accessible to the physician when too high readings occur. 2.2.Observational data – empirical grounding of guidelines Guidelines are constructed by experts and represent idealized treatment processes – what is expected to happen given a diagnosis. In reality, each patient and care process is unique; furthermore, a complex problem will require that different guidelines are combined. A guideline may serve as a starting point, but will often need to be adapted to the specific situation at hand. In [6] the authors discussed how to use methodical observations of clinical care situations to improve guideline implementation. An observational study was carried out in the summer of 2005. Two medical students observed clinicians at work in the pre-rounds meeting and ward rounds. They took detailed notes of who were present, the subject of discussion (patient), information sources (written/electronic and oral), and specifics about what type of information was used. In each observation session they followed one clinician and from her viewpoint they noted who else were present and what role they had in the situation. We have reviewed these data to construct an example of how observational data may be used to create patterns of information\needs, shown in Figure 1. Due to space limitations, Figure 1 shows only the first few interactions in the previsit meeting, but it is sufficient to serve our purpose as an illustrative example. In this case they are discussing patient NN. The patient is new to the doctor so the nurse fills him in on some background info. Several information sources are used – some are paper-based (the patient list and the patient chart) and some are computer-based information systems (the electronic patient record (EPR) and the radiology imaging system (IDS)). The figure illustrates communicative acts between the actors present and the actors and the information sources they use. Roles are used to label the actors. This figure illustrates how observation may be used to uncover information needs in specific situations with a specific diagnosis (in this case heart failure), and link these to roles. Though not shown in Figure 1, the observational data shows that the diagnosis changes as test are being done and test results received and reviewed, as is very common. Through observational studies we can examine these transitions and study transfer of responsibilities and access requirements related to this. Paper G: Towards Dynamic Access Control Figure 1 – Information needs in pre-rounds meeting Even if observations provide real-world examples that may be collected over time, generalized, and used to improve guidelines, they still only give us a relatively highlevel view. To complete this picture and get detailed and accurate information about information accessed and actions performed, we turn to the audit logs. 2.3.Usage patterns from audit logs Most health care systems keep complete history; of changes in information and of user actions. The purpose is to always be able to roll back to a previous state, and to have complete traceability. This means that there exist audit logs with very detailed traces of user actions: the user's role at the time, what information was accessed, for which patient and what actions were performed [2]. From these audit logs it is possible to create generalized usage patterns per role. If a system allows “break the glass” access, it is also common to require the user to provide a reason for doing so and keep a log of these reasons as well [2]. We suggest utilizing this information for access control by: 1. Examine the reasons for using “break the glass” – any reasons that occur often should be considered as candidates for inclusion in the access control rule set. 2. Look for common usage patterns that describe workflows inwards. Examples include: Temporal patterns If action X occurs – then action Y occurs within Z time. Responsibility patterns If action X is performed by Role A – then action Y is performed by role B. Location patterns If action X is performed at ward 1 – then action Y is performed at ward 2. Situation patterns Role X is in situation S in a guideline, and requires specific information. 123 124 Paper G 3. Discussion “Break the glass” access is necessary to handle unexpected situations, but it constitutes a security risk and may be misused. The ideas presented here aim at minimizing the need for glass-breaking and making retrospective control feasible. In access control, the main concern is privacy, where access should only be granted to the information required by an actor in any situation. Clinicians may well disagree with this from the viewpoint that it is better to have broad access. In this paper we therefore suggest an approach to access control that combines guidelines and learning from observations and logs. The goal is to take another step towards the goal of having access mechanisms that support the work of care providers, while protecting the privacy of patients. The approach presented here is not another “do once – use forever approach”. It is fundamental to this idea that observing, learning, and improving should be a continuous process, allowing access rules to adapt to a dynamic, ever-changing environment. 4. Conclusion and future work In any clinical situation, the information about a patient can be ordered along a continuum from highly relevant, via interesting, to irrelevant, and at the other extreme; illegal according to laws of privacy. Being able to sort correctly may mean life and death. The main problem facing today’s busy clinician is avoiding irrelevant information and at the same time getting access to relevant information. In this perspective, relevance ranking and access control depend on the same knowledge about situation, role, guideline, and care process. We believe that optimistic access control, based on analysis and learning from practice as intended and as enacted, is a first step towards both effective relevance ranking and optimal access control. References [1]. [2]. [3]. [4]. [5]. [6]. [7]. Ferraiolo, D.F., D.R. Kuhn, and R. Chandramouli, Role-Based Access Control, 1 ed. Computer Security Series. 2003, Boston: Artech House Publishers, ISBN: 1580533701 L. Røstad, O. Edsberg, A Study of Access Control Requirements for Healthcare Systems Based on Audit Trails from Access Logs, Proceedings of the 22nd Annual Computer Security Applications Conference, Miami, USA, 2006. D. Povey, Optimistic security: a new access control paradigm, Proceedings of the 1999 workshop on New Security Paradigms, Ontario, Canada, 1999. Zhang, L., G.-J. Ahn, and B.-T. Chu, A role-based delegation framework for healthcare information systems. Proceedings of the seventh ACM symposium on Access control models and technologies. 2002, Monterey, California, USA: ACM Press. 125-134. Wilikens, M., et al. A context-related authorization and access control method based on RBAC, in Symposium on Access Control Models and Technologies. 2002. Monterey, California, USA: ACM. D. Sørby, T. B. Røst, Ø. Nytrø, Empirical Grounding of Guideline Implementation in Cooperative Clinical Care Situations, AI Techniques in Healthcare: Evidence-based Guidelines and Protocols (Workshop proceedings), Riva del Garda, Italy, 2006. The Asgaard Project, http://www.asgaard.tuwien.ac.at (last accessed: November 2007). Paper H An Initial Model and a Discussion of Access Control in Patient Controlled Health Records 126 Paper H Paper H: An Initial Model and a Discussion of Access Control 127 The Third International Conference on Availability, Reliability and Security An Initial Model and a Discussion of Access Control in Patient Controlled Health Records Lillian Røstad Norwegian University of Science and Technology Department of Computer and Information Science Sem Sælands vei 7-9, 7491 Trondheim, Norway [email protected] Abstract formation, and that of others for whom they are authorized, in a private, secure, and confidential environment.” [3] Health information about a patient is usually kept local to the hospital or clinic where the patient was treated. Patient Controlled Health Records (PCHR) has been proposed as a means to collect all this information and make it available to the patient. In a PCHR the patient is in control and determines who gets access to his health information. In this paper we present a set of usage scenarios to explore the concept of a PCHR. From the scenarios we deduce a set of concerns of relevance when designing an access control model for a PCHR. Finally we outline an initial access control model for a PCHR. 1 As pointed out by [4] this definition is a good starting point, but more information is needed on the context and use of PHRs. A PHR, in its most common current form, is a webbased system where a patient can enter notes and information about his health condition and share this information with his health care providers. Some PHRs also import clinical information and make this accessible to the patient through the system. However, most PHRs are local and specific to one point of care [5], or to a set of care sites that subscribe to the same PHR from one software vendor. As such, most existing PHRs only provide the patient with limited insight into parts of his health care information. The goal of a Patient Controlled Health Record (PCHR) [6] is to assemble the patient’s complete health history and grant the patient control over who gets access to this information. A PCHR differs from the usual PHR in that it exists outside of organizational boundaries. A PCHR contains data from multiple care sites, and the patient is in complete control of the information. This means that it is the patient himself who is administrator and assigns access rights to grant other users access to his information. Through a PCHR the patient may choose to share his data with health care providers and family members. He may also use the PCHR to release part of his health information for research studies or public health purposes. PCHRs provide a technology that may address several common problems in health care and health information exchange but, as a technology, they present some new challenges. Developing an approach to supporting access controls that corresponds to the dual needs for protecting patient privacy and autonomy (on the one hand) while preserving a high degree of flexibility so that the real variation in the conditions and circumstances of patients is served is the main challenge. Introduction Improved information technology is seen by many [1] [2] as the best means of making health care delivery more consistent, comprehensive, safe and timely. Accurate and complete medical records are a prerequisite to this vision. Health information about a patient is usually kept in local systems, specific to a ward or clinic, and accessible only to health care personnel. For every point of care there are separate systems to record information, and information flow between systems is very limited. Even if the information is immobile, the patient is not. As a consequence, patients often find themselves having to retell their medical history and redo tests whenever they encounter a new health care provider. Personal Health Records (PHR) have been proposed as a potential solution to this problem. The Markle Foundation, a public-private organization, in a report from their Connecting Health care in the Information Age Project defines PHR as follows: ”An electronic application through which individuals can access, manage and share their health in- 0-7695-3102-4/08 $25.00 © 2008 IEEE DOI 10.1109/ARES.2008.185 935 128 Paper H The remainder of this paper explores in detail the concept of a PCHR focusing on how it may be used for sharing and what this means for access control. From this discussion we deduce a set of concerns that need to be included in an access control model. Based on these concerns we outline an initial access control model for a PCHR. We conclude by summarizing what future work is needed on the topic. 2 RBAC has been implemented in many commercial systems. Therefore an RBAC-standard [12] has been created to ensure that the main principles remain equal across different implementations. 2.2 The architecture of the Indivo (formerly PING) PCHR system was outlined in [13]. Key features of Indivo are: • The patient is in complete control and in charge of determining who gets access to his information. Related work • Information is imported into Indivo from clinical systems and made available to the patient. The main concepts of Role-Based Access Control (RBAC) is introduces in this section as it is fundamental the initial model. Much of the background for he discussion in this paper comes from the Indivo1 PCHR system. Work on this system has been ongoing for years, and the author of this paper was fortunate enough to get to work with the Indivo team to study PCHRs and the issues related to this system. In this section we briefly describe the Indivo system with a focus on the current access control model. The information presented in this section serves as a basis for further discussion in the remainder of this paper. 2.1 The Indivo PCHR • The Indivo code is open source and available for anyone to download and customize or adapt to their needs. • Public health surveys may be deployed through Indivo and the patient given the option to participate. 2.2.1 Access Control in Indivo When a user is registered in Indivo he is given a role (researcher, patient or provider) that is used to restrict functionality that is available to the user in the system. For example only an administrator may create new users. In addition to this, access profiles are used to set permissions when a user is sharing his record with another user. The current implementation presents the patient with a set of predefined access-profiles to choose from when sharing. An access profile is a set of permissions. Assigning an access profile to a user means granting this user all the permissions included in the profile. There are currently five access profiles that are available to a patient when sharing his record in Indivo: primary care provider, family member, friend, school and research administrator. The users that have been assigned the role of a provider has an additional access profile to choose from - patient - that allows a provider to connect with his patients in the system. The Indivo access control model provides the patient with the opportunity to share his record and to some extent also to determine what access rights are granted. However this control is limited by the predefined access profiles, and the patient has no way of knowing the exact permissions included in each profile. Through trials, system tests and focus groups the Indivo team has collected knowledge about expected use of the system, as well as concerns and wishes from the system users. This knowledge has been used to formulate a set of usage scenarios and concerns that capture requirements that needs to be fulfilled by a more comprehensive access control model for a PCHR. These usage scenarios and concerns are presented in detail in the next two sections of the paper, and serves as a basis for our proposed access control model for a PCHR. Role-Based Access Control Role-Based Access Control(RBAC) [7] has become one of the most common access control models, and is by many [8] [9] [10] [11] considered particularly well-suited for health care systems. RBAC is based on the concept of assigning permissions to roles and roles to users. Roles often correspond to positions in an organization. In other words a role represents the permissions needed to perform the responsibilities of a specific position. The access profiles mentioned in the previous section on Indivo may be considered to represent roles in the system. RBAC has become so popular because of its: • Simplicity and ease of administration. There are relatively few roles in an organization compared to the number of users. With RBAC a role has to be defined only one time and can be assigned to many users. • Flexibility. Changing responsibilities for a job position only requires updating permissions for one role, and the update is reflected for all users assigned to that role. • Scalability. As the organization grows the number of roles may remain unchanged if there are no new positions. New roles may easily be created and assigned to users as needed. 1 http://indivohealth.org 936 Paper H: An Initial Model and a Discussion of Access Control 3 Usage Scenarios 3.5 The expected use of the system is best presented by a set of usage scenarios. These scenarios have been selected because they illustrate the most common expected uses of the system, as well as a set of identified likely, but uncommon, use of a PCHR. All scenarios focus an sharing. The scenarios illustrate usage around which design decisions have to be made. Patient moving providers or changing When a patient is an infant or a child, the parent (or legal guardians) typically have access to the medical records and act as administrators on the patients behalf. They make decisions about the circumstances and conditions for sharing information. As the patient becomes older there may be specific information he wants to keep from his parents. When the patient becomes an adult he takes over as administrator. The parents does not have access anymore unless the patient chooses to share with the parents. Complicating the matter here is the fact that the rights and obligations of an adolescent and his parents is regulated by the law. These laws are specific to a country, or even state within a country, and as such, even the definition of the age-range for an adolescent may vary from one state to another. The question is which rules prevail. Patient in need of medical care while traveling A patient may become ill or injured while traveling or away from home. Through a PCHR the patient can give health care providers access to the information they need to provide proper care. 3.3 Patient is an adolescent care Very few people live in the same place for their entire life. One of the main purposes of a PCHR is to enable patients to manage access to their own health information. When moving or switching to a new care provider for other reasons, the patient may use the PCHR to grant access to his health information to his new health care provider. 3.2 Sharing in emergency situations In an emergency situation a PCHR can serve as a valuable source of information for the emergency care team. Depending on the severity of the patients injuries he may grant access or an access mechanism for emergency situations may be used. 3.6 3.1 129 3.7 Sharing with family or friends Patient has a legal guardian Sometimes a patient may want to share his health information with family or friends. Common cases may include young adults seeking advice from their parents, and persons with chronic or long-term diseases who rely on help from others. Yet another case that is expected to be common, is elderly parents seeking advice and help from their younger, and more computer-literate, children. If a patient, at any time in life, becomes incapable of caring for his own interests due to incapacity or disability, a legal guardian is appointed. The legal guardian is then acting as administrator of the record on the patient’s behalf. 3.4 Through a PCHR the patient can contribute his data to research. What data is shared depends on the research project. Sometimes, research studies reveal medical knowledge about individuals that they should be made aware of. However, as research data are usually de-identified, there is no other means for researchers to get in touch with these patients other than issuing a public notice and hoping that they read it. In [14] it was proposed how the PCHR can be utilized for this purpose. The authors suggested a model where the researches could broadcast an electronic notice. An agent within each patient’s PCHR could then examine the notice and determine if the patient should be notified. This way, the research subjects stay anonymous, but the researchers has a means of reaching specific subjects with important, targeted information. 3.8 One-time sharing There are several situations when a patient may want to share selected health information for a very limited time. Examples include colleges requesting access to the latest physical examination, insurance companies requesting a bill of health. For these situations the patient should be able to limit the time sharing is valid for. However, if a patient has chosen to share parts of his medical data with, say, an insurance company for a limited time - there is no sure technological way to keep them from making a copy of the information and keep that in their own record. The only way to force someone to ”forget” may be by law. But, through time-limited sharing one can at least deny sharing of the evolving data. 937 Sharing for research 130 4 Paper H Concerns Information sensitivity All health information is considered sensitive. However, some types of information, e.g. related to psychiatry and STDs, may be considered to be more sensitive. Information classification may be used to limit what information is shared. The main questions here are: who determines what information is ”more sensitive”? And how do we label this information? This section presents concerns that are common to all usage scenarios. These concerns represent key points and decisions that has to be made when designing the access control model. We have identified three main groups of concerns: • Simplicity • Time 4.2 • Transparency Time is a central issue when sharing information. The issue is the patient’s understanding of what is shared. Is it: Related concerns have been grouped under these headings. We will continue to use these three main groups in our discussion, to justify and explain our choices. 4.1 Time • a snapshot of the record at the time of sharing? • only historical information? Simplicity • or the evolving record also as new information is added? This is a matter of what it means to grant the patient control over his own information. What is detailed enough to facilitate all usages scenarios - yet simple enough that the patient is capable of doing it? Another issue related to time, is for how long the record is shared. Is it forever or only for a limited time period? And what happens when that time period is over? 4.3 Patient control In the simplest case; the patient is given a set of roles to select from when sharing and the roles determine the permissions granted. The roles are predefined in the system and the patient is not allowed to change them. The only options are sharing using one of those roles - or not sharing at all. On the other extreme, we have the possibility of giving the patient complete control. When sharing the patient could be allowed to specify exactly what information to share and what permissions to grant on this information. Transparency In a PCHR the users are given control to set access permissions. Tasks that are usually performed by system administrators are shifted to the users. To ensure that the users are able to take advantage of the possibilities the system presents without compromising their privacy, it is important to strive to keep the users informed about the consequences of their decisions to share. In other words the consequences of actions should be transparent to the system users. The question is how to keep the users informed. Informed sharing The patient needs to be informed about the consequences of sharing. The key here is to keep the patient informed of exactly what sharing means, so he can make informed decisions. Consequences of sharing should be obvious and the process of assigning access transparent. Sharing with identity and/or groups Through the PCHR a patient should be able to share his health information with his family, friends and health care providers. It may be the case that the patient wants to share his information with a practice rather than a specific provider at that practice. How can the patient trust this practice to enforce local access rules and protect his privacy? Auditing Extensive auditing is important to ensure traceability of actions. Audit logs are usually only accessible to system administrators. When the user is in charge of his own information, he should also be able to trace the actions of people he is sharing with. Auditing system logs is a formidable task. Providing the user with insight into access logs may help making this task easier, assuming that the user has a special interest in keeping track of who does what with his health information. The key challenge is to make the audit logs accessible and understandable to the patient. Delegation of sharing rights When sharing information with a provider, this provider may wish to share with other providers e.g. to get a second opinion. If this is allowed the patient loses control over who has access to his information. However, if this is not allowed it means the provider has to ask the patient to grant access to another provider, before they can interact. This appears inconvenient. 938 Paper H: An Initial Model and a Discussion of Access Control 5 131 An Initial Access Control Model for a PCHR In this section we present our initial access control model for a PCHR. The model is very much unfinished, but we have chosen to put it forth to generate discussion on the subject. There are many aspects of access control for a PCHR that needs to be explored further. In this section we provide a sketch of what we consider most important to focus on, and how we think this may be solved. 5.1 Simplicity Simplicity and transparency is key when the patient is put in charge of assigning access to other users. It should be easy to do and the consequences of sharing, i.e. what permissions are granted, should be obvious. Assigning permissions by selecting from a list of system-defined roles is arguably a very simple way for a user to assign permissions, but there is a tradeoff between simplicity and specificity that needs to be considered. To allow for flexibility and adaptability in privacy requirements, the user should be allowed to change a role and/or create new roles with specific permissions to fit his needs. Ideally we should like to provide both simplicity through role selection and complete specificity in selection of permissions for a user. To keep the model clean and consistent we propose an approach that allows us to do both, and keep the role as the base element for access assignment. Central to the concept of RBAC is the fact that there is an administrator that is responsible for role creation. Certain models propose allowing the user some control on role assignment and delegation [9] [15], but not on role creation or adaption. In a PCHR the patient is the administrator. Though this model takes advantage of the base principles of RBAC, the viewpoint of the administrator is fundamentally different from the usual RBAC case. Figure 1 provides an overview of the main elements of the proposed PCHR role model. There are two main classes of roles: Figure 1. PCHR role model • A set of system-defined user roles. These roles are grouped into individual roles and group-roles. Group roles allows sharing with a practice. The set of individual roles should be fairly small, not more than 10. T • User-defined user roles. These are specific to each user. The system maintains a repository for each user of the roles he have created and assigned to other users to share his record. These roles may be based on a template (adapted from a system-defined role) or created from scratch. A user-defined role may also be based on one of the users previously defined roles. The user is responsible for giving the roles he defines meaningful names. Once a role is defined, the user may use this role many times and assign it to several people. The model adopts the principle of permission inheritance from RBAC. The system-defined roles are structured in a hierarchy where lower level roles inherit permissions from higher level roles. The further down in the inheritance hierarchy, the more specific the role is. For instance one may have a parent role provider that specifies permissions common to all providers, and then a role primary care provider that inherits all the permissions of the general provider role, and adds permissions that are specific to a primary care provider. When looking up permissions for a role, the policy of the target role is combined with the policies of its parent roles. To provide specificity, we want the PCHR users to be able to subtract permissions as well. When basing a new • System roles: are assigned when a user is created in the system. There are only three system roles: patient, provider and researcher. These roles are used to restrict the functionality available in the system, and as a control when sharing. E.g. a patient may only assign the role of primary care provider to a user with the system role ”provider”. • User roles: are assigned by the patient to other system users he wants to share his record with. The system roles are straightforward. The user roles are more complex. As Figure 1 shows, the user roles are structured as follows: 939 132 Paper H 5.2 role on an existing one it should be possible to make it more restrictive in some areas, and add more permissions to others. This means that the rule when combining roles for inheritance is ”deny overrides”. If one of the roles denies the desired action, then the decision is deny. In the case of a PCHR, a user may well be assigned to a number of roles. But each role is linked to a specific record. In other words, when a patient is sharing his record he selects, or creates, only one role for this user. The assignment of a user role is specific to a record. One of the main pros of RBAC is the flexibility it provides. To update the permissions of many users one only has to change the role they are all assigned to. This is a task usually performed by a system administrator. As previously stated, for the case of PCHR the patient is the administrator. He can change the roles he has defined as he wishes and these changes are reflected in the permissions of the user he his sharing his record with. However, as Figure 1 shows the user-defined roles may be connected to the system-defined role that was a template for creation of this role. This link is permanent through an inheritance relationship. This means that any change in a system-defined role is reflected in all user roles that is related to this role through an inheritance relationship. We therefore need to be careful about allowing updates of system-defined roles. If the role changes because of an identified error in the definition or due to changes in the law, these changes should propagate and be effective throughout the system. However, if the change is a less severe update we may want to keep links to the old version of the system-defined role. The user only agreed to sharing on the basis of what the role used to be, and it should not be changed without giving the user the option of agreeing or denying to share based on the updated role. To allow for this the concept of history in the role hierarchies is introduced: Time Time is one of the main concerns listed in the previous section. In our model we propose always labeling a role assignment with a start time. The start time is required for useful audit information. In addition it should be possible, but not required, to set an end time of a role assignment. 5.3 Transparency There currently exists a major push towards patient empowerment in health care. A PCHR system is a great tool for patient empowerment as it enables the patient to exercise control over his health information. However, it also means shifting responsibility and tasks that have usually been performed by educated system-administrators over to the user. ”Everyone” is a potential patient, and therefore a potential user of a PCHR. It is safe to assume that these users will span the entire range of computer-literacy. Many will be well accustomed to the use of online services for information management like online banking, while many others will have little experience with web-based systems. A PCHR is intended to contribute to the patients sense of empowerment and control. To achieve this, the process of sharing, and auditing the shares, must be intuitive and transparent to the user. The goal is to make sure the user is always informed of the consequences of his actions. It is, however, hard to be sure that the user is always informed, and correctly informed. We suggest increasing system transparency by: • Using graphics to visualize to the patient the consequences of assigning a role. Figure 2 illustrates what this might look like in a PCHR system, illustrated by an adaption of the current Indivo-GUI. When the patient selects a role the permissions of this role are visualized in a cube representing the information in the record. A dark field with grey characters illustrates no access, a lighter shade and black characters illustrates read access, while a white field illustrates edit access. • A template-based user role is linked to a version of a system-defined role. If the system-defined role is updated, a new version is created and the links are maintained for user-roles who were based on the previous version. • Using a graphic notation to visualize an overview of current or historical shares and their permissions. • Having complete history in both role sets (user-defined and system-defined) ensures that the user can perform auditing and examine who had what permissions to his information at any given time. Without history of roles, one would only be able to tell what role a user had at some time, but could not be sure if the permissions of the role were the same then as now. • Also using this graphic notation when a user creates or adapts a role. E.g. by allowing a user to drag-and-drop a document from the sidebar menu onto the cube to add it to a sharing. • Presenting the user with a view of the audit log. This allows the user to examine who has access to his record and their actions. • For the same reason a role should never be completely deleted. Keeping history ensures that it is always possible to find a role, even if it is no longer part of the active role set. Examining access logs is often an overwhelming task. Still many systems rely on auditing of log data as a security 940 Paper H: An Initial Model and a Discussion of Access Control 133 Figure 2. Example graphic representation of access rights mechanism. However, a study [16] indicates that these log data are seldom used. By distributing this task to let each patient be responsible for auditing the access log for his own record, we reduce the workload. Our assumption is that the patient is both more motivated and knowledgeable to be able to detect any misuse of his health information. Having access to the audit log also serves an educational purpose as examining other user’s actions gives the patient insight into what the people he is sharing with are allowed to do with is information. 6 for increasing the transparency of the system. 7 Acknowledgments The author would like thank the Indivo-team at the Children’s Hospital Informatics Program in Boston for the opportunity to learn from their work. References Conclusion and Future Work [1] R. Hillestad, J. Bigelow, A. Bower, F. Girosi, R. Meili, R. Scoville, and R. Taylor. Can electronic medical record systems transform health care? potential health benefits, savings, and costs. Health Affairs, 24(5):1103–1117, 2005. In this paper we have presented a discussion of issues related to access control in a PCHR. Based on this discussion we have explored some aspects of what such an access control model would be like. However a lot of work certainly remains. In our model we have made some assumptions that needs to be explored further. For instance, we assume that most users, most of the time, will prefer sharing by selecting a role from a list. We also assume that most users will not want to set up specific permissions each time they share. Though this appears to be a valid assumption, user test should be performed and usage data collected to see if this assumption holds. We intend to continue work on the model with the goal of creating an implementation that can be tested and evaluated properly. Our work will focus on defining a default role set and continue exploring methods [2] W. R. Hersh. Medical informatics: Improving health care through information. The Journal of the American Medical Association (JAMA), 288(16):1955– 1958, 2002. [3] Connecting for health: The personal health working group final report. Technical report, Markle Foundation, July 1 2003. [4] P. C. Tang, J. S. Ash, D. W. Bates, J. M. Overhage, and D. Z. Sands. Personal health records: Definition, benefits, and strategies for overcoming barriers to adop- 941 134 Paper H tion. Journal of the Ammerican Medical Informatics Association, 2005. [15] S. Na and S. Cheon. Role delegation in role-based access control. Proceedings of the fifth ACM workshop on Role-based access control. ACM Press, Berlin, Germany, 2000. 344300. [5] M. I. Kim and K. B. Johnson. Personal health records: Evaluation of functionality and utility. J Am Med Inform Assoc, 9(2):171–180, 2002. [16] L. Røstad and O. Edsberg. A study of access control requirements for healthcare systems based on audit trails from access logs. In 22nd Annual Computer Security Applications Conference (ACSAC’06), pages 175–186, Miami, Florida, 2006. IEEE. [6] K. D. Mandl, P. Szolovits, and I. S. Kohane. Public standards and patients’ control: how to keep electronic medical records accessible but private commentary: Open approaches to electronic patient records commentary: A patient’s viewpoint. BMJ, 322(7281):283–287, 2001. [7] D. F. Ferraiolo, D. R. Kuhn, and R. Chandramouli. Role-Based Access Control. Computer Security Series. Artech House Publishers, Boston, 1 edition, 2003. [8] B. Blobel. Authorisation and access control for electronic health record systems. International Journal of Medical Informatics, 73(3):251–257, 2004. [9] L. Zhang, G.-J. Ahn, and B.-T. Chu. A role-based delegation framework for healthcare information systems. Proceedings of the seventh ACM symposium on Access control models and technologies. ACM Press, Monterey, California, USA, 2002. 507731. [10] K. Beznosov. Requirements for access control: US Healthcare domain. Proceedings of the third ACM workshop on Role-based access control. ACM Press, Fairfax, Virginia, United States, 1998. [11] M. Evered and S. Bgeholz. A case study in access control requirements for a Health Information System. Proceedings of the second workshop on Australasian information security, Data Mining and Web Intelligence, and Software Internationalisation - Volume 32. Australian Computer Society, Inc., Dunedin, New Zealand, 2004. [12] A. N. S. Institute. American national standard for information technology: Role based access control. Technical Report ANSI INCITS 359-2004, 2004. [13] W. W. Simons, K. D. Mandl, and I. S. Kohane. The ping personally controlled electronic medical record system: Technical architecture. J Am Med Inform Assoc, 12(1):47–54, 2004. [14] I. S. Kohane, K. D. Mandl, P. L. Taylor, I. A. Holm, D. J. Nigrin, and L. M. Kunkel. Medicine: Reestablishing the researcher-patient compact. Science, 316(5826):836–837, 2007. 942 Paper I Personalized Access Control for a Personally Controlled Health Record 136 Paper I Paper I: Personalized Access Control 137 Personalized Access Control for a Personally Controlled Health Record Lillian Røstad Øystein Nytrø Department of Computer and Information Science Norwegian University of Science and Technology Trondheim, Norway Department of Computer and Information Science Norwegian University of Science and Technology Trondheim, Norway [email protected] [email protected] ABSTRACT 1. INTRODUCTION Access control is a key feature of healthcare systems. Up until recently most healthcare information systems have been local to a healthcare facility and accessible only to clinicians. Currently there is a move towards making health information more accessible to patients. One example is the Personally Controlled Health Record (PCHR) where the patient is in charge of deciding who gets access to the information. In the PCHR the patient is the administrator of access control. While it certainly is possible to create roles representing people most patients would want to share with, like primary physician, it is also likely, and desirable, to afford the patients a high level of control and freedom to be able to create specialized access policies tailored to their personal wishes. We entitle this personalized access control. In this paper we present a semi-formal model for how we believe personalized access control may be realized. The model draws on and combines properties and concepts of both Role-Based Access Control (RBAC) and Discretionary Access Control (DAC) to achieve the desired properties. Throughout the paper we use the PCHR as a motivating example and to explain our reasoning and practical use of the model. Access control is a key feature of healthcare systems. Enforcing access control on sensitive health data is about protecting the patient’s privacy as well as ensuring that clinical personnel have access to the information they need to provide the best possible care. Access control has a unique challenge in that it is always most important to save the patient’s life. In other words: though confidentiality is the norm availability takes precedence when the patient’s health is at stake. A challenge in healthcare today is the lack of connectivity and sharing. Information exists in proprietary information systems local to hospitals or doctors offices and accessible only to health care personnel. Personal Health Records (PHR) have been proposed as a potential solution to this problem. The term PHR has been defined by The Markle Foundation as: Categories and Subject Descriptors The challenge with most PHRs is that they are local and specific to one point of care [4] and therefore most existing PHRs only contain a subset of a patient’s clinical information. The Personally Controlled Health Record (PCHR) has been proposed as a possibility that has the potential to solve many of the PHR’s shortcomings. The goal of a Patient/Personally Controlled Health Record (PCHR) [5] is to assemble the patient’s complete health history by importing data from many source systems. A PCHR differs from a PHR in that it exists outside of organizational boundaries and contains data from multiple care sites. Also, the patient is in complete control of the information in the PCHR. The patient decides what data should be added to the PCHR. Any data import has to be approved by the patient. The patient also decides who gets access to the information in the PCHR. This means that it is the patient who is administrator of access control [7]. Through a PCHR the patient may choose to share his data with health care providers, family members and any other as needed. One of the main challenges of the PCHR is the duality of empowerment potential and privacy risk. The patient is empowered in that he is given control over his own health information. But, it may also increase the risk of inadvertently leaking sensitive information about himself as the patient is ”An electronic application through which individuals can access, manage and share their health information, and that of others for whom they are authorized, in a private, secure, and confidential environment.”[1] H.1 [Information Systems Models and Principles]: Miscellaneous General Terms Security Keywords Access Control Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. CSAW’08, October 31, 2008, Fairfax, Virginia, USA. Copyright 2008 ACM 978-1-60558-300-6/08/10 ...$5.00. 9 138 Paper I are added to the PCHR as is routine. Her mother is concerned and asks if she can get access to the PCHR so she can read the information. Using the PCHR it is possible for the girl to give her mother access only to the parts of the PCHR that she considers ok to share. The mother is never aware of what she cannot see. solely in charge of assigning access rights and maintaining these over time. This means that it is important to have an access control model that is easy to use, hard to misuse, yet affords the patient a high-level of flexibility and control. In many healthcare systems today, Role-Based Access Control (RBAC) is the norm. Healthcare organizations fits very well the RBAC premises of having many users that can be grouped into a relatively small number of roles. One may argue that for a PCHR this is also true. For instance, most people would likely want to give their primary physician access to their PCHR. However, it is also likely that given the opportunity to share with anyone, many users will construct access policies that are personal, unique and not generalizable. As such there is a need for a model that has both a pre-defined, common set of access policies, for convenience, yet allows the patient absolute control when desired. In this paper we present a semi-formal model for what we have entitled personalized access control. The model is motivated by our work on personal health records [7] and the PCHR is used as a motivating example throughout the paper. The model is semi-formal in the sense that some properties still requires some more discussion and there remains some issues to be resolved. 3. REQUIREMENTS FOR PERSONALIZED ACCESS CONTROL Based on the previous section, we can formalize a set of requirements for our model for personalized access control for a personally controlled health record: 1. The patient is the owner of information in the PCHR. 2. Every information element in the PCHR database is owned by somebody. 3. Any information element in the PCHR database has only one owner. 4. The patient is administrator of access to his/her information. The patient decides what permissions to assign to who. 2. THE PERSONALLY CONTROLLED HEALTH RECORD 5. Information in the PCHR is structured in categories. Examples of categories include: lab results, clinical notes, immunizations etc. A PCHR is a collection of clinical information about a patient [5]. What’s unique about the PCHR is that the patient is in charge of deciding who gets access to this information by assigning sharing privileges. In this section we provide some usage scenarios to help explain the PCHR concept in more detail and how it will be used. These examples will be used for explanation throughout this paper as we move from requirements to a more detailed description of personalized access control in a PCHR. PCHR usage scenarios 6. Every information element in the PCHR belongs to a category. 7. Permissions may be granted on a category or a single information element. 8. Permissions are granted by assigning an access policy to another user. An access policy is a set of permissions. 1. A patient moves from one city to another. She decides to give her new primary physician access to her PCHR so he can read up on her medical history before their first appointment. She also decides that he should be able to add information to her PCHR, so she will have a complete medical history there in case she has to move again. 9. For ease of use it should be possible to define a set of access policies believed to be common to most users (patients). 2. A patient that has been healthy most of his life, suddenly is diagnosed with a complex disorder. This diagnosis implies that he will from now on need regular services from many health care providers including a physical therapist, an orthopaedist and an occupational therapist in addition to his primary physician. To provide the best care it is helpful if all the service providers are aware of and informed about the other services he receives and how they are progressing. The patient decides to set up a PCHR and grant all of his providers access to read the information in his PCHR. 10. For reuse purposes it should be possible for the patient to create personal access policies. 3. A young girl has had a PCHR for a while. The girl is now 17 and still not legally an adult, but as she is considered an adolescent, she is in control of the PCHR and her parents currently do not have any access. One day she has an accident on the way to school an breaks her leg. The X-ray summaries and the doctor’s notes 13. For flexibility the patient should be allowed to update or delete any of his/her self-defined access policies at any time. 11. For simplicity it should be possible for the patient to create a new access policy by adapting one of the common policies to his/her specific needs, or by extending or adapting one of his/her personal policies. 12. The patient should not be allowed to update or delete the common access policies. 14. The patient may at any time revoke an assigned access policy. 10 Paper I: Personalized Access Control 139 4. RELATED WORK our discussion by elaborating on some of the requirements and from that we construct the core PAC model. Central to the PAC model is the concept of ownership of information. Every information element in a PCHR is owned by the patient and only the owner may decide who to share information with. In other words only the owner has the power to assign and revoke permissions. And the owner can of course only share her own information. As stated in the requirements an information element has to have one, and only one, owner. Any information created in or added to the PCHR is owned by the patient: ownership is not linked to who creates information, but to who owns the PCHR the information is part of. A PCHR may over time grow very large. Therefore it does not seem like a good solution to only have the possibility of setting permissions on single information elements. However, we may take advantage of the fact that most healthcare information is heterogeneous, often with complex structure, types and relationships. Information is often grouped by topic - e.g. doctor’s notes, immunizations, x-rays etc. The specific information may be complex or simple, we just need a category tag to identify parts of the structure. A category “personal information” may subsume another category “allergies”. Note that access to “personal information” and access to “allergies” may conflict, and can only be resolved by taking the information structure into account. The actual meaning of the permissions given by a policy will thus have to be interpreted according to the information model. To simplify the PAC model, for now, we simply state that any information must belong to a category. Note that no restrictions are placed on the number of categories an information element may belong to. This has to be included for practical reasons, though it does lead to some complications when combining and interpreting policies that we will discuss further later on in this paper. As stated in the requirements, to allow for specific control and high granularity, in the PAC model it is possible to grant permissions on both specific information elements and categories. The assumption is that most of the time granting permissions on categories is sufficiently detailed. Permissions on information elements will probably only be used in specific situations e.g. like in the example of the girl with the broken leg. In general she wants her mother to see her lab results, but not the ones related to the abortion. Also, the existence of categories makes it possible to construct generalized policies, or policy templates, that can be reused. To fulfill requirements 9-13, we need to construct two sets of access policies in our model. We denote these two policy sets common policies and personal policies. The common policies are not changeable by the patient while the patient is in complete control of the personalized policies. The set of common policies, describing common relationships, should be system-wide and available to all users. As such there exists only one common policy set while there are just as many personalized policy sets as there are users that are information owners in the system, as depicted in figure 1. Note that the personal policy set for a user may be empty. We will return to the personal and common policies and discuss them in more detail after we have defined the core PAc model. In the PAC model an access policy, common or personal, may exist without being assigned to anyone. An unassigned To the best of our knowledge, no model with these exact properties have been proposed before. However, there exists work that has similarities. Most notably there are similarities to both Role-Based Access Control (RBAC)[2] and Discretionary Access Control (DAC). The concept of access policies in our model is similar to roles in RBAC. We will reuse many of the RBAC properties for combining and applying roles to our access policies. We have chosen to use the term access policy rather than role because in our model an access policy may be personal and specialized while a role in RBAC is supposed to be generalized and ”define once apply many”. In the RBAC standard [2] a role is defined as: (..) a job function within the context of an organization with some associated semantics regarding the authority and responsibility conferred on the user assigned to the role. In this traditional definition of a role, the role describes a relation between a person/set of persons and a set of objects. In our work, an access policy represents a relationship between two persons - the owner of the information in the PCHR and the person she is sharing her information with. This is significantly different from standard RBAC where a role is a mapping from a user to allowed actions on data. Our work has similarities with DAC in that information has an owner, and the owner has discretionary authority over who else can access that information. In [6] Osborn et al. presents how DAC may be implemented using RBAC. In their approach they create an owner role that is associated with each object, and declares ownership by assigning this role to a user. We will not adopt this approach since, as already stated, we are not using RBAC directly and also because while that approach shows that it is possible to implement DAC using RBAC it is not uncomplicated. Also, in DAC it is usually the case that the owner of an object is the one who created the object. For our model the owner is the one the information is about. The owner may allow others to add information, but the information created belongs to the owner of the record it is part of. In our model we need to allow negative permissions. That is, we want to be able to combine access policies to create an adapted policy that contains most of the permissions of the policies it is based on, but with some exceptions. Negative authorizations have been proposed in [3] where attribute expressions are used to prevent a user from being able to assume a role. The issues of potential conflict in negative authorizations are relevant for the use of negative permissions in our model. 5. PERSONALIZED ACCESS CONTROL In this section we present the core components of our model for personalized access control. From this point on we will use the abbreviation PAC for Personalized Access Control. We start out by defining an access policy as: Definition 1. An access policy is a representation of a relationship between two people. This relationship is reflected in the permissions one user (the owner) grants another user through policy assignment. Throughout the remainder of this paper we will assume access policy and policy to have the same meaning. We begin 11 140 Paper I Figure 1: Common and personal policies Figure 2: Core PAC Model policy represents a potential relationship. Assigning the polcy to a user means establishing a relationship between the assigner and the assignee. An example of a potential relationship is that of a primary physician as described in scenario 1. This is a relationship that most people have with one person. Most people would probably also agree that your primary physician should have access to most of your clinical information and also be able to add information. It is probably possible to create a common access policy for primary physicians with a minimal set of permissions that most people would agree is representative and appropriate. But it is only when the owner of a PCHR assigns this role to a person that the relationship user u is primary care provider for owner o is established. There are mainly two sets of users: regular users and owners. Not every user has to own data. But only users owning data have a personal policy set and the ability to share their information. 5.1 • A set A of actions • A set CP of category permissions CP = {(a, c)|a ∈ A, c ∈ C} • A set IP of information permissions. Permissions on single information elements. IP = {(a, i)|a ∈ A, i ∈ I} • A set CPol of common policies • A set PPol of personal policies • A common policy is a set of category permissions, i.e. CPol ⊆ CP. • A personal policy is a set of category permissions and information permissions, ie. PPol ⊆ CP × IP. • A function ci from a category to the set of all information elements (possibly empty) belonging to that category. Core PAC model With this in mind, we start out by defining the core concepts of the PAC model more formally. Then we move on to discussing policy definition, assignment and revocation in more detail. Figure 2 depicts the Core PAC Model. The figure shows how the relationship between two users is established by policy assignment. It also shows how a permission, in an assigned policy, is a set of allowed actions on information elements and that there is a owner relationship linking a user (the owner) directly to information elements. This model is similar to the core RBAC model [2]. The main difference is the introduction of ownership and that a policy links two users. Figure 1 illustrates that the model consists of two policy sets: a set of policies that are common and known to all users and a set of personal policies that are specific to one user. From this we define the core components of the PAC model: • A function io from an information element to the (unique) user owning that information. The concepts of common and personal policies, and hierarchies of such, are described in more detail in the following sections. 5.1.1 Common policies Common policies form policy hierarchies. These hierarchies differ from hierarchical RBAC in that they are not hierarchies under subsumption of a set of permissions, but policies related by being derivable from each other from root to node according to simple rules of addition and removal of permissions. For example, the policy “Significant other” could be related to the superior policy “Family” by adding access to all information of category “Medication” but explicitly remove (just in case it would be accessible) all information in category “Childhood diagnoses”. Thus the hierarchies form by virtue of the order that permissions are removed and added. We denote this an adaption hierarchy. It is worth noting here what adapting means. In RBAC, when one role extends another we say that there is an inheritance relationship between the roles. The RBAC standard • A set U of users • A set O of owners where O ⊆ U • A set C of categories • A set I of information elements 12 Paper I: Personalized Access Control 141 We need to state some rules for adaption relationships on policy definition: [2] defines a role inheritance relationship as: role r1 inherits role r2 if all privileges of r2 are also privileges of r1 . In the case of PAC we want to be able to base one policy on another, but we also want the flexibility to allow this new policy to be both wider and more narrow than the policy it is based on. In other words we want to be able to both add and subtract privileges, which means that we need to be able to specify negative privileges. Usually, when roles are combined the default rule is permit overrides. If one of the roles that are combined allows, then the result is allow. Negative privileges are only represented as the absence of a privilege, and the resulting permission set is the combination of all privileges in the roles that are combined. An actual role is just a set of (positive) category permissions resulting from this process. The permissions of an adapted policy is calculated by adding together all the positive permissions, removing a permission if any of the participating policies has a negative permission for this category or information element. As for roles the result of this calculation is a set of only positive permissions, and absence of a permission implies no permission. So the result of policy adaption is the same as when role hierarchies are collapsed, but the calculation process is different. In the calculation process for policy adaption the rule for policy combination is deny overrides. 5.1.2 • Adaption relationships form a lattice. • Every element in the lattice is composed of two sets: a set of positive and a set of negative permissions. • A permission is an allowed action on a category or an information element. • The resulting policy is calculated by collapsing the adaption hierarchy in the definition. The last element to be added is the set of specific permissions defined for the policy to be calculated. • Deny overrides is used as the rule for calculation. If any policy denies a permission, then that permission is left out of the resulting calculation. • The resulting policy is a set of positive permissions. 5.3 Personal policies Every user that owns information potentially has a set of personal policies. The set may be empty. As Figure 1 shows, the personal policies differ from the common policies in that they are a mapping of allowed actions on owned information elements and/or categories. A personal policy may be more specific and detailed than a common policy. This is necessary to cover those situations where a patient wants to share some of the information belonging to a category, but not all. For instance a patient may want to share knowledge of some of her test results with her mother, but not all of them, as illustrated in example 3. As for common policies we also use the concept of policy adaption for personal policy. A personal policy may: • Assigning a common policy. • Assigning a personal policy. Note that the assigned policy may depend on any number of other policies by definition. A policy assignment is a one-to-many relationship between an owner and other users. An owner may share her PCHR with many other users. An owner may also assign multiple policies to the same user. This is required to handle situations like when one person is both the father of and e.g. physiotherapist for one patient. In multiple policy assignments the permissions of the policies are combined. For this combination we apply the rule of permit overrides, and as such it is different from policy adaption. The resulting permissions are the sum of permissions in all assigned policies. If the policies to be combined are themselves defined in terms of adaption hierarchies, the adaption calculations are performed first and then the resulting policies are combined. Remember that the result of calculating an adaption is a policy containing only positive permissions. We will illustrate this process by example in the next section. • Be an independent entity. • Be based on one or more personal policies by an adaption relation. • Be based on one or more common policies by an adaption relation. • Be based on common and personal policies by adaption relations. Figure 3 provides an example adaption policy to illustrate the concept. The top node is the empty set. Note that the set contains two sub-sets: the set of positive permissions and the set of negative permissions. Each policy in the hierarchy consists of a positive and a negative permission set. 5.2 Policy assignment In PAC policy assignment is interpreted as relationship declaration. Unassigned common and personal policies may exist. An unassigned policy is simply a policy definition. Figure 2 illustrates relationships in PAC. A relationship is a direct link between two users established through a policy assignment. An owner assigns a policy (declares a relationship) by: 5.4 Policy activation A policy is activated when a user applies the policy to access information. A policy definition is simply a declaration of how one policy is related to others, and what to add or remove specifically for this policy. An assignment is simply a link between two users in the form of a policy. Only upon policy activation, when the policy is applied, is the policy definition evaluated and calculated and the relationship confirmed. For this we need a set of steps for calculating and applying the permissions of the policy to be applied: Policy definition Policy definition is about creating a set of permissions and declaring adaption relationships to other policies. Defining a common policy is simpler than a personal policy because we only deal with categories and there is no concept of ownership. For definition of personal policies we also need to include individual information elements related to an owner. 13 142 Paper I Figure 3: An example policy adaption hierarchy 5.5 1. Calculate the permissions formed by the adaption hierarchy by: first calculate adaption hierarchies formed by common policies - collapse any positive permissions together and do the same for negative permissions (two identical positive permissions results in a positive permissions, two identical negative permissions results in a negative permission etc - the presence of a negative permission at any point results in a removal of the corresponding positive permission if it is present), then take the result of this operation and do the same with any personal policies that are part of the adaption hierarchy. The result will be a set of negative permissions that is the union of all negative permissions in the adapted policies, and a set of positive permissions that is the set of all positive permissions in the adapted policies for which no corresponding negative permission exists in any of the adapted policies. Policy update As stated in the requirements the personalized policies may be changed by the owner at any time. Changing or updating a policy includes adding or removing specific permissions or adding or removing policies from the policy adaption set. As stated above, the actual policy to be used is recalculated every time it is applied and as such any change will be reflected immediately. Though this approach results in a very flexible model, it also results in potential problems. If the owner changes one of her policies – is it safe to assume that she is able to grasp all the consequences of this action? Updating one policy affects all policies that are related to this one. Deleting a policy also has a cascading effect that it is difficult for the user to foresee. Potential solutions to this problem are: • Do not allow a user to change a policy when it has been defined. This is not desirable. 2. Calculate the intermediate policy by adding any positive permission specific to this policy for which there exists no negative permission, and by adding any negative permission that is not already part of the negative permission set. • Keep a complete history of policies. If a user updates one policy that only affects policies defined after this. A copy of the old policy is kept and any pre-existing policies keeps their relationship to the old version. This is safer, but may not be what the user expects to happen. 3. Calculate the resulting policy by removing the negative permission set. The policy to be applied only consists of positive permissions. When the policy is applied, the absence of a permission is interpreted as no access. • Only allow updates of policies that no other policy depends upon. 4. If more than one policy is assigned: repeat the above steps for all assigned policies. Combine the policies by calculating the union of the permissions in all the assigned policies. Again the result is a set of only positive permissions. None of these possibilities are ideal, and work remains on how policy updates should be defined in the model. 5.6 Policy revocation Relationships are not permanent. A patient may switch to a different doctor, visit another hospital etc. Even social relationships like family and friends may not be permanent. In this model the process of revocation is simple: it simply involves the owner removing the policy assignment. However, considering the motivating case, the consequences of revocation are not so simple. Assuming that the owner is This process is repeated any time a policy is applied. This may seem cumbersome and inefficient, but it affords flexibility in that any policy may be updated at any time and those changes will be reflected the next time any policy that is adapted from this one is applied. This allows great flexibility in the model. 14 Paper I: Personalized Access Control 143 in complete control she can deny anyone access. Depending on how the PCHR is used this may have unfortunate consequences. If the primary physician has relied on the PCHR to get information about other care the patient receives, suddenly losing access may result in lesser quality of the care he may provide. Still it is at the patient’s discretion to do so. While we consider these to be valid considerations, we also consider this to be out of the scope of what can be included in a model for personalized access control but certainly an issues that needs to be resolve when the model is to be realized. 7. CONCLUSIONS 6. DISCUSSION The authors would like to thank the Indivo team at the Children’s Hospital Informatics Program in Boston for the opportunity to learn from, and be inspired by, their work. In this paper we have presented a model for personalized access control for use in a personal health record. We strongly believe that the ideas put forward here are important and bring something new to the access control field. In our future work we will focus on unresolved issues, exploring the model for various cases to make it more generic and creating a reference implementation. We will also focus on usability of PAC implementations. 8. ACKNOWLEDGMENTS One of the main purposes of the PAC model is to allow the owner the power to define very specific permissions when sharing her information with someone, while at the same time preserving the flexibility provided by RBAC. Rather than having inheritance hierarchies as in standard RBAC, PAC has adaption hierarchies where it is possible to both add and subtract permissions. While this is an important property of the model, it also increases complexity by introducing the possibility for conflicting authorizations. There are also issues that are outside the scope of this model, but nevertheless are important to mention. Many of these were summarized in an earlier paper [7] but we repeat some of them here as they are important to consider. The introduction of PCHRs is a step on the way to patient empowerment. Through a PCHR the patient is given complete control over who gets access to her health information. But this also implies an increased responsibility for the patient. It is important to consider how to achieve true empowerment. How do we make sure that the patient understands the consequences of every access decision she makes? Usability becomes an important feature of any implemented access mechanism based on PAC to ensure that the intentions of the model are achieved. We believe that visualization, how permissions, assignments and consequences are displayed to the user, can be used to increase the users’ understanding and as such the usability of a PAC implementation. We intend to develop a set of potential visualization interfaces for PAC, in a PCHR, and perform a usability study to get feedback on the different interfaces. Such a study will yield important knowledge about the users’ reactions to using PAC that will serve as valuable feedback to improving the model. 9. REFERENCES [1] Connecting for health: The personal health working group final report. Technical report, Markle Foundation, July 1 2003. [2] American national standard for information technology - role based access control. Technical Report INCITS 359-2004, American National Standards Institute, Inc., 3 February 2004. [3] M. A. Al-Kahtani and R. Sandhu. Rule-based rbac with negative authorization. Computer Security Applications Conference, 2004. 20th Annual, pages 405–415, 6-10 Dec. 2004. [4] M. I. Kim and K. B. Johnson. Personal health records: Evaluation of functionality and utility. J Am Med Inform Assoc, 9(2):171–180, 2002. [5] K. D. Mandl, P. Szolovits, and I. S. Kohane. Public standards and patients’ control: how to keep electronic medical records accessible but private commentary: Open approaches to electronic patient records commentary: A patient’s viewpoint. BMJ, 322(7281):283–287, 2001. [6] S. Osborn, R. Sandhu, and Q. Munawer. Configuring role-based access control to enforce mandatory and discretionary access control policies. ACM Trans. Inf. Syst. Secur., 3(2):85–106, 2000. [7] L. Røstad. An initial model and a discussion of access control in patient controlled health records. In The International Workshop on Privacy and Assurance (WPA-2008), Proceedings of the The International Conference on Availability, Reliability and Security (ARES 2008), Barcelona, Spain, 2008. IEEE Computer Society. 15 144 Paper I Paper J Patient-Administered Access Control: a Usability Study 146 Paper J Paper J: Patient-Administered Access Control: a Usability Study 147 Patient-Administered Access Control: a Usability Study Lillian Røstad and Ole Andreas Alsos Norwegian University of Science and Technology Department of Computer and Information Science Sem Sælands vei 7-9, 7491 Trondheim, Norway {lilliaro, oleanda}@idi.ntnu.no Abstract—Patient-Controlled Health Records (PCHRs) allow patients complete control over their health information. They decide who to share their information with, which makes the patient the administrator of access control. While PCHRs have a great potential for patient empowerment, they have an equally great risk for breach of privacy if consequences of sharing are not completely clear to the patient. This paper presents results from a usability evaluation study that compares three different visual interfaces for sharing in a PCHR. The goal of this study was to investigate how users understand and react to the concept of sharing. The study found that when given the opportunity to do so the users wanted to exercise detailed control. The study also indicated that defined templates for sharing in a PCHR has a lot of authority as users assume them to be created by experts and therefore “correct”. I. I NTRODUCTION A major challenge in healthcare today is the fractured nature of clinical information. A patient’s health record does not exist as one single unit, but rather as small fractions of information scattered among many information systems and accessible only within the organizations where those systems exist. As a result it is rarely the case that a clinician has the complete health history of a patient available when making important clinical decisions. Personal health records (PHR) have been proposed as a possible solution to this problem. According to the Markle foundation, a PHR is [3]: “An electronic application through which individuals can access, manage and share their health information, and that of others for whom they are authorized, in a private, secure, and confidential environment.” A patient-controlled health record (PCHR) [6] is an extension of the PHR concept. Once information has been entered into a PCHR, the patient is considered the owner of that information and is in complete control of deciding who gets access to it, and what they are allowed to do. In other words: in a PCHR the patient is the administrator of access control. This leads to a number of challenges, the most important of which, and the focus of this paper, is how to keep the patients informed about the consequences of their actions when they share sensitive health data with others. Though a PCHR potentially is a useful tool for patient empowerment, it may as well lead to increased risk for the patient in terms of privacy breaches. Healthcare information is sensitive and Fig. 1. Access control in a PCHR access control policies are usually created by panels of highly knowledgeable individuals and the administration of those policies carried out by trained experts. However, everybody is a potential patient and therefore the potential user of a PCHR is anybody. Hence the protection of patient privacy relies on the usability of the actual access control interface or sharing interface used in the PCHR. The effects and consequences of sharing must be obvious to the patient. We believe that visualization of data and permissions may help improve this. This paper reports on a comparative usability evaluation study performed on three different designs of the sharing interface for a PCHR. The objective of the study was to find out how users understand and react to the concept of sharing in a PCHR. An additional objective was to explore how the user interface for sharing should be designed. II. T HE I NDIVO PCHR The designs were based on the Indivo1 PCHR [8]. The Indivo system is an open-source PCHR developed by the Children Hospital’s Informatics Programme (CHIP2 ) in cooperation between MIT and Harvard. Figure 1 illustrates the underlying access control model in Indivo. In Indivo the patient grants permissions to individuals by assigning an access profile to them. The access profile consists of a set of permissions and a permission is an allowed operation (e.g. read, write) on a piece of information (or section of the record). Figure 2 shows the sharing interface in Indivo as it is today. To share with someone the patient 1 http://www.indivohealth.org 2 http://www.chip.org 148 Paper J 2 Fig. 3. List style visualization of sharing involvement in healthcare. It remains to be seen if people trust Google or Microsoft to manage their health data. IV. T HE P ROTOTYPES Fig. 2. The original Indivo sharing interface has to enter this other persons Indivo user ID and assign permissions by selecting an access profile from a list. The main shortcomings of the existing sharing interface is that it is not possible for the patient to see what permissions are included in an access profile. In this study we use the same underlying access control model as is in Indivo today. However, the sharing interface i.e. how the model is communicated to the user - was enhanced on several points: • A visual component was added to communicate to the user the permissions contained in an access profile. • The visual component was made modifiable to allow the user to change access profiles. • The user was also given the opportunity to create new access profiles by using the visual component. III. R ELATED WORK This paper is about coupling security research and research on human-computer interaction (HCI). The underlying assumption is that for a system to be secure it has to be usable. In [9], Marko and Simon introduce the term user-centered security to refer to security models, mechanisms, systems, and software that have usability as a primary motivation or goal. The current study is in line with this in addition to usercentered security engineering [7]; the purpose is to involve the users in the design and evaluation of security models and mechanisms. Recently, both Microsoft and Google have presented PCHR initiatives. Google Health [1] is an online repository where you can import health information and share with providers. Google Health was launched in early 2008. Microsoft launched a similar initiative, HealthVault [2], in the fall of 2007. Both systems are so far only accessible to people living in the US and hence it has not been possible to study their access control models in detail. The added challenge for these PCHRs is that they are created by commercial companies with no historical Three prototypes were developed based the Indivo user interface. All three used the same underlying information structure, functionality and access control model. Information is grouped in categories and every category may have subcategories. For the purpose of this study we only used the permissions “edit” and “read”. All versions enabled the user to share specific parts of the health record to other persons, such as the primary care provider or a family member. Having three different prototypes allowed us to use a comparative approach in the usability evaluations were the best design solutions from the best prototypes could be used as a basis for the final design. The only functional part was the sharing interface, but the rest appeared exactly like the standard Indivo interface. The reasoning behind this is that the participants were recruited from the Indivo trial population and were already familiar with the system. Even though all the prototypes allowed the user to create their own access profiles, we also kept the list of “templates”. The purpose was to investigate whether the existence of templates was desired or not, if the users would want to change an existing template, or if they wanted to create their own profiles. The prototypes (list, cube and rainbow) are presented in the following sections. List: The List prototype displays a list of all the information categories with checkboxes to set read and edit permissions (see Figure 3). A row is permanently highlighted if permissions are set to give the user a quick impression over categories with read/edit permissions. Highlighting every row where permissions are set gives an immediate impression of how many categories that are accessible to others. Cube: The Cube prototype displays a matrix with threestate toggle buttons for all categories and their sub categories. Pressing the corresponding button sets the permissions for a category. The cube, shown in Figure 4, was designed primarily to visualize how much of information the used is sharing. It uses coloring to visualize permissions. Rainbow: The Rainbow implementation displays a three state toggle button besides each category and subcategory, which show the permission state. The design, shown in Figure 5, was designed to take advantage of the existing left hand menu and to save space. As permissions are changed using the rainbow, the coloring of the menu items changes to connect them visually. Paper J: Patient-Administered Access Control: a Usability Study 149 3 They were recruited from the Indivo MIT 3 study population and from CHIP 4 . The participants had some prior knowledge of the system and were familiar with the PCHR concept and the idea of sharing health data. They were not familiar with the concept of sharing parts of the health record. All participants were technically skilled, and are as such not entirely representable for the population in general. However, prior knowledge of the system was required for this test because we wanted to evaluate a new Indivo concept, not usability of Indivo itself. Recordings: Video and audio of the users interaction with the system was recorded during the usability tests. In addition, a log of every access profile created by the user was collected. Fig. 4. Cube style visualization of sharing B. Evaluation procedure Fig. 5. Rainbow style visualization of sharing V. U SABILITY EVALUATION A comparative approach was used in the study. Such studies are used from time to time in usability evaluations. In these studies two or more design versions of the same system are tested with representative users. There are several reasons for performing comparative studies, for example to generate quantitative data on user performance [5] or to encourage user reflection [4]. The test procedure followed a general procedure consisting of (1) a preliminary briefing, (2) usability evaluation of the three prototypes, (3) a concluding interview, and (4) a card ranking exercise. Preliminary briefing: The users were given a short preliminary briefing. They were explicitly informed that they were using mock-up prototypes where any changes made would not be reflect in their own PCHR. In addition information about their prior experience with Indivo was collected. Usability evaluation: The users were introduced to the tasks and asked to complete them one at a time. They were instructed to think aloud during the evaluation and were not offered any help. Concluding interview: The test participants were interviewed and encouraged to sum up and give further comments on the user interfaces. Their opinions about template access profiles, and whom they would like to share the health record data with, were collected. Card ranking: For each prototype an illustration representing it was printed on a card. After completing the tasks, the participants were asked to rank these cards after preference and encouraged to give reasons for their decision. The purpose was to revive the participants memory, to support user reflection and to collect quantitative data on their preference. A. Evaluation setup Physical setting: The evaluations took place in a usability lab resembling an office with a desktop, chair and a laptop computer. User tasks: The participants were given the tasks of setting the access rights of the EHR and sharing it with these settings with (1) their primary care provider, (2) their physical therapist, and (3) their mother. The first task allowed them to use an existing Indivo profile, the second task required them to create a new profile, and the third task encourage them to modify an existing profile. Prototypes: Each test participant evaluated all three Indivo prototypes. To minimize the impact of learning effects, the ordering of the prototypes were randomized for each user. Participants: 12 participants, ranging from 1st-year college students to retirees, participated in the usability evaluation. VI. R ESULTS A. Familiarity Most participants reported that they had used the system before. Many had answered surveys on request, and some had also imported their health information5. However, none of the participants had ever used the sharing interface before. This reflects that the Indivo study at MIT has been ongoing for a while, but the users have not started to use the system to its full potential yet. However, all participants were aware that they could use the system to share their health information. 3 Massachusetts Institute of Technology Hospital Informatics Program is only imported into Indivo when the user takes an explicit action to do so 4 Children’s 5 Information 150 Paper J 4 B. Comments on the prototypes The three interaction styles received different comments from the test participants. List: The design solution based on the list was perceived as simple and intuitive to use for most users. 9 of the 13 test participants selected this design solution as their most preferred, and non as their least preferred. Many users commented the benefits of being able to see all options at the same time and the familiarity of checkboxes. They also emphasized the learnability of the interface; it was easy to understand and learn without additional instructions. However, some test participants commented that they where intimidated by the long list. Others pointed towards the other design solutions and liked how it was just one block that said read/edit rather than two. In addition they disliked the amount of clicking in the interface. Cube: Three of the study participants selected the cube as their favorite. However it was also the least favorite of 5 participants. The cube design was experienced as cleaner and less confusing by some users. However, several users criticized the choice of coloring and complained that the contrast was too low; it was hard to tell the difference between the blue shades for read and edit. Some users also were uncertain if edit permissions included read permissions. Others thought the legend below the cube was a way to change settings. Rainbow: Only one study participant selected the rainbow as favorite. It was the least favorite of 6 participants. Some users commented that this solution was a nice way to avoid repetition. However, in general most participants found this method difficult to use. Most users commented the lack of visual cues. The participants used much time to understand this solution compared to the others. Many started clicking the menu and it took a while to realize that the rainbow was clickable. Access profiles: Most people stated that it made sense to have templates for access profiles. However, templates conserned some users, as this quote shows: “This kind of thing to my mind has so much authority (...) Is that what I’m supposed to tell my physician, is that what they require me to tell my physician, or is that what my physician said he needs to know, or what?” This is clearly something that needs to be considered carefully. A template is not just for convenience, but may also be perceived as a suggestion made by someone with authority in the matter (in this case the system and/or whoever made it), and people may choose to use the template because they reason that it was created by someone who knows best. The functionality of the prototypes was such that the participants could choose to either use one of the templates unchanged, create a profile from scratch or change one of the existing templates. If they chose to create a new or made changes in an existing they were prompted to provide a name when they clicked “save”. This new profile would then show up in the list of available templates. Some users had issues with this. Some commented that “create new access profile” should be clearly labeled as functionality and not presented in the list of templates as it is a very different thing. The prototypes automatically switched to “create new..” whenever a user made a change in an existing profile. This was intended to make the system more usable, but turned out to confuse many. Some users selected a profile, made some changes and upon realizing that the profile they had wanted was no longer selected then re-selected it, which meant that they lost all the changes they had made. Clearly this switch should not be done without notifying the user explicitly. Most users who encountered this issue also commented that when they selected a profile and changed it, they expected it to be saved with the same name and different content. In other words they expected to be able to update the profile itself, rather than creating a new one based on the existing profile. Some users also expressed surprise that the profiles they created showed up in the list of profiles afterwards. However, even if this was unexpected for some they also thought it was a good idea. One user suggested that maybe the list should be divided into two parts: the profiles suggested by the system and the ones you have created yourself. On the question of who to share with, most simply answered their provider, any other clinician they have a treatment relationship with, and family. They were probably guided by the templates available in the prototypes. Most also stated that as long as they were healthy or didn’t have any illnesses they considered embarrassing or otherwise sensitive, they were not that concerned about sharing. But most of them also said that this could change if their health status changed. Save vs. share: Several users were concerned or confused that the button to confirm selection/creation of a profile said “save”. To make the action more explicit, some users commented that the button should say “share”. “So if I didn’t wanna change it save means share. But if I do wanna change it save means save.” Information content: Several users were concerned that they didn’t know the exact information content of the categories. Some said that they would like to be able to browse their record and look up information and then go back to the sharing interface to continue, but they were afraid that they would loose their changes if they did that. On staying informed: Many users were concerned about the consequences of sharing health information with someone and how they would know what those people were doing with the information. They also wanted the health care providers to be able to fix errors or update information. However, it was very important for the users to get notifications if these persons changed something. They also wanted to be able to track changes and see who did them. On being allowed to make changes: The main feature of these demos was that they actually allowed the user to change profiles before assigning them to someone. The participants were not told to do so - because an important part of the usability test was to see if the designs themselves communicated to the users that they could change them. Some users took a bit longer than others to realize this. The users who got to do the tasks on the list style interface first got it immediately. It was a bit more difficult for the ones who Paper J: Patient-Administered Access Control: a Usability Study 151 5 started out with the cube, and of the ones that started out with the rainbow, several did not realize they could make changes until they got to the next demo. It was very interesting to note that once they realized that they could make changes, every user did that for every task. This indicates that given the opportunity to exercise control, the users would like to do so. VII. D ISCUSSION In this comparative usability evaluation of three versions of a PCHR, we have found that, given the opportunity, most users would like to exercise detailed control of their health record. Further, we have found that users need to be notified when other change their EHR, that they want to control the access profiles, and that they want to see the content of what they are sharing. None of the three evaluated designs were completely satisfactory, but we found that a simple list style was most intuitive for a majority of the users. A final design should be based on this design. With the launching of both Microsoft Health Vault and Google Health within the last year it is becoming obvious that PCHRs or PCHR-like applications is no longer just an idea. While the potential for patient empowerment is great, so are the security risks for the patient. The patient being able to actually be in control relies on the security, transparency and usability of these applications. Security and usability is often presented as being at complete odds. However, usability as a term was introduced in a security and safety context. To minimize the risk of a plain crashing because of pilot error the controls have to be designed in an intuitive, usable manner. So is the case for access controls in PCHRs. As developers we cannot rely on the technological skills of the users - they could be anyone. Sharing one’s health record is expected to be an infrequently used functionality. The chance is therefore larger that one share wrong information with wrong persons of. Consequently intuitiveness and usability is of high importance. The prototypes evaluated were simplified for test purposes and does not completely reflect a fully functional PCHR system. In a real PCHR the permission set would be more complex, at least include read, edit and append. In the evaluated prototypes we reduced the permission set to make the users’ tasks easier; their understanding of the permissions and what they mean were not the objectives of this study. VIII. C ONCLUSION AND F UTURE W ORK This paper summarizes findings from a usability study of the sharing interface in a PCHR. The study shows that users would like to exercise detailed control given the opportunity to do so. None of the evaluated interfaces were completely satisfactory. Further work should enhance the user interface and include functionality allowing the users to control access on a per-document level. IX. ACKNOWLEDGMENTS The authors thank the Indivo-team at the Children’s Hospital Informatics Program in Boston. R EFERENCES [1] Google Health, last accessed: October 31st 2008. https://www.google.com/health. [2] Microsoft HealthVault, last accessed: October 31st 2008. http://www.healthvault.com. [3] Connecting for health: The personal health working group final report. Technical report, Markle Foundation, July 1 2003. [4] O. Alsos and Y. Dahl. Toward a best practice for laboratory-based usability evaluations of mobile ict for hospitals. In Proceedings of NordiCHI 2008, 2008. [5] W. L. Bewley, T. L. Roberts, D. Schroit, and W. L. Verplank. Human factors testing in the design of xerox’s 8010 “star” office workstation. Hum. Fact. in Comp. Sys., pages 72–77, 1983. [6] K. D. Mandl, P. Szolovits, and I. S. Kohane. Public standards and patients’ control: how to keep electronic medical records accessible but private commentary: Open approaches to electronic patient records commentary: A patient’s viewpoint. BMJ, 322(7281):283–287, 2001. [7] D. Markotten. User-centered security engineering. In Proceedings of the 4th EurOpen/USENIX Conference-NordU2002, 2002. [8] W. W. Simons, K. D. Mandl, and I. S. Kohane. The ping personally controlled electronic medical record system: Technical architecture. J Am Med Inform Assoc, 12(1):47–54, 2004. [9] M. E. Zurko and R. T. Simon. User-centered security. In NSPW ’96: Proceedings of the 1996 workshop on New security paradigms, pages 27–33, New York, NY, USA, 1996. ACM. 152 Paper J Bibliography [1] Connecting for health: The personal health working group final report. Technical report, Markle Foundation, July 1 2003. [2] Unified modeling language: Superstructure. Technical report, Object Management Group (OMG), August 2005. http://www.omg.org. [3] The asgaard project. URL: http://www.asgaard.tuwien.ac.at. Last accessed: June 18th 2008. [4] Google health. URL: https://www.google.com/health. Last accessed: June 18th 2008. [5] Ieee std 1471-2000 ieee recommended practice for architectural description of software-intensive systems. Technical report, IEEE, 2000. [6] Microsoft healthvault. URL: http://www.healthvault.com. Last accessed: June 18th 2008. [7] St. olavs hospital medical ward. http://www.stolav.no/stolav/Virksomhet/ behandling/medisin/index.htm. Last accessed: June 18th 2008. URL: [8] M. A. Al-Kahtani and R. Sandhu. Rule-based rbac with negative authorization. Computer Security Applications Conference, 2004. 20th Annual, pages 405–415, 6-10 Dec. 2004. ISSN 1063-9527. doi: 10.1109/CSAC.2004.32. [9] I. Alexander. Misuse cases: Use cases with hostile intent. IEEE Software, 20 (1):58–66, 2003. [10] I. Alexander. Misuse cases help to elicit non-functional requirements. Computing & Control Engineering Journal, 14(1):40–45, 2003. [11] I. Alexander. Initial industrial experience of misuse cases in trade-off analysis. In IEEE Joint International Conference on Requiremenst Engineering, Essen, Germany, 2002. IEEE. 154 Bibliography [12] I. Alexander. Modelling the interplay of conflicting goals with use and misuse cases. In Goal-Oriented Business-Process Modeling (GBMP) 2002, volume 109, London, UK, 2002. CEUR Workshop Proceedings. [13] I. Alexander. Modelling the interplay of conflicting goals with use and misuse cases. In International Workshop on Requirements Engineering: Foundation for Software Quality (REFSQ) 2002, Essen, Germany, 2002. [14] I. Alexander and N. Maiden. Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle. John Wiley & Sons, 2004. ISBN: 0470861940. [15] R. J. Anderson. A security policy model for clinical information systems. Proceedings of the 1996 IEEE Symposium on Security and Privacy. IEEE Computer Society, 1996. [16] E. Barka and R. Sandhu. Framework for role-based delegation models. In Annual Computer Security Applications Conference (ACSAC), pages 168– 176, 2000. [17] J. Barkley, K. Beznosov, and J. Uppal. Supporting relationships in access control using role based access control. In RBAC ’99: Proceedings of the fourth ACM workshop on Role-based access control, pages 55–65, New York, NY, USA, 1999. ACM. ISBN 1-58113-180-1. doi: http://doi.acm.org/10. 1145/319171.319177. [18] K. Beznosov. Requirements for access control: US Healthcare domain. Proceedings of the third ACM workshop on Role-based access control. ACM Press, Fairfax, Virginia, United States, 1998. ISBN: 1581131135. [19] B. Blobel. Authorisation and access control for electronic health record systems. International Journal of Medical Informatics, 73(3):251–257, 2004. ISSN: 1386-5056. [20] N. K. Denzin and Y. S. Lincoln. Handbook of Qualitative Research. Sage Publications, Inc, 2 edition, 2000. ISBN: 0761915125. [21] T. Dingsoyr and N. Moe. The process workshop: a tool to define electronic process guides in small software companies. Software Engineering Conference, 2004. Proceedings. 2004 Australian, pages 350–357, 2004. doi: 10.1109/ASWEC.2004.1290488. [22] W. Essmayr, S. Probst, and E. Weippl. Role-based access controls: Status, dissemination, and prospects for generic security mechanisms. Electronic Commerce Research, 4(1-2):127–156, 2004. ISSN 1389-5753. [23] M. Evered and S. Bögeholz. A case study in access control requirements for a Health Information System. Proceedings of the second workshop on Australasian information security, Data Mining and Web Intelligence, and Bibliography 155 Software Internationalisation - Volume 32. Australian Computer Society, Inc., Dunedin, New Zealand, 2004. [24] D. Ferraiolo and R. Kuhn. Role-based access control. In Proceedings of 15th National Computer Security Conference, 1992. [25] D. F. Ferraiolo, R. Sandhu, S. Gavrila, D. R. Kuhn, and R. Chandramouli. Proposed nist standard for role-based access control. ACM Trans. Inf. Syst. Secur., 4(3):224–274, 2001. ISSN 1094-9224. doi: http://doi.acm.org/10. 1145/501978.501980. [26] D. F. Ferraiolo, D. R. Kuhn, and R. Chandramouli. Role-Based Access Control. Computer Security Series. Artech House Publishers, Boston, 1 edition, 2003. ISBN: 1580533701. [27] D. F. Ferraiolo, S. Gavrila, V. Hu, and D. R. Kuhn. Composing and combining policies under the policy machine. In SACMAT ’05: Proceedings of the tenth ACM symposium on Access control models and technologies, pages 11–20, New York, NY, USA, 2005. ACM. ISBN 1-59593-045-0. doi: http://doi.acm.org/ 10.1145/1063979.1063982. [28] M. J. Field and K. N. Lohr. Clinical practice guidelines: Direc-tions for a new program,. Technical Report The National Academy of Sci-ences, 1990. [29] D. G. Firesmith. Security use cases. Journal of Object Technology, 2(3):53–64, 2003. [30] C. K. Georgiadis, I. Mavridis, G. Pangalos, and R. K. Thomas. Flexible team-based access control using contexts. In SACMAT ’01: Proceedings of the sixth ACM symposium on Access control models and technologies, pages 21–27, New York, NY, USA, 2001. ACM. ISBN 1-58113-350-2. doi: http: //doi.acm.org/10.1145/373256.373259. [31] D. Gollmann. 0471978442. Computer Security. John Wiley & Sons, 1999. ISBN: [32] W. R. Hersh. Medical informatics: Improving health care through information. The Journal of the American Medical Association (JAMA), 288(16): 1955–1958, 2002. [33] R. Hillestad, J. Bigelow, A. Bower, F. Girosi, R. Meili, R. Scoville, and R. Taylor. Can electronic medical record systems transform health care? potential health benefits, savings, and costs. Health Affairs, 24(5):1103–1117, 2005. [34] P. Hope, G. McGraw, and A. I. Anton. Misuse and abuse cases: Getting past the positive. IEEE Security & Privacy, 2(3):90–92, May/June 2004. 156 Bibliography [35] V. C. Hu, D. A. Frincke, and D. F. Ferraiolo. The policy machine for security policy management. In ICCS ’01: Proceedings of the International Conference on Computational Science-Part II, pages 494–506, London, UK, 2001. Springer-Verlag. ISBN 3-540-42233-1. [36] A. N. S. Institute. American national standard for information technology: Role based access control. Technical Report ANSI INCITS 359-2004, 2004. [37] S. Jajodia, P. Samarati, V. S. Subrahmanian, and E. Bertino. A unified framework for enforcing multiple access control policies. SIGMOD Rec., 26 (2):474–485, 1997. ISSN 0163-5808. doi: http://doi.acm.org/10.1145/253262. 253364. [38] S. Jajodia, P. Samarati, M. L. Sapino, and V. S. Subrahmanian. Flexible support for multiple access control policies. ACM Trans. Database Syst., 26 (2):214–260, 2001. ISSN 0362-5915. doi: http://doi.acm.org/10.1145/383891. 383894. [39] M. I. Kim and K. B. Johnson. Personal health records: Evaluation of functionality and utility. J Am Med Inform Assoc, 9(2):171–180, 2002. [40] I. S. Kohane, K. D. Mandl, P. L. Taylor, I. A. Holm, D. J. Nigrin, and L. M. Kunkel. Medicine: Reestablishing the researcher-patient compact. Science, 316(5826):836–837, 2007. [41] A. Kumar, N. Karnik, and G. Chafle. Context sensitivity in role-based access control. SIGOPS Oper. Syst. Rev., 36(3):53–66, 2002. ISSN 0163-5980. doi: http://doi.acm.org/10.1145/567331.567336. [42] K. D. Mandl, P. Szolovits, and I. S. Kohane. Public standards and patients’ control: how to keep electronic medical records accessible but private commentary: Open approaches to electronic patient records commentary: A patient’s viewpoint. BMJ, 322(7281):283–287, 2001. [43] J. McDermott. Abuse case models for security requirements analysis. In Symposium on Requirements Engineering for Information Security (SREIS), Indianapolis, USA, 2001. [44] J. McDermott and C. Fox. Using abuse case models for security requirements analysis. In Annual Computer Security Applications Conference, Phoenix, Arizona, 1999. [45] G. McGraw. Software Security - Building Security In. Addison-Wesley Software Security Series. Addison-Wesley (Pearson Education), Boston, 1 edition, 2006. ISBN: 0321356705. [46] P. H. Meland, L. Røstad, and I. A. Tøndel. How to mediate between information security and patient safety. In Proceedings of the Eight International Bibliography 157 Conference on Probabilistic Safety Assessment and Management (PSAM8), New Orleans, 2006. [47] S. Miksch, Y. Shahar, and P. Johnson. Asbru: A task-specific intention-based, and time-oriented language for repre-senting skeletal plans. In 7th Workshop on Knowledge Engi-neering: Methods and Languages (KEML-97), 1997. [48] S. Na and S. Cheon. Role delegation in role-based access control. Proceedings of the fifth ACM workshop on Role-based access control. ACM Press, Berlin, Germany, 2000. [49] S. Osborn, R. Sandhu, and Q. Munawer. Configuring role-based access control to enforce mandatory and discretionary access control policies. ACM Trans. Inf. Syst. Secur., 3(2):85–106, 2000. ISSN 1094-9224. doi: http://doi.acm. org/10.1145/354876.354878. [50] M. Peleg, S. Tu, J. Bury, P. Ciccarese, J. Fox, R. Greenes, R. Hall, P. Johnson, N. Jones, A. Kumar, S. Miksch, S. Quaglini, A. Seyfang, E. Shortliffe, and M. Stefanelli. Comparing computer-interpretable guideline models: a casestudy approach. JAMIA, 10(1):52–68, 2003. [51] R. Sandhu. Roles versus groups. In RBAC ’95: Proceedings of the first ACM Workshop on Role-based access control, page 7, New York, NY, USA, 1996. ACM. ISBN 0-89791-759-6. doi: http://doi.acm.org/10.1145/270152.270163. [52] R. N. Shiffman, Y. Liaw, C. A. Brandt, and G. J. Corb. Computer-based guideline implementation systems: A systematic review of functionality and effectiveness. JAMIA, 6:104–114, 1999. [53] F. Siewe, A. Cau, and H. Zedan. A compositional framework for access control policies enforcement. In FMSE ’03: Proceedings of the 2003 ACM workshop on Formal methods in security engineering, pages 32–42, New York, NY, USA, 2003. ACM. ISBN 1-58113-781-8. doi: http://doi.acm.org/10.1145/1035429. 1035433. [54] W. W. Simons, K. D. Mandl, and I. S. Kohane. The ping personally controlled electronic medical record system: Technical architecture. J Am Med Inform Assoc, 12(1):47–54, 2004. [55] G. Sindre and A. L. Opdahl. Capturing security requirements through misuse cases. In Norsk Informatikkonferanse (NIK), Tromsø, Norway, 2001. [56] G. Sindre and A. L. Opdahl. Eliciting security requirements by misuse cases. In 37th International Conference on Technology of Object-Oriented Languages and Systems (TOOLS-Pacific 2000), pages 120–131, Sydney, Australia, 2000. [57] G. Sindre and A. L. Opdahl. Eliciting security requirments with misuse cases. Requirements Engineering, 10(1):34–44, 2005. 158 Bibliography [58] G. Sindre and A. L. Opdahl. Templates for misuse case description. In Seventh International Workshop on Requirements Engineering: Foundation of Software Quality (REFSQ’2001), Interlaken, Switzerland, 2001. [59] G. Sindre, A. L. Opdahl, and G. F. Brevik. Generalization/specialization as a structuring mechanism for misuse cases. In 2nd Symposium on Requirements Engineering for Information Security (SREIS’02),, Raleigh, NC, USA, 2002. [60] G. Sindre, D. G. Firesmith, and A. L. Opdahl. A reuse-based approach to determining security requirements. In 9th International Workshop on Requirements Engineering: Foundation for Software Quality (REFSQ’03), Klagenfurt/Velden, Austria, 2003. [61] I. d. Sørby, T. B. Røst, and Ø. Nytrø. Empirical grounding of guideline implementation in cooperative clinical care situations. In AI Techniques in Healthcare: Evidence-based Guidelines and Protocols, Riva del Garda, Italy, 2006. [62] F. Swiderski. Threat Modeling. Microsoft Press U.S., 2004. ISBN: 0735619913. [63] P. C. Tang, J. S. Ash, D. W. Bates, J. M. Overhage, and D. Z. Sands. Personal health records: Definition, benefits, and strategies for overcoming barriers to adoption. Journal of the Ammerican Medical Informatics Association, 2005. [64] R. K. Thomas. Team-based access control (TMAC): a primitive for applying role-based access controls in collaborative environments. Proceedings of the second ACM workshop on Role-based access control. ACM Press, Fairfax, Virginia, United States, 1997. [65] R. K. Thomas. Team-based access control (tmac): a primitive for applying role-based access controls in collaborative environments. In RBAC ’97: Proceedings of the second ACM workshop on Role-based access control, pages 13–19, New York, NY, USA, 1997. ACM. ISBN 0-89791-985-8. doi: http://doi.acm.org/10.1145/266741.266748. [66] R. K. Thomas and R. S. Sandhu. Task-based authorization controls (tbac): A family of models for active and enterprise-oriented autorization management. In Proceedings of the IFIP TC11 WG11.3 Eleventh International Conference on Database Securty XI, pages 166–181, London, UK, UK, 1998. Chapman & Hall, Ltd. ISBN 0-412-82090-0. [67] W. Tolone, G.-J. Ahn, T. Pai, and S.-P. Hong. Access control in collaborative systems. ACM Comput. Surv., 37(1):29–41, 2005. [68] R. Tuchinda. Access control mechanism for intelligent environments. Bitstream: The MIT Journal of EECS Student Research, 2002. [69] D. Verdon and G. McGraw. Risk analysis in software design. IEEE Security & Privacy, 2(4):79–84, 2004. Bibliography 159 [70] J. Viega and G. McGraw. Building Secure Software: How to Avoid Security Problems the Right Way. Addison Wesley, 2001. ISBN: 020172152X. [71] M. Wilikens, S. Feriti, A. Sanna, and M. Masera. A context-related authorization and access control method based on rbac. In Symposium on Access Control Models and Technologies, pages 117–124, Monterey, California, USA, 2002. ACM. [72] L. Zhang, G.-J. Ahn, and B.-T. Chu. A role-based delegation framework for healthcare information systems. Proceedings of the seventh ACM symposium on Access control models and technologies. ACM Press, Monterey, California, USA, 2002.
* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project
advertisement
© 2021