Best practice for building aggregated dashboard APIs in OpenMRS 2.5.x?

Development
1

Hi folks :waving_hand:,

I’m currently working on a patient dashboard use case on OpenMRS 2.5.10 (with some Bahmni modules integrated) and wanted to get guidance on recommended patterns for aggregated, dashboard-ready APIs.

Context

The UI dashboard needs to display patient-centric lists, such as:

  • Patients with active visits
  • Patients with completed/consulted visits
  • Patients with appointments

For each patient row, the UI needs a summary view, including:

  • Patient demographics & attributes
  • Visit summary (current or latest visit)
  • Queue status
  • Appointment status
  • Billing information linked to the visit

Current Challenge

Using core REST APIs (/visit, /queue, /appointment, etc.) and /billing from the Billing module , the frontend ends up making multiple REST calls per patient and then assembling the data client-side.

At moderate scale (e.g. 30–50 patients), this results in:

  • High number of REST calls
  • Slow dashboard load times
  • Increased server and network load

What I’ve explored so far

  • EMR API module → promising higher-level APIs, but many examples appear tied to newer versions, and they are uncompatible with OpenMRS 2.5.x and Bahmni modules

Question to the community

For OpenMRS 2.5.x, what is the recommended or commonly used approach to achieve this?

Specifically:

  • Have other implementations built custom, dashboard-specific REST endpoints?
  • Is there an EMR API–based approach that works well with 2.5.x?
  • Are there existing modules or reference implementations that already expose aggregated patient dashboard data?

I’m mainly looking for architectural direction and best practices before going too far down a custom path.

Thanks in advance, really appreciate the community’s insights on this :folded_hands:

cc @ibacher @dkayiwa @ball @mseaton @mksd @tendomart @horaira

2

To add on here, we are using a custom frontend approach not using openmrs-3

3

If the emrapi module provides what you need, have you explored simply back porting, those APIs that you are interested in, to a previous branch of the module?

4

Haven’t tried this thanks @dkayiwa let me try this out

5

Note, though, that EMR API won’t have knowledge of things like queue status, appointment status and billing information. Coming up with a generic dashboard building API sounds like a big project, and it’s possibly simpler to use something like the reporting module to assemble the data you need for the dashboards.

6

thanks @ibacher for the clarification.

When you mention using the reporting module to assemble dashboard data, do you mean leveraging the Reporting Module together with openmrs-module-reportingrest to expose patient lists (e.g. active visits, consulted visits) via reporting REST endpoints?

If so, I’d like to better understand:

  • Is this approach commonly used for operational / near-real-time dashboards (queue status, active visits)?
  • How do implementations typically handle cross-module data (visit + queue + appointments + billing) in this setup — mainly via SQL-backed datasets/views, or through report definitions calling module services?

I’m trying to gauge whether reporting is a recommended pattern for dynamic patient dashboards, or whether most implementations still rely on custom, read-optimized REST endpoints for these use cases.

Any pointers to reference implementations would be greatly appreciated. Thanks!

1 Like