We are currently facing a challenge with keeping certain frontend components updated using the OpenMRS REST API. At the moment, our frontend performs a fetch every 5 seconds to retrieve updated data (for example things like active visits or similar dynamic information).
However, this frequent polling is not very efficient and generates repeated requests to the backend.
Our goal is to achieve near real-time data updates on the frontend without relying on constant polling. Because of this, we are exploring whether WebSockets or another push-based mechanism could be used so the backend can notify the frontend when data changes.
My questions are
Has anyone implemented WebSockets with OpenMRS to support real-time updates?
Are there existing modules, patterns, or discussions around real-time data synchronization in OpenMRS?
If WebSockets are not commonly used in OpenMRS, what would be the recommended approach for achieving real-time updates instead of polling every few seconds?
For context, we are currently using the OpenMRS REST Web Services API.
Any insights, examples, or references would be greatly appreciated.
Anyway To give more context, we already developed a dashboard on top of OpenMRS where we display active visits and incoming appointments. Currently, the frontend fetches updates from the REST Web Services API every 5 seconds so that the dashboard stays updated.
A challenge we are facing is that the dashboard does not update in real time. For example, in a live scenario: if a new visit or appointment is created in the system, it does not immediately reflect on the dashboard. The change only appears after the next polling cycle or if the user manually refreshes the page.
Our goal is to have the dashboard reflect these changes instantly (near real-time) when a visit or appointment is added, instead of waiting for the next fetch cycle. Because of this, we are exploring whether something like WebSockets or another approach could be used with OpenMRS to notify the frontend when such changes occur.
❯ what do you think about this? https://talk.openmrs.org/t/using-websockets-with-openmrs-rest-api-for-real-time-data-instead-of-polling/48714
⏺ Fetch(https://talk.openmrs.org/t/using-websockets-with-openmrs-rest-api-for-real-time-data-instead-of-polling/48714)
⎿ Received 23.6KB (200 OK)
⏺ Here are my thoughts on this:
Jonathan's problem is valid — polling every 5 seconds is wasteful and still doesn't give true real-time updates. But your response asking for more
context was spot-on, because the right solution depends heavily on the specifics.
Regarding WebSockets in openmrs-core:
Looking at the current codebase, OpenMRS core doesn't have built-in WebSocket support. Adding it would be a significant undertaking — it would
require integrating something like Spring WebSocket (since the platform already uses Spring), managing authentication/session handling over WS
connections, and deciding what events to broadcast.
More pragmatic alternatives Jonathan should consider:
1. Server-Sent Events (SSE) — simpler than WebSockets for this use case since the data flow is one-directional (server → client). The dashboard only
needs to receive updates, not send them. SSE works over regular HTTP, plays well with existing auth, and is easier to implement.
2. Smarter polling — before introducing new infrastructure, they could:
- Increase the interval (does a dashboard really need sub-5s updates?)
- Use conditional requests (ETag/If-Modified-Since) so the server returns 304 Not Modified when nothing changed
- Poll a lightweight "last updated" endpoint instead of fetching full data each time
3. Event-driven module — OpenMRS has an event system (the Event module based on ActiveMQ). A custom module could listen to relevant events (visit
created, appointment scheduled) and push notifications to connected clients via SSE or WebSockets.
My recommendation for what to tell Jonathan: The most practical path is probably a lightweight module that hooks into OpenMRS events and exposes an
SSE endpoint for dashboards. Full WebSocket support in core would be over-engineering it for a dashboard use case. If his polling interval is
causing actual performance issues, smarter polling alone might be sufficient.
What are your thoughts — are you considering this as something worth exploring for the platform, or more of a one-off solution for Jonathan's case?
✻ Cogitated for 31s
❯ the latter
⏺ Makes sense. I'd suggest pointing Jonathan toward the smarter polling approach first (conditional requests or a lightweight "last changed" endpoint)
since it requires no new infrastructure and would likely solve his immediate problem. If that's not enough, an SSE-based custom module using the
existing Event system would be the next step.
time to improve my prompt engineering skills
Claude getting the points here …thanks