Introduction
An embedded team that has built IEC 62304-compliant firmware for years can still be caught off guard the first time a project turns out to be Software as a Medical Device rather than software inside one. Software as a Medical Device (SaMD) development is a distinct regulatory category with its own classification logic and lifecycle expectations, and the distinction isn't academic: it changes what evidence a submission needs, how updates get managed post-market, and in some cases whether a familiar embedded compliance playbook applies at all.
In short: the question that actually matters is whether the software itself performs a medical function independent of any specific hardware, that's SaMD, or whether it controls or is embedded within a hardware medical device, that's conventional embedded medical device software, and getting this classification right early avoids building toward the wrong regulatory framework.
What Qualifies as SaMD vs. Embedded Medical Device Software
The IMDRF (International Medical Device Regulators Forum) defines SaMD as software intended for one or more medical purposes that performs those purposes without being part of a hardware medical device. A mobile app that analyzes a photo to assess a skin lesion's risk, or a standalone algorithm that interprets ECG data uploaded from any compatible device, is SaMD, its medical function exists independent of specific hardware. Firmware that runs inside a patient monitor, controlling its sensors and generating its display, is conventional embedded medical device software regulated as part of that hardware device, not SaMD. The distinction gets genuinely ambiguous at the edges: a mobile app that only works with one specific companion hardware sensor sits closer to the embedded category than a platform-agnostic diagnostic algorithm does, and that ambiguity is exactly where teams need to seek explicit regulatory guidance rather than assume.
FDA and IMDRF Risk-Based SaMD Classification
IMDRF's SaMD risk categorization, adopted in substance by the FDA and other regulators, classifies based on two factors: the significance of the information the software provides to a healthcare decision (informing clinical management, driving clinical management, or treating/diagnosing) and the seriousness of the healthcare situation or condition (non-serious, serious, or critical). A SaMD product that directly diagnoses a critical condition sits at the highest risk category and faces correspondingly rigorous evidence requirements; one that merely informs a clinician's decision about a non-serious condition sits considerably lower. This classification, not the technology stack or algorithm sophistication, is what actually determines the regulatory rigor a SaMD product needs to demonstrate.
Lifecycle and Change-Management Implications Specific to SaMD
SaMD's lifecycle and change-management expectations diverge from embedded firmware's in a specific way: because SaMD frequently updates independent of any hardware release cycle, sometimes far more frequently than a typical embedded firmware update cadence, regulators have developed frameworks specifically for managing this, most notably the FDA's evolving Predetermined Change Control Plan (PCCP) approach for AI/ML-enabled SaMD, which allows a pre-specified, pre-authorized scope of future model or software changes without requiring a new submission for each one. Building a SaMD product without early attention to how post-market changes will be managed and regulatorily justified is a common gap that surfaces expensively once the product is in the field and a genuinely necessary update is stuck behind an unplanned resubmission.
How This Differs From IEC 62304 Compliance for Embedded Firmware
IEC 62304 still applies to SaMD's software development lifecycle, the standard doesn't exempt SaMD, but SaMD's classification and evidence requirements layer additional, SaMD-specific expectations on top of the IEC 62304 baseline that a conventional embedded firmware project wouldn't otherwise face. SaMD classification and lifecycle for embedded teams coming from a hardware-embedded background means recognizing that IEC 62304 compliance alone doesn't satisfy SaMD's additional evidence and risk-categorization requirements, the software lifecycle process is necessary but not sufficient on its own.
Where SaMD Questions Come Up Most Often
SaMD classification questions surface most frequently in a recognizable set of product categories: mobile health apps that interpret patient-generated data (symptom trackers that escalate to a diagnostic claim, image-analysis apps for dermatology or wound assessment), standalone diagnostic algorithms that process data from third-party or multiple compatible devices rather than one specific companion hardware, and increasingly, AI/ML-based clinical decision support tools where the software's adaptive behavior itself raises classification and change-management questions regulators are still actively refining guidance for. Teams building in any of these categories should assume the SaMD question needs an explicit answer early, not an assumption carried over from prior embedded-hardware medical device experience.
Digital Health Embedded: Where Embedded Systems Still Matter for SaMD
Digital health embedded systems intersect with SaMD constantly even when the SaMD classification question points toward the software category: the sensor hardware generating the data a SaMD algorithm analyzes, the connectivity stack delivering that data reliably, and the embedded firmware ensuring data integrity before it ever reaches the SaMD software all remain critical to the overall product's safety and performance, even though they may be regulated as a separate, conventional embedded medical device rather than as SaMD themselves. Embedded systems for digital health monitoring and the SaMD software that analyzes their output are often best designed by a team that understands both regulatory categories together, since a data quality issue at the embedded sensor layer can undermine a SaMD algorithm's clinical validity regardless of how rigorously the software itself was developed.
FDA Compliance Embedded in the Development Process, Not Bolted On
Building FDA compliance embedded into the development process from day one, rather than treated as a submission-time activity, matters especially for SaMD given how much of its evidence burden (clinical validation data, algorithm change-management planning, cybersecurity documentation for connected products) needs to be generated throughout development, not assembled retroactively. A team that waits until a SaMD product is functionally complete to start building this evidence typically discovers gaps that require rework the earlier-integrated approach would have avoided.
Practical First Steps for a Team Building a SaMD Product
Teams new to SaMD should start with an explicit classification exercise, using IMDRF's risk categorization framework, before committing to a development plan, ideally validated against regulatory guidance or a pre-submission conversation with the relevant authority for anything ambiguous. From there, plan the IEC 62304 software lifecycle process, the ISO 14971 risk management approach, and, for AI/ML-enabled products specifically, a change-management strategy addressing how the software will be updated post-market, as three coordinated workstreams from the start rather than sequential, disconnected efforts.
Embien's Capabilities
Embien supports both conventional embedded medical device software and SaMD-classified products, building IEC 62304-aligned software lifecycles, ISO 14971 risk management, and the sensor-to-software data integrity work that connects embedded digital health hardware to SaMD algorithms. Our teams help clients work through SaMD classification questions early, before development commits to the wrong regulatory framework.
To discuss classification or lifecycle planning for a Software as a Medical Device (SaMD) development program or a digital health product, reach out to Embien's engineering team.