Duration and auto-expire date on orders

Question for order entry gurus. I’m working on order entry capabilities, and had been setting “duration” and “durationUnits” on drugOrder, with an assumption that these would lead to an automatic calculation of autoExpireDate and are applicable for all Drug Orders, not just those with particular dosing instructions.

However, I found that this does not happen. For orders that use FreeTextDosingInstructions, or orders that use SimpleDosingInstructions and specify numRefills > 0, autoExpireDate is not autocalculated, but is left as null in the OrderService. This automatic calculation of autoExpireDate is done within the SimpleDosingInstructions implementation, not as something applied to all drug orders in the Order Service.

This seems imply that I had been misconstruing these properties? Is it incorrect to collect duration when using FreeTextDosingInstructions? Should this only apply to SimpleDosingInstructions? How are these intended to be used? From a UI perspective, I’d prefer to just have a duration/units selector that is optional for all orders than an auto-expire date picker that has to be used for some.

@burke and others - can you provide some perspective on this? @ddesimone FYI.

Thanks, Mike

You are correct. Duration is not specific to the type of dosing instructions (simple, free text, taper, etc.). If the duration is set, then I would expect autoExpireDate to be set to start date + duration, regardless of what type of dosing instructions are provided. When provided, a drug order duration says “the patient should not be taking this medication after ,” which means the drug can automatically expire (not be considered active) after that duration has been reached.

So, it looks like you may have found a bug.

-Burke :burke:


Ideally, we would pre-populate duration when possible

Duration is intended for drug orders that have a finite duration (e.g., giving an antibiotic for one week). Ideally, duration would be pre-populated when possible – for example, from a pre-defined order (i.e., you pick the “give seatoncillin once daily for a week” from a choice list and duration is its pre-defined duration) or by parsing non-ambiguous free text (i.e., you type the free text “take 1 tablet daily for one week” and an instruction parser is able to unambiguously parse the duration from it). If we actually had those features to infer duration, it would be pre-populated and the user could change it if they wanted. For lack of those features, we just provide blank duration fields for the user to populate as you describe.

Many drugs orders don’t have a duration

For many drug orders (HIV meds, blood pressure meds, diabetes meds, etc.), they are taken indefinitely and duration fields would be left blank (ignored).

Dispensing information might be informed/inferred from duration, but duration is not dispensing information

The duration is meant to be the duration that the medication should be taken/administered, and not dispensing information. In other words, if your pharmacy dispenses meds in one month supplies and you want the patient to take a medicine for 3 months and stop taking it, the duration would be 3 months, the dispensing information would likely be quantity for one month + 2 refills.

1 Like

@burke - thanks very much for the quick and thorough response - this was exactly what I had hoped you’d say and matches what I would naturally expect. I’ll raise an issue and submit a PR for this in the next day or so most likely. As you say, many of our orders particularly for HIV and other chronic care will leave duration empty, but when it is specified I’d like the system to respect it and ensure the order expires after the duration indicated.

Thanks again! - Mike

1 Like

Hi @burke ,

As a follow-up, I started looking at implementing the changes needed for ensuring auto-expire date is always set if duration is specified. In doing so, I uncovered a bit of the history, and I’d like to first understand the design decisions that went into the current API, to better inform how to make these revisions.

Looking at the code, the current design was implemented in TRUNK-4446, and the specific functionality for delegating the decision to DosingInstructions as to whether to set auto-expire date is found in a few comments (among the many) on that ticket. Specifically, see your comments here:

https://issues.openmrs.org/browse/TRUNK-4446?focusedCommentId=210404&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-210404

https://issues.openmrs.org/browse/TRUNK-4446?focusedCommentId=211128&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-211128

These indicate that (at least some of) the current behavior is deliberate.

Looking at the code, here is where the OrderService delegates setting autoExpireDate to the DosingInstructions on the DrugOrder, which in turn delegate to the specified DosingInstructions.

Right now, we have 2 DosingInstructions implementations in core. The first, SimpleDosingInstructions, does not set autoExpireDate if numRefills > 0 in line with the comments on the above ticket. This is explicitly mentioned in the javadoc of the DosingInstructions interface. The second, FreeTextDosingInstructions, never sets the autoExpireDate.

Given the current implementation and previous decisions, do you have suggestions as to the most appropriate changes to make? It still feels to me like if someone explicitly indicates a duration that we should respect it, but since the previous design discussion thought otherwise, I’d like to just double check before changing.

Thanks, Mike

FYI - This is the ticket I created for this change: TRUNK-5992

2 Likes