Introduction
Thanks to the rapid development in the field of information technology, healthcare providers rely more and more on information systems to deliver professional and administrative services. There are high demands for those information systems t provide timely and accurate patient medical information. High-quality healthcare services depend on the ability of the healthcare provider to readily access the information such as a patient’s test results and treatment notes. Failure to access this information may delay diagnosis, resulting in improper treatment and rising costs (Rind et al., 1997).
Compared to paper-based patient data, computer-based patient data has more complex security requirements as more technologies are involved. One of the key drivers to systematically enhance the protection of private health information within healthcare providers is compliance with the healthcare information system security standard framework and related legislation. Security standards and legislation of the healthcareinformation system are critical for ensuring the confidentiality and integrity of private health information (Amatayakul, 1999). Privacy determines who should have access, what constitutes the patient’s rights to confidentiality, and what constitutes inappropriate access to health records. Security is embodied in standards and technology that ensure the confidentiality of healthcare information and enable health data integrity policies to be carried out.
Based on the investigation of security standard and legislation, we can analyze and create basic security requirements for the healthcare information system. To meet the security requirements, it is necessary to deploy an appropriate access control policy and system within the organization. As discussed elsewhere (Sandhu, Coyne, Feinstein, & Youman, 1996), role-based access control (RBAC) is a promising technology for managing and enforcing security in a large-scale distributed system. In the healthcare industry, RBAC has already been adopted by the Health Level Seven (HL7) organization as a key access control standard (Blobel & Marshall, 2005).
HL7 was established in 1987 to develop standards for the electronic interchange of clinical, financial, and administrative information among independent healthcare-oriented computer systems. In June of 1994, HL7 was designated by the American National Standard Institute (ANSI) as an ANSI-accredited standards developer. HL7, in its draft Security Service Framework (Kratz et al., 2005) categorizes healthcare information security exposures in the following manner:
• Disclosure: Exposure, interception, inference intrusion
• Deception: Masquerade, falsification, repudiation
• Disruption: Incapacitation, corruption, obstruction
• Usurpation: Misappropriation
Although RBAC has been introduced to the latest version of HL7 (version 3) for strengthening the security features, it only includes those basic functions. Due to the complexity of the healthcare process, RBAC with only basic functions may not be sufficient. More context constraints need to be processed in addition to traditional RBAC operations.
The major contributions we have made in this article are:
• Illustrating the detailed design of a flexible and securer RBAC model for a healthcare information system based on HL7 standard;
• Introducing the basic elements of HL7 v3 and RBAC, which are necessary for us to realize our proposed model; and
• Analyzing the potential weakness of current HL7 standard and the basic RBAC model in terms of security and flexibility.
The rest of the article is organized as follows. The next section provides a general introduction and basic analysis of HL7 version 3. We then explain the RBAC concept model and describe our major work, and finish with our conclusion and future work.
HL7 Version 3 What is HL7?
Health Level Seven is one of several American National Standards Institute-accredited Standards Developing Organizations (SDOs) operating in the healthcare arena. Most SDOs produce standards (sometimes called specifications or protocols) for a particular healthcare domain such as pharmacy, medical devices, imaging, or insurance (claims processing) transactions. HL7′s domain is clinical and administrative data (HL7, 2005).
HL7 is also a non-profit volunteer organization. Its members are the providers, vendors, payers, consultants, and government groups who have an interest in the development and advancement of clinical and administrative standards for healthcare services. In its achievements so far, HL7 has already produced HL7 Version 2 (HL7 v2) specifications (HL7, 2005), which are in wide use as a messaging standard that enables disparate healthcare applications to exchange key sets of clinical and administrative data. However, the newer specification HL7 Version 3 (HL7 v3), still under development, pertains to all aspects of clinical and administrative data in health services. Unlike its older version, HL7 v3 specifications are completely based upon the extensible markup language (XML) standards, and so have potential to win an instant acceptance by developers and vendors alike.
The target system during our research is based on HL7 v3, so only HL7 v3 will be described in this article.
The lack of data and process standards between both vendor systems and the many healthcare provider organizations present a significant barrier to design application interfaces. With HL7 v3, vendors and providers will finally have a messaging standard that can provide solutions to all of their existing problems.
HL7 v3 is based on a reference information model (RIM). Although RIM is not stabilized yet, once it is stabilized, it will be the most definitive standard to date for healthcare services.
The following section will highlight some key components of RIM.
Reference Information Model
RIM is the cornerstone of the HL7 Version 3 development process. An object model created as part of the Version 3 methodology, RIM is a large pictorial representation of the clinical data (domains) and identifies the lifecycle of events that a message or groups of related messages will carry. It is a shared model between all the domains and as such is the model from which all domains create their messages. RIM comprises six main classes (Beeler et al., 2005):
1. Act: Represents the actions that are executed and must be documented as health care is managed and provided.
2. Participation: Expresses the context for an act in terms such as who performed it, for whom it was done, where it was done, and so forth.
3. Entity: Represents the physical things and beings that are of interest to and take part in health care.
4. Role: Establishes the roles that entities play as they participate in health care acts.
5. ActRelationship: Represents the binding of one act to another, such as the relationship between an order for an observation and the observation event as it occurs.
6. RoleLink: Represents relationships between individual roles.
Three of these classes—Act, Entity, and Role—are further represented by a set of specialized classes or sub-types.
RIM defines all the information from which the data content of HL7 messages are drawn. It follows object-oriented modeling techniques, where the information is organized into classes that have attributes and that maintain associations with other classes. RIM also forms a shared view of the information domain used across all HL7 messages, independent of message structure.
HL7 v3 security
The focus of HL7 security needs analysis on how systems communicate information using HL7 message. It is expected that healthcare application systems that implement HL 7 v3 will be required to have significantly more functionalities to protect the confidentiality of patient information and to authenticate requests for services than has been common in the past. The new functions may include, but are not limited to, limiting the right to view or transfer selected data to users with specific kinds of authorization, and auditing access to patient data, electronic signature, and authentication of users based on technologies more advanced than passwords. Version 3 will seek out and reference standards such as X.500 (Weider, Reynolds, & Heker, 1992) and RFC 1510 to support conveying the necessary information from one healthcare application system to another, so that these systems may perform the authorization and authentication functions. Version 3 will also seek out and adopt industry security standards that support conveying the necessary information from one healthcare application system to another, so that these systems may perform the confidentiality functions.
To meet the security goals, the HL7 Secure Transaction Special Group has created a security service framework for HL7 (Kratz et al., 2005). According to the scope of the framework, HL7 must address the following security services: authentication, authorization and access control, integrity (system and data), confidentiality, accountability, availability, and non-repudiation. The HL7 security service framework uses case scenarios to illustrate all the services mentioned above. All those case scenarios can help the readers to understand those services in a very direct way. However case scenarios are not detailed enough to be an implementation guide for the security services.
In this article we are going to design a flexible model for one key security service—access control. This model will extend the case scenarios to a very detailed level which can be directly used as an implementation guide for HL7 v3.
Figure 2. RBAC permissions with context constraints
role-based access control
RBAC has became very popular in both research and industry. RBAC models have been shown to be “policy-neutral” in the sense that by using role hierarchies and constraints (Chandramouli, 2003), a wide range of security policies can be expressed. Security administration is also greatly simplified by the use of roles to organize access privileges. A basic RBAC model will be covered in this section, as well as an advanced model with context constraints.
Basic RBAC Model
The basic components of the RBAC model are user, role, and permission (Chen & Sandhu, 1996). The user is the individual who needs access to the system. Membership to the roles is granted to the user based on his or her obligations and responsibilities within the organization. All the operations that the user can perform should be based on the user’s role.
Role means a set of functional responsibilities within an organization. The administrator defines roles, a combination of obligation and authority in organization, and assigns them to users. The user-role relationship represents the collection of users and roles.
Permission is the way for the role to access more than one resource.
As shown in Figure 1, the basic RBAC model also includes user assignment (UA) and permission assignment (PA) (INCITS359, 2003).
The user assignment relationship represents which user is assigned to perform what kind of role in the organization. The administrator decides the user assignment relationship. When a user logs on, the system UA is referenced to decide which role it is assigned to. According to the object that the role wants to access, the permission can be assigned to the role referenced by the permission assignment relationship.
The set of permissions (PRMS) is composed of the assignments between operations (OPS) and objects (OBS).
UA and PA can provide great flexibility and granularity of assignment of permissions to roles and users to roles (INCITS359, 2003). The basic RBAC model has clearly illustrated the concept about how role-based access control works within an organization. However it may not be dynamic enough when the business process becomes very complex. Thus the idea of context constraints is introduced to make the RBAC model more useful.
RBAC Model with context constraints
Traditional RBAC supports the definition of arbitrary constraints on the different parts of a RBAC model (Sandhu et al., 1996). With the increasing interest in RBAC in general and constraint-based RBAC in particular, research for other types of RBAC constraints has gained more attention (Bertino, Bonatt, & Ferrari, 2001). In this section we describe the context constraints in an RBAC environment.
A context constraint is an abstract concept. It specifies that certain context attributes must meetcertain conditions in order to permit a specific operation. As authorization decisions are based on the permissions a particular subject/role possesses, context constraints are associated with RBAC permissions (see Figure 2).
The context constraint is defined through the terms context attribute, context function, and context condition (Strembeck & Neumann, 2004):
• A context attribute represents a certain property of the environment whose actual value might change dynamically (like time, date, or session-data, for example) or which varies for different instances of the same abstract entity (e.g., location, ownership, birthday, or nationality). Thus, context attributes are a means to make context information explicit.
• A context function is a mechanism to obtain the current value of a specific context attribute (i.e., to explicitly capture context information). For example, a function date() could be defined to return the current date. Of course, a context function can also receive one or more input parameters. For example, a function age(subject) may take the subject name out of the subject, operation, object_ triple to acquire the age of the subject, which initiated the current access request, for example, the age can be read from some database.
• A context condition is a predicate that consists of an operator and two or more operands. The first operand always represents a certain context attribute, while the other operands may be either context attributes or constant values. All variables must be ground before evaluation. Therefore, each context attribute is replaced with a constant value by using the corresponding context function prior to the evaluation of the respective condition.
• A context constraint is a clause containing one or more context conditions. It is satisfied if and only if (iff) all context conditions hold. Otherwise it returns false.
A context constraint can be used to define conditional permissions. Based on the terms listed above, the conditional permission is a permission associated with one or more context constraints, and grants access iff each corresponding context constraint evaluates as “true.”
As we can see, a context constraint can help the organization provide more flexible and securer control for the RBAC model.
Design a RBAc Model with context constraints for the Healthcare Information system Based on HL 7 Version 3
The access control model we are going to describe is a method to control access on a healthcare information system. It is developed to enhance the security and flexibility of traditional access control systems. The resource to be accessed in this article is limited to a patient’s electronic health record (EHR).
The primary purpose of the EHR is to provide a documented record of care that supports present and future care by the same or other clinicians. This documentation provides a means of communication among clinicians contributing to the patient’s care. The primary beneficiaries are the patient and the clinician(s) (ISO/TC-215 Technical Report, 2003).
System design will include two major phases:
1. Components design: Describes all the necessary elements that make up the system.
2. Data flow design: Describes all the processes that make the whole system work.
Components Design
As described in the previous section, the RBAC system must include the basic elements such as user, role, permission, user-role assignment, and role-permission assignment. All those elements will be associated with real values in our system design. Figure 3 illustrates the overall structure of the system.
• User: Anybody with authenticated identity can act as the user in the system. For example, after Tom successfully logs into the hospital’s computer system with his user ID 19245678, he becomes the user of our system.
• Role: The set of roles can be retrieved from those functional roles that already exist in the current healthcare information system such as physician, pharmacist, registered nurse, and so forth. As the number of roles is limited in our system, we can store all the role information by simply using an XML file instead of a database. This file is named “Common Role File.xml.”
• Permission: The scope of the permissions in our design will focus on those system operations (create, read, update, delete, execute, etc.). Similar to role information, we use another XML file with the name “Common Permission File.xml” to represent all the permission information.
As shown in Figure 3, the user, role, and permission file can be used as the basic input for the whole system. To generate user-role assignment and role-permission assignment relationship, we introduce the administration function module. This module is designed to create and maintain the user role assignment file and role permission assignment file.
The rules of user role assignment and role permission assignment are referenced from the security section of HL7 v3 standard (HL7 Security Technical Committee, 2005).
In addition to the administration function module, we also designed another two function modules: support function module and review function module. The support function module provides the core function of the system. It receives the access request from the user and makes judgment based on the input from different sources to decide whether the access can be granted. The detailed process will be described in the next section.
The review function module is an extension of the support function module. It is used for exceptional scenarios, such as emergent circumstances that do not satisfy the constraint condition. Every time the review function module is initiated, an audit file will be created to record all the necessary information of the exceptional case. In our system, the audit file is saved in XML format with the name ” Audit File.xml.”
The ultimate object the users want to access is the EHR. The existing database that stores all the EHRs can be used directly by our system.
Another database included in this system is the constraint database, which stores all the context attributes and context conditions. The context attributes and context conditions can be used as input for the support function module during the access control decision process.
In summary, the components can be categorized into three types based on the design:
• Type 1 – Basic elements: Role, User, Permission, User Role Assignment, Role Permission Assignment, Audit File. All these basic elements are represented in XML format.
• Type 2 – System functional modules:
Administration Function Module, Support Function Module, Review Function Module. All these modules provide the core functions of the system and are represented in real program.
• Type 3 – Database: EHR database and constraint database.
Data Flow Design
After all the components are defined, we will design the proper data flows to make the system work. The data flow design is based on the three functional modules previously discussed. Thus, we introduce three kinds of data flow in this article:
• data flow for administration function module,
• data flow for support function module, and
• data flow for review function module.
Data flow for administration function module
1. Administration function module reads the common user file, common role file, and common permission file. Those files contain all the user information, role information, and permission information respectively.
2. Based on the pre-defined user-role relationship/role-permission relationship, the administration function module creates a user role assignment file and a role permission assignment file in XML format.
Data flow for support function module
1. The user sends an access request to the support function module.
2. The support function module requests and receives role information about the user from the user assignment file.
3. The support function module requests and receives the permission which is assigned to the role. This can be retrieved from the permission assignment file.
4. Get context attributes and context condition information from the constraints database.
5. The support function module performs the “check access” function then grants the access permission to the user.
6. The user can retrieve the information from the EHR database.
Data flow for review function module
1. Sometimes the context condition cannot be met, however all the other conditions (permission assignment, user assignment) can be met and the user really wants to access the resource because of emergency. In this case, all authentication information will be forwarded to the review function module.
2. The review function module records all the necessary information and generates an audit file, then grants conditional access permission to the user.
3. The user can retrieve the information from the EHR database.
All the steps listed above for the data flow just give a brief description. More detailed steps are necessary when it comes to the system implementation phase.
CONCLUSION AND FUTURE WORK
Clinical information sharing between different healthcare information systems is the key factor to improve the quality of service. Health Level Seven is the data exchange standard for clinical information. In this article we first introduce the basic concept of Health Level Seven and role-based access control. Then we illustrate how to design a flexible role-based access control model for a healthcare information system based on Health Level Seven version 3. The design utilizes the existing access control feature of Health Level Seven version 3 and integrates context constraints to make the system more secure and more flexible.
In the future, the major work will be the development of those function modules and applying this model to a real healthcare information system to see how the security access control can be improved.
KEY TERMS
Electronic Health Record (HER): A longitudinal electronic record of patient health information generated by one or more encounters in any care delivery setting.
Extensible Markup Language (XML): A W3C initiative that allows information and services to be encoded with meaningful structure and semantics that computers and humans can understand.
Health Level Seven (HL7): One of several American National Standards Institute (ANSI) -accredited Standards Developing Organizations (SDOs) operating in the healthcare arena.
Permission Assignment (PA): Assigns permission to an authorized role.
Reference Information Module (RIM): The cornerstone of the HL7 Version 3 development process and an essential part of the HL7 v3 development methodology. RIM expresses the data content needed in a specific clinical or administrative context, and provides an explicit representation of the semantic and lexical connections that exist between the information carried in the fields of HL7 messages.
Role-Based Access Control (RBAC): A system of controlling which users have access to resources based on the role of the user.
User Assignment (UA): Assigns a role to a user.
