Flag Profile¶

Canonical	`../StructureDefinition/nexus-emr-core-flag`
Status	draft · 1.26.0
Base	Flag (constraint)
Source	FSH · JSON

Nexus EMR profile for Flag, carrying a singleton administrative free-text field about a patient (booking alert or patient note). The patient-flag-type coding discriminates the field; the free text rides on Flag.code.text. Backs the Patient Profile Notes section.

Overview

The Nexus EMR Core Flag profile is an administrative "sticky note" about a patient. It backs the two singleton free-text fields of the Patient Profile "Notes" section — the booking alert (intended for booking and banner surfaces) and the general patient note — storing each as one active Flag. Flag is FHIR's own home for this kind of note, so no extension is involved.

The unusual part is the storage shape: the type of field is a coding on Flag.code, and the field's text is Flag.code.text. At most one active Flag per flag type exists per patient, and a field with no text stores no Flag at all. subject is 1..1 MS, restricted to Reference(Patient).

`code` carries both the field and its text

code is 1..1 MS, bound extensible to the nexus-emr-patient-flag-type value set, with code.coding 1..* MS and code.text 1..1 MS. The two published types are:

booking-alert — a short administrative alert for booking and front-desk staff
patient-note — a general administrative free-text note about the patient

So the coding says which field this is and code.text is the field's content. That is worth stating because CodeableConcept.text is normally the display fallback for a coding, and here it is not: it is the payload, it is mandatory, and it never restates the concept's display. A reader that renders the coding display and ignores code.text shows the label instead of the note. Because the binding is extensible, treat an unrecognised flag type as a note to display rather than a defect.

category is 1..* MS and pattern-pinned to http://terminology.hl7.org/CodeSystem/flag-category#admin — every Flag in this IG is administrative. The pattern pins system and code only, so a producer that omits or localizes the display stays conformant, and additional categories may travel alongside.

Flags are retired, never edited or deleted

status is the soft-delete axis and this model uses it instead of mutation:

Changing a field's text retires the current Flag to inactive (keeping its text) and creates a replacement active Flag.
Clearing a field retires the current Flag with no replacement.
entered-in-error is reserved for retracting a Flag that should never have been recorded.

A field's history is therefore the chain of its retired Flags, ordered by resource history, and what was removed or superseded stays queryable. Two implementer consequences follow. First, readers must filter to status = active: a retired Flag no longer backs its field, so an unfiltered read of a patient's Flags shows every superseded version of both fields and appears to contain duplicates. Second, do not update a Flag's code.text in place — that destroys the history the retirement chain exists to keep.

`period` is not populated

This model never writes period, and the profile deliberately declares no effective date rather than naming an element nothing populates. Order a field's history by resource history, not by a date on the Flag, and do not treat a missing period as incomplete data.

meta.source (0..1 MS) identifies the EMR instance and pipeline version the resource came from, and text (0..1 MS) carries the human-readable narrative. The profile is exposed to SMART apps for read, write, and delete (flag:read, flag:write, flag:delete) — note that the retirement model above, not delete, is how a note is removed.

Terminology bindings

Path	Strength	Value set
`Flag.category`	extensible	flag-category