Audit

C0901Which events does the audit trail record, and what does each entry contain?

The pilot covers part of this. The rest is designed, not built. Pilot detail: Per-clinic SHA-256 hash chain (tamper-evident, verify endpoint, edit/delete/reorder detected in tests); not WORM storage. For reference, REQ-4501 (a top-priority requirement, all three tiers) says every access, change, print, export, consent, authentication, admin, alert and break-glass event must generate an audit record with actor, role, terminal, purpose, patient pseudonym, object type, action, outcome, time and correlation id. Check: audit schema validation; 100% of covered actions produce a record in test.

C0902How would audit records be chained, batched and anchored to the ledger?

Audit records must be hash-chained per node, batched into Merkle trees and the batch root anchored to the ledger at an interval (still an open decision). That is REQ-4502, a top-priority requirement for all three tiers. Not yet. It is designed in the specification and not built in the pilot. Test in the specification: deleting a local record breaks verification. Parts of it are explicitly marked as open in the specification.

C0903Can anyone edit or delete audit records once written?

The pilot covers part of this. The rest is designed, not built. In the pilot: Per-clinic SHA-256 hash chain (tamper-evident, verify endpoint, edit/delete/reorder detected in tests); not WORM storage. REQ-4503 says audit storage must be append-only with WORM tier and no update or delete interface for any role. Its acceptance check: attempted update fails and is itself audited.

C0904Could a patient see who has looked at their record?

REQ-4504 is a top-priority requirement for all three tiers: audit must provide a patient-facing accounting-of-disclosures and access-history view without exposing workforce personal data beyond profile rules. The pilot covers part of this. The rest is designed, not built. What v0.2.0 does today: Per-patient access report for privacy staff; not patient-facing. To verify it, the specification says report matches underlying audit.

C0905Would the system detect snooping and unusual access patterns?

The audit part of the specification (REQ-4505) says audit analytics must detect snooping (VIP, coworker, neighbor, family), volume anomalies, off-hours access and repeated denials, producing review items with SLA. No. The specification describes it, but the pilot does not include it. Acceptance check: seeded snooping scenarios detected in test.

C0906How long would audit records be kept?

How would it be tested? The specification says retention config cannot go below profile value. That is the check for REQ-4506: audit retention must meet the longest applicable profile requirement; HIPAA documentation retention is 6 years (to be verified). Not yet. It is designed in the specification and not built in the pilot.

C0907Can an outside auditor read the audit trail, and is their own access logged?

The pilot covers part of this. The rest is designed, not built. In the pilot: Append-only by convention (no UPDATE/DELETE routes); no WORM; no scoped auditor role. For reference, REQ-4507 (a high-priority requirement, all three tiers) says auditors must have read-only access by scoped, time-boxed role and their queries must be audited. Check: auditor query appears in audit.