The platform landscape
Epic runs on the Chronicles database, accessed through the Hyperspace and newer Hyperdrive clients. The patient-facing chart you receive on production is an abstracted output; the forensic data — who opened the chart, when each entry was filed, and how notes were revised — is held separately and exported through Epic's reporting and audit tooling.
Audit trail & access-log reporting
- Access log / record access report
- Commonly used to show which users viewed or opened a patient's chart and when. Useful for establishing who was in the record around a disputed event.
- Audit trail report
- The action-level log — entries filed, modified, or deleted, with user and timestamp. The label and export format vary by Epic version and by how the organization configured reporting.
- Note revision / edit history
- Epic retains the editing history of clinical notes, including addenda and the times text was entered or changed. This is where backdating and after-the-fact additions surface.
Report names and behavior vary by version, module, and how the organization configured its system — capability should be assessed against the specific deployment, not assumed.
| Timestamp (UTC) | User | Action | Detail |
|---|---|---|---|
| 2024-03-11 22:47:03 | RN J. Doe | CREATE | Progress note created — status: draft |
| 2024-03-11 23:02:10 | RN J. Doe | VIEW | Vitals flowsheet opened |
| 2024-03-12 08:55:41 | Dr. A. Roe | VIEW | Progress note opened |
| 2024-03-12 09:14:55 | RN J. Doe | EDIT | Flagged: Progress note edited — entered late, back-dated to 03-11 |
| 2024-03-12 09:15:10 | RN J. Doe | SIGN | Progress note signed |
What to demand in discovery
- Request the native Epic audit trail and access-log export for the specific patient and a defined date range — not the printed 'designated record set' or Release-of-Information output, which omits audit data entirely.
- Specify both the access log (views) and the action/modification audit; producing one is not producing the other.
- Demand note revision history, including the timestamp each note was first saved versus signed, and any addenda.
- Ask the organization to identify the Epic version and which audit reports it is technically able to run, so 'we can't produce that' can be tested against Epic's documented capabilities.
Common production gaps
- Producing the abstracted legal chart in place of the audit trail — the most common substitution, and easy to miss because the output looks complete.
- Disclosing an access report (who viewed) while withholding the action audit (who changed what), or vice versa.
- Omitting note revision history so that a late or backdated entry reads as contemporaneous.
- Asserting a short audit-log retention window without supporting the claim with Epic's actual configured retention.
Frequently asked questions
Does Epic keep an audit trail of every change to a medical record?
Epic logs access to and actions on the record at the back-end database level, including when entries are filed and when notes are edited. Exactly which audit reports an organization can produce depends on the Epic version and its reporting configuration, which is why discovery requests should ask the provider to identify its audit capabilities rather than accept a blanket 'not available.'
Why does the Epic chart we received not show late entries or edits?
The printed or exported chart is an abstracted output designed for clinical and release-of-information use. It is not the audit trail. The metadata that reveals late entries, backdating, and edits is held separately and must be requested specifically as the audit-trail and note-revision export.
What should a request for production ask for with Epic records?
Ask for the native Epic audit trail and access log for the named patient and date range, the note revision history including addenda, and identification of the Epic version and available audit reports — explicitly distinguished from the designated record set.
This page is technical and regulatory information, not legal advice.