Filter

Filtering is the only component in this system whose entire job is to hide clinical information. That makes it the one that most needs to be honest: what is hidden, how much of it, and how to get it back — visible at all times, in one glance, without opening anything.

Overview

A clinician who forgets a filter is on is looking at a subset of a patient's record while believing they are looking at the record. Every rule here follows from that single failure: filters are loud, counted and reversible.

The system's default position is that filters are a convenience for large sets, not a workflow. They never persist silently, never survive a patient change, and never apply to anything at advisory priority or above.

Anatomy

What a filter may never hide

• Not filterable: unacknowledged critical, urgent and advisory alarms; a patient's identity band; any item the clinician has explicitly flagged.
• Filterable: resolved and acknowledged items, informational status, ward and team scoping, time windows, result types.
• Never filter to zero without saying why. An empty filtered set names the filters responsible and offers to remove them — see Empty state.
• Never filter across a patient boundary. Filters are cleared on patient change and never restored from a previous patient's session.

Persistence

A filter that outlives the clinician's memory of setting it is the hazard. So persistence is deliberately weak, and always announced.

States

Do's and don'ts

Accessibility

• The tag row is a labelled list — role="list" with aria-label="Active filters" — so the whole filter state can be read as a set, with its size announced.
• Each remove control names its filter in full: "Remove filter Ward: Emergency". A row of buttons all called "Remove" is unusable non-visually.
• The count line is a live region (aria-live="polite") so applying a filter announces the new denominator rather than silently changing it.
• Clear-all carries its count in the accessible name — "Clear all 3 filters".
• Focus after removal moves to the next tag, or to Add filter when the last one goes. It never falls to the document body.
• Tags are never colour-coded by dimension alone; the dimension is in the text.
• Never brand coral, never an alarm hue on a filter tag. Filtering is not a clinical state — see Colour.
• Targets ≥ 24 px including the remove control inside the tag, with ≥ 24 px between adjacent remove controls (WCAG 2.2 SC 2.5.8).
• Tags wrap, never scroll horizontally. A filter you have to scroll to see is a filter you do not know about (SC 1.4.10).

Outcomes of use

What this contributes to, in the terms of Usability & context of use. These are attributes believed to contribute to an outcome; the outcome itself is settled by observing real use in a specified context, not by this page.

• Effectiveness — the clinician's belief about what they are looking at matches what they are looking at. This is the whole purpose of the component.
• Efficiency — a large set narrowed in one action, and restored in one action. Neither direction should cost a mental model.
• Satisfaction — no residual doubt about whether something is hidden, which is the doubt that sends clinicians to a second system to check.

Clinical safety notes

• Active filters always rendered as readable tags. Mitigates: a filtered view mistaken for the complete record.
• Hidden quantity stated numerically at all times. Mitigates: the size of what is missing being unknowable.
• Alarms at advisory priority and above are unfilterable. Mitigates: a deteriorating patient hidden by a scoping choice made minutes earlier.
• Filters cleared on patient change. Mitigates: one patient's view constraints applied to another patient's record.
• Filters never restored silently at sign-in. Mitigates: a shift beginning inside a narrowed view nobody set today.
• Previous set retained while applying. Mitigates: a blank region read as an absence of patients.
• Zero-result state names the responsible filters. Mitigates: an over-narrow filter read as "nothing to do".
• Criteria written in clinical language. Mitigates: a filter misread under time pressure and left on.

Implementation

$ npx shadcn@latest add https://md.notjustany.tech/r/filter.json

// The escape rule is enforced in the component, not in each product's
// query layer, because it is the control that must not be forgotten.
<FilterBar
  label="Worklist filters"
  filters={active}
  total={19}
  shown={4}
  onRemove={remove}
  onClearAll={clearAll}
  escaped={escapedAlarms}        // items the filter would have hidden
/>

// Anything unacknowledged at advisory or above escapes the filter and is
// reported above the set. There is no flag to switch this off.
const escapes = (item) =>
  item.alarm && !item.acknowledged &&
  PRIORITY_ORDER[item.alarm] >= PRIORITY_ORDER.advisory

if (shown < total && escaped === undefined) {
  throw new Error("[FilterBar] a narrowed set must compute its escaped items.")
}

Related

• Data grid — the primary consumer, and its column filters.
• List & tree — the same denominator rule at a smaller scale.
• Search — narrowing by query rather than by criterion.
• Empty state — what a filtered-to-zero set must say.
• Triage worklist — why handover is never filtered.
• Tokens & governance — why the escape rule has no override.