...
- Patient
- Encounter
- Care Setting, null is allowed OrderServiceImpl.saveOrder will either set it or reject the order
- Concept (what is being ordered)
- Instructions
- Orderer
- urgency
- startDate
- action
- orderType, null is allowed OrderServiceImpl.saveOrder will either set it or reject the order
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
...
- For discontinuation orders, 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
- Cannot order retired orderables e.g retired drugs or concepts? In case of retrospective data entry dateStarted should come before dateRetired
- 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 being revised or the previous can't be a DC order
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.
Class type for DC and drug order should match, same for revision
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:
- 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:
...