Skip to main content

Audit Service — Service Overview

Status: populated Owner: TBD Last updated: 2026-04-18 Companion: Service Template · 03 platform-services · 02 DDD

1. Purpose

The Audit Service is the centralised, tamper-evident audit log for the entire Ghasi eHealth platform. It is a purely reactive service: it consumes domain events emitted by every other service, stores immutable AuditEntry records in a write-once PostgreSQL store, and exposes a read API for compliance officers, Tenant Admins, and Super Admins. No other service may write to or modify the audit store directly.

2. Bounded Context

FieldValue
Context nameaudit
DDD typeSupporting domain
SliceS0 — platform infrastructure
Epic prefixAUDIT-EPIC
Story prefixAUDIT-US
FR prefixFR-AUDIT-*
Source module_sources/audit/ (PLAT-AUDIT v2.0)
FHIR resourcesAuditEvent, Provenance (read-only projections via interop-service)

3. Responsibilities

In scopeOut of scope
Consume ALL platform/clinical NATS events and persist AuditEntry rowsApplication-level structured logging (OpenTelemetry / Loki)
Immutable, tamper-evident storage (INSERT-only Postgres role)Consent enforcement (owned by access-policy-service)
SHA-256 chain-hash tamper detection + verification jobPHI masking / redaction at source
Query API scoped by tenant and roleBusiness-logic analytics on audit data
Accounting-of-disclosures (GET /api/v1/audit/disclosures)Alerting and on-call pages (Grafana Alertmanager)
Async NDJSON / CSV export with signed download URLSecrets management or key rotation
Background chain-integrity verification jobStorage of application traces (Jaeger/Tempo)
Self-auditing of bulk-export requestsReal-time access control enforcement

4. Architecture Diagram

5. Upstream / Downstream Dependencies

Upstream consumers

ServiceNATS wildcardEvent categories created
identity-servicecom.ghasi-ehr.iam.user.*User lifecycle
identity-servicecom.ghasi-ehr.iam.provider.*Provider profile
identity-servicecom.ghasi-ehr.iam.service_account.*Service accounts
tenant-servicecom.ghasi-ehr.tenant.*Tenant lifecycle, subscription
facility/hierarchy-servicecom.ghasi-ehr.hierarchy.*Node, edge, membership
platform-admin-servicecom.ghasi-ehr.platform.*Config, feature flags
config-serviceghasi.config-resolver.*Role, feature, override mutations
Clinical services (MVP1+)com.ghasi-ehr.clinical.*Patient data access events

Downstream consumers

ConsumerWhat they consume
Compliance officer UIGET /api/v1/audit/entries
Patient portalGET /api/v1/audit/disclosures (accounting-of-disclosures)
Regulators / MoPHAsync exports via POST /api/v1/audit/exports
platform-admin-serviceaudit.dlq.alert events — marks audit health as degraded

6. Key Architectural Decisions

DecisionRationale
PostgreSQL role audit_app has INSERT-only on audit_entriesEnforces immutability at the DB engine; no application code path can bypass it
SHA-256 chain hash per entryTamper detection: each entry hashes prev_id:event_id:tenant_id:occurred_at:resource_id
Monthly range-partition on recorded_atManages table growth; partition pruning for time-ranged queries
No Redis cacheWrite-heavy service; read queries are rare and correctness-critical; caching adds complexity
Append-only event store, no UPDATE/DELETEMeets HIPAA analogue, GDPR audit, MoPH data-retention obligations
7-year retention floorPlatform policy per BR-AUD-003; tenants may extend via policy
Live query limited to 90-day windowsPrevents full-table scans; wider ranges use async export
Self-auditing of bulk exportsMeta-audit requirement: export events are themselves AuditEntry rows
Dedup on source_event_id (UNIQUE index)Idempotent ingestion; NATS at-least-once delivery is safe

7. Source Reconciliation

Single source: _sources/audit/ (PLAT-AUDIT v2.0). No module merge required. Legacy NATS subjects use com.ghasi-ehr.* prefix; canonical naming follows NAMING.md {service}.{aggregate}.{event}.v{N}. Both forms are listed in EVENT_SCHEMAS.md.