Most conversations about medical software focus on the software itself. But a large share of the code in the medical device industry never ships as a product. It ships inside something: the firmware controlling an infusion pump, the embedded software in a continuous glucose monitor transmitter, the code running an optical reader. That category has a name, and it carries its own set of engineering and regulatory expectations.
This guide explains what software in a medical device is, how it is classified and regulated, and what makes developing it meaningfully different from building standalone software.
Note: This guide provides general educational information, not legal or regulatory advice. Requirements and classification vary by device, intended use, market, and regulator. Confirm the applicable requirements for your product and target markets.
What Is Software in a Medical Device?
Software in a medical device, often abbreviated as SiMD, is software that runs on a hardware medical device and controls, operates, or supports it. It does not achieve a medical purpose on its own. It exists to make the hardware do what it’s for.
The everyday examples sit throughout the industry. The firmware that governs dose delivery in an infusion pump is SiMD. So is the embedded software in a CGM transmitter that samples the sensor, applies the conversion, and transmits a reading. So is the control software in a benchtop analyzer, a patient monitor, or an optical reader in a point-of-care diagnostic platform.
This is the counterpart to Software as a Medical Device (SaMD), which performs its medical function independently of any particular hardware. The two are frequently confused, and the distinction is important enough that the SaMD guide covers it in detail, including a full comparison with general health software. The short version: SaMD is the product; SiMD is part of a product.
How SiMD Is Classified and Regulated
The most practical thing to understand about SiMD is that it is not classified as a separate category. SaMD can be a medical device in its own right, with its own classification and its own submission. SiMD is not. It inherits the classification of the device it is part of and is evaluated as part of that device’s regulatory submission.
There is no separate SiMD pathway to pursue, nor is there a standalone SiMD clearance to obtain. If the host device is in a higher-risk class, the software on it is developed and documented to meet the expectations associated with that class. If the device is lower risk, the same applies proportionately. The software does not get its own regulatory identity.
Teams get this wrong in both directions. Some assume their embedded software needs its own submission and plan work that is not required. Others assume that because the software is not the product, it attracts less scrutiny, which is not the case. The software is part of the device, so it is included in the review.
IEC 62304 applies either way
The software lifecycle expectations do not change based on whether software is SaMD or SiMD. IEC 62304 applies to medical device software generally, with the same software safety classification, the same lifecycle processes, and the same obligations around third-party components. Risk activities connect to ISO 14971 in the same way. A team building embedded device software is held to the same lifecycle discipline as a team building a standalone diagnostic application.
What Makes SiMD Development Different in Practice
The regulatory framework is shared. The engineering reality is not. Six differences shape how SiMD is actually built, and they are where most of the difficulty lives.
1. The software cannot be developed in isolation from the hardware
SiMD is developed alongside the device it runs on, often while that hardware is still changing. Requirements shift as the mechanical and electrical design evolves, and software decisions can constrain hardware choices, and vice versa. This co-development reality means the software plan must account for hardware milestones, prototype availability, and design changes that arise mid-sprint. A software team that plans as though the hardware is fixed will replan repeatedly.
2. Resources are constrained in ways cloud software never is
Embedded targets bring hard limits: memory, processing, power budget, and thermal headroom. A battery-powered wearable or an implantable-adjacent device may need to run for weeks or years on a small cell, which shapes everything from algorithm choice to how often the device wakes. Design decisions that are trivial in a cloud service — adding a library, logging more data, running a heavier computation — can be genuinely unavailable here.
3. Timing and real-time behavior can be safety-relevant
In many devices, the software must do something within a bounded time, not merely eventually. A delayed response in a delivery or monitoring function is not a performance annoyance; it can be a hazard. That makes timing behavior part of the risk analysis and part of what verification must demonstrate, which is a different kind of testing than functional correctness alone.
4. Verification has to happen against real hardware
Simulators and test harnesses are valuable and necessary, but they cannot fully stand in for the device. Sensor noise, electrical behavior, timing under load, temperature effects, and battery degradation all manifest in physical hardware and rarely in simulation alone. Verification planning for SiMD has to account for hardware availability, test fixtures, and the fact that some evidence can only be produced on the real thing.
5. Updates are a deployment problem, not just a release problem
Both SaMD and SiMD require changes to be evaluated for their effect on safety and performance, so the regulatory obligation is comparable. What differs is how an update reaches the field. Standalone software can often be pushed over the air. Embedded software may require a connected update path that has to be designed and secured in advance, a service visit, or in the worst case a field action. This is why update strategy belongs in the architecture conversation at the start rather than after the first defect.
6. Third-party components carry the same obligations, with less room to maneuver
Real-time operating systems, communication stacks, cryptographic libraries, and vendor board support packages are all software of unknown provenance under IEC 62304. They require identification, specification of what they must do and what they need to run, evaluation of known anomalies, and ongoing monitoring. On embedded targets, the practical difficulty is sharper, because swapping a component late can mean revalidating against hardware, and some vendor-supplied code offers limited visibility.
Where SiMD Sits in a Connected Product
Very few modern devices consist solely of embedded software. A connected medical device typically spans SiMD on the device, a mobile or companion application, a cloud backend, and often an integration into clinical systems. The embedded layer is where measurement and control occur, and everything downstream depends on the integrity of its output.
That makes the boundaries between layers a design concern in their own right: what the device computes versus what the cloud computes, what it stores locally when connectivity drops, how it authenticates, and how a reading is kept traceable from sensor to clinician. Our guides to medical device connectivity and EHR interoperability cover the layers above the device.
SiMD Readiness Checklist
Use this as a planning and readiness review for embedded medical device software. Depth and evidence depend on the device, its classification, and the applicable regulatory expectations.
# | Checklist item | What supporting evidence typically looks like |
1 | Host device classification confirmed and software scope defined | Documented device classification and a clear statement of which software functions sit inside it |
2 | Software safety classification assigned | Classification rationale consistent with the device’s risk and the software’s contribution to hazards |
3 | Software development plan aligned to hardware milestones | Plan covering co-development, prototype availability, and handling of hardware design changes |
4 | Requirements capture timing and resource constraints | Requirements specifying timing behavior, memory, power, and performance bounds where safety relevant |
5 | Architecture documented, including hardware interfaces | Design records covering the software architecture and its interfaces to hardware and external systems |
6 | Risk analysis addresses embedded-specific failure modes | Hazard analysis covering timing failures, resource exhaustion, sensor faults, power loss, and communication loss |
7 | Risk controls implemented in software and traced | Requirements and design outputs implementing each control, traceable to the risk file |
8 | Third-party components identified and evaluated | SOUP inventory covering RTOS, stacks, libraries, and vendor code, with anomaly evaluation and monitoring |
9 | Verification planned against physical hardware | Verification strategy defining what is tested in simulation and what requires target hardware, with fixtures identified |
10 | Update and field-service strategy defined | Documented approach to secure updates, including how changes reach deployed devices |
11 | Cybersecurity addressed at the device layer | Threat modeling, secure boot and update integrity where applicable, and interface hardening |
12 | Configuration and version control established | Controlled versioning of software, toolchain, and build environment, with reproducible builds |
13 | Traceability maintained across the lifecycle | Links from requirement to risk control to test to released software version |
14 | Software records integrated into the device file | Software evidence compiled so it supports the device’s technical documentation and design history file |
Frequently Asked Questions
What is software in a medical device (SiMD)?
Software in a medical device is software that runs inside a hardware medical device and controls, operates, or supports it. It does not achieve a medical purpose on its own. Examples include infusion pump firmware, the embedded software in a CGM transmitter, and the control software in a patient monitor or analyzer.
Is SiMD regulated separately from the device?
No. SiMD is not classified in and of itself. It inherits the classification of the device it lives in and is evaluated as part of that device’s submission. There is no separate SiMD pathway or standalone clearance, though the software is still reviewed as part of the device.
Does IEC 62304 apply to SiMD?
Yes. IEC 62304 applies to medical device software whether it runs independently as SaMD or is embedded as SiMD. The same software safety classification, lifecycle processes, and obligations around software of unknown provenance apply.
Is firmware considered SiMD?
Generally yes. Firmware that controls or supports a medical device is software within the device and falls under the same lifecycle and documentation expectations. The term firmware describes how the software is deployed; it does not change its regulatory treatment.
What is the difference between SaMD and SiMD?
SaMD performs its medical function independently and can be a medical device in its own right. SiMD runs inside a hardware device and exists to make that device work, inheriting the device’s classification. Our Software as a Medical Device guide provides a comprehensive comparison, including how both differ from general health software.
Building Software Inside a Medical Device
Embedded device software carries the same lifecycle expectations as standalone medical software, with engineering constraints that standalone software never faces. The teams that handle it well plan for hardware co-development from the start, treat timing and resources as requirements rather than implementation details, and design the update path before they need it.
Sequenex builds medical device software under an ISO 13485-certified quality management system, across the embedded, mobile, and cloud layers of connected devices. To discuss your device, explore our medical device software development services or get in touch with us.
