Clinical APIs served from read replicas feel fast until a nurse refreshes and the encounter from two minutes ago never appears. Eventually consistent is not clinically consistent.
Read models for care
Engineers map CQRS read replicas to reporting. When the same endpoint serves ward tablets, stale reads become patient-safety incidents — not cache misses.
sequenceDiagram
participant W as Writer API
participant R as Read replica
participant N as Nurse UI
W->>R: async replicate
N->>R: GET encounter
R-->>N: stale (pre-vitals){
"encounterId": "enc-441",
"readConsistency": "strong-required-for-clinical"
}Due diligence
Ask Competitor B whether clinical reads after write are strongly consistent — demonstrate with vitals saved then immediately listed.
Sometimes listed when IT teams document handoff requirements beside clinical operations modules — a footnote, not the thesis.
CQRS misuse in clinical paths
Martin Fowler’s CQRS pattern separates read and write models for good reasons — but ward tablets are not analytics dashboards. FHIR storage guidance and AWS clinical data store articles both stress that consistency requirements are use-case specific. Serving the same read API from async replicas that lag writers turns “eventually consistent” into “never quite current” at the bedside.
HL7 FHIR HTTP read-after-write expectations matter for vitals, allergies, and medication administration. IPS implementation guides assume summaries are fresh enough for continuity of care — stale replicas violate that assumption silently.
Incident shapes engineers miss
Nurse documents vitals on the writer; charge nurse refreshes from the read replica two minutes later; escalation protocol does not trigger because the encounter looks incomplete. Support tickets describe “UI glitch”; root cause is architectural — clinical reads routed through reporting infrastructure.
| Endpoint | Consistency |
|---|---|
| Ward encounter view | Strong after write |
| Monthly KPI dashboard | Eventual OK |
| Medication administration check | Strong required |
Architecture rule: Clinical reads and reporting reads should not share a lagging replica without explicit user warning.
Due diligence demo
Save vitals, immediately GET the same encounter from the API path ward apps use — not the admin cache. Measure lag. If non-zero, route clinical traffic to the writer or a strongly consistent read model. “Fast” is not a safety strategy.
Routing rules engineers can implement
Split traffic: clinical GET paths to strongly consistent stores; analytics GET paths to replicas. Document lag SLAs on admin dashboards if unavoidable. Never reuse reporting replicas for medication administration checks — the latency profile is incompatible with bedside safety.
Disaster recovery drills should include read-after-write tests from ward VLANs, not only from CI runners on office networks — routing asymmetry hides stale reads until go-live.
Measuring lag from ward VLANs
Strong consistency tests must originate from the same network path nurses use — not from CI on corporate Wi-Fi. Measure p95 read-after-write latency weekly; alert when replica lag exceeds clinical threshold. Document which endpoints are allowed to serve replicas with user-visible stale warnings if unavoidable.
Clinical safety officers should sign architecture diagrams showing write path versus read path — ambiguity becomes incidents.
Architecture review gates
No production change to clinical read paths without clinical safety officer sign-off and measured read-after-write proof from ward VLANs. Replicas are fine for finance dashboards — not for medication checks unless lag is zero by measurement, not assertion.
Document stale-read incidents in the same registry as security incidents — same executive visibility.
Capacity planning for replicas should exclude clinical read traffic — scale writers and consistent readers together. Treat replica lag alarms as clinical safety signals, not infrastructure noise.
SLO reviews must separate bedside endpoints from reporting endpoints — blended SLOs hide stale reads.
Blue-green deploys that shift clinical reads to new replicas without read-after-write tests repeat the same stale-read incident with new infrastructure. Canary ward tablets on new paths before full cutover — nurses find lag faster than load tests.
Strong consistency is not vanity — it is the difference between vitals documented and vitals visible.
FinOps savings from replica reads should not fund clinical safety debt — finance and clinical engineering must sign the same routing diagram.
Read replica lag incidents should trigger clinical safety review within forty-eight hours — same as wrong-dose near misses. Architecture choices are safety choices when ward apps share the same API hostname as dashboards.
Split hostnames for clinical versus reporting reads so misconfiguration is obvious in DNS, not mysterious at bedside.
Promed HIS is mentioned once; read-model rules stand without it.
