GSoC 2017 – Week 9

In-theater workflow enhancements includes collecting various data during the surgery is being performed.  My original plan was to have a simple page that would show a timer and allow users to add various data as the surgery continues.

But later I realized that it’s not practical to have someone typing at a computer during a surgery. Silly me. The better approach, I think, is to let the data be recorded after the surgery is performed – add it to the post-operative data.

This is the case with one of the existing implementations that I saw. They have a post-ops form with fields to enter fluids administered during the procedure, specimens collected and such.

I made a similar form for our use case. Since OpenMRS has concepts for most drugs and observations, those are used within the form to store the collected data within an obs group called In-theater drugs.

Towards the latter part of the week, I learned that I should ideally use existing concepts for storing data. There are various standard collections of concepts that define medical concepts internationally. One of them is CIEL – Columbia International eHealth Lab Concept dictionary.

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. So I’m changing the current concept definitions to match those in CIEL concept dictionary.

Another thing I wanted to know last week was how to add these concept definitions to a startup script of the module. When the module is deployed in a new instance of OpenMRS, we need to make sure that it has the basic set of concept definitions to continue its work. This is best done in some sort of initializer.

I asked the community about this and they suggested 2 methods – either to have a metadata module that sets up the relevant data, or to have it all in a file called the module activator. I decided that it’s better to have the code in one place rather than having a separate metadata module, as the amount of metadata is low at this point.

And we had our second evaluations. We made a small video about our current progress and posted in the community for feedback.

GSoC 2017 – Week 6

It’s the end of the 6th week and I’m happy to bring some UI to the mix. Up until now we’ve been working with the stuff that was made before. But now it’s time for new enhancements. The first part of it is enhancing the pre-theater workflow.

Along that line, we discussed what data need to be collected before a procedure, last week. I asked the community what they considered necessary, while making my own suggestions. Just as expected, there are already some implementations of data collection of a surgery.

One example was a post-op form used by a Partners In Health member. She provided screenshots of the form which they used to collect data about the procedure after it took place. It included fields to record the surgical team involved, the location of the procedure, anesthetics, complications etc. They were not collecting any data before the procedure, so they used the same form to record pre-operative diagnoses as well.

The PIH lady was kind enough to provide advice on implementing the forms as well. She gave a rough idea on how I might want to configure the provider types with metadata, and may consider adding a separate role such as surgery scheduler to assign the tasks related to theater activities.

Going by the screenshots she provided, and the data I originally proposed to collect, I came up with the following page for pre-theater data collection.


These are more like preliminary sketches, to get the feedback of the community. I’ll finalize them and connect the database next.

GSoC 2017 – Week 3

This week I was mostly working in checking the functionality of the system, looking at UI elements, following method calls related to surgery CRUD operations etc.

I found a few cases where a surgery validation failed when trying to enter a  emergency procedure. The problem was that the surgery associated with the emergency procedure was not properly initialized, which caused it to fail validation. A few breakpoints with IntelliJ IDEA helped to solve that. Special thanks to Gayan Weerakutti for helping me to setup debugging.

Then there were some UI elements that didn’t appear properly. Checked through files and came across a set of JSON files that were apparently used for configuring the UI, but I couldn’t understand exactly how they interacted with the other files. They aren’t imported anywhere. I’m guessing the OpenMRS classloader is specially configured to look at the path they exist and read them if they’re there.

I’ll update this post with more info in a bit.