EHR Design, Timelines, and Audit Trails: Getting a Sense of What Has Happened

by Jerome Carter on January 14, 2013 · 2 comments

As EHR use increases, the number of complaints about incoherent paper printouts has grown.  However, it isn’t just clinicians who are having problems.   EHRs Prove a Difficult Witness in Court , an article from the Journal of AHIMA, details the legal headaches that can occur as a result of the inability to reconstruct an accurate timeline and story from EHR data.   The difficulties that arise in piecing together a patient’s story from electronic health record data as compared to paper records are due to the very different ways the two record systems store and present information.

Paper records are a collection of discrete units (forms/pages) that contain clinically-relevant aggregations of various types of data. On the contrary, EHR data are stored as small, discrete information units (records) that are aggregated on demand for display.  The flexibility gained from storing records in electronic form allows for capabilities that are impossible with paper: searching, sorting, cross-referencing, linking, etc.  However, since the electronic chart is a virtual construct created by software and populated via database queries, printing a coherent paper chart from raw EHR data can be problematic, as is quickly becoming obvious to EHR users.

While creating a coherent paper printout is obviously important, I see two additional, and more fundamental, issues looming in the JAHIMA article: 1) how to ensure that an EHR system is acceptable as a legal record,  and 2) what is the best way to provide chart review capability with electronic records.   Fortunately, the three issues share a common origin—the lack of appropriate metadata.

The inability to provide a coherent, trustworthy printed record is a by-product of the fact that an electronic record is virtual, and what is displayed is controlled by software.  Reconstructing what happened from raw EHR data requires not only patient data, but non-clinical metadata as well.  With the appropriate metadata, coherent printouts are doable, and the EHR takes a giant step toward being a viable and usable legal record.

Thinking About Data and Events
In relational databases, the basic storage format is a two-dimensional table in which each row (record) contains a set of data elements.   Thus, problems/diagnoses may be stored in a Problem_List table, as seen below. This is an oversimplification of an actual row (record), but it captures enough detail to illustrate the principles discussed.

V_ID MR# SNOMEDCode Date Time

[V_ID =Visit_ID, MR#=Medical Record Number)

In this example, the record contains a V_ID associating the problems/diagnosis with a specific visit, a medical record number, a SNOMED Code for the problem/diagnosis, and the date and time this record was added to the database.    This table structure captures enough data to produce a chronological problem list that can be sorted by patient and visit.  Using this table, we know what was recorded, but not by whom, nor whether it has been altered or otherwise accessed.

Cues that alert one to paper record tampering: erasures, differences in handwriting, form color, paper type, ink color and others do not exist in electronic systems.  Even those elements that do exist in the EHR, such as date and time stamps, can be easily changed.  Changing dates on paper is hard to cover up; in EHRs, not so much.

EHRs are dynamic systems, and specific measures are required to assure the integrity of their data.  As with paper records, we need to know not only what data have been captured, but also who is responsible; if any alterations have occurred; and how any given data element relates to other data in the system.   Audit trails are a good starting point for capturing information about internal EHR actions.

The 2014 EHR certification requirements mandate that certified products provide specific audit log capability.  The requirements are based on the ASTM E2147 standard, which dictates the data that must be captured. The required data elements are listed below.

Type of action (additions, deletions, changes, queries, print, copy)
Date and time of event
Patient identification
User identification
Identification of the patient data that is accessed

These requirements are an important step toward ensuring the integrity of EHR data and enhancing the EHR’s viability as a legal record.  Even so, the matter of how to best provide chart reviews for legal/regulatory purposes remains.

Producing coherent printouts requires the capture of specific types of data.  Paper charts are organized, among other things, by date/time, location, and encounters/visits. They are further divided into sections: notes, labs, radiology, preventive care, problem list, medication list, etc.   Creating a paper chart from a collection of data tables requires knowledge of how data in each table relates to the overall organization of the chart—a type of metadata that is not relevant for audit trails.   Producing a quality paper printout requires a software feature that takes in electronic data and reformats it for printing.  Usually this requires either a special template or that the database contain information to guide the reconstruction process. If both are lacking, the usual result is what occurred in the article.

Designing for E-Discovery
While better paper printouts are important in the short-term, they are surely not the ideal solution for conducting chart reviews for electronic systems.  Electronic discovery rules, at least at the federal level, stipulate that data for discovery be provided in electronic form whenever possible. The defendant in the article, a hospital, had to work with its vendor to provide the plaintiff with an electronic version of his record.  (I hate to think how much trouble that was to do—not to mention the cost.)   However, being that it has happened once, such a requirement is likely to happen again.

The ideal long-term solution (admittedly, not easy or cheap) is building EHRs that offer special features to support chart reviews for legal and regulatory needs.    Consider how great it would be if reviewers could rollback an EHR to a specific point in time and see what was on the screen, or if they were able to playback, video-like, a series of screen interactions and database accesses.  Such capability would be useful for HIT patient safety research as much as for legal proceedings.

The main purpose of an EHR is to maintain a logical, readable chronological record of a patient’s interactions with the health care system.  Thus, at a minimum, an EHR system should be able to provide a clear, detailed, and readable account of what happened to the patient.   Audit trails are a good starting point for creating the infrastructure required to make EHR systems reliable and usable legal records, but they alone are not enough. EHR designs must evolve to support the legal realities of health care.  This much is clear: e-discovery is here and disclosures, subpoenas, and lawsuits are not going away.

(For information on adding audit trails to a clinical system see EHR Design Basics: Tracking Data Changes and Accesses Using Audit Trails)


Leave a Comment

{ 2 comments… read them below or add one }

Charles Webster MD @EHRworkflow January 14, 2013 at 11:54 AM

I’d like to suggest process mining for EHR e-discovery:

“EHR process mining can discover, monitor and improve evidence-based processes (not assumed processes) by extracting knowledge from event logs available in (or “generatable” from) today’s EHRs. Process mining can answer three types of questions [3] for an EHR-using hospital or clinic: What is happening inside processes (Discovery)? It can compare what is happening with what should be happening (Conformance: especially relevant to medical error and patient safety). It can suggest ways to improve healthcare process effectiveness, efficiency, and user and patient satisfaction (Enhancement).”

Paper & Video: EHR Business Process Management: From Process Mining to Process Improvement to Process Usability


Jerome Carter January 16, 2013 at 3:09 PM

Chuck, thanks for your comment. I have no experience with process mining, but given your recommendation, I will certainly look into it.



Previous post:

Next post: