Modelling Access Control for a Complex Healthcare Organization Ana Ferreira1
[email protected]; Ricardo Correia2
[email protected]; Luís Antunes3
[email protected]; Ernesto Palhares2
[email protected]; Pedro Farinha2
[email protected]; Altamiro Costa-Pereira2
[email protected] 1
Department of Informatics, Faculty of Medicine, University of Porto. Al. Prof. Hernâni Monteiro, 4200-319 Porto, Portugal. Tel: +351 22 5573970; Fax: +351 22 5573971 2
Biostatistics and Medical Informatics Department, Faculty of Medicine, University of Porto, Portugal. 3
Computer Science Department, Faculty of Science & LIACC, University of Porto, Portugal Keywords: e-Health patient records; security, confidentiality & access control;
Abstract The Electronic Patient Record (EPR) constitutes the informational basis for communication and cooperation in and between healthcare organizations. Information security is then essential; moreover access control, which manages the first contact between users of a system and its functionalities and features. The Biostatistics and Medical Informatics Department of Porto’s Faculty of Medicine recently implemented a centralized EPR in order to integrate heterogeneous patient information within a university hospital. More than 300 doctors access this system every day, and this number is increasing, stressing the need for the definition of a proper access control policy, and subsequent model development and implementation. This was achieved using a centralized database technology in order to perform the authentication and authorization procedures. Other technologies, such as single sign on were also implemented and worked well with the model. Further, an access control management tool was developed and is used to perform those tasks. The developed infrastructure is a good starting point to build upon because most policy procedures for this complex healthcare organization were already implemented and further modules can be added as needed.
Introduction The wide use of information systems and technologies stresses the need for healthcare organizations to integrate and manage information from various sources, types and formats. The Electronic Patient Record (EPR) constitutes the informational basis for any communication and cooperation in, and between healthcare organizations [1]. Information security is then essential, moreover when people accessing the EPR can have varied objectives, different types of access and several processes to execute [2]. Being the baseline for information security [3], access control is essential to provide because it manages the first contact between users of a system and its functionalities and features. The Biostatistics and Medical Informatics Department of Porto’s Faculty of Medicine is implementing a centralized EPR system (VEPR – Virtual EPR) [4] in order to integrate patient information within a university hospital, the Hospital S. João in Porto, Portugal. It collects reports from several department information systems (DIS) scattered among the hospital and centrally stores them in the VEPR. Information security was thought from the beginning of its implementation, being always an important goal to achieve [5] [6]. With over 1300 beds and 5000 workers from 56 departments, where about 1000 are medical doctors, any access to information needs to be properly defined, controlled and monitored. A generic but strong access control policy that reflects people’s processes and interactions with the system, without incapacitating its use, is the basis for the VEPR success and, more importantly, acceptance, trust and use. The main objective is to develop and implement a model for an access control policy defined for the VEPR within that Hospital, in order to access the system mentioned above. This paper describes the development and implementation of this model. Its implementation is based on the Role-Based Access Control (RBAC) model. However, due to the heterogeneity of healthcare professionals’ roles, activities and physical location, this model is adapted to the reality of a large healthcare organization with specific characteristics and needs.
Access Control The main objective of access control is to provide confidentiality of sensitive information, one of the main characteristics of security. Traditional multi-user operating systems, by their very nature, have simple and generic access operations and are not concerned with the meaning of the resources they handle. On the other hand, modern operating systems and applications handle quite complex access operations due to their specific user purposes and high functionality [7]. This complexity needs to be translated by generic models and specific security policies into computer understandable processes. From the several existing access control models, the one that can better translate the processes and workflow of a heterogeneous institution and allows easier administration and adaptability in large and complex environments is the non-discretionary model (RBAC - Role-Based Access Control) [8]. Apart from defining the model to be used, the development of an access control policy is required as it constitutes an essential basis for a secure system. It is the framework that expresses the need for selecting and implementing countermeasures [9] within a system. An access control policy must specify what are the rules and procedures to follow in order to provide access to confidential information.
If this access control policy is properly modeled by a generic but adaptive model, it is easier to find the exceptions or unique characteristics and model them also, according to the specificities of the system.
Case Study The VEPR system described in [4] was implemented between May 2003 and May 2004. For the last 10 months it has been scanning regularly 7 DIS within the hospital. According to the most recent statistics, an average of 2000 new reports is collected every day, from about 800 patients. The visualization module (Figure 1) was first made available in October 2004 for users to search patient reports. The number of users as well as the number of sessions has been increasing since then. This module allows users to search information about the patient and about all the reports collected from the DIS that the VEPR system integrates.
Figure 1: Visualization module to search for patient reports.
About 300 doctors access and use the system on a daily basis. Up until now, only doctors and the IT staff connected to the project development were able to access the system. This is changing, since many other healthcare professionals can also benefit from its use. Being so, and adding the fact that more people from each DIS will have access to this VEPR, and that more DIS are going to be integrated in a near future, a proper model becomes essential to face all the security issues that access control creates for this system. Moreover, the system will need a proper tool to manage the model itself as well as user information. The following sections describe how these issues were tackled.
Access Control Policy The first step towards the task of defining and implementing an access control model was to create a Security Commission, comprising several representatives of the Hospital, in order to define the access control policy for that Institution. This Commission included mainly doctors (DIS directors) but also IT specialists and an Information Security Specialist.
Its main objective was to define and enforce the ethical, medical, institutional and human procedures to take into consideration when interacting with the VEPR system. Another important aim was to make the end users of the system intervene as part of its development and implementation. This is extremely important in the healthcare environment where much resistance to change and novelty is usually found. The access control procedures were expressed in terms of roles and further, in terms of what type of action or access level was required for each one of them. Here are the main rules that were defined among the policy: About the user’s roles and access levels - medical doctors must be able to access information about all the patients; - medical doctors must be able to add notes and comments relating to the information they are accessing, and view each others’ notes; - nurses must have read access to the EPR of the patients registered within their department; - appointed medical doctors may have access to restrict and more sensitive information (this is defined in a case-by-case basis); - healthcare researchers may have temporary access to the system for I&D purposes; - there is a different login, restricted and used only for education purposes (i.e. to learn how to use the system); - administrative staff has no access to the system at present; - only a few defined IT professionals have full access to the system to be in charge of its management; About the mechanisms that need to be in place - all users of the system must be uniquely identified; - auditing and monitoring mechanisms have to be in place at all times, for all users; - administrative information about the users of the system has to be regularly updated; - break-the-glass mechanisms are implemented so that people can access information which are not authorized (specially in cases of emergency or system error); in this case, they must be warned beforehand of what they are doing and a notification to his responsible superior is sent, so that involved parties are made responsible and their actions properly registered; These were the main rules to take into account when developing the new model, described below in this paper.
Role-based Access Control Model From several existing access control models, RBAC is a model that can generally map actions and privileges to users, groups of users or the roles those users perform within the organization. These characteristics allow for easier management and better adoption of the model into the specificities and exceptions that may be necessary to model. The first step was to analyze the model and verify what was able to be adopted from it, and what issues needed a different approach, so that this model could be augmented in a way that could satisfy the policy defined above.
The following figure (Figure 2) shows what was adopted from the standard [8] (on the left) and some of the initial changes needed to model the access control policy (on the right). RBAC Standard
The New Model
1 USER
USER
N DEPTS
ROLE
ROLE
(doctor, nurse, student, researcher…)
PERMISSIONS
ACCESS LEVEL
(all, clinical limited, research, nothing …)
OPERATIONS
ACTIONS
OBJECTS
RESOURCES
(all, search, adv. search, execute…)
(all, only some features…)
Figure 2: Adoption of RBAC [9] to the VEPR system [5].
Development and Implementation of the New Model 1. Main differences
There are several issues to consider in Figure 2 that required an analysis and development of other concepts and tools to comply with the defined policy. First of all, the concepts presented in [8] had to be slightly different in order to model the access control policy mentioned above. The concept of access level was introduced because it refers to different functionalities and not only to grant access to an operation. In this case, it refers to how much a role can access and do. The access authorization of a healthcare professional may be limited to his own patients or to all the patients of the Institution where he works (as in the policy described above). The concept of actions is new. It has a bigger range in terms of what can be made within the VEPR system. It includes functionalities such as search, advanced search, listing, besides the common execute, modify or delete. The concept of resources is similar to objects and relates to what information/functionalities within the application a role is allowed to perform. In terms of roles, there are still some considerations to make since a healthcare professional belongs to a professional group (e.g. medical doctor, nurse), but also belongs to one or more professional categories (e.g. trainee, dept. director, researcher). Further, he can belong to several different projects, and can be allowed to access,
accordingly, different applications. It is necessary to properly order them in terms of which access level each one of these can translate into. We also stress that in this system a user can belong to several departments, and can have different access levels in each one of them. However, (according to our policy) a user relates only to one role (although he can belong to more than one group for that role), which will map to only one access level. The access control policy defines that the bigger access level overrides all the others, whichever department or departments the user belongs to. 2. Exceptions
There are times when some users need to have specific access control rules defined. For instance, a medical doctor may be able to see information about a specific patient, but information which is more sensitive (i.e. HIV exam results) may only be seen by those specific medical doctors defined for each case. In order to implement this, the user will inherit the privileges defined in the role and groups or departments where he belongs and, the exception rules will be added to those privileges, overriding what is defined for that role, whether those refer to more or less access rights. Due to unique healthcare characteristics, the policy break-the-glass has to be applied, for instance, in emergency situations when information needs to be accessed independently of who accesses it. It means that every user that tries to access a resource or perform an operation he is not authorized to, will be alerted for this fact, and give the choice to back off or proceed. In order to implement this kind of rules, other mechanisms need to be implemented. Some examples are mechanisms for auditing and notification that need to be included within the diagram above. A responsible party will be alerted for this proceeding and act accordingly. This is a concept under study [10] that needs to be followed closely. 3. Implementation of the Model
In order for the model to be implemented it is necessary an authentication procedure where the user is uniquely identified and associated with his profile according to the role or groups where he belongs (i.e. privileges and permissions). To associate this profile to the user, an infrastructure to model the relationships presented in Figure 2, including the exceptions, was created. This infrastructure includes entities such as users, roles (which can include subroles), resources, access levels, actions, projects, the entity that includes the privileges and connects all of them (return_profile), and also the entity that does the same for the exception rules (return_exceptions). These are all related amongst them in order to create a meaningful infrastructure to represent the model. This infrastructure was created using a relational database and its representation is as follows (Figure 3):
Figure 3 – Entity-Relationship structure for the model created
This model implements all the necessary structure as well as the exceptions needed to generate the profile for a specific user at the time he authenticates to the system. To retrieve all this information there is a centralized feature, a procedure, to search the whole structure and collect all the privileges associated to the user. This information includes all the exceptions intersected automatically with the ones already obtained. All accesses are registered by a specific database structure, separate from the one above. It registers the user, date and time and also the errors that may occur during this process. This is easy to do because the procedure itself can generate exceptions and insert error information according to the failed action. Although the infrastructure described in this section is very important to make sure the access is properly controlled, this requires the development of another infrastructure and tool to manage all the information that lies underneath. In this scope, a new management tool was created in order to manage user information as well as the model itself (Figure 4).
Figure 4: Management tool for the model.
This tool has restricted access and only specific assigned administrators for the project have permissions to access its functionalities. In a more generic context, this tool allows the creation of new projects and can associate new and existing roles and users to those projects. This modularity greatly benefits and increases the efficacy of this tool, and the model itself.
4. Technology
At the beginning of the model’s development, several studies were made in order to decide the best technologies to implement it. The first option was to use the standard LDAP v3 [11] with the Oracle Internet Directory (OID) structure (although Active Directory was also tested) in order to implement authentication, whilst the authorization rules were defined in Oracle RDBMS version 9i. However, because of institutional issues, the use of a directory infrastructure is still not totally in place, and so it was decided to implement user authentication within the Oracle Database. User passwords are not stored in clear text but encrypted using the DBMS_OBFUSCATION_TOOLKIT.MD5 package that Oracle provides. The authentication functionality uses a single Oracle procedure that accesses all the structure in Figure 3 and collects all the profile relating to one user. This procedure is modular because it can access the database itself or the OID mentioned above. This choice allows defining and implementing the exception rules, as well as providing for good mechanisms for monitoring and notification. These mechanisms were implemented within the database itself, using a different schema and the various exceptions that can be raised by the procedure. The visualization infrastructure for both the application and management tools was implemented in PHP [12]. All the management needed for the users and roles is done through calls from the PHP language to Oracle procedures, optimizing and centralizing, and at the same time hiding the code and requests needed to perform the authentication and authorization functionalities. 5. Security
This paper describes the development and implementation of an access control model for a new system implementation within a large and complex healthcare organization. As already mentioned, information security was thought from the beginning of its development, therefore the need for proper access control, amongst many other security issues. When an access control model is defined in such a way that relies on a strong and meaningful policy, this will make an easier adoption as well as provide for a correct and secure work flow. Further, it will be modular and simple to apply for other projects within the same institution. In order to make sure that whilst creating this access control infrastructure no new security problems aroused, several security aspects needed to be analysed. In terms of confidentiality, user information is stored within the database and passwords are stored encrypted as mentioned previously. An important issue to refer is the fact that all the processing is done within the database itself with the use of procedures that deal with all the information, in a centralized and controlled way. The PHP does all requests to data only through them. The use of a unique database technology allows for an easier and more successful implementation of monitoring and backups solutions. Further, all the information in transit is protected with the use of TLS (SSLv3) [13]. As a means of correcting some minor problems that may still exist, the application is being tested only by doctors, but this will soon change and more people will be able to connect and properly test the model.
Discussion The whole infrastructure and model created is a good starting point to build upon because most policy procedures were possible to implement for this large and complex healthcare organization. User intervention in the definition of the access control policy for the institution they work, and the definition of rules and procedures that they follow on a daily basis are a must in the healthcare environment. Although most of the times security is thought as a technology issue this could not be more wrong. Security is about human processes and as such it needs to be defined and understood by the executive committee in conjunction with senior IT, and then implemented by the IT staff. This is why the model presented within this paper was thought and developed by all the interested parties and therefore, is more rooted and meaningful, as well as transparent to the normal user. Technology is a means to achieve goals and only this way can it be used in an optimized and secure way. If technology is used in a centralized and controlled manner, as it was in this case, fewer problems will follow and those will be easier to tackle. As future work, there are still some issues that need to be taken into account. The policy break-the-glass needs to be fully implemented and tested. Also, after testing the model and policy in an effective way, this needs to be certified by proper authority parties (e.g. the hospital itself, the data protection commission). Future work can include the analysis and evaluation of usability and accuracy of the model. Other features that this model still does not include (e.g. different types of access control: 2 and 3 factor authentication) can also be analyzed. It is commonly thought that a model is a static definition and structure, but this does not need to be so. An access control policy, as well as an access control model cannot be static, but must be modular enough, like the one presented in this paper, in order to grow and be correctly adapted to the environment changes and characteristics.
References [1] Blobel B. Authorisation and access control for electronic health record systems. International Journal of Medical Informatics. 2004; 73(3): 251-257. [2] Kurtz G. EMR confidentiality and information security. Journal of Healthcare information management. 2003; 17(3):41-48. [3] Anderson R. Security Engineering: A guide to building dependable distributed systems. Wiley. 2001. [4] Cruz-Correia R, Vieira-Marques P, Costa P, Ferreira A, Oliveira-Palhares E, Araújo F, Costa-Pereira A. Integration of hospital data using agent technologies – a case study. AICommunications special issue of ECAI 2004 (to be published). [5] Ferreira A, Correia R, Costa-Pereira A. Securing a Web-based EPR: An approach to secure a centralized EPR within a hospital. Proceedings of the 6th International on Enterprise Information Systems. 2004; 3: 54-59. [6] Ferreira A, Cruz-Correia R, Antunes L, Palhares E, Marques P, Costa P, Costa-Pereira A: Integrity for Electronic Patient Record Reports. Proceedings of the 17th IEEE Symposium on Computer-Based Medical Systems. 2004; 4-9. [7] Gollman D. Computer Security. Wiley. 1999. [8] Ferraiolo D, Sandhu R, Gavrila S, Kuhn R, Chandramouli R. Proposed NIST Standard for Role-based Access Control. ACM Transactions on Information and systems security. 2001; 4(3):224-274. [9] Schneier B. Secrets and Lies: digital security in a networked world. Wiley. 2000. [10] Rissanen E, Firozabadi S, Sergot M. Towards a Mechanism for Discretionary Overriding of Access Control. Proceedings of the 12th International Workshop on Security Protocols, Cambridge. 2004. [11] LDAP – Lightweight Directory Access Protocol v3. Internet RFC 2251. IETF - Network Working Group 1997. Available at: http://www.faqs.org/rfcs/rfc2251.html. Accessed in May 2005. [12] PHP Group. PHP Hypertext Preprocessor. Available at: http://www.php.net. Accessed in May 2005. [13] TLS – Transport Layer Security. RFC 2246. Internet Engineering Task Force - IETF. 1999. Available at: ftp://ftp.rfc-editor.org/in-notes/rfc2246.txt. Accessed in May 2005.
