BulkCriticalCalloutManager — order-wise callout orchestration, state transitions, batch data fetch, and draft handling.

BulkCriticalCalloutManager

File: operation/views/bulk_critical_callout_manager.py

BulkCriticalCalloutManager is the central orchestrator for all order-wise callout actions. Every callout request — draft or done — passes through process_callout(). It handles batching, state transitions, DB writes, ES sync, and activity logging in a single atomic flow.

Initialisation

BulkCriticalCalloutManager(
    lab_id=int,
    bill_id=int,
    session=dict,
    base_url=str,
    callout_payload=dict,   # notification object from frontend
    lab_report_ids=list,    # reports included in this callout action
    is_draft=False,
)

lab_report_ids is the user's selection — the subset of critical reports they chose to include in this callout.

process_callout() — main flow

State transitions

Per-report criticalValues

`is_draft`	Selected reports set to	Excluded ATTEMPTED reports reset to
`False` (done)	`CALLOUT_DONE (2)`	`CALLOUT_PENDING (1)`
`True` (attempted)	`CALLOUT_ATTEMPTED (4)`	`CALLOUT_PENDING (1)`

"Excluded ATTEMPTED reports" are reports that had a previous draft but are not in the user's current selection — they are reset to CALLOUT_PENDING so they appear actionable again.

CriticalCallout records created

`is_draft`	Records created	`lab_report` value
`False` (done)	One per selected report	Each `CriticalReport` instance
`True` (attempted)	One bill-level record only	`None`

For draft, only one CriticalCallout row is created (from the first report), with lab_report=None. The selected test IDs are stored in critical_callout_meta.callout_for for UI restore.

Batch parameter fetch — get_critical_report_params_mapper()

All DB reads happen in a single classmethod call before any writes. This avoids N+1 queries across reports.

3 DB queries serve all reports regardless of how many reports are in the order.

trigger_email()

Called only when is_draft=False. Delegates to CriticalReport.notify_by_email() using the first report as the sender context (lab, org, bill details).

Email subject for bulk callout:

Critical Results Alert from {lab_name} for Order ID - {labBillId}

The Jinja template receives is_bulk=True when more than one report is included, allowing it to render a multi-report layout.

share_comment setting is checked here — comment is passed to the template only if enabled.

get_updated_reports_and_callout_instances()

Iterates over critical_reports and builds two lists in one pass:

updated_reports — every report with updated criticalValues and lastUpdated
callout_instances — unsaved CriticalCallout objects (one per report for done; one total for draft)

For draft mode, callout_instances is populated only on the first iteration — subsequent reports only update criticalValues. This is the mechanism that ensures a single bill-level draft record.

Constants

METHOD_KEY_VALUE_MAPPER = [
    ("sendFax",   "Fax"),
    ("sendEmail", "Email"),
]
RECIPIENT_KEY_VALUE_MAPPER = [
    ("is_patient",      "Patient"),
    ("is_referral",     "Referral"),
    ("is_organization", "Organization"),
]
CRITICAL_NOTIFICATION_LOG_CATEGORY_ID = 648
WORKLIST_CALLOUT_CRITICAL_VALUES = (
    CALLOUT_DONE, CALLOUT_PENDING, CALLOUT_ATTEMPTED
)

Bulk Manager