Orders API Actions

Wanted to start a discussion on the Order actions we are looking to support in the order entry MF.

The key actions we’d like to support:

Add : create a new order Revise : discontiue existing order, create new order that is linked to old order Discontinue: disconintue active order Renew : create new order that is the same as an existing order (active or inactive or discontinued).

Renew is trickiest of the four - can you renew an active order? If so, does that discontinue the existing order?

Also, can we have two orders for the same drug active at the same time? I can see a use case for this: a patient is to take lasix 40 mg in the am and 20 mg in the pm could be two different orders (though it would be nice if we had the ability to represent this in a single order)

Also, @ibacher @corneliouzbett, does the FHIR module support order creation?

Thanks,

JJ

@mseaton @mogoodrich @florianrappl @burke @dkayiwa @mksd @mksrom @wyclif

Not right now. It turns out OpenMRS has some business logic around creating orders that we’ll need to add support for. Basically, I need to figure out how we can track the users “location”, since we don’t normally have that as a session property.

This is actually a question I encountered recently and wanted to ask this of the broader community and @burke specifically. We have this exact case we need to support - a patient has a chemotherapy cycle ordered, and it contains the following sequence of orders for day X:

  • Premedication
    • Normal Saline 500.0 ml…
    • Ondansetron 8.0 mg…
  • Chemotherapy
    • Prednisone 100.0 mg…
    • Vincristine 1.4 mg/m2…
    • Doxorubicin 50.0 mg/m2…
    • Cyclophosphamide 750.0 mg/m2…
  • Post-Chemotherapy
    • Normal Saline 500.0 ml…
    • Prednisone …

We represent this as an Order Group containing 8 Drug Orders, all ordered for the same date (eg. dateActivated, scheduledDate, autoExpireDate are the same for all).

The API disallows this as-is. It will not allow both Normal Saline and Prednisone orders to be placed for the same day.

So far the only way around this that I have found is a feature within the Order Context. This allows one to specify a specific existing drug order (by uuid) on the order context to allow additional drug orders to be placed for the same orderable as this uuid.

So we have written some custom code for our use case to support this, which first identifies the existing orders we wish to allow duplicates for, then pulls these uuids into a String[] in the OrderContext, before saving the subsequent orders, which works. A few limitations / workarounds (some of which I just made into tickets):

  • Is this support sufficient to allow us to meet our various use cases, or are there other ways we want to enable this?

  • This doesn’t work at all with any of the existing Order Group-based service methods, as unlike our saveOrder methods, we have no saveOrderGroup methods that allow passing in an Order Context. I added a ticket for this here which needs assessment.

  • The logic in our service methods to enforce this validation only kicks in for Drug Orders. And the way the system determines whether the Order is a Drug Order is by comparing it’s Order Type to a specific hard-coded uuid. However, the system is explicitly designed to support configurable order types, as well as multiple order types that represent drug orders (by virtue of the javaClassName property), and there is nothing that requires or enforces this particular uuid. So this validation can be bypassed entirely by using a DrugOrder orderType that has a uuid other than 131168f4-15f5-102d-96e4-000c29c2a5d7. This seems like a bug in our system and we should not have any logic that requires specific order type uuids to function. Ticketed here for assessment.

Interested in others thoughts… Mike

1 Like

In OpenMRS, an Order can be placed with 4 possible “Order Actions”: NEW, REVISE, DISCONTINUE, RENEW, which matches your requirements.

From what I can tell looking at the API, only REVISE and DISCONTINUE will automatically close an existing, active Order before saving the new Order. I don’t actually see any specific logic for handling RENEW orders at all. So I think the answer to your question is: No, you cannot currently RENEW an active order with the current API. This might be a bug / oversight that we could ticket. @burke?

Depending on your exact use case for REVISE, it may or may not meet your use case as it is, as there is a lot of validation in the system that assume certain constraints. As an example, for any order that stores a reference to a previousOrder (which would be REVISE, RENEW, and DISCONTINUE), the orderable must match both previous and new orders. For Drug Orders this includes the actual drug formulation, so you can’t Revise an order from a drug of “Ibuprofin 100mg” to “Ibuprofin 200mg”. This would fail validation.

If this is a use-case you need to support, you can still do so, but you would need to create a custom method that first discontinues the existing order, then creates a new order, and does not link them together. You would likely want to write java code to so this, and expose a custom rest endpoint, because you’ll want this operation to be transactional and not just a series of independent web service calls. Or you could lobby that this should be allowed, and add support for this into core. I defer to @burke, yourself, and others on that.

Just wanted to highlight this example to try to address your overall question around whether OpenMRS supports all of the order actions you need, as the answer is not 100% straightforward. Depending on your use cases, my guess is that it is mostly there, but some additional work may be required.

Mike

1 Like

I would expect RENEW on an active order to replace it with a new active order. The typical use case is to renew a chronic outpatient medication (and likely printing a script for the patient), where a new order would be needed to track a newly issued prescription, refreshed refills, etc. RENEW of an inactive order would create a new order based on the inactive order (e.g., reissuing a chronic outpatient medication that recently expired). In the inpatient (hospital) context, we use CONTINUE in a similar way during patient care transitions (i.e., transfer).

Yes, carefully. When we created the Medical Gopher, Clem disallowed multiple simultaneous orders for the same thing. This made sense from a patient safety perspective, since juggling simultaneous multiple orders for the same thing increases the chance for errors geometrically (incorrect dosing, properly communicating changes, opening the door to accidental duplicate orders). That said, an absolute restriction against multiple simultaneous orders seems too restrictive. There are cases where it’s needed, like your example.

The compromise we made in OpenMRS was for patient safety. You can create multiple simultaneous orders for the same orderable, if you explicitly acknowledge the duplication. In other words, if the patient is on lasix 40 mg daily, you can add lasix 20 mg daily as long as you include a reference to the 40 mg order (proving you know it exists). I don’t know if we managed to implement this for orders being created in the same transaction (i.e., if you are creating both lasix orders in one step, so don’t have a UUID), but this could be accomplished by including a non-UUID-based reference in each order to the other(s) that are duplicates.

The point of this restriction is not to create hurdles for developers; rather, it’s for patient safety. The goal is to ensure anyone working with orders will make sure users acknowledge potential duplication before placing orders. Of course, you can programmatically identify potential duplicates and auto-fill these references, but that would defeat the purpose. Instead, it’s expected these references would only be populated when a user acknowledges the potential duplication and any code unaware of this complexity would be prevented from accidentally creating duplicates.

@mseaton, ideally the editor creating an order set would be able to acknowledge the duplicates when creating the order set, which would populate these cross-references (obviously not with order UUIDs) in a way that would allow them to be passed along successfully through the order API. The goal is that someone (either when creating the order set or placing the orders) must acknowledge the duplicates. Having the computer do this automatically defeats the safety feature. For example, even if we have an order set with duplicates already acknowledged, if the patient is already getting normal saline as an active order when the order set is ordered, I would expect the application to detect the duplication, warn the user and have them either discontinue the active order or confirm the duplication is okay.