All three critical callout API endpoints — fetch by bill, fetch logs in bulk, post callout — and the LRR serializer.

API Views

Three endpoints power the critical callout UI. Two are read (GET) endpoints consumed when the modal opens; one is a write (POST) endpoint that creates audit records.

1. FetchCriticalRecordsByBillView

File: report/views/critical_callout.py

GET /report/<bill_id>/critical/records

Called when the modal opens. Returns all critical reports for the bill plus any existing draft (attempted) callout state.

Query filters

{
    "dismissed": 0,
    "labId_id": lab_id,
    "billId_id": bill_id,
    "sampleCollected": 1,
    "criticalValues__in": [CALLOUT_DONE, CALLOUT_PENDING, CALLOUT_ATTEMPTED],
}

Dismissed and uncollected reports are excluded. All three callout statuses are included so the modal shows reports regardless of current state.

Department scoping

Session type	Filter applied
Doctor login (`docType=0`)	`reportID__departmentId_id__in` — doctor's department list via `DoctorDepartmentRelation`
Doctor login (`docType=2`)	`billId__docId` — only reports assigned to that doctor
Lab user (`departmentDataType=0`)	`reportID__departmentId_id` — session's department list
Lab user (`departmentDataType=1`)	`reportID__departmentId_id__in` — via `LabUserDepartmentRelation`
Support login	No department filter applied

Draft restore

Queries CriticalCallout where bill_id=bill_id AND lab_report IS NULL. If a draft exists, the attempted_callout object is populated:

{
  "recipients": ["Organization"],
  "critical_callout_comment": "Patient's doctor was informed",
  "critical_values_meta": { ... },
  "critical_callout_meta": {
    "communication_methods": ["email"],
    "callout_for": [101, 102]
  }
}

callout_for contains the testID values of reports that were in the draft — the frontend uses these to pre-select the same reports when the modal reopens.

Critical parameters

BulkCriticalCalloutManager.get_critical_report_params_mapper() is called to evaluate all reports in one batch. Reports with no critical parameters are excluded from the response.

Response shape

{
  "reports": [
    {
      "critical_parameters": [
        { "value": 75.0, "parameter_name": "WBC Count", "reference_range": "100 - 200", ... }
      ],
      "lab_report": { /* LabReportRelationAllTestSerializer */ }
    }
  ],
  "attempted_callout": { ... }
}

2. FetchCriticalNotificationLogsBulkView

File: report/views/critical_callout.py

GET /report/bulk/critical-notification/logs?report_ids=1,2,3

Returns activity log entries for the given report IDs, used to populate the history timeline in CriticalCalloutLogs.

Validation: All report_ids must be valid integers (digit check before query).

Query:

ActivityLog.get_activity_log(
    size=1000,
    sort_by_date="activityDate",
    sort_recent_first=False,
    filters={
        "labId": lab_id,
        "labReportId": sanitized_report_ids,
        "logCategoryId": 648,
    },
)

Response per entry:

{
  "meta": { "is_draft": true, "method": "Email", "recipients": "Organization", ... },
  "labUserName": "Dr. Smith",
  "activityText": "Callout Attempted by - Dr. Smith, ...",
  "activityDate": "2026-04-27T14:30:00Z"
}

meta is the parsed dumped_json from the activity log record.

3. CriticalCalloutView (audit record fetch)

File: operation/views/critical_callout.py

POST /operation/critical-callout
Body: { "lab_report_ids": [1, 2, 3] }

Returns CriticalCallout records for the given report IDs, annotated with resolved names. Used by the worklist's export flow (getCriticalCalloutData) to get the latest callout details per report.

Response fields include:

org_name, patient_name, referral_name
performed_by_user_name, performed_by_doctor_name
critical_callout_comment, critical_callout_meta (JSON), created_on

Serializer — LabReportRelationAllTestSerializer

File: report/serializers/custom/lrr_custom_serializer.py

Used in FetchCriticalRecordsByBillView to serialize each CriticalReport row.

fields = (
    "orgId", "onHold", "billId", "docForId", "reportID",
    "isSigned", "isSynced", "comments", "isProfile",
    "isApproved", "isResolved", "inQuestion", "labReportId",
    "notPerformed", "claim_on_hold", "userDetailsId",
    "reportFormatId", "criticalValues", "auto_approval_status",
)

reportID is serialized via StoreTestRelationSerializer — includes testID, testName, departmentId, and related metadata needed by the frontend for report accordion rendering and draft restore.

API Reference