Medical devices are designed, tested, manufactured, and reviewed with safety in mind. Yet failures still happen.
Sometimes the cause is obvious. A component breaks, a battery stops holding charge, or a sensor produces an incorrect measurement. Other failures are much harder to explain. Software behaves unexpectedly only under a particular combination of conditions.
An interface encourages a user to make the wrong selection. A manufacturing variation gradually changes product performance.
When something goes wrong, finding the immediate technical problem is only part of the job.
Manufacturers also need to ask a more difficult question: why was the problem able to reach the user in the first place?
The answer can reveal weaknesses in requirements, design, risk management, software development, manufacturing, supplier controls, usability, or post-market monitoring. This is why medical device failures should be treated not only as problems to correct, but also as opportunities to understand how the wider development system can improve.
Failure Can Begin Long Before the Device Is Manufactured
A device does not need to contain a defective component to have a design problem.
Sometimes the original requirements are incomplete.
Imagine a portable monitoring device intended for both hospitals and home use. Engineers design it around environmental conditions normally found in clinical settings.
Technically, the device performs exactly according to its specifications.
But patients begin using it in homes where temperature, humidity, connectivity, lighting, and handling conditions differ significantly from those considered during development.
If performance deteriorates, is that a manufacturing failure?
Not necessarily.
The deeper problem may be that the original requirements did not adequately represent the intended use environment. This demonstrates why failures need to be traced backwards.
A problem observed during use may originate months or even years earlier when user needs, operating conditions, or design requirements were established.
Hardware Components Can Fail in Different Ways
Medical devices can contain hundreds or thousands of individual components.
Batteries, connectors, sensors, cables, power supplies, displays, switches, pumps, valves, and mechanical assemblies all have potential failure modes.
Some failures are immediate.
A connector breaks and the device stops working. Others are gradual.
A sensor drifts over time and begins producing measurements that remain plausible but are increasingly inaccurate.
The second situation can be more difficult to detect.
A device that clearly stops working tells the user that something is wrong. A device that continues operating while providing incorrect information may create greater risk because users have no obvious reason to distrust it.
Manufacturers therefore need to consider more than whether components can fail.
They need to consider how they fail.
Will failure be obvious? Can the device detect it? Does another component provide redundancy? Could the user continue operating the device without recognising that performance has changed?
These questions influence both product architecture and risk controls.
Software Failures May Remain Hidden Until Specific Conditions Appear
Software creates a different type of challenge.
A mechanical component may wear progressively. Software does not wear in the same way. The same code can operate correctly thousands of times and then fail when it encounters an unusual combination of inputs.
Consider software that calculates a value using information from several sensors.
During verification, the expected input ranges are tested extensively. After release, however, an unusual sequence of events causes one sensor to temporarily produce an unexpected value.
The software receives an input that developers did not anticipate.
What happens next?
Perhaps the application displays an error and enters a safe state.
Or perhaps the value moves through several calculations and eventually produces an incorrect result that still appears believable to the user.
This is why medical device software requires more than ordinary functional testing. Development also needs structured requirements, architecture, verification, configuration management, maintenance, and problem-resolution processes.
The IEC 62304 software safety classification provides a lifecycle framework and helps determine the rigor of development activities according to the potential consequences of software failure.
The important principle is proportionality.
Software controlling or contributing to a potentially hazardous function deserves different attention from software performing a function that cannot contribute to injury.
Human Error May Actually Reveal a Design Problem
When an incident involves incorrect device use, describing it as “user error” can seem like an explanation.
Often, it is only the beginning of the investigation. Why did the user make the mistake?
Imagine two adjacent buttons that perform very different functions but look almost identical. A healthcare professional selects the wrong one during a busy clinical situation.
Technically, the user made the incorrect selection.
But if the same mistake occurs repeatedly among different users, the interface itself deserves attention.
Perhaps the buttons are too similar. Maybe the terminology is unclear. The system might provide insufficient confirmation before executing an important action.
The same applies to alarms.
A device might generate technically correct warnings, but if alarms occur so frequently that users routinely silence them, the system may contribute to unsafe behaviour.
Medical device usability therefore needs to consider how people actually interact with technology rather than assuming perfect attention and perfect behaviour.
Manufacturing Can Introduce Problems Into a Good Design
A product can be designed correctly and still fail because the manufacturing process does not reproduce that design consistently.
Consider an adhesive used to create a critical seal.
Engineering testing shows that the selected adhesive performs correctly when applied at the specified amount and cured under defined conditions.
During production, however, variation in application thickness or curing time changes the strength of the seal.
The design itself may be sound. The manufacturing process is introducing variability. This is why production controls are an important part of medical device quality.
Manufacturers need to understand which process parameters affect the finished product, how those parameters will be controlled, and whether inspection can reliably detect unacceptable results.
In some situations, final inspection alone cannot provide sufficient assurance. The process itself needs to be demonstrated to operate consistently.
Supplier Problems Can Become Device Problems
Medical device manufacturers rarely produce every component themselves.
They depend on external suppliers for electronics, plastics, batteries, sensors, software components, packaging, raw materials, and specialised manufacturing services.
This creates dependencies. Suppose a supplier changes a material used inside a component.
From the supplier’s perspective, the new material may be equivalent. But within the medical device, the change could affect durability, electrical characteristics, biocompatibility, sterilisation resistance, or another important property.
If the change is not communicated or assessed appropriately, the manufacturer may discover its significance only after failures occur.
Supplier management therefore needs to reflect the importance of the supplied product or service.
A supplier providing office stationery does not require the same level of oversight as one providing a component whose failure could affect patient safety.
Testing Cannot Reproduce Every Real-World Condition
Verification and validation are essential, but no practical testing programme can reproduce every situation a device will encounter.
Laboratory conditions are controlled. Real healthcare environments are not.
Devices may be dropped, transported, cleaned repeatedly, connected to different equipment, used by people with different levels of experience, exposed to electromagnetic interference, or operated near the limits of their environmental specifications.
Home-use devices introduce even greater variability.
Patients may store equipment incorrectly. Internet connectivity may disappear. Accessories can be misplaced. Instructions may be misunderstood. Children or other family members may interact with the device.
This does not mean manufacturers should attempt to test every imaginable scenario.
They need to identify reasonably foreseeable conditions and focus testing according to risk.
Even then, some problems will only become visible after the product reaches a much larger population.
One Complaint Rarely Tells the Whole Story
Imagine a manufacturer receives a complaint that a device unexpectedly restarted during use.
The returned unit is examined, but technicians cannot reproduce the problem.
Should the case be closed? Perhaps.
But now imagine three similar reports arrive during the following month. Then another five.
Individually, none provides enough information to establish the cause. Collectively, they may indicate an emerging pattern.
Perhaps every affected device contains the same component batch. Maybe all incidents occurred after a particular software update. They might involve a specific accessory or environmental condition.
This is why complaint handling should not focus only on resolving individual cases.
Manufacturers need mechanisms for identifying relationships between events.
Patterns often contain more useful information than isolated incidents.
Root Cause Is Usually More Valuable Than the Immediate Fix
When a failed component is found, replacing it solves the immediate problem.
But why did it fail?
If the answer is simply “the component was defective,” the investigation may stop too early.
Was the component operating outside its rated conditions? Did manufacturing damage it? Did the supplier change something? Was the component specification inadequate? Could incoming inspection have detected the problem?
The same logic applies to software.
Fixing a software defect is necessary, but manufacturers should also ask why verification did not identify it.
Was a requirement ambiguous? Was an edge case omitted? Was the software architecture unnecessarily vulnerable to that type of failure?
Understanding the underlying cause can prevent an entire category of problems.
Corrective Actions Can Create New Problems
A solution should also be evaluated for unintended consequences. Suppose a medical device generates too many unnecessary alarms.
Engineers reduce the sensitivity of the alarm algorithm. The number of false alarms decreases dramatically.
Problem solved?
Not until the team asks whether the new threshold could delay or prevent a legitimate alarm. Changes interact with the rest of the system.
A stronger mechanical component may increase weight. A new battery may change thermal behaviour. Additional authentication may make a device harder to use during an emergency. A software patch may affect another function that previously worked correctly.
Corrective action therefore needs its own risk assessment and verification.
Otherwise, manufacturers may simply exchange one failure mode for another.
Post-Market Information Should Change Future Development
The greatest value of investigating failures comes when lessons reach future products.
Suppose a company discovers that users repeatedly misunderstand a particular type of warning.
Fixing the wording in one device is useful.
But the organisation can go further.
The finding can influence interface requirements for future products. Usability teams can test similar warnings earlier. Risk-management procedures can account for the issue. Designers can avoid repeating the same pattern.
This turns an individual failure into organisational knowledge.
The same can happen with supplier problems, software defects, manufacturing deviations, component failures, and maintenance issues.
A mature development system does not merely correct failures.
It remembers them.
Failure Should Feed Back Into the Entire Lifecycle
Medical device failures rarely fit neatly into one category.
A software problem may originate from an unclear requirement. A manufacturing issue may reveal that the design is too sensitive to normal process variation. A user error may expose an interface weakness. A component failure may reveal insufficient supplier controls.
That is why investigating failures should extend beyond identifying the part that stopped working.
Manufacturers need to understand the chain of decisions and conditions that allowed the problem to occur.
A medical device reaching the market is not the end of its development story. Real-world performance continues to test the assumptions made during design, software development, manufacturing, and risk management.
When those assumptions prove wrong, the strongest response is not simply to repair the device.
