[Drug entry] Mapping OpenMRS Order statuses to FHIR

Development
, , , ,
1

Hi all,

I’ve been looking into working on FM2-476 which about adding support of searching MedicationRequests based on status.

The OpenMRS data model has limited support for statuses in comparison with FHIR:

RECEIVED, IN_PROGRESS, EXCEPTION, COMPLETED

Plus “maybe” UNKNOWN which is just implied at the translation layer.

FHIR on the other hand supports:

ACTIVE,
ONHOLD,
CANCELLED,
COMPLETED,
ENTERED_IN_ERROR,
STOPPED,
DRAFT,
UNKNOWN,

I’ve also peeked on FM2-480 which I suppose is about expanding the OMRS data model to support for the rest of the supported statuses by FHIR. Now considering our project goals for an MVP, we just need to support “Active”, “Complete”, “Cancelled” & “Returned” which can be achieved with the current data model except for “Returned” which isn’t a primitive status. That being said, for the MVP we are able work with the current data model in regards to MedicationRequest statuses. (Incase of any objections, kindly share)

Evaluation for "complete" status

I assumed that it’s simple as listing all orders within an encounter that have status with value “COMPLETE”. Quoting @mseaton from: [O3-1213] - OpenMRS Issues

For this ticket, the dispensing app should indicate that a particular Order is COMPLETED if all associated Orders have a status of “COMPLETED”. This should be written in such a way to support easily changing this business logic across the entire dispensing app, and for easily adding business logic around other statuses as need, supporting notions like “PARTIALLY COMPLETED” in the future, etc.

By associated orders you meant the Order.previousOrder tree? Or there is more to that including the Order.orderGroup?

OMRS status Can be Mapped to FHIR as
COMPLETED COMPLETED
IN_PROGRESS Which FHIR status can we map this to?
RECEIVED Which FHIR status can we map this to? What does it even mean?
EXCEPTION Not sure of the original usecase but maybe it’s close to ENTERED_IN_ERROR?

Calculated statuses

  1. ACTIVE
    In OpenMRS, the active status is evaluated on the fly basing on a couple of variables

  2. CANCELLED
    This status is based on whether the underlying Order was discontinued or not

  3. UNKNOWN
    The system doesn’t know which of the status values currently applies for this order

Any objections or comments on the above?

cc: @burke, @ibacher, @eudson, @PIH

1 Like
2

Hi @samuel34 ,

I’d like to hear what @burke and @ibacher have to say, and this might be worth spending some time discussing on a TAC or Platform call to go through in detail. The ticket you mentioned above - [FM2-480] - OpenMRS Issues - is really what this thread is trying to flesh out - how can we map the OpenMRS data model to each of the supported FHIR Medication Request Statuses.

I wouldn’t characterize it like that. Those statuses in OpenMRS are specifically fullfiller statuses. So they indicate the status from the perspective of the fulfiller, but if unfulfilled (or otherwise) need to consider the perspective of the orderer.

Not really. What this is talking about is a different type of status - a “prescription” status, which is more of a dispensing construct. On the dispensing UI, each of the rows represents a “prescription”, which is “all of the orders placed in a given encounter”. These may belong to an order group, but often/usually do not. In such a model, each individual order will have a status, and then the aggregation of these statuses will determine the overall “prescription” status. So we should not conflate the “status” field in the dispensing UI with the notion of an individual order status.

Overall, we need to identify 2 things:

  1. How do we map an individual OpenMRS order to each of the possible FHIR MedicationRequestStatus fields. This may require new modeling changes to OpenMRS core, or it may not. It certainly will require logic that combines both the Order status (status from the perspective of the orderer, including whether the order is active, discontinued, future, etc) and the fulfiller status, and possibly more computational statuses (for example, comparing the quantity/quantityUnits/numRefills on the order with one or more associated MedicationDispense records to see if the order is partially or completely filled).

  2. How do we determine the status to display on the dispensing UI based on the statuses of all of the orders contained in the encounter that a given row represents.

Mike

1 Like
3

That’s probably a good idea. There’s kind of a fundamental mismatch between FHIR’s model of how we track order status and OpenMRS’s.

From a pure-FHIR perspective, a MedicationRequest is just that: a request for a medication. As part of processing that request, a FHIR server might create one or more FHIR Tasks to track what’s actually happening with the request. That Task would track what happens with the request from the perspective of the fulfiller (likely resulting in a MedicationDispense resource). Once the MedicationDispense is completed (or stopped or declined) an appropriate update might happen to the MedicationRequest—depending on business logic.

In OpenMRS, we have various mechanisms to determine the status of an order (some combination of the Action, dateActivated, autoExpireDate, dateStopped, etc.) as well as the FulfillerStatus which is actually something different from FHIR’s concept of status for a MedicationRequest.

1 Like
4

OpenMRS orders includes all types of orders, including drugs orders, test orders, referral orders, etc. which align with FHIR’s MedicationRequest (drug orders) and ServiceRequest (everything else). When it comes to determining the status of an order, there’s a distinction between the state of the request (the order itself) and the state of the fulfillment of that request (e.g., result(s) for a lab test or dispensing events for a drug order).

I believe the statuses of RECEIVED, IN_PROGRESS, and EXCEPTION were created for lab workflows – i.e., to try to summarize the fulfillment of a lab test… which it is called a FulfillerStatus. Typically, labs report on the status of results (our Observations), which follow FHIR’s Observation statuses:

REGISTERED
PRELIMINARY
FINAL
AMENDED
CORRECTED
CANCELLED
ENTERED_IN_ERROR
UNKNOWN

This can be tricky, because a single order for a test can result in many results (observations) and each can have it’s own status. For example, ordering a Complete blood count might return a dozen results and one (e.g., Platelets) might still be in progress while the others have been resulted (final). I believe the OpenMRS Order.fulfillerStatus is an attempt to summarize the state of all observations connected to the test order and does not apply to drug orders. Whether you tried to summarize the state of administration or dispensing events, it won’t make sense in many cases, because drug orders can have multiple refills or be chronic drugs (where a single dispense event… even the “final” dispense event doesn’t mean the patient’s HIV or hypertension prescription is “completed”; these lifelong prescription are only completed when the patient dies or we discover a cure).

For orders in OpenMRS, we currently report isActive(), isDiscontinuedRightNow(), and isExpired(), but I don’t believe we have a separate property for the order status. Note, this is not the FulfillerStatus per @mseaton’s comments and mine above.

There are two options for FM2-480:

  1. Map the results of the methods to the status:

    • isActive() → ACTIVE
    • isExpired() → COMPLETED
    • isDiscontinued() → STOPPED
    • all three false → COMPLETED

    The extra work might be the need to search for orders by status, which would might require – for performance purposes – creating some queries that implement the logic for determining these statuses.

  2. We add an Order.status that combines the possible values across order types – i.e., a union of MedicationRequest statuses and ServiceRequest statuses:

    • ACTIVE
    • ONHOLD (can be harmful to patients if held orders are accidentally treated as active)
    • CANCELLED (at this point, we don’t know if any actions have been taken on the request)
    • REVOKED (I don’t think we have this capability)
    • COMPLETED
    • ENTERED_IN_ERROR (would require user effort to distinguish from cancelled or stopped)
    • STOPPED
    • DRAFT (we don’t yet have support for draft encounters)
    • UNKNOWN (if we add status, it should be known for every order)

    Given that the statuses we support (ACTIVE, COMPLETED, STOPPED) could be achieved with #1, it might be easier to go that direction.

FWIW, I started thinking through how we would use statuses for drug orders before I really understood the questions in this thread. I didn’t want to just delete the table, so here it is:

Status Description
ACTIVE Any order that has been submitted and has not been discontinued or expired.
ONHOLD We have explicitly avoided ONHOLD, since putting orders on “HOLD” is tricky business and has potential harm to patients if someone sees a medication in a list and doesn’t recognize that it should be withheld.
CANCELLED Based on FHIR’s definition, this is subtly different from STOPPED. It implies that the order was stopped before any actions were taken, which I’m not sure we can reliably infer. I would assume we would use STOPPED when an order is discontinued and only in a situation where the system was tracking & could reliably determine no actions had been taken could we consider using CANCELLED.
COMPLETED Orders that have expired or stopped because a fulfiller signaled the order had been completed (e.g., could apply to tests if a lab system reports the corresponding result(s) have been finalized).
ENTERED_IN_ERROR We could only use this is someone took the time to give a reason for discontinuing an order and specified it was entered in error. Even if we had this capability, it would depend on user effort that would be not be reliable.
STOPPED Orders that have been discontinued (i.e., a discontinue (D/C) order placed for the orderable).
DRAFT Unfortunately, we don’t yet have support for draft orders, although, it would be great to approach any code aware of the possibility of DRAFT orders being introduced in the future.
UNKNOWN I don’t think this should ever apply for our orders. Orders will always be ACTIVE, COMPLETED, or STOPPED… and hopefully someday possibly DRAFT.
1 Like
5

I think one thing we want to be clear on here is not just how we might map the FHIR MedicationRequest.status field to OpenMRS, but whether FHIR’s MedicationRequest.status would actually capture the information we’re interested in. As I understand things, the goal here is to be able to fulfil this design:

Screenshot 2022-09-08 at 13.42.39
Screenshot 2022-09-08 at 13.42.391082×903 155 KB

Especially the Status column there. It seems like “Active prescription” and “Complete” can be well-represented by the MedicationRequest.status field, but I’m not sure about how we would represent “Returned”. Have I got this right? @burke do you have any thoughts on that?

6

Hello all… sorry, just seeing this now (and this may have been what was discussed on the TAC call a couple weeks ago), after I already updated the ticket with some potential new mappings:

https://issues.openmrs.org/browse/FM2-480

Luckily, I think this lines up closely with what @burke mentioned in the above post.

Per the “Returned” status that @ibacher asked about, I think we need to continue to flesh that out, but I also think we’ve determined that the “return to prescriber” functionality is not MVP for Dispensing app, so I think we have also move forward with a “Phase 1” before figuring this out.

1 Like