Skip to content

Encounter Abnormal Extension

Canonical../StructureDefinition/encounter-abnormal
Statusdraft · 1.26.0
BaseExtension (constraint)
ContextEncounter (element)
SourceFSH · 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.