Prescription was rejected

When a provider rejects a prescription, TelegraMD emits two events — there is no single dedicated prescription_rejected event. Detecting a denial (and its reason) requires knowing where each piece of information lives.

Event	`targetEntity`	Carries
`new_status_set_to_request`	`PrescriptionFulfillment`	`eventData.newStatus = "rejected_by_provider"`; the reason also appears in its free-text `eventTitle`
`order_updated`	`Order`	The rejection reason in the free-text `eventDescription` — only emitted on the first rejection of a given prescription

Field guarantees

Signal	v1	v2
That a denial happened	✅ `order_updated` title/desc or `new_status_set_to_request.newStatus`	✅ `new_status_set_to_request` → `order_status: "rejected_by_provider"`
The denial reason	⚠️ Free text only — in the `eventTitle` of `new_status_set_to_request` and the `eventDescription` of `order_updated`; never a structured field	⛔ Not available — v2 has no title/description

🚧
The rejection reason is v1-only, and unstructured even there. The reason is written into eventTitle/eventDescription free text, never into a structured eventData field. v2 payloads have no title/description, so on v2 you can detect the denial (via new_status_set_to_request → order_status = "rejected_by_provider") but cannot recover the reason. A dedicated prescription_rejected_by_provider event with a structured rejection_reason is planned — until then, use v1 if you need the reason. See Field Guarantees.

v1 payload — the `order_updated` firing (carries the reason)

targetEntity is the Order. Note eventData is empty — the reason is in eventDescription only.

{
  "ownerEntity": "pat::xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "ownerEntityModel": "Patient",
  "targetEntity": "order::xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "targetEntityModel": "Order",
  "eventTitle": "Prescription was rejected",
  "eventDescription": "The prescription of the order was rejected for the following reason: \"<REJECTION_REASON>\"",
  "eventType": "order_updated",
  "eventData": {},
  "deleted": false,
  "createdAt": { "$date": "2025-01-15T15:03:03.220Z" },
  "updatedAt": { "$date": "2025-01-15T15:03:03.220Z" },
  "__v": 0
}

v1 payload — the `new_status_set_to_request` firing (carries the status)

targetEntity is the PrescriptionFulfillment. eventData.newStatus is the reliable structured signal of the denial.

{
  "ownerEntity": "pat::xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "ownerEntityModel": "Patient",
  "targetEntity": "prfm::xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "targetEntityModel": "PrescriptionFulfillment",
  "eventTitle": "Provider (<PROVIDER_NAME>) rejected the prescription for the following reason: \"<REJECTION_REASON>\"",
  "eventType": "new_status_set_to_request",
  "eventData": {
    "newStatus": "rejected_by_provider"
  },
  "deleted": false,
  "createdAt": { "$date": "2025-01-15T15:03:03.220Z" },
  "updatedAt": { "$date": "2025-01-15T15:03:03.220Z" },
  "__v": 0
}

v2 payload

On v2, detect the denial via the new_status_set_to_request event — newStatus aliases to order_status, which is on the ORDER allowlist, so the status value comes through. The reason is not available (no eventDescription in v2).

{
  "event_type": "new_status_set_to_request",
  "event_id": "event::xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "api_version": "2026-08-09",
  "timestamp": "2026-05-30T14:00:00.000Z",
  "affiliate_id": "aff::xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "patient_id": "pat::xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "patient_external_id": "ext-patient-123",
  "patient_marketing_consent": false,
  "is_returning_patient": false,
  "order_status": "rejected_by_provider"
}

Field	Delivered in v2	Notes
`order_status`	✅	`"rejected_by_provider"` — your denial signal on v2
Rejection reason	⛔	Free-text only in v1's `eventDescription`; no v2 equivalent