Summary

When the registrar saves a TB screening while the tablet shows "Camp Hub Offline", the referral X-ray (and TrueNat) order is never created. The screening syncs to the hub later, but the order does not, and nothing retries it. The registrar role cannot see the X-ray/TrueNat sections, and the nurse sees nothing because no order exists on the hub, so the patient silently misses the X-ray.

Field report: "only beneficiaries registered today get orders". The data shows the gap affects old and new beneficiaries alike; it tracks hub connectivity at the moment of saving, not registration date.

Evidence (camp 458, Indravelly Van1)

Beneficiary 601413456541 (registered 23 Oct), hub data via Fleet query #35:

• tb_screening id 2207: visit_date 2026-11-06 17:14, referred_for_digital_chest_xray = 1 (tablet screenshot at 17:15 shows "Camp Hub Offline")
• t_benvisitdetail 151088: created 2026-11-07 09:08 (screening reached the hub next morning)
• tb_diagnostic_order: no rows of any type for this beneficiary

X-ray-referred screenings on the hub vs orders (Fleet query #37):

Root cause

STOP-TB app:

• TBScreeningFormViewModel.initializeDiagnosticsAndPush saves the screening, then queues DiagnosticOrderPushWorker for XRAY_CHEST / SPUTUM_TRUENAT.
• TBRepo.createOrder: in camp mode with the hub disconnected it calls saveFailedOrderStatus (status FAILED on the tablet only) and never calls flw-api/diagnostic/order/push.
• DiagnosticOrderPushWorker returns Result.success() for that case, so WorkManager never retries.
• The only recovery is the manual Retry/Reorder action on the X-ray/TrueNat list, which the registrar role cannot access.

FLW-API: order creation exists only behind POST /diagnostic/order/push. Screening sync (StopTBServiceImpl.saveNurseTBScreening) stores referredForDigitalChestXray / referredForSputumCollection but never creates an order. createAndPushOrderAsSystem exists and is unused.

Fix

FLW-API (release-3.12.1):

1. After a screening save commits, create the referred orders on the hub (XRAY_CHEST when referred for X-ray, MTB when referred for sputum) via createAndPushOrderAsSystem, asynchronously so a slow device does not block screening sync. Patient name/DOB/sex read from the hub identity tables.
2. Catch-up sweep on the hub: periodically find today's referred screenings with no order and create them (covers screenings synced before the deploy and any failed attempt).
3. Existing per-beneficiary lock and dedup make a concurrent tablet push safe.

STOP-TB app (2.3.1):

1. Remove the screening-time order/push (TBScreeningFormViewModel); the hub owns order creation from the screening.
2. Keep nurse-initiated pushes (Reorder/Retry, refusal close, result-driven follow-on orders).

Open decisions

• Should re-screening on a later day create a new X-ray order? Today both app (hasXrayOrder) and server (BLOCKING_STATUSES) return the old PENDING/COMPLETED order, so a re-screened beneficiary gets none.
• Missed orders from earlier days (e.g. 4 Nov at camp 458): call patients back or close out; the sweep only covers the current day.