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. 

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.

Adding a surgery note above would save the current surgery as a past procedure of this patient. Less hassle for the data operator.

Code Contributions

Please find my contributions at the project repo. Here are some important milestones:

• Fully replaced Joda Time library.
• Migrated to Optaplanner 7.0 from 6.0.
• Pre-theater data collection
  • Pre-theater data form
  • Past procedures and allergies
• Concept definitions in Module Activator
• Post-theater data collection
  • In, post-theater drugs and surgery note
• Create concepts when adding a new procedure
• Tests

Documentation

I’ve added documentation of the module in the OpenMRS wiki under Operation Theater Module. I’ve added demonstration videos for the workflows there as well.

Future Work

The scope of the data collected throughout a surgery is limited to drugs, allergies, and past procedures at this time. We can certainly work on adding more to this list. The tests written by the previous student are mostly invalid at this point, so we need to change them accordingly.

Furthermore, the planning engine can use some more fine-tuning. If I get the chance, I’d like to rewrite it completely.

Experience, Knowledge Gained

The insight into how data are gathered in an electronic medical record management system has been quite enlightening. For example, the idea of concepts and observation groups just jumps over many issues I’ve had in my personal projects where I had to fix the possible data collections in the design phase, which historically resulted in heavily coupled code and low flexibility.

Next up, time. Dealing with time is always a messy business. Replacing an entire time library with two others was quite a tedious task, especially without the intricate knowledge of timelines and other related concepts of time buried deep in programming. And it’s definitely not a good idea to learn them from someone else’s work. I believe I’ve just scratched the surface on this front.

Final words

The community has been quite supportive throughout this time, and I’d like to say thank you all! Plus, we should definitely add more documentation for the resources available – like the UI Commons library.

And a special thank you to @akshika47 for always checking on my work and motivating me to do my best. @harsha89 and @ball, thank you for your support throughout.

It’s been a privilege working with the OpenMRS community, and I hope to be part of it in the future as well. Thank you for a summer well spent