Overview

Machine Flags provide a mechanism to store and display device-generated flags received from interfacing analyzers inside LIMS workflows.

These flags are primarily used in:

• Report Entry
• Overview Reports
• Device Results Validation

Machine Flags are not rendered in PDF preview or printable report output.

1. Configuring Machine Flags Feature

Overview

Machine Flags support is configured at the Test/Report level.

When the user enables or disables the Enable Device Flags (Store results in MongoDB) checkbox from the frontend and saves the test configuration, the following API is triggered.

API

POST reporting/report-format/<testId>/update/

URL Pattern

url(r"(?P<test_id>\d+)/update/$", ReportFormatView.as_view(is_new=False))

Important Payload Field

The frontend sends the following field inside testData.test.enable_device_flags

Example:

{
  "testData": {
    "test": {
      "enable_device_flags": true
    }
  }
}

Backend Flow

Inside both:

• LabTest.create
• LabTest.update

the following logic is executed:

enable_device_flags = test_info.pop("enable_device_flags", False) or False

If the test type is Normal then:

instance.document_report = int(bool(enable_device_flags))

is set before saving the test.

Important Note

enable_device_flags is not stored directly in any database column.

Instead, it is only used to decide whether the report should behave as a Document Report

which enables storage of:

• Machine Flags
• Parameter Flags
• Device Extra Data

inside DocumentDB-backed report values.

Request Payload Structure

The payload contains multiple sections:

{
  "testData": {},
  "reportData": [],
  "ageRangeData": [],
  "calculations": [],
  "addTestToChildLabsData": {}
}

Relevant Request Example

{
  "testData": {
    "addFlag": 0,
    "testID": 10268009,
    "test": {
      "testName": "CBC",
      "test_type": "Normal",
      "enable_device_flags": true,
      "show_device_extra_data_in_pdf": false
    }
  }
}

2. Sending Data from Interfacing Device to LIMS

Overview

When a device sends raw analyzer output, the interfacing layer parses the raw string into a structured payload and sends it to the LIMS backend.

Each mapped test inside LIMS is associated with a dedicated processing function responsible for filling report values.

Machine Flags are currently supported only in PartialFill mapping function.

API

POST dataPartialFromDevice/

URL Pattern

url(r"^dataPartialFromDevice/$", getDeviceDataForPending)

Request Payload Structure

{
  "labId": 11957,
  "sampleId": "000114626",
  "deviceAuth": "f94032be-5e1f-47fd-96a1-92a66c6014c3",
  "test_flags": [
    "DUMMY TEST FLAG1",
    "FLAG2"
  ],
  "data": {
    "values": [
      {
        "testName": "hmg",
        "value": 110.12,
        "param_flags": [
          "P1",
          "H~N"
        ]
      }
    ]
  }
}

Payload Fields

Root Level Fields

Parameter Structure

Each parameter inside data.values may contain:

{
  "testName": "hmg",
  "value": 110.12,
  "param_flags": [
    "P1",
    "H~N"
  ]
}

Backend Processing Flow

Step 1 - Validate Device

The API validates:

• Device authentication
• Lab ID
• Sample ID
• Payload structure

Step 2 - Find Device Mapping

Mapped tests are fetched using deviceTestMapping.objects.filter(...) Each mapping contains a processing function name.

Example PartialFill

Step 3 - Invoke Mapping Function

The mapped function is dynamically executed:

methodCall = getattr(devices.functions, test.functionName, testValidateFlag)

PartialFill Function

Machine Flags are processed inside def PartialFill(...)

Machine Flag Handling

Report-Level Flags

Report-level flags are received from test_flags and stored in report values:

update_values["test_flags"] = test_flags

Parameter-Level Flags

Parameter flags are received from param_flags and stored as:

update_values["param_flags"] = param_flags

Example Stored Structure

{
  "value": 110.12,
  "test_flags": [
    "FLAG1",
    "FLAG2"
  ],
  "param_flags": [
    "P1",
    "H~N"
  ]
}

3. Fetching Data for Report Entry Modal

Overview

When the user opens a report from: Pending Reports the frontend fetches report values and metadata using:

GET getReportFormatForTestEntry/

This response also contains:

• Machine Flags
• Parameter Flags
• Device Name

for each report value.

API

GET getReportFormatForTestEntry/

URL Pattern

url(r"^getReportFormatForTestEntry/$", getReportFormatForTestEntry)

Request Payload

{
  "labReportId": 123,
  "isSigned": 0
}

Machine Flag Structure in Response

Inside value[] each parameter may contain:

{
  "index": 4,
  "value": 110.12,
  "device_name": "Alinity",
  "test_flags": [
    "DUMMY TEST FLAG1",
    "FLAG2"
  ],
  "param_flags": [
    "P1",
    "H~N"
  ]
}

Important Response Fields

Response Structure

{
  "value": [],
  "reportFormat": [],
  "calculationList": [],
  "qcArray": [],
  "historicalValuesByIndex": {},
  "labReportSigningMeta": {}
}

4. Fetching Data for Overview Section

Overview

When the user opens the Patient Overview screen, the frontend fetches all patient reports along with associated report values. Machine Flags are included in the same API response.

API

GET api-v3/patient/<labReportId>/all-reports

Backend Entry Point

PatientOverview.fetch_patient_all_reports()

DocumentDB Report Values

For Document Reports, report values are fetched from:

get_docdb_report_values()

Machine Flags Projection

The aggregation pipeline includes:

"test_flags": 1,
"param_flags": 1,

Returned Structure

Machine flags are returned inside report_result_mapper

Example:

{
  "index": 4,
  "value": 110.12,
  "test_flags": [
    "FLAG1",
    "FLAG2"
  ],
  "param_flags": [
    "P1",
    "H~N"
  ]
}

Main Response Structure

{
  "reports": [],
  "report_result_mapper": {},
  "report_format_mapper": {},
  "calculations_mapper": {},
  "qc_values": {},
  "patient": {}
}

5. Fetching Data for Device Results Validation

Overview

Machine Flags are also displayed inside Device Results Validation for pathology devices. This screen displays un-reviewed interfaced device results along with associated report information.

API

GET /api-v3/interfacing/device-results-validation/<deviceId>

Query Parameters

Example:

/api-v3/interfacing/device-results-validation/3?startDate=2026-05-25T18:30:00.000Z&endDate=2026-05-26T18:29:59.000Z

Backend Entry Point

FetchDeviceResultsForValidation.get()

Main Processing Method

DeviceResultsValidation.get_device_path_results()

Machine Flag Formatting

During response preparation:

device_result["value"] = [
    {
        "value": value.get("value"),
        "test_flags": value.get("test_flags", []),
        "param_flags": value.get("param_flags", []),
    }
]

Example Response Value

{
  "value": [
    {
      "value": 110.12,
      "test_flags": [
        "FLAG1",
        "FLAG2"
      ],
      "param_flags": [
        "P1",
        "H~N"
      ]
    }
  ]
}

Related Report Information

Each result also contains:

{
  "related_reports": [
    {
      "report_name": "CBC",
      "parameter_index": 4,
      "linearity_ranges": {},
      "parameter_historical_values": []
    }
  ]
}

Final Response Structure

{
  "results": [],
  "device_id": 3,
  "device_name": "Alinity",
  "bill_and_user_details_by_sample": {}
}

Summary

Machine Flags Lifecycle

Configuration

enable_device_flags determines whether the report behaves as a Document Report.

Ingestion

Interfacing devices send:

• test_flags
• param_flags

through dataPartialFromDevice/

Storage

Flags are stored inside DocumentDB Report Values through the PartialFill function.

Retrieval APIs

Machine Flags are available in:

PDF Behaviour

Machine Flags are intentionally excluded from:

• PDF Preview
• Printable Reports