When consumer software fails, someone reloads the page. When software inside a medical device fails, a patient may be exposed to the wrong radiation dose, a clinician may act on an image belonging to someone else, or a diagnosis may simply be delayed while the equipment is out of service. The consequences do not scale like ordinary bugs, and neither can the engineering.

Software has become the largest source of complexity in modern medical equipment. A mammography system or an MRI subsystem contains far more logic than mechanism, and the behaviour a clinician experiences is largely determined by code. That shift is why regulators, hospitals and manufacturers all treat device software as a safety concern in its own right rather than as an implementation detail.

What failure actually looks like

The failures that matter in practice are rarely dramatic crashes. They are quieter and more dangerous:

• Wrong patient association : an image acquired under one patient's identity and stored under another's. The system reports success; the error surfaces at reporting, or never
• Incorrect parameter application : a control system applying a value that was superseded, or applying the right value to the wrong axis
• Silent data corruption : an image stored with damaged pixel data or wrong orientation metadata, where nothing alerts anyone
• Unhandled state on interruption : a power interruption mid acquisition leaving the device in a state its designers never enumerated
• Degradation under load : behaviour that is correct in testing and unreliable during a busy clinic
• Availability failure : the device works correctly but is unavailable, and a medical imaging system out of service for a day is a genuine clinical cost

The common thread is that most of these produce a plausible-looking wrong result rather than an obvious fault. Software that fails loudly is comparatively safe. Software that fails quietly is the problem.

Reliability is designed, not tested in

The most persistent misconception is that reliability comes from testing harder at the end. Testing finds defects; it does not create reliability. By the time software reaches a test department, its reliability characteristics are already largely determined by decisions taken much earlier.

Start from hazards, not features

Safety-critical development inverts the usual order. Before asking what the software should do, the question is what harm the device could cause and how software contributes to it. ISO 14971 provides the framework: identify hazards, estimate risk, apply controls, verify those controls actually work.

Software then implements risk controls that were derived deliberately, rather than acquiring safety properties by accident.

Architecture carries the load

Where a hazard is severe, the mitigation belongs in the structure of the system:

• Separation of concerns : safety-critical control isolated from user interface and networking code, so a fault in the less critical part cannot propagate
• Independent verification : a second, simpler mechanism checking that the primary one is behaving, sized so it can be reasoned about completely
• Defined safe states : the device has an explicitly designed behaviour for every failure it can detect, rather than an emergent one
• Deterministic timing : where control loops have real deadlines

IEC 62304 and why process matters here

IEC 62304 defines the software life cycle processes for medical device software. It is sometimes treated as documentation overhead, which misreads what it is doing.

The standard classifies software by the harm a failure could cause — Class A where no injury is possible, Class B where non-serious injury is possible, Class C where death or serious injury is possible — and scales the required rigour accordingly. Higher classes require more detailed architectural design, unit-level verification and traceability.

What that produces, when done properly, is traceability: every requirement traces to a design element, to code, and to the tests that verify it. The practical value is not the paperwork. It is that when something changes three years later, an engineer can determine what that change affects, and what must be re-verified.

Most field failures in long-lived devices originate in maintenance changes made without full understanding of their consequences. Traceability is the defence against precisely that.

Verification that means something

Verification in this context goes beyond checking that features work:

• Requirements-based testing : each requirement has tests demonstrating it is met, with results recorded
• Boundary and invalid input testing : the values a well-behaved user never produces, but a busy clinic eventually will
• Fault injection : deliberately removing the network, the disk, or power at inconvenient moments to observe real recovery behaviour
• Interoperability testing : against the systems the device will actually meet in the field, not just a reference implementation
• Load and endurance testing : software that leaks a small amount of memory per study is fine for a day and fails in the fourth week
• Regression testing : so that fixing one defect does not quietly introduce another

Third-party and legacy software

Almost no device is built entirely from new code. Operating systems, libraries and imaging toolkits all carry risk that must be assessed rather than assumed away. IEC 62304 refers to this as SOUP — Software of Unknown Provenance — and requires that its use be justified, its known defects reviewed, and its behaviour verified within the device's context.

Legacy platforms raise the same question with added weight. Long-lived equipment often runs software written years ago, sometimes for operating systems no longer supported. Modernising it is a reliability activity as much as a feature one: an unsupported platform accumulates unpatched vulnerabilities and becomes progressively harder to build, test and repair.

Reliability after release

A device's software life continues for as long as the equipment is in service, often a decade or more. Sustaining that reliability requires:

• Post-market surveillance : field issues captured, analysed and fed back into development
• Controlled change : every modification risk-assessed and re-verified against the traceability established during development
• Security maintenance : connected devices face threats that did not exist when they shipped, and a security failure is now a safety failure
• Obsolescence management : planning for components, operating systems and libraries reaching end of life before they do

The commercial case

Reliability is usually argued on safety grounds, and rightly so. But it is also the better commercial position:

• A defect found in design costs a fraction of the same defect found in the field, where it may involve a recall
• Regulatory submissions supported by genuine traceability proceed more predictably than those assembled retrospectively
• Hospitals evaluate vendors on service history, and equipment with a reputation for unreliability loses future business regardless of its specification
• Well-structured, traceable software is cheaper to maintain across a decade of service life — which is where most of the total cost actually sits

In short

Software reliability in medical devices is not achieved by writing careful code, though that helps. It comes from deriving requirements from hazards, designing an architecture where safety functions are small and verifiable, following a life cycle process that produces real traceability, verifying against realistic conditions, and maintaining all of it for as long as the device is in clinical use.

The discipline is demanding. It is also the difference between equipment a hospital trusts and equipment it merely tolerates.