Content uploaded by Dean Forrest Sittig
Author content
All content in this area was uploaded by Dean Forrest Sittig on Mar 07, 2017
Content may be subject to copyright.
D F. S is the Christopher Sarom Family Professor of Biomedical Informat-
ics and Bioengineering in the School of Biomedical Informatics at the University of
Texas Health Science Center in Houston, TX. He received his PhD in Medical Infor-
matics from the University of Utah. His research interests center on design, devel-
opment, implementation, and evaluation of all aspects of clinical information and
communication systems. He is working to improve understanding of both the fac-
tors that lead to success, as well as, the unintended consequences associated with
various forms of health information technology. Most recently he has focused his
eorts on developing guidelines for the safe and eective implementation and use of
electronic health records (EHRs) that are based on an 8-dimension socio-technical
model that he developed with Hardeep Singh. is work lead to the development of
the SAFER guides that were designed to help healthcare organizations conduct pro-
active risk assessments of their EHRs.
e author wishes to thank Elisabeth Belmont, Esq., Corporate Counsel,
MaineHealth, for her contributions to this paper.
Audit Logs ■ Sittig ■ 3
Audit Logs
I. What Should Be in the Audit Log? ................................................................................................................5
II. Key Denitions ...............................................................................................................................................5
III. HIPAA Security Rule .....................................................................................................................................6
IV. Meaningful Use Audit Requirements ...........................................................................................................6
V. Audit Log Overview .......................................................................................................................................6
VI. How to Use e Audit Log to Defend a Medical Malpractice Claim ..........................................................8
VII. An Example: Epic EHR Audit Log ................................................................................................................8
VIII. Understanding an Audit Trail .......................................................................................................................8
IX. A Defense Attorney Should Know the Answer to All of ese Questions .................................................9
X. Sample Questions at Could Be Used in a Deposition of an Opposing Expert .....................................10
Endnotes .....................................................................................................................................................................11
Table of Contents
Audit Logs ■ Sittig ■ 5
Audit Logs
e purpose of this paper is to provide an introduction to audit logs and their use in litigation.
Audit logs are a form of metadata, commonly described as “data about data,” and are automatically
generated computer logs for certain electronic documents including electronic heath records (EHRs) that
chronologically identies: (i) the date and time of a use or change of a record; (ii) identies the particular
user; (iii) identies the type of action such as entering, revising, deleting or printing data; and (iv) the particu-
lar data being accessed.
By way of analogy, one can think of metadata as being the data that is on the outside of an envelope.
e actual data is the information that is enclosed in the envelope. erefore, from the outside, one can see
who sent the envelope (return address), who the envelope is for and where that person is living (address),
when and from where it was sent (post mark), but one cannot see the contents of the envelope. To extend the
analogy, if everyone that added something to or removed something from the envelope was required to add
their identifying information, along with the date and time that they performed this activity to the outside of
the envelope, as an ‘access log,’ one could determine who added contents to the envelope, who removed con-
tents, who changed its contents, or even who printed or copied the contents, but still one would not know
what those contents were. So, while the metadata provides important data, it only provides a part of the infor-
mation.
I. What Should Be in the Audit Log?
• e name of the user interacting with the EHR (note: the default is the ID of the user who logged
into the EHR, but it is possible that another user “poached” or began interacting with the EHR
aer the rst user le the computer and did not log o or “lock” the EHR application or the user
shared his log on credentials with another clinician;
• e application the user was using to interact with the EHR;
• e physical location of the workstation (note: the audit log will most likely contain a logical
name of the device which can be associated to a physical location using another reference le)
where the interaction took place;
• e date and time of the interaction (note: oen the time that the user enters describing when
the event occurred is earlier (a later time means that the data was entered before the event took
place) than the time that the data was input into the EHR, which is the time recorded in the
audit log) (note: e date and time recorded should utilize an internal system clock that has
been synchronized following (RFC 1305) Network Time Protocol); and
• A description of the type of interaction (e.g., view, modify, delete, print, etc.).
II. Key Definitions
• Audit logs are records of sequential activities maintained by the application or system.
• An audit trail consists of the log records identifying or related to a particular transaction or
event.
• A system security or access audit is the process of reviewing the audit log and is an integral part
of an organization’s security and risk management process.
6 ■ Medical Liability and Health Care Law ■ March 2017
III. HIPAA Security Rule
e HIPAA Security Rule includes two provisions that require covered entities to perform security
audits. e audit log is designed to meet the following provisions of the HIPAA Security Rule:
• Section 164.308(a)(1)(ii)(c), Information system activity review (required), which states organi-
zations must “implement procedures to regularly review records of information system activity,
such as audit logs, access reports, and security incident tracking reports.”
• Section 164.312(1)(b), Audit controls (required), which states organizations must “implement
hardware, soware, and procedural mechanisms that record and examine activity in informa-
tion systems that contain or use electronic protected health information.”
IV. Meaningful Use Audit Requirements
EHR vendors must demonstrate that their products meet the “technical safeguards” in the HIPAA
Security Rule, including audit requirements, in order to become certied through the Oce of the National
Coordinator (ONC) and participate in the multi-stage “meaningful use” EHR Incentive Program. Stage 1 of
certication criteria for meaningful use, 45 C.F.R. Section 170.302(r), Audit log, requires entities to:
• Record actions related to electronic health information in accordance with the standard speci-
ed in §170.210(b); and
• Generate an audit log. Enable a user to generate an audit log for a specic time period and to sort
entries in the audit log according to any of the elements specied in the standard at §170.210(b).
Stage 2 of the meaningful use certication criteria includes the following section:
§170.314(d)(3) Audit report(s). is section requires a user to create an audit report for a spe-
cic time period and to sort entries in the audit log according to each of the data specied in the standards
at §170.210(e). e federal government requires vendors to implement appropriate controls and reporting
mechanisms. Covered entities are expected to use these controls and reporting mechanisms to monitor the
behaviors of their workforce and to prevent unauthorized access and disclosure of protected health informa-
tion (PHI).
V. Audit Log Overview
Counsel for the Plainti and Defendant may dier in their views as to whether an audit log is part of
the legal electronic health record (EHR). e HIPAA Privacy Rule arguably provides support for the defense
position that an audit log is not part of the legal EHR with its denition of a designated record set as
“(1) A group of records maintained by or for a covered entity that is:
(i) e medical records and billing records about individuals maintained by or for a covered
health care provider;
(ii) e enrollment, payment, claims adjudication, and case or medical management record sys-
tems maintained by or for a health plan; or
(iii) Used, in whole or in part, by or for the covered entity to make decisions about individuals.
(2) For purposes of this paragraph, the term record means any item, collection, or grouping of infor-
mation that includes protected health information and is maintained, collected, used, or disseminated by or
for a covered entity.” 1
Audit Logs ■ Sittig ■ 7
Audit trails and metadata are not included in the denition of designated record set because it is not
used by the covered entity to make treatment decisions or eligibility determinations about individuals. More-
over, the American Health Information Management Association (AHIMA) has recognized that audit trails
and metadata are not included as part of the legal health record or designated record set by opining, “Equally
as important, organizations need to identify information that is not in the legal health record or designated
record set. Data such as audit trails, metadata, and psychotherapy notes are not included in the denitions for
these record sets. . . .”2
Certain state hospital licensing regulations may dene an EHR to include an audit log.3 It thus is
important for defense counsel to review applicable state laws and regulations.
e audit log is a record of who accessed which aspect of a patient’s record at a particular point in
time from a particular computer and what operations the user performed. An audit log has many limitations,
however. For example, it does not include WHY a particular action was taken, users may share (inadvertently,
or on purpose) login credentials, it has low granularity (i.e., only describes which screen the user opened, not
which individual data elements were viewed or changed). Additionally, certain EHRs such as Epic log each
user’s keystroke and thus it is not possible to tell exactly what parts of the EHR were actually reviewed by a
particular user. An audit log thus cannot be used to determine whether a clinician viewed a particular por-
tion of the EHR. Certain EHRs such as Epic involve
‘machine to
machine’
communications
that prompt the
EHR
system to record actions that sta take
and
assign terms to such actions for which there may be
no human
interaction
involved. Accordingly, entries
that
appear
to reect human interaction may not,
in
fact,
reect human
interaction. Finally, dierent EHR vendors utilize dierent formats for audit
trails.
It is not unusual for there to be more than one audit log responsive to a discovery request
involving EHRs.
Most EHR systems include a variety of separate clinical components such as scheduling
and practice management, laboratory, radiology, and pharmacy, all of which may have their own audit logs.
Additionally, medical devices that collect patient data can be integrated into a clinical information system
and oen have their own temporary audit logs. For example, an EKG machine may keep a copy of who used
the device, which patient’s data was recorded, when, and where. Most likely this device’s audit log will only be
kept for a nite period due to the costs and the limited utility of storing vast amounts of data on each device.
Healthcare organizations may still be using certain legacy clinical information systems which contain audit
logs as well. A
particular patient’s hospitalization or outpatient encounters may encompass a time
frame that includes a transition from one EHR system to another. Some or all of these clinical systems
may feed into a secondary audit log system for privacy and security compliance purposes (e.g., Fair
Warning).
ese 3rd party companies specialize in maintaining the EHR’s audit log, providing tools to review
it, and oen generate reports of suspicious activity (i.e., inappropriate access to patient information by admin-
istrative or clinical sta). It is permissible, and potentially advisable, for an organization to have a policy for
retention of this data that states how long it will be routinely kept (e.g., 1 year). Although in the case that a
lawsuit is led, the healthcare organization may be required to keep all data pertaining to that case until the
case is settled.
ere are other logs within an EHR that are used by the application to ensure its internal consistency
and integrity. Specically, there are journal les that are used to ensure that in the event some part of the com-
puting infrastructure breaks that the actions of the user can be recreated by the system. For example, if a user
was entering an order for a medication and the network connection stopped working, the journal le could be
used to bring the user back to the previous point in their work.
8 ■ Medical Liability and Health Care Law ■ March 2017
VI. How to Use The Audit Log to Defend a Medical Malpractice Claim
Remember, the audit log only provides a part of the answer. One should always start with interview-
ing the key clinicians involved in the claim to understand the evaluation, diagnosis and treatment rendered
to the patient and whether there were any deviations from the standard of care. One should then review the
EHR in an attempt to corroborate their statements. Once one has identied the key medical issues, then one
should review the EHR metadata surrounding those issues. Finally, if there is any doubt about who did what,
when, and where, one could review the audit log at these key points in time to determine whether there is any
available data which may support the clinicians’ statements and EHR entries. Finally, remember that the audit
log for a multi-day hospital stay will be hundreds of pages long and dicult to understand, thereby adding to
the costs of the defense. Again, an audit log of certain EHR systems cannot be used to denitively determine
whether a clinician viewed a particular portion of the EHR at a particular time.
VII. An Example: Epic EHR Audit Log
e Epic application is comprised of a series of interconnected application modules supporting a
continuum of care within hospital-based and ambulatory settings. Patient access log events are captured
within an application function or reporting module. When a user opens a patient record, enters a specic
functionality within Epic, and then drills into a specic result or document, their activity could have three or
more separate log entries across several application modules to show the search, select, and subsequent drill
down into one element of the medical record. e above characteristics of Epic logging result in:
• e log content of the information accessed is dependent upon the underlying application func-
tion and/or reporting module context, coupled with the patient location and encounter type;
• e logs tend to be more verbose for each user and patient event because each ‘click’ could gen-
erate a new audit trail record and there is more information provided in Epic through the provi-
sion of results information within the system; and
• A user could appear to have accessed a record if a patient ends up on their search result list. Only
aer that user clicks on the record directly to open it would a second log record be created, how-
ever.
For patient access audit trail log extraction, Epic recommends using the Audit Trail Viewer function-
ality. Where an audit log request is extensive, log le extractions are performed within discrete windows of
time and pooled together for the full le.
VIII. Understanding an Audit Trail
Figure 1 shows a sample audit trail. e rst task in understanding an audit trail is obtaining an
accurate description of the meaning of the contents in each column. Oen this is referred to as the “data dic-
tionary”. For illustration purposes, the names and other identifying information were changed. In addition,
the patient’s ID column was deleted. In this case, the remainder of the columns are
• “EventDtm” refers to the date and time that the event was recorded in the format of Year-Month-
Day Hour:Min:Second:Millisecond.
• “Identier” refers to a particular part of the EHR.
• “Action” tells us what type of action the user performed.
• “EventType” describes what the user did.
Audit Logs ■ Sittig ■ 9
• “RoleCode” tells us the role, which gives us information about the data access privileges, of the
user.
• “UserName” tells us the name of the user that performed the action.
• “NetworkAccessPointValue” tells us the logical address of the device from which the user per-
formed the action. e organization that uses this EHR should have a le that describes the
physical location (3 West) of each of these logical addresses.
From this brief snippet of the audit trail, which is an extract of the audit log showing all accesses to a
particular patient’s EHR, one can see that several dierent clinicians interacted with the patient’s record over a 3
day period. We can see that a nurse, Jane Doe viewed the patient’s EHR, but we cannot see what portions of the
medical record that she viewed. Later we see that she queried the results. Again, we do not know what specic
results she viewed. If we look down further we see that a pharmacist, John Miller, updated the patient’s prescrip-
tion history. Once again, we do not know what particular information was changed by this individual. To nd out
what information was changed, we would need to look in the actual medical record around this date and time to
see what was updated. is may be dicult, because the EHR may show the time that the user entered when he
made the change which may be dierent than the actual time the change was entered in the EHR. erefore, we
may need to see the metadata associated with each data entry to nd this exact change.
Many EHR vendors consider the data dictionary that explains the audit log denitions to be propri-
etary information, and the contract between the provider and the EHR vendor may prohibit the sharing of the
data dictionary with third parties.
Figure 1. Example of an audit trail. For illustration purposes several columns, including the patient’s
name, were deleted and other information was changed.
IX. A Defense Attorney Should Know the Answer to All of These
Questions
• Who can access the audit logs and for what purposes?
A: e organization carefully limits the number of people who have access to the audit logs and
species the purposes for which such access may occur. For example, medical records supervisors and their
designees should have access to the EHR audit logs for the purposes of ensuring the condentiality, integrity
and availability of EHR data. Additionally, an organization’s privacy ocer will have access to the audit logs.
Restricting access to audit logs is important to prevent tampering or altering of audit data.
• Where are the audit logs stored, both digitally and physically?
A: e audit logs are stored on a physically (i.e., in a locked, limited access part of the facility) and
logically (i.e., requires special privileges to login to the server and access the audit log les) separate (i.e., dif-
ferent from the servers responsible for running the EHR application that created the audit log), secure server.
EventDtm Identifi er Action EventType RoleCode Use rName NetworkAccessPointValue
2015-06- 12 10:47:18.817 Patient Re cord Read Patient Viewed Registered Nurse Doe, Jane CTX ZN3129C.d gy z.org
2015-06- 12 10:47:20.183 Use r Acti on Exe cute Tab Accesse d Registered Nurse Doe, Jane CTX ZN3129C.d gy z.org
2015-06- 12 10:47:20.190 Query Re ad Results Queried Registered Nurse Doe, Jane CTX ZN3129C.d gy z.org
2015-06- 14 09:57:52.070 Patient Re cord Read Allergy Summary Viewed Registered Nurse Do e, Jane CTXZN3122C. dg yz .org
2015-06- 14 09:58:01.493 Patient Re cord Read Flowsheet Viewed Registered Nurse Doe, Jane CTX ZN3122C.d gy z.org
2015-06- 14 10:27:47.257 Patient Re cord Read Patient Viewed Pharm acy Tech Sm ith , Mar y CTX ZN3121B.d gyz.o rg
2015-06- 14 10:32:33.267 Patient Re cord Update Mi scellan eous Data Create d Pharm acy Tech Sm ith , Mar y CTX ZN3121B.d gyz.o rg
2015-06- 15 14:15:01.787 Order Re cord Read Orde rs Querie d Pharmacist Miller, John CTXZ N3110E. dgyz. or g
2015-06- 15 14:15:09.083 Use r Acti on Exe cute Dialog Opene d Pharmacis t Miller, John CTX ZN 3110E.d gy z.o rg
2015-06- 15 14:17:32.730 Patient Re cord Update Prescri ption Hi story Added P harmacist Mi ller, John CTX ZN3110E.d gyz .o rg
10 ■ Medical Liability and Health Care Law ■ March 2017
• Are all audit logs associated with the EHR turned on and fully functional with respect to the fea-
tures that the organization has determined best meets its particular needs?
A: Yes. It would be a bonus if the organization could document that the audit logs were tested.
• When was the functionality of audit logs associated with the EHR last tested and what is the sched-
ule of such testing on an annual basis?
A: e audit log functionality is tested following every major upgrade to the EHR application.
• How long do you keep your audit logs?
A: e organization has a policy in place that clearly describes that the audit logs will be maintained
for 1 year, unless the organization is served with notice of a pending lawsuit in which case, if requested, the
audit logs will be maintained until the case is closed.
• Which of the organization’s systems and/or applications have separate audit logs?
• What privacy related logging is in place for each such system and/or application?
• Are privacy log retention settings in place for each such system and/or audit log?
• Are the privacy log retention settings sent to a secondary audit log (e.g., Fair Warning)?
• Is the secondary audit log retention congurable within the systems and/or applications?
• Who within the organization is the systems and/or applications “owner”?
X. Sample Questions That Could Be Used in a Deposition of an
Opposing Expert
1. Where did you receive your training in computer forensics?
2. Do you have any computer forensics certications? (e.g., Certied Computer Examiner; Com-
puter Hacking Forensic Investigator; Certied Forensic Computer Examiner; Cyber Security
Forensic Analyst)?
3. Where did you get your training in the computer science?
4. Have you ever taken a computer science course?
5. Have you ever written a computer program? If yes, did it include audit logging capabilities?
6. Where did you receive your training in nursing informatics?
a. If yes, are you a certied professional in nursing informatics?
7. Where did you get your training in health information management?
a. If yes, Are you are registered health information administrator?
8. Have you ever worked in a health information management department?
9. Have you ever worked for an electronic health record vendor? Are you familiar with the audit log
functionality of the particular EHR vendor used by the provider in this particular case?
10. Can you tell me what the HITECH act says about audits trails?
11. What elements does the HITECH act require in an audit log?
12. Can you tell me what HIPAA says about audit logs?
13. What elements does HIPAA require an audit log to include?
14. Are there any other federal or state rules and regulations pertaining to audit trails that we should
be thinking about?
Audit Logs ■ Sittig ■ 11
15. Are you familiar with the AHIMA (American Health Information Management Association)
guidelines on audit trails?
16. Have you ever worked in a hospital, outpatient facility or physician practice that used and EHR?
If so, which one(s)?
17. If the expert has a clinical background, you could ask: Have you taken care of a few patient
care activities (e.g., given medications, taken vital signs, turned the patient) and then entered
your notes in the computer an hour or so aer the fact? If no, ask what if one of your patients
“crashed” or “coded” before you got to the computer?
18. If the expert has a clinical background, you could ask: Have you ever gone back into the EHR
and made a change to one of your notes or entries? If so, why would you do something like that?
(should answer: realized I made a mistake, or needed to clarify something).
19. If the expert has a clinical background, you could ask: Did you always write a note to explain why
you made the change to the EHR?
20. Can you show us how you use the audit log to reconstruct a modication of the EHR?
a. Find a good example that pertains to the particular case you are working on.
Endnotes
1 See 45 C.F.R. § 164.501.
2 AHIMA. “Fundamentals of the Legal Health Record and Designated Record Set.” Journal of AHIMA 82, no.2 (Febru-
ary 2011): expanded online version.
3 See e.g., New York Codes, Rules and Regulations, Section 405.10 (4)(v) - Medical Records (safeguards to ensure secu-
rity and condentiality shall include but not be limited to the implementation of an audit capability to track access by
users) (6/2/10).