We need to record Observations along with drug orders for one of our implementations. The use case in detail is as follows:
The implementers want to record the reason for stopping a drug. There is a set of possible values that this reason could have, thus we believe it can be recorded as a coded concept. Also they want to record what they call as “Adverse event ID”, which basically refers to the ID of an entry in a log that they maintain for the side effects that the medicine is having. (which most probably is the reason the drug is being stopped)
Please let me know if you have some suggestions for solving this use case.
Interesting - discontinueReason used to exist on Order in the 1.9
model. It seems like it was removed in the latest order design. That
being said, it still appears as a part of the design shown here:
https://wiki.openmrs.org/pages/viewpage.action?pageId=34146504
@burke - is this still meant to be part of the design?
In OpenMRS 1.10 we removed Order.discontinueReason, and the new approach is:
When you discontinue a drug, you place a new order with action = DISCONTINUE. This new discontinuation order can have an orderReason or orderReasonNonCoded, and this is where you would store the reason that the original order was discontinued.
Wanted to highlight that discontinue reason and adverse event are different
data points for this implementation.
The need is to have the following:
discontinue reason (free text)
stop date
implementation specific information (in this case it is only adverse
event type). I was wondering whether one would solve this by having a obs
group associated to it stopped drug order.
This would make sense to me, and is what we have done in the past based
on what is possible with the data model.
The fact that Observations are not made directly accessible from Order
(eg. order.getObs() does not exist) makes me wonder whether we have
intentionally discouraged use in this way though. I have to again defer
to @Burke or @Darius on that.
Mike
I believe this is what we have done in the past.There is no direct way
to get Observations for an Order (eg. order.getAllObs() is not
available), but there is direct relationship (eg. obs.getOrder()
It’s perfectably reasonable for an application to generate observations link the observations to the orders through obs.order_id (and we could add a OrderService.getObsByOrder(Order) for convenience), though I think the assumption from the API (and most clients of the API) would be that those observations represent observation about the patient that resulted from the order and not attributes about the order itself.
In the described case, I would probably put the coded adverse event detail into order_reason and any free text into comment_to_fulfiller of the D/C order. If that won’t do, it would probably make more sense to create order_attribute for these data, since they are custom details about the order and not observations about the patient.
By the way, the way this has been “solved” historically is that in a
retrospective-form-entry world, the encounter is what groups obs and
orders. (So you might observe the adverse reaction and order a drug change.
And someone doing analysis/display would infer that an adverse event and a
drug change in an encounter are linked. This wouldn’t let you handle the
case where multiple different adverse events associated with different
drugs are recorded in the same encounter.)