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.
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
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.
@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.
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:
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
Reviving this topic from a few years ago, because it’s become relevant in the context of the Dispensing ESM.
@burke the above description makes sense to me, but a follow-on question: should an auto-expire date really be set based on duration then? I was also assuming that the Dispensing application should prevent dispensing for orders after the expire date, but maybe this is an incorrect assumption?
Consider this use case:
In an outpatient setting, a doctor wants a patient to go on a two-day course of antibiotic treatment, and so fills out an order for such with a duration of 2 days. Say the patient doesn’t get to the pharmacy until 3 days later (or the pharmacy isout of the drug and tells the patient to come back in 2 days). Should the doctor really have to re-order the prescription?
In FHIR, we are mapping order duration to the “timing” component of the dosage instructions of a Medication Request (which seems accurate based on your description above).
But it seems like date activated and auto-expire should be mapped to something like validity period, and stand alone from duration, but this is separate from Duration:
It’s relevant in the context of the Dispensing app that we are working on… the Pharmacy team as said that you should not be able to dispense expired orders, which makes sense to me, but I foresee lots of confusion where clinicians don’t properly set the duration, and orders “expire” earlier than they should.
It seems to me that there should be the option for clinicians to should explicitly set an auto-expire date, and for perhaps a system to set a default expire date to apply to new orders?
I think you’re conflating expiration of an order and expiration (or length of validity) of the ability to dispense based on an order.
In acute care settings (e.g., inpatient, emergency department), medications are administered in near real-time, so the period of an order is much closer to the period of its administration. In outpatient settings, as in your example, the dispensing of drugs is often delayed and the we can’t depend on alignment of an lifespan of an order and the when a drug might get dispensed or administered. Prescriptions are commonly valid for 30 days or even a year. How long a prescription is valid (can still be dispensed) can vary with factors like local policies, the type of prescription, and the type of drug. So, a medication prescribed for a few days, especially if printed, could be honored (dispensed) by a pharmacy months following the order (long after the order expired).
So, while version 18 of the dispensing module (just after alien technology is introduced) might allow implementation-specific policies (regional rules) to use information from the order (e.g., the class of drug, the start date & duration of the order, etc.) to inform a dispensing system of whether or not the order is still valid for dispensing, I would avoid a tight coupling of the period of validity of dispensing to the duration/expiration date of the order. Perhaps a simple “1.0” solution would be to allow the module to be configured to avoid dispensing orders that expired more than n days ago (with a default informed by surveying implementations and likely somewhere in the range of 30-365 days).
@burke@ibacher@mseaton in order to move forward with this, I’d like to propose the following:
In the FHIR module, when converting an OpenMRS Order to a Medication Request, we currently don’t map any dates on the Order to the Medication Request (besides the last updated metadata).
Looking at Medication Request, I see the following fields:
MedicationRequest.authoredOn
MedicationRequest.dispenseRequest.validityPeriod (which is a period, with a start and end date)
Those are the only two datetime-based parameters that I see on the order.
Would it make sense to map the “date activated” field on Order to the dispenseRequest.validityPeriod.start, (but leave the validityPeriod.end null, ie not based on auto expire date, due the reasoning Burke states above). That is, can we assume that the dispensing validity start date maps to the date activated? This would allow use within the Dispensing module to say an order can be dispensed if the validity start date is within the past n days.
Alternatively, we could map the date created to the date of validity start date, but it seems more appropriate to map that to date created.
Interested in others thoughts, but wondering if you need to be considering the order.getEffectiveStartDate(), which takes into account whether the order is scheduled for the future.
Maybe dateActivated → authoredOn and effectiveStartDate → validityPeriod.start ?
I still think that dateCreated is the right field to tie to authoredOn. I’d assume effectiveStartDate is would take into account the date activated? If we need to separately track the date activated, it’s easy enough to add a custom extension to hold that information.
My gut is to agree with @ibacher and that dateCreated maps best to authored on.
Interested in @burke 's thoughts about mapping medicationRequest.dispensingRequest.validityPeriod.start since he seems to have clearest understanding of the meaning behind some of the OpenMRS Order fields.
For reference, this is the implemetation of getEffectiveStartDate:
public Date getEffectiveStartDate() {
return this.urgency == Urgency.ON_SCHEDULED_DATE ? this.getScheduledDate() : this.getDateActivated();
}
So I guess the question is “can you dispense a medication as soon as it’s activated, or not until it’s scheduled date”?
For what it’s worth, in order to make searching by validityPeriod.start performant in the FHIR2 module, we’d need to implement the search directly via DB queries and not need to access the API (but encoding the above getEffectiveStartDate logic in a query seems straightforward enough).
Would be nice to use the easiest start mapping (validatyPeriod.start = order.dateActivated) but fine to do the more complex logic if it’s actually the right thing ( “can you dispense a medication as soon as it’s activated, or not until it’s scheduled date”?)
Sorry. I thought I had replied here and just found my reply was left unsent.
Lacking support for draft or pending orders, all orders saved via the API are effectively “active” orders until they stopped (expire or have been discontinued). When an order specifies a specific start date –e.g., you write an order on Monday for the patient to start a medication on Thursday – during the intervening Tuesday or Wednesday, I would consider the order active, but the medication not yet getting administered. This would be similar to ordering a ramping dose when starting a drug, where you take 50 mg tablets for a week before switching to the 100 mg tablets. During the first week, the order for 100 mg tablets is active, but the medication administration has not yet started. Both 50 mg and 100 mg prescriptions could be dispensed on day 1, with the expectation the patient wouldn’t start taking the 100 mg tablets for a week.
