Healthcare: real-time capacity steering with Real-Time Intelligence

A regional hospital network with five locations steered bed, OR and ED capacity reactively: only once a department was full did staff switch course. The underlying data, EHR, IoT monitoring and scheduling systems, was scattered, so a current, network-wide picture simply did not exist. Management reports existed, but they told yesterday's story, not today's.

Batch and operational data lands via Mirroring and pipelines in Bronze on OneLake. In parallel, an Eventstream feeds live signals (bed status, equipment, throughput) into an Eventhouse, where KQL enables sub-second analysis. Activator watches thresholds and triggers alerts to department heads the moment a pattern, rising ED wait time, for example, crosses a boundary. For management, a Direct Lake semantic model exposes the same Gold layer in Power BI, without a second copy of the data. OneLake Security governs access to patient- and department-sensitive fields at row and column level for the Lakehouse and mirrored items, so through Spark and the SQL analytics endpoint. The Eventhouse recently got row-level security enforcement through OneLake Security in public preview; column-level security is not yet available there, so treat that layer as separately secured at Eventhouse level until the preview reaches GA.

The network needed both batch and streaming without running two separate platforms. Real-Time Intelligence and the Lakehouse share the same OneLake storage, so the capacity data behind the steering dashboards and the live alerts come from one source instead of two parallel truths. That is the difference between "a busy dashboard" and a system nurses actually trust.

A standalone streaming solution (Azure Stream Analytics next to a separate data warehouse, for example) was technically possible, but would have doubled security and governance: two access models, two audit trails. For a sector with GDPR and NEN 7510 requirements, that risk was not worth the flexibility gained.

• Real-time analytics is an always-on cost model; the Eventhouse runs continuously, even outside peak hours.
• Two query languages (KQL alongside Spark and T-SQL) demand an extra competency from the platform team.
• Activator is built for operational alerts, not safety-critical control; emergency-stop functions belong in a separate, deterministic layer.

Microsoft Fabric (Eventstream, Eventhouse, Activator, Lakehouse), OneLake with OneLake Security, Power BI with Direct Lake, Microsoft Entra ID for identity, Microsoft Purview for classifying patient-sensitive data.

• Split the hot and cold path from the same Eventstream: KQL for sub-second questions, the Lakehouse for anything needing history and joins.
• Set thresholds per department together with clinical staff; a generic alert gets ignored, a department-specific one does not.
• Monitor the Eventhouse's capacity consumption as actively as the Lakehouse's; streaming is the first place unmonitored cost creeps in.

The biggest resistance did not come from the technology but from trust: only once department heads saw that the alerts consistently matched what they experienced on the floor did they actually start steering by them. The first version of the thresholds also proved too sensitive; without deduplication and a recovery threshold, one flapping sensor sent dozens of alerts an hour, and nobody read them anymore.