Event-Driven Architecture for Clinical Workflows Why Polling Doesn't Work in Healthcare
Polling delays critical clinical data when speed matters most. This post makes the case for modeling clinical actions as events (Kafka/RabbitMQ) instead of database checks cutting latency on alerts while producing a natural audit trail for compliance.
Why Polling Doesn’t Work in Healthcare
Most hospital software still relies on request-response patterns and periodic polling: a nurse’s station app checks every 30 seconds for new lab results, an inventory system checks hourly for restocking needs, a shift-handoff tool refreshes on page load. This works fine for low-stakes data. It fails badly for anything time-critical.
When a critical lab value comes back, a 30-second polling delay isn’t a UX inconvenience it’s a delay in care. Event-driven architecture solves this by treating clinical actions as a continuous stream of events rather than a series of database snapshots.
Modeling Clinical Actions as Events
Instead of “check the orders table for changes,” an event-driven system publishes discrete events as they happen:
OrderPlaceda doctor submits a medication or lab orderResultAvailablea lab result is finalizedShiftHandoffInitiateda nurse begins transferring patient contextSupplyThresholdBreachedinventory for a critical item drops below safety stock
These events flow through a broker like Kafka or RabbitMQ, and any interested service an alerting engine, an audit logger, a dashboard, a mobile push notification service subscribes independently. No service needs to know who else is listening.
Why This Matters for Compliance, Not Just Speed
The side benefit of event streams is that they create a natural, immutable audit trail. In healthcare, “who ordered what, and when did the result reach the right person” isn’t optional logging it’s often a regulatory requirement. An event log gives you this for free, since the sequence of events is the history, rather than something reconstructed from mutable database rows and timestamps.
Practical Considerations
- Ordering guarantees matter more here than in typical SaaS. A
ResultAvailableevent arriving before its correspondingOrderPlacedevent is a real correctness bug, not a cosmetic glitch. Partition keys should be chosen carefully (e.g., by patient ID) to preserve per-patient ordering. - At-least-once delivery is usually the right default, paired with idempotent consumers (see the companion piece on idempotency in patient data pipelines). Losing a critical alert is unacceptable; processing it twice should be harmless by design.
- Dead-letter queues need a human-facing escalation path. A failed message in a typical SaaS app might just get retried and logged. A failed clinical alert needs someone paged.
Where to Start
You don’t need to rebuild your entire system around Kafka on day one. A pragmatic path is to identify the two or three workflows where staleness costs the most critical lab alerts and medication order routing are common starting points and introduce event-driven delivery there first, while leaving lower-stakes reporting on its existing batch or polling model.
Event-driven design isn’t a trend to chase; in clinical software, it’s the architecture that matches how care actually happens as a sequence of urgent, ordered, must-not-be-missed moments.