Extending a discussion started by @ibacherhere, the overwhelming consensus is to enhance OpenMRS’ modeling concerning medication management. The proposal entails introducing a new domain referred to as MedicationStatement. Initially, this will be implemented as a module in the early stages and subsequently migrated to the core. This approach offers the advantage of expedited code deployment and facilitates the adoption of this feature by downstream distributions.
I’m currently drafting the details of the modeling here. Feel free to contribute; I’ve left some comments and questions in the document.
Should we prioritize support for coded fields?
According to the FHIR specification, medication statements can originate from various sources such as the patient, a relative, or a referenced organization. When retroactively entering data, especially for a coded field like the drug, it’s possible for a patient to report historical usage of a drug that may not be defined within the configured drugs. How should we handle such scenarios? Would it be advisable to capture coded fields as arbitrary data points?
We have a well-established pattern of having certain fields that are CodedOrFreeText (the class name for the underlying implementation).
Also, modelling-wise, please make sure you actually look at how we already model drugs, etc. and especially the medication dispense stuff. Creating domains that don’t look like our existing domains will not make people want to reach for this feature. Oh, and if you’re going to add a note field, make it CLOB.
@grace does this fall within a platform conversation or O3 squad or TAC or ? Just wondering where we would see this discussed for a decision to be made.
@samuel34@ibacher Looking at the modeling, it’s not clear to me how a patient-reported medication would be stored within OpenMRS, or a medication that would be added from outside of the facility that might be pulled in from the SHR or patient transfer workflows (but not necessarily available as an available drug within the facility). How are we addressing that use case here?
Thanks for the pointer, @ibacher. With that being said, would it make sense to mark the following fields as CodedOrFreeText: drug, adherenceReason, and medicationReason? Would you remove or add any field(s)?
Additionally, can we overwhelmingly define codings for the fields: status, category, adherence, doseUnits, and route? Or this is something solved at the implementation level?
Fair point. The main objective of this post is to seek validation, answers, and opinions from everyone here and to reach a general consensus on the modeling. It would be very helpful to hear any objections regarding the modeling from everyone in this discussion.
This was my main concern and I asked a question related to this in my post above. From @ibacher’s response, we can solve this problem by treating such fields as CodedOrFreeText; meaning, we can capture an existing drug as a coded data point otherwise as free text.
I will start with a few questions in regards to some column names:
Is there a reason why you named the column information_provider instead of information_source to match with FHIR?
adherence instead of adherence_code?
category_id instead of category?
medication_reason_id instead of medication_reason?
The undocumented convention that i have seen is that, if you are not using an existing openmrs column name (e.g patient_id, encounter_id, drug_id, etc) then you default to the fhir name.
You make a fair point, @dkayiwa. The reasoning behind the variants in naming compared to the standard naming system in FHIR is the generalization of naming in FHIR to support most systems out there. So, I thought it would make sense to have more specific names, such as information_provider instead of information_source. According to the FHIR spec, this field can capture a person or organization that provided the information about the taking of this medication. With the modeling I came up with, this field has a Java class type of Person, hence it only captures individuals, which makes the naming information_provider more specific. I can however update the modelling to adopt fhir’s naming.
We almost certainly want to allow that field to contain free-text. FHIR-wise:
{
"informationSource": {
"display": "Eric, the patient's uncle"
}
}
Is perfectly valid FHIR (although merry ■■■■ for a mapping layer), but it’s also extremely likely that we don’t want to create a Person for everyone who might communicate this information; it’s one of the reasons that Relationship so frequently gets replaced with a Obs that capture free text about contacts.
That’s a reference to any resource, but it would be where in the FHIR schema we put that information. I’d suggest that when we’re mapping it, we have a 1 to N join on DrugOrders (since, presumably, refills should just update the existing entry).
Hey @janflowers after discussing w/ @ibacher and @samuel34 we think it would be helpful to discuss on the TAC call this week - but specifically we’d like to focus on the use cases more than the modelling, since that’s the biggest grey area right now.
We have handled drug start, stop, change, etc as events in KenyaEMR and this mostly applies to treatment regimens for HIV and TB. Our implementation uses grouped obs to document this i.e. which drug, program, start/end date, and reason for a change.
From this, one can quickly get answers to questions like the baseline regimen, regimen at 6/12/18 months, and related questions. In addition, we use this to restrict prescriptions of HIV and TB drugs to the active regimen and one has to explicitly update the events in case of any changes in the drugs.
Could this be a possible use case for consideration?
One of the prescription use cases that I did not see in the medication statement use cases is, during an encounter a clinician may want to prescribe a medicine that is not offered in the facility or that is out of stock and patient will need to get this elsewhere. Based on the fhir description of the resource A MedicationStatement may indicate that the patient may be taking the medication now or has taken the medication in the past or will be taking the medication in the future. For such prescriptons we may not know whether patient will actually buy and start using it, I was curiuos to know will we still be capturing this as medication statements and if yes might we need an addition status to just indicate it is unconfirmed. The additional request is we need to be able to print this prescription for a patient.
