Page Comparison

...

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
• Care Setting, null is allowed OrderServiceImpl.saveOrder will either set it or reject the order
• Concept (what is being ordered)
• Instructions (not necessarily orders.instructions attribute, can be satisfied by dosing instructions for drugs or clinical history for tests)
• Orderer
• urgency
• startDate
• action
• orderType, null is allowed OrderServiceImpl.saveOrder will either set it or reject the order
• 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

...

• Dosing type
• asNeeded
• Instructions corresponding to dosing type
  • Simple: dose, dose units, route, frequency, and as_needed (defaults to false)
  • Free text: orders.instructions

  • Other dosing types (i.e., not simple or free text): drug_order.dosing_instructions

• For outpatient care settingsettings: 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

• the order Stopped orders cannot be revised – i.e., if an order is being revised or , the previous can't 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.

Not sure how all this will work with retrospective data entry of orders

We might want to implement these in the future:

...

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.Other Validation Rules