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.


Published by