Order Actions and States
This page sets out the actions and states to be maintained in the order record. It is based loosely on a diagram of Burke's which is attached to the page.
Pre-order states: DRAFT, GENERATED
"Current" states: PENDING, ACTIVE, EXPIRED
Terminal states: REJECTED, CANCELLED, MODIFIED, COMPLETE
Editing rules:
All fields can be edited in DRAFT
Execution and expiration dates can be changed in GENERATED, PENDING
Directed to can be changed in all non-terminal states so long as fulfillment is null
Fulfillment can be edited in "Current" states.
Reason is required for REJECT, CANCEL and MODIFY actions
Single-Order Actions
Previous | Activity | Action | Fulfillment | Next |
|---|---|---|---|---|
none | Doctor begins creating an order, is interrupted Doctor gives a verbal order to a nurse or other provider Student creates an order | DRAFT |
| DRAFT |
none | Computer assigns an order from another patient to this patient Computer receives an HL7 order message from another site | GENERATE |
| GENERATED |
DRAFT | Doctor reviews, edits and submits the order for immediate execution | CREATE |
| ACTIVE |
DRAFT | Doctor reviews, edits and submits the order for later execution | CREATE |
| PENDING |
DRAFT | Doctor reviews and rejects the order | void |
| none |
GENERATED | Doctor review, edits and submits the order for immediate execution | ACCEPT |
| ACTIVE |
GENERATED | Doctor reviews, edits and submits the order for later execution | ACCEPT |
| PENDING |
PENDING | Pre-execution delay expires | none |
| ACTIVE |
PENDING | Doctor reviews and edits the execution time for later execution | none |
| PENDING |
PENDING | Doctor reviews and submits the order for immediate execution | ACTIVATE |
| ACTIVE |
ACTIVE | Expire date or auto-expire date reached, or both dates are null | none |
| EXPIRED |
ACTIVE, | For referral-type orders, facility has taken all actions preparatory to referral |
| READY |
|
ACTIVE, | For non-referral-type orders, acknowledged but awaiting action |
| PENDING |
|
ACTIVE, | Indication received that order is being executed |
| IN PROGRESS |
|
ACTIVE, | Some but not all anticipated results received |
| PARTIAL |
|
ACTIVE, | All anticipated results received |
| COMPLETED | COMPLETE |
ACTIVE, | Less than all anticipated results received but no further results expected |
|
| COMPLETE |
The diagram below is in progress (not complete ... yet)!
Two-Order Actions
Order 1 | Activity | Order 2 | Order 1 | Order 2 |
|---|---|---|---|---|
GENERATED | Doctor reviews and rejects the order | REJECT | REJECTED | COMPLETE |
PENDING, | Doctor cancels order | CANCEL | CANCELLED | COMPLETE |
PENDING, | Doctor reviews and writes a different order for later execution | MODIFY | MODIFIED | PENDING |
PENDING, | Doctor reviews and writes a different order for immediate execution | MODIFY | MODIFIED | ACTIVE |
Comments
I wanted to acknowledge your work.
I don't know where the "assumption" mentioned in your last sentence comes from. I think the recent discussion on generated orders indicates that it's not tenable.
But the bigger point is, where do platform rules end and business rules begin? Surely you could have a facility where only active orders are entered and nothing else was done (this approximates the situation where legacy obs are being converted to orders). This would mean certain API calls wouldn't be as useful (like getActiveOrders(Patient p) and report filters based on active orders), but things would still work. However, would users at that facility be able to edit their orders, or would they have to do a two-order Modify?
Without a status field, then all orders are assumed to be active; therefore, any work with orders prior to activating them must happen elsewhere (e.g., draft or pending orders would need to be stored in module tables or somewhere else until they were signed or otherwise ready for activation).
Orders that are activated cannot be modified in-place, so any modification of an order (e.g., changing the dose) would result in the existing order being voided and a new order created by the API.
Thanks for doing this, Roger.
We debated whether or not to include draft orders in the orders table and decided against it. At Regentrief, we do this (put drafts in the orders table). The advantage is that drafts are ensured to follow the same model & can use much of the same tooling. The disadvantage is that all API methods (or any direct access) must know about & filter out draft orders. As it stands, the assumption is that all orders created via the API represent activated orders.
-Burke