Wiki Spaces
Documentation
Projects
Resources
Get Help from Others
Q&A: Ask OpenMRS
Discussion: OpenMRS Talk
Real-Time: IRC Chat | Slack
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 State |
|---|---|---|---|---|
| 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 (requires a new order?) | none | PENDING | |
| PENDING | Doctor reviews and submits the order for immediate execution (requires a new order?) | ACTIVATE | ACTIVE | |
| ACTIVE | Expire date or auto-expire date reached, or both dates are null | none | EXPIRED | |
| ACTIVE, EXPIRED | For referral-type orders, facility has taken all actions preparatory to referral | READY | ||
| ACTIVE, EXPIRED | For non-referral-type orders, acknowledged but awaiting action | PENDING | ||
| ACTIVE, EXPIRED | Indication received that order is being executed | IN PROGRESS | ||
| ACTIVE, EXPIRED | Some but not all anticipated results received | PARTIAL | ||
ACTIVE, | All anticipated results received | COMPLETED | COMPLETE | |
| ACTIVE, EXPIRED | 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 Previous State | Activity | Order 2 Action | Order 1 Next State | Order 2 |
|---|---|---|---|---|
| GENERATED | Doctor reviews and rejects the order | REJECT | REJECTED | COMPLETE |
| PENDING, ACTIVE | Doctor cancels order | CANCEL | CANCELLED | COMPLETE |
| PENDING, ACTIVE, GENERATED | Doctor reviews and writes a different order for later execution | MODIFY | MODIFIED | PENDING |
| PENDING, ACTIVE, GENERATED | Doctor reviews and writes a different order for immediate execution | MODIFY | MODIFIED | ACTIVE |
Overview
Content Tools
Feedback on this page? Questions?
Copyright © 2004-2016 OpenMRS Inc. By using this site, you agree to the OpenMRS Privacy Policy.
Text is available under the Creative Commons 4.0 International Attribution License (CC BY 4.0).
Software is available under the Mozilla Public License 2.0 with Healthcare Disclaimer (MPL 2.0 HD).
"OpenMRS" is a registered trademark and the OpenMRS graphic logo is a trademark of OpenMRS Inc.
3 Comments
Burke Mamlin
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
Roger Friedman
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?
Burke Mamlin
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.