Healthcare teams over the Internet: programming a certificate-based approach

Transcription

1 International Journal of Medical Informatics (2003) 70, 161 /171 Healthcare teams over the Internet: programming a certificate-based approach Christos K. Georgiadis*, Ioannis K. Mavridis, George I. Pangalos Informatics Laboratory, Computers Division, Faculty of Technology, Aristotle University of Thessaloniki, Egnatia Str., Thessaloniki, Greece Received 9 December 2002; accepted 21 March 2003 KEYWORDS Health information systems; Information systems security; Healthcare teams; Internet; Digital certificates; Access control systems Summary Healthcare environments are a representative case of collaborative environments since individuals (e.g. doctors) in many cases collaborate in order to provide care to patients in a more proficient way. At the same time modern healthcare institutions are increasingly interested in sharing access of their information resources in the networked environment. Healthcare applications over the Internet offer an attractive communication infrastructure at worldwide level but with a noticeably great factor of risk. Security has, therefore, become a major concern. However, although an adequate level of security can be relied upon digital certificates, if an appropriate security model is used, additional security considerations are needed in order to deal efficiently with the above team-work concerns. The already known Hybrid Access Control (HAC) security model supports and handles efficiently healthcare teams with active security capabilities and is capable to exploit the benefits of certificate technology. In this paper we present the way for encoding the appropriate authoritative information in various types of certificates, as well as the overall operational architecture of the implemented access control system for healthcare collaborative environments over the Internet. A pilot implementation of the proposed methodology in a major Greek hospital has shown the applicability of the proposals and the flexibility of the access control provided Elsevier Ireland Ltd. All rights reserved. 1. Introduction A significant change regarding the functioning of healthcare information systems (HIS) is the transition from the conventional model of isolated HIS, *Corresponding author. Tel.: / ; fax: / addresses: gxri@auth.gr (C.K. Georgiadis), mavridis@uom.gr (I.K. Mavridis), pangalos@auth.gr (G.I. Pangalos). to the networked one [1]. Internet technologies provide unique opportunities for interaction and data sharing among doctors, patients, researchers and healthcare establishments (HCEs). However, these benefits come with a considerably greater factor of danger to the security [2]. This is because Internet s underlying protocols were not designed to offer secure communication services. As a consequence, additional security technologies are needed to tackle the significant security concerns for satisfying an increasing demand of modern HIS: in which ways these systems have to grow, in order /03/$ - see front matter 2003 Elsevier Ireland Ltd. All rights reserved. doi: /s (03)

2 162 C.K. Georgiadis et al. to become a well-trusted health information network. Latest efforts to maintain an acceptable level of Internet security rely on public-key cryptography (PKC) and digital certificates. A Public-Key Infrastructure (PKI) supports the management of digital certificates suitable for identification and authentication purposes. In addition, the emerging complementary Privilege Management Infrastructure (PMI) can provide other types of certificates that are particularly suitable for authorization purposes [3]. Therefore, in order to fully exploit digital certificates to shield transport and sharing of medical data and protect healthcare applications over the Internet there is a need of a suitable security model with appropriate structure, compatibility with the PKI and PMI environments [4] and ability to be propagated within distributed systems that spread on different healthcare institutions. A fundamental issue regarding access control management in HCEs is their co-operative nature. Healthcare environments are a representative case of collaborative environments since the individuals (e.g. doctors and nurses) in many cases do not act in isolation, but they collaborate with others in order to provide care to patients in a more proficient way (e.g. by forming care-teams [5]). The access privileges of each member of a team must conform to the current access requirements in order to accomplish the specific task of the team. As a result, in dynamically changing clinical workflow environments there is a need for active security permission activation [6,7]. In order to deal with the above issues, we propose in this paper the use of the already known Hybrid Access Control (HAC) security model, which supports and handles efficiently the concepts and structures of healthcare teams and is capable to exploit the benefits of certificate technology, as expressed in PKI and PMI environments, in distributed healthcare applications over the Internet. The resulting access control system is a particularly suitable security tool for healthcare collaborative environments. 2. Protection requirements in distributed HIS The increased mobility of the patient populations and the changes in the structure of HIS has resulted in a patient s computerized medical information being accumulated in a variety of locations. Today s HCEs use clinical electronic records that usually contain data that are shared between source systems that are involved in healthcare distributed applications, in order to provide information to internal users as well as external requests, payers, etc. Data may be accessed via remote workstations and complex networks supporting one or more organizations, and potentially within a national information infrastructure [8]. Distributed healthcare systems that are geographically dispersed over wide-area networks to support data sharing in restricted collaborations give rise to a range of requirements for distributed control of access. Among other things administration of such resources need to be handled by a programmed authorization infrastructure so that management of data availability and enforcement of access rules can be accomplished automatically. Security of HIS requires the use of special security policies that are able to preserve all the security components at the same time: confidentiality, integrity, availability and accountability. In addition, the way the medical and ward services are provided in HCEs can be characterized as patient-centred. This means that every new patient initiates a new case. Such a case is consisted of a different number of particular tasks according to the patient needs for care. As a consequence, the case of a patient is the main target of a group of doctors and nurses who are qualified to play specific roles in order to provide efficiently their services. Not only across different domains, but even within the same healthcare unit, the single doctor /patient relationship is being replaced by one in which the patient is managed by a team of health care professionals each specializing in one aspect of care. All the more, in the case of large HCEs, there is a significant turnover of staff as doctors, nurses and trainees undertake rotations in each of the different departments and units. As a result, user authentication and authorization procedures become heavy in such situations [9]. The already known HAC model [10], which is based on the RBAC [11] and emedac [12] models, satisfies the above mentioned protection requirements for HIS. In more detail, it provides a differentiated role-based [11] authorization mechanism for accessing medical records, depending on the particular values of the context parameters of users that form teams. The HAC model proposes that clinical tasks can be characterized during the runtime with a number of context factors, such as patient (a user gains additional permissions for a specific patient he is in care of), location (the collaborative activity depends on the specific area wherein the users of a particular team are working)

3 Healthcare teams over the Internet: programming a certificate-based approach 163 and time (all permissions are valid during a certain time interval). Furthermore, it provides mandatory security features [10,12]. 3. An overview of HAC model The HAC model is based on five sets of entities called users, roles, permissions, teams and contexts, as well as a collection of sessions (Fig. 1). A user (U) is simply a person (doctor or nurse). A role (R) is a job function within the organization with some associated semantics regarding the authority and responsibility conferred on a member of the role. Permissions (P), which are equivalent to privileges, authorizations and access rights are approvals of a particular mode of access to one or more data objects. The nature of permission depends on the implementation details of a system and the kind of system that it is. Thus, for a relational database management system, the objects of protection may be relations, tuples, attributes and views using modes of access operations such as SELECT, INSERT and UPDATE. User assignment (URS) and permission assignment (PRS) are both many-to-many relations. A user can be a member of many roles, and a role can be assigned to many users. Similarly, a role may have many permissions and the same permission can be assigned to many roles. These relations are the fundamentals concepts in RBAC [13]. Therefore, it is a user who exercises permissions. Using roles as intermediaries to enable users to exercise permissions provides more control advantages than directly relating users to permissions. An important property of a session (S) is that the user associated with a session, via the session-user function defined below, cannot change. The association remains constant for the life of a session. Sessions are also considered under the control of individual users. The distinction between a user and a session is useful only if users exercise discipline regarding the roles they normally invoke. A user should be allowed to login to a system with only those roles appropriate for a given occasion, in order to support the principle of least privilege [13]. So, each session is a mapping of one user to a set of roles, i.e. a user establishes a session during which the user activates some subset of roles that Fig. 1 The HAC access control model.

4 164 C.K. Georgiadis et al. he is a member of. The permissions available to the user are the union of permissions from all roles activated in that session. In addition, active roles in a session can be changed at the user s discretion. Ongoing activities, processes or tasks are related to some additional context (C) information, which defines mainly the involved users and data objects. In addition, other factors such as location and time may also be taken into consideration. The team (T) term is used as a concept that sums up a group of users in specific roles with the objective of completing a specific activity in a particular context. However, the team concept is more useful as a grouping mechanism that associates users with contexts. The placement of a team as an intermediary to enable a user to obtain a context is similar to the role usage. Even when a user is acting alone, we may consider him as the only member of his private team. During a session, a user can participate in a number of teams. So, each session is also a mapping of one user to a subset of teams that he is a member of. The contexts available to the user are the union of contexts from all teams that he participates in. Moreover, active teams in a session can be changed at the user s discretion, just like his active roles. A team can also be seen as a mapping to multiple users. The roles activated by these users identify the permission set available to the team as the union of permissions from all roles participating in that team. Context assignment (CTS) and team assignment (UTS) are both many-to-many relations. A team may have many contexts and the same context can be assigned to many teams. Similarly, a user can be a member of many teams, and a team may have many users. However, there are constraints when assigning user to teams. An obvious constraint is related to the roles already assigned to the user. There are mutually exclusive roles and teams, e.g. a user that has been assigned the roles Physician and Director cannot participate into a care-team as a Director Formal definition The following definition, which is based on the definitions of RBAC 0 [13] and emedac [12], provides some formalization to the above discussion Definition The HAC model has the following components [10]:. U, R, P, S, T, C, stand for users, roles, permissions, sessions, teams and contexts, respectively.. PRS /P /R, is a many-to-many permission to role assignment relation.. URS /U /R, is a many-to-many user to role assignment relation.. CTS /C /T, is a many-to-many context to team assignment relation.. UTS /U /T, is a many-to-many user to team assignment relation.. session-user: S 0/U, is a function mapping each session s i to the single user user(s i ) that is constant for the session s lifetime.. session-teams: S 0/2 T, is a function mapping each session s i to a set of teams teams(s i ) / {tj(user(s i ), t) /UTS}, which can change with time, and session s i has the contexts U t teams(si ) {cj(c, t) /CTS}.. team-users: T 0/2 U, is a function mapping each team t i to a set of users users(t i ) /{uj(u, t i ) / UTS}ffl/ / s j : user(s j )/u}, which can change with time.. HNH mechanism (construction of hierarchies): N, C, are sets of nodes and connections, respectively. HN /N /C, each hyper node HN is a double {N, C}. HNH /HN /HN, is a totally ordered hyper node hierarchy. HN and DN, disjoint sets of (regular) hyper nodes and dummy nodes, respectively. BC and LC, disjoint sets of branches and links, respectively. a node N i has a level (depth in the hierarchy) of number i. BC: N i 0/N i91?, branch is a function mapping a node to its ancestor node at the above level. LC: N i 0/N i?, link is a function mapping each node to its ancestor (hyper) node at the same level. Implementation of the security level and the category set in a HNH: a hyper node HN i has a security level of number i; the category set of a hyper node HN i is consisted of all its possible first ancestors. Implementation of a role hierarchy, as a HNH: URH /UR/UR, is a totally ordered hyper node hierarchy of roles (UR) that is also known as a dominance relation (written as ]/ in infix notation).. session-roles: S 0/2 R, is a function mapping each session s i to a set of roles roles(s i ) / {rj(( / r?]/r) [(user(s i ), r?) /URS]}, which can change with time. Session s i has the permissions U r {pj( / roles(si ) rƒ5/r) [(p, rƒ) /PRS]} and a security level that is the maximum of security

5 Healthcare teams over the Internet: programming a certificate-based approach 165 levels of roles(s i ) and a category set that is the union of category sets of roles(s i ).. team-roles: T 0/2 R, is a function mapping each team t i to a set of roles roles(t i ) /{rj(( / r?]/r) [(users(t i ), r?) /URS]}, which can change with time. Team t i has the permissions U r roles(ti ) {pj( / rƒ5/r) [(p, rƒ) /PRS]} and a security level that is the maximum of security levels of roles(t i ) and a category set that is the union of category sets of roles(t i ) Derivation of permission set The HAC model provides role-based permission assignment and team-based permission activation in order to access particular objects in a short period of time. After the completion of the user identification and authentication process, the user has to select a subset of roles from the set of roles already assigned to him. According to this selection, a particular set of role-based permissions is activated, called session-roles permissions. After the role selection, the user has to select a subset of teams to participate and gains the additional permissions from the roles activated by other users that are currently participating in the same teams. As already mentioned, teams can be seen as groups of current task contexts. As a result, by selecting a team, the user obtains also the context of his task. The team context consists of particular data objects and conditions, expressed in terms of ranges of values such as time, patients and location [10]. For every team there are available system variables, capable to hold sets of values of chosen factors. The binding of these variables to actual values is accomplished during the runtime by the administration staff of the hospital. Team contexts can be seen also as limitations or restrictions on objects and/or on conditions concerning the filtering of the access request, providing in such a way selections of the result sets. The final permission set of a user is filtered by using the context of the current task of his team. Any subsequent user access request is permitted only for the objects included in the context and during the period of his current task. In this way only the medical records of the patients charged to the user s team are accessible during the teamwork. In a more formal way, the expression u i / user(s i ) /U refers to a user u i who has been logged in the system during a session s i /S. Supposed that user u i has made the following choices for roles and teams: roles(s i )fr=(u i ; r) URSg teams(s i )ft=(u i ; t) UTSg Then, the following expressions are valid: users(t k t k teams(s i ) ug fu=(u; t k ) UTS ffl s j :user(s j ) The term users(t k ) stands for the set of users who are members of team t k, where t k /teams(s i ). This set of users is defined as the union of every team s individual user set. In other words, it is the union of team-users mappings: roles(t k t k teams(s i ) fr=users(t k ); r) URSg The function roles(t k ) stands for the set of roles, which are given to the members of every team t k, where t k /teams(s i ). This set of roles is defined as the union of every team s individual role set. In other words, it is the union of the team-roles function mappings. contexts(t k t k teams(s i ) fc=(c; t); r) CTSg The function contexts(t k ) stands for the set of contexts, which are attached to every team t k, where t k /teams(s i ). This set of contexts is defined as the union of every team s individual context. Then, according to the previous expressions, the two-steps permissions activation procedure is expressed as follows: Step 1: Initially, the role-based permissions of user u i (who has activated a subset of roles and participates in a subset of teams) are derived as follows: Role-based Permissions (u i )/Session-Roles Permissions (s i ) Team-Roles Permissions (teams(s i ))/Session-Roles Permissions (s i ) Team-Roles Permissions (t k )/@ r roles(si ) fp=(p; r) PRSg [/@ r roles(tk ) fp=(p; r) PRSg]//@ r roles(tk ) fp=/ /(p; r) PRSg:/ Step 2: The final permissions activated are the context-based permissions, which are derived from role-based permissions (step 1) with the following definition, where œ/ means filtered by : Context-based Permissions (u i )/Role-based Permissions (u i ) œ/ Team-Context (teams(s i ))/Rolebased Permissions (u i ) œ/ contexts(t k r roles(tk ) fp=(p; r) PRSg [/@ œ/ t k teams(s i ) fc=(c; t)/ / CTSg]:/ 4. Certificate-based security mechanisms In order to control the use of a networked resource, access management systems must make

6 166 C.K. Georgiadis et al. use of suitable authentication, authorization and policy handling services Authentication, PKI and identity certificates According to [3], two levels of authentication can be distinguished:. Simple authentication, using a password as a verification of claimed identity. It offers limited protection against unauthorized access.. Strong authentication, involving credentials formed using cryptographic techniques. A significant issue about implementing security over the Internet is that the concept and application of security is emerging in conjunction with the rapid development of the distributed networks (and their underlying technologies) it is tasked to secure. This is the case of PKI: it is essentially evolved as a management infrastructure surrounding PKC. Currently, there are two standards evolving in the field of PKI. This paper focus on the PKI using X.509 certificates (PKIX) implementation that has been more widely adapted and has earned the most commercial acceptance. The arrival of PKC was a breakthrough for distributed system security. Before PKC was available, users that wanted to confidentially exchange information required a secret key be shared between the two users. While the technology of secret (also known as symmetric, private or shared secret) keys was well established and had achieved pervasive acceptance, the main concern associated with using secret keys was key distribution, the method in which the keys would be exchanged. This problem still exists today. If secret keys are exchanged over an insecure network, any individual watching the network could gain access to the key and consequently, have the ability to pose as a legitimate user. PKC eases these problems, by allowing secure communication to occur without requiring any previous key exchange. Instead, when a user wants to communicate securely with another individual (either inside or outside the organization, permissible so long as binding trust relationship is established), the sender simply obtains a copy of the recipient s publicly available public key, typically in the form of a digital certificate. Identity Certificates (IC) or public key certificates [3] are widely used as a secure means for identification purposes in network environments. Using an IC to support a user s public key allows the certification authority (CA), which is implicitly trusted by all users, to sign the user s public key in order to maintain the integrity of the public key, expiration information and other important information contained within the IC. Once the sender has access to the intended recipient s IC, the sender would be able to encrypt messages for the recipient using recipient s public key. Only the holder of the private key associated with the IC (in this case, the recipient), would be able to decrypt the contents. The reverse is true for digital signatures, where the sender would sign a document or transaction with his/her private key, which could then be verified by the recipient using the sender s public key. Actually, it is more complicated, because the digital signature is applied to a hash of the message or transaction. In summary, public-key certificate framework or PKI allows for public key encryption and digital signature services and it may be utilized by applications with requirements for authentication, integrity, confidentiality and non-repudiation Authorization, PMI and attribute certificates Not all access control decisions are identitybased. For example, information about a user s current role may be more important than his identity. Modern research efforts [3,4,14] in this area conclude in a second kind of digital certificate, namely attribute certificate (AC). Attribute authority (AA) is the authority which assigns attributes (permissions or privileges) by signing the ACs. An AC is a separate structure from a subject s IC. A subject may have multiple ACs associated with each of its ICs. An AC certifies that its holder possesses specific authorizations (like group membership, role etc.). The use of ACs provides the required network-oriented protection, since in fact they are digitally signed sets of attributes. Revocation of ACs may or may not be needed. For example, in some environments, the AC validity periods may be very short (e.g. minutes), negating the need for a revocation scheme. Digital signatures are used in both PKI and PMI as the mechanism by which the authority that issues a certificate certifies the binding in the certificate. In PKI the digital signature of the issuing CA on an IC certifies the binding between the public-key material and the subject of the certificate. In PMI the digital signature of the issuing AA certifies the binding between the attributes and the holder of the certificate. The necessity for this different type of certificate is resulted by the fact that entity attributes

7 Healthcare teams over the Internet: programming a certificate-based approach 167 have lifetimes that do not match the validity period for an IC. Privileges often have a much shorter lifetime. The authority (AA) for assigning privileges is frequently other than the authority (CA) for issuing ICs and different privileges may be assigned by different AAs. Privileges may also be assigned based on a temporal context and the turn on/turn off aspect of privileges may well be asynchronous with the lifetime of the IC. The use of ACs provides a flexible PMI, which can be established and managed independently from a PKI. Although PKI and PMI are separate infrastructures and may be established independently from one another, they are related. The ITU-T specification [3], recommends that holders and issuers of AC be identified within AC by pointers to their appropriate IC. Authentication of the AC issuers and holders, to ensure that entities claiming attribute and issuing attribute are who they claim to be, is done using the normal processes of the PKI to authenticate identities. This authentication process is not duplicated within the AC framework. In summary, PMI may be utilized by applications with requirements for access control and authorizations Policy handling and access rule certificates Traditionally, authorization policies are managed in a relatively centralized manner. In distributed computing environments, however, policy control has to be decentralized because there are multiple, independent and geographically spread entities (individuals, organizations, institutes, notaries etc.) with authority to control access. Each of these parties is responsible to define access-rules for the protected resources and brings its own set of concerns [14]. So, many information security systems need to rely on the evaluation of upcoming rules to determine access permissions. This approach requires continuous connectivity and sophisticated directory services to contain and manage the relationships of information and most importantly its terms of use. In order to address authorizations distribution problems, we use a third type of digital certificate, namely the Access-Rule Certificate (RC). An RC is a data structure comparable to an IC and AC. It enables policy responsible parties to distribute access control rules remotely and securely, authorizing in this way access to specific resources. RCs are in fact, digitally signed sets of rules. In a fashion similar to an AA and a CA, a Rule Authority (RA) is considered as an entity trusted by one or more users to sign access-rule certificates. 5. Certificate-based implementation of HAC Certificate-based access management provides authentication strength, fine-grained access control and user accountability, so that if improper use is discovered, the administrator knows where to begin investigating. In our implementation approach, the scope is to demonstrate the benefits of digital certificates by using them as a safe means for communicating reliably critical security metadata. Therefore, their contribution becomes considerable concerning the flexibility of the implementation of the security policy that is in force. As we have seen previously, our approach exploits three types of certificates: identity, attribute and access-rule certificates. In the following implementation example, we use these three types of certificates in order to transmit securely via the Internet the critical security metadata that influence the behavior of the access control system in use Structure of AC and RC certificates To support the HAC model, we propose to use ACs for encoding the assigned roles and the assigned teams during a particular session. In general, the attributes component contained in a certain AC depends on the overall security policy that is in force. In our case, the role attribute (as it is described in [3]) may be utilized as follows: individuals are issued role assignment certificates that assign one or more roles to them through the role attribute contained in every one certificate. Besides the role attribute, an additional entry is required to contain the team attribute, in accordance to the HAC security model. The structure of our proposed role/team attribute certificate is presented in Fig. 2. It is worth mentioning that only in special situations a single AA signs attribute of both role and team type, as it is shown in Fig. 2. It is more likely that different AAs are authorized to encode role and team assignments. Thus, a privilege asserter (holder of a set of role/team ACs), may present his ACs to the privilege verifier (HAC system), demonstrating that he has particular roles and that he belongs to particular teams. HAC

8 168 C.K. Georgiadis et al.. PLE: each one entry of policy entity encodes (Fig. 4): short-name: the short-name of a user role, data set, team or user location that is going to be created or altered; value: the binding value or description of the previously mentioned short-name field.. CTS: the mechanism of context to team assignments (CTS), which can be further analyzed as (Fig. 5): patient to team, location to team and timezones to team assignments. In any case, all these assignments are encoded with the same format. The distribution of access-rule certificates is performed according to the push model, which involves the RA supplying the RCs directly to every security server [4]. Having already distributed the appropriate RCs, the authentication and authorization process is performed according to the following operational architecture. Fig. 2 Role/team attribute certificate. system may know a priori (e.g. may be locally configured), or may have to discover by some other means, the privileges associated with the asserted roles and teams, in order to make a deny/allow authorization decision. Apart from the solution of the role specification certificate, which is proposed in [3], we suggest a more complete answer for policy handling issues. As we have referred in previous section, we utilize a third type of certificates, the Access-Rule Certificate (RC). Below, we describe the structure of RCs. Then, the privileges and the contexts associated with the asserted roles and teams may be expressed through its PRS and CTS components, as it will be shown in the next paragraph. For the propagation of a security policy based on the HAC model, an RC must encode entries relative with at least one of the following types of control data:. PRS: a sequence of three items (user role, data set and access mode) that express an authorization rule, which is a tuple in the permission-toroles assignment (PRS) relation (Fig. 3).. HNH: the entries to construct the appropriate user role (URH) and data set (DSH) hierarchies, according to the HNH mechanism [10] Operational architecture The security system we have developed provides three types of security services: policy propagation, network-level identification and authorization, as well as access control services (Fig. 6) Policy handling services In distributed computing environments the process of propagating the access control mechanisms and authorization rules among different organizations is accomplished with Access-Rule Certificates. The inherited mechanisms are stored in the local base of access control metadata of HAC security server by accepting and validating the new coming access-rule certificates (according to the push model) from trusted Access-Rule Authorities Network-level identification and authorization services When a user initiates a new session, he must be first identified and authenticated, using his network-level credentials that could have the form of an X.509 IC. Then the user activates a subset of user roles (URs) and teams (UTs), in order to form his session-dependent user profile. His choices are used for the preparation and issuance of an AC request, which is then submitted to a trusted AA. The AA authenticates the information included in the user profile, sets the AC and issues it to the

9 Healthcare teams over the Internet: programming a certificate-based approach 169 Fig. 3 Example of recording PRS entries in an access rule certificate. user. Issued ACs are then used in subsequent access requests during the same session. An AC is sessiondependent and is valid only during the current session [4,7] Access control services The user places an access request and pushes it to the medical database server along with his session dependent profile. Then, the user profile, along with the user access request are examined by the access control server, which contains the required access control mechanisms, as well as the policy engine for the implementation of the HAC security mechanisms. The particular query of the user may be modified, if permitted according to the specific HAC security considerations that are in effect, or denied. 6. Results of experimental implementation The AHEPA University Hospital has been used as our test-bed for defining and implementing a minor access control system according to the proposed operational architecture. Our experimental implementation gives strong evidences that the most likely exposure areas in HCEs are satisfactory confronted. Indeed, the integration of a HAC-based policy with ACs and RCs, introduces great improve- Fig. 4 Example of recording PLE entries in an access rule certificate.

10 170 C.K. Georgiadis et al. Fig. 5 Example of recording CTS entries in an access rule certificate. ments in key-problematic issues such as: the accidental mistreatment of patient medical information, the lack of appropriate employee screening and supervision in healthcare domain, the failure to act properly in order to prevent, detect or correct privacy breaches, the inconsistencies in the implementation of security policies across affiliate healthcare organizations, the discrimination in the application of personnel task-procedures and the informal, undocumented or out-ofdate user authorizations. Moreover, the access control mechanisms of distributed HIS, are able to collect all the relevant user qualifications and statements (rules) and make an explicit access decision, without requiring static configuration information that must be centrally administered. 7. Conclusion The inability to share information across systems and between care organizations has been one of the impediments in the HCE s progress towards efficiency. Internet technology can be the answer for this problem, as it is expected to have an evergrowing impact on the delivery of medical information across all domains. However, the Internet has caused significant concerns about security. A significant segment of the challenge is the selection Fig. 6 Operational architecture.

11 Healthcare teams over the Internet: programming a certificate-based approach 171 of the security technologies and their application and integration into a practical and scalable solution. Many of the current technologies attempt to address these issues but fall short in a practical application that would hold back their use in dynamic healthcare corporate environments. Careful application of specific security technologies can provide innovative approaches to these issues to yield more practical and operable solutions. It is not enough to say that PKC may considerably reduce security concerns, since it can play an essential role in addressing authentication and authorization issues. It is important to realize that access control policies in HCEs may get the best of an approach that integrates them with PKI and PMI, as long as it has been clear the advantages and the limitations of certificate technology. In this paper we demonstrate such an implementation example that is based on the already known HAC security model, which supports and handles efficiently the concepts and structures of healthcare teams. The resulting system provides active security capabilities, it increases independence from temporal and spatial factors and reflects in a computing-communication environment, the general principles that have been established in HCEs for policy-based access control. References [1] S.K. Katsikas, Health care management and information systems security: awareness, training or education, Int. J. Med. Informatics 60 (2000) 129/135. [2] Department of Health and Human Services (USA), The HCFA Internet Communications Security and Appropriate Use Policy and Guidelines, Health Care Financing Administration, Office of Information Services, Security and Standards Group, February 1999, isecplcy.htm. [3] ITU-T Recommendation X.509. Information Technology: Open Systems Interconnection*/The Directory: Public Key and Attribute Certificate Frameworks, 2000, ISO/IEC :2001. [4] I. Mavridis, C.K. Georgiadis, G. Pangalos, M. Khair, Using Digital Certificates for Access Control in Clinical Intranet Applications, book edition of J. Technol. Health Care, vol. 8, Nos. 3, 4 (2000), ISSN , IOS Press, pp. 173 / 174. [5] R.K. Thomas, Team-based access control (TMAC): a primitive for applying role-based access controls in collaborative environments, in: Proceedings of the Second ACM Workshop on Role-Based Access Control (RBAC 97), Fairfax, VA, USA, 6 /7 November, 1997, pp. 13 /19. [6] C.K. Georgiadis, I. Mavridis, G. Pangalos, R.K. Thomas, Flexible team-based access control using contexts, in: Proceedings of the Sixth ACM Symposium on Access Control Models and Technologies (SACMAT 2001), Chantilly, VA, USA, May 2001, pp. 21/27. [7] C.K. Georgiadis, I. Mavridis, G. Pangalos, Implementing Context and Team Based Access Control in Healthcare Intranets, International Journal of Health Care Engineering Technology and Health Care (book edition), vol. 9, Number 6 (2001), ISSN , IOS Press, Special Issue: Abstracts of the Sixth World Congress on the Internet in Medicine (MEDNET 2001), Udine, Italy, December [8] The Computer-based Patient Record Institute. Description of the Computer-Based Patient Record (CPR) and Computer-Based Patient Record System. Prepared by the CPRI Work Group on CPR Description (WDES). May [9] J. Grimson, W. Grimson, W. Hasselbring, The System Integration (SI) Challenge in Health Care, Communications of the ACM. June 2000, vol. 43, No. 6, pp. 49/55. [10] C.K. Georgiadis, I. Mavridis, G. Pangalos, Context and role based hybrid access control for collaborative environments, in: Proceedings of the Fifth Nordic Workshop on Secure IT Systems-Encouraging Co-operation (NORDSEC 2000), Reykjavik, Iceland, 12 /13 October 2000, pp. 225 / 238. [11] R. Sandhu, D. Ferraiolo, R. Kuhn, The NIST model for rolebased access control: towards a unified standard, in: Proceedings of the Fifth ACM Workshop on Role-Based Access Control (RBAC 2000), Technical University of Berlin, Berlin, Germany, 26/28 July 2000, pp. 47/63. [12] I. Mavridis, G. Pangalos, M. Khair, emedac: role-based access control supporting discretionary and mandatory features, in: Proceedings of 13th IFIP WG 11.3 Working Conference on Database Security, Seattle, WA, USA, 25 /28 July 1999, pp. 55/63. [13] R. Sandhu, Role-Based Access Control, Advances in Computers, vol. 46, Academic Press, [14] W. Johnston, S. Mudumbai, M. Thompson, Authorization and attribute certificates for widely distributed access control, in: Proceedings of IEEE Seventh International Workshop on Enabling Technologies: Infrastructures for Collaborative Enterprises (WETICE 98), Stanford, USA, 1998.