Critical Lab Result Received

Fires when a critical lab result is received. targetEntity is the LabOrder. The eventType is lab_order_critical_result_received.

Field guarantees

Field	Guarantee
`eventData.labOrderId`, `labName`, `interpretation`, `externalOrderId`, `providerEventType`, `providerOrderStatus`, `latestProviderEventStatus`, `reportedAt`, `webhookPayload`	✅ Always present (v1)
`interpretation` (critical vs abnormal) in v2	⛔ Not delivered as a field — but the event type already identifies which result fired, so no signal is lost
v2 lab reference (`lab_order_id`, `lab_order_status`)	✅ Always present

🚧
interpretation is v1-only. v2 payloads carry a lab-order reference but not interpretation, labName, or the raw provider payload — so on v2 you cannot distinguish critical from abnormal. Keep this webhook on v1 if that distinction matters.

v1 payload (legacy)

ownerEntity is the full patient document (contains PHI) and targetEntity the full lab order; both abbreviated here.

{
  "ownerEntityModel": "Patient",
  "targetEntityModel": "LabOrder",
  "deleted": false,
  "ownerEntity": { "id": "pat::50c75435-xxxx-xxxx-xxxx-25220febd9cf", "firstName": "<PATIENT_FIRST_NAME>", "lastName": "<PATIENT_LAST_NAME>", "…": "full patient document" },
  "targetEntity": { "id": "lbo::3162cd49-xxxx-xxxx-xxxx-c8bb185b979a", "status": "completed", "followUpReason": "critical", "labOrderId": "OIFUJO49W5", "…": "full lab order" },
  "eventTitle": "Critical Lab Result From Quest Diagnostics",
  "eventDescription": "A critical lab result was reported by Quest Diagnostics...",
  "eventType": "lab_order_critical_result_received",
  "eventData": {
    "labOrderId": "OIFUJO49W5",
    "labName": "Quest Diagnostics",
    "interpretation": "critical",
    "externalOrderId": "ext-order-88213",
    "providerEventType": "order.completed",
    "providerOrderStatus": "completed",
    "latestProviderEventStatus": "completed",
    "reportedAt": "2025-06-19T16:40:55.000Z",
    "webhookPayload": { "event_type": "order.completed", "data": { "…": "raw provider payload" } }
  },
  "_id": "event::4a1a414e-xxxx-xxxx-xxxx-d68703d50aa1",
  "createdAt": "2025-06-19T16:41:12.108Z",
  "updatedAt": "2025-06-19T16:41:12.108Z",
  "id": "event::4a1a414e-xxxx-xxxx-xxxx-d68703d50aa1"
}

`eventData` field	Type	Always?	Notes
`labOrderId`	string	✅	Lab's order id
`labName`	string	✅	e.g. Quest Diagnostics
`interpretation`	string	✅	`critical` for this event
`externalOrderId`, `providerEventType`, `providerOrderStatus`, `latestProviderEventStatus`, `reportedAt`	mixed	✅	Provider result metadata
`webhookPayload`	object	✅	Raw provider payload

v2 payload

Sanitized envelope. Note the two lab identifiers are different values: v1 eventData.labOrderId carries the lab's external order number (e.g. OIFUJO49W5), while v2 lab_order_id is TelegraMD's internal lab-order reference (lbo::…), resolved from the event's target entity — it is a resolution, not a rename. The rest of eventData isn't on the LAB allowlist. lab_order_status/order_id resolve from the lab order.

{
  "event_type": "lab_order_critical_result_received",
  "event_id": "event::4a1a414e-xxxx-xxxx-xxxx-d68703d50aa1",
  "api_version": "2026-08-09",
  "timestamp": "2026-05-30T14:00:00.000Z",
  "affiliate_id": "aff::81253635-xxxx-xxxx-xxxx-c068ba573d7d",
  "patient_id": "pat::50c75435-xxxx-xxxx-xxxx-25220febd9cf",
  "patient_external_id": "ext-patient-123",
  "patient_marketing_consent": false,
  "is_returning_patient": true,
  "lab_order_id": "lbo::3162cd49-xxxx-xxxx-xxxx-c8bb185b979a",
  "lab_order_status": "completed",
  "order_id": "order::7a2c1e3d-xxxx-xxxx-xxxx-13f5e2a55f21"
}

Field	Delivered in v2	Notes
Envelope + patient identity	✅
`lab_order_id`, `lab_order_status`, `order_id`	✅	Resolved from the lab order (incl. follow-up order)
`interpretation`, `labName`, provider metadata	⛔	Not on the allowlist

📘
Completing the loop on v2. Full lab-order detail — the external requisition id (labOrderId), lab name, results, and a status history with dates — is retrievable via GET /labOrders/:id using the delivered lab_order_id. The endpoint is scoped to your affiliate.

Critical Lab Result Received

Field guarantees

`interpretation` is v1-only. v2 payloads carry a lab-order reference but not `interpretation`, `labName`, or the raw provider payload — so on v2 you cannot distinguish critical from abnormal. Keep this webhook on v1 if that distinction matters.

v1 payload (legacy)

v2 payload

Completing the loop on v2. Full lab-order detail — the external requisition id (`labOrderId`), lab name, results, and a status history with dates — is retrievable via `GET /labOrders/:id` using the delivered `lab_order_id`. The endpoint is scoped to your affiliate.

Field guarantees

interpretation is v1-only. v2 payloads carry a lab-order reference but not interpretation, labName, or the raw provider payload — so on v2 you cannot distinguish critical from abnormal. Keep this webhook on v1 if that distinction matters.

v1 payload (legacy)

v2 payload

Completing the loop on v2. Full lab-order detail — the external requisition id (labOrderId), lab name, results, and a status history with dates — is retrievable via GET /labOrders/:id using the delivered lab_order_id. The endpoint is scoped to your affiliate.

`interpretation` is v1-only. v2 payloads carry a lab-order reference but not `interpretation`, `labName`, or the raw provider payload — so on v2 you cannot distinguish critical from abnormal. Keep this webhook on v1 if that distinction matters.

Completing the loop on v2. Full lab-order detail — the external requisition id (`labOrderId`), lab name, results, and a status history with dates — is retrievable via `GET /labOrders/:id` using the delivered `lab_order_id`. The endpoint is scoped to your affiliate.