I’ve been working on an improvement to how drugs are selected in the order basket and would like to get feedback from the community.
What’s the problem? Based on feedback and observations from real‑world clinical workflows, clinicians often prescribe from a known subset of medications depending on their context. For example, in a maternity ward, only a specific group of drugs is typically relevant. Relying solely on free‑text search across the full drug catalog can be inefficient and may increase the risk of selecting an incorrect medication. Providing predefined, context‑aware medication lists that can be selected directly can simplify prescribing and improve usability.
What’s the solution? The proposed approach builds on Concept Sets, which are managed via Legacy Admin and can be used to group drugs into flexible categories. These categories can reflect local needs such as service types, formularies, or workflows.
On the UI side, a new List tab has been added alongside the existing Search (which remains unchanged and is still the default):
The Search continues to support free‑text drug search.
The List tab allows clinicians to browse drugs by selecting one of the configured categories.
Which categories appear in the List tab is controlled via Implementer Tools, by specifying the relevant Concept Set UUIDs in the application configuration. This allows implementations to enable and evolve medication lists incrementally, as needed.
How does it look in practice? Below is a short video demonstrating the feature. The only precondition is that the relevant Concept Sets are configured.
A pull request is already in place implementing this functionality. Before deciding whether this should be enabled by default or introduced behind a feature flag, I’d appreciate feedback from the community.
In particular:
Does this approach reflect common clinical workflows in your implementations?
Should this be feature‑flagged initially?
Are there alternative approaches you’ve found effective for similar use cases?
Afraid that video blew past me pretty quickly. I understand that you want to essentially filter potential drugs based upon context or category. Rather than searching across all drugs (in the concept dictionary or the drug table?) you only want to return those from a preselected list.
It seems that this sort of filtering has multiple levels. The first is what we would typically call a formulary and that would reduce the number of drugs returned, but not by context. The Drug table, I believe, was intended to provide this sort of filtering down from all the concepts in the concept table.
Next, you have context based searching. This certainly could be done by concept sets, but it is a large effort to maintain. Guideline or care plan-based concept sets are a good example of where this can work.
Clinicians often search based on drug class. They want to order a beta-blocker of hypertension, or a aminoglycoside for an antibiotic. We have explored using concept sets when classes are needed for drug allergies. Similar drug to drug class maps could be instantiated in the concept dictionary, but again this is a maintenance nightmare. The idea of having reference maps on drug concepts and drug rows in the drug table, was to be able to leverage those maps for things like class-drug mapping or subsumption queries. I would hope that we might consider how we could use those rather than have to maintain manual concept sets in the future.
Yes, that’s correct - the core idea is to extend the UI and its filtering options by providing a configurable list of predefined drug groups (Concept Sets) that clinicians can browse directly, rather than searching across all available drugs.
Apologies if the video moved a bit quickly - I’ll try to make the key points clearer in follow-ups. Thanks for the valuable feedback; I agree with many of the points you’re raising and see this as an initial, pragmatic step focused specifically on improving the UI and prescribing workflow, not on redefining drug semantics. It’s meant to work alongside existing mechanisms. If this browsing pattern proves valuable, it could later be supported by reference maps, or other semantic structures instead of manually maintained Concept Sets.
Thanks again for taking the time to review and share your thoughts.
Partners In Health uses concepts with class=MedSets for various purposes – reporting or drug selection (OpenMRS RefApp2). Totally makes sense to do this filtering with O3 and order basket @olewandowski
These are some examples: ART, Anti-TB, Anti-malaria, NCD, Diabetes, Mental health, etc
Thanks for sharing - that’s a great example. In my showcase I’m using ConvSet class, and I’ve also confirmed that MedSet works well with this solution. It’s nice to see that a similar pattern is already in use.
I think it is much more than that… and @ball can speak to the work of keeping them up to date. PIH has 14 and I think as more care guidelines and tertiary care is added to OpenMRS implementations, the number will increase.
The sets are essential for our implementations. For PIH, they are not changed constantly – only when we update the drug lists for our multi-country implementations. (I estimate 6x per year.).
But if these sets are maintained in CIEL for the community, it could require Andy to update the set(s) whenever a new drug is added to CIEL. One preliminary approach is maintaining only a few of the sets (ie. ARVs, anti-TB). Or is it possible that implementations maintain their own sets – same as PIH does?
Not a problem for PIH since we manage our own concept dictionary, but I assume that some implementations rely on CIEL for all concept management. (good question @dkayiwa )
CIEL could have empty sets for the main categories and then implementers can populate the sets.
Some thoughts that came up in today’s O3 Squad Call…
It would be worth considering how this browse feature would behave when the order basket is triggered from within the context of a form. For example, a mental health form triggering the order basket with orders filtered to a subset of mental health medications. Could browsing be similarly filtered? Or would the browse tab be suppressed in these workflows?
Consider ways to minimize the chance of users starting with an empty browse tab. For example, assuming browse categories are configured, could the browse tab default to the user’s last chosen category?
If there are a large number of choices in a category, is the user able to search within that list without confusing that search with the general search option?
Regarding context-specific forms and persisting values: these aren’t implemented yet, but we could definitely support filtering the browse list to specific Concept Sets in a future iteration.
As for search behavior, it currently uses the default Carbon Select (highlighting matches rather than filtering). We can improve this if the community prefers an actual filter.
I’m currently implementing several reviewer suggestions to make the list more usable and reliable. I’ll share an updated version as soon as I’m finished.
I would also add something @michaelbontyes mentioned in a CIEL discussion, which is that user frequency data might be brought into the ordering/filtering of the list. So perhaps 1) if no set is defined when the orderbasket is loaded, then a user-frequency specified list would be returned (but there is currently no database table to store this as yet) or 2) if you have a set returned, order the list based on frequency of use).
For some reason something is preventing me from posting this here. Also, if can start building a list of specific use cases for the concept sets, I can consider how CIEL might help. For me, the PR does not allow playing of the videos, so I am a bit in the dark, but I also think that user configuration should eventually be handled on OCL. I don’t think it is a good idea for complicated interactions with concept sets and concepts (taken both from CIEL and locally) to be ONLY handled on the OMRS server side. The whole idea of OCL was to allow for dictionary management in the cloud with CIEL providing the backbone and allowing customization for local use. If the use cases are standardized, then we can levarage reference mapping to provide value sets/concept sets which meet certain requirements, such as “beta blockers”. But even having a starter set of drugs for different guidelines/use cases in CIEL would be a good way to help people along.
