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”.
This link is to a really very good review of many issues related to how a medication list should be displayed. With regard to recording medications that were prescribed elsewhere there could be a checkbox that could be used to indicate that this was an external prescription and that not all the usual details may not be available.
I’ve been following this very interesting and informative thread on medication lists.
I’m curious to know if anything has been finalized, implemented, or is currently in progress,
I have some questions and scenarios I’d like to discuss, especially in cases involving comorbid illnesses.
Scenario 1:
A patient has an active condition and is consulting a specialist doctor who doesn’t use an EMR system. The patient then visits another specialist for a different complication; this second doctor uses OpenMRS. How should the second doctor capture the medications prescribed by the first doctor? This is important to avoid:
Double prescribing common medicines or painkillers.
Prescribing medications that might aggravate the patient’s other conditions.
CDSS
Scenario 2:
Both doctors are using EMR systems that are interoperable through FHIR. With patient consent to view the other doctor’s prescriptions for comorbid conditions:
How would this information be fetched or displayed in OpenMRS 3.0?
How would the Clinical Decision Support System (CDSS) work in this context?
Can the current doctor will be allowed to adjust any dosages for medications related to comrbidity illness?
Are there any reference documents or guidelines on how this would work within OpenMRS?
With the current implementation, anyone using an EMR system it is possible to capture active medications, and users can discontinue or modify these active entries. Discontinued and modified medications move to the past medications section once they hit the the expiry or endDate, while the new version of a modified medication appears in the active medications list.
One thing that is not being implemented and the ticket is already in place is to directly add the past medication on the past medication list. I was and am still willing to fix it though the discussion is still ongoing. This is the ticket am refering to Jira.
Thanks @jwnasambu , i was looking more from comorbidity illness and treatment already going with other doctor.
So still looking if someone could shed some light
Also i am looking if we could add Drug form as well while ordering drugs
like Tab/Cap/Syr/Crm, is it possible to have additional filed?
Another specific thing, not sure , how to handle this
Prescribing same medicine with different strength , generally when Provider try to increase the dose.
for example
Sertraline 25 mg , starting today for one week
Sertraline 50 mg , starting after one week and duration 2 weeks.
I see that we can prescribe same medicine with different strength but we cant choose start date in future. any particular reason of not allowing to select start date in future?
Patients should ideally have one medication list and each independent system (ideally, working together) strives to represent that list as faithfully as possible. If data about active medications are obtained from another system, then they would be incorporated in the patient’s medication list (ideally through a medication reconciliation process to reduce duplicates/errors). Coordination of medications across doctors/specialties is a social contract, not a technical one, meaning any provider with prescribing privileges should be able to edit any medication (it’s up to the provider to decide when it’s appropriate vs. inappropriate).
Having a technical way to distinguish patient-reported medications from prescribed medications would be nice to have.
Drug forms are part of the drug formulation; the drug being ordered and not a separate property of the prescription. In other words, you order “foocillin tablet” and then specify dose, instructions, etc.; you do not order “foocillin” and then decide on tablet vs. syrup in the prescription.
Our design to constrain prescriptions to one per drug was based on an earlier system and done for safety purposes. In the future, we will probably want to relax this constraint (allowing multiple orders of the same drug), but – for safety of patients – will need to ensure the system properly recognizes and handles these cases to avoid putting patients in harm’s way.
