A cyber-attacker gains access to a care provider’s computer network through an e-mail phishing trap and assumes command of a file server to which a heart monitor is attached. While scanning the network for devices, the attacker takes control (e.g., power off, continuously reboot) of all heart monitors in the ICU, putting multiple patients at risk.

It defies logic why a hacker would want to intentionally harm patients, but this type of threat is definitely not science fiction. It is one example of the risks that connected devices pose to patient safety according to a recently published paper by the US Department of Health and Human Services (HHS), which oversees FDA.…

In our first post we talked about international risk management standards and guidance applicable to medical device software, including the ISO 14971 and IEC 62304 standards. In this post we will discuss specific compliance requirements in the US and Europe for medical device software paired with hardware, and stand-alone Software as a Medical Device (SaMD).…

Software itself is not risky. Nobody gets directly injured by bad code or a poorly designed UI and, unlike hardware, software does not fail randomly.

That being said, software can definitely expose someone to a hazardous situation because software is viewed to have 100% probability of failure when it does occur. Therefore, this makes software rightfully subject to risk management oversight, including special considerations for software-controlled medical devices.

In this post, we’ll cover the basics of risk management for embedded software or stand-alone Software as a Medical Device (SaMD), so you have an understanding of what is required before, during, and after coding.…