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