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.

FSH

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

// EncounterAbnormalExtension.fsh
// The marker saying an encounter is abnormal, and the companion the standing "bring this back to me
// if it comes back abnormal" instruction on an order looks for.
//
// WHY IT IS AN EXTENSION. R4 has no element on Encounter for "what this visit produced was
// abnormal". `Encounter.diagnosis` names conditions, `status` names where the visit got to, and
// neither carries a judgement about the result. The judgement is also not the same fact as an
// `Observation.interpretation` code: this is one flag on the whole encounter, set so a later
// workflow can find the encounter without re-reading everything filed under it.
//
// WHAT READS IT, AND WHAT THAT COSTS A WRITER. A periodic review walks orders carrying the
// `action-on-abnormal` instruction, follows each order to its appointments and each appointment to
// its encounters, and if any of those encounters carries this flag as `true` it flags the ORDER as
// needing review -- a system note on the order, and needs-review business status on every task filed
// against it. That is a real workflow consequence of a single boolean on a different resource, and
// it is stated in the Description because a writer needs to know it before setting the flag.
//
// IT HAS NO WRITER TODAY, and the guide already says so in the other half of the pair: the
// `action-on-abnormal` Description tells a reader that the review "reads a companion marker
// alongside this flag, and no writer produces that marker". This IS that marker, and until now the
// guide would not say which address it was -- a reader told a marker exists and not told its name
// can do nothing with either statement. Naming it is the point of this file.
//
// THE ADDRESS THIS IS PUBLISHED AT IS NOT THE ONE THE SOFTWARE READS 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: EncounterAbnormal
Id: encounter-abnormal
Title: "Encounter Abnormal Extension"
Description: """
Marks an encounter as abnormal: what this visit produced warrants somebody looking at it.

**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`](StructureDefinition-action-on-abnormal.md) 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.
"""
* ^url = "../StructureDefinition/encounter-abnormal"
* ^status = #draft
* ^date = "2026-09-14"
* ^publisher = "WELLSTAR Technologies Corp."
* ^context[0].type = #element
* ^context[0].expression = "Encounter"
* extension 0..0
* url 1..1
* value[x] 1..1 MS
* value[x] only boolean
* valueBoolean ^short = "True when this encounter is marked abnormal"
* valueBoolean ^definition = "`true` when this encounter is marked abnormal and a review of the orders it answers should surface it. `false` means not abnormal and carries nothing an absent extension does not; it exists so the flag can be cleared in place."