I am working on a module to log medications prescribed to a patient and maintain a history of active/in-active drug orders.
I am stuck in between revise and saveRetorspectiveOrder. Few questions:
Can anyone please clarify the difference in between these two?
If an order needs to be revised, we clone the order for revision. Does the idea of changing drug related information (like dose, quantity, frequency etc.) conforms to the definition of “Revising an Order”? Or only the Order related information e.g orderer, order reason etc. can be changed?.
If a drug order is revised, it is not necessary that it will have the same encounter as the original one. Changing encounter will require to keep a check on the dateActivated that it should always be after the encounterDate. Does the encounter need to be changed in this scenario also?
Can ONLY active orders be revised?
In case of a drug order that was successfully completed but the doctor needs to give the same medication. Which option will be used? Revise or saveRetrospectiveOrder?
Looking forward to your help to clarify these ambiguities.
Think of revising an order as being equivalent to editing it.
Revising an order should really only be done to active orders, it makes no sense at all to revise an order that’s expired or discontinued.
When you revising an order pretty much all fields maintain their original values including encounter except for the fields you explicitly change on the revision order.
If an order has been completed and the doc needs to give the same order, they’d have to place a new order.
Thanks @wyclif for the immediate response, this all makes sense to me. I have few more questions. What is the use of this method OrderService.saveRetrospectiveOrder in api? It was mentioned here under Action heading that new actions like RENEW will be included in future. Is it implemented now?
Orders are meant to be placed in realtime but in some cases, the system might be unavailable to capture them in realtime, therefore you need to save them retrospectively and that’s the purpose of OrderService.saveRetrospectiveOrder
Renewing of orders hasn’t yet been implemented, you just have to place a new order for now.
I see a problem when revising a current order. Api stops the current order, sets the date_stopped to a moment before (subtracts 1 second from date_activated) and creates a new order with REVISE action. This results in a date_stopped that is one day older than the date_activated which is obviously confusing that how can the order be stopped before it was created.
On the first glance it screams bug but I want to think it’s not really, this seems to me like a construed scenario, in a typical live setting this should never arise because the action of revising an order can never happen at the same time as that for placing the same order.
If you look at your screenshot, the original and revision order both have the same activation date, and am saying that is unlikely to ever happen as long as humans are entering the data into the system because there would be enough room for time to pass from when the original order is placed and when the revision happens.
Note that the orders in your screenshot have no time component which shouldn’t really be the case and it seems to me like the cause of the issue, are you sure those orders were entered into the system in the ‘normal way’? I.e. through the IU or were they just populated into the database via some other mechanism?
These orders were entered through UI using the order entry. This can result in case if the doctor has mistakenly placed an incorrect order and eventually revision is the solution.
I’m thinking this is a problem related to the way the UI works, am guessing the IU only lets the user enter a date for date activated with no time component.
@tahira what are you using to create the orders? Is it a custom module? It would need to be fixed in the UI to record the time too so that the 2 dates don’t turn out to be the same in case the user attempts to revise the order on the same day.
@tahira I’ll second what @wyclif said. We should incorporate time as well, because especially in case of in-patients it is possible that there’ll be changes in medication in the same day but different time.
I think the behavior of the UI should be such that if the user doesn’t specify a time component for date activated when placing an order and date activated matches the current calendar day, it defaults to the current time including seconds. This same behavior should also apply when discontinuing or revising an order.
In the future, I think we could possibly move this logic into core.
@wyclif Thank you very much for responding to my queries. Currently, I am trying to figure out where does the actual problem occurs even if the time component is captured in the date_activated. Will share if I’m able to trace the issue.
I have one more question. If an order is discontinued, API creates a new order, sets the previous_order_id to the one that was discontinued, but this new order which is created has all drug related properties set to NULL in drug_order table. Why is that so?
@tahira the action of discontinuing an order is an order itself, we call it a discontinuation order, therefore, that new order you are seeing that’s getting created isn’t a replacement of some sort, it’s just a plain Order which is neither of the subclasses of Order. In fact, if you check in the database it’s action is set to DISCONTINUE to differentiate it from other orders, the API will never return discontinuation orders among active orders.
@wyclif Thank you for being responsive through out this thread. I’m interested to know that why doesn’t the API provide a method to retrieve completed/discontinued orders like it does for active orders getActiveOrders(...)?
The only reason I can think of is because nobody requested for it. Note that the API has a method that can return pretty much all orders, it is really intended for migration purposes.
Thanks again Yes! there is a method getAllOrdersByPatient(Patient patient) that returns all orders. The actual issue is to differentiate between completed & discontinued orders. Even if we are able to distinguish by auto_expire_date and date_stopped, the question is “Do they need to be displayed separately on patient dashboard?” Please see the screen shot below:
For now, I have treated discontinued/completed orders both under the heading of Completed Regimens. When a discontinued order appears in list, I fetch its previous order to display information but the problem occurs when I need to show discontinued reason (order_reason), but that is attached to the discontinued order itself, not with its previous order (that was discontinued).
@wyclif what would you suggest shall they be treated differently (completed & discontinued orders)?
Note that the API has a method that can return pretty much all orders, it is really intended for migration purposes.
And I didn’t get what do you mean by migration purposes and which method is intended for that kind of use?
Yes! there is a method 