Overview
Sample Rerun — re-run lab test parameters on the same sample, triggered manually, automatically by configured conditions, or by the instrument itself.
Sample Rerun
Sample Rerun is the workflow that allows a lab to re-run one or more test parameters on the same patient sample — either because the values look suspect, because the instrument detected an anomaly and re-analysed the sample on its own, or because an auto-rerun rule was configured and the incoming value crossed a threshold.
The feature spans four repositories: crelio-app (backend API and business logic), livehealth-frontend (React UI), interfacing (instrument communication), and the livehealthapp Django host (no rerun-specific code; hosts URL routing only).
Why is Sample Rerun needed?
Some test results need to be verified before they can be reported:
- A parameter value may fall outside expected ranges — the lab technician wants the instrument to process the sample again before trusting the result
- The instrument itself may detect an internal anomaly (e.g., a clot, a flagged aspiration) and automatically re-test the sample
- Lab SOPs may require automatic re-runs when values cross critical or abnormal thresholds
Without a structured rerun workflow:
- There is no traceability of which parameters were re-run, how many times, or what the earlier values were
- Instrument-triggered re-runs produce duplicate result rows with no way to distinguish the original from the rerun
- Technicians have no confirmation step — new values silently overwrite old ones
How rerun is triggered
Three distinct trigger paths exist:
| Trigger | Who initiates | rerun_number | type |
|---|---|---|---|
| Manual Rerun | Lab user via UI | User-specified (1, 2, …) | Manual |
| Auto Rerun | System, when device values cross configured threshold | 1 (default) | Auto |
| Instrument-triggered Rerun | The instrument itself re-sends data for the same sample | -1 (sentinel) | Instrument-triggered |
sampleRedrawFlag — the report-level status
The sampleRedrawFlag field on LabReportRelation tracks the current rerun state of each report:
| Value | Constant | Meaning |
|---|---|---|
0 | NON_REDRAWN | No rerun active — normal state |
1 | PARTIAL_REDRAWN | Legacy — partial sample redraw |
2 | FULL_REDRAWN | Legacy — full sample redraw |
3 | RERUN_REQUESTED | A rerun has been requested; awaiting instrument values |
4 | RERUN_RECEIVED | Rerun values received; awaiting user confirmation |
Where is rerun visible?
| Surface | Behaviour |
|---|---|
| Report Entry | RerunProgressComponent banner shows rerun status; Save/Sign disabled while rerun is in progress |
| Test Waiting List | Badge shows "Rerun Requested" or "Rerun Received" |
| Doctor Waiting List | Same badge behaviour |
| Active Reruns sidebar | Dedicated sidebar item under Operations and Doctor Login showing count of active reruns |
| Device Results Validation | Shows "Rerun Triggered" / "Rerun Complete" status; actions disabled during rerun |
| Device Waiting List (interfacing) | "Rerun" label badge next to Sample ID; rerun parameters sent to instrument |
| LabAdmin → Test Configuration | Checkboxes for "Auto rerun" and "Manual rerun" per parameter with condition configuration |
Feature scope summary
- Manual Rerun: Lab user selects parameters → requests rerun → instrument re-tests → user reviews original vs rerun values → confirms which to keep
- Auto Rerun: Configured per parameter with conditions (abnormal, critical, custom range) → triggered automatically when device values qualify → routed through Fusion webhook
- Instrument-triggered Rerun: Device re-sends data without being asked → system detects it as a rerun → values stored with
rerun_number = -1 - Confirmation flow: Side-by-side comparison of original and rerun values with radio selection per parameter
- Cancellation: Rerun can be cancelled at any stage, resetting
sampleRedrawFlagto0and cleaning up DocumentDB records - Waiting list integration: Reports with
sampleRedrawFlag = 3appear in the device waiting list with rerun parameters mapped to instrument machine names - Activity logging: Five dedicated log categories track every rerun lifecycle event