Working on Dispensing, I’ve discovered that in FHIR2 we don’t have a good way for modelling “Discontinue” orders in OpenMRS.
Overview: in OpenMRS, when an Order is cancelled, a new “Discontinue” order is created (the idea being that this “Discontinue” order may need to be passed on to downstream systems).
Currently, when orders are requested via REST FHIR2, discontinue orders are returned just like any other order, with status simply set to “Uknown”. (and in fact in the fleding Dispensing app are showing up as if they are orders to be fulfilled!)
We need to mark these orders as “Discontinue” orders, and it seemed like the right place to do this might be the “doNotPerform” boolean in the MedicationRequest model?
The “intent” also seems like a potential place to do this, but I don’t see a relevant category.
(Setting the “status” as “Cancelled” would not be correct, because that should be the status of the original order that was cancelled by the “discontinue” order, not the status of the discontinue order itself)
Thanks @burke ! Do you agree with setting the “doNotPerform” boolean as well? (which is defined as "
If true indicates that the provider is asking for the medication request not to occur.")
My concern with setting the status of “stopped” would be that it would be a bit of double negative, flagging as “stopped” (status) an “order” (intent) that “asks for the medication request not to occur”. (thereby saying “go ahead and dispense based on the original order”).
(From a practical standpoint with Dispense, it doesn’t really matter to me, because I’d just be filtering out all the “doNotPerform” requests, but as I understood it a “Discontinue” order was developed specifically for instances of communicating with downstream ordering systems).
Technically, I’d think the status of the original order should be stopped. If there’s really an order to discontinue a medication, that order, it seems to me, is actually completed once the original order is stopped (because the demand in the order has been fulfilled). (We also would have no way to differentiate between discontinue orders that had, themselves, been cancelled, e.g., by a new order).
I had been under the impression that the “doNotPerform” was mostly there to indicate orders that shouldn’t be processed, but the text is ambiguous and implies it could be used for this case…
Actually, re-reading it, I think this might be exactly the reason for the doNotPerform boolean. I was thinking of it the way orders in financial systems sometimes have a “do not process” attribute to indicate test orders that usually test system integration.
In the OpenMRS Order API, if you try to “discontinue” an order, the API sets the “date_stopped” on the original order (logic may be a little more complex than this, but generally that is what is done) and issues a new “discontinue” order. “Completed” does sound like the correct state for this new order (with the “doNotPerform” boolean set as well) since OpenMRS automatically handles updating the existing order.
I’m not sure about the interpretation of MedicationRequest.doNotPerform. I don’t see this as a way to communicate to stop an earlier request; rather, not to act on the current request. For example, sometimes we need to get a medication on a patient’s list of active medications when they don’t need a new prescription (i.e., they already have the medication, but it didn’t get onto the med list because the prescription was given outside the EMR, handwritten during downtime, etc.). So, I would interpret “doNotPerform” as a way of adding a medication to the med list without trigger a prescription workflow and not a way to indicate a request to discontinue an order.
In HL7 v2, there was a DC order control code to indicate a discontinue order. I’m not sure where this is in FHIR. From this googled table, it appears to have been mapped to ServiceRequest.status, which would’ve become MedicationRequest.status for meds. While the value set for MedicationRequest.status appears to provide values for things that have already happened (i.e., “stopped” instead of “stop!”), MedicationRequest.status = “stopped” still feels like the closest to the discontinue order.
I agree. But I don’t see where FHIR represents a “discontinue order” separately. It looks like discontinuation is the act of changing the status to stopped.
As a related aside, we also need to support discontinuation of orders that are not active. For example, the patient or nurses believe the patient should be getting a medicine you know should no longer be given and is not on their med list (whether due to miscommunication, orders happening outside the EMR, paper orders used during a power failure, etc.). In this case, you would still like to be able to explicitly request the (non-active) medication order be stopped. Presumably, with FHIR this would be the creation of a new (not currently active) order with a status of stopped.
Oh, yeah. You’re completely correct on this and a discontinuation order is probably not how I’d have chosen to represent this in FHIR, because, yeah, ultimately, the FHIR representation of this is just to update the original order with an appropriate status… But I’m sort of working from the perspective that we already have these discontinuation orders to implement the business logic and that unwinding that is more disruptive. One thing I was unclear on is whether, from a clinical workflow perspective, it makes sense to explicitly have orders to discontinue other orders, e.g., as documentation for why an script was stopped.
We could, of course, use an extension to indicate something like “is a discontinuation order” and then provide a custom search parameter (to allow Mark to filter these requests). I suppose, we could also just modify the FHIR2 module to ignore these discontinuation drug orders, but we might, eventually, want a way to discontinue a MedicationRequest via FHIR and if just changing the status doesn’t trigger the right business logic, we’d need to figure out how we represent these orders.
I agree that “doNotPerform” is not necessarily targeted at this specific case, but it is the closest to an standard attribute that indicates that something should not be done.
PS I’m not sure how this works in v2-land, but in FHIR, if we want to add a med to a patient’s active med list, we could just add a MedicationStatement resource without the need for a new order at all.
I guess if a FHIR Medication Request doesn’t currently have a way to model a “Discontinue Order” my thought would be to just exclude them from the search results, at least for now. Adding a custom extension at this point seems suggestive that we either aren’t modelling things properly in OpenMRS or aren’t understanding the FHIR model properly, but I could be convinced.
Modelling a discontinue order as an order with a status of “stopped” doesn’t work because we end up with two Medication Requests with status stopped, the original order (after being updated) and the discontinue request, and no way to distinguish between them. Having the default behavior return both like this seems incorrect to me.
This seems like a different use case, where a doctor is explicitly issung an order not to give patient a drug, as opposed to “I prescribed this in error” or “I made a typo in my order”… maybe the former is the real motivation for “discontinue” order, but in OpenMRS, orders are (more or less) immutable, so we end up with a discontinue or revise order in all cases.
Alright, so new wrinkle. I found a thread on the FHIR chat discussing the doNotPerform which suggested a different use-case: that is an order to not give a patient a particular medication (“do not give the patient ACE inhibitors”), which is quite different from “stop this order”. I’ve tried to craft a question in the thread aimed at what I see to be the heart of the issue (“How do I represent a request to cancel a previous authorization?”). Will report back when I get a response.
A discontinue order is typically represented by Task, where the focus is the order to be ended. An order to “not perform” is actually different from an order to discontinue. Note that the “discontinue order” is generally only necessary when the source system doesn’t have the ability to just change the status of the target order immediately. The same process can be used to request that an order be suspended or resumed.
I guess from a purely FHIR perspective, that makes some sense, though from an OpenMRS perspective, it’s likely a bit of a pain to implement, since I’m not sure how we map our already-defined process (other than DC orders probably shouldn’t be being returned from the medicationrequest endpoint at all, which kind of obviates the initial issue Mark was having).
Thanks @ibacher , glad you checked, as it sounds like @burke was spot-on about “doNotPerform” being incorrect.
I’d be fine, actually, with not returning the DC orders from the medication request endpoint, and we could ticket potentially implementing them as “Task” in the future.
