Maintaining sequence order for drug orders

Development
1

At JSS when a doctor prescribes cancer drug order it is used by the nurse to administer it to the patient. The order of prescription items is very important because nurse just follows what doctor has ordered (for sequence). We are generating the drug orders from the system which doctor edits to make minor changes. The problem we are facing is that if the doctor realises that there is a change required after saving once, and makes the edit, the sequence order changes because a new drug order has to be created.

I understand that we want to maintain the immutability for drug orders. Given that how should this problem be solved or what enhancements are required to drug orders in openmrs?

2

@vsingh,

Is the use case “I prescribe 3 drugs, all with the same start date, and I need to indicate the specific order in which they are given (on that date)”?

I think that in the past (when @mseaton was working on oncology ordering for PIH Rwanda), @burke had wanted to have something like “custom order attributes” and an implementation could choose to have one like “sequence number”. Personally I could see defining this directly in the DB. (@jteich, can you think of any other use cases for a “sequence number” or “order” in orders, besides oncology, that might push us towards this?)

Perhaps another approach is to say that the orders together should be part of an “order group” and to let membership in an order group have a sort weight.

3

tl;dr

We could add orders.sort_weight (float) and carry this value forward when a new order is created from an existing one (i.e., when previous order is set). Then the API could support reliable sorting of orders:

  • Manual sorting by sort weight (default)
  • Date created, descending
  • Date created, ascending
  • Alphabetic

When a new order was created from an existing one (e.g., revising an order), then it would naturally sort into the same position as the original.

-Burke

Burke’s pleonastic brain dump…

@darius, I think the order attributes idea was to support cycle number, which is commonly used in oncology to define a sequence of treatments over time (e.g., monthly treatments), not necessarily order sequencing (i.e., reproducing n orders with reliable sequencing – e.g., doctor orders A+B+C, later changes B to D, and we can reliably reproduce this as A+D+C). It’s possible the order attributes (i.e., an implementation-specific “sequence number” attribute) could meet this need, it’s worth considering if we can build this capability into the API.

I believe what @vsingh is describing is:

Scenario

  • Doctor orders A, B, and C
  • The doctor later changes B
    • This could be a revision (e.g., adjustment to instructions), changing B to B'
    • This could be a replacement, replacing B with D

Requirements

  • We can reliably display the original orders in the same sequence: A, B, then C
    • Currently this could be done using date created if timestamps are at least a second apart or using order number if the algorithm being used is incremental and reliably sortable (e.g., contains an incrementing number). I don’t believe either of these are currently guaranteed by the API.
  • The system can reliably reproduce the correct sequence even after orders are revised/replaced. If B was revised, then we can produce an order list as A, B', then C; if B was replaced, we can produce an order list as A, D, then C.
    • Currently, you would need to take active orders and track any previous order back to original orders and, assuming the sorting mentioned above worked, use the date created or order number from the original orders to reliably reproduce the correct sequence.

NOTE: while the use case described by @vsingh is for drugs, this need for sequencing could be applied to any type of orders.

The simplest approach would be to add orders.order_weight (float), allowing all orders to have an optional sort weight applied to reliably reproduce sequencing of orders. To support proper sequencing even after revisions/replacements, this assumes either the user will specify the position (weighting) when revising/replacing an order (which is probably not a reasonable expectation) or that the application (or the API) would need to trace any revision/replacements (via previous order) to its original order to obtain its weighting. In essence, the “sort weight” for any order would come from the original order (first order in any chain of previous orders). If the user creates a completely new order (without previous order pointing to what it’s replacing), then the only way to control its position would be for them to manually position it (i.e., adjust its sort weight within active orders).

This could be simplified further If we add orders.sort_weight (float) and ensure that the value is carried over whenever an order is created from an existing order (i.e., at the time that a previous order link is being created). The API could then support three modes of sorting:

  • Natural sorting (default): orders listed in the order they were created.

  • Alphabetic sorting: orders listed alphabetically by name.

  • Manual sorting: order listed by sort weight (orders without a sort weight would be naturally sorted at the end)

I think that could work, but we would probably want to stop relying on uniqueness of date created or the sortability of a potentially custom order number and would end up making the API add default sort weight values behind the scenes to support reliable natural sorting of orders (in the same sequence as they were created). So, in effect, the API would “manually” sort orders as they were created and any manual sorting would be manual adjustments to the values set by the API.

If we assume the number of orders may exceed the paging size, then sorting needs to be performed on the server side, so we end up with the API supporting the following sort modes:

  • Manual sorting by sort weight (default)
  • Date created, descending
  • Date created, ascending
  • Alphabetic
1 Like
4

I would like to understand the problem statement in a little more depth. The sequence of administration of several drugs should not be dependent on the sequence in which they are ordered. If you actually want drugs to be given at the same time but any particular sequence (this is a relatively unusual case), then you would put instructions to that effect in the orders themselves (“give 30 minutes after cisplatin”) and not rely on which order was written first. More commonly, you would carefully specify the times at which each drug was to be given.

I’m not sure that a “sequence number” will be well understood. But it could be that being able to link orders to other orders (a concept called “corollary orders”) could be useful in this particular case; that lets the order for drug A carry a special start-time field saying give it right after drug B, and so on. This is one of the special cases for drug administration times that could be part of a more complete solution, or we could special-case it for this purpose. I can help outline one or two possible solutions.

Am I understanding the question correctly?

PS Cancer chemotherapy regimens can be presented in a different style; in my past life we built a special ordering system solely for chemotherapy, essentially a matrix where you would have the drugs representing the rows and the days and times representing the columns, and you could mark in the grid where you wanted that drug to be given. (Darius, this is like the medication administration module that we were using in Ebola.) This is done because many chemotherapy regimens call for certain drugs to be given on odd-numbered days, others to be given on even numbered days, and so on. I expect this is too complicated for the immediate problem at hand, but something to think about if we are doing extensive cancer work.

5

@burke - What you explained as problem statement and the solution (based on sort order and api to manage it manually) are both spot on.

@jteich - The doctors also provide the instructions (in fact some of the instructions are also auto-generated).

6

I hadn’t seen Burke’s thoughts previously…

I think perhaps this could use some discussion in a design meeting. Some of this feels a bit clinically off to me and may stand a bit of simplification, although you’re of course welcome to proceed.

7

I also feel that just the sequencing may not be the complete information e.g. where does one mention the wait duration between two drugs, logically speaking it doesn’t belong in any specific drug order.

But if the protocol is understood between the doctor and nurse, then just sequencing could work and at the same time it could be possible to do something like this from the system and not resorting to paper.

I hope i am being clear. We can wait for some time for this discussion to play out.

8

I kind of have the same view as Jonathan, if a doctor prescribes certain medications and they need them to be administered in the order in which they were prescribed, i would imagine that the ordering is already sequential based on the effective start date and not order number. This implies if you edit a drug order and don’t change anything that would affect the effective start date then the new revised order shouldn’t fall out of order based on start date.

I’m also not thrilled by adding sort_weight as a new column, if other requirements keep coming up, are we just going to keep expanding the table? Order entry doesn’t seem to be a trivial thing especially when it comes to workflows and such needs will always crop up. I thought this is what attribute types are meant for, to take care of such requirements that don’t cut across the larger group but rather implementation specific. How about we add order attribute types? Then an implementation can have an attribute type they can use to do what they need to do.

9

In this scenario all the drugs have the same start date.

10

I see, i guess in that case the sequence should be in the dosing instructions

11

I am not sure how putting this in instructions is going to help because the nurse looking at various drug orders would have to mentally arrange then in the right order which will be quite error prone.

Regarding doing it via attributes or sort order. To me it seems like an important and common use case (as usage of people of OpenMRS matures) which should have native solution instead expecting everyone to come up with the same solution using attributes.

Should we go ahead with creating request for solving this via sort order?

12

Would it be right to think of wait between administration of drug orders be captured via some sort of order type = wait, and these orders contains the instructions like wait for 30 minutes.

Such sequenced drug orders would make the intermediate instructions explicit. Is it possible to schedule a design call on this?

13

After sleeping on this a bit, there may be another approach.

@jteich makes a very valid point. Depending on sequencing of orders from the API along could be a very fragile and potentially dangerous approach (e.g., if the sequencing is not properly supported in all views).

An alternative would be to use order sets & order groups. We have anticipated sequencing (“sort weight”) within order sets, but hadn’t (until now) considered preserving the sequencing within order groups. (FYI – I use “order sets” to refer to the metadata temlpates of potential orders and “order groups” to refer to the data about orders that were actually placed within groups… there’s a lot of old design notes about it here).

So, protocols that require a specific sequence of orders could be defined as an order set and, when the orders are placed, this sequence could be preserved within the order group. If orders within that group are later revised/replaced, as long as the previous_order chain is used, the group could be presented in its original sequence. This could support @vsingh’s use case without the need for trying to preserve an arbitrary sequence for all of a patient orders (which could be viewed and revised in a a myriad of different views & contexts that might have different opinions about how the orders should be sequenced).

So, instead of adding orders.sort_weight (float), perhaps we could meet the same need in a better way by doing what we’ve previously discussed as a first step into order sets: adding order_group and including an order_group.sort_weight (float). Even without order sets in place, Bahmni could begin storing sequence information by defining order groups.

1 Like
14

Hi,

cc @dkayiwa

I’m looking for a way to enforce “Drug Order Sequence Management” in custom frontend, we are using platform 2.5.10. I am putting it here as this question is related/same as in this thread.

Here is problem statement, when providers prescribe a series of 6–8 meds in a specific order, everything looks great—until they edit, renew, or change brand/strength/dosage. At that point the frontend re-sorts the list and confuses providers who expect their original sequence to stick. Here goal is to preserve the exact prescription order through every step of the order lifecycle (create, edit, renew, brand-change, etc.) so that providers don’t lose context. this thread suggests using OrderGroup.

  1. Is OrderGroup the recommended approach today? or there is better approach?
  2. Any guidance on OrderGroup primary use cases and design rationale
  3. Why does it require an “orderset” definition? I can’t find up-to-date docs on this and would love any pointers or examples. Thanks in advance!
15

Without diving deeply into this, it looks like just sorting these orders by the date created field of each original order would solve your problem. Correct?

16

@dkayiwa

Not sure, here when we modify the order (changing trade name or strength), in that case, I assume new order would be created, same goes for when we renew auto expired, in all cases we can link it to previous order.

But not sure if sorting by date created would full fill it, as edited or renewed order would be having date creation date changed.

I re-read your reply, you meant original order, so in that case, we need trace back through previous order and finally get the created date for original, would it be not complicating for over the period to fetch the original order?

Additional requirement we have to provide feature rearrange drug orders.

I am sure, I might be missing some very oblivious because this doesn’t seem unique requirement and i assume that this would be basic expectation for a provider , if there is more than 8-10 drug orders and editing one should not re-arrange the table.

17

Hi all, Anyone please, could shed some light on this?

18

Hi @dkayiwa @ibacher

Any input on this ?

19

It depends on the use-case for the table. The default orders view in O3 is designed to show the most recent orders first, because we make no assumptions about drugs being ordered in some sort of sequence. If you wanted that feature, OrderGroups are probably the way to go.

20

Thanks @ibacher for suggesting OrderGroups to maintain drug order sequences. I’d like to share more details and seek your advice on whether OrderGroups are still the best fit or if observations might be a better option.

Context

  • Medication Sequence: Providers prescribe 8-10+ drugs (e.g., injections, syrups, tablets) with various routes (IM, IV, oral), frequencies (HS, OD, SOS), and durations. They need to arrange these medications in a specific sequence based on their clinical preference (e.g., Med1, Med2, Med3) and should be able to insert new medications between existing ones. This sequence must remain consistent even after editing, renewing, or revising orders. For example:
    • Visit 1 (June 29, 2025): Med1, Med2, Med3 (all 30 days) → Sequence: [Med1, Med2, Med3].
    • Visit 2 (July 14, 2025): No change to Med1/Med2, stop Med3, add Med4 (15 days). The provider wants to place Med4 between Med1 and Med2 → Sequence: [Med1, Med4, Med2].
  • Visit-Wise Snapshot: At any point in the future, we want to retrieve a snapshot of all active medications a patient was taking after each visit in OPD scenerio. This includes drugs ordered in the current visit and those from previous visits that were still active at that time. The snapshot should reflect the provider’s preferred sequence. For example:
    • Visit 1 Snapshot: [Med1, Med2, Med3].
    • Visit 2 Snapshot: [Med1, Med4, Med2] (since Med3 is stopped, and Med4 is inserted).
    • Even on July 14, 2026, I should be able to see these exact snapshots.
  • Challenge: Editing one order shouldn’t rearrange the table, and the sequence and snapshots should persist across visits, including the ability to adjust the order dynamically.

Questions

  • Would OrderGroups allow providers to define and adjust their preferred medication sequence (e.g., inserting Med4 between Med1 and Med2) across visits, and can they store a visit-specific snapshot of all active medications (including past orders) that remains accessible years later? I understand sortWeight helps within a visit, but I’m unsure how to manage the sequence and snapshot across multiple visits with dynamic insertions.
  • Could observations be a better option? For example, storing the sequence of active order UUIDs (e.g., [Med1_UUID, Med4_UUID, Med2_UUID]) as an observation per visit to capture both the sequence and a permanent snapshot, without recreating orders?
  • Are there any best practices or examples in OpenMRS for managing dynamic sequencing with insertions and long-term historical snapshots of active medications?

I’d appreciate your insights or suggestions!

Best regards, Horaira