Wiki Spaces

Documentation
Projects
Resources

Get Help from Others

Q&A: Ask OpenMRS
Discussion: OpenMRS Talk
Real-Time: IRC Chat | Slack

Projects

Page tree
Skip to end of metadata
Go to start of metadata

 

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
State

ActivityActionFulfillmentNext
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
DRAFTDoctor reviews, edits and submits the order for immediate executionCREATE ACTIVE
DRAFTDoctor reviews, edits and submits the order for later executionCREATE PENDING
DRAFTDoctor reviews and rejects the ordervoid none
GENERATEDDoctor review, edits and submits the order for immediate executionACCEPT ACTIVE
GENERATEDDoctor reviews, edits and submits the order for later execution

ACCEPT

 PENDING
PENDINGPre-execution delay expiresnone ACTIVE
PENDINGDoctor reviews and edits the execution time for later execution
(requires a new order?)
none PENDING
PENDINGDoctor reviews and submits the order for immediate execution
(requires a new order?)
ACTIVATE ACTIVE
ACTIVEExpire date or auto-expire date reached, or both dates are nullnone 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,
EXPIRED

All anticipated results received COMPLETEDCOMPLETE
ACTIVE,
EXPIRED
Less than all anticipated results received but no further results expected  COMPLETE

The diagram below is in progress (not complete ... yet)!

Single Order Workflow

Two-Order Actions

Order 1
Previous
State
ActivityOrder 2
Action
Order 1
Next State

Order 2
Next State

GENERATEDDoctor reviews and rejects the orderREJECTREJECTEDCOMPLETE
PENDING,
ACTIVE
Doctor cancels orderCANCELCANCELLEDCOMPLETE
PENDING,
ACTIVE,
GENERATED
Doctor reviews and writes a different order for later executionMODIFYMODIFIEDPENDING
PENDING,
ACTIVE,
GENERATED
Doctor reviews and writes a different order for immediate executionMODIFYMODIFIEDACTIVE
  • No labels

3 Comments

  1. 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

    1. 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?

      1. 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.