A women’s health clinician in Haiti wants to enter a “drug” (using htmlform) for a common med (ie. Globugen). The med is not stocked in our pharmacy and the patients purchase them on their own.
Questions:
Should we use drugOrder? Or should this be an obs.value_text?
If drugOrder, should we use orders.concept_id of “Other (CIEL:5622)” and drug_order.drug_non_coded = “Globugen”?
The current htmlform tag for drugOrder doesn’t allow for this behavior although dosing can be free-text.
I think it should be the same as however the coded drugs are being stored, whether obs or drugOrder. I guess if this is the drugOrder tag, then we should make it deal with non-coded drugs correctly.
I guess in the latter case , assuming that we also dispensing at that facility, there’s the question of how we represent that the patient already has the drug. I’m not so sure about this. It seems like something of an unsolved problem in our data model—we track prescriptions and dispensations but not whether the patient is expected to get the drug elsewhere or whether they already have a stash. But maybe that latter information isn’t important; maybe “We prescribed X Y and Z and the patient got X and Y from the pharmacy” already implies “the patient must either already have Z or be getting it elsewhere.” Maybe @jteich is the right person to ask about this? Or @akanter ?
In Bahmni, and in a few US EHRs I’ve worked on, we structured this somewhat differently. The primary workflow for the clinician is to enter that Globugen is in the patient’s medication list – that includes drug (we can talk about strength and form later), dose, frequency, duration if there is one, PRN information if there is any. Then there’s a checkbox (default ‘on’) enabling an additional section if the clinician is actually ordering the drug – that includes amount prescribed, # of refills. So, both drugs that are prescribed and drugs that are purchased on the outside are included together in the same list, which is appropriate for most clinical purposes. I don’t know what specific data class is used; it was always referred to as ‘medication’.
Regarding non-coded drugs / drugs not found in the formulary search – if the drug was found in the search, the drug code was retrieved with it. If not, then the free-text drug name was accepted, and I imagine that some sort of ‘other drug’ code, or a blank or negated ‘code’ field, would be appropriate.
No, the orders.concept_id should be the concept for “Globugen”. If there are no specific formulations for this that clinicians should order, then they can specify the formulation as drug_order.drug_non_coded, if there is, then they can specify it as drug_orders.drug.
I would think this is independent of the order. This seems related to dispensing / fulfillment of the order.
The htmlform tag for drugOrder does allow for the various combinations of order.concept_id, drug_order.drug_id, and drug_order.drug_non_coded. Not sure what aspect is perceived to be missing, but perhaps something needs to be better documented.
@mseaton the issue was that @ball added an “orderProperty” of “drugNonCoded” on a form, but no corresponding widget was being rendered for it:
I noticed on the form there was no “orderProperty” for “concept” so I added this and after adding this the non-coded text box for “drugNonCoded” appeared (along with the concept selector). I didn’t look at the code, but I assumed it was intentional to make “concept” orderProperty required with “drugNonCoded” orderProperty, as otherwise there’s no way to determine the concept_id to associate with an order.
One behavior would be to allow “drugNonCoded” without “concept”, and then behind-the-scenes store "orders.concept_id of “Other (CIEL:5622)”, but we were guessing that might be frowned upon. We can ticket adding support for that to the widget if people think it’s a good idea.
I think the underlying issue we want to keep the form simple for the 95% use case when users are just selecting a drug from drug list, and adding the full concept widget seemed confusing. Another option would be to have both a “concept” and a “drug” order property but have them restricted to non-overlapping sets, but I’m not sure if that’s possible or advisable.That is:
The “drug” search-box/dropdown would display the list of drugs we have full formularies for
The “concept” search-box/dropdown would be limited to to the 6-8 “other” drugs we don’t have formularies.
Selection of the two fields would be mutually exclusive
As I’m thinking through this now, I’m thinking it might be possible to configure two different widgets to achieve this objective… but it might be confusing to the user to figure out which one to us.
Hope that made some sense… I haven’t played around with this too much but can look into it some more.
@jteich For the explanation you provided (ie. adding Globugen), should this be a drug order – even though it’s not for the facility pharmacy to dispense?
Like all of the other properties that can be set, some of which might be required but which we often want to set to a fixed default value, the intended way to do this is to add the orderProperty tag with a single option that is set as the default value, and then to hide this with css.
In any event, I’m still unclear why you would use drugNonCoded for this? Isn’t “Globulin” the orderable that should be associated with the concept attached to the drug order?
We can add “Globugen” concept, but what do clinical staff enter if there is no drug/concept for the drug xyz?
The other issue is that the clinician is aware that the patient will supply their own medication from home (or a place other than the same health facility). That’s why I wondered if it should be a “drugOrder”. Would it be tracked internally as an order that’s never complete and confusing for the pharmacist and reports?
@ball I don’t think it should be an order. Unlike an ordered drug, it’s not an appropriate object to refill, to specify dispensing amount, to send to the pharmacy, etc. As you said, if treated as an order, it could clutter and confuse the pharmacy queue.
As noted above, the primary workflow of the medications section is to enter and edit the meds that a patient is taking. Ordered drugs are a subset of that list with some special properties.
(PS None of this applies to inpatient care, where essentially every med is dispensed by the pharmacy)
Do we have examples of OpenMRS systems in production that do this well? Are any of the patient medication user interfaces that have been built or are designed and planned done in a way that captures both ordered medications and observational data about “other medications that the pharmacy doesn’t fill”? I think entering and viewing this data in the context of a single encounter is likely straightforward if that’s what the implementation wants to do, but I imagine that once someone wants to see all of the medications for a patient on a dashboard or a report that none of our existing systems are designed to handle this distinction well.
I certainly defer to @jteich expertise on EMR order entry, but it feels odd to me to have a different clinical workflow / entry mechanism based on where the patient will pick up the medications, whether at the clinic or not. Wouldn’t it be better to just let clinicians order meds, and then let the dispensing / pharmacy system determine whether those meds are stocked or not and how to handle fulfillment?
Right, so in this case we need to have a Concept in our orderables list for “Non-coded drug”, which when chosen would allow free-text entry for the drugNonCoded orderProperty.
In a perfect world, “NON-CODED DRUG” would never be needed because all drugs would be known by the system. In reality, new drugs and drugs from outside facilities are likely to be encountered on occasion by OpenMRS users (real drugs for which a concept doesn’t exist), so we need a mechanism to support them.
It’s important to remember non-coded drugs can be dangerous. You lose the ability to check drug interactions, accidental drug duplication, dosing ranges, etc. Granted, we don’t have a lot of these safety features built into OpenMRS yet, but they will come and will be powerless to help with non-coded drugs.
So, use of non-coded drugs should be discouraged & avoided as much as possible.
Unlike non-coded observations (i.e., a question on a form being answered with free text), non-coded orders deserve some special treatment, like showing in lists as the name entered in quotes.
Instead of displaying this…
Displaying something like this…
ampicillin lisinopril Drug, non-coded Truvada
ampicillin lisinopril “semaglutide” Truvada
As @jteich points out, there’s a distinction between prescribing a medication and recording a patient-reported medication. But, whether or not an drug is known the system or not (requiring use of “Drug, non-coded”) could be independent of whether or not you want to generate a prescription. I would favor an approach that is easy for users (avoids separate interfaces) but allows for patient-reported drugs to be recorded:
When choosing the drug, the user has an option when they can’t find the drug to enter the name themselves (for patient safety, both the doctor and we should die a little inside whenever we are forced to do this).
Provide an option to bypass the quantity to dispense, refills, etc. by indicating it’s a patient-reporting medication (via checkbox or whatever) for the exceptional cases where you just want to add the entry to the med list without generating a prescription.
I could be mistaken, but my interpretation of what @ball was asking about was not “patient-reported medications”, but about prescribed medications that are just not in the formulary / dispensed at the clinic, but which are expected to be picked up at non-clinic location. And the question was should these be orders if there is no downstream order fulfillment in the EMR. Is that right @ball ?
Correct. I agree. There are certainly environments where order fulfillment does not occur within the EMR, whether scripts are printed or sent electronically to an external system.
Sorry for the confusion. I wanted to point out skipping dispensing information (that @jteich mentioned) applies to patient-reported meds or cases of med reconciliation where you want to add an entry to the med list without prescribing, which is independent from the use of “Drug. non-coded.”
Bahmni did a good job, at least when I was working with them a few years ago.
I had thought @ball was in fact referring to drugs the patient takes on their own or gets from some other guidance besides this prescriber; medically that’s not really an order. If the clinician is specifying the dispensing of the medication (perhaps by issuing a printed or hand-written prescription), that’s an order.
But if we wish we can keep the data structures and processes together, which is how I’ve always seen it done before: a single workflow for adding/editing the patient’s meds in the patient’s med list, and then the separate checkbox-controlled section for prescribing info (dispense, refills, whether there’s a printed prescription, whether it goes to a pharmacy electronically…). The provider should be able to understand the distinction pretty easily, and so the provider can handle all meds in one workflow.
Technically, if the patient is taking their own drug I can’t really issue a refill later on – that’s the main practical distinction for ordered and non-ordered ambulatory meds.
Right, these are separate problems.
I think that will always happen because the pharmacy will not catch up to all available meds quickly enough, so you need the ‘non-coded drug’ concept plus the med name, and it should be shown in the UI as the med name, as @burke illustrates.
For the most rigorous implementation, it’s possible to keep a record of those med-list entries (or “orders”) in an archive that gets reviewed periodically, so the drugs can be re-named with concept IDs as the formulary catches up. In practice, I don’t think people keep track of that conscientiously enough.
I haven’t played around with this too much but can look into it some more.