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
All orders
- Patient
- Encounter
- Care Setting
- Concept (what is being ordered)
- Instructions
- Orderer
Assumed defaults
- Order ID – assigned by the API
- 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
- Drug (formulation)
- Dosing type
- Instructions corresponding to dosing type
- Simple: dose, dose units, route, frequency
- Free text:
orders.instructions
- For outpatient care setting: quantity, quantity units, and number of refills (not required for inpatient drug orders)
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.