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.