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.

...

• 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

...