GSoC 2017 – Operation Theater Module Workflow Enhancements

This post originally appeared in OpenMRS Talk as my final presentation.

Operation Theater Module Workflow Enhancements

Mentors: Akshika Wijesundara & Harsha Kumara

Code contribution Summary: GitHub

There’s a certain pleasure in seeing people make use of your work. That’s one of the main driving forces behind the open source philosophy. It’s deeply satisfying to know that your lines of code makes someone’s life easier, even if by just a little bit.
But what about not just making lives easier, but helping to save entire lives? That’s some next level thing. Enter OpenMRS.
This summer I had the opportunity to contribute with code to save lives, and this is my final note about the experience.


My project was to work with the operation theater module which can be used to manage theater activities in hospitals. It had been made as a previous GSoC project, but not updated with the rest of OpenMRS.
So I had two primary targets:

  1. Migrate the module to work with the latest OpenMRS platform.
  2. Perform workflow enhancements to make it more useful.

And migrate and enhance we did.


Migrating the Operation Theater module

The OT module was written for platform 1.9.7, in the age of Java 7. Fast forward to 2017, and we’re having platform 2.7 in beta.
So as my first task, I set out to migrate the module to the latest stable OpenMRS platform – 2.6. This involved a number of things, mostly related to replacing outdated components in the module code base.

Replacing Joda Time library

The module solves a constraint satisfaction problem – scheduling surgeries to available operation theaters. It uses the Optaplanner library for this task. This involves coding the available times of operation theaters, the surgery durations, avoiding surgery overlaps and making maximum use of the available times.

The original implementation modeled the problem with programmatic concepts and implementations of time available in 2014. It used the Joda Time library for things like intervals, durations and timeline management. This library was deprecated and became obsolete with the introduction of the Time package in Java 8.

What’s more, the use of the Joda Time library raised many dependency issues as the same library’s different versions were being used across different modules in OpenMRS. We had a nightmare with class loader constraint violations.

After discussions with my mentors, I replaced the Joda Time library with the Java standard library’s Time package, and the ThreeTen-Extra package. Together, these two packages provide the essential features such as intervals and durations required as part of the CSP solution.
Elsewhere, OpenMRS had moved on from Hibernate 3.x, while the OT module still used the older version. We did the needful to move to newer Hibernate versions.

Thus went down the primary target. Here are some views from the module.

Next I started on performing workflow enhancements.


Workflow Enhancements

Workflow enhancement mostly focused on the data collection throughout a surgery’s life cycle. During the initial planning period, we had identified a set of data that would be useful for theater activities. These encompassed pre-theater, post and in-theater activities.

As for pre-theater data, our initial plan was to collect the following.

  1. Past surgeries
  2. Pre-theater prescriptions
  3. Allergies
  4. Fitness for surgery / physical condition

My first thought was to collect these data as free text. Let someone type them as notes for the surgical team. But it was later pointed out that we should ideally collect the data with concepts and observation groups. This made more sense, as it organized the collection of data and provided a way to query the information more readily via OpenMRS. In the long run, this would allow users to generate reports on theater activities.

I was warned that implementing data collection with obs groups may be tougher and would take longer. After discussing with my primary mentor, we decided to implement as much of the data collection as we can using concepts and obs groups.

In choosing the concepts for obs groups, @ball provided guidance and advised to use concepts already available, as this would make the code adhere to established standards, allowing collected data to be analyzed beyond just OpenMRS. She pointed me to CIEL, where past procedure data collection could be done with the following concepts:

  • Procedure History (Grouping concept)
    • Procedure performed.
    • Procedure date/time
    • Procedure comment.

The next problem was to ensure that these concepts would be available in the work environments where the module was deployed. Again, @ball provided examples of how this has been done in other implementations, and I added the concepts to the module activator.

The module activator checks if a deployment environment already has the procedure history concepts from CIEL, and adds them if not. Along with that, I added a new concept group for gathering surgery data across its workflow as below.

  • Procedure information (Grand-parent grouping concept)
    • Pre-theater drugs (parent grouping concept)
    • In-theater drugs
    • Post-theater drugs
    • Procedure History (same as before)

All three drug concepts are parent groups that facilitate adding drug prescriptions as observations of the surgery. So we’ve achieved collection of data with concepts and obs groups, thereby standardizing the data collection.
The point here is that this allows the data to be identified across systems, rather than being confined to OpenMRS. It’s better to use an international convention so that more people can make sense of the data without going through the hassle of another concept dictionary.

Here are some views that portray the data collection within the module. Oh and I’m not the most knowledgeable person on drug-related terms. Please do excuse if I’ve mixed up pills and tablets, or given a drug where you never do. :smile:

Pre-theater data:

Post-theater data

As for in-theater data, I felt that it’s best to add them to the post-operative form.