Considering that orders are generally immutable, I was wonder if there was a best practice for managing order fulfillment. In particular:
For a Test Order, tracking:
- when a specimen has been collected for an order
- when the results have returned for the specimen
For a Drug Order, tracking:
- When the drug has been dispensed to the patient
Maybe I’m missing something, but there seems to be no obvious way to track these things?
I’m hoping that @burke can comment on this. IIRC he feels that this should not be modeled in openmrs-core. (Though I don’t really agree with that.)
I’m 100% for tracking order fulfillment; it’s one of the holy grails of order entry. What I’m not excited about is building into core the expectation that fulfillment data exist for order entry to operate properly – i.e., we cannot assume results will only be reportedly internally or will always have linkages to the corresponding order. If results are entered manually or are received electronically from an external system, it’s likely the result will have no reference to the order from which it came.
Im short, we added
obs.order_id in core specifically to track order fulfillment. We just can’t assume all implementations will be able to reliably populate it.
Dispensation of drugs is outside the purview of an EMR. It would be great to expose drug dispensing information during order entry if it’s available (e.g., from a pharmacy module or external inventory system), but order entry’s job is to gather the request and not to dispense or administer drugs.
The issue with the linking by order_id solution is that is doesn’t really provide an easy means to query against, nor it is intuitively obvious what the logic would be.
For instance, lets say you are modelling drug orders and decided to create a “Drug Dispensed” obs when a drug was dispensed (this could happen within OpenMRS based on a form entry or perhaps on receipt of a message from an outside system).
If we wanted to know the list of active drug orders that have yet to be dispensed/fulfilled you’d need to query for of all active orders and then query the obs table for all “Drug Dispensed” obs and subtract any orders referenced on this obs. I guess you could come up with a JOIN to do that relatively efficiently but it seemed fairly confusing compared to having a “status” column on Order with states like “Ordered”, “Pending”, and “Fulfilled”.
I get that one issue with having a “status” field would be that if you are in an environment where you aren’t getting responses back from a third party system or tracking status, the “status” could theoretically be considered misleading, but I think if you consider a generic enough base state like “Ordered” this wouldn’t be a huge issue. Or you could just have states like “Pending” and “Fulfilled” and as a rule have the API set the “status” to null when creating an order and require additional API calls to set/modify the “status” state so that by default the “status” field is never used. We could hold the “status” in a separate domain object as well if we didn’t want to break the rule of an Order being immutable.
It’s also the case that merely having lab results come back in response to an order doesn’t necessarily mean the order is completely fulfilled. (E.g. some tests are still pending.)
Personally I think it’s a big deficiency in our Order model that we don’t allow an easy way to mark an order as complete/fulfilled (and thus no longer active).
(Presently there is an Order.dateStopped, which looks like it can only be set by discontinuing or revising the order.)
Whether we add a status, or add a stopReason, this would make things a lot more straightforward for the typical OpenMRS use case.
(If your architecture is such that you can’t figure out whether status/fulfillment has happened or not, you should ignore that field, but this shouldn’t prevent us from supporting this for the more typical OpenMRS use cases.)
FYI, FHIR’s Procedure Request resource has a status, that includes “completed”.