Should renewing a medication auto-stop the original prescription?

Development
, ,
1

Background context: for a primer on the order entry API’s backend validations and how they shape O3 workflows, see Order Entry in O3: A PM Reference.

In OpenMRS today, a renewal is saved as action: NEW with a previousOrder link, and the original prescription is not automatically stopped. Both prescriptions remain active until the original expires on its own end-date or is discontinued separately. The duplicate-active-order safety checks explicitly exempts the renewal chain, so nothing in the platform catches the overlap.

The clinical concern

How do the workflows in many commercial EMRs treat “renew”? Is the current behaviour in OpenMRS surprising for clinicians? Does it create a real risk of:

  • Double-dispensing if the original has refills remaining and the pharmacy fills both
  • Charting ambiguity - two parallel active orders for the same drug muddy the medication list, the pharmacy queue, and downstream reporting.

If so, these risks are amplified because the downstream layers cannot compensate:

  • The pharmacy app does not know the new prescription is a renewal (it sees two independent orders)
  • The FHIR layer drops the previousOrder linkage entirely, so external EMRs and analytics see two standalone prescriptions

What the prior thread settled (and didn’t settle)

The earlier discussion at Revising and renewing orders established useful framing but didn’t resolve the auto-stop question:

  • @burke’s tighter RENEW semantics: RENEW = re-issuing an unchanged order (same drug, dose, instructions); REVISE = changing order details. Under this definition, a renewal is a continuation and the original would naturally be replaced.
  • The dateStopped/dateActivatedboundary: TRUNK-4580 introduced the 1-second gap between a stopped REVISE-previous and the new order’s activation. @burke proposed redefining dateStopped as exclusive and dateActivated as inclusive so they could be identical - a cleaner model that removes the +1s math.
  • An open suggestion - the API could auto-classify REVISE vs RENEW based on whether drug + dosing changed.

The thread didn’t land an auto-stop decision and the open suggestions stayed open.

Legitimate edge cases for the current behaviour

Several clinical scenarios could genuinely need overlap:

  • Bridging: Original order has 2 days left; clinician wants to the renewal to start when the original ends. One option: a future-dated renewal that starts when the original ends, expressed as scheduledDate + urgency: ON_SCHEDULED_DATE rather than as parallel actives.
  • Route/form transition (e.g., IV → PO in inpatient) where the the old order is kept active until the new one is verified)

None of those require the platform-level default to be “don’t auto-stop”.

Questions

  1. Should OrderServiceImpl.saveOrder auto-stop the previous order when it processes a renewal (action: NEW with previousOrder set)?
  2. If yes, how do we handle the bridging edge case - a future-dated start on the renewal that delays the auto-stop, or an explicit “do not stop the original” override?
  3. If no, where do we surface the safety net - at the pharmacy queue, at the order list, at save time as a confirmation prompt?
  4. Should the API switch the action type from REVISE to RENEW when the submitted drug + dosing match the previous order (per the prior thread’s open suggestion)? If we adopted @burke’s tighter “RENEW = unchanged re-issue” definition, the auto-stop question becomes definitional rather than contested.
  5. Is it worth revisiting the TRUNK-4580 one-second gap model? @burke’s dateStopped exclusive / dateActivated inclusive proposal would clean up the arithmetic the application layer has to mirror.

Paging @burke @ibacher @mseaton @veronica @robai

Thanks! Dennis