medplum / medplum / 26255510787

92%

push

github

Soft-delete draft MR on order-medication failure (#9273)

* feat(medication-order): soft-delete draft MR on order-medication failure

When `$order-medication` throws after the draft `MedicationRequest` has been
created, hard-deleting the orphan record races against vendor acceptance — if
the vendor side already created (and possibly transmitted) the prescription
before the response was lost, we lose the only local handle that an inbound
vendor webhook can use to reconcile.

Replace the hard `DELETE` in `OrderMedicationPage.submitSingle`'s `catch`
branch with `updateResource({ ...mr, status: 'unknown', statusReason })`.
The `statusReason` carries a canonical CodeableConcept built by the new
`buildMedicationRequestResponseLostStatusReason()` helper in
`@medplum/core/medication-order-utils`, which exports two new constants:

  - `MEDICATION_REQUEST_STATUS_REASON_SYSTEM`
    (`https://medplum.com/fhir/CodeSystem/medication-request-status-reason`)
  - `MEDICATION_REQUEST_STATUS_REASON_RESPONSE_NOT_RECEIVED`
    (`'response-not-received'`)

`status: 'unknown'` is a valid FHIR R4 MedicationRequest status; PUT is
idempotent so retries are safe; update failures are still swallowed so the
user sees the original error. The compound flow is untouched (it doesn't
pre-create a draft MR). `MedicationsPage` filters that hide non-active
prescriptions must treat `'unknown'` as inactive alongside `'draft'`;
vendor webhook bots that observe an order whose pending-id matches an MR
with this `statusReason` coding should transition it to the live status.

Closes the first deferred row from PR #8999 review comment r3276980997.

Tests:
- packages/core: 4 new tests for the new constants + helper shape, system
  stability, code stability, and fresh-object-per-call (35/35).
- medplum-provider: existing failure-path test rewritten to assert
  \`updateResource\` was called with \`status: 'unknown'\` + the canonical
  \`statusReason.coding[0]\` system/code, and that \`deleteResourc... (continued)

21432 of 24152 branches covered (88.74%)

Branch coverage included in aggregate %.

3 of 3 new or added lines in 1 file covered. (100.0%)

35213 of 37397 relevant lines covered (94.16%)

23573.88 hits per line