Supporting Patients’ Privacy Preferences Using Aspects

pointcuts. We can write an aspect with abstract pointcuts and abstract methods. A subaspect then extends the abstract aspect and deˆnes the concrete pointcuts and methods. Such abstract aspects open the way to build generic aspects that are essential to an aspect framework. Our proposed scheme takes full advantages of the above features of AspectJ. The one class and three aspects in Figure 1 outline how we our approach works. Here the class, PData, contains patient data that must be protected. The aspect, PrivacyGeneric, illustrates the generic structure of a privacy enforcing aspect. It is an abstract aspect because the method, getPatientPref, is abstract. Its around advice (Line 07~13) monitors the execution of the access control module via the pointcut PDP. When an access request is granted, the advice will get the intended purpose of use and the purposes consented by the underlying patient on the contents of PData. If they match, then the execution is resumed; otherwise, the access request will be denied. Besides, there are two sub-aspects of PrivacyGeneric, namely Privacy1 and Privacy2. The ˆrst sub-aspect simply deˆnes the missing method, but the second sub-aspect is more complex. It uses inter-type declaration 120 Supporting Patients' Privacy Preferences Using Aspects mechanism to add a new ˆeld to the class PData (Line 20), and employs after advice (Line 2122) to ˆll in that ˆeld after an instance of PData was created. 3. The Privacy Framework Currently, employing a proper access control mechanism to protect patients' electronic health records is a well-accepted discipline in HIS development6,7). However, the design of such mechanisms hardly takes patient privacy requirements into account. Indeed, privacy protection goes beyond the traditional view of access control by requiring some additional complexity. There are complex questions of who controls the data about us and how they are used. In making access control privacy aware, the recent trend is that permission to use any sensitive data should be linked to the purpose of use8). For example, a doctor may have permission to hold personal data for operational health care delivery, but not for other purposes such as research, or health product promotion. Moreover, patient consent should be checked, and each data subject may make diŠerent decisions regarding which parts of his/her personally identiˆable information (PII) can be accessed by who under what intent. In other words, the decision on disclosing a patient's PII is extremely ˆne-grained: it does not only depend on the data contents and purpose of use, but also is patientspeciˆc. On the other hand, we must also consider the proper balance between patient safety and patient privacy in exceptional situations. In particular, during an emergency, an attending physician needs to bypass routine access control restrictions to provide timely treatment without any delay due to administrative or technical complexities. This is often referred to as the break glass policy9). Yet, once such privileged requests were allowed, the access control system should create an audit trail, executed as an obligation, for administrative review. However, auditing and reporting is di‹cult to manage. Each application in a HIS usually creates logs in an application speciˆc way and may not provide audit trails detailed enough for privacy auditing purpose. Preparing an audit report from such logs is not only time-consuming but also imprecise. Thus, it is desirable to have a centralized auditing mechanism that can create required logs for all requests and accesses to PII data. The goal of our framework is to enhance access control to patients' health records with enforcement and auditing of patients' privacy preferences regarding the use of their personal information. The main di‹culties in achieving this lies in the fact that, in current practices, privacy polices and patient consent are usually added after the HIS has been built. Hence, even though it is possible to collect patients' preferences for controlling access to their health records afterwards, it is rather di‹cult to enhance the working access control system yet being able to accomplish it with little impact on the structure of the underlying HIS. Based on our prior experience10,11), we claim that we can further leverage the aspect technology to develop a privacy framework to address the issues described above. The proposed privacy framework consists of three main components, namely action purpose manager, privacy aspect and patient preference manager. Figure 2 displays the structure of the framework, and highlights the interaction between the framework and the underlying access control system. The remainder of this section describes how they work together to provide privacy-aware access control and the next section will sketch how to implement this privacy framework. For the purpose of this work, we follow the industry practices such as XACML12), and assume the existence of the policy enforcement point (PEP) and policy decision point (PDP) in an access control system. All user requests to access a