Serve the same audit-trail request on two hospitals and you can get two entirely different answers — not because one is hiding more than the other, but because they run different software. The words "audit trail" map onto a differently named report, a differently scoped export, and a differently located data set in every major EMR. A request drafted in the abstract lands on whatever the defendant's system happens to call the nearest thing, and "we can't produce that in the form you asked for" is sometimes true of the label while being false of the data. The vendor matters, but mostly as the thing that decides what the request has to name.
Which makes identifying the defendant's EMR step zero. The pillar EMR discovery guide covers the full landscape of what to request across any system; the individual system guides at /emr-systems go deep on each platform's audit tooling and its production gaps. This guide sits between them: a cross-system comparison of what the seven most common EMRs actually log and export, and — where a system's audit facility has no crisp, fixed name — what to ask for by function instead. Report names and export formats vary by version and configuration in every one of these platforms, so treat what follows as the shape of each system's audit data, not a catalog of report titles to demand by name.
Epic
Epic runs on the Chronicles database, reached by clinicians through the Hyperspace and newer Hyperdrive clients; the chart produced in records is an abstracted output, while the forensic data sits behind it. Epic's audit data is not one report but three layers: an access log (also called a record access report) showing who opened the chart and when, an audit trail report capturing action-level events — entries filed, modified, or deleted, each with a user and timestamp — and note revision history retaining how notes were edited, including addenda and the times text was entered or changed.
The recurring substitution is producing that abstracted legal chart in place of the audit trail — easy to miss because the output looks complete — or disclosing the access log while withholding the action audit, or the reverse. The label and export format vary by Epic version and reporting configuration, so a blanket "not available" should be tested against the reports the organization can actually run — as should any assertion of a short retention window, which ought to be measured against Epic's actual configured retention rather than accepted on its face. The Epic discovery guide covers all three layers and how a filtered export narrows them.
Oracle Health (Cerner)
Oracle Health — formerly Cerner — most often runs on Cerner Millennium, and it splits its audit data across tools. Privacy and access auditing, commonly handled through a dedicated tool labeled P2 Sentinel, reports which users accessed a record and when; it answers "who looked" more than "who changed what." The lower-level action and modification logging lives in Millennium itself and is typically reached through Discern-based reporting or a vendor-assisted export, and document/note history carries the version and addendum detail. Because the data lives in more than one place, a single "audit report" rarely tells the whole story.
The gotcha is treating a privacy/access report as "the audit trail" so that change history never surfaces, or citing the limits of the access tool to avoid producing the deeper Millennium logs that do capture modifications. Ask for the access auditing and the clinical change history as distinct data sets, anticipate that the deeper logs may be characterized as "not a standard report," and define the patient, encounter, and date range precisely — Cerner exports are scoped queries, and a window drawn too narrowly around a single user or day lets surrounding edits fall outside the production. The Oracle Health / Cerner guide works through the split and how to keep one report from standing in for the other.
MEDITECH
MEDITECH is not one platform but several generations — the older MAGIC and Client/Server (C/S) systems and the modern web-based Expanse — and audit granularity differs meaningfully between them. Its audit-and-trace reports capture access and documentation activity, but what they include and how far back varies by generation, and detailed retrospective data is frequently queried from MEDITECH's Data Repository (DR) rather than the bedside application. Document edit and addendum timing is captured where the platform version supports it.
The version is often the first thing a production fails to disclose, which lets a thin MAGIC or C/S audit pass as if it were the ceiling for any MEDITECH system, and it lets a bedside audit view stand in for the richer Data Repository extracts. Establish the platform and version first, then request both the application audit trail and any DR-based access/activity extract, and pin down retention and archival separately — legacy installs sometimes hold audit data on different schedules than the live record. The MEDITECH guide details the version-specific differences and where the DR data hides.
athenahealth
athenahealth's clinical product (athenaOne / athenaClinicals) is delivered as a hosted cloud service rather than software installed at the practice, so the audit data is retained centrally by athenahealth rather than on a server in the building. There is no single crisply named audit module to demand; the data exists as document and encounter audit history — when items were created, edited, and closed — together with a user activity log of actions within the hosted environment. Broader or historical exports may route through athenahealth at the practice's request.
The predictable response is "the data is hosted by athenahealth, not us" — but the practice contracts with the vendor and can request the export, so the cloud model changes the logistics of production, not the existence of the data or the obligation to produce it. Ask for the centrally retained audit history specifically rather than a clinician-facing activity summary, and require a vendor-assisted export where the practice's own login cannot reach it; the cloud architecture is also a reason not to assume a short retention window, since hosted retention may actually run longer than an on-premise install's. The athenahealth guide covers the cloud-hosting objection in full.
eClinicalWorks
eClinicalWorks (eCW) is a widely deployed ambulatory EHR whose audit log captures user actions and documentation activity, including the timing of note creation and changes. Its handling of note locking and addenda is the center of gravity: once a progress note is locked, later changes should appear as logged edits or disclosed addenda rather than silent alterations, and the audit log — alongside the note-lock and addendum history and per-encounter activity detail — is the record that tests whether that actually held.
The gap is producing the visible progress note without the audit log, so an edit made after locking reads as contemporaneous, or conflating an addendum — disclosed and timestamped — with a silent edit to the original. Request the per-encounter audit log with timestamps for note creation, locking, and any subsequent edits or addenda, ask specifically whether the notes at issue were locked and when, and seek the timing of documentation entry relative to the visit date, which surfaces entries authored well after the encounter. The eClinicalWorks guide covers the lock-and-addendum line and the productions that blur it.
Veradigm (Allscripts)
Veradigm — formerly Allscripts — is not one product but a family of them: ambulatory lines such as TouchWorks EHR and Professional EHR, and Sunrise in the acute setting. These were built separately and audit documentation activity in different ways, so there is no single "audit trail" report to name across the portfolio; each product maintains its own audit of user actions and documentation activity, with its own report names and scope, plus document version history and access reporting where the product supports them.
The decisive gotcha is drafting against the wrong product, which invites a technically true objection that the named report does not exist. Establish the specific product first, then request the audit data by function — access, documentation actions, and edit history — rather than by a generic label the product may not use, and remember that an acute (Sunrise) and ambulatory (TouchWorks/Professional) deployment at one health system may both be relevant and audit separately. The Veradigm / Allscripts guide covers identifying the product line before drafting.
NextGen Healthcare
NextGen's products (NextGen Enterprise and the cloud-oriented NextGen Office) are concentrated in the ambulatory setting and lean heavily on templates and copy-forward functionality. Its audit trail logs user actions and documentation activity including entry and edit timing, its encounter/note edit history shows documentation timing relative to the visit and authentication and whether content was changed after signing, and access reporting shows who opened the chart and when. Because of the template and copy-forward reliance, cloned and carried-forward content is a recurring integrity question its audit data is well positioned to answer.
The gap is producing the final note without the audit trail, so copy-forward and cloned content reads as freshly authored each visit, and omitting the documentation timing that would reveal entries authored well after the encounter. Request the audit trail with documentation and edit timing, target the data bearing on template and copy-forward duplication, seek note edit history including changes made after authentication, and confirm whether the deployment is Enterprise or Office, since audit access differs. The NextGen guide covers the cloning-detection angle in full.
The cross-system constants
For all the differences in naming and architecture, three things hold across every platform on this list — and they are what let you push past a vendor-specific "we can't produce that." First, action-level logging exists. A system that holds electronic protected health information is operating under HIPAA's audit-controls requirement (45 CFR 164.312(b)), which obligates the mechanism that records and examines activity in that system. The log is the output of a control the provider was already required to run, not a courtesy it chose to offer — which is why "there is no such record" is a claim about noncompliance more than a discovery position.
Second, a native tabular export exists. Audit data is rows of events, each with a user, a role, a timestamp, and an action, and every one of these systems ships a way to export that data in the structured form the vendor built for it. A proprietary container or a printed PDF is a decision about which button was pressed, not a limit on whether the data can be handed over in native form. Third, the person who runs the export chooses parameters — a date range, an event-type filter, a user scope, a report template — and those parameters shape what you see far more than the vendor's logo does. The same Epic or Cerner export can arrive complete or quietly narrowed depending entirely on who ran it and how.
That is why the vendor is the smaller variable. What decides whether a production is complete is the language of the request and the parameters agreed before the export is generated — and both are the same across all seven systems. How to request EMR audit trails covers the definitions, the native-format specification, and the export-parameter meet-and-confer that hold a request together regardless of which EMR is on the other side. Identify the system so you can name what it calls things; then rely on the discipline that does not change from vendor to vendor.
This article is technical and regulatory information, not legal advice. EMRCheck is not a law firm.