API Support for Order Entry (Design Page)

Background

Order entry is an important part of an electronic medical record system.  To date, OpenMRS has provided minimal support for orders within the database, since our initial focus was on around data (observation) gathering and reporting.  As OpenMRS implementations have grown, more and more have found the need for support of orders within the system.  Our goal is to create enterprise-quality support for order-entry within OpenMRS.  We begin with the underlying API (programmers interface) and with a focus on building a foundation upon which modules can build/innovate/discover various ordering paradigms.

Scope

Orders are requests made by providers for actions to be carried out, including scripts to be given to the patient, tests to be run on the patient, procedures to be performed on the patient, doctors the patient should go see, requests to discontinue something previously ordered, etc.  While it's helpful for the system to know when/if these requests have been carried out, it is not the job of the EMR's order service to handle all of the actions needs to fulfill the request.  In fact, in many cases the actions taken to fulfill these requests (orders) will be managed by applications external to the EMR (e.g., prescriptions dispensed by a pharmacy system interacting with an inventory system, labs performed within a laboratory system to fulfill the requested tests, etc.).  The primary job of the orders service is to manage the metadata needed to help generate the orders, record the orders, and maintain the list of active orders.

Our goal is to provide an order entry service capable of supporting simple outpatient orders, focusing initially on medication orders and tests but allowing for other types (referrals, nursing, etc.).  While starting with outpatient orders, we want a design that will be able to gracefully grow into support for inpatient orders as well as supporting concurrent inpatient and outpatient orders (i.e., support for orders stored on a single server for the same patient across more than one care settings).

We are taking a pragmatic approach, realizing that our design will not cover every possible attribute or need, but will cover at least 80% of the use cases & needs within resource-constrained environments, focusing on those items that implementations need most now.  These include:

• Ability to define which concepts are orderable (what items in the dictionary represent potential orders)

• Ability to pre-define sets of orders (order templates) – e.g., to support ordering of pre-defined regimens.

• Support basic medication orders and simple test orders.

• Allow for modules to introduce new types of orders.

• Answer the question: what are the active orders for this patient?

Glossary

• active orders – all orders for a patient that have been signed/activated and have not been discontinued or expired. Note that orders that are post-dated (have a start date in the future) are still considered "active", since the request is active even if the future action to fulfill the request is not yet.  See Active Orders (Design Page).

• complex dosing – this is the opposite of "structured dosing."  For medications, complex dosing is when the dosing instructions cannot fit neatly within the structured dosing fields and therefore must be stored as free text.

• instruction template -- a pre-defined set of instructions for a specific order, used to present choices for common instructions and/or indication-specific instructions for providers as an alternative to writing the instructions manually each time.

• order – a request from a provider to do something for/to a patient

• order action – the action being taken on an orderable ("new" may be implied; other actions would include "discontinue", "revise", "continue" to continue without generating a new prescription, "renew" to continue by generating a new prescription, "supplement" to perform a one-time request that should not affect a standing order for the same orderable).

• order group – use to record the source of orders that are placed as groups of orders (i.e., chosen from an order set, such as a drug regimen) to assist with subsequent management or reporting of the orders (e.g., a drug regimen of three drugs chosen by the provider as a group instead of ordered individually would be recorded as three orders within an order group pointing to the regimen order set as the source).

• order number -- this is a unique identifier generated for an order and passed to ancillary systems so that results & events related to the order to be connected to the original order (i.e., HL7's placer number).  Order numbers must be unique across all orders generated by the system, but the algorithm or format of the number could be implementation-specific.

• order set – an order set represents a pre-defined list of order templates to be used in certain situations (e.g., pre-defined drug regimens, a set of common orders for treating viral gastroenteritis, etc.)

• order template – an order template represents a single, pre-defined order, which may include choices and/or defaults for the various components of the order.  Templates allow providers to generate structured orders quickly by picking a template from a list or changing only one or two components without having to manually complete every component of the order.

• order type – defines the category of the the order (e.g., drug, test, referral, activity, diet, nursing, call order, letter, handout, etc.)

• order validator – used to check the validity of an order given the current ordering context (setting, user, item being ordered, etc.); multiple order validators may be chained together so that each validator can focus on a specific business rule.

• orderable concepts – all orders are concept-based, meaning that all orders are based on a concept within the system's concept dictionary.  Only certain concepts are valid for defining an order (e.g., while you might want to order a "CD4 COUNT", you should not be able to order the concepts "HIV POSITIVE" or "YES").

• orderer -- the person (provider) responsible for the order.  There must always be someone accountable for the order (generally, the person making the request who may not always be the same as the person entering the order into the system)

• orders – our "order" is modeled much like the HL7 order event.  Each order represents a clinical provider's intent for something to happen for/to a patient, including drug prescriptions, tests, referrals, etc.

• PRN – used in drug prescriptions, derived from the latin "pro re nata", and stands for "as needed."  For example, a pain medication may be administered "prn pain" or a sleeping medication administered "prn insomnia."  In the API and data model, we use the phrase "as needed" to help developers understand the meaning.

• structured dosing – for drug orders, instructions that are codified within discrete fields (dose, dose unit, route, frequency, duration, duration units, PRN condition, and administration instructions)

• urgency – when and with what urgency an order should be carried out (e.g., "STAT" to drop everything and do immediately, "routine", "scheduled" on a certain date or at a certain time, "conditional" to perform when certain conditions are met

Structured Dosing vs. Unstructured Dosing

Drug orders include dosing information that explains how much, in what manner, and in what frequency the medication should be administered.  Specifically, the attributes of a medication order that define the structured instructions are:

Simple Structured Dosing

The structure for simple dosing (e.g., 1 tab orally once daily) is reflected in the data model and expected to be filled when the dosing type is "SIMPLE".

• Dose – (required) number of tab, milligrams, etc. to be given

• Dose units – (required) unit of the dose (tabs, milligrams, etc.) for a single dose

• Route – (required) how the dose is to be given (orally, intravenous, etc.)

• Frequency – (required) how often the dose is given

• Duration – (optional) how long the medication should be given (number)

• Duration units – (optional) the units for how long the medication should be given (minute(s), hour(s), day(s), week(s), month(s), ...)

• As needed – (defaults to false) true if the medication is PRN (taken only when needed)

• As needed condition – (optional) the condition when the med should be dosed (e.g., "pain" when something is dosed only when pain occurs)

• Administration instructions – (optional) free text instructions on how to administer the medication (e.g., "take with a full glass of water")

Free Text Dosing

In some cases, the provider may need to provide very complicated dosing instructions that cannot fit into any of the existing structured forms.  In that case, the dosing type is "FREE TEXT" and the free text dosing instructions are placed within the orders.instructions field.

Requirements

First Priority

• Get orderable concept(s) ± limited by query string

• Allow creation of simple drug and test orders.

• Revise orders.

• Discontinue orders.

• Get order(s) by patient ± within date range.

• Get order(s) by encounter.

• Get order(s) by concept.

• Get order(s) by ordering provider.

Second Priority

• Order attributes

• Order groups and order sets

• Allow grouping of orders (to support regimens and/or arbitrary groupings)

• Get active order(s) by patient ± as of a specific date.

• Get order by order number.

• Get order(s) by group

• Get all order set(s), order set(s) by name, or order set(s) by concept.

• Proof of concept of a module adding its own new type of order, with proper inheritance