Follow an order through to its result, then design an alert on that pathway that clinicians will not learn to dismiss.

An order is an accountable request, not a message

A clinician decides a patient needs something: a blood test, an imaging study, a medication, a referral, a diet change. Placing that order through computerised provider order entry creates a durable record with three properties that shape every system touching it.

It has an author and an owner, which are not always the same person. The author is who entered it, which may be a resident or, under protocol, a nurse. The owner is the clinician accountable for acting on what comes back. Systems that record only the author lose track of accountability the moment a shift changes.

It has a state machine, and the states are clinically meaningful rather than technical. An order is drafted, placed, accepted by the performing department, scheduled, in progress, completed, or it is rejected, cancelled, held, or revised. A specimen can be collected and then rejected by the laboratory as unsuitable, which is not a failure of the order but a return to a prior state with a reason attached. In FHIR the request itself is a ServiceRequest or MedicationRequest, the work is tracked as a Task, and the outputs come back as Observation and DiagnosticReport resources; in an HL7 v2 estate the same flow moves as order and result messages between the electronic record and the laboratory or radiology system.

And it produces a result that somebody must see and acknowledge. This is the part that carries the clinical risk. A result that arrives correctly, is filed correctly to the right patient, and is never read by a human is one of the recognised patterns of avoidable harm in outpatient care. So the result is not the end of the order. Acknowledgement is.

The result side is where the design work is

Results arrive asynchronously, sometimes days later, sometimes in parts. A microbiology culture yields a preliminary result and then a final one with sensitivities, and both matter. A radiology report may be issued provisionally by one radiologist and amended by another. A corrected laboratory result supersedes a value the clinician may already have acted on.

Three requirements fall out of that, and a system missing any one of them is unsafe rather than merely inconvenient.

Every result must be matched to an order and to a patient with certainty, and where it cannot be, it goes to a human queue rather than being filed on a best guess. Silent mismatching is worse than an unfiled result because it puts one patient's data in another's record.

Every result must have a live acknowledgement obligation attached to a named person, with an escalation path when that person does not exist any more. The clinician who ordered it has left, the patient has been discharged, the clinic has closed for a fortnight: each of those is normal, and each needs a defined next owner rather than an orphaned flag. An unacknowledged critical result should be capable of escalating out of the electronic record altogether, to a phone call, because the safety net cannot be inside the system that is failing to get attention.

Amendments must be first-class. A corrected result has to reopen the acknowledgement obligation even if the original was already signed off, and the record has to show what the clinician saw at the time they made their decision, not only the current value. Overwriting is not an option in a record that will be read forensically.

Designing an alert that survives contact with a ward

Now the harder half. Decision support fires on this pathway: a drug-drug interaction on a medication order, a dose outside range for the patient's renal function, a duplicate test already performed, a critical value on a returning result. The failure mode is well documented and universal, which is that clinicians who receive a high volume of low-value interruptions learn to clear them without reading, and then clear the important one the same way. The habit is a rational adaptation to a badly designed system, and it is the system's fault.

Design against it with a small number of hard rules.

Start from the action, not the detection. Before writing the rule, answer: who receives this, what specifically will they do differently, and what happens if they do nothing? If you cannot name the action, you have built a notification rather than decision support, and it should be a passive display in the chart rather than a modal. A great many rules die honestly at this question.

Match severity to interruption. An alert that stops the workflow and demands a reason must be reserved for things where continuing is likely to harm the patient. Everything else is passive: an inline annotation next to the field, a colour on the value, a line in a review list. Uniform interruptive delivery for everything is the single largest cause of the fatigue, because it removes the signal that interruption is supposed to carry. Some categories, such as a genuinely contraindicated combination, deserve a hard stop that cannot be overridden without a second clinician; using that mechanism for anything less devalues it.

Deliver to whoever can act. An alert about a nursing task presented to a physician, or a pharmacy alert presented at the point of prescribing when only the pharmacist can resolve it, produces a dismissal and nothing else. Routing is part of the design.

Be specific enough to be trusted once. "Potential interaction" with a list of eleven drugs teaches the reader that the alert has not done any work. "This patient's creatinine clearance was measured yesterday and this dose exceeds the range for that value" is a sentence a clinician can evaluate in two seconds. Include the data that triggered it, the recommendation, and a one-click route to the compliant alternative. If accepting the advice takes more clicks than overriding it, the override rate is a measure of your interface, not of clinical judgement.

Suppress what the clinician already knows. Do not re-fire on a combination the same prescriber deliberately continued this admission. Do not fire on a test that has already been ordered by someone else if the alert cannot show who and when. Repetition of an already-answered question is the fastest way to train dismissal.

Instrument it and be willing to delete it. Every rule needs an override rate, a time-to-dismiss, and a rate of subsequent action, reviewed on a schedule. An alert with a very high override rate is not evidence of non-compliant clinicians; it is evidence that the rule is wrong, too broad, or badly targeted, and the response is to narrow it or retire it. Retirement has to be a normal, routine act. A governance process that only ever adds rules guarantees the fatigue it is trying to prevent, and the burden of justification should sit on keeping a rule, not on removing it.

The part that gets missed

Most designs treat dismissal as user non-compliance to be engineered around with a stronger modal, a mandatory free-text reason, or a longer delay before the button activates. Each of those raises the cost of dismissing without raising the value of the alert, so the clinician's behaviour does not change and their frustration does. The only durable fix is to fire less. An alerting system's quality is the proportion of its firings that change a decision, and that proportion goes up almost exclusively by removing rules, tightening them against the specific patient's data, and demoting them from interruptive to passive. A system that fires ten times a shift and is right twice has trained its users to ignore it, and no amount of interface friction will untrain them.

The measure of a decision-support rule is not how many risks it detects but how many decisions it changes. Rules that fire without changing anything are not neutral; they consume the attention the important rules need.