How the audit log works — Compliance and GDPR

The audit log is the practice's event register: who did what, to what, and when. It is the basis of accountability under Article 5(2) GDPR and the first document reached for during an inspection or a suspected abuse.

Entries are created automatically, in a middleware layer between the request and the database — they do not depend on whether the author of the code remembered them. The app has no path that changes or deletes a single entry; the only deletion mechanism is the scheduled job described below.

What gets recorded

Every entry carries:

who — the user identifier,
in which practice — the tenant-separating field, always present,
which action — from a closed vocabulary of several hundred entries; the interface shows their names, for example Created, Viewed, Exported, Submitted to KSeF, AI Scribe session started,
on what — the object type and its identifier,
whose data was viewed — a separate column pointing at the patient, including when the action concerned a note or an appointment,
details — a JSON attachment, put through redaction so that a PESEL number or an e-mail address does not leak into the register,
a network fingerprint and a client fingerprint — cryptographic digests of the place the request came from and of the browser that sent it,
a timestamp.

Change of 2026-08-24. Until that day the IP address and the browser identifier were stored in raw form, even though the English version of this page promised a cryptographic digest. The discrepancy was closed by raising the product, not by lowering the promise: new entries carry only the HMAC-SHA256 of both values (with a separate AUDIT_IP_PEPPER key and domain separation, so the same address in two tables yields two different values). The interface shows the first 12 characters of the digest — enough to establish that two events came from the same place, and too little to establish which place that was.

Two caveats, so this page does not promise more than the product delivers:

Entries from before 2026-08-24 still contain raw values. They are removed by a one-off operator script (backfill-network-hashes.ts), which computes the digest and only then blanks the raw column. Until it is run on a given installation, the old rows do not change. There is no "after 30 days" automation here.
The consent register (ConsentRecord) deliberately keeps the raw address — it is evidence that consent was given under Article 7(1), and its evidentiary value before the authority matters more here than minimisation. That is a separate decision, not an oversight.

The register has no before-and-after state columns — whatever remains fits in the Details field.

Read events are recorded in batches and without the IP address and browser identifier — we collect those only on changes, so as not to weigh reads down. Changes are written immediately, so that a process failure cannot cut the trail short.

How to do it

The log opens at /audit, in the navigation as Audit Log. The filters: Date range (with ready-made ranges from Today to Last 90 days), User, Action type, Entity type and record ID. Clicking a row expands the details.

The Export button returns the result as CSV or JSON — honouring the filters that are set. The export is itself an event and leaves an entry in the log.

When something does not work

Warning

Only clinic owners and admins can view the audit log.

What this means: The signed-in person holds neither the owner nor the admin role in this practice.

What to do: Ask whoever manages the practice for access, or for a one-off export of the range you need.

Info

No audit events match the selected filters

What this means: The date range, the user or the action type narrows the result to zero.

What to do: Use **Clear filters** and narrow by one criterion at a time. An empty result over a wide range means the events have already been removed by the retention period.

Error

No records to export

What this means: The export inherits the filters from the view, and those return no rows.

What to do: Widen the date range before exporting again.

Who has access

Only the practice owner and administrator read the log. There is no "audit-log read-only" role today for an external auditor — the auditor is given an export.

The register is one shared table for all practices, but every query from the application layer is narrowed to the active practice, and membership in it is checked before the procedure runs. A person working in two practices sees only that practice's events in each. The boundary is guarded by a dedicated lint rule and several ratchets that run on every code change.

How long entries live

A daily job deletes entries older than the period set in Settings → GDPR & Privacy → Audit-log retention (20 years by default). That setting governs the log only — not medical records and not patient data; automatic deletion of patient data is not enabled in Heltio. Until 2026-08-24 the label in the interface said otherwise. Billing, financial and patient-rights entries are excluded from it and stay regardless of the setting. The full list of exclusions: Retention policy.