Audit and tamper evidence

C0150What does the audit log record?

In the pilot: sign-ins, chart and list reads and writes, registration changes, alerts and acknowledgements, cancellations, catalog changes, break-glass and administrative actions.

C0151Can the audit log be edited?

The pilot has no edit or delete path, and a hash chain lets a verify button detect edits, deletions, reordering, truncation or a forged head in tests. It is tamper-evident, not write-once storage, and the database owner could still rewrite it.

C0152Will audit records be anchored outside the database?

Yes in the design: a hash of each batch is anchored on the ledger so later tampering is detectable. Not built.

C0153Is there an immutable copy of the audit log?

The design calls for a write-once copy with no delete interface for any role. The pilot does not have one.

C0154Can a patient see the access history for their record?

The design derives it from the audit log. The pilot gives privacy staff a per-patient access report.

C0155Does the audit log store patient data?

The design keeps personal content out of logs and uses pseudonymous identifiers. A build test is specified to fail if a log schema holds restricted fields.

C0156Are reads audited or only writes?

Reads too. Every access, print, export, consent action and authentication is an audit event in the design, and the pilot logs chart, list and registration reads.

C0157Can auditors look without changing things?

Auditor roles are read-only, scoped and time-boxed, and their queries are audited as well.

C0158Does the audit detect snooping on neighbors or VIPs?

The design includes analytics for VIP, coworker, family and off-hours access, repeated denials and honey-record touches. Detection rules are not built.

C0159Is there a limit to what audit detection can do?

Yes: it cannot catch a well-behaved insider reading within quota. The design states this limit plainly.