Can we implement freeText DrugOrders?


Wanted your thoughts on the idea of freeText DrugOrders i.e. to allow doctors to prescribe drugs that are not yet added to dictionary. Is this something that can be allowed?


In general this is strongly discouraged because it becomes impossible to do any of the things one would like to do around orders (allergy checks, triggering messages to downstream systems, etc).

I guess it’s possible to have an order for an “Other, Non-Coded” concept and define the specific drug in the instructions text field (though perhaps this isn’t sufficient because duplicate-checking might prevent two drug orders with the same concept, and drug=null).

Is this really a use case? In my experience it is usually possible to get people to define the full formulary of orderable drugs ahead of time.

In one national rollout, the drug list is controlled via the terminology registry. But it seems that the registry would be able to keep up only with the drugs which are provided by the government. Doctors 50% of the time have to prescribe medicine which are outside the in-facility pharmacy. The drugs (brands) available change far too frequently for someone to be able put them in the terminology registry - at the country scale. We suggested that doctors put the name of actual brand in additional instructions, but given that 50% medicine belong to this category, it would results in a lot double entry to be done by them - per drug order.

Do they order by brand as opposed to ordering the generic?

@burke, @jteich, please note this topic.

We are really trying to get to a full drug dictionary with a formulary overlay for specific preferred drugs, but we (CIEL) have not fully populated something…

They order brand because that should go in the prescription printout they would get. They don’t want the pharmacy (which is essentially a shop for medicine without qualified pharmacist) to decide which brand to give.

Interesting usage, compared to the US where it is increasingly frowned upon to specify a brand for any drug (but still possible, and important in a few circumstances). Obviously a much different situation here.

It should be permitted to order a drug by a brand-name. If the appropriate generic concept exists and has been mapped to that name in its list of synonyms or brand names, then the order goes in with the concept matching the basic concept, but with the brand name appearing alongside the generic name on the prescription.

If the name is not found in the dictionary, then the software could first encourage the provider to look for the generic name if known; in that case, the brand-name can be added to the name on the prescription or included in the instructions.

If the appropriate generic drug concept is not in the dictionary, or if the provider does not know the relevant generic name, then it probably has to be treated as an unknown drug (until that mapping someday comes to exist in the dictionary). See next paragraph for one way to handle this.

It is also possible, and infrequently happens, that you want to order a drug that simply isn’t available (the concept doesn’t exist) in your drug set. Functionally that works out the same as the use case in the previous paragraph, You don’t want to make this order impossible if the doctor really wants to order it. Standard approach is to make it a medication order, so that the dose and other fields can be completed and so that it routes to medication administration and pharmacy. The drug name is entered as free text, and can be assigned to an “other drug” concept or whatever is most convenient in the software. In our hospital, these are reviewed every few days; most of them turn out to be misspellings, but a few represent new drugs that need to be added to the formulary.

At Regenstrief, we have a handful of concepts dedicated for cases where a drug is not defined – e.g.,

  • Drug Other 1
  • Drug Other 2
  • …
  • Controlled Drug Other 1
  • Controlled Drug Other 2
  • …

We use an “specific name” attribute to hold the drug’s name. These are used in a small set of cases where a new drug hasn’t been defined yet or someone is trying to work around a constraint for some other (valid) reason.

When displaying these in the UI, we place the name in quotes. So, you could see a drug list like:

  • ampicillin
  • “foocillin”
  • metformin

Pretty much in agreement with what the Brigham does. Like you, we make it a little inconvenient to do this (try the concept search anyway, give you a challenge to verify that you want to enter free text) to discourage people, but do make it possible.

So, to summarize from today’s design call where we chatted about this by voice:

  • real-world systems do need to allow you to prescribe outside of the list of coded drugs
  • we are in favor of a change to the underlying API to add something like “String drugNonCoded” to DrugOrder.
  • “Concept concept” in Order would still be required, so we’d need to introduce a magic value for “Other non-coded drug” that the API knows about
  • the existing API logic around preventing duplicate drug orders for the same orderable would need to be fixed to be aware of this new field.
  • this change needs to be in OpenMRS Platform 1.12, which we’ve already said is okay to do as a release of “additional fixes for order entry”. (Or else it could go in OpenMRS Platform 2.0)
  • at the UI level, the strong recommendation is to make it a bit hard to access this functionality (e.g. require extra clicks), because you really want most ordering to happen from the coded list.

So you will need a new concept created “Other non-coded drug”

I don’t have an opinion myself about whether a generic “Other non-coded” (5622) concept is sufficient to reuse for this purpose, or whether CIEL needs a specific “Other drug, non-coded” concept.

The API should have something like OrderService.getNonCodedDrugConcept() which can be configured by the implementation to return its appropriate concept.

Anecdotally, we ended up with two at Regenstrief:

  • Drug Order Other
  • Controlled Drug Order Other

This was driven by the difference in handling of controlled substances in the U.S. (e.g., controlled drugs cannot have refills, cannot have electronic signature, etc.), so the concept could be used to discriminate between which form/script behavior is needed. We could probably get along fine with a single concept for OpenMRS, but I wouldn’t be surprised if we ended up needing another in the future.

Also, we use “Drug Order Other” at Regenstrief, because users use this (i.e., search for it by name) to order an undefined drug. One of the main reasons for this approach is to support a single order field (i.e., a generic order field that searches across all orderables, including drugs, tests, referral, etc.). While our UI provides a way to filter to specific order types (just search drugs), it is rarely if ever used, since a decent search algorithm can get you to the order you want with a few letters, obviating the need to make users navigate through multiple search fields.

Can this be back ported to 1.11? Bahmni just switched to this version.

Hi Shruthi,

We would typically not backport this to openmrs-core 1.11.x, as this is a new feature + data model change, and API consumers would not expect to see this happen midway through a release branch.

Burke and I have discussed things, and we have the green light to do a “special” openmrs-core 1.12.x release line, which would be branched off of 1.11.x (rather than master, which will become 2.0). In 1.12.x we would ideally make data model changes and new features related to improvements to order entry. And this change seems very appropriate for that.

Basically that means the the “philosophy” of the recent and upcoming release branches would be:

1.9.x … lots of new features 1.10.x … 1.9.x + new order entry 1.11.x … new features 1.12.x … 1.11.x + new order entry 2.0 … new features, remove deprecated things

Thanks Darius.

We plan to start work on this in a day or two. We’ll create a branch for 1.12 as you suggested and implement this there.

Curious though, when can we actually release this branch? Can you give us some details about the other changes that will be implemented on this branch?


So for the drugs ordered through free text how do we address the following challenges

  1. Duplicate Orders - How do we manage the duplicate orders, like entering the drugs with the same name twice.

  2. Schedule Overlaps - How do we control the schedule of the drugs ordered through free text with other saved (concept) drug orders.

  3. Re-Ordering (Refill of the drug) - We in Bahmni have a function which refills the drug in drug order for saved drugs. So, how do we refill the drugs ordered through free text.

Any thoughts or suggestions around it ?

This work either needs to be done in 2.0 and backported or done in a 1.12 branch (off of 1.11.x) and forward-ported to master. Please coordinate with @maany.

1 Like

Order uniqueness should include the name of the drug for non-coded drug orders, using case-insensitive comparison. So, for example, the API should disallow a new drug order for “foocillin” (non-coded) if there is an existing, overlapping order for “FOOCILLIN” for the patient. Basically, when the drug is non-coded, the free text name should be used in place of the drug_id when checking for uniqueness.

Same as above. Drug orders are considered equal if (1) drug ID is equal or (2) for non-coded drugs the free text names are equal (ignoring case). I’m assuming all free text names are trimmed (leading, trailing, and consecutive whitespace removed) as they are set.

Refilling a non-coded drug order should behave identically to refilling a coded drug order. In other words, a coded drug order uses its drug_id to specify the drug formulation and a non-coded drug order uses it’s drug_noncoded to specify the formulation; otherwise, they should behave the same.


About duplicate orders, the way I would approach this is to say that there is already an existing algorithm there, and the only thing that should change is that when a free-text drug is specified instead of a coded one, you use the free-text value in place of the coded value in the existing algorithm.

For the other two questions, are you asking this at a UI level or an underlying API level? At the API level, as Burke says, nothing should behave differently for these types of orders.