Action on Abnormal Extension

Canonical	../StructureDefinition/action-on-abnormal
Status	draft · 1.26.0
Base	Extension (constraint)
Context	ServiceRequest (element)
Source	FSH · JSON

Records that the requester wants this order brought back to them if what it produces is abnormal.

FSH

The authored source of truth: extensions/ServiceRequestActionOnAbnormalExtension.fsh (edit on GitHub). One FSH file may define several related artifacts.

// ServiceRequestActionOnAbnormalExtension.fsh
// The requester's standing instruction on one order: bring this back to me if what comes back is
// abnormal.
//
// WHY IT IS ON THE ORDER AND NOT ON THE RESULT. It is a preference recorded when the order is
// placed, before anything is known about the result, and it applies to whatever the order
// eventually yields. Putting it on a result would mean writing it after the fact, on each result
// separately, which is a different instruction and a later one. R4 offers no element for it:
// `priority` is about how fast the order is worked, `intent` is about what authority it carries,
// and neither says what should happen if the answer is abnormal.
//
// IT IS AN INSTRUCTION, NOT A FINDING. Nothing about this flag says a result WAS abnormal, and a
// consumer must not read it as an abnormality marker. Whether the instruction ever fires is decided
// later, by a periodic review of what the order produced; that evaluation is a Nexus EMR behaviour
// rather than a shape this specification describes, and its outcome is visible on the order's own
// notes and on the tasks filed against it, not here.
//
// ABSENT AND `false` MEAN THE SAME THING. A writer creates the extension only when turning the
// instruction on, and thereafter sets the value in place, so `false` appears on orders where the
// instruction was once on and has been turned off. Neither carries anything the other does not.
//
// THE ADDRESS THIS IS PUBLISHED AT IS NOT THE ONE THE SOFTWARE WRITES TODAY. The migration note is
// in the Description below, which is the text that travels inside the package; the handbook states
// the rule and indexes every published artifact in this position, in
// `docs/guide/patterns/canonical-urls.md`.

Extension: ServiceRequestActionOnAbnormal
Id: action-on-abnormal
Title: "Action on Abnormal Extension"
Description: """
Records that the requester wants this order brought back to them if what it produces is abnormal.

**An instruction recorded on the order, not a finding about a result.** It is set when the order is
placed and applies to whatever the order eventually yields. Nothing about a value of `true` says any
result was abnormal, and a consumer must not read it as an abnormality marker -- `Observation`
interpretation codes are where that question is answered.

**Whether the instruction fires is decided elsewhere**, by a periodic review of what the order
produced. This element is the preference alone: it changes nothing by itself, and a consumer must
not infer from its presence that any review has run, that any result was abnormal, or that anyone
was notified. Where such a review does act, it does so by adding to the order's own `note` and to
the tasks filed against the order, not by writing back here.

**Absent and `false` mean the same thing.** A writer creates the extension only when switching the
instruction on and thereafter sets the value in place, so `false` occurs on orders where it was once
on. Read either as "not requested".

**At most one per order.** A reader encountering more than one should take the first.

**Nothing acts on this instruction today.** The review that would surface an abnormal result reads a
companion marker alongside this flag, and no writer produces that marker, so an order carrying
`true` records the preference and goes no further; that is tracked as FHIR-387. Treat the value as
the requester's stated preference alone, and never as evidence that a review ran or that a result
was abnormal.

**Nexus EMR writes this today at
`http://services.well.com/fhir/ServiceRequest/action-on-abnormal` (FHIR-371)**: it is live in
stored `ServiceRequest.extension` values and in code, and is under migration to the canonical
declared here. Write the canonical; expect both until the migration completes, and match both
addresses exactly -- the pre-migration address carries a `ServiceRequest` path segment the canonical
does not, so a rule built on the whole address rather than its last segment will not reach it.
"""
* ^url = "../StructureDefinition/action-on-abnormal"
* ^status = #draft
* ^context[0].type = #element
* ^context[0].expression = "ServiceRequest"
* extension 0..0
* url 1..1
* value[x] 1..1 MS
* value[x] only boolean
* valueBoolean ^short = "True when the requester asked to be brought an abnormal result"
* valueBoolean ^definition = "`true` when the requester asked for this order to be surfaced to them if what it produces is abnormal. `false` means not requested and carries nothing an absent extension does not; it exists so the instruction can be switched off in place."