O3 Frontend for the Operation Theater Module

Development
1

Hi OpenMRS community! :waving_hand:

We’re excited to share a new O3 microfrontend we’ve been building: an Operation Theater scheduling and management module for OpenMRS 3 (@openmrs/mediviya-esm-operation-theater-module):

:video_camera: Introduction

OT
OT1920×1517 218 KB

This work was driven by a real clinical need at our implementation sites, where surgical teams needed a modern, tablet-friendly interface to manage their daily OT lists.

As we designed the UI, we drew significant inspiration from the Bahmni OT Module UI — a well-regarded reference implementation for operation theater workflows in the OpenMRS ecosystem. Bahmni’s approach to scheduling views, surgical block management, and the overall OT workflow informed many of our UX decisions. We’ve adapted and extended those patterns to fit the O3 Carbon Design System and added two new capabilities not present in the Bahmni reference: a Freeze Window for locking confirmed surgical blocks, and a tablet-ready responsive view purpose-built for bedside and scrub-area use.

We want to be transparent about this lineage, give credit where it’s due, and invite the Bahmni community and any implementers familiar with that workflow to weigh in — especially on whether our adaptations make sense for a broader O3 audience.

:stethoscope: Problem Statement

Managing and scheduling Operation Theater (OT) activities is a critical workflow in hospital settings. The existing OpenMRS Operation Theater backend module provides solid scheduling logic — but it has no OpenMRS 3 frontend. Clinical staff working in the OT are left using legacy 2.x interfaces that are neither mobile-friendly nor usable on the tablets increasingly found at the scrub sink and nursing station.

The Bahmni OT Module UI demonstrated what a well-designed OT scheduling experience can look like in the OpenMRS ecosystem. We used it as a reference to ensure our O3 implementation follows established clinical workflow conventions — rather than designing from scratch and risking incompatibility with how OT staff actually work.

Additionally, once a surgical block is committed, there was no mechanism to freeze it from further edits — creating a risk of last-minute schedule changes going unnoticed by the surgical team.

:light_bulb: What the Module Does

@openmrs/mediviya-esm-operation-theater-module is a new O3 microfrontend (ESM) that delivers a full Operation Theater scheduling and management UI built on React and the Carbon Design System. It connects entirely to the existing openmrs-module-operationtheater REST API — no backend changes required — and introduces two key additions on top of the existing feature set:

  • :locked: Freeze Window — allows supervisors to lock a surgical block against further edits after a configurable cut-off time, preventing last-minute schedule disruption
  • :mobile_phone: Tablet-Ready View — a responsive layout optimised for touch input on tablets used at the bedside and in the scrub area

:laptop: GitHub Repository

Resource Link
:link: Repository mediviya-esm-ot-module
:hospital: Backend Module openmrs-module-operationtheater

:busts_in_silhouette: Target Users & Use Cases

User Role Use Case
Surgical Coordinator View and manage daily OT schedules; lock blocks before cut-off time
Surgeon / Anaesthetist Check their assigned theater, procedure, and patient details on a tablet in the scrub area
Scrub Nurse View real-time OT list on a wall-mounted or hand-held tablet without needing a desktop login
Hospital Administrator Review historical OT utilisation and throughput per theater

:building_construction: Technical Overview

  • Type: @openmrs/esm-* O3 frontend microfrontend (React + Carbon Design System)
  • Backend: Reuses the existing openmrs-module-operationtheater REST API — no new backend module required
  • Integration points: openmrs-module-operationtheater REST endpoints, esm-patient-chart (patient context), O3 SPA shell (navigation & extensions)
  • UI reference: Bahmni OT Module — workflow patterns and scheduling views adapted to Carbon Design System
  • New features (frontend-only):
    • Freeze Window — configurable via esm-config, enforced in UI; no backend schema changes
    • Tablet View — responsive CSS breakpoints + touch-optimised Carbon components
  • OpenMRS compatibility: O3 3.x, backend module requires OpenMRS Platform 2.6+

:framed_picture: Prior Art & Reference

We want to be explicit about our design lineage:

Reference What We Borrowed What We Changed
Bahmni OT Module UI Overall scheduling layout, surgical block structure, OT list workflow conventions Rebuilt in React + Carbon; adapted for O3 SPA shell routing and extension slots
openmrs-module-operationtheater All backend data models and REST API endpoints No changes — this module is a pure frontend consumer

We did not copy any Bahmni source code. The Bahmni OT UI served as a clinical and UX reference to ensure our implementation aligns with how OT staff actually work, rather than re-inventing conventions that the Bahmni community has already validated in production.

If any Bahmni contributors spot divergences from clinical best practice in our implementation, we’d genuinely welcome that feedback in this thread.

:bar_chart: Current Status

Item Status
:white_check_mark: Core scheduling UI Complete
:locked: Freeze Window feature Complete
:mobile_phone: Tablet-ready view Complete
:test_tube: Unit test coverage Improving

:globe_showing_europe_africa: Community & Implementation Context

  • Built by: Specific-Group Healthcare & Specific-Group Kosovo
  • Generalizability: The core scheduling view and tablet layout are fully generic. The Freeze Window cut-off time is configurable per site. This module is designed to work alongside any O3 distribution.

:red_question_mark: Questions for the Community

  1. Overlap check — Are there other O3 OT frontends in progress we should be coordinating with?
  2. Freeze Window design — We implemented this as a purely frontend config guard. Should this be enforced server-side instead? Happy to open a PR on the backend module if there’s appetite.
  3. Bahmni alignment — For those familiar with the Bahmni OT UI: are there workflow patterns we’ve missed or misrepresented in our adaptation?
  4. Adoption into core — Would the O3 squad consider mediviya-esm-operation-theater-module as a candidate for the core or community-maintained namespace?
  5. Tablet UX feedback — If you work in a facility that uses tablets clinically, we’d love to hear about your workflow and whether this layout fits.
  6. Co-maintainers — Is anyone else building OT tooling and open to joining forces?

:handshake: How You Can Get Involved

  • Try it — install on your O3 instance and share feedback in this thread

Thank you for reading, we look forward to your feedback and to building this together with the community. :folded_hands: — If you like to know about us Specific-Group (SPG) Healthcare you can check out our homepage: https://specific-group.com/healthcare-services

7 Likes
2

@mksd @veronica @beryl As discussed, we posted our current state of work of the O3 operation theater module development here to the community forum to have the opportunity gathering first impressions - feel free to share or comment below :slight_smile:

1 Like
3

Really great to see this work happening. Thank you so much to the team involved at SPG Healthcare. OT scheduling/workflows have been one of the notable gaps in O3 for a while now, so this is a very welcome addition at last.

Relying on openmrs-module-operationtheater is indeed the obvious approach here. However, integrating Bahmni backend modules into O3 has historically sometimes triggered broader discussions around governance, code review, release management, ownership, etc. At the very minimum, we’ll need to ensure that the ESM depends on a clearly released Maven version with artifacts available from a legitimate/public Nexus repository. Ideally, the backend module itself would eventually be reviewed, possible refactored/cleaned up and adopted under /openmrs on GitHub.

A bit of a tangent to the above, and maybe a rabbit hole we may collectively choose to ignore :slightly_smiling_face:, but OT booking/scheduling feels conceptually very close to “service booking” in general, which is already something handled through appointments. It raises the question (which honestly could already have been asked within Bahmni years ago): should there ultimately be a single backend scheduling/service-booking engine (openmrs-module-appointments?) capable of handling all service bookings, including OT scheduling? Please disregard if I’m missing some well established differences, especially if those are backed up by FHIR modelling.

There may well be good historical reasons for the split, but it could also partly be a consequence of the module proliferation that happened as Bahmni progressively forked away from OpenMRS over time.

On naming: I assume the project itself would eventually become something like esm-operatingtheater, esm-ot-scheduling, or another generic/functional name aligned with what the frontend actually brings to O3.

From a use-case perspective, at @Mekom we definitely have at least one surgery-focused implementation currently relying on Bahmni specifically because of OT scheduling capabilities. We’ve been discussing what a transition path toward O3 could realistically look like, and this kind of work suddenly makes that conversation much more practical, which is fantastic :flexed_biceps:

@PIH — worth a look as well. This could potentially become a really valuable addition for MCOE in Sierra Leone.

Tagging also @pauladams and @cduffy for some UI/UX input.

Again, big thanks :folded_hands: to the team at SPG Healthcare and @jbravo94 for pushing this forward.

2 Likes
4

Dear @mksd,

thank you for your detailed feedback, we appreciate it!

I could not reference the backend module initially but now here: openmrs/openmrs-module-operationtheater, because it is actually under the openmrs github already, but you are right with some points:

  • The module has a required reference to the atomfeed module which should probably not be a strict requirement
  • The artifact is maybe not tracked in a maven repository but in OpenMRS Add Ons
  • One of the main differences of the OT Module is the data model with the surgical blocks and appointment attributes Operation Theatre Scheduling Module - Bahmni Wiki - but I am not sure about its FHIR capabilities

I think the main question is if the requirements of OT planning can be covered by the openmrs-module-appointments module or if the openmrs-module-operationtheater specific capabilites like the data model is still relevant for today for most usecases.

The name is based on our internal product names - so this can be aligned with community standards if desired.

@mksd Thank you as well for referencing respective members - I would also be happy to hear their input!

5

Ok that’s great, and will make things much easier.

The trick here will be to make it <aware_of_module/>, like it’s was done here for appointments for example.

I don’t remember how that works, but clearly it’ll have to be deployed to the official Maven repo like for any other OpenMRS JAR/OMOD. As far as I remember this happens through the Bamboo build. We can look into that later.

It’s probably a bit late to litigate the existence of this module. Both modules (OT scheduling and appointments) were in fact created around the same time, back in mid-2017 by Thoughtworks.

What I was trying to say is that if FHIR models OT scheduling differently from regular service scheduling, then that somewhat reinforces the case for handling it separately. But if not, then arguably this could probably have been handled through a single backend module from the start.

Anyway, that ship has sailed :flight_departure: :waving_hand:

6

Thanks for the detailed explanation - got your point. I think a detailed review of the OT backend module would be required to determine how it can be mapped to FHIR models and especially if there is additional behaviour embedded in the current backend which may justify a separate module - we will monitor your suggestion :+1:

1 Like