Five EHR Records Commonly Missed in Medical Discovery

A standard request for medical records usually produces the printed or exported chart. That document is necessary, but it is not the whole of what the electronic health record, or EHR, holds. Several categories of evidence sit outside the standard production and have to be requested specifically. Five come up again and again.

1. The audit trail. This is the system’s log of activity on the chart: who accessed it, when, what they did, and often from which device. It records creation and modification times and whether results were viewed. It is generally not included in a routine record request and must be sought by name, in native or full report form rather than a summary.

2. Alert and clinical decision support logs. Modern EHRs fire alerts for drug interactions, allergies, and other risks, and they log how each was handled. This matters because override rates are high. Studies of drug-interaction alerts report that roughly nine in ten are overridden, and only about half of overrides are judged clinically appropriate. An alert log can show what warning was presented at the decision point and how it was addressed. Neither the fact of an alert nor an override proves negligence, but the log documents what the clinician was shown.

3. Order-set and configuration history. Order sets and system configuration change over time. The version in place on the date of care may differ from the version produced during discovery. Requesting the historical version, with its effective dates, shows what options and defaults were actually available to the clinician then.

4. Downtime records. When an EHR is unavailable, staff document on paper and enter the information later. Downtime logs explain gaps and clusters of late entries that might otherwise look irregular. Requesting them prevents a benign explanation from being mistaken for something more.

5. Native data and metadata. The printed chart is a formatted report. The native data behind it, including flowsheet detail, discrete values, and metadata, can carry information the report compresses or omits. Requesting native data, along with the data dictionary needed to interpret it, preserves detail that a printout flattens.

Two practical points tie these together.

First, specificity and format matter. Each of these categories can be produced in a thin summary that strips out the useful detail. The request should name the item, ask for the native or complete form, and, where relevant, ask for the effective dates and the data dictionary.

Second, timing matters. These records are most useful when reviewed early, before depositions, so that testimony can be compared against the system evidence. Because they frequently prompt further written discovery, an early read shapes the questions that follow.

A closing note on discipline. Requesting these records does not assume wrongdoing, and finding them does not prove it. Audit and system data provide context that requires interpretation, sometimes with vendor documentation. The goal is an accurate reconstruction of what happened, which begins with asking for the evidence that the standard production leaves behind.