Validating Orders
Background
There are many factors that go into determining whether or not an order is valid, including many different context-specific details (what's being ordered, type of order, care setting, orderer) and often incorporating implementation-specific business rules.
Basic Validation
Required for All Orders
Patient
Encounter
Concept (what is being ordered)
Orderer
Urgency
Start date
Assumed defaults
Order ID – assigned by the API
Care Setting – set to the default Care Setting within the user context
Order type – inferred from the concept being ordered, i.e., getOrderTypeByConceptClass(order.concept.conceptClass)
Urgency – API assumes ROUTINE
Action –API assumes NEW
Start date – API assumes date created
Creator – API assumes current user
Date created – API assumes now
Drug orders
Dosing type
asNeeded
Instructions corresponding to dosing type
Simple:
dose
,dose units
,route
,frequency
, andas_needed
(defaults to false). Any unstructured instructions go intodrug_order.dosing_instructions
Free text:
drug_order.dosing_instructions
Other dosing types (i.e., not simple or free text):
drug_order.dosing_instructions
For outpatient care settings: quantity, quantity units, and number of refills (not required for inpatient drug orders)
Other Validation Rules
Concept (and Drug for drug orders) cannot differ on revised orders (when previousOrder != null, order.concept must match order.previousOrder.concept)
For discontinuation orders with a previous order, concept and its previous order's concept must be the same
The dateStopped of a previous order should be the same as the start date of the revised or discontinued order
Unit concepts(quantity, duration and dose units) should be of units concept class(es)
Frequency concepts should be of frequency concept class
order.startDate can't be before its encounter's encounterDatetime
Stopped orders cannot be revised – i.e., if an order is being revised, the previous order cannot be a DC order
Java Class and order type for a dicontinuation or revision should match that of its previous order should match
scheduled_date can only be specified with the correct urgency, currently the only supported urgency is ON_SCHEDULED_DATE but there could be others added
order.startDate can't be in the future
order.concept.conceptClass should be in order.orderType.conceptClasses respecting order type hierarchy i.e the check should happen recursively for all ancestors if not found on the immediate order type.
order.orderType.javaClassName should match order.class.name, taking into consideration class hierarchy.
For any field that has a corresponding units field, if it is specified then automatically the matching units field becomes required, i.e. if quantity is provided, quantityUnits becomes required, if duration is provided, durationUnits becomes required etc.
We might want to implement these in the future:
Cannot order retired orderables e.g retired drugs or concepts? In case of retrospective data entry dateStarted should come before dateRetired
Patient can't be on the same order at the same time, for drug orders, exception is the patient can be on different formulations but same concept.
Extensible Validation
Ultimately, implementations will need to be able to introduce their own business rules for order validation. Some examples of common business rules:
Requirements may vary based on the care settings (e.g., outpatient drugs must specify quantity & refills, while inpatient drugs do not)
Some specific drugs cannot be refilled
Some radiology tests require that laterality be specified, while many others laterality does not apply
Validator Chaining
In order to accommodate implementation-specific business rules that may vary based on context, OpenMRS should implement some basic "out-of-the-box" business rules in a manner that can be adapted by implementations. A validator chain would invoke 1-to-N order validators, passing the current order along with the ordering context (Encounter, CareSetting, Orderer, User) and collect a list of validation errors that could be passed back to the user.