Retrospective encounters and orders

Order Entry folks,

There is a feature that exists in the Order Entry API that allows one to distinguish between a real-time Order and a retrospectively-entered Order:

OrderServiceImpl:

/**
 * @see org.openmrs.api.OrderService#saveOrder(org.openmrs.Order, org.openmrs.api.OrderContext)
 */
@Override
public synchronized Order saveOrder(Order order, OrderContext orderContext) throws APIException {
	return saveOrder(order, orderContext, false);
}

/**
 * @see org.openmrs.api.OrderService#saveOrder(org.openmrs.Order, org.openmrs.api.OrderContext)
 */
@Override
public synchronized Order saveRetrospectiveOrder(Order order, OrderContext orderContext) {
	return saveOrder(order, orderContext, true);
}

One of the features that the retrospective Order supports is the ability to explicitly stop/discontinue an Order for a date prior to it’s auto-expire date, even if that auto-expire date is currently in the past (if I am reading the implementation correctly). This is a feature we’d like to take advantage of.

However, currently in the Encounter Service, all nested Orders are saved by invoking the non-retrospective method:

From EncounterServiceImpl:

	//save the new orders which do not have order groups
	for (Order o : encounter.getOrdersWithoutOrderGroups()) {
		if (o.getOrderId() == null) {
			Context.getOrderService().saveOrder(o, null);
		}
	}

What I’d like to propose, is to potentially modifying this to support invoking the saveRetrospectiveOrder method instead, if the encounter itself is being entered retrospectively.

Presumably this could be determined by comparing the current date to the encounter date (with suitable provisions for encounters recorded with no time component).

This could be done either in the encounterService, which would then invoke the appropriate orderService method, or it could be done directly in the OrderService (i.e. if saveOrder is invoked, and the encounter date is in the past, then indicate that retrospective = true)

I wanted to run this by everyone here to sanity check whether either of these options make sense, particularly since I’ll be looking to backport this to 2.3.x if agreed.

@burke FYI.

1 Like

Thanks @mseaton. That seems to make a lot of sense to me at first sight.

Thanks @mksd . I’ve created this ticket to reflect this work: https://issues.openmrs.org/browse/TRUNK-6002

If there are opinions about this - either disagreements that this is the right thing to do, or opinions on where and how this should be implemented (how we determine if an encounter is retrospective, or whether we add logic in the encounter service or order service to meet this need), please indicate so here.