Order Proposals hides a real proposal behind a standing order invented from a hash of the patient id

Start in backend-ts/src/order/standing-order-provider.ts, especially simulatedStandingOrderProvider and resolveStandingOrderProvider, then inspect frontend/app/(dashboard)/orders/page.tsx to understand how suppressed orders are displayed. Make the unconfigured provider return no fabricated standing orders, and verify that real proposals are no longer suppressed or presented as covered.

Order Proposals suppresses a real proposal behind a standing order invented from a hash of the patient id.

What the code does

backend-ts/src/order/standing-order-provider.ts:

export const simulatedStandingOrderProvider: StandingOrderProvider = {
  activeOrdersFor(subjectId) {
    const h = hash(subjectId);
    if (h % 5 !== 0) return [];
    const entry = CATALOG_ENTRIES[h % CATALOG_ENTRIES.length];
    if (!entry) return [];
    const [, order] = entry;
    return [{ subjectId, order }];
  },
};

resolveStandingOrderProvider selects it whenever WORKWELL_EH_FHIR_BASE_URL / WORKWELL_EH_FHIR_API_KEY are unset, which they are on the Maui deployment. So on the pilot this is the live provider.

Two separate problems follow.

The order is unrelated to the patient's gap. The catalog entry is chosen by h % CATALOG_ENTRIES.length over the whole of ORDER_CATALOG, which is mostly occupational (audiogram, tb_surveillance, hazwoper, mmr, varicella). A patient overdue for breast cancer screening can therefore be shown as already having a standing order for a HAZWOPER medical surveillance exam.

Their real proposal is withheld. The suppression is the point of the provider — the proposal is removed from proposed and moved to suppressed. So roughly one in five at-risk patients on the pilot has no actionable row, for a reason that is not real.

What a user sees

frontend/app/(dashboard)/orders/page.tsx renders the suppressed set under "At-risk subjects with an existing standing order", one row per named patient, with a per-row "standing order on file" cell. The page's top banner correctly states that orders are advisory, never auto-submitted, and never reach WebChart — it says nothing about this set being fabricated, and nothing on the row distinguishes a simulated standing order from a real one.

A quality lead reading that page concludes those patients are already handled. They are not.

Scope

Order of hundreds of patients on the pilot's 20,000-patient corpus. Also live on the TWH demo stack for the same reason.

Options

1. Return nothing when the seam is unconfigured. Every other inert seam on this stack returns empty or stays unselected; this is the only one that fabricates data while inert. It is the smallest change and it makes the page truthful.
2. Keep the simulation but confine it to the default/demo profile and label each simulated row on the row itself, not in a banner.
3. At minimum, pick the catalog entry for the measure that actually flagged the patient, so the fabrication is at least internally coherent — this fixes the absurdity but not the false claim.

Option 1 is the recommendation: a demonstration of dedupe suppression is not worth a screen that tells a clinic a patient is covered when nothing covers them.