As a patient, I can request my audit trail (AuditEvent for every case action) #20

New issue

Open

opened 2026-04-14 20:43:16 +00:00 by claude-desktop · 0 comments

claude-desktop commented

2026-04-14 20:43:16 +00:00

Collaborator

User story

As a patient (and as a compliance-aware admin), I want every clinical action to leave an auditable trace, so that I can later request a clear history of who accessed or modified my data.

Acceptance criteria

AuditEvent emission

A FHIR AuditEvent is written for every:
- Case create/update/state-transition.
- Practitioner and Patient resource read/write.
- DocumentReference upload, read, and download.
- Cross-instance resource fetch (from #19).
- Federation trust change.
Each event carries: recorded, agent (who), source (instance + IP hash), entity (resource refs), outcome, purposeOfEvent, and, when relevant, agent.role.

Append-only storage

Dedicated DB table (or FHIR persistence) with no update/delete paths exposed.
Backup guidance documents WORM configuration for operators.

Access

GET /api/audit?patient={id}&from=&to= — patient or their attending practitioner can query their own trail.
GET /api/audit?from=&to= — admin only, full scope.
Export as CSV and as FHIR bundle.

Tests

Integration test: walk through a full case lifecycle and verify expected events are emitted.
Policy test: a practitioner cannot read another practitioner's audit trail.

Out of scope

Long-term retention policy automation (later operator chore).
Tamper-evident signing of the audit log (later).

References

spec/03-architecture/07-security-compliance.md §5.
spec/04-functional/03-patient-record.md §8.
spec/08-roadmap-mvp.md — step #20.

## User story **As a patient** (and as a compliance-aware admin), I want every clinical action to leave an auditable trace, **so that** I can later request a clear history of who accessed or modified my data. ## Acceptance criteria ### AuditEvent emission - [ ] A FHIR `AuditEvent` is written for every: - Case create/update/state-transition. - `Practitioner` and `Patient` resource read/write. - `DocumentReference` upload, read, and download. - Cross-instance resource fetch (from #19). - Federation trust change. - [ ] Each event carries: `recorded`, `agent` (who), `source` (instance + IP hash), `entity` (resource refs), `outcome`, `purposeOfEvent`, and, when relevant, `agent.role`. ### Append-only storage - [ ] Dedicated DB table (or FHIR persistence) with no update/delete paths exposed. - [ ] Backup guidance documents WORM configuration for operators. ### Access - [ ] `GET /api/audit?patient={id}&from=&to=` — patient or their attending practitioner can query their own trail. - [ ] `GET /api/audit?from=&to=` — admin only, full scope. - [ ] Export as CSV and as FHIR bundle. ### Tests - [ ] Integration test: walk through a full case lifecycle and verify expected events are emitted. - [ ] Policy test: a practitioner cannot read another practitioner's audit trail. ## Out of scope - Long-term retention policy automation (later operator chore). - Tamper-evident signing of the audit log (later). ## References - `spec/03-architecture/07-security-compliance.md` §5. - `spec/04-functional/03-patient-record.md` §8. - `spec/08-roadmap-mvp.md` — step #20.

claude-desktop added this to the v0.1 milestone

2026-04-14 20:43:16 +00:00

claude-desktop added the

area:backend

area:clinical

type:user-story

labels

2026-04-14 20:43:16 +00:00