Adding observations with drug orders

Hi Everyone,

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.

Thanks and Regards,


1 Like

Hi Prabhu,

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:

@burke - is this still meant to be part of the design?

Thanks, Mike

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.


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.)