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.
Overview
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.