Issue with creating linked orders in OpenMRS

mohant · February 3, 2026, 3:04am

Hello OpenMRS Community,

Our team is currently looking into linking orders where a subsequent order is directly contingent upon the results or performance of a prior order. We are looking to utilize the previous_order_id to maintain linking between these related orders.

Clinical Scenarios

We have identified two primary use cases where a subsequent order of a different concept must be linked to an initial order:

1. Laboratory Order

In many public health settings, a positive screening for Hepatitis B Surface Antigen (HBsAg) must be followed by a viral load test to determine if the infection is active.

Initial Order: Hepatitis B Surface Antigen (HBsAg) - Serology test.
Linked Subsequent Order: HBV DNA (Viral Load) - Molecular test.
The Need: The clinician needs to link the DNA test back to the HBsAg screen to show that the second order was triggered by the first, ensuring a clear linkage.

2. Sequential Radiology Imaging

Radiological investigations often follow a “preliminary view” protocol. A clinician may initially order a standard view, and upon reviewing the image or the patient’s condition, require additional specific views to be performed under the same clinical context.

Initial Order: Chest X-ray (CXR) - PA View.
Linked Subsequent Order: Chest X-ray - Lateral or Oblique View.
Need: Linking these ensures the radiologist and technician understand the subsequent view is a continuation of the initial diagnostic inquiry, rather than a separate, unrelated order.

Technical Constraint

Currently, the OpenMRS API enforces a validation rule that requires the concept of a new order to match the concept of the previous_order it references. Reference to OrderServiceImpl.

While this logic is essential for REVISE, RENEW, and DISCONTINUE actions to prevent data inconsistency, it creates a blocker for the NEW action type where the clinical intent is continuation or reflex testing rather than replacement.

Proposed Alignment

This requirement aligns with the HL7 FHIR ServiceRequest resource, which utilizes the basedOn field to reference prior requests, allowing for different order to be linked.

We propose that the validation check requiring matching concepts be bypassed specifically when the OrderAction is NEW. This would allow clinicians to “chain” orders while maintaining a clear audit trail of which order triggered the next.

We would love to hear the community’s thoughts on this:

Is there an existing alternative mechanism for this type of linking that we may have overlooked?
If not, can we proceed with creating a JIRA issue to allow different concepts for NEW actions in the OrderService?

Looking forward to your feedback.

@dkayiwa @burke @mseaton @ibacher @angshuonline

Best regards,

dkayiwa · February 4, 2026, 2:16pm

Your proposal makes a lot of sense to me. Therefore, i am in full agreement with proceeding to create a JIRA issue to allowing different concepts for NEW actions in the OrderService

angshuonline · February 4, 2026, 5:42pm

Me too, completely agree

ibacher · February 4, 2026, 5:55pm

My main query here would be whether we’re certain that a single one-way linkage is sufficient to meet the need here, i.e., do we potentially need a many-to-one relationship?

I think the current restriction in validation is in-place because the main use-case for the previous_order_id field is currently to track prescription re-ups or where one order replaces another one. Which may lead to some ambiguity about the meaning of the previous_order_id in an order that has been discontinued.

mohant · February 4, 2026, 6:03pm

Hmm. many-one relationship might be a subsequent addition we can think about. Even with the current model, it is possible to link many child orders with a single parent order as well. (previous_order_id can be same).

I think for the discontinue and revise scenario, orders are still identified as a combination of previous_order_id with Order Action.