Encounter Abnormal Extension¶
| Canonical | ../StructureDefinition/encounter-abnormal |
|---|---|
| Status | draft · 1.26.0 |
| Base | Extension (constraint) |
| Context | Encounter (element) |
| Source | FSH · JSON |
Marks an encounter as abnormal: what this visit produced warrants somebody looking at it.
Overview
One flag on the encounter, not a finding about any one result. R4 offers no element for this --
diagnosis names conditions and status names where the visit got to -- and it is deliberately
coarser than an Observation.interpretation code, which answers the same question for a single
measurement. This exists so a workflow can find the encounter at all without re-reading everything
filed under it. A consumer wanting to know WHICH result was abnormal must read the results.
Setting it has a consequence on a different resource. A periodic review walks orders carrying
the action-on-abnormal instruction, follows each
order to its appointments and each appointment to its encounters, and where any of those encounters
carries this flag as true it flags the ORDER as needing review: a system note is added to the
order, and every task filed against the order is given needs-review business status. Write true
only where that outcome is intended.
Absent and false mean the same thing. The review treats a missing extension, a false value
and an unreadable one alike, and raises no error on any of them. false exists so the flag can be
cleared in place rather than by removing the extension.
At most one per encounter. A reader meeting more than one should take the first.
Nothing writes this today. No writer in Nexus EMR produces the marker, so the review described
above currently never fires on it and every encounter in the estate reads as not abnormal; that is
tracked as FHIR-387. It is declared because the reader is live: an encounter carrying true from any
source WILL be acted on as described. Treat this as an input contract, not as a field to expect in
data Nexus EMR hands you.
MIGRATION. The reader in Nexus EMR looks for this extension today at
http://services.well.com/fhir/encounter/is-abnormal, an address on a host this specification does
not govern, minted in application code before the guide declared the extension; the move onto the
canonical declared here is tracked as FHIR-371. Write the canonical; expect both until the migration
completes, and match both addresses exactly rather than deriving one from the other -- they share no
final segment, so a rule built on the last path element reaches neither from the other.