Why this distinction matters far beyond healthcare
One of the most helpful ways to understand modern software architecture is to distinguish between state-based systems and event-based systems.
This is a concept I have had to explain many times in healthcare interoperability, especially to people trying to understand why certain systems behave so differently from others. It also helps explain why technologies built around live updates and server-driven changes make so much sense once you see the architectural difference underneath them.
To make it simple, imagine two fictional healthcare platforms: ChartStone Clinical and PulseTrail Health.
ChartStone Clinical: a state-based system
ChartStone Clinical is a records-focused application. A user opens a patient chart, the server sends the current data to the client, and from that point forward the user interacts with a local representation of that state until they submit their changes back to the server.
This is how a large portion of modern applications work, whether they are SPAs, traditional server-rendered apps, thick clients, or older LAMP systems. The client receives a snapshot, works against that snapshot, and eventually sends back an updated version of state for the server to merge into the source of truth.
That approach is practical and familiar, but it comes with a number of challenges.
What happens if another user changes the same record before the first user submits their update? What happens if authorization expires mid-edit? What happens if the client loses power, restarts unexpectedly, or drops connection before its local changes are persisted? Suddenly the system has to deal with file locks, merge conflicts, local drafts, recovery mechanisms, and complicated rules about reconciling client-side changes with the authoritative data on the server.
If the system is mostly read-only, some of this complexity fades into the background. But most business software is not read-only. Most systems support active collaboration against mutable shared data. That means the moment the client owns a working copy of state, the burden of consistency becomes much heavier.
PulseTrail Health: an event-based system
Now imagine PulseTrail Health, a monitoring platform used in a critical care environment.
In this world, devices connected to patients continuously emit events: heart rate updates, oxygen changes, alarm thresholds, patient assignment changes, and other vital signals. Those events flow to a central hub, which aggregates and distributes them to the places that need them, such as bedside displays, nurse stations, and mobile monitors.
The key difference is that the system is not waiting for someone to ask for the latest snapshot. It is reacting to what is happening as it happens.
If a patient’s heart rate drops suddenly, the system cannot afford to let that information sit idle until the next poll cycle or page refresh. The event itself is what matters. The architecture is built to push meaningful changes outward immediately.
This is why event-based systems are often a better fit for highly reactive environments. They reduce the delay between change and response. They also reduce waste. Instead of constant polling across the network just to ask whether anything has changed, a push-based system can remain relatively quiet until something meaningful actually occurs.
That is a major architectural advantage, especially when timing, visibility, and coordination matter.
The difference in plain terms
A state-based system is centered on the question:
What does the record look like right now?
An event-based system is centered on the question:
What just happened, and who needs to know?
The state gives you the latest snapshot whereas events give you the flow of change. Both of these matter, most applications still need some current state view. Users need dashboards, forms, lists, reports, and screens that show the latest known truth. But when an application is built only around snapshots, it can become blind to the significance of the transitions that produced them. The events capture those transitions directly.
Why this matters beyond healthcare
Healthcare makes the distinction easy to see because the stakes are high. But the principle applies almost everywhere. Most applications are not merely storing data; they are coordinating change over time.
Orders are placed. Payments clear. Inventory moves. Messages are sent. Users sign in. Documents are edited. Approvals happen. Sensors report. Notifications fire. Background jobs complete. External systems need to be informed. Audit trails need to be preserved. Failures need to be recoverable.
A state-based model can tell you where the system ended up while an event-based model can tell you how it got there, what happened along the way, and what other parts of the system should do in response.
That is why event-based architecture is useful far beyond medical monitoring. It fits CRMs, ERPs, commerce systems, logistics platforms, financial applications, content systems, communications tools, and operational dashboards. Nearly every serious application deals with meaningful change, and meaningful change is where events shine.
Why almost every application can benefit
This does not mean every application should be purely event-sourced or that state no longer matters. It means that thinking in events often leads to better systems. Event-based architecture can improve real-time responsiveness, integration with other systems, auditability, decoupled workflows, automation, resilience, and visibility into what actually happened. In other words, event-based thinking helps software behave more like the real world it is modeling. Real businesses do not operate as a sequence of static snapshots, they actually operate as a stream of things happening.
The more an application needs to react, coordinate, notify, synchronize, or explain itself, the more value there is in treating events as first-class citizens.
Final thoughts
State still matters, but events often tell the full story. In practice, that also shapes how I think about the web stack itself. If the goal is to model systems as a flow of meaningful change rather than a sequence of disconnected snapshots, then the transport and UI model should reflect that.
That is one reason I tend to favor DataStar over HTMX for this kind of architecture. HTMX is excellent at request-driven hypermedia and remains one of the most approachable ways to build server-rendered applications with minimal client complexity. But when an application starts leaning into truly live, server-driven behavior, DataStar’s model feels more aligned with the problem itself. Its philosophy centers the backend as the source of truth and treats the UI as something continuously updated through a unified SSE stream, with only small, intentional client-side signals and event pushes where needed. That creates a cleaner mental model than treating realtime communication as an add-on and reaching for WebSockets as the default transport for everything. WebSockets certainly have their place, but in many business applications they can bring extra operational weight around scaling, connection lifecycle, message handling, and recovery after failure. Even automatic reconnect becomes more complicated once distributed infrastructure, missed messages, retries, and partial client state enter the picture. By contrast, a server-led approach built around downstream SSE and very small upstream pushes can stay simpler, quieter, and easier to reason about both architecturally and operationally.
Bringing it back to healthcare, this is also part of why many FHIR-based architectures still feel incomplete when compared to the practical event movement that made HL7-style workflows so effective in the real world. FHIR has brought major improvements in structure, readability, and interoperability, but many implementations still lean too heavily on request-response thinking, polling, or subscription models that do not yet fully embrace true event-first communication. Until more FHIR-based ecosystems grow toward genuinely event-based exchange, where systems publish and react to meaningful changes as they occur, they will continue to struggle to replace the practical strengths that older HL7 workflows delivered in high-volume operational environments.
The future is not just better resource models. It is better system-to-system communication built around events as first-class citizens.
Top comments (0)