i n t e r n a t i o n a l j o u r n a l o f m e d i c a l i n f o r m a t i c s 7 7 ( 2 0 0 8 ) 242248

journal homepage: www.intl.elsevierhealth.com/journals/ijmi

Web-based secure access from multiple patient repositories

Jun Choe a , Sun K. Yoo b,c,
a

Graduate School of Biomedical Engineering, Yonsei University, Seoul, Republic of Korea Department of Medical Engineering, BK21 project for Medical Science, Yonsei University College of Medicine, Seoul, Republic of Korea c Center for Emergency Medical Informatics, Signal Processing Research Center, Human Identication Research Center, Yonsei University, Seoul, Republic of Korea
b

a r t i c l e
Article history:

i n f o

a b s t r a c t
Background: Internet-based health-record management requires not only the provision of strong data protection to prevent privacy intrusion and unauthorized access, but also the introduction of a common healthcare-record format to allow cooperation using heterogeneous repositories held at various hospitals. Methods: A secure multi-agent architecture is proposed for accessing healthcare information through the Internet from multiple heterogeneous repositories. The proposed system

Received 5 November 2004 Received in revised form 1 June 2007 Accepted 1 June 2007

Keywords: Multi-agents Heterogeneous repositories Secure access RBAC XML Security Web

is organized into a four-tier architecture that consists of client applications, a central access-control system, local access-control systems, and hospital information systems. The eXtensible Markup Language (XML) and the role-based access-control (RBAC) system are combined for efcient repository management by providing methods for access-control, information exchange, user authentication, data integrity, and selective encryption. Result: A multi-agent architecture using XML and RBAC can interconnect heterogeneous repositories with different formats and different hospital policies, and allow them to communicate securely. The authorized client, having conrmed access privileges, can retrieve the requested healthcare data in an XML-based common data format with embedded condentiality. Conclusion: The proposed method for Internet-based exchange of patient data is particularly useful for cooperative healthcare and the creation of lifetime healthcare records. 2007 Elsevier Ireland Ltd. All rights reserved.

1.

Introduction

Access to healthcare information through the World Wide Web has received considerable attention due to the widespread use of the Internet, and the introduction of electronic healthcare records; various hospitals can now be interconnected and healthcare data can be accessed ubiquitously by means of the

Internet. Web-based applications enable the integration of a variety of applications, and the exchange of healthcare data through the Internet. The information-exchange capability provided by a Web service can also facilitate multi-specialist and multi-institutional cooperative patient care without the restrictions of time or location, as well as forming the basis for the creation of a lifetime healthcare record.

Corresponding author at: Department of Medical Engineering, Yonsei University College of Medicine, 134 Shinchon-dong, Seodaemun-ku, Seoul 120-752, Republic of Korea. Tel.: +82 2 2228 1919; fax: +82 2 363 9923. E-mail address: sunkyoo@yumc.yonsei.ac.kr (S.K. Yoo). 1386-5056/$ see front matter 2007 Elsevier Ireland Ltd. All rights reserved. doi:10.1016/j.ijmedinf.2007.06.001

i n t e r n a t i o n a l j o u r n a l o f m e d i c a l i n f o r m a t i c s 7 7 ( 2 0 0 8 ) 242248

243

For secure information exchange, a Web-based healthcare information system requires a comprehensive security policy and a common data format. As the healthcare information is made accessible through the Internet from multiple repositories scattered throughout various hospitals, security becomes a major concern [15]. The access privileges for a repository should be carefully managed, and the data that are made available depend on the privileges granted to a user. Moreover, important healthcare data should be exchanged over the Internet in a condential way to protect patient privacy. However, different hospitals might have different security policies, and different record formats, which can obstruct the coherent and seamless exchange of information from multiple repositories. In the current paper, a multi-agent architecture is proposed for authorized information access and the secure exchange of patient information based on Web services in order to provide integrated healthcare applications, such as lifetime patient medical records and cooperative consultation. The proposed system consists of client applications (CA), a central access-control (CAC) system, local access-control (LAC) systems, and hospital information systems (HIS). The architecture employs the role-based access-control (RBAC) system [6,7] and eXtensible Markup Language (XML) for user authentication, data integrity, and selective encryption of patient information [811].

2.

System design

The system can securely access patient healthcare data that are held at multiple hospitals. In general, each HIS has its own storage format, and each hospital manages the access rights to its HIS using predened roles for staff members. Hence, the designed system employs multi-agent technology, RBAC, and XML-based data exchange. Fig. 1 illustrates the proposed system architecture, in which hospitals and users are interconnected through the Internet via a central access-controller (CAC). Healthcare information is stored at repositories held in various hospitals, and users can access this information regardless of time and location by means of a Web service, provided that there is access to the Internet. More generally, as shown in Fig. 2, the proposed system adopts a multi-agent architecture that serves to distribute the complexity arising from the interconnection of multiple hospitals and multiple users, and the need for secure information exchange. This consists of CAs, a CAC, LACs, and HISs. The following conditions must be assumed in order for the system to operate for several hospitals: Condition 1: Only a patient has a permanent right to access his or her own healthcare data, irrespective of the repository.

Fig. 1 The proposed system architecture. CA, client application; CAC, a central access-control; LAC, local access-control; HIS, hospital information system; DB, data base.

244

i n t e r n a t i o n a l j o u r n a l o f m e d i c a l i n f o r m a t i c s 7 7 ( 2 0 0 8 ) 242248

Fig. 2 The proposed four-tier system architecture. CAC, a central access-control; LAC, local access-control; HIS, hospital information system.

Condition 2: While receiving medical care at a hospital, a patient commits the access rights to his or her own healthcare data to that hospital. Condition 3: Users outside the hospital can access the patients healthcare data through the CAC using Web-based services on the Internet. Condition 4: The CAC must establish a relationship of mutual trust with each hospital and a secure connection to each hospitals LAC; as an example, this might be accomplished using a Virtual Private Network. From the point of view of a hospital at which a patient is being actively treated, the individuals healthcare data can be logically classied as either inner healthcare data (IHD) if they are stored at that particular hospital or as outer healthcare data (OHD) if they are stored at any other hospital. Likewise, all users, except the patient, are classied into two groups: the inner user group (IUG), which is dened as team members working at the hospital in question; and the outer user group (OUG), which consists of team members working at other hospitals. Being a team member is a role of entry in relation to a workow or in a specic organizational setting. The patient is located at the center (starting point) of the access-control system. When a patient registers at a hospital, he or she commits access rights to part of their healthcare record, including the IHD and OHD, to that hospital. The hospital (LAC) then has a responsibility to manage the patients healthcare record in a secure manner. The rules for role assignment based on that hospitals security policy are applied to each member of the healthcare team, including the IUG and OUG, and their level of access to the healthcare data is restricted according to the specic roles they have been assigned. In addition to the IHD, the OHD stored at other hospitals might be accessed with the patients permission. In addition to the IUG, the OUG located at other hospitals might access the healthcare data based on that hospitals security policy. In other words, the distinctions between the IHD and OHD, and between the IUG and OUG, are only associated with the physical hospital locations holding the repositories and the team members, as the patient cannot distinguish the OHD from the IHD, and the rules for role assignment at a particular hospital cannot distinguish the OUG from the IUG. Hence, the LAC has the major responsibility for managing the access to patients healthcare data, while the CAC has the control capability (by passing a request to the corresponding LAC) to

overcome the physical location barrier associated with the OHD and OUG.

3.

Communications

The system communications are based on RBAC and XML technologies. Request processing within the system, from the CAC to the HIS via the LAC, is outlined in Fig. 3. When a client wishes to request healthcare data by the CA, it must rst contact the CAC. For secure communications, between the CAC and a client (with the CA), a session key is shared. The user authentication at the CAC is based on the public key infrastructure (PKI). The X.509v3 used in this proposed system species a PKI and public key certicate format [12]. A certicate binds a public key value to authenticate the user. In order for public keys to be trusted among a vast user community, a reliable entity (trusted third party) that is trusted by all users should verify the public keys. A PKI refers to an infrastructure that is used to issue and revoke public keys and public key certicates. Depending on the patient and repository, the LAC can be classied into the LACP and the LACD ; the former is associated with the hospital at which a patient is being actively treated, and the latter is associated with the hospital at which the healthcare data are stored. After user authentication, the CAC communicates with the LACP for the privilege management based on the RBAC. RBAC systems dene a number of roles and assign each role as a set of permissions (userrolepermission, URP, relationship). The RBAC denes role specication attribute certicates (ACs) that hold the permissions granted to each role, and role assignment ACs that assign various roles to the users. To determine the permissions granted to a user, the role checker would read the role assignment ACs granted to the user and all role-specication ACs for each granted role, and check the various certicaterevocation lists to ensure that no AC has been revoked since its creation. The RBAC at the LACP can signicantly simplify access-control management for large numbers of local users, because it allocates permissions to roles rather than individuals. After verication of the data request, the CAC passes the data request onto the corresponding LACD with permission to access the data. The LACD retrieves the requested data from the HIS and transforms it into an XML-based common format, for example, the clinical document architecture (CDA)

i n t e r n a t i o n a l j o u r n a l o f m e d i c a l i n f o r m a t i c s 7 7 ( 2 0 0 8 ) 242248

245

Fig. 3 System-request processing described by a unied modeling language (UML) sequence diagram. The LACP is associated with the hospital at which a patient is being actively treated, and the LACD is associated with the hospital at which healthcare data are stored. CA, client application; CAC, a central access-control; LAC, local access-control; HIS, hospital information system.

[13]. It then transfers the data to the CAC through the secure communication channel that has been established. The CAC uses the shared session key to selectively encrypt the data; this selectivity is achieved using meta-data in the form of an encryption tree (Fig. 4), which describes in detail the parts of

the data that should be protected. Attaching a digital signature ensures the integrity of the transferred data. For auditing purposes, all transactions between a user and an HIS are logged by the CAC. The role of each element is described below.

246

i n t e r n a t i o n a l j o u r n a l o f m e d i c a l i n f o r m a t i c s 7 7 ( 2 0 0 8 ) 242248

Fig. 4 The requested data, corresponding encryption tree, and resulting selectively encrypted data.

3.1.

CA

The CA performs user authentication with a users digital certicate. The request to the CAC, as well as the reply to the CA, is sent with an XML digital signature attached to ensure integrity, and XML encryption is used to achieve secure data exchange between the CA and the CAC. For the digital signature, the Secure Hash Algorithm 1 (SHA1) is used to generate a message digest. For encryption, the Rivest, Shamir, and Adleman (RSA) algorithm is used to protect the session key during session initiation between the client and the CAC, and the triple data encryption standard (3-DES) algorithm is used for selective data encryption.

The encryption tree is used to create the nal result data based on the healthcare data returned from the LACD , with selective encryption by the selective encryption agent, as shown in Fig. 4. The selectively encrypted data is then transferred to the client with the CACs digital signature attached.

3.3.

LAC system

3.2.

CAC system

The CAC performs user authentication, and logs transactions for audits and data exchange to both the LAC and the CA. For healthcare data requests, the CAC requests validation to the relevant LAC to conrm the URP relationship. When a member of an IUG requests OHD (case A: LACP = LACD ), the CAC requests the URP relationship for the appropriate LACP associated with the IUG, as the patient commits access rights to that hospital. After verifying the URP relationship for the IUG associated with OHD, the reply is passed onto the CAC. The CAC then inspects the URP relationship to determine whether the request should be approved. The CAC then redirects the request with permission to access the data to the corresponding LACD associated with the OHD. When a member of an IUG requests IHD (case B: LACP = LACD ), the same procedures as those described for case A can be applied, using the corresponding LACD associated with the IHD. When a member of an OUG requests IHD (case C: LACP = LACD ), the CAC requests the URP relationship for the appropriate LACP associated with the IUG, as the OUG is assigned as a team member by the hospital corresponding to the IUG. After verifying the URP relationship for the OUG associated with IHD, the reply is passed onto the CAC. The CAC then inspects the URP relationship to determine whether the request should be approved. The CAC then redirects the request with permission to access the data to the corresponding LACD associated with IHD. When a member of an OUG requests OHD (case D: LACP = LACD ), the same procedures as those described for case C can be applied, using the corresponding LACD associated with the OHD.

The LAC system consists of two agents: the access-control agent and the data-transformation agent. In order to interact with the CAC, the data-transformation agent converts its native HIS record format into an XML-based common format. The access-control agent provides verication of the URP relationship for a healthcare data request. In addition to the verication of URP relationship, the user request is transformed into a native form, which is specic to each HIS, and then passed in this form to the HIS. The response from the HIS is then transformed into an XML-based common format known to the CAC, and this response is sent to the CAC.

3.4.

HIS

An HIS responds to an LAC request for data with the appropriate information. It has its own proprietary repositories.

4.

Application scenarios

The two scenarios described below were included to explain the operation of the proposed system in detail. When testing both scenarios, the authorized client, having conrmed access privilege, retrieved the desired healthcare information in an XML-based common data format with embedded condentiality and integrity. Scenario 1: Retrieval of patient Bobs historic data, stored at Hospital B, by Bobs primary physician Alice at Hospital A. When patient Bob registers at Hospital A, he commits his access rights to his historic data stored at other hospitals to Hospital A for the duration of his hospital stay. Hospital A assigns the appropriate access roles for Bobs data to corresponding healthcare team members at Hospital A, in accordance with the hospitals security policy; this results in an update to the URP relationship table in the LAC of Hospital A. Based on Bobs commitment to Hospital A, it also assigns

i n t e r n a t i o n a l j o u r n a l o f m e d i c a l i n f o r m a t i c s 7 7 ( 2 0 0 8 ) 242248

247

access privileges to some members of the IUG, according to its security policy. During the course of Bobs healthcare service at Hospital A, Alice needs to refer to Bobs historic data at Hospital B. After a successful login process (user authentication), Alice sends the data request to the CAC. The CAC asks the LACA about Alices access privileges to Bobs historic data (OHD). The LACA returns the URP relationship to the CAC. The CAC then inspects the URP relationship to determine whether this request should be approved. The CAC redirects Alices request to the LACB , which grants permission to access the data and passes on the request to the HISB . The LACB then reformats the retrieved data to the XML-based common format and returns it to the CAC. To protect Bobs data, the CAC attaches a digital signature and performs selective encryption of the data received from the LACB . Finally, Alice reviews Bobs historic medical records stored in Hospital Bs repository. Scenario 2: Retrieval of patient Bobs current healthcare data, stored at Hospital A, by a consulting physician John at Hospital B. Bob registers at Hospital A, and commits his access rights to his healthcare data for the duration of his hospital stay. Hospital A assigns the appropriate access roles to Bobs healthcare team members at Hospital A. However, some staff members at Hospital B (OUG) are included in the organized team members, and are granted the appropriate access privileges for Bobs data at Hospital A. That is, Hospital A enrolls them as OUG, and then LACA updates its URP relationship table according to the assigned roles for the OUG. During the course of the healthcare service, Bobs primary physician Alice at Hospital A needs to consult with physician John at Hospital B. Consequently, John at Hospital B needs to access Bobs current health data, which are stored at Hospital A. After Johns successful login process (user authentication), he sends the data request to the CAC. The CAC asks the LACA about Johns access privileges to Bobs current healthcare data. The LACA returns the URP relationship to the CAC. The CAC then inspects the URP relationship to determine whether this request should be approved. The CAC redirects Alices request to the LACA , which grants permission to access the data and passes on the request to the HISA . The LACA then reformats the retrieved data to the XML-based common format and returns it to the CAC. To protect Bobs data, the CAC attaches a digital signature and performs selective encryption of the data received from the LACA . Finally, John reviews Bobs healthcare data stored in Hospital As repository.

5.

Discussions and conclusion

Multi-institutional and multi-specialist medical consultation, and lifetime healthcare records are important for providing a better patient healthcare service. However, patient healthcare data are held in multiple hospitals, whose repositories have different record formats at different locations, and are governed by each specic hospitals policies. A centralized data repository is one possible solution for managing multiple heterogeneous repositories. The healthcare data, recorded at different hospitals, would be transferred to a data center, where they are stored and managed accord-

ing to that centers policy and format. If a centralized system were employed to control the mapping between different formats and role relationships, the complexity of the system would increase exponentially with the number of hospitals. In addition, not only can the number of hospitals grow, but their data formats and role relationships might also change. In that case, the system would necessitate a central mapping table that comprises the mapping between different formats and the role relationships of hospitals, which would need to be updated, resulting in a signicant increase in maintenance costs for the centralized system. Moreover, the centralized system would be vulnerable to hacker attack. Security issues and the large size of a central repository can have particularly serious consequences for a nation-wide cooperative healthcare network with national lifetime medical records. Instead of a centralized control system, our system utilizes multiple systems (LACs) in a distributed conguration, with one central CAC serving as the communications hub. Each LAC can adopt a native data format and security policy specic to the particular hospital with which it is associated. The LAC complies with the heterogeneous hospital setting, which differs from hospital to hospital. In other words, a particular hospital setting cannot be affected by other hospitals settings, and they can only be accessed through an intermediate LAC. A single CAC in combination with multiple LACs simplies the addition and deletion of data repositories from the entire conguration, because the CAC serves as the communications hub. Additionally, the proposed system offers the exibility for changes in security policy and data format. In this case, only the modication of the relevant LAC is sufcient, because of the independence and locality of the LAC compared with others. However, in a distribution conguration, some weak points should be carefully managed. The security level will be governed by the weakest LAC, and a high level of trust must exist among all LACs. The response time for accessing data will vary depending on the capabilities of associated LAC infrastructures. Moreover, in order to cope with the introduction of new technologies, and user requirements, it is recommendable to equip scalable infrastructure. The scalability cannot only adopt new requirements, and strategies, but also to migrate into next generation system incrementally. The proposed system uses XML messages for communication, which enables a exible design for the exchange of healthcare data in a common format. Each LAC is then responsible for transforming the records from the local HIS from their native format into a common data format using XML. Additionally, the use of XML message structures can enhance security by utilizing the security functions provided, which includes certicates for authenticating user identity, signatures for data integrity, and encryption for data protection. Encryption is normally performed for all items associated with patient healthcare data by default, as comprehensive criteria for determining which items should be encrypted have not yet been established. However, the computational burden increases as the amount of data to be encrypted and decrypted increases. This is particularly severe if health records with imaging data are accessed through a CA consisting of a lowperformance computing device, such as a portable digital assistant (PDA). It is generally thought that raw image data are rarely recovered in the proper order if the header associated

248

i n t e r n a t i o n a l j o u r n a l o f m e d i c a l i n f o r m a t i c s 7 7 ( 2 0 0 8 ) 242248

Summary points The following facts were known before this study: The Internet-based exchange of patient data is particularly useful for cooperative healthcare, and for the creation of lifetime healthcare records. Patient healthcare data are held in multiple hospitals whose repositories have different record formats at different locations, each of which are governed by their respective hospital policies. Important healthcare data should be exchanged over the Internet condentially to protect patients privacy. This study has added the following to our knowledge: A multi-agent architecture using XML, PKI, and the RBAC can interconnect heterogeneous repositories with different formats and different hospital policies, and allow them to communicate securely. The four-tier architecture consisting of CAs, a CAC system, LAC systems, and HISs can provide a means to exchange healthcare data over the Internet for multi-institutional and multi-specialist cooperative healthcare, and for lifetime healthcare records.

information. Therefore, the proposed system is useful for establishing a patient-centered framework for the exchange of healthcare data over the Internet, which is particularly important for multi-institutional and multi-specialist cooperative healthcare, and for the maintenance of lifetime healthcare records.

Acknowledgement
This study was supported by a grant of the Korea Health 21 R & D Project, Ministry of Health & Welfare, Republic of Korea (02-PJ3-PG6-EV08-0001).

references

with the image display format is well protected by encryption. If a patient agrees on the selective encryption of permitted items, the encryption can be applied only to these items in order to reduce the computational burden. Moreover, accesscontrol policies, including AC decision rules, can be properly expressed by XML-based policy and access-control decision request/response language (XACML) [14]. In the current paper, we have proposed a multi-agent secure architecture for uniform and transparent access to healthcare information from heterogeneous repositories located in various hospitals. The proposed system is organized into a four-tier architecture consisting of the CA, the CAC, the LAC, and the HIS. An emphasis is placed on the use of distributed processing with multiple HISs, multi-agent systems of LAC, and multiple CAs connected via the Internet to the CAC. Multiple LAC systems connected to a central controller (CAC) serve to interconnect heterogeneous repositories with different formats and different hospital policies, and allow them to communicate securely using a common format. This conguration also simplies and localizes the effects of complex maintenance operations, including the addition, removal, and modication of repositories. The combined use of XML and the RBAC system enables efcient repository management by providing constructs for access-control, information exchange using a common format, user identication for authentication, digital signatures for data integrity, and selective encryption for protecting condential health

[1] D. Gritzalis, C. Lambrinoudakis, A security architecture for interconnecting health information systems, Int. J. Med. Inform. 73 (3) (2004) 305309. [2] V.N. Kallepalli, S.A. Ehikioya, S. Camorlinga, J.A. Rueda, Security middleware infrastructure for DICOM images in health information systems, J. Digit. Imaging 16 (4) (2003) 356364. [3] R.E. Scott, P. Jennett, M. Yeo, Access and authorisation in a Glocal e-Health Policy context, Int. J. Med. Inform. 73 (3) (2004) 259266. [4] B. Blobel, Authorisation and access control for electronic health record systems, Int. J. Med. Inform. 73 (3) (2004) 251257. [5] S. Tzelepi, G. Pangalos, G. Nikolacopoulou, Security of medical multimedia, Med. Inform. Internet Med. 27 (3) (2002) 169184. [6] C.K. Georgiadis, I.K. Mavridis, G. Nikolakopoulou, G.I. Pangalos, Implementing context and team based access control in healthcare intranets, Med. Inform. Internet Med. 27 (3) (2002) 185201. [7] D.F. Ferraiolo, D.R. Kuhn, R. Chandramouli, Role-Based Access Control, Artech House, 2003. [8] S. Gritzalis, D. Gritzalis, C. Moulinos, J. Iliadis, An integrated architecture for deploying a virtual private medical network over the Web, Med. Inform. Internet Med. 26 (1) (2001) 4972. [9] B. Dournaee, XML Security, McGraw-Hill, 2002, pp. 107278. [10] D. Eastlake, J. Reagle, XML Encryption Syntax and Processing, W3C Recommendation, 10 December 2002, http://www.w3.org/TR/2002/REC-xmlenc-core-20021210, accessed 10 July 2004. [11] D. Eastlake, J. Reagle, D. Solo, XML-Signature Syntax and Processing, W3C Recommendation, 12 February 2002, http://www.w3.org/TR/2002/REC-xmldsig-core-20020212, accessed 10 July 2004. [12] R. Housley, W. Polk, W. Ford, D. Solo, IETF, RFC 3280: Internet X.509 Public Key Infrastructure Certicate and Certicate Revocation List (CRL) Prole, April 2002, http://www.ietf.org/rfc/rfc3280.txt, accessed 10 July 2004. [13] HL7 Standard, Clinical Document Architecture (CDA), http://www.hl7.org/, accessed 10 July 2004. [14] R. Cover, Extensible Access-control Markup Language (XACML), http://xml.coverpages.org/xacml.html, June 2005.