Order Entry Module Design
We did not release this module. Ultimately, we introduced a new Order Entry API in OpenMRS Platform 1.10.0, and there is no module to add this support in earlier OpenMRS platform versions.
Background
A new 'Order Entry' module will be authored to provide a new API and features necessary to manage patient specific orders, the module is intended to be a cleaner version of the existing order entry API with several additions and subtractions. For more background information, please visit api support for order entry page. This module will use the "org.openmrs" namespace, rather than the conventional "org.openmrs.module" namespace in order to more easily support the goal of eventually incorporating this module into core. By keeping it as a module initially, this allows implementations running older versions of OpenMRS (1.7, 1.8, 1.9, etc) to take advantage of, and test out, this work, without requiring them to upgrade. It also will allow the module to evolve at a different pace than the core code.
The module will use existing orders tables, installing the module will essentially lead to modification of the related tables,
Can we have the OrderService in core marked as deprecated prior to releasing 1.9?
Module id: orderentry
Module name: Order Entry
Package namespace: org.openmrs.orderentry
Module design
We are getting rid of the OrderType class including the associated database table, the broader categorization of will by the concept class of each order's backing concept. A more granular break down of these can be done through attribute types. (Though this is not supported in older versions)
Order
( * = required)
class Order extends BaseOpenmrsData{
public enum OrderAction {
DISCONTINUE, ORDER
}
*Integer orderId
*Patient patient
*Concept concept
*String orderNumber
String previousOrderNumber
*OrderAction orderAction
*Date startDate
Date autoExpireDate
*Encounter encounter
String instructions
*User orderer
Boolean discontinued
User discontinuedBy
Date discontinuedDate
String discontinuedReason
}
DrugOrder
class DrugOrder extends Order{
Drug drug
Concept concept;//should be drug.concept if drug is not null
Double dose
String doseUnits
Boolean isStructuredDosing
Double strength
String strengthUnits
Integer quantity
String quantityUnits
String frequency
String brandName
String dosageForm
String route
Boolean asNeeded - Indicated PRN
String asNeededCondition
String additionalInstructions
Integer duration
String durationUnits
Integer numRefills
}
TestOrder
class TestOrder extends Order{
Concept specimenSource
Concept laterality
String clinicalHistory
}
Orderable
Marker interface for things that a User can order
BaseOrderable
Base implementation of the Orderable interface, should define the properties and provide the default implementation of the inherited methods
Is Drug.concept nullable?
SimpleOrderable
Acts a wrapper for a concept or Drug(if drug.concept is nullable) with concept class as 'Drug' or 'Test' or 'Misc Order' or a Drug with no