/
2011 Initial attempt at API Support for Order Entry

2011 Initial attempt at API Support for Order Entry

Jul 25, 2018

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).

 

Scope

 

Our goal is to provide an order entry service capable of supporting outpatient orders, focusing initially on medication orders but allowing for other types of orders (tests, referrals, 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.

 

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.

 

Definitions

 

  • activation – an order is "activated" at the point that it can be carried out (filled) – i.e., in a paper-based system, an "activated" order is one that has been written in ink and signed.  In many cases, signing & activation occur within in a single step, where, for example, signing an order also makes it immediately available to be carried out.  In other cases, signing & activation may occur in discrete steps.  For example: in some clinical workflows (especially inpatient settings) certain orders (like admitting, discharge, & transfer orders) may be created & signed prior to being activated.  When verbal orders are created, they may be activated before being signed by the ordering provider.  "Activated" and "active" have different meanings, see the note below on "Activated vs. Active".

  • order number – this is an identifier generated for a given order and shared by all revisions (if any) of that order.  The order number is passed to ancillary systems in order for results & events related to the order to be connected to the original order.

  • order filter – filters determine which properties (fields) available within a given context.  Similar to order validators, filters can be chained together to apply specific business rules based on the current context (user, setting, patient, item being ordered, etc.).  For example, if refills are not allowed for opiates then an order filter could remove "refills" from the list of available properties when an opiate is being ordered.

  • order group – orders may be placed within groups to assist with subsequent management or reporting of the orders (e.g., a drug regimen of three drugs may be placed within an order group).

  • order set – an order set represents a pre-defined list of orders 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 is a document (e.g., XML) describing a single order, which may include choices and/or defaults for the various components of the order – i.e., a pre-defined order.  templates allow providers generate structured orders without having to manually complete every component of the order.

  • order type – there are pre-defined types of orders (e.g., medications, tests, referrals, activities, diet, 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.

  • order version – to keep track of different revisions of the same order

  • orderable concepts – 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 an "HIV POSITIVE" or a "YES").

  • 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.

  • signing – signing of an order represents either documentation of an existing signature or – more commonly – the electronic signature provided by a user

  • urgency – specifies when the order should first occur (e.g., stat/immediately, routine, on a specific date, etc.)

 

"Active" Orders

 

There can be many interpretations of "active" orders (e.g., which medications have been ordered, which medications are being filled, which medications are being taken) and these are not always identical lists.  There can also be differences based on context – e.g., inpatient medications vs. outpatient medications.  Within the order entry API, we are focused on orders, so "active" refers to those things that have been ordered, should have already started, and have not yet ended/expired.  Knowledge about which orders are actually being followed (e.g., medication adherence, prescription dispensing data, etc.) are outside of the scope of the first pass at a generic order entry API.  For example, medication reconciliation can be a complete project in its own right, taking into consideration adherence, dispensing data, orders from external systems, and orders placed through the order entry API.

 

"Activated" vs. "Active"

 

It's possible for an order to be "activated" (available for filling, no longer modifiable) but not yet "active."  For example, an order can be signed & activated with a start date two weeks in the future; in this case, the order is "activated" (signed & can no longer be modified, only discontinued & replaced if needed) but may not be considered an "active" order until the start date is reached.  We may end up wanting to consider future tests (with a future start date) as "active" (or let implementations decide on which behavior they prefer, if that can be done without complicating the API).

 

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.  The dosing information can be collected in either a structured (discrete values for each component) or unstructured (free text) format.  While structured dosing information allows for valuable calculations (e.g., how much medicine the patient will need and/or how much the pharmacy must order to maintain inventory), not all implementations need this level of detail.  Some implementations will never need the detailed dosing information and can function fine with free text instructions for all orders, some implementations may wish to pick & choose when they structure information vs. use free text, and other implementation will expect fully structured dosing information for every drug order.  Allowing for both structured & unstructured dosing of medication allows OpenMRS to adapt to the needs of the implementation and prevents our API from assuming everyone will order medications with the same level of detail.  Allowing for unstructured dosing also provides a mechanism for handling complex dosing instructions that cannot be expressed in simple terms (e.g., take 2 pills in the morning and 1 pill in the evening).

 

Requirements

 

1.10

 

  • Allow creation of simple drug orders.

  • Revise orders.

  • Discontinue orders.

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

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

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

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

  • Get order(s) by encounter.

  • Get order(s) by concept.

  • Get order(s) by ordering user.

  • Get order by order number.

  • Get order(s) by indication.

  • 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

 

Post-1.10

 

  • Advanced order set definitions (e.g., exclusion criteria)

  • Ability to filter orders by care setting – e.g., get all inpatient orders vs. all outpatient orders.

  • Support for order alerts (drug-drug interaction, drug-diagnosis interaction, allergy, etc.)

  • Support for additional order types (diet orders, referrals, activities, etc.)

  • HL7 support (inbound and outbound orders)

  • Order tagging

  • Mapping to standardized drug terminologies

  • Mapping to standardized drug terminologies

  • Support for multiple dosing clauses for drug orders (e.g., with AND/OR/THEN conjunctions like the NHS Dose Syntax).

  • ... and much more.