A normal screen can conceal a failure

The most reassuring software failure may be the most dangerous one: nothing crashes, no alarm sounds and the screen looks entirely normal.

Medical software can fail quietly when it displays stale data as current, associates a result with the wrong patient, misinterprets a unit or presents a value in a way that invites the wrong conclusion. The output remains plausible. That plausibility allows the failure to travel further than an obvious error.

A fictional near miss

ClearPath receives creatinine results and other observations from a hospital interface. Following a short outage, the interface reconnects. The latest result is not received, but the previous value remains in the local cache.

The dashboard loads normally. The patient name is correct. The displayed value is clinically plausible. The deterioration score is calculated exactly according to the specification—but from stale input.

No exception is thrown. A conventional test that asks whether the calculation returns the expected answer will pass.

The failure is not in the arithmetic. It is in the unexpressed assumption that the input is current.

Plausibility defeats superficial control

Quiet failures commonly involve:

  • Stale, duplicated, incomplete or out-of-sequence data.
  • Milligrams interpreted as micrograms, or conventional units treated as SI units.
  • Patient, specimen or episode mismatches.
  • Default values that look like genuine measurements.
  • Truncated displays, misleading rounding or hidden qualifiers.
  • A successful message acknowledgement that confirms transport, not correct clinical processing.
  • Decision-support logic applied outside the population or conditions for which it was validated.

These hazards sit across interfaces and responsibilities. The sender may believe it transmitted correctly; the receiver may believe it parsed correctly; the user may believe the display represents the latest verified state.

Make uncertainty visible

The design should preserve and expose the information needed to judge the output. Depending on the product, that may include source, acquisition time, receipt time, units, status, corrections and the completeness of the input set.

The software should define when data are too old, incomplete or inconsistent to support the intended calculation. It should not silently substitute a convenient value merely to keep the workflow moving.

This does not mean overwhelming users with technical metadata. It means presenting the clinical meaning of uncertainty clearly: current, delayed, incomplete, corrected or unavailable.

Test the lies the system could plausibly tell

Happy-path testing proves that the system works when its assumptions hold. Quiet-failure testing challenges those assumptions.

Useful tests deliberately introduce:

  • Old timestamps with otherwise valid values.
  • Correct values attached to the wrong identifier.
  • Unit and decimal-place variations.
  • Replayed, duplicated and re-ordered messages.
  • Corrections received after an earlier result was acted upon.
  • Partial data sets that nevertheless permit a calculation.
  • Display widths, localisation and rounding at clinical decision boundaries.

The acceptance criterion should address what the user sees and can conclude—not merely what appears in a log.

Monitoring must look for silent degradation

Post-market monitoring often concentrates on crashes, uptime and support tickets. Those measures can remain healthy while clinical input quality deteriorates.

Manufacturers should consider monitoring data age, missing-field rates, unexpected unit distributions, interface corrections, rejected records and changes in the population receiving outputs. Such monitoring must be designed with privacy, security and regulatory obligations in mind, but the absence of monitoring is itself a lifecycle risk.

The uncomfortable review question

Ask the development team: what incorrect output could this software produce while appearing to work normally?

The answers are likely to reveal requirements, risk controls and tests that a crash-focused review would miss.

Safety is not demonstrated by the absence of visible failure. For medical software, it also depends on preventing—and detecting—convincing misinformation.

Discussion question

Which quiet failure would be hardest for users or support staff to recognise in your product?

Continue learning

Develop the subject in greater depth

MTL-107: Software lifecycleTurn assumptions about data freshness, units, patient identity and failure behaviour into controlled requirements and verification evidence.Study at MedTech Learning →MTL-108: Product cybersecurityExplore interface integrity, resilient design, detection of degraded operation and monitoring throughout the product lifecycle.Study at MedTech Learning →

Key takeaways

  • Plausible outputs can conceal stale data, incorrect units or patient mismatches.
  • Define acceptable input age, completeness and consistency, and make uncertainty visible.
  • Challenge interface assumptions with quiet-failure tests, including replayed and corrected records.
  • Check what the user sees and can conclude, as well as the calculation and logs.
  • Monitor input quality and silent degradation throughout the supported lifecycle.

Authoritative sources

This article provides general educational information. Applicable requirements depend on the device, jurisdiction, lifecycle stage and current regulatory position.