Actually, some medication orders do not expire — some patients take drugs every day for life, such as thyroid medication or blood pressure medication. An order that does not have an explicit duration (or frequency + number-to-dispense) should not expire, whether it is free text or structured entry.
If the order is written in the inpatient setting, a different mechanism could end this order, and all other medication orders, when the patient is discharged or transferred.
A free-text order that is supposed to expire would have a duration as part of its text (such as “…for 10 days”), but I believe we have decided not to parse any of the text of a free-text order.
Interest, and you are correct that we do not parse the free-text at all. But I feel like that’s going to be problematic because it means that free-text orders will basically stick around forever.
Would a good-enough hack solution be, if after the text box we put structured fields like this?
(optional) Keep order open through [date] -or- for [number][duration units]
Great suggestion. I guess this would also require modifying the underlying backend API logic for creating free text orders to include handling the auto expire date?
Test orders auto-expire by default (we used 24 hours)
When drug orders have an explicit duration, we would obviously use that. But when we weren’t sure, we would not auto-expire drug orders by default. We later added some heuristics to parse duration from free text and used that only when we could unambiguously determine the duration from free text. For now, I wouldn’t worry about parsing free text.
To your specific question, it would be fine to include an optional end date for free text orders.
It’s okay for free text drug orders to stick around until expicitly discontinued. It’s far better than having prescriptions disappearing unexpectedly. As I mentioned above, I would support some business rule for a default auto-expire for test orders (a day, a week… 24 hours worked for us, but implementation needs may vary).
In any case, adding an optional end date field for free text drug orders should suffice. Later on, we could add some heuristics to examine the free text and, when a duration could be confidently inferred, we could pre-fill the end date appropriately.
Yes you are right, in my earlier comment I meant that the application can let you mark any order as expired and didn’t mean that in real life any order should expire.
@fred thanks for raising this issue. Now that we’ve gotten some (advanced!) clinician feedback, and I’ve had a chance to look at our existing code, I suggest that we document this issue, but leave it in the backlog for now. So in the short term free-text drug orders will stick around forever until someone actively clicks “stop”.
Taking a quick look at the code in openmrs-core, I don’t believe it’s currently possible to set an autoExpireDate on a DrugOrder with FreeTextDosingInstructions, so we’re going to need to create an openmrs-core ticket to allow this. (And this will take time to get released, etc.)
Structured orders without a duration or frequency/number-to-dispense don’t expire
Free text orders don’t expire without some additional structured directive to do so
An optional structured field following the free-text order, saying “order expires after [Number] Days” is reasonable. Note that here I prefer explicitly using Days instead of making the duration-unit selectable, because if you chose number of pills or doses, you’d still need to parse the free text to figure out how many days that would last.
BTW, note that some of Burke’s comments referred also to test orders (lab tests) – on a quick read that could be misinterpreted as text orders. His comments on test orders make sense but are separate from the drug-order free-text discussion. I mis-read it at first and wanted to make sure nobody else does.
Yes, you are using the encounter endpoint because it allows you to create multiple orders at a time, grouped together.
Encounters also can contain observations (e.g. “weight in kg = 70”). Encounters can also point to the (data entry) form that was used to fill them out. Neither of those are relevant for the screens you are building, though. If you want to explore more, you can fill out the Visit Note form in the reference application UI and then check out what actually happened in the DB or via the REST API.
@darius so all orders placed at the same time are grouped with “Order Entry” encounter? Is there support/do we want to support in the future assigning orders to an existing encounter? (ie, attaching to a Consult encounter if ordered during a consult)?
Yes that is the short term planned behavior and yes we would want to support what you describe.
I haven’t analyzed whether the REST API actually lets you do it though.
In a simpler scenario, the Reference Application out of the box seems to just define Unknown and Clinician:
I guess for this project it should work like EncounterType (i.e. the admin should configure, via global property, what EncounterRole to use when recording the provider for the order entry encounter)
Okay, thank you. We will look into it in that direction.
However, I still have a concern. As for encounterType we agreed on using one encounterType called order entry when adding an encounter. While in encounterRole, a provider can be a clinician or not. If we set a global property for encounterRole, does it mean that every time a drug order will be added the same encounterRole is going to be used? Say an encounterRole called Clinician?
The team is working on implementing pagination for active and past orders. So far we are making progress. However, we have some blockers. The `webservices.rest.maxResultsDefault global property is set to 50 results by default unless a limit is set to override this. The challenge this poses is that while implementing pagination, we would need to know the total results available, which could be above 50 in some cases. This total result helps to determine the total number of pages the results would take when given a certain limit.
What we have tried:
Using custom REST endpoint shown here - …/order?careSetting=${careSetting}&patient=${patientUuid}&status=inactive&t=drugorder&v=custom:(orderNumber). This is to help us find the total number of results based on orderNumber. The restriction still applies to this method.
What we need:
How to get a total count of all the results without the default limit restriction.
When you make the first rest call, you should include a totalCount request parameter with its value set to true, this tells the API to include the total count in the returned payload, this feature was added in version 2.15 of the rest module, so you need to be running this version or later.
