Future-Order Binding (Universal)

Status: spine shipped (orderRequest + consult + admission). Backend; auto-deploys on push. Generalizes: consult-visit-encounter-chain.md and admission-future-binding-and-reminders.md.

The model — any request can be a future order

A doctor places an order for a later visit. It is intent, not an event: it does not bind to the current/last visit’s encounter. On the patient’s next arrival, a new encounter is created and consumes (binds) the due future orders.

Not admission-only. The canonical multi-type entity is orderRequest (lab, medication, imaging, procedure, blood) — so one generic binder covers all of them. Consult and admission are siblings with their own binders. New domains plug into the same checkIn trigger.

The spine — one trigger, N binders

administration.encounter.checkIn → on arrived, fan out to the registered binders:

Binder (Moleculer action)	Domain	Gate	“Open future” predicate
medication.orderRequest.bindOpenOrdersToEncounter	lab / med / imaging / procedure / blood (all orderRequest types)	none	scheduledAt ≤ now, encounterTarget unset, status ∉ {cancelled, completed}, active
medication.consultRequest.bindOpenConsultsToEncounter	consult	sub-clinic match	status ∈ {nurse_accept, appointment}, encounterTarget unset
administration.admission.bindOpenAdmissionsToEncounter	admission (IPD)	encounterClass === IMP	status ∈ {request, pending, appointment, receivePendingAdmit}, encounterIpd unset

Each binder is idempotent — it only touches requests with no target encounter set, so it is safe to run on every arrival and safe alongside any legacy pre-create path. Adding a domain = a new bindOpen…ToEncounter action + one ctx.call in the checkIn hook.

The fields (orderRequest)

Added to OrderRequest (mirrors ConsultRequest’s encounterTarget):

• scheduledAt?: Date — the future-order marker (intended realization day). An order with no scheduledAt is a normal same-visit order and is never picked up by the binder.
• encounterTarget?: Ref — the arrival encounter the order was bound to. encounter stays the source (where it was ordered); encounterTarget is where it was realized.

On bind: encounterTarget = arrivalEncounter, status → PENDING (activated for the receiving dept).

Invariants

1. A future order never binds to the current/last visit’s encounter.
2. The order is realized at arrival and binds to that encounter via encounterTarget.
3. Binders are idempotent (no double-bind).
4. Orders with no scheduledAt are untouched (normal same-visit flow unchanged).
5. scheduledAt > now orders are not consumed early (only due orders bind).

Read-model + reminders

Surface on the scheduled day + remind the patient — same plan as admission-future-binding-and-reminders.md §4–5 (project scheduled_at; “expected for [date]” view; a dedicated reminder domain — one-way patient notification over messaging.notification.* (SMS / Ever app / email), not AcknowledgementRequest; ICS-first calendar). That applies to every order type via this spine.