During the 7th week, I got feedback on the mock-ups for pre-theater data collection. Just as I suspected, letting the user simply note data as free text was not the best idea.
Although a simple note might be useful in communicating the patient history, it’s not usable for analytical purposes. I mean, a text paragraph is not granular enough to analyze trends in patient history and can’t be used to generate reports. We need to organize the data collection such that they can be analyzed in the future. This means breaking it down into contextual chunks. Then structuring the DB to store them allowing easy querying.
My first idea about implementing this was a little complex. I thought about making 3 tables – tags, surgeries and surgery_tags. The tags table would denote the past surgeries. Surgeries would store the master entity. The surgery_tags table would add multiple entries with past surgery data before doing a new surgery.
But then I was directed towards Obs Groups and the OpenMRS Concepts Dictionary. Those two blew my mind. Literally.
Let’s start with the concepts dictionary. It defines the medical concepts that are used within a particular implementation of OpenMRS. As many institutions use OpenMRS around the world, they add the concepts they use into their instance. To quote the docs,
the concept is the basic element of flexibility in OpenMRS. Concepts are the individual data points collected from a population of patients. Concepts include both questions and answers.
For example, blood type data is collected for a patient. The question is “What is the blood type for the patient?”, with a set of discrete answers of “A, B, AB or O”. To implement this in OpenMRS with concepts, the question is a concept (“blood type“) and each response (“A“, “B“, “AB” and “O“) is also a concept. For this one question, a total of 5 concepts are required.
Here are the docs, it’s an interesting approach that allows future modifications to the data collected within the server. This works in tandem with Obs, or observations.
An observation is anything that is actively measured or observed during an encounter (-> a patient’s interaction with the doctor). This could be the white blood cell count of a patient. Or the mode of transportation to the hospital.
Logical groupings of observations are called Obs Groups. For example, there may be an obs group called “TRAVEL TO CLINIC”, which may include the member observations “MODE_OF_TRANSPORTATION”, “DISTANCE_TRAVELED”, “TIME_SPENT_TRAVELING” and such. You can read the docs here to get a better idea about it.
So in our particular case, we’d need to register an obs group called past surgeries, as this would be an observation made during an encounter before scheduling the surgery. Then, the date of the past surgery, its name and diagnosis would be member observations. These would be recorded as concept entries within the DB.
This will take some time to implement, and we’re supposed to be done with the pre-theater workflow enhancements in a week. I discussed with my mentor and we’ll implement as much as we can during the available time.
Another thing I noticed is that we can’t view the details of a surgery once we finish entering its details the first time. There’s no way to view a single surgery and info about it. We get a summary page of the surgery when we finish creating it, but you can never get back to it once you exit from there. So I connected that page to the overall surgeries page so that we can click on a particular surgery and view details of it at a later point. Such a simple thing, I’m not sure how this was not discovered before.
And that’s all for this week, folks. I’m sorry that I’m late to post this (hell, I got asked why I’m late). Work, you know how it is during the intern period.
Until later, then. Ciao.