GSoC 2017 – Operation Theater Module Workflow Enhancements

This is the official blog for my Google Summer of Code 2017 project. I am going to be working for OpenMRS, an open source project that supports healthcare delivery around the world. It feels great to have been awarded this opportunity, thank you @Team OpenMRS! 😁

My project is to work on the Operation theater module, which has been made as part of GSoC 2014. It’s used to schedule surgeries and other operation theater activities in multiple theaters. The module was written for an older OpenMRS version, so my first task is to migrate it to the latest platform.

The next steps would be to make enhancements to the workflow. There are 3 stages in any operation theater activity – pre-theater, in-theater and post-theater. The enhancements will focus on the data collection procedures during the entire workflow of an activity.

Coding officially kicks off on the 30th of May. It’s the community bonding period right now, so I’m using this time to learn more about OpenMRS. It’s a wonderful community with people willing to help and share knowledge.

After discussions with my mentor, we decided to start early. So here I’ll be posting on my progress.

Setting Up the Dev Environment

OpenMRS has a nifty tool for working on their projects – the OpenMRS SDK. It allows you to run multiple instances of OpenMRS at the same time. Hence you can easily test something on different OpenMRS versions concurrently.

The original OT module had been written for platform version 1.9.7, and the current version is 2.0.5. I used the SDK to set up the OpenMRS Reference Application 2.6, which is built on that platform and has a slew of modules bundled with it. The idea is to migrate the OT module to the latest stable release first, then provide backward compatibility if and where necessary.

I use IntelliJ IDEA as the IDE as it has great documentation and support both within the OpenMRS community and outside.

Work so far

When submitting the proposal, I had identified database changes as a key point of consideration when migrating the module. So I decided to start with that.

Out of sheer curiosity, I first tried changing just the target platform version of the module and building against that. The module got compiled successfully, but failed some tests written for the older platform. Then I skipped the tests, and imported the built module to the Ref App via the web interface. Just for the kick of it. Well, the error logs weren’t pretty. But they taught me where to look.

Specifically, they taught me that the changes of Hibernate were causing trouble. The OT module was built for Hibernate 3.x, while OpenMRS currently uses Hibernate 4.x. SessionFactory was now used in place of DbSessionFactory.

The next step was changing the module dependencies to the ones included in the latest Reference Application. Reporting, ID Generation and many other modules had come a long way forward from their older versions used in the OT module.

Then I tried building the module again. It wasn’t going to be that easy of course. Tests failed, so I skipped them again. Imported the module again, but as expected, the module couldn’t start. Database errors were all over the place.

I perused the error logs and it seemed the bean definitions in the module application context were causing the errors. Looking into the file, the errors were caused by a set of beans defined for the Appointment Scheduling module, as it apparently didn’t have its own bean definitions at that time. The current version probably does.

So I commented off those beans, and rebuilt the module. Imported the module  to the Ref App and voila! The module started! 😁

Right now the Operation theater module correctly appears in the UI, with scheduling and other functionality. Next step is to verify that it works properly, going through each action one by one. There’ll be lots of errors, lots of bug hunts. I can already feel the thrill of the hunt. Or the dread, you choose.

Next Steps

So yeah, we’re making progress. I plan to use the tests written before to identify the API calls and learn what has changed. The other option is to read the logs when errors come up.

So much to look forward to.

I’ll be sure to keep you updated.

See ya.