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

OrderEntryService

OrderValidator

DrugOrderValidator

TestOrderValidator