Skip to content
Back to Articles
Article

Audit Trails in Pathology: What to Record and Why

4 November 2026 at 08:00
7 min read
Audit Trails in Pathology: What to Record and Why

When a report is amended, a slide goes missing or a patient asks who has seen their results, the lab needs a reliable answer. Audit trails provide that answer, but only if they record the right events in a form people can trust and actually use. This article is for pathologists, quality managers and IT staff who want audit trails in pathology systems that serve patient safety, accreditation and privacy rather than just filling a disk.

What an audit trail is

An audit trail is a chronological, tamper-resistant record of actions taken in a system. Each entry should answer five questions:

  • Who: the individual user, or the system or interface that acted
  • What: the action, such as created, viewed, changed, signed, printed or deleted
  • When: a reliable timestamp from a synchronized clock
  • Where: the record affected, and ideally the workstation or location
  • Why: a reason, where the action requires one, such as an amendment or emergency access

For changes to data, the trail should also keep the value before and after the change. A log that says a diagnosis was edited, without showing what it said before, has limited value in an investigation.

An audit trail is not the same as report versioning, although the two work together. Versioning preserves each issued version of a report; the audit trail records every action that led to those versions, and many actions that never changed anything at all.

Why audit trails matter in pathology

Audit trails serve several purposes at once:

  • Patient safety investigations: reconstructing how a labeling error, a delayed report or a misdirected result happened.
  • Accreditation: standards such as ISO 15189 expect traceability of results, changes and the people who made them.
  • Privacy accountability: laws like Thailand's PDPA expect organizations to protect sensitive health data and demonstrate it.
  • Medico-legal defense: showing what was known, by whom and when, if a diagnosis is later challenged.
  • Deterrence: people behave differently when they know access is recorded and reviewed.

What to record

Case lifecycle events

Every significant step in a case should leave a trace: registration, specimen receipt, grossing, block and slide creation, staining, distribution to a pathologist, additional orders such as recuts and immunohistochemistry, draft reports, sign-out, release, amendments, addenda and distribution of the report. Chain-of-custody events for blocks and slides, including archive retrieval and borrowing, belong here too.

Access events

Many systems log changes but not views. That is a serious gap. Inappropriate browsing of records is a common privacy incident, and the only way to detect it is to log who opened which case. Searches, printing, PDF downloads and data exports should also be recorded, as should failed and successful sign-ins.

Configuration and security events

Changes to report templates, user roles and permissions, system settings and interface mappings can affect many patients at once. Record who changed what and when. Emergency or break-glass access should be logged with its stated reason and flagged for review. If your access model follows good role-based access control, every grant and removal of a role should be logged too.

Interface and automated events

Orders received from hospital systems, results sent out and automated actions should be attributed to the interface or process that performed them, not left anonymous.

What makes an audit trail trustworthy

A log that can be quietly altered is worse than no log, because it creates false confidence. Look for these properties:

  1. Append-only: entries cannot be edited or deleted through normal use, including by administrators.
  2. Tamper-evident: any attempt to alter stored entries can be detected.
  3. Individual identity: every action is tied to a named person. Shared accounts make the whole trail unreliable.
  4. Synchronized time: all servers and devices use a common, accurate time source.
  5. Defined retention: logs are kept for a period agreed with quality, legal and privacy leads, and protected for that whole period.
  6. Readable and searchable: authorized staff can query by patient, case, user or date without needing a developer.

Reviewing audit trails in practice

Recording events is only half the job. A trail that nobody looks at deters little and detects nothing. Build review into routine work:

  • Event-driven review: pull the trail whenever there is an incident, complaint, amended report with diagnostic change or patient request.
  • Targeted routine review: check access to records of staff members and high-profile patients, all break-glass events and all permission changes.
  • Sampled review: periodically review a random sample of case access against clinical need.
  • Pattern checks: look for unusual volumes of views or exports, access at odd hours and access from unexpected locations.

Document each review and its outcome, and treat findings through your usual nonconformance process.

Be clear about who reviews what. Line managers are well placed to judge whether access by their own staff was justified, while the quality manager or data protection officer can oversee the process and handle sensitive findings. Agree in advance how suspected inappropriate access will be investigated, so that staff are treated fairly and patients can be told what happened when required.

Common pitfalls

  • Logging only edits, so inappropriate viewing goes unseen
  • Logs that only the vendor can read, available weeks after an incident
  • Administrators who can disable logging or purge entries
  • So much low-level noise that meaningful events are impossible to find
  • No agreed retention period, so logs are lost just when they are needed
  • Shared bench logins that make every entry ambiguous

Key takeaways

  • A useful audit trail records who, what, when, where and why, with before and after values for changes.
  • Log access and views, not just edits, along with configuration and security events.
  • Trust depends on append-only storage, individual accounts and synchronized time.
  • Review trails routinely and after incidents, and act on what you find.
  • Make logs searchable by authorized lab staff, not only by the vendor.

Audit trails work best when they are built into the system rather than added afterward. PATHOLOGY+ records audit logs across case handling, reporting and access as part of normal use, and you can book a demo to see what is captured.

Found this useful? Share it with your team

HanumanIT Editorial
Clinical Communication Team