Building a HealthTech Audit Trail Clinicians and Auditors Trust

A HealthTech audit trail clinicians and auditors trust records who accessed or changed what, when, and from where, in a log that is append-only and tamper-evident so no one can quietly edit it, and queryable so staff can answer "who saw this patient". Build it as a separate append-only table, block updates and deletes at the database, and hash-chain the rows so tampering shows.

This is general engineering information, not compliance advice; keep production and patient data in your own covered cloud and confirm what you must log and retain with your adviser. If you would rather have it built for you, see how RAITHub would build this below.

What makes an audit trail trustworthy?

Three properties, in order. It must be complete enough to answer the question auditors ask; it must be append-only, so a record cannot be changed after the fact; and it must be tamper-evident, so if someone bypasses the controls and edits the storage directly, the log can prove it. A log you can quietly edit is not evidence.

Property	What it means	How you get it
Complete	Reads and changes of sensitive data are recorded	Log at the write path, including failed attempts
Append-only	No one can edit or delete an entry through the app	Block UPDATE and DELETE at the database
Tamper-evident	Direct edits to the storage are detectable	Hash-chain each row to the previous one
Queryable	Staff can answer "who accessed this record"	Index actor, record and time
Safe	The log does not itself leak data	Store identifiers, not full record bodies

What does the schema look like?

A single append-only table, written by every sensitive action, with the actor, the record, the action, the time, the source, and a hash that chains each row to the one before it.

CREATE TABLE audit_log (
  id          bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  actor_id    uuid NOT NULL,            -- who did it
  action      text NOT NULL,            -- 'read' | 'update' | 'export' | ...
  record_type text NOT NULL,            -- 'patient' | 'encounter' | ...
  record_id   uuid NOT NULL,            -- which record (an ID, not its body)
  clinic_id   uuid NOT NULL,            -- tenant scope
  at          timestamptz NOT NULL DEFAULT now(),
  source_ip   inet,
  prev_hash   bytea,                    -- hash of the previous row
  row_hash    bytea NOT NULL            -- hash of this row + prev_hash
);

CREATE INDEX idx_audit_record ON audit_log (record_type, record_id, at);
CREATE INDEX idx_audit_actor  ON audit_log (actor_id, at);

Store the record's ID, not its contents, so the audit log cannot become a second copy of the data it is meant to protect.

How do I make it append-only and tamper-evident?

Block edits at the database, not just in the application, and chain each row to its predecessor so a direct edit breaks the chain. First, refuse updates and deletes:

-- Even a direct connection cannot change history.
CREATE RULE audit_no_update AS ON UPDATE TO audit_log DO INSTEAD NOTHING;
CREATE RULE audit_no_delete AS ON DELETE TO audit_log DO INSTEAD NOTHING;

Then hash-chain: each row's hash covers its own fields plus the previous row's hash, so changing any past row invalidates every row after it. A verifier re-walks the chain and flags the first break. This is the same hash-chained design used on Sundor Skin, described in designing an audit log customers trust. Testing that the log is append-only and cannot be edited through the API is covered in testing a HealthTech app before launch.

What queries will auditors and staff actually run?

Design the indexes for the questions people ask, not just for writing. The two most common:

-- Who accessed this patient's records, and when?
SELECT actor_id, action, at, source_ip
FROM audit_log
WHERE record_type = 'patient' AND record_id = $1
ORDER BY at DESC;

-- What did this user access in a time window? (a "did a leaver snoop" check)
SELECT record_type, record_id, action, at
FROM audit_log
WHERE actor_id = $1 AND at BETWEEN $2 AND $3
ORDER BY at;

Log failed access attempts too, not only successful ones, since an auditor often wants to see who tried. The access-control side of this, who should be able to reach a record at all, is in preventing a patient-data leak.

Buy, build or hire this?

Option	Choose this when	Trade-off
A logging or SIEM platform	You need aggregation and alerting across systems	Good for ops logs; not a tamper-evident record of record-level access
Your framework's audit plugin	You want change tracking quickly	Often lacks append-only enforcement and hash-chaining; verify both
Build an append-only, hash-chained log	You need an evidentiary trail of who saw what	More work; you own the schema, the triggers and the verifier

Doing it yourself is realistic: plan 2 to 4 days for the table, the append-only rules, the write path and the verifier, if you know PostgreSQL. The main risk of going alone is enforcing append-only only in application code, so a direct database connection can still rewrite history.

Why RAITHub for this

• Hash-chained audit logs are shipped work. Sundor Skin, built by RAITHub, runs a hash-chained audit log across 146 tables with 530+ tests, and TheSkinProof keeps an append-only trail across 217 endpoints.
• Logging at the right layer. RAITHub logs at the write path and tests the append-only behaviour through the API, the same discipline a health audit trail needs. It has also built a healthcare scheduling app for a client.
• Honest limits. This is audit-logging engineering. What must be logged, and for how long it is retained, is a compliance question for your adviser. RAITHub has not shipped a regulated health product and holds no SOC 2 or ISO 27001 certification. Patient data stays in your own covered cloud; development uses synthetic data.

When you don't need us

• Your app holds no sensitive data and an ops log is enough.
• You already have a tested, append-only, tamper-evident trail.
• You have an engineer who owns the audit log and its verifier.

How RAITHub would build this

• Scope: a free 15-minute call on what must be logged (confirmed with your adviser), the records involved and who queries the log.
• Spec: a signed design for the append-only table, the write path, hash-chaining and the auditor queries, built on synthetic data.
• Build: database-enforced append-only rules, a hash-chain verifier, indexes for the real queries, and logging of failed attempts, with tests in CI.
• Deliver: the trail with tests that prove it cannot be edited through the app, a verifier runbook and full IP; an NDA is standard. A focused build fits a 4 to 6 week SaaS scope.
• What you receive: tested, tamper-evident logging, CI gates, handover docs and IP, paired with your compliance partner for what and how long to log.

The build is fixed-price, quoted in writing after the call. See SaaS development, the HealthTech industry page, and the sibling guide on preventing a patient-data leak. To start, book a free technical audit.

General engineering information only; what you must log and retain is for your compliance adviser. Documentation checked on 11 October 2026.

Frequently asked questions

What should a HealthTech audit trail record?

At minimum, who accessed or changed what, when, and from where: the actor, the action, the record type and ID, the clinic, the time and the source. Log failed attempts as well as successful ones, and store the record's ID rather than its contents so the log does not become a second copy of the data. Exactly what must be logged is a compliance question for your adviser.

How do I make an audit log append-only?

Block updates and deletes at the database, not only in the application, so even a direct connection cannot change history. In PostgreSQL that can be rules or triggers that turn UPDATE and DELETE into no-ops on the audit table. Then test through the API that an attempt to edit or delete an entry is refused.

What does hash-chaining add?

Tamper-evidence. Each row's hash covers its own fields plus the previous row's hash, so altering any past row invalidates every row after it. A verifier re-walks the chain and flags the first break, which means a direct edit to the storage is detectable even if someone bypasses the append-only rules.

Will the audit log itself leak patient data?

It should not, if you log identifiers rather than full record bodies. Store the record type and ID, the actor and the action, not a copy of the clinical note. That keeps the log useful for answering "who accessed this record" without turning it into an unguarded second dataset.

How do I answer "who accessed this patient's record"?

Index the log by record type and ID and by time, then query for all entries matching that record. Index by actor and time as well, so you can also answer the reverse question, what a given user accessed in a window, which is the common check when someone leaves or an incident is investigated.

Does an audit trail make my product compliant?

No. A good audit trail supports a compliance programme, but compliance is an obligation on your organisation, decided with a compliance adviser, including what must be logged and how long it is retained. RAITHub builds the engineering; it has not shipped a regulated health product and holds no SOC 2 or ISO 27001 certification.