Audit Log Report

The question every clinic eventually has to answer

At some point, every clinic runs into a version of the same question: who looked at this record, and when? It might come from a patient disputing a change to their chart, a staffing issue that needs a factual answer instead of two conflicting memories, or an external auditor asking your clinic to demonstrate that patient data access is actually controlled and traceable. Whatever the trigger, the answer can't depend on someone remembering correctly. Audit Log is where that answer lives: a complete, automatically-generated history of every view, export, print, and edit performed on every patient record in your clinic.

This isn't a report you configure or opt into. From the moment a clinic starts using ClinyPal, every access to a patient record is written to this log the instant it happens, with no setup required and no way to switch it off. That's a deliberate design choice, not an oversight — an audit trail that could be disabled by the very staff it's meant to keep accountable wouldn't be worth much as evidence of anything.

The Audit Log report showing the Events, Record views, and Exports/prints KPI tiles above the Events table, with User and Action columns visible for each logged entry.

What gets logged, and why it can't be switched off

Every time a patient record is viewed, exported, printed, or edited, ClinyPal writes an entry to this log automatically, as part of the action itself rather than as a separate step someone has to remember to trigger. There's no setting anywhere in ClinyPal that disables this, and no user role — including Administrator — has a way to turn it off, pause it, or delete an individual entry after the fact.

That permanence is the entire point. An audit log that any sufficiently senior user could quietly disable or edit would be worthless as accountability — anyone with something to hide would simply turn it off first. Because logging in ClinyPal is unconditional and untouchable by design, it works as genuine evidence: a record of what happened that existed before anyone had a reason to check it, rather than something assembled after the fact.

Why this protects your clinic, not just your patients

It's easy to read an audit log as a tool aimed at watching staff, but that framing misses most of what it's actually for day to day. The far more common use is protecting the clinic itself. If a patient claims a note was altered without their knowledge, the log shows exactly who touched that record and when, resolving the dispute with facts instead of it becoming a he-said-she-said situation between a patient and a staff member. If a staff member is wrongly accused of accessing something they didn't, the same log clears them just as readily as it would confirm a genuine problem.

The other major use case is external: HIPAA and comparable data-protection frameworks expect a covered entity to be able to demonstrate accountability for who accessed protected health information. When an auditor or regulator asks a clinic to show that access to patient records is tracked and controllable, this report is the direct answer, already sitting there rather than needing to be reconstructed under time pressure. Clinics that can produce this instantly tend to have a much easier time in an audit than clinics that have to explain why they can't.

None of this is meant to feel like surveillance of your team, and in ordinary day-to-day use it won't — most staff will never need to look at this report at all, since normal, legitimate access to a patient's own assigned records is exactly what's expected to show up here constantly. The log only becomes actively useful in the specific moments described above: a dispute, an internal question, or an external audit.

Filters

• <strong>Date range</strong> — limits the report to events that happened inside the selected period.
• <strong>Location</strong> — limits the report to events that happened at a specific clinic location, useful for multi-location clinics narrowing down an incident to one site.

Combined with the Events table below, these filters are what let you reconstruct a genuine internal audit — for example, every record a specific user viewed at a specific location over the last 30 days, or everything that happened clinic-wide on the single day a dispute is centered on.

KPI tiles

• <strong>Events</strong> — total number of logged actions in the period, across all types.
• <strong>Record views</strong> — number of times a patient record was opened.
• <strong>Exports/prints</strong> — number of times a record or list was exported or printed. These tend to be the highest-sensitivity actions to review, since exporting or printing takes data outside the normal flow of viewing it on screen.
• <strong>Failed actions</strong> — number of attempted actions that did not succeed, such as an access attempt blocked by role permissions. A rising Failed actions count is worth a closer look, since it can indicate anything from a confused staff member to a genuine attempt to reach something they shouldn't.

The Events table

Each row is one logged event, and together the three columns answer the report's core question without needing to cross-reference anything else: what happened, who did it, and exactly when.

Who can see this report

Access to the Audit Log report itself is role-gated and limited to Administrators. That restriction exists for the same reason the log can't be disabled: a record of everyone's access to sensitive data shouldn't become a second exposure point that's freely browsable by anyone on staff. Keeping review of the log itself in the hands of whoever is accountable for the clinic's overall compliance keeps that accountability meaningful rather than diffuse. See Understanding Your Role & Permissions for the full picture of what each role can see across ClinyPal.

FAQ