Currently, in OpenMRS, as far as I know, we don’t really have a solid data domain to handle medication lists, that is the list of currently active and historical medication a patient has been on, their dosage, and treatment indication.
We do have a widget in O3 that sort of offers this functionality (the patient chart “Medications” view), but this is basically just a wrapper around medication orders, so something is on the active medications list if it is ordered for the patient and it’s on the past medications list when the order has expired or been cancelled. Medications are added to that list by creating an order for them, and removed from that list via a discontinuation order.
The problem here is that not all medications that a patient is being given are being prescribed in the clinic in which they might be treated, so it’s inappropriate to add an “order” for those medications. Similarly, there is no way to record the fact that a patient has been prescribed medications, but is not, in fact, actively taking them. Even in cases where all of a patients active drugs might be ordered via the current clinic or system, we have no way of recording previous drugs the patient had been on before they entered care. Basically, all of this seems to indicate that we have a need for a separate data model to be able to hold a patients medication list.
Are there any solutions in implementations out there to address these sort of issues? Or is this kept as either notes or part of a paper chart instead of the electronic record?
How about starting with an Obs Group to capture these past medications, their dosages and treatment indication? Then after monitoring the adoption of this functionality by various implementations, we can later on migrate them to a dedicated domain model, just like we did for allergies, conditions, and diagnoses.
The advantage of this approach is that it does not require platform upgrades for existing implementations, and the data can be captured using existing forms functionality.
We currently have a medication history concept which groups together historical prescriptions… and a separate current medication order concept… I’d love to rationalize this in the context of an actual medication list object.
Thanks @ibacher for starting the conversation here. I definitely think we need to make sure we have a “meds list” for both prescribed meds, and for meds/supplements that a care team wants to capture beyond those ordered within that EMR (or in that health system). I’d love to figure out how to do this in a way that doesn’t box us in to a funny way of doing this, that we’ll regret in the long run - and that makes it difficult for others to deal with in HIEs with FHIR, or in difficult upgrading over time with us as we decide to correct the way we have it initially. That said, I don’t really know what I don’t know, so take my comments here as fairly high-level view and general. Tagging some of my team because we’ll need this for our implementations and O3 work over time.
My only real issue with an ObsGroup is that medication data is more like a problem list, i.e., it’s not just past medications, but also current medications, and things need to be added or removed from the list (or at least marked as inactive) as they happen. I think the transition from using an obs-based problem list to condition domain was kind of painful, and I wouldn’t want to set us up for re-living that process unless this really is the best way to approach it.
The medication history concept does seem to have most of the data elements I’d expect. I’m not quite sure what to do with current medication order concept.
How about creating a new data model for this in a module, but with table and package names which will automatically end up in core without any modification? The module would help us to easily iterate on this with more flexible release cycles, and will not require platform upgrades by implementations. Later on, after it has become stable, we migrate it to core.
@dkayiwa I like this idea conceptually! It seems like a small enough project (hey, I’m optimistic by nature!). Could you outline what technical steps need to take place to get us to that? UW might be able to work with you and others as a quick feature squad?
Partners In Health has hit this issue several times and discussed this same issue just last week for Liberia. These are our use cases:
For Women’s Health in Haiti, the clinicians want to record patient using common meds like Globugen in the EMR although they are not stocked in our hospital pharmacy. Patients purchase them on their own. These are not “drug orders” in OpenMRS. This was discussed by this Talk thread
For NCD in Liberia, the NCD intake form records the medication that the patient reports they have taken (or using now). This is also not a “drug order”. The medication name is free-text. We use the [CIEL:160741] obsgroup (https://app.openconceptlab.org/#/orgs/CIEL/sources/CIEL/concepts/160741/)
I agree with aligning ourselves with FHIR – i.e., introducing MedicationStatement, while evolving our base orders + drug order extension to align with MedicationRequest.
I wouldn’t look at MedicationStatement as another medication list (e.g., the patient’s medication list); rather, as another source of information to generate the patient’s medication list. While we need to manage separate lists (discriminating using care setting) to independently manage medication orders in different contexts (outpatient, inpatient, ED, etc.) while facilitating reconciliation of meds as patients transition between contexts, for any given context, we want to strive for presenting “one” medication list. So, for example, while a patient-reported medication might get stored as a medication statement, we’d want to make this information available within a single medication list (avoid asking providers to manage medication information across multiple lists).
The MedicationStatement documentation implies it can be used to record “patient reports as being not taking”… but, with a cursory review, I didn’t see how MedicationStatement would be used to state a negative (i.e., “my medication orders – aka prescriptions – say I should be taking metoprolol, but I am not taking it because it makes me feel funny.”). Presumably, in this case, there would be an order for metoprolol along with a statement (stored separately) refuting its usage and we would show this to providers within a single medication list by decorating the metoprolol entry with something like “patient not taking”) with an easy way to dismiss (override/end) the statement or remove the medication from the list.
So, perhaps introducing a new drug_statement table to begin introducing MedicationStatement into our model?
MedicationStatement.adherence, specifically using this ValueSet.
In an HIE scenario, we probably do have multiple MedicationStatements to worry about, but I would think that the EMR’s produced MedicationStatement would be a reconciled list of medications drawn from the list of orders, consultation with the patient and, potentially, MedicationStatement(s) from a SHR. That would get us closer to the goal of being able to produce “an IPS”.
