Software in a medical device (SiMD) is embedded software that is integral to a physical medical device and required for it to achieve its intended medical purpose. Unlike standalone software, SiMD cannot perform a medical function on its own. Firmware in an infusion pump and control software in an MRI scanner are typical examples.
What is software in a medical device (SiMD)?
SiMD is the code that runs on, controls, or drives a hardware medical device. It is often called embedded software, firmware, or microcode. The device depends on it: remove the software, and the hardware can no longer deliver its intended function. That dependence separates SiMD from Software as a Medical Device (SaMD), which meets a medical purpose on general-purpose computing hardware without being part of any device.
The same algorithm can land in either category depending on where it runs. An image-analysis routine hosted on a hospital server behaves as SaMD. Compile that routine into the firmware of an imaging system, and it becomes SiMD, regulated as part of that device.
Why software in a medical device matters in device development
A fault in SiMD propagates directly into hardware behavior. A dosing miscalculation, a timing error in a therapy sequence, or a corrupted sensor reading can change what the device does to a patient. Regulators treat these failures as device failures, not IT bugs.
The cost of getting it wrong is real. Software design errors have long ranked among the most common root causes in device recalls, and a defect found after launch can trigger field corrections, submission holds, and audit findings. Classification decisions made early shape the entire evidence burden, so a misjudged safety class is expensive to unwind later.
How software in a medical device is developed and controlled
SiMD is governed primarily by IEC 62304, the international standard for medical device software lifecycle processes. It applies whether the software is the device itself or embedded in it. The current edition is IEC 62304:2006 with Amendment 1 (2015); a second edition is anticipated around 2026 but is not yet published or harmonized. The standard sits alongside ISO 14971 for risk management and ISO 13485 for the quality system.
IEC 62304 scales rigor to a safety class assigned from worst-case harm:
- Class A: No injury is possible if the software fails.
- Class B: non-serious injury is possible.
- Class C: death or serious injury is possible.
Higher classes demand more documentation, design detail, and verification. Core lifecycle activities include development planning, requirements analysis, architectural and detailed design, implementation, verification, integration and system testing, and release, followed by a maintenance process and problem resolution once the device is in the field.
Two concepts recur throughout. SOUP (software of unknown provenance), meaning any component not developed for the device, such as an operating system or open-source library, must be identified and risk-assessed. Cybersecurity is now expected alongside safety evidence, with IEC 81001-5-1 providing the security lifecycle and the FDA requiring premarket cybersecurity information under Section 524B of the FD&C Act.
SiMD, SaMD, and how classification differs
Because SiMD is part of a hardware device, it usually inherits that device’s regulatory classification rather than triggering a separate one. Standalone software (SaMD) is classified on its own, in the EU through Rule 11 of MDR Annex VIII and in the US through its own submission path.
Teams still make avoidable mistakes. A frequent one is treating firmware as “just engineering” and skipping formal software classification, then discovering during an audit that Class C activities were never performed. Another is weak traceability, where requirements, risk controls, design, and tests are not linked, so a single change forces a full re-analysis. Good practice keeps that trace intact, versions every change under configuration management, and revisits the risk file whenever code changes. Under the FDA Quality Management System Regulation, effective February 2, 2026, these expectations tie directly into an ISO 13485-based quality system.
How SJML helps with software in a medical device
SJML develops SiMD as part of its electromechanical device engineering, covering embedded systems and software alongside electronics, mechanical, and systems work. Software is built to the IEC 62304 lifecycle, with risk management under ISO 14971 and usability under IEC 62366 integrated into the design flow rather than bolted on afterward. In-house labs support electrical safety, EMC, and reliability testing. The QARA team adds IEC 62304 documentation, software safety classification, and IEC 81001-5-1 cybersecurity risk assessment for regulatory submissions.
Talk to SJML’s engineering team →
Frequently asked questions
SiMD is embedded in a hardware medical device and cannot perform its function without that hardware. SaMD performs a medical purpose on general-purpose computing platforms without being part of any device. The same algorithm can be either, depending on where it runs. Both are regulated as medical devices, and both follow IEC 62304 for their software lifecycle.
Yes. Software in a medical device is regulated as part of the device it belongs to. It must meet the same quality, risk, and lifecycle requirements as the hardware, including FDA QMSR or EU MDR obligations and IEC 62304 processes. Its safety documentation is reviewed as part of the parent device’s regulatory submission.
IEC 62304 is the primary lifecycle standard for SiMD and SaMD alike. It works with ISO 14971 for risk management, ISO 13485 for the quality system, IEC 62366-1 for usability, and IEC 81001-5-1 for cybersecurity. The current edition is IEC 62304:2006 plus Amendment 1 (2015).
IEC 62304 assigns each software item to Class A, B, or C based on the worst-case harm a failure could cause, from no injury (A) to serious injury or death ©. The class sets how much documentation, design detail, and verification are required. Teams default to the higher class when the justification is unclear.
Related terms
- Software as a Medical Device (SaMD)
- IEC 62304
- Software of Unknown Provenance (SOUP)
- Medical Device Cybersecurity
- Software Verification and Validation
