There’s one thing modern hospitals can’t afford anymore: delay.
They are quite common, especially when a patient’s vitals are bad and no one in the workflow is reacting accordingly. It is not the fault of the team not paying attention but it’s because the system didn’t update anything and reminders didn’t go off. Besides, the dashboard didn’t refresh.
The truth is that hospitals today are not lacking data, but they are receiving it late.
Most traditional HMS platforms were designed for administrative conveniences such as appointments management, records collection, billing after discharge.
But clinical realities have evolved. Patient status can change in seconds. And unless data moves in real time, decisions stall and care quality declines.
Today, inefficient communication and system delays contribute to over $12.4 billion in losses annually
That’s exactly the kind of problem we tackled while building NZCares’ cloud hospital management system.
In this post, I’ll break down how we used WebSockets and MQTT to enable real-time patient status updates across departments, from ICU to pharmacy, from mobile apps to front desks, without bringing down the entire hospital network.
Why Real-Time Communication is Crucial in Healthcare
Think about how many departments rely on fresh data:
Doctors need the latest vitals and reports before prescribing.
Nurses must see any alerts or medication adjustments immediately.
Labs need to know when a patient is ready for sample collection.
Admins should track bed availability without yelling across the hallway.
And yet, most cloud HMS platforms still function like outdated messaging boards: post something, wait for someone to walk by and notice it.
We knew that wasn’t going to cut it for NZCares Cloud Based Hospital Management Software. Our objective was to build cloud HMS that is smarter, faster, and leaner in its approach. We wanted a solution that gives patients everything before they ask for it.
Our Stack: MQTT + WebSockets
We combined the strengths of MQTT, a lightweight publish-subscribe messaging protocol, and WebSockets, which allow for persistent two-way communication between client and server.
Here’s the architectural overview:
[Medical Devices / Wearables / Mobile App]
|
MQTT Broker
|
[HMS Backend Engine]
|
WebSocket Server
|
[Doctor App / Nurse Dashboard / Admin Panel]
Now, if that seems like a lot, let me simplify:
MQTT will handle incoming patient data coming from devices, wearables, external apps,
And WebSockets will take care of outgoing updates (to user dashboards and internal systems)
Use Case in Action: Patient Vitals Alert
For instance, if a patient is connected to a heart rate monitor, the cloud-based hospital management software will update the readings in the background patient data file and send reminder if something is off.
Here's how NZCares handles it:
The device publishes data to patients/1823/vitals via MQTT.
The HMS backend listens to this topic and runs threshold checks.
If something’s off, for example, the heart rate jumps too high, it triggers a flag.
A WebSocket event pushes this alert to the nurse’s tablet and the doctor’s mobile app.
At the same time, the event is logged for analytics and compliance.
The entire loop of NZCares cloud HMS takes only milliseconds to complete.
Why Not Just Use One Protocol?
It’s a good argument to have, and we did try building everything around WebSockets in our early developments. But it didn't work the way we wanted it to work.
WebSockets are great for UI, but they become clunky for high-frequency, low-payload updates, like the ones you get from medical devices every few seconds. Also, they require more overhead for reconnection logic and scaling, which is not ideal for a long-term cloud hospital management system.
That’s where MQTT shines. It’s built for constrained environments, supports QoS levels (guaranteed delivery), and doesn’t flinch when 100+ patients send vitals every 3 seconds.
On the other hand, MQTT isn’t ideal for pushing updates to complex user interfaces like dashboards or mobile apps with multiple filters, roles, and logic layers. That’s where WebSockets still rule.
So instead of choosing one of them, we took the best of both worlds to develop our standalone cloud hospital management system.
Scalability and Performance
Here’s what our benchmarks showed after going live in a mid-sized multi-specialty hospital:
Average MQTT message delivery time: under 90ms
WebSocket push latency (UI): 70–120ms
Concurrent updates handled: 500+ users
Data loss or drop rate: <0.01%
No one had to hit refresh. Nurses stopped calling IT professionals, and the front desk had a taste of peace.
We also used Redis pub/sub internally to sync across microservices, ensuring both WebSocket and MQTT data pipelines stayed in sync without overloading the system.
Security Considerations
Now, if your brain just thought HIPAA compliance. Don’t worry, we considered it for our cloud hospital management system. Here’s how we covered that base:
All MQTT topics are encrypted using TLS.
Authentication happens via access tokens per user role.
WebSockets are gated using JWTs and role-based permissions.
MQTT topic structure ensures patients can’t eavesdrop on each other’s data.
Every message is logged (but anonymized) for audit purposes.
Yes, the compliance team is sleeping well now.
Real-World Anecdotes (Also, a Little Funny)
During early testing, a doctor received a live vitals alert halfway through their lunch. He rushed to the patient ward, only to find it was just the patient watching a particularly emotional soap opera episode.
We fixed the sensitivity and alerting threshold at that time. Real-time can be a double-edged sword. It will show you everything, even things you don’t want to know about.
Challenges We Faced
Alert Fatigue: Initially, our cloud hospital management system was too sensitive. It was sending notification even with minor fluctuations. We had to add logic to the group, prioritize, and throttle updates.
IoT Chaos: Not all devices speak the same language. Some needed custom MQTT wrappers.
Connection Persistence: As you know hospitals aren’t running on the fastest Wi-Fi connection. We implemented reconnect strategies and fallback SMS alerts for critical events.
Data Ownership: Deciding who gets notified and when, wasn’t easy. We had to build nuanced filters by department, shift, and priority.
What You Can Learn from This
Don’t overengineer real-time features. Let the business logic dictate what’s truly “real-time.”
Use MQTT for devices and ingestion. It’s fast, scalable, and reliable.
Use WebSockets for the front end. They shine when you need rich, reactive dashboards.
Build for humans. No one wants 300 blinking alerts. Be smart about grouping, escalation, and silence periods.
Looking Forward in Future
As our cloud hospital management software scale, we’re looking into:
Edge computing to offload device processing
Integrating AI triage that reads vitals and recommends action
Predictive workflows that pre-alert departments based on trends (yes, pre-alerts are a thing now)
Real-time healthcare is only scratching the surface. The next frontier will be relevance, precision, and trust.
If you are a startup healthcare tech or just want to know about real-time systems, let’s connect. We’d love to understand your view of today’s innovation in healthcare delivery.
Until then, may your cloud HMS be connected and alerted.
Top comments (0)