"Completing" Active Orders

@burke

I’ve been working on upgrading our radiology module to work with the new Order API and have been trying to understand the concept of an “active” order. For a test order, after the test have been performed, shouldn’t the order switch to some other state (“complete”)? I don’t see a way for an order to get out of the active state other than expiring or being discontinued.

Thanks, Mark

We had order.status in earlier versions of the Order Entry design to track states of the order, but it was left out in the process of simplifying order entry. As a result, the current order entry service is focused on recording & managing orders (the requests) and does not (yet) support tracking of order completion.

@darius, are we ready to add order.status back in now? :wink:

We definitely need a way to mark a test order as being fulfilled, and thus inactive.

Our specific case right now is in Mirebalais where we have OpenMRS driving a PACS system, so you’d order an xray in OpenMRS, which sends an HL7 message to the PACS, and when someone reads the xray an HL7 message comes back with the report. (I presume we could also get a message when the xray is actually taken, but we didn’t need this before.)

The quick fix for us is to just set the order to auto_expire after a second (it will still trigger the message to PACS). This will let us preserve our existing functionality.

The better solution would be if the messages from the PACS system could update an order status. This would let us stop people from ordering a duplicate xray if one is already ordered/in-progress.

Peeking at the FHIR model, it’s a bit more complex than just a single order.status, i.e. DiagnosticOrder has 0-n events. We don’t need that complexity for the current Mirebalais use case.

Let’s discuss this on the design call tomorrow. (If there’s buy-in for a design on status that we can backport to 1.10.x, then we may be able to work on this.)

1 Like

Browsing the FHIR model, it seems that order.status within FHIR is used differently in tests and drugs — i.e., they have different possible values for status.

Test orders (DiagnosticOrder.status) uses diagnostic-order-status value set:

  • requested
  • received
  • accepted
  • in progress
  • review
  • completed
  • suspended
  • rejected
  • failed

Drug orders (MedicationPrescription.status) uses medicationprescription-status value set:

  • active
  • on hold
  • completed
  • entered in error
  • stopped
  • superceded

Since they have not fully developed order resources within FHIR (e.g., referrals, diet, activity, etc.), we don’t know for certain how status of those will be modeled.

From a quick glance, it appears that we may be in decent shape to have an order.status if we, instead of trying to define one workflow (set of states) for all order types, allow the possible values for status to be dictated by the order type.

As an aside, we (and FHIR) need to keep repeating orders in mind, where an order may be fulfilled multiple times a day for a week or more while remaining “active”.

Dear @burke,

is this topic still of interest, any updates? Or currently not so relevant.

@teleivo, it looks like they found a workaround to auto-expire orders. While I’d be happy to assist in realizing such features in a way that was acceptable to implementations, I’m not aware of anyone pushing this forward at the moment.