medical records; Information and Communication Technology. I. INTRODUCTION ... Insurance Portability and Accountability Act (HIPAA) has similar motivation ... comply with the privacy requirements outlined in the various laws and policies.
Protecting Patient Privacy in Distributed Collaborative Healthcare Environments by Retaining Access Control of Shared Information Peter R. Burnap1, Irena Spasić1, W. Alex Gray1, Jeremy C. Hilton1, Omer F. Rana1, Glyn Elwyn2 School of Computer Science & Informatics1, School of Medicine2 Cardiff University Cardiff, UK interoperability between distributed healthcare systems, law and policy making officials define the data sharing constraints necessary to protect the privacy of individuals in such environments. EU member states have enacted data protection laws that align with the 1995 European Union Directive 95/46/EC on Data Protection [11], which defines cross-industry standards regarding privacy of personal data. The US Health Insurance Portability and Accountability Act (HIPAA) has similar motivation, as do similar laws in Canada, Australia and Japan [12]. One of the key principles behind the EU directive is that information must “not be kept in personal form for longer than necessary for the purposes for which they were collected or (compatibly) further processed.” Therefore, when information is shared between healthcare professionals in support of collaborative patient care, the information owner (in this paper we refer to the ‘owner’ as the entity legally accountable for information disclosure) must ensure (i) the information is not accessed by third parties for use beyond the agreed purpose of sharing and (ii) does not remain accessible to collaborators once the initial purpose of sharing is complete. We appreciate that (ii) may be contentious in medicine as records are often kept for longer periods in case of legal action or patient relapse. However, (i) still stands regardless and we aim to stop the unauthorized leakage of personal information.
Abstract - Access control and privacy policies change during the course of collaboration. Information is often shared with collaborators outside of the traditional “perimeterized” organizational computer network. At this point the information owner (in the legal data protection sense) loses persistent control over their information. They cannot modify the policy that controls who accesses it, and have that enforced on the information wherever it resides. However, if patient consent is withdrawn or if the collaboration comes to an end naturally, or prematurely, the owner may be required to withdraw further access to their information. This paper presents a system that enhances the way access control technology is currently deployed so that information owners retain control of their access control and privacy policies, even after information has been shared. Keywords-Privacy; Data security; Access control; Electronic medical records; Information and Communication Technology
I.
INTRODUCTION
A recent study indicated that more than 90% of patients supported the sharing of their medical records between healthcare professionals when it is used to provide better informed clinical care and advice [1]. Modern healthcare information systems are striving to support the seamless sharing of patient medical records between members of clinical care teams as a patient’s treatment follows a clinical pathway [2-5]. Such information is typically stored as part of several distributed Electronic Medical Records (EMRs), electronic documents containing information about the patients’ medical history [6]. There are emerging standardization efforts to address interoperability issues among distributed information systems by encoding EMRs using a standard information model (e.g. HL7 [7]), and physically transferring the records between distributed autonomous systems using a standardized set of interfaces (e.g. Continua Health Alliance [8]). One of the main aims of these efforts is to maximize the accessibility of EMRs to clinical care teams to improve the treatment of a patient through collaborative healthcare [9] and decision making [10]. However, systems that facilitate EMR accessibility must also take account of the limits to personal data sharing imposed by privacy protection laws.
Despite the recent paradigm shift towards collaborative patient-centric care, most existing EMR systems are legacy systems or silos originally designed and deployed with the sole purpose of local usage [13]. As a result, most access control technology currently deployed in healthcare environments is designed to retain access control of personal information when it is physically stored in a local system. In this paper, we define local systems as institutional information systems that exist in private information domains (e.g. private hospitals, national health service institutions such as those run by the NHS in England and Wales, and GP practices). Access control technology aims to provide a barrier between EMRs and potential readers that can be lifted when the information owner grants access. Within a collaborative environment, problems in adhering to privacy laws arise when electronic information is copied from the information owner’s local system into the autonomous system of a collaborator, because the copied information then resides outside the owner's access control domain. This information could be forwarded to another third
While information model and data interchange standards such as HL7 and Continua [7, 8] address the problems of
978-1-4673-1382-7/12/$31.00 ©2012 IEEE
490
party and used for a secondary purpose (e.g. an insurance company). It could also be mishandled and lost, as evidenced by the recent loss of 8.6 million personal health records in the UK [14] and the reported 165 breaches or personal and confidential information in the UK NHS last year [15].
patient care is frequently transferred back to centres B or C. Such practice is also common in Wales and has been noted in a similar study into MDTM in Australia [17]. To support the discussion at the MDTM, information relating to patients’ conditions is collected from electronic medical records maintained in centres A, B and C. An MDTM administrator collects relevant patient information from multiple sources (e.g. the radiology and pathology departments of the patients’ local hospital) and shares the relevant information at the meeting on a global screen and grants access to members of the MDT. Opinions are sought from the members, based on their expertise and the information available, in order to reach a decision on how best to treat the patient.
Access control technology in an information-sharing environment, such as healthcare, has yet to be enhanced to comply with the privacy requirements outlined in the various laws and policies. To date, there is no published access control technology that allows the information owner to effectively revoke access to their information once it has been physically shared with a collaborator outside their domain. This means that if it is lost, forwarded or archived, it can be accessed and reused at a later date for purposes other than those for which it was originally shared without the owner’s knowledge. This is particularly relevant to EU countries, where there is a legal requirement to prevent access to personal data beyond the purpose for which it was initially gathered and shared. Such an access control barrier cannot currently be re-introduced after the information moves out of the information owner’s EMR system.
The sharing scenario can be described as: After presenting symptoms of cancer, a patient is referred by their GP to their local hospital (e.g. centre B), where the necessary tests and diagnostic procedures are performed. The patient’s case is referred to an MDTM for discussion. Centre C performs the role of information collection for MDTM events and, therefore, requests the patient information from centre B. Centre B shares the information with centre C for the purpose of MDTM discussion, based on the understanding that it will revoke all access to it after the meeting. Following the meeting, centre C informs centre B that surgery has been recommended by the MDTM and at this point centre B revokes access to the information they shared with the MDTM to prevent further unauthorized use (e.g. leakage by MDTM members). Centre B does not have the facilities or resources to perform the surgery and thus refers the patient to centre A, a better equipped hospital, for surgery. Centre B also sends all the patient information to centre A. It is difficult to determine prior to surgery what information is pertinent to it, so as much information as possible is shared at that time.
This paper proposes a secure information sharing solution where EMRs from many different sources can be gathered to create a virtual patient record for a specific purpose (e.g. multidisciplinary decision making), and where each institution can revoke access to their parts of the virtual record when the purpose of sharing is over. We use a worked example of information flow within a multi-disciplinary team meeting (MDTM) for cancer care, with information sharing scenarios based on documented practice. The approach has been motivated by the need to share personal information between institutions with shared interests in patient care. Section 2 describes a clinical use case scenario, developing the privacy requirements and defining the limitations of existing access control technology in supporting the scenario. Section 3 details the design and implementation of the proposed technical solution. Section 4 outlines a test case and reports the successful implementation of a technical solution. Sections 5 and 6 discuss some of the limitations and future developments of the proposed approach, and draws conclusions. II.
Following the surgery, the patient is returned to centre B for care, along with a summary of the surgery notes. Some of the information shared by centre B has been used to inform decision making during surgery at centre A, and some has not been used by centre A. The information that has been used to inform decisions (e.g. X–rays and CT scans) is kept by centre A for very specific cases of possible future use such as patient relapse, audit or misconduct allegations. Non-pertinent information, i.e. information not used to make decisions (e.g. pathology results and psychological evaluations) should not be retained by centre A as they have no purpose to keep it, thus it is revoked by centre B. None of the information should be accessible to anyone outside these three collaborators, even is lost, stolen or inadvertently shared. As healthcare information systems strive to support the seamless sharing of medical records between members of clinical care teams while the patient’s care follows the treatment pathway [2-5], the exposure to information loss increases, unless the information access can be effectively controlled after being shared.
BACKGROUND
A. Medical Information Sharing Scenario To illustrate the need and requirements for a system that enables the information owner to comply with privacy laws while sharing patient information, we use a case study based on actual practice in multi-disciplinary team meetings (MDTM). Sharing information to improve clinical decision-making is particularly relevant in MDTM because they depend on the gathering of clinical patient information, often from multiple sources, to provide information to support an informed decision on how the patient should be treated. Kane and Luz [16] conducted an in-depth study into MDTM processes at a large teaching hospital and tertiary referral centre (which they refer to as centre A), and two smaller regional hospitals (which they refer to as centres B and C). They found that it was not unusual for a patient at centre B or C to be referred to centre A for surgery, following the advice of the MDTM. Post-operative
B. Access Control of Shared Information Before proceeding to describe the issues surrounding the retention of access control for shared information, let us define some of the related concepts. Access control technology
491
comprises a number of elements and ways in which they interact, to provide a barrier between an information resource (e.g. an EMR), and individuals or systems (both of which are referred to hereafter as subjects) who attempt to access them, in accordance with an access control policy [18]. An access control policy contains a number of rules that define the conditions under which subjects are permitted to access information resources. Such rules can be described as a combination of subject, action, resource and purpose, as described by Rahmouni et al. [19]. Subject and resource are semantically aligned to our definitions. Action and purpose define specific actions (e.g. read or write) and reasons why the subject is trying to perform the action on the resource (e.g. treatment). The process of determining whether a subject is permitted to perform an action on a resource is known as authorization.
on the target resource. The PDP returns the decision to a PEP, which then enforces it. Fig. 1 illustrates that effective access control depends on communication between access control elements. Therefore, retaining access control of shared information depends on maintaining communication between the access control elements, and making them available to support policy evaluation and enforcement on shared resources. To analyze the ability of existing access control technology to fulfill these dependencies, it is useful to define a set of access control rules that enforce continuous communication and availability:
Summarizing the de-facto access control standards: OASIS XACML access control architecture [20], which is referenced by the Health Information Technology Standards Panel (HITSP) security and privacy technical committee; and ISO 10181-3 access control framework [21], access control technology involves three key interacting elements, referred to hereafter as the access control elements: •
A Policy Storage Point (PSP),
•
A Policy Decision Point (PDP), and
•
A Policy Enforcement Point (PEP).
1.
An information owner must be able to access a PSP and modify access control policy.
2.
A PDP must be able to reference the PSP.
3.
A PEP must be able to invoke the PDP.
4.
A PEP must be available and able to enforce the policy on shared information.
When these control rules are in place, the owner retains control of their shared information. However, upholding the rules is difficult in cross institutional information sharing scenarios because each institution commonly has its own local system, within which they deploy access control elements to protect their information resources (e.g. EMRs). If an EMR from institution A were shared with institution B, the PEP deployed within A’s local system would no longer be available to enforce access control policy for the shared EMR at B. This breaks access control rule 4. Let us therefore define this limitation of control as the perimeter. Formally, the perimeter defines a logical boundary; outside of which continuous communication between access control elements and/or availability of access control elements is lost, which in turn breaks the control rules. In many EMR systems designed for local usage, the perimeter is an organizational computer network. In general, the access control rules get broken whenever information or any of the access control elements move outside the perimeter. The conceptual perimeter plays an essential role in enabling retention of access control. Efficient collaboration between distributed healthcare professionals aims to break down boundaries between information systems and maximize the information available to clinical decision makers. This presents a problem to institutions that have access control systems that can only retain access control of information in local systems because they are inherently perimeterized, i.e. they have definite limitations to communication between access control elements and availability to shared resources. We therefore aim to redefine the perimeter so that communication between access control elements and their availability to shared resources is not limited to local systems. By redefining the perimeter we can uphold the control rules even when information is shared between institutional information domains, thus ensuring that the owner retains access control over shared information.
Figure 1. Access Control Element Interaction.
As illustrated in Fig. 1, the roles of the access control elements in relation to an information resource whose access they control are as follows: The PEP acts on behalf of the subject to submit an access request to a PDP. When an access request, which consists of a subject identifier, a target information resource, and a requested action, is received by the PDP, it obtains an access control policy from a PSP, which provides storage and management of access control policies. The access request is then evaluated against the access control policy by the PDP, in order to decide whether the subject should be granted permission to perform the requested action
492
application. The access control policy moves with the shared information and the DRM technology extracts the policy, evaluates it, and enforces it on a remote machine. Like the sticky policy approach, DRM breaks access control rule 1, because the information owner cannot modify the access control policy attached to the information once it has been shared.
C. Existing Access Control Technology Many existing approaches to sharing medical information aim to support cross-organizational information sharing [2227]. Access control is an essential requirement for all of them. Subjects’ requested actions are authorized before any information is released to them. However, they are perimeterized approaches, meaning that the access control elements in these approaches can only communicate within a local system. Once information has been released outside the system, access can no longer be revoked. The control rules are broken because information has moved outside the information owners’ physical control.
Effectively, existing approaches to enforcing access control beyond a local system involve copying the access control elements (i.e. PSP, PDP and PEP) to any endpoint where access needs to be controlled. This provides the ability to remotely enforce access control policy on shared information. However, moving the access control policy (PSP) to an endpoint, which is inaccessible to the information owner, causes loss of continued control and breaks control rule 1. Thus, to uphold the access control rules, a new approach is required to deploy the access control elements in such a way that: (i) a PEP is available to enforce policy at remote endpoints (access control rule 4); (ii) the PEP can communicate with a PDP so that it can evaluate access requests (access control rule 3); (iii) the PDP can locate the access control policy for shared information, from a PSP (access control rule 2); and (iv) the information owner can modify the access control policy for their shared information and revoke previously granted access rights when a collaboration is complete (access control rule 1).
Privacy laws require access to third parties to be granted for a specific purpose only, and that the information should not be available to them after that purpose is complete. Consequently, a recent review of security and privacy issues in healthcare systems highlighted the need to enhance access control technology to “implement authorization across organizational boundaries” [13]. This suggests that a perimeterized approach, where an institutional local system is the limit of effective authorization, is no longer sufficient. This requirement is supported and refined in [12] which suggests that, when healthcare organizations share personal patient data, they need to ensure that the access control policy will be enforced on the shared information as a pre-condition of transfer. In other words, when medical information is shared outside an organizational boundary, its policy must be enforceable within the organizational boundaries it has moved to.
Points (i)-(iii) can be achieved using the sticky policy approach or a DRM solution, but point (iv) requires the resource owner to retain control of the PSP. In previous approaches, shared information is effectively moved outside the perimeter because of point (iv). We therefore propose a new deployment of access control elements that “stretches” the perimeter, so that a PEP can move to any remote endpoint and enforce access control policy for shared information across organizational boundaries, but where the PSP remains under the control of the information owner, on their local system, so that the owner can change the policy and know the modified policy will be enforced on all copies of the information. The challenge here is to retain communication between distributed PEPs and local PDPs and PSPs, so that the latest version of an access control policy can be obtained. By doing this using an Internet-enabled connection, it is possible to allow access control policy to be modified and enforced on shared information.
So-called “sticky policies” are a way of enforcing access control on systems outside of the control of the information owner, by transferring access control policy to the collaborator together with the shared information [12]. Approaches described by Chadwick et al. [28] and Mont et al. [29] show how sticky policies can be implemented in practice. The sticky policy approach is based on the assumption that all access requests are audited, and that the recipient is, in principle, obliged to enforce the policy when the shared information is accessed. Failure to comply leaves them open to legal action using the logs that show they were granted access provided they enforce the policy. Even so, once the sticky policy has moved from the information owner’s local system into the autonomous systems of their collaborators, the transferred policy should be enforced, but it can no longer be modified. The shared information may be copied or moved between computers (e.g. emailed to other people) and removable devices (to work remotely) in the collaborator's system, meaning potential access control policy updates would not necessarily result in them being applied to the shared information, even if the collaborator is notified. This means that the information owner cannot modify their access control policy once it has been shared with collaborators, thus breaking access control rule 1.
III.
METHODS
As illustrated in Fig. 2, we have developed an architecture and implemented supporting technology that enables the proposed access control rules to be upheld simultaneously, while sharing information between collaborating organizations. The technology, that we will refer to as “our system”, is distributed as a standalone Java application under an open source license on SourceForge, which can be used by software developers interested in modifying the functionality or simply reusing some of its components as part of different medical informatics applications.
The sticky policy approach is very similar to that used in technology controlling access to digital media, known as Digital Rights Management (DRM) [30], which physically copies all the access control elements to the computer of an individual requesting access to digital media. DRM technology plays the roles of PSP, PDP and PEP in a single standalone
493
Figure 2. System Interaction Architecture
Figure 3. Workflow to Prepare Resource
Our approach logically locates the Policy Storage Point (PSP) and Policy Decision Point (PDP) on a local computer network, managed by the information owner, and distributes the Policy Enforcement Point (PEP) together with the shared
information across remote networks, so that access control can be enforced no matter where the information is now held. To overcome the logical break in communications between the PDP and PEP, a static logical address (e.g. a URL) is
494
embedded into a file that contains shared information, which the distributed PEP can extract and use to send a message to the PDP. This approach effectively “stretches” the perimeter of control across multiple autonomous networks, meaning shared information in these networks effectively remains under the control of its owner, while being physically stored on remote networks. This section details the design and implementation of our approach.
Wherever the file is physically located from this point on, it always has a pointer to the PDP required to handle access requests, and an identifier to inform the PDP which target resource is being accessed. The PEP can extract and use this information to route requests to a PDP. This will allow the PEP to obtain the latest access control policy and receive any modifications or withdrawals in future. If access is granted by the PDP, the decryption key for the file is returned to the PEP, which in turn decrypts the file and displays it in a “viewer window” (think of a PDF file). If access is denied, the key is not returned. When the user manually closes the “viewer window”, the information is discarded.
A. Distributed Access Control Enforcement The key point to explain here is how communication is maintained between the distributed PEP and a centralised PDP. This section explains the methodology for achieving this. We assume that EMRs can exist as self-contained files (e.g. plain text document) or as a record in a database. In the latter case, a record from a database can be exported to a file containing medical information specific to a patient in order to share it. Therefore, for simplicity reasons, we will hereafter refer to such information as a file that contains shared information. It is worth noting that the access control provided by a database management system is ineffective once information is shared outside the database.
In this paper we will not discuss the methods used to create access control policies as many of the approaches we discussed in the related work section can already do this, and do it in different ways. The importance of our work is to locate the latest version of a policy, in whatever electronic form and structure, and enforce it on each individual distributed patient record, which we suggest can be achieved through centralising the access control policies for shared information and maintaining a link to distributed patient records using the methods described. For demonstrative purposes, we represented access control policies in a database as triples of the form subjectID, targetID, action. For instance: subject S is authorized to read target T. For each subject we stored a name (e.g. Dr X), a role (e.g. GP), and an institution (e.g. ThisTown General Practice). The targetID is the UUID of the shared file, and we only focus on read access in this work.
When sharing information outside a local system, the information owner needs to ensure that unauthorized subjects cannot access the information. This requires a shared file to remain inaccessible prior to the access control policy being enforced by a PEP. Our system uses encryption to enable this. The workflow to prepare a file for sharing is illustrated in Fig. 3 and explained here: a file is encrypted before it is distributed, and the decryption key is stored on the information owner's site in a key database. Our system enables the information owner to select a file to ‘share’, the selected file is then encrypted with a randomly generated 256 bit AES encryption key, which is stored in the key database. To link the encryption key to the shared file, our system dynamically generates a Universal Unique Identifier (UUID) for the file, which it stores in the key database, in the same row as the key needed to decrypt the file. To bind the UUID to the selected file, our system reduces it to a stream of bytes and appends the UUID to the encrypted data in plain text. The file can now be securely distributed and can only be accessed through a distributed PEP.
IV.
EXPERIMENTAL TEST CASE
Based on the information sharing scenario given in Section II.A, we differentiate between three local information systems: the patient’s lead care hospital and patient information owner (centre B), the supporting surgical hospital (centre A) and the MDTM lead hospital (centre C). Note that MDTM members can initially access information collected and managed by centre C and may comprise employees from all three centers. We set up three virtual machines representing the three domains involved (i.e. centre A, B and C). One, virtual machine (M1) representing the information owner’s domain (i.e. centre B) was configured with a PSP (including access control policies) and PDP Web service, as well as a key store for decryption keys. The other two virtual machines (M2 and M3), representing the collaborating partners, i.e. MDTM lead hospital (centre C) and surgical hospital (centre A), respectively, were configured with a distributed PEP and an X.509 digital certificate containing identity details, within a virtual machine located on a computer network.
To enable the distributed PEP to communicate with the local PDP of the information owner, we need to provide the PEP with an Internet addressable endpoint for the relevant PDP. The PDP is implemented as a Web service, a server-side application used programmatically by remote applications, capable of accepting requests over the Internet from distributed PEPs. Our system prompts the information owner for a URL that points to the endpoint of the PDP. The system then inserts the URL in plain-text at the end of the file’s byte stream after the UUID. The UUID has a fixed length, so by inserting a delimiter between the UUID and the PDP URL (an @ symbol that would not appear in a URL), the byte stream can be read backwards from the end, one byte at a time, until the delimiter is located. When the delimiter is reached, we have our URL and we know how many more characters we need to extract from the file to obtain the UUID. The remaining data is the encrypted file.
Three files (F1, F2, and F3) representing medical records containing test results and scans were shared by M1 (i.e. centre B) with M2 (i.e. the MDTM at centre C), allowing them read access, for the purpose of MDTM discussion. We sent the files to M2 to an email account created for the study. Once received, an attempt was made to read their content, using the PEP, which forwarded the requests to the PDP. We monitored incoming HTTP requests to verify they were reaching the correct PDP with the relevant identity credentials, target resource UUID, and requested action. The decryption key was
495
successfully returned to M2, and the PEP decrypted the files and accurately displayed their content in non-editable windows.
evaluated. By doing this, the access control elements were distributed across local and remote networks, but always remained inside the same logical perimeter, that is, communication between elements and their availability to shared information remained possible. As a result, the information owner was able to effectively revoke access to previously shared information.
We then modified the PSP on M1 to revoke access to the files for M2, i.e. we removed the read access right from the access control policy for this domain. This demonstrates the revocation of access when the purpose of sharing is complete. We repeated the previous access request steps and observed the requests were the same as before, but the HTTP response from the PDP to M2 was now deny and the decryption key was not part of the payload. Therefore, when the PEP could not locate the key, it presented a message that access was denied.
Our approach relies on documents (or files) as the transfer mechanism for information, which makes it suitable for transactional processing in a heterogeneous, asynchronous, distributed environment such as healthcare. Our information sharing model decouples information from large data resources they are originally stored in, minimizing dependencies on such systems across different organizations. This makes our approach flexible and universally applicable, while still protecting privacy using an Internet connection to support communication between PEP and PDP in order for an owner to retain access control over the shared information. However, there are some issues associated with the approach taken.
We then sent the files to M3 (i.e. the surgical team at centre A) to represent the patient being referred for surgery along with all the relevant information to inform surgical decisions. We then attempted to access the files from M3 using the PEP, which in turn forwarded the requests to the PDP. The decryption keys were successfully returned to M3, and the PEP decrypted the files and accurately displayed their content. We then modified the PSP on M1 to revoke access to files F1 and F2 for M3 and attempted to access all three files again. Access was denied to files F1 and F2 as expected, demonstrating the revocation by centre B of access to the patient information not used to inform surgery at centre A. However, access to file F3 was unaffected, representing centre A retaining future access as part of the patient’s hospital record at centre A. V.
From the information recipient's point of view, failing to establish an Internet connection means that their access request cannot reach the PDP and shared information cannot be decrypted, thus preventing their access to the shared information. This would be an issue in the case of emergency, where the real-time information access is critical. As illustrated in our use-case scenario, one of our main aims is to maximize the accessibility to medical information while protecting patient privacy in support of collaborative healthcare and shared decision-making. Obviously, emergency use would typically take precedence over privacy issues and information that might be required in an emergency may not be suitable for sharing with the additional privacy our system provides.
DISCUSSION
The key requirements of the given use case were that medical information could be shared with distributed healthcare professionals in support of collaborative healthcare and shared decision making, while supporting the information owner in complying with data protection laws. We particularly focused on the EU data protection directive, which states that personal data should “not be kept in personal form for longer than necessary for the purposes for which they were collected or (compatibly) further processed.” This presented the requirement to be able to revoke access to medical information at the end of collaboration and prevent access to people who have no legitimate reason to access it.
Another issue from the information owner's point of view is that a modified access control policy will be enforced the next time the information is accessed using the PEP, it is not instantly applied. This is because the proposed architecture works using a “pull” approach, i.e. the PEP requests the latest version of the access control policy each time shared information is accessed. Changes are not “pushed” and applied while the document is open. Finally, the PEP in our approach handles the decryption of the shared information, which creates a situation where a malicious expert user could in theory extract the decryption key from the PEPs application memory, thus being able to effectively decrypt the shared information. Working around policy enforcement is an issue already highlighted in some “sticky policy” approaches, such as Chadwick et al. [28] and Mont et al. [29] where the authors suggested the use of auditing and trusted platform modules to overcome the PEP "workaround" problems. To tackle this issue, we introduced a logging system to audit possible PEP workarounds. If information were to be leaked or reused without the permission of the information owner, a list of potential malicious users can be generated from the logs. The information owner would be able to provide evidence that access had been revoked, demonstrating officially that the malicious user had reused the information with intent to work around the access control policy.
Existing access control technology implemented the access control elements that we summarized from the key access control standards [20] [21] (PSP, PDP, PEP) as localized services that only support retained access control if they are all present inside the same logical perimeter, such as an organizational network. Recent work aiming to enforce access control between local networks effectively transferred all of the access control elements from the information owner’s local network to the collaborator’s remote network. However, by doing this, the information owner lost the ability to modify access control policies, which meant the revocation requirement could not be met. The proposed approach achieved retention of control by establishing a persistent connection between shared information, its owner, and the policy that governs its access, through a distributed PEP and an embedded static URL to which PDP access request messages could be submitted and
496
[11] European Union, European Union Directive on Data Protection, Http://europa.eu.int/comm/internal_market/en/dataprot/index.htm, Editor. 1995. [12] R. Agrawal and C. Johnson, Securing electronic health records without impeding the flow of information. International Journal of Medical Informatics, 2007. 76: p. 471-479. [13] H. van der Linden, D. Kalra, A. Hasman and J. Talmon, Interorganizational future proof EHR systemsA review of the security and privacy related issues. International Journal of Medical Informatics, 2009. 78: p. 141-160. [14] Information Age (Web). NHS unit lost 8.6 million patient records on stolen laptop. 2011; Available from: http://www.informationage.com/channels/security-and-continuity/news/1630788/nhs-unit-lost86-million-patient-records-on-stolen-laptop.thtml. [15] UK Information Commisioner's Office. Information Commissioner’s Annual Report. 2011. [16] B. Kane and S. Luz, Multidisciplinary Medical Team Meetings: An Analysis of Collaborative Working with Special Attention to Timing and Teleconferencing. Computer Supported Cooperative Work (CSCW), 2006. 15(5): p. 501-535. [17] T. Robertson, J. Li, K. O’Hara, and S. Hansen, Collaboration Within Different Settings: A Study of Co-located and Distributed Multidisciplinary Medical Team Meetings. Comput. Supported Coop. Work. 19(5): p. 483-513. [18] R. Sandhu, E. Coyne, H. Feinstein, and C. Youman, Role-based access control models. Computer, 1996. 29: p. 38-47. [19] H. Rahmouni, T. Solomonides, M. Mont, and S. Shiu et al. Privacy Compliance in European Healthgrid domains: An ontology-based approach. Proceedings of 22nd International Symposium on ComputerBased Medical Systems, Albuquerque, NM, USA. 2009. [20] OASIS, eXtensible Access Control Markup Language (XACML) Version 2.0. [21] ISO, ISO/IEC 10181-3:1996 - Information technology -- Open Systems Interconnection -- Security frameworks for open systems: Access control framework, ISO, Editor. [22] D. Gritzalis, A security architecture for interconnecting health information systems. International Journal of Medical Informatics, 2004. 73: p. 305-309. [23] J. Jin, G. Ahn, H. Hongxin, M. Covington and X. Zhang, Patient-centric authorization framework for electronic healthcare services. Computers & Security, 2011. 30(2-3): p. 116-127. [24] M. Li, S. Yu, K. Ren, and W. Lou, Securing Personal Health Records in Cloud Computing: Patient-Centric and Fine-Grained Data Access Control in Multi-owner Settings, O. Akan, et al., Editors. 2010, Springer Berlin Heidelberg. p. 89-106. [25] Y. Li, H. Kuo, W. Jian, D. Tang, C. Liu, L. Liu, C. Hsu, Y. Tan, and C. Hu, Building a generic architecture for medical information exchange among healthcare providers. International Journal of Medical Informatics, 2001. 61: p. 241-246. [26] P. Ruotsalainen, A cross-platform model for secure Electronic Health Record communication. International Journal of Medical Informatics, 2004. 73: p. 291-295. [27] F. Ueckert and H. Prokosch, Implementing security and access control mechanisms for an electronic healthcare record. Proceedings of AMIA Annual Symposium. 2002: p. 825-829. [28] D. Chadwick and K. Fatema, An advanced policy based authorisation infrastructure, in 5th ACM workshop on Digital Identity Management DIM '09. 2009. [29] M. Mont, S. Pearson and P. Bramhall, Towards accountable management of identity and privacy: sticky policies and enforceable tracing services, in 14th International Workshop on Database and Expert Systems Applications. 2003. [30] S. Hwang, How Viable Is Digital Rights Management? Computer, 2009. 42: p. 28-34.
VI. CONCLUSION Our study described a method of retaining access control even after information had been shared and moved into an autonomous computer network, within which the information owner had no formal control. We used a scenario of real-life medical information sharing to illustrate the need for and viability of the proposed approach. This study provides evidence of a technological basis for establishing a persistent connection between a shared information resource and its owner, which is used to support retention of access control. Permanent connection between shared information and its owner is achieved by installing policy enforcement tools on distributed machines and embedding a link to the policy decision point into a shared file. This allows the distributed PEPs to continue to communicate with a centralised PDP and PSP, and obtain the latest version of an access control policy. This enables the information owner to share information with collaborators, while being able to revoke access at any point and prevent collaborators and any other third party from gaining any further access to the previously shared information beyond the original purpose of sharing. Therefore, information can be shared between collaborating healthcare professionals in support of collaborative clinical advice and shared decision making, while assisting the resource owner in complying with privacy laws, allowing them to revoke access once the initial purpose of sharing is complete. REFERENCES [1]
G. Perera, A. Holbrook, L. Thabane, G. Foster and D. Willison, Views on health information sharing and privacy from primary care practices using electronic medical records. International Journal of Medical Informatics, 2011. 80: p. 94-101. [2] R. Blaser, M. Schnabel, C. Biber, M. Baumlein, O. Heger, R. Lenz, and K. Kuhn, Improving pathway compliance and clinician performance by using information technology. International Journal of Medical Informatics, 2007. 76: p. 151-156. [3] R. Lenze, R. Blaser, M. Beyer, O. Heger, C. Biber, M. Baumlein and M. Schnabel, IT support for clinical pathways—Lessons learned. International Journal of Medical Informatics, 2007. 76: p. S397-S402. [4] M. Muller, F. Uckert, T. Burkle, and H. Prokosch, Cross-institutional data exchange using the clinical document architecture (CDA). International Journal of Medical Informatics, 2005. 74: p. 245-256. [5] S. Wakamiya and K. Yamauchi, What are the standard functions of electronic clinical pathways? International Journal of Medical Informatics, 2009. 78: p. 543-550. [6] E. Shortliffe, The evolution of electronic medical records. Academic Medicine : Journal of the Association of American Medical Colleges, 1999. 74: p. 414-419. [7] G. Beeler, HL7 Version 3—An object-oriented methodology for collaborative standards development1. International Journal of Medical Informatics, 1998. 48: p. 151-161. [8] R. Carroll, R. Cnossen, M. Schnell, and D. Simons, Continua: An Interoperable Personal Healthcare Ecosystem. IEEE Pervasive Computing, 2007. 6: p. 90-94. [9] V. Patel, K. Cytryn, E. Shortliffe and C. Safran, The collaborative health care team: the role of individual and group expertise. Teaching and Learning in Medicine, 2000. 12: p. 117-132. [10] F. Legare, G. Elwyn, M. Fishbein, P. Fremont, D. Frosch, M. Gagnon, D. Kenny, M. Labrecque, D. Stacey, S. St-Jacques, and T. van der Weijden, Translating shared decision-making into health care clinical practices: Proof of concepts. Implementation Science, 2008. 3.
497
