Explaining Accesses to Electronic Health Records

Transcription

1 Explaining Accesses to Electronic Health Records Daniel Fabbri, Kristen LeFevre and David A. Hanauer {dfabbri, klefevre, Electrical Engineering & Computer Science, University of Michigan, 226 Hayward Ave. Ann Arbor, MI 4819 USA Department of Pediatrics, University of Michigan Medical School, 15 E Medical Center Dr. Ann Arbor, MI 4819 USA ABSTRACT Electronic health record systems (EHRs) are increasingly used to store patient medical information. To ensure the responsible use of this data, EHRs collect access logs, which record each access to sensitive data (e.g., a patient s record). Using the access log, it is easy to determine who has accessed a specific medical record. However, in addition to this information, we observe that for various applications such as user-centric auditing, it is also important to understand why each access occurred. In this paper, we study why accesses occur in EHRs. Our goal is to provide an explanation describing why each access occurred (e.g., Dr. Dave accessed Alice s medical record because Dr. Dave has an appointment with Alice). Using data from the University of Michigan Health System, we demonstrate that most accesses to EHRs occur for a valid clinical or operational reason, and often the reason is documented in the EHR database. Specifically, we observe three general types of explanations (direct, group, and consultation), and we show that these explanations can explain over 9% of the accesses in the log. Moreover, we identify collaborative groups that help to explain additional accesses. 1. INTRODUCTION Electronic health record systems (EHRs) are often used to store patient health information. As more data are stored in EHRs, the security of the data and privacy of the patients become paramount. In the United States, recent legislation such as the Health Insurance Portability and Accountability Act (HIPAA) and Health Information Technology for Economic and Clinical Health Act (HITECH) impose new requirements governing the responsible management of patient data. For example, HIPAA stipulates that patients can request an accounting of the disclosure of their protected health information by hospitals and other "covered entities. One way to provide an accounting of disclosures would be to develop a user-centric auditing system. Such a system would provide a portal where the patient could login and view a list of all accesses to his medical record. The portal would provide the patient with This work was supported by NSF grants CNS and IGERT Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. KDD-DMH 11, August 21, 211, San Diego, California, USA. Copyright 211 ACM /11/8...$1.. Dr. Dave had an appointment with Alice on Jan 3, 21. Lid Date User Patient L1 Mon Jan 3 1:16:57 21 Nurse Nick Alice L116 Mon Jan 3 11:22:43 21 Dr. Dave Alice L127 Mon Jan 3 17:9:3 21 Radiologist Ron Alice Figure 1: Sample access log and explanation information about who has accessed his record, when each access occurred, and possibly a coded description describing the type of action (e.g., viewed labs, or updated medications). Unfortunately, this information can be hard to analyze and may cause undue concern, particularly if the list of accesses is long. For example, while a patient is likely to know the name of his primary care doctor, he probably does not know the name of the intake nurse. To understand how their medical information is used, patients will also want to understand why their medical information was accessed. EXAMPLE 1.1. Consider a sample patient Alice, who had a broken arm. She was treated by Dr. Dave at the hospital, and several x-rays were taken. Later, when Alice logs into the auditing portal, she sees a list of all accesses to her medical record (Figure 1). This list can be very long, so ideally, when she clicks on an access, the system should provide a text explanation: L1 Nurse Nick works with Dr. Dave, and Dr. Dave has an appointment with Alice on Jan 3, 21. L116 Dr. Dave has an appointment with Alice on Jan 3, 21. L127 Ron is a radiologist, and he reviewed Alice s x-rays. One approach to producing explanations would require the user (doctor or other staff member) to explicitly enter a reason for each access. While some systems may require this (e.g., [1]), it is too burdensome to be a general solution. In an ideal world, we would be able to generate explanations automatically. From the above example, it is interesting to observe that the explanation for each access can actually be generated using information that is located elsewhere in the EHR database. For example, Alice s appointment with Dr. Dave is recorded in the appointments table. The EHR database also records the fact that Alice had an x-ray taken, and that Ron is a radiologist. In this paper, we study the extent to which EHR accesses can be explained using data located elsewhere in the EHR database. We describe a large-scale empirical study using a data set from the University of Michigan Health System s CareWeb EHR system. The data set includes a log of over 4 million accesses and

2 1 # Accesses Date List Pa(ent's Documents/ Imaging View Pa(ent's Document View Pa(ent's Labs View Pa(ent's Demographics View Pa(ent's Schedule List Image Documents View Pa(ent's Problem Summary List Record Results List Other Frac3on of Accesses Write Read Figure 2: Accesses Per Hour (12/21) Figure 3: Actions Figure 4: Read-Write Distribution de-identified information about the patients whose medical records were accessed, including appointments, labs, and medications. Based on our results, we conclude that a large majority of EHR accesses can be explained automatically. The remainder of this paper is organized as follows: We begin with a basic description of the data set in Section 2. In Section 3, we use the access log to provide an overall characterization of CareWeb usage patterns. In Section 4, we investigate the extent to which EHR accesses can be explained automatically. We identify three different types of explanations (direct, group, and consultation), and observe that over 9% of accesses can be explained using information already located in the EHR database. In order to support group explanations, it is important that we be able to automatically identify collaborative groups (i.e., groups of users who work together). Section 4.2 demonstrates that this can be done effectively by observing shared patients in the access log. The paper concludes with discussions of related and future work in Sections 5 and DATA DESCRIPTION We analyzed a large data set from CareWeb, the University of Michigan Health System s locally-developed, web-based EHR system. The data set includes a comprehensive access log. Each time a user (e.g., a doctor or other UMHS staff member) accesses a patient record, the system automatically records information about the access, including the time, UserID, PatientID, and a description of the action performed. An access corresponds to a user reading or writing data. We analyzed the log records collected during one week (December 13-19, 21). During this period, the log recorded over 4M accesses, referencing over 12K distinct users and 124K distinct patients. The number of distinct user-patient pairs is approximately user patient pairs 5K, which gives a user-patient density of = users patients.3. The data set also includes mappings from UserIDs to department codes (e.g., Pediatrics or Nursing-Pediatrics). For the users mentioned in the log, we observed 291 distinct department codes. Finally, we obtained de-identified information about the patients whose records were accessed. This information is stored in eight database tables: Appointment, Document, Inpatient Medication, Lab, Outpatient Medication,, Service/Order, and Visit. For example, the Appointment table lists the date of each appointment, the PatientID, and the UserID of the doctor. The Inpatient Medication table lists the date, the UserID of the person who entered the medication, the UserID of the person who requested the Table # Records Log 4.5M Appointment 51K Document 76K Inpatient Medication 122K Lab 45K Outpatient Medication 12K 17K Service/Order 16K Visit 3K Table 1: Data Overview medication, and the UserID of the person who administered the medication. We extracted data for these tables from the weeks before, during and after the week in which the log was created. Table 1 lists the number of records in each table. It is important to point out that our data set is, in some sense, incomplete. We only received a subset of the log (one week) and a subset of information about the patients referenced in the log. As a result, we do not have access to information such as appointments that were scheduled more than one week before or after the period covered by the log. Nonetheless, the data set provides valuable insight, and a more extensive study covering a larger period of time is an interesting topic for future work. 3. BASIC USAGE In this section, we use the access log to provide a basic characterization of CareWeb usage patterns. 3.1 Log Characteristics First, we examined the general properties of the access log. Figure 2 shows the number of accesses per hour over the week (December 13-19, 21). Clearly, the accesses follow a diurnal pattern, where the number of accesses is low in the early morning, increases through the day, drops during lunch, increases in the afternoon, and then declines again in the evening. Additionally, fewer accesses occur on the weekend (December 18-19) than during the week. Intuitively, the number of accesses appears to be proportional to the number of people working in the hospital system at a given point of time. While the raw number of accesses can be useful, we are also interested in the types of actions that are executed. Along with each access, CareWeb records a description of the action that was performed. There are 124 distinct action types. Figure 3 shows the eight most frequent actions, which account for over 65% of all accesses. Unsurprisingly, the most common action is to view a list of a patient s documents, and the second most common action is to view a patient s document (e.g., doctor s note).

3 # Users # Users # Patients # Patients # Accesses # Patients Accessed # Accesses # Users Who Accessed a Patient's Record Figure 5: Accesses Per User Figure 6: Patients Per User Figure 7: Accesses Per Patient Figure 8: Users Per Patient Accesses/User Patients/User Accesses/Patient Users/Patient UMHS Int Med - General Medicine (Physicians) UMHS Int Med - General Medicine (Physicians) Cancer Center UMHS Internal Medicine (Physicians) Central Staffing Resources UMHS Int Med - General Medicine (Physicians) Central Staffing Resources Cancer Center Int Med - Outpatient Svcs - Taubman UMHS Internal Medicine (Physicians) Pathology Health Information Management Physician Services Medical Students Operating Rooms/PACU UMHS Pediatrics - General Medicine (Physicians) Health Information Management Cancer Center Medical Students Cancer Center Central Staffing Resources Physician Services UMHS Family Medicine (Physicians) Health Information Management Medical Students Figure 9: Top departments by access behavior. For example, Internal Medicine physicians access the most medical records and the most unique patients. Finally, we examined the number of actions that read data vs. write data. Figure 4 shows that most accesses only read EHR data, while a smaller fraction modify the data. 3.2 User and Patient Characteristics Due to the different types of jobs within the hospital system, EHR users access patient records in different ways. For instance, some users repeatedly access the same patient s record, while others access many different patients records. Similarly, patients have their medical records accessed in different ways. For some patients, only their primary care physician accesses their medical record; other patients have large teams of doctors. To better understand the types of users and patients in our data set, we analyzed the log of accesses based on four quantitative measures: 1. Total number of accesses per user (accesses/user) 2. Number of distinct patients accessed per user (patients/user) 3. Total number of accesses to a patient s medical record (accesses/patient) 4. Number of distinct users that access a patient s medical record (users/patient) Figures 5, 6, 7 and 8 show the distribution of each measure using a log-log scale. We find that all four measures have heavily-skewed ("long-tail") distributions. While the average user performed 358 accesses (39 distinct patients) during the week, most users accessed very few records. Similarly, the average patient s record was accessed 36 times (4 distinct users), but most patients records were accessed very few times. For both patients and users, there is a small subset of "heavy" users and patients. To further understand who these people are, we examined the users and patients in the tails of the distribution. For example, for accesses per user, we identified the top 1% of users (i.e., those with the most accesses). Among these users, the most frequent department codes are shown in Figure 9. Notice that internal medicine physicians perform the most accesses, and they access the most unique patients. In general, physicians tend to be among the heaviest users. We also looked at the top 1% of patients (i.e., those with the most accesses to their records). Because we were working with de-identified data, we were not able to examine the patients characteristics directly. Instead, we looked at the department codes of the users who accessed the patients records, which gives us a good idea of where the patients were being treated. Figure 9 shows the common department codes of the users who treated this group of patients. Interestingly, and perhaps unsurprisingly, many of the patients were treated by users from the Cancer Center. When we look at the patients whose records were accessed by the most distinct users, we find that the users are from radiology, pathology and the operating room. These departments make sense for heavily accessed patients, since patients with x-rays, labs or who are in the operating room are typically treated by teams of hospital employees. 4. EXPLAINING ACCESSES The main hypothesis of this paper is that most accesses to EHR records occur for a valid clinical or operational reason, and often this reason is actually documented elsewhere in the EHR database. Returning to example 1.1, Dr. Dave accessed Alice s record because Alice had an appointment with Dr. Dave, and indeed, this appointment is recorded elsewhere in the EHR database. In this section, we identify three types of explanations, and demonstrate empirically that they can be used to explain a significant number of accesses in the log. Direct Explanations: The access can be explained based on an event (e.g., an appointment or a doctor s note) that involves both the patient and the user. For example, Dr. Dave accessed Alice s medical record because Dr. Dave has an appointment with Alice.

4 1.8 Recall Appointment Document Inpa6ent Meds Inpa6ent Meds (Requested By) Inpa6ent Meds (Administered By) Labs (Ordered By) (Updated By) (Authorized By) (Began By) (Ordered By) Service/Order Service/Order (Requested By) Visit Repeat Access Explana6ons Events Figure 1: Frequency of events and direct explanations in the database for all accesses. 1.8 Recall Appointment Document Inpa6ent Meds Inpa6ent Meds (Requested By) Inpa6ent Meds (Administered By) Labs (Ordered By) (Updated By) (Authorized By) (Began By) (Ordered By) Service/Order Service/Order (Requested By) Visit Explana6ons Events Figure 11: Frequency of events and direct explanations in the database for first accesses. Group Explanations: The access can be explained based on an event that involves the patient and a member of the user s group (e.g., someone with the same department code, or who works with the user), but not the user himself. For example, Nurse Nick accessed Alice s medical record because Nurse Nick works with Dr. Dave and Dr. Dave has an appointment with Alice. Consultation Explanations: The access can be explained because the user works in a department that provides consultation services related to an event involving the patient. For example, Radiologist Ron accessed Alice s medical record because Alice had an x-ray taken. 4.1 Direct Explanations A direct explanation explains why a user accessed a patient s medical record based on an event stored in the database. Common events include appointments, visits to the hospital, doctor s notes and accesses in the log. A full list of the events we consider is provided in Table 1. Figure 1 shows the event recall for each of the events. We define the recall of an event to be the proportion of accesses in the log that mention a patient who was involved in an event of that type Accesses F or P atients W ith T he Event (Event Recall = ). For Log example, if every patient mentioned in the log had an appointment, then the event recall for appointments would be 1.. The events with the highest recall were services/orders that were requested for patients (71% of all accesses), patient documents such as a doctor s note (7%), and outpatient medication prescriptions (67%). Additionally, approximately 88% of the accesses correspond to the event of a repeat access; a repeat access means that the user previously accessed the same patient s record. Of course, in order for an event to explain a particular access, the event should involve the same patient and user. Intuitively, an explanation connects the user who accessed the medical record to the patient whose record was accessed. For example, Dr. Dave accessed Alice s medical record because Alice had an appointment with Dr. Dave. However, Alice s appointment does not imply that any hospital employee should access her medical record. Figure 1 shows the explanation recall for a set of hand-crafted direct explanations, such as having an appointment with a patient. The recall of an explanation is the proportion of accesses that are Accesses Explained Log explained (Explanation Recall = ). If every access could be explained by an appointment, then the explanation recall for appointments would be 1.. Of course, we observe that the explanation recall is lower than the event recall. While many patients have appointments, it is relatively less likely to have an appointment with the particular user who accessed the patient s record. Nonetheless, each type of event can be used to directly explain some accesses. While repeat accesses make up a majority of the log, it is more interesting to explain why a user accesses a patient s record for the first time. Therefore, we additionally analyzed the set of first accesses in the log. It is important to note that since we only have a subset of the log, repeat accesses may appear as first accesses. Figure 11 shows the recall for the first accesses from the log. We observe that the general proportion of events and explanations is similar to those for all accesses, except that the recall for the events and explanations are slightly lower. A user-centric auditing system would utilize all of the direct explanations when attempting to explain why an access occurred. Figure 12 shows the recall when the direct explanations are combined. When we only consider first accesses, we are able to explain approximately 22% of the accesses. In contrast, 86% of the first accesses correspond to a patient who experienced an event. We hypothesize that the recall is lower for explanations than events because only a subset of the events mention the user who accessed the

5 1 1 Recall All (First Accesses) All (All Accessses - Other Than Repeat Access) All (All Accesses) Recall (First Accesses) Accesses/User Pa2ents/User Accesses/Pa2ent Users/Pa2ent Explana>ons Events Top 1% Bo@om 1% Figure 12: Recall Summary - Direct Explanations patient s record (e.g., Alice s appointment mentions Dr. Dave, not Nurse Nick). We will address this issue in Section 4.2. When we consider all the accesses in the log and all the direct explanations other than the repeat access explanation, we are able to explain approximately 43% of the accesses for which there are events for 92% of the accesses. Lastly, when we consider all the accesses in the log and all direct explanations, we can explain approximately 91% of the accesses for which there are events for 98% of the accesses. This result supports our hypothesis that EHRs store a reason for why most accesses occur. Interestingly, 2% of accesses in the log correspond to patients that did not experience at least one event from the tables listed in Table 1. There are multiple possible reasons for this gap in information. First, since our data set was extracted from a specific timeframe, relevant events that occurred outside our timeframe were missed. Second, the university s health system has many researchers that access patient information; these accesses typically do not have an event for the patient. Lastly, it is possible that there are additional data sources in the hospital that we were unaware of that could have been used to help explain accesses, but were not included in our data set User and Patient Characteristics Additionally, we examined whether specific types of users accesses could be explained more effectively. Using the top and bottom 1% of users based on the four measures from Section 3.2, we calculated the recall for the groups. Figure 13 shows the explanation recall for first accesses given the eight groups. Interestingly, the top-1% of users that access the most medical records have a higher explanation recall (33%) when compared to all users in our data set (22%). Moreover, the bottom-1% of users that access the fewest medical records have a lower explanation recall (15%). The bottom-1% of patients who are accessed by the least number of users have an even worse explanation recall of 3%. We hypothesize that EHRs store more information for heavy users, which allows us to explain a higher proportion of their accesses Temporal Patterns Lastly, we analyzed when accesses could and could not be explained. Figure 14 shows the fraction of accesses that cannot be explained per hour for both all accesses and first accesses (F raction Unexplained = 1 Explanation Recall). We observe that the fraction of unexplained accesses varies with the number of accesses in the system. Additionally, at night, the fraction of accesses that cannot be explained is lowest. We hypothesize that this occurs because hospitals are minimally staffed at night and do not have many ancillary staff. It is also important to note that the fraction of all accesses that cannot be explained trends downwards during the week as fewer accesses are incorrectly represented as first accesses. Figure 13: Explanation Recall By User Behavior Type Fraction Unexplained All Accesses First Accesses Date Figure 14: Unexplained Accesses Over Time 4.2 Group Explanations So far, we have only considered accesses that can be explained directly by an event that involves the same user and patient. However, this fails to explain many real accesses. For example, consider Nurse Nick from Example 1.1 who works with Dr. Dave. Alice has an appointment only with Dr. Dave, not with Nurse Nick. More generally, as we showed in Figures 1 and 11, while most patients are involved in events, relatively few of these events constitute direct explanations. Because of cases like this, we also consider what we will call group explanations. In addition to event information, a group explanation also incorporates user groups. For example, in the simplest case, we can create groups of users by department code (i.e., place all users with the same department code into a single group). An explanation can then be constructed for any access where there is an event involving the patient and some member of the user s group. For example, we might find that Dr. Mike accessed Alice s record because Dr. Mike works in Pediatrics, and Alice had an appointment with Dr. Dave, who also works in Pediatrics. Unfortunately, groups based on department code are often insufficient for explaining accesses. In particular, in our data set, we found that often users who work together have different department codes (e.g., Pediatrics and Nursing-Pediatrics). Instead, we want to infer true collaborative groups based on the real working relationships between users. One approach to inferring collaborative groups involves looking at the access log. Intuitively, if two users work together, they will often access the same patients records. Thus, we inferred collaborative groups using the following approach: First, we constructed a weighted network graph where the nodes are users, and there exists an edge between two nodes if the users accessed the same patient s medical record. The weight of an edge depends on how often the two users access the same patients medical records. We assign

6 # Users Degree Cancer Center Pathology UMHS Int Med - Hem/Onc (Physicians) UMHS (Physicians) Radia>on Oncology Clinical Trials Office Central Staffing Resources Pharmacy Other UMHS Psychiatry (Physicians) Psychiatry - Hospital Psychiatry - Social Work Social Work Physician Services Nursing - CAP6 (Child & Adolescent Psych) Medical Students Nursing - Psych 9C/D (Adult Psych) Psychiatry - Business Office Other Figure 15: Degree distribution in the collaborative network representation Figure 16: Collaborative Group I (Cancer Center) Figure 17: Collaborative Group II (Psychiatric Care) weights to edges using an approach similar to the one described in previous work by Chen et al. [5]. Figure 15 shows the node degree distribution from the resulting network. As is often the case in social and collaborative networks, the distribution is heavily skewed. Second, we directly applied a weighted graph clustering algorithm [14], which discovers a set of groups and an assignment of users to groups. We recursively applied this clustering algorithm on each group to create a hierarchical clustering. Intuitively, groups at the bottom level of the hierarchy are more tightly connected than groups at the top level of the hierarchy. Using the above approach, we created groups using the first six days of accesses in the log. We manually inspected the 33 top-level groups in the hierarchy, and we were able to identify groups that represented the Cancer Center and psychiatric care, among others. Figures 16 and 17 show the department codes of users assigned to these two groups. Introducing collaborative groups can potentially create false positive explanations. To measure the trade-off, we performed a precision and recall experiment. For the experiment, we constructed a fake log with an equivalent number of accesses as the real log. Entries in the fake log were created by selecting pairs of users and patients uniformly at random. We define precision to be the number of real accesses explained over all accesses explained (P recision Real Accesses Explained Real+F ake Accesses Explained. = Figure 18 shows the precision and explanation recall for the first accesses from day seven of the log. We used only appointment, document and visit events for this experiment. Depth zero corresponds to every user being placed in a single group. Additionally, the figure includes the precision and recall when the samedepartment explanation is used. The figure shows that more general groupings (lower numbers in the hierarchy) provide the best explanation recall, but lower precision. For instance, using the groups at depth one, the group explanations explain 33% of the first accesses compared to 13% when only the direct explanations are used with the appointment, document and visit events. As we use groups at lower depths of the hierarchy (higher numbers), the precision approaches 1.. We attribute the high precision to the low user-patient density; for these tightly connected groups, it is unlikely that a fake access corresponds to an actual appointment in the database. We also observe that the collaborative groups perform better than the same-department groups since most teams in the hospital are multi-disciplinary. 4.3 Consultation Explanations Initially, we only requested data for patient appointments, visits and documents. However, after a preliminary analysis, we discovered that a number of accesses that could not be explained were made by users from departments that provide services to the hos Same Dept. Precision Depth In Group Hierarchy Recall (First Accesses) Figure 18: Group Explanation Precision and Recall (Using Appointments, Documents, Visits and Log Day 7) pital (e.g., radiology, pathology and pharmacy). Users in these departments typically do not have appointments with patients. Instead, there is often an explicit request for a service that is stored in the database. Following the request, these users perform the consultation service. EXAMPLE 4.1. Continuing with Example 1.1, Alice has an x- ray taken of her arm. A request is then sent to the radiology department to review the x-ray and diagnose the injury. The request does not specifically state which radiologist will review the x-ray. Radiologist Ron sees the request, accesses Alice s medical record and provides a diagnosis. Consultation explanations explain accesses based on the fact that specific departments provide consultation services when specific events occur. For example, Radiologist Ron accessed Alice s medical record because Alice had an x-ray and Ron is a radiologist. We looked at three specific types of consultation explanations: radiology events, medication events and lab events. Specifically, we examined how many accesses corresponded to (i) patients who had a radiology event and were accessed by radiologists, (ii) patients who had an inpatient or outpatient medication event and were accessed by a pharmacist and (iii) patients who had a laboratory event and were accessed by a pathologist. Figure 19 shows the explanation recall for first accesses of each of the consultation explanations as well as the recall when all the consultation explanations are combined (All). When combined, the consultation explanations account for approximately 5% of the first accesses.

7 Recall (First Accesses) Inpa-ent Meds Labs Outpa-ent Meds Figure 19: Consultation Explanation Recall 5. RELATED WORK As more information is stored digitally, it becomes more important to provide an accurate accounting for how sensitive data is used. There have been multiple instances where data has been accessed inappropriately. For example, in 28, Britney Spears medical record was inappropriately accessed by multiple hospital employees; these employees were subsequently fired for their behavior [15]. Inappropriate accesses also occur in non-medical database systems. For example, Barack Obama s passport information was inappropriately accessed at the U.S. State Department [8]. Recent work has proposed methods to detect inappropriate access behavior in electronic health record systems. For example, Chen et al. analyze a hospital system s access log to detect anomalous insiders [5]. Anomalous users are detected by measuring the difference in accesses pattern from one user to other EHR users that access similar medical records. In this work, the authors consider a user to be the unit of suspiciousness. In contrast, we consider single accesses as the unit of suspiciousness and attempt to explain why each access occurred. We believe this is appropriate when users are typically well behaved but irregularly access inappropriate information. Other work has considered how to set access control policies for EHRs to restrict access to sensitive data. Malin et al. propose a data-driven system that mines common usage patterns [1]. For example, one possible mined usage pattern is that a surgeon will likely access a patient s medical record after it is accessed in the emergency room. Deploying access controls in EHRs can be challenging. It would be dangerous to delay a patient s treatment while a doctor waits to be given permission to access a patient s medical record, so it is common to instead apply "access control policies" after the fact to detect that misuse has already occurred. As EHRs become more prevalent, users are increasingly using search systems to find and retrieve patient information. Researchers have begun to study the queries issued to EHRs. For example, Natarajan et al. provide an analysis of clinical queries in an electronic health record search utility [13]. The authors classify queries into categories such as navigational, transactional, and searches. Moreover, searching for complex medical information can be challenging due to a user s lack of experience or lack of knowledge in a specific domain. To make EHR search easier, Zheng et al. propose a collaborative search system [17]. In the system, users can share search bundles that preserve their search knowledge. In this work, we considered application-level logging, which is commonly found in EHRs. Typically, these logs store the time, the UserID and PatientID for each access. A recent body of work has focused on the related problem of SQL log auditing. These logs store the SQL text of the operations executed on the database; All this type of logging is provided by most commercial DBMSs [9, 12, 16]. For these types of logs, it is nontrivial to determine who has accessed sensitive data. Recent models and systems have been proposed to address this problem for SQL logs [2, 7, 11]. Lastly, in some sense, explaining why accesses occur in an electronic health record system is similar to the problems faced in data provenance [3, 4, 6]. While there are some connections between the two problem spaces, we are not aware of other systems that can be applied directly to explain why accesses occur in EHRs. 6. CONCLUSION AND FUTURE WORK In this paper, we showed that most accesses in electronic health record systems occur for a clinical or operational reason, and this reason is usually documented in the EHR database. Common reasons to access medical records include preparing for a patient s appointments and diagnosing an x-ray. Using this information, we demonstrated that over 9% of the accesses recorded during a week at the University of Michigan Health System can be explained. In particular, we observed three types of explanations from the data set: direct, group and consultation explanations. To support group explanations, we identified collaborative groups that can be combined with EHR data to explain additional accesses. There are many interesting related problems for future work: Automated Misuse Detection: One important application of explanations lies in user-centric auditing systems. However, these explanations can also likely be used for alternative purposes such as automated misuse detection. Current approaches for detecting misuse typically involve a manual audit of the access log. If we are able to automatically explain why an access occurs, then the auditor would only have to analyze the accesses that cannot be explained, reducing the audit time. Temporal Groups: Hospitals are composed of dynamic teams that change over time. For instance, medical students and residents change services weekly or monthly. We plan to explore how these groups change over time and the frequency of the changes. Understanding Hospital Workflows: Intuitively, patients with the same medical conditions will be treated in the same manner. We plan to examine if hospital workflows can be mined from the access log and EHR database information. Grouping Explained and Unexplained Accesses: Multiple users may access a patient s medical record for the same reason. Alternatively, a single user may access a patient s record for many different reasons. We will consider how to group these accesses and explanations. We will also consider grouping unexplained accesses. 7. REFERENCES [1] Cerner power chart [2] R. Agrawal, R. J. Bayardo, C. Faloutsos, J. Kiernan, R. Rantzau, and R. Srikant. Auditing compliance with a Hippocratic database. In VLDB, 24. [3] P. Buneman, S. Khanna, and W. chiew Tan. Why and where: A characterization of data provenance. In ICDT, 21. [4] A. Chapman and H. V. Jagadish. Why not? In SIGMOD, 29. [5] Y. Chen and B. Malin. Detection of anomalous insiders in collaborative environments via relational analysis of access logs. CODASPY, 211.

8 [6] J. Cheney, L. Chiticariu, and W. C. Tan. Provenance in databases: Why, how, and where. Foundations and Trends in Databases, 29. [7] D. Fabbri, K. LeFevre, and Q. Zhu. Policyreplay: Misconfiguration-response queries for data breach reporting. In VLDB, 21. [8] G. Kessler. Two fired for viewing Obama passport file. Washington Post, March [9] D. Kiely. SQL Server 28 Security Overview for Database Administrators. SQL Server Technical Article, October 27. [1] B. Malin, S. Nyemba, and J. Paulett. Learning relational policies from electronic health record access logs. J. of Biomedical Informatics, 211. [11] R. Motwani, S. Nabar, and D. Thomas. Auditing SQL queries. In ICDE, 28. [12] A. Nanda. Fine-grained auditing for real-world problems. Oracle Magazine. [13] K. Natarajan, D. Stein, S. Jain, and N. Elhadad. An analysis of clinical queries in an electronic health record search utility. International Journal of Medical Informatics, 21. [14] M. Newman. Analysis of weighted networks. Phys. Rev. E, 24. [15] C. Ornstein. Hospital to punish snooping on Spears. L.A. Times, 28. [16] T. J. Wasserman. DB2 UDB Security Part 5: Understanding the DB2 Audit Facility, March 26. [17] K. Zheng, Q. Mei, and D. A. Hanauer. Collaborative search in electronic health records. J Am Med Inform Assoc, 211.