We are seeking your input on this pull request, which proposes enabling future dates when placing medication orders in the patient chart.
The idea is to allow providers to schedule medications that are intended to start at a future date. For example, a clinician might want to prescribe a drug that starts after the completion of an existing regimen.
We’d greatly appreciate your guidance on the following points:
Are there any clinical or implementation concerns with allowing medication orders to have a future start date?
Should the system support this as a configurable option?
How should the dispensing process treat medications with future start dates? Should they be available for dispensing immediately or only on/after the scheduled start date?
Has anyone implemented a similar support in their OpenMRS setup? If so, what considerations came up?
Hi @veronica, thanks for bringing this up here. In my opinion, it might be helpful to make the start date and time optional but configurable, just in case someone needs to set it for a future time. For example, in a hospital setting, a clinician might want a patient to start medication tomorrow afternoon or after a certain procedure. It’s just a small thought, but I feel it could add some flexibility for those who need it, while still keeping things simple for everyone else.
So I vote for having the future start date for dispensing.
Along with it, we also need to figure out the tapering dose prescribed to the patient. example:
Tab Prednisolone 5 mg Oral Two time a day for 5 days
Then
Tab Prednisone 2.5 mg Oral Two time a day for 5 days
Then
Tab Prednisone 2.5 mg Oral once daily for 5 days
Then Stop.
I don’t see an issue with allowing orders with a future start date. Doesn’t seem like the sort of thing we should prevent people from doing. That said, how this relates to dispensing is difficult. Without a proper set of rules to implement, the safest option seems to be to just make it available for dispensing and rely on the pharmacist for the legal implications (maybe with some kind of visual cue that the order is not for today). I suspect the real answer is very highly dependent on the drug in question, the amount of time the order is in advance for, etc.
Hi @veronica, @ibacher
I see that, by using below fields in payload during creation of drug order, we can kind of give hint to start medication in future (I am assuming this as I am no expert)
In this case, the thread “medications to start at future date” (the current thread), how it is different functionally with scheduledDate ?
I am sure, I am missing something here, any pointer ?
Also, if patient comes after follow-up date that is medication got expired, what would be way to renew/revise it so that it could be linked to previous order
We tried to use revise, but it throws error as already discontinued medication can’t be discontinued.
Do drug order API end point supports RENEW?
It’s exactly that functionality, and we should use that for future start dates.
You should be able to RENEW a medication order that has expired. It may be that there’s a bug around this or that the drug order widget doesn’t handle this properly.
Any way to change dateStopped after autoExpireDate is passed ? as even after autoExpireDate is passed the dateStopped is null?
when we renew a drug order after autoExpireDate is passed , in that we are passing uuid of previous order, any way to forward fetch the renewed order using the auto Expired order uuid ?
Hi everyone, based on the conversations here and on Jira, I had started implementing a version of this.
During the process however I discovered that the ‘Start date’ input as seen on the ‘Add drug order’ form, does nothing. The input is just a placeholder that is yet to be implemented. And thus, all drug orders created (even if you select a date in the past) start from ‘this moment’.
This expands the topic to the question,
Should drug orders be allowed to be created in the past?
And based on the current talk, the current implementation plan is as:
Allow the selection of dates in the future (and perhaps in the past as well)
With a strong visual cue for the future orders that This order is for x days from today as a pill-icon on the dispenser and medication summary pages.
@tanishqqq Thank you for digging into this even further and for your findings. The start date field being “non-functional” is actually an issue that has been raised before.
The use case for backdating is primarily retrospective data entry - for example, a facility may have failed to capture data at the point of care due to a power blackout or system unavailability.
For future dating, there are clinical cases where medications need to be scheduled to start at a specific future time, such as medications scheduled to start upon hospital discharge, or sequential therapy where one medication begins after completing another course.
Given these are distinct use cases, I suggest we separate them. This PR should focus on future-dated orders first. We can address backdating as a separate ticket (in my view).
Regarding your implementation plan, the visual indicators sound good. @pauladams@cduffy Any suggestions on the UI or what the visual would look like?
Seems like it would be good to document medication life cycle along with its representation within OpenMRS (UI and database). There clearly is a difference between the ordering/prescribing, when the drug is dispensed and when the patient is supposed to actual take/administer/receive the medication, and finally when it no longer is being taken. You could even add that there is a time when the drug is still in the patient’s system (for example Azithromycin which when taken for 5 days lasts another two weeks in the patient’s bloodstream). The latter date can probably be ignored, but the earlier dates are all relevant and dependent on each other.