Page Comparison

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.

...

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 mange manage the metadata needed to help generate the orders, record the orders, and maintain the list of active orders.

...

• saveOrder(...all required params...no Order object...)
  • used for inserts mainly
  • if called with a previously saved order, creates a new one with the new fields, doens't change the old one, and links the two orders using previous_order_number
  • (similar to saveObs())
• modifyOrder(Order old, Order new)
  • (implement this or no?)
• saveActivatedOrder(___, Provider/User?) ?? (or name this documentOrder() or saveDocumentOrder() or saveHistoricalOrder())
  • calls saveOrder, signOrder, activateOrder
• signOrder(Order, Provider)
  • Can we discern if the Provider is a Nurse vs MD here, or do we need multiple signOrder methods?
  • means setting date signed and signed by
• activateOrder(Order)
• fillOrder(Order, User)
  • calls following method with a urn
• fillOrder(Order, String) // if filler is not a user
  • means it was completed
  • if the order is not signed yet, throw an exception
• getActiveOrders(Patient patient, Class orderClass, CareSetting careSetting)
  • TODO: Should get Orders that are not yet stopped nor auto expired.
• getActiveDrugs(Patient patient)
  • TODO: Should get active DrugOrders that are not yet stopped nor auto expired.
• Order getOrderByOrderNumber(String orderNumber)
  • Gets the 'latest_version=true' order with this orderNumber
• List<Order> getOrderHistoryByOrderNumber(String orderNumber)  // or by Order object?
  • returns all orders, even ones discontinued, even old versions of the order
• List<Order> getOrderHistoryByConcept(Patient patient, Concept concept)
  • similar to previous, gets all Order objects that use this Concept
  • create and use an OrderHistory object for this?  Would keep the sequence/history of the Orders and convenience methods for how to look at them.
• discontinueOrder(Concept)
  • finds all active orders with this drug/concept and discontinues them

...

• NEW -- creating a new order
• REVISE -- modifying an existing order (e.g., changing dose of a medication, edits to instructions, etc.)
• CONTINUE RENEW -- continue Renew an existing order order(should this only apply to auto expired orders?) (e.g., providing another prescription for a chronic medication when refills run out)
• DISCONTINUE -- stopping an order

...

Drug Reference Mappings (Proposed by Wyclif)

Like Concepts, Drugs need to have looser mapping mappings to other terminologies as shown , see diagram below.

TODO (and notes)

...

public Drug getDrugByMapping(String code, ConceptSource conceptSource, Boolean includeRetired)
public List<Drug> getDrugsByMapping(String code, ConceptSource conceptSource, Boolean includeRetired)

TODO (and notes)

• Rename "Regimens" tab to "Drug Orders"
• "standard drug regimens" replaced by order sets and and templates in them
• When initially creating orders via a saveEncounter call, the orders should be in draft state.  A second call to sign all the orders is needed
• order_number, order_version, latest version are internally maintained, not to be entered by a user
• Don't link to the admin page edit screen from the dashboard.  add a small popup that only lets the user edit certain properties
• On dashboard, can change the dosage to "change" an order. (aka orders are linked via discontinue and new order)
  • aka, should not be able to change an activated order
• Make saveOrder smarter so that we can link/dc/etc orders if there are other ones that are related?
• Mutability needs to be researched, may be done for API 2.0, but not here
  • Order object properties should be mostly immutable. 
  • Encounter.orders should not contain mutable Order objects

Interested Parties

• Unlicensed user
• Unlicensed user
• Unlicensed userBurke Mamlin
• Ben Wolfe
• Paul Biondich
• Daniel Kayiwa
• Roger Friedman
• Unlicensed userMike Seaton
• Ashley Maher
• Unlicensed user
• Unlicensed userAndrew Kanter
• Wyclif Luyima

Assigned Developers

• Unlicensed userDaniel Kayiwa

Work Items

1. Add new objects and attributes to current order and drug order objects
2. Determine the feasibility of transitioning from current Orders to new orders
   1. If doable, add liquibase changesets, etc
   2. If impossible, investigate writing a one-time-use script or module to help implementations with the upgrade.  PIH has a lot of experience with orders, get feedback from them
3. Modify the Regimens tab to work with new order templating system
4. Update the simple order jsp pages to work with the new attributes
5. TBD: Write a module with more complex workflow possibilities. 

...

• How do we identify orderable concepts?  By class(es)?
• Do we treat the orders table as a transactional table (essentially write-only) vs. creating separate table(s) for storing revision history?
• Can we support draftorders & encounters & visits – i.e., unsigned work – within the same tables?  Or do we persist these data elsewhere until signed?
  • PROS:
    • Avoid creating separate table(s) for persisting drafts
    • Increases potential in the future to see or react to concurrent drafts
  • CONS:
    • Drafts must be filtered by API
    • Old drafts will need to be cleaned
• We'll need to agree on order workflows – i.e., what are the valid states of an order.
• Our first pass at medication orders assumes a single clause for structured dosing.  Eventually, we may want to support multiple clauses linked with AND/OR/THEN to allow for structured representation of more complex medication orders.
  • Support for multiple clause structured dosing could be supported within the data model by adding preceding_order_drug_id (to link to preceding clause) and conjunction (to represent join as AND vs. OR vs. THEN).  More complete representation of structured dosing clauses would probably require moving structured dose into a separate order_drug_dosing table.

See Also

• Discussed on the 2011-02-03 Developer Meeting

Associated Tickets

...