Event log

The durable record. Append-only by the shape of its props: there is no edit, no delete and no clear.

Overview

Three pages in this system already argue from a durable record. Toast queue says a toast is safe to dismiss because what it reports is written somewhere permanent. Alert banner says a critical alert always leaves a trace. Acknowledge & escalate says an acknowledgement is terminal because it persists. Until this component existed, all three arguments were complete and had nothing underneath them.

Anatomy

What a log may never do

• Never edit an entry. Not to fix a typo, not to correct an attribution. The corrected version is a new entry that references the old one, and both are readable.
• Never delete an entry, including one written in error. “Acknowledged in error” is itself a clinically meaningful fact: it says an alert was dismissed by somebody who was not looking at it.
• Never collapse repeated entries into a count. Twelve identical alarms in four minutes is a different record from one alarm with a badge saying twelve — see Messaging.
• Never order by anything but time, and never re-order. A log read as a sequence is a claim about causality; sorting it by severity makes a claim nobody meant.
• Never show an entry without its actor. An unattributed action in a clinical record is a gap in the record, not a tidy entry.

When the actor is not a person

Most entries in a clinical event log are written by software, and a reader scanning for what a colleague did should not have to work out which is which. The actor union makes the distinction structural rather than a naming convention.

• Software carries its version. “AcuteLine 4.2” and “AcuteLine 4.3” may have raised that alarm for different reasons — see Model version & change.
• A person carries their role, because the role is what decided the action was permitted.
• An action taken by software on a person's instruction is two entries, not one. The instruction and the execution have different times and can fail independently.
• Nothing here is signed. A displayed log is a rendering of a record; the integrity of that record is your storage's problem, and it is the part that matters — see what this component enforces.

Do's and don'ts

What the component enforces, and what it only asks for

A displayed log is a rendering. The rules that make a record trustworthy are almost all about storage, and none of them can be held by something that draws a list.

Accessibility

• A real <ol> with a name. The order is the meaning, and a screen reader announces the position and the count.
• Times are in <time datetime>, so the machine-readable value is available alongside the human one.
• The actor kind is a word — “automatic” — not a glyph and not a colour. It survives greyscale and is announced.
• A correction notice is text in the entry, not a strikethrough. Struck text is announced inconsistently and read as decoration.
• Nothing here is a live region. A log that announces every arriving entry is unusable; the reader comes to it, it does not come to them.

Outcomes of use

• Effectiveness — a clinician can reconstruct what happened, who did it, and what was known at the time.
• Efficiency — the sequence is readable without cross-referencing a second system.
• Satisfaction — not having to trust a summary. Attributes believed to contribute to an outcome; the outcome is settled by observing real use, not by this page — see Usability & context of use.

Clinical safety notes

• No entry can be edited or removed through this component. (the component) Mitigates: a record that reflects what is currently believed rather than what happened.
• Every entry is attributed, and software is marked as software. (the component) Mitigates: an automatic action read as a clinical decision somebody made.
• A shortened view states the size of the record. (the component) Mitigates: a partial log read as complete, which is how an absent entry becomes evidence that nothing happened.
• Repeated events are not collapsed. (the component) Mitigates: an alarm rate — the thing IEC 60601-1-8 cares about — made invisible by a multiplier.

Implementation

$ npx shadcn@latest add https://md.notjustany.tech/r/event-log.json

<EventLog
  caption="Alert activity · HARLAND, A."
  orderedBy="newest first"   // required: an unstated order is a claim about causality
  totalCount={47}                // required: a shortened view cannot read as the whole record
  entries={[
    { id: "evt-118", at: "14:41:07 CEST",
      actor: { kind: "person", name: "S. Whitfield", role: "Registrar" },
      action: "Corrected the acknowledgement", subject: "STEMI alert · 14:26" },
    { id: "evt-092", at: "14:26:38 CEST",
      actor: { kind: "system", name: "AcuteLine", version: "4.2" },
      action: "Raised a critical alarm", subject: "STEMI pattern",
      supersededBy: "evt-118" },
  ]}
/>

// There is no onEdit, no onDelete and no onClear. Correcting a record
// means appending an entry that says so; both stand.

Related

• Toast queue — the transient copy of what is written here, and why it is safe to dismiss.
• Alert banner — the alarm whose trace this holds.
• Acknowledge & escalate — what an acknowledgement is, and why it is terminal.
• Authorship & the record — who a recorded action belongs to.
• Date & time picker — why every time here carries its zone.