tl;dr: we rename
orders.date_scheduledto specify the start date for scheduled orders.
We have been discussing (on dev list and design forum) how dates on orders are related to order uniqueness. For patient safety, it’s important that OpenMRS never allow two or more orders of the “same thing” to be active at the same time (see Order Uniqueness Constraints for more detailed discussion). In order to allow the same thing to be ordered to be carried out in non-overlapping periods of time, we need to understand the various dates involved with an order.
NOTE: While OpenMRS is not yet ready for handling signing of orders, pending orders, student orders, or verbal orders, we include these considerations in the design, since we expect to support these later.
date_signed– When the order is signed by the accountable ordering provider (for student orders or verbal orders, this is when the order was cosigned). Typically happens with activation; however, pending orders can be signed before being activated and verbal orders can be activated before being signed.
date_activated– When the order is activated – i.e., passed from the orderer to other provider(s) or system(s). An order cannot be carried out until it is activated and, once activated, orders cannot be taken back (they can only be altered or stopped by issuing another order).
scheduled_date– For scheduled orders (i.e., orders that should be started at a specific date and/or time), this is when the order should be started.
expiration_date– When the order will be stopped automatically. For orders that have a known duration, this is set by the API at the time that the order is written.
date_stopped– When the order was stopped, whether it was explicitly discontinued or stopped for any other reason.
date_signedimplementation is deferred for now (out of scope for first pass of order entry, while all orders saved to the API are considered signed by the
Active orders are any orders that have been activated and have not yet expired or been stopped.
For order uniqueness, scheduled orders* are allowed as long as their course(s) (i.e.,
auto_expire_date) do not overlap.
For patient safety (to avoid ambiguity), discontinuing an active order should discontinue all active orders for that orderable, including any scheduled orders that have not yet started. Likewise, revising an active order should replace all active orders for that orderable, including any scheduled orders that have not yet started.
* “Scheduled orders” are orders with an urgency that specifies a start date, such as
Thoughts? Feedback? Too long? Clear as mud?