DBRaven

Healthcare Records Platform

Financial Ledgerexpert complexity

Deterministic topology derived from YAML knowledge entities. Nodes represent workloads, datastores, patterns, and risk components. Edges show typed relationships with propagation direction.

19

Components

0

Connections

6

Failure Modes

3

Propagation Paths

Max exposure: high· 2 high-risk nodes in this topology
Topology Graph19 nodes · 0 edges
2 high-risk nodesClick a failure mode below to trace propagation
Workload
Datastore
Cache
Event stream
Pattern
Risk node
Risk path

Failure Propagation Trace

Topology Notes

  • ·Every clinical write operation atomically writes three rows in one PostgreSQL transaction: the clinical record mutation (or event append for event-sourced tables), the audit_log row (who accessed what record at what time with what operation), and the outbox row (FHIR event payload for downstream relay). If any of the three writes fail, the entire transaction rolls back. This guarantees that the audit log is never ahead of or behind the clinical record state.
  • ·PostgreSQL row-level security policies are enforced on all tables storing patient-identifiable data. The application database role is never granted superuser or BYPASSRLS privileges. RLS coverage tests must run against every new table before it is added to the migration deployment: the test must verify that a different patient's records are inaccessible via a cross-patient query.
  • ·Kafka FHIR topics partition by patient_id to preserve per-patient event ordering. Topic retention must be at least 90 days for replay capability during system integrations. min.insync.replicas = 2 across at least 3 brokers. Consumers must implement idempotent processing keyed on the outbox event_id: duplicate FHIR events can occur during relay restart and must not produce duplicate downstream clinical records.
  • ·Redis is used exclusively for session state (authenticated practitioner sessions, token validation caches) and terminology lookup caches (ICD-10, SNOMED code to display label mappings). Clinical record data must never be stored in Redis : Redis eviction policies could silently drop patient data without error. If Redis is unavailable, the system must degrade gracefully by falling back to PostgreSQL for session validation, not fail open.
  • ·The read replica serves clinical summary queries, dashboard aggregations, and audit report generation. The replica must never be used to serve real-time clinical decision support queries where stale data could affect treatment decisions. The routing layer must explicitly categorize query paths as "primary-only" or "replica-acceptable" and enforce the routing, not rely on developer judgment per-query.