Sample Rerun Workflow Guide

This guide walks through the complete lifecycle for each rerun type — from triggering a rerun to confirming or cancelling the results.

End-to-end workflow (manual rerun)

1. Initiate a manual rerun

Pre-conditions

• Report has a format with manual_rerun enabled in at least one parameter's meta
• Report is in normal state (sampleRedrawFlag = 0)

Steps

1. Open the report in Report Entry or the Patient Test List
2. The RerunProgressComponent banner shows "Sample rerun is enabled for this report" with an "Initiate Rerun" button

3. Click "Initiate Rerun" → the SampleRerunModal opens on the "Initiate Sample Rerun" tab
4. A table of parameters is shown with checkboxes — select the parameters to re-run
5. If the report is already completed or signed, a confirmation warning appears requiring the user to type "confirm"
6. Click "Initiate Sample Rerun" in the footer

What happens on submit

After the rerun is requested, the banner updates to show the rerun-requested state with a Cancel button:

Payload shape

{
  "type": "manual_rerun",
  "rerun_number": "1",
  "requested_parameters": [1, 3, 5],
  "parameter_names": ["WBC Count", "RBC Count", "Hemoglobin"],
  "is_active": true
}

2. Auto rerun

Auto rerun is configured per parameter in LabAdmin → Profile & Report Management → Test List → Rerun tab and triggers automatically when device values qualify.

Configuration

Each parameter can have auto_rerun enabled with a condition:

Trigger flow

Guard conditions

• DOCUMENT_DB_ENABLED must be true
• At least one parameter must have auto_rerun in its ReportFormat.meta
• No existing auto rerun record for the same lab report (auto_rerun_record_exists check)
• The parameter value must satisfy the configured condition against the appropriate range (normal, critical, custom, or age-based)

3. Instrument-triggered rerun

When an instrument re-sends results for a sample that already has a pending manual rerun, the system detects this and treats the new values as rerun data.

Detection logic (interfacing app)

The qualify_rerun() function in interfacing/src/main/tasks/sample_rerun.js:

1. Checks if a manual rerun was requested by querying the WaitingList for the sample's rerunNumber
2. If not a manual rerun, checks if machine_triggered_rerun is enabled in device settings
3. Compares the processed timestamp or parsed values between the current and existing result
4. Returns { is_rerun: true, rerun_number: -1 } for machine-triggered reruns

Prerequisite: The machine_triggered_rerun field must be set to true in the device settings JSON. If this field is false or absent, step 2 above will return early and the system will not detect instrument-triggered reruns. See Testing & Debugging for the full device settings example.

4. Receive rerun values

When rerun data arrives (via any trigger path), the SampleRerunView.post() dispatches to:

• Instrument-triggered (rerun_number = -1): register_machine_triggered_rerun() — stores all values, marks fulfilled immediately
• Manual (rerun_number ≥ 1): register_manual_triggered_rerun() — validates against requested parameters, tracks partial fulfilment

Manual fulfilment tracking

5. Review and confirm rerun values

Once sampleRedrawFlag = 4, the RerunProgressComponent banner updates to "Sample rerun for this report is in progress. Please confirm the rerun values" with a "Confirm Rerun" button.

Steps

1. Click "Confirm Rerun" → the SampleRerunModal opens on the "Review Rerun Results" tab
2. A table shows each parameter with columns for the original value and each rerun value (value1, value2, etc.)
3. Radio buttons on each row let the user pick which value to keep — original or a specific rerun iteration
4. A header-level radio button selects all rows for a column at once
5. Click "Confirm Rerun Values" in the footer

What happens on confirm

6. Cancel a rerun

A rerun can be cancelled at any stage — whether awaiting instrument values (flag = 3) or after values have been received (flag = 4).

Steps

1. Click "Cancel" on the RerunProgressComponent banner → the CancelRerunModal opens
2. Confirmation message: "The sample rerun for this report is currently in progress. Are you sure you want to cancel?"
3. Click "Cancel Rerun" to confirm

What happens on cancel

7. Report behaviour during an active rerun

While a rerun is in progress (sampleRedrawFlag = 3 or 4):

8. Device waiting list integration

When a manual rerun is requested, the report appears in the device waiting list (interfacing app) with additional rerun metadata:

{
  "labReportId": 12345,
  "is_rerun_request": true,
  "rerun_number": 1,
  "rerun_params": "{\"42\": [\"HGB\", \"WBC\"]}"
}

The rerun_params field maps device IDs to the list of machine names (parameter codes) that need to be re-tested. This allows the interfacing app to send targeted rerun commands to the instrument.

9. Activity log reference

10. Testing & Debugging

UAT environment

Use the following UAT endpoint to trigger sample reruns for testing:

The /dataPartialFromDevice/ endpoint is the interfacing entry point that processes partial device data. When is_rerun: true is set in the payload, the system treats the incoming data as rerun values.

Trigger an instrument-triggered rerun via curl

Use this curl command to simulate an instrument sending rerun data for an incomplete or partially completed report:

curl --location 'https://e2e-lhapp.crelio.solutions/dataPartialFromDevice/' \
--header 'App-Version: 9.9.99' \
--header 'Content-Type: text/plain' \
--header 'Cookie: DEPLOYMENT_ZONE=E2E; labUserId=' \
--data '{
    "labId": 22,
    "deviceAuth": "ffecd1a4-c330-4a50-b5d0-f9393a91e308",
    "data": {
        "values":[
            {
                "testName": "wbc",
                "value": 5
            },
            {
                "testName": "rbc",
                "value": 50
            },
            {
                "testName": "pc",
                "value": 500
            }
        ]
    },
    "sampleId": "BL000135924",
    "sample_id": "BL000135924",
    "is_rerun": true,
    "rerun_number": -1
}'

Payload field reference

Pre-conditions for testing

1. The sample (sampleId) must have an existing report in the system that is incomplete or partially completed (completedTests = 0 or isPartialFill = 1)
2. The device identified by deviceAuth must be mapped to a lab and have test mappings that include the machine codes in data.values (e.g., wbc, rbc, pc)
3. The report's sampleRedrawFlag should be 0 (no active rerun) for a first-time rerun, or 3 (rerun requested) for an in-progress manual rerun
4. machine_triggered_rerun must be true in the device settings — without this, the system will not treat incoming data as a rerun

Device settings for machine-triggered rerun

The device must have machine_triggered_rerun: true in its settings JSON. Below is a sample device settings object with the required field highlighted:

{
    "fileSettings": {
        "dir_path": "C:\\interfacing-cobas4800",
        "extensions": [
            "csv"
        ],
        "sheet_no_to_parse": [
            1
        ],
        "start_row_no": 1,
        "watch_timeout": 10000,
        "order_settings": {
            "output_dir": "C:\\interfacing-cobas4800",
            "filename": "test.txt"
        }
    },
    "timeout": 1000,
    "valuesMapping": [
        "value"
    ],
    "matchingKeywords": [
        {
            "reportFormatID": 4034153,
            "servername": "table",
            "machinename": "table"
        },
        {
            "reportFormatID": 4034153,
            "servername": "main_result",
            "machinename": "main_result"
        },
        {
            "reportFormatID": 4034153,
            "servername": "-",
            "machinename": "-"
        },
        {
            "reportFormatID": 4019571,
            "servername": "alb",
            "machinename": "alb"
        },
        {
            "reportFormatID": 4019571,
            "servername": "wbc",
            "machinename": "wbc"
        },
        {
            "reportFormatID": 4019571,
            "servername": "plt",
            "machinename": "plt"
        },
        {
            "reportFormatID": 4019571,
            "servername": "glu",
            "machinename": "glu"
        }
    ],
    "matchingKeywordsFlag": true,
    "keywordsToBeSentFlag": false,
    "interfaceType": "file",
    "autoSend": true,
    "initiate_order": false,
    "mark_sent_orders": false,
    "requires_ack": false,
    "machine_triggered_rerun": true  // ← Required for instrument-triggered reruns
}

Key field: "machine_triggered_rerun": true at the root level of the device settings. When this is false or absent, the qualify_rerun() function in the interfacing app will skip machine-triggered rerun detection and return is_rerun: false.

What to expect

After sending the curl:

1. The system saves SampleRerunValues in DocumentDB with rerun_type = "instrument_triggered" and rerun_number = -1
2. The report's sampleRedrawFlag is set to 4 (RERUN_RECEIVED) — the rerun is immediately marked as fulfilled for instrument-triggered reruns
3. Opening the report in the UI will show the RerunProgressComponent banner with "Sample rerun for this report is in progress. Please confirm the rerun values"
4. The Review Rerun Results tab will display the original values alongside the rerun values for side-by-side comparison