The global Software as a Medical Device (SaMD) market was valued at $3.83 billion in 2025 and is projected to reach $5.3 billion in 2026. The AI-enabled medical device market — a subset of that — stood at $18.9 billion in 2025 and is expected to reach $26.2 billion in 2026. By early 2026, the FDA had authorized over 1,350 AI-enabled devices — roughly double the number cleared in 2022.
The growth is real, but the engineering requirements are specific. Medical device software operates in one of the most regulated environments in software engineering. Regulatory failures cost teams years and tens of millions of dollars. Understanding what is actually required — and what common patterns produce compliant, shippable software — is the prerequisite to building in this space.
The Two Software Categories: SaMD vs. Software in a Medical Device
The regulatory treatment of software depends on where it sits in relation to the device.
Software as a Medical Device (SaMD): software that performs a medical purpose on its own, without being part of a hardware medical device. A diagnostic AI that analyses radiology images and surfaces findings — that is SaMD. A clinical decision support tool that recommends treatment options based on patient data — SaMD. The FDA regulates SaMD as a medical device in its own right.
Software in a Medical Device (SiMD): software embedded in or used to operate hardware medical devices — the firmware running an infusion pump, the control software in an MRI scanner, the software in an implantable defibrillator. SiMD is regulated as part of the device it controls.
The engineering and compliance requirements differ significantly. SaMD teams must address SaMD-specific regulatory pathway questions first; SiMD teams work within the hardware device’s regulatory submission. This guide focuses primarily on SaMD, which is where most software-first teams building in medtech operate.
The Regulatory Framework in 2026
QMSR: The 2026 Baseline for U.S. Quality Management
Effective February 2, 2026, the FDA’s Quality Management System Regulation (QMSR) replaced the legacy Quality System Regulation (QSR) under 21 CFR Part 820, which had governed U.S. medical device manufacturing since 1996. The QMSR incorporates ISO 13485:2016 — the international quality management standard for medical devices — by reference into U.S. regulation.
What this means practically: if your team has already implemented ISO 13485:2016, your QMS is now substantially aligned with U.S. regulatory requirements. ISO 13485 is no longer optional for companies selling into the U.S. market. Teams that previously maintained separate U.S. and EU quality systems now have a unified framework.
Key QMSR requirements that software teams must address: design and development controls (planning, inputs, outputs, review, verification, validation, transfer, and change control); risk management integration throughout the software lifecycle; complaint handling and post-market surveillance; and document and record control that produces a defensible audit trail.
IEC 62304: The Software Lifecycle Standard
IEC 62304 — Medical Device Software — Software Life Cycle Processes — is the international standard defining how medical device software must be developed, maintained, and retired. The FDA recognises it as a consensus standard; compliance with IEC 62304 satisfies the FDA’s software development process expectations, and most regulatory submissions reference IEC 62304 alignment explicitly.
The standard requires software to be classified into one of three safety classes based on the potential harm if the software fails:
| Safety Class | Failure Consequence | Required Activities |
|---|---|---|
| Class A | No injury or damage to health | Basic planning, requirements, architecture |
| Class B | Non-serious injury possible | Full lifecycle documentation + testing |
| Class C | Death or serious injury possible | All Class B requirements + full unit, integration, and system testing |
Software safety class determines the required rigour of documentation, testing, and risk management activities. Most clinical AI and diagnostics software is Class C. Clinical decision support that cannot harm patients without physician override may be Class B.
IEC 62304 Edition 2 is currently in development, with publication targeted for mid-to-late 2026. Teams starting new development programmes should follow Edition 1.1 amendment and monitor for Edition 2 requirements.
ISO 14971: Risk Management
ISO 14971 — Medical Devices — Application of Risk Management — is the risk management standard that governs how manufacturers identify, analyse, evaluate, control, and monitor risks associated with medical devices and their software. Under QMSR, ISO 14971 risk management must be integrated throughout the software development lifecycle, not treated as a documentation exercise at the end of development.
For software, ISO 14971 risk management produces the Software Risk Analysis (a decomposition of software hazards and their contributing causes) and the residual risk evaluation that feeds the overall device risk/benefit determination.
FDA Cybersecurity Requirements (2025/2026)
The FDA’s cybersecurity guidance for medical devices, finalized in June 2025 and reissued in February 2026 to align with the QMSR, codifies security-by-design requirements that now apply to all medical device software submissions:
Software Bill of Materials (SBOM): manufacturers must maintain a complete inventory of all software components, including open-source libraries, with version information. The SBOM must be kept current and provided to FDA on request. This requires dependency tracking infrastructure — most teams implement this via CycloneDX or SPDX SBOM generation integrated into the build pipeline.
Coordinated Vulnerability Disclosure (CVD): a published policy and process for receiving, evaluating, and addressing security vulnerability reports from external researchers.
Post-market cybersecurity monitoring: active monitoring of third-party vulnerability databases (NVD, CVE feeds) for vulnerabilities affecting components in the SBOM, with defined timelines for remediation and disclosure.
Secure software development practices: threat modelling integrated into design, static analysis tooling in the CI pipeline, penetration testing before submission.
The Medical Device Software Architecture
System Architecture Patterns
Medical device software typically follows a layered architecture that separates the core medical function from the user-facing application and the connectivity layer:
Device firmware layer (for SiMD): real-time control software running on embedded hardware. Safety-critical functions (pump control, stimulation delivery, valve actuation) run in a real-time operating system (RTOS) — FreeRTOS, Zephyr, VxWorks — with deterministic timing requirements and formal verification of critical state machines.
Medical engine layer: the core computational function — algorithm, model, or decision logic that produces the medical purpose. For AI medical devices, this is the inference engine and model. For diagnostic devices, this is the measurement and classification logic. This layer must be rigorously validated: sensitivity/specificity on representative patient populations, performance across demographic subgroups, failure mode characterisation.
Integration layer: connects the medical engine to clinical systems — DICOM for imaging integration, HL7 FHIR for EHR data exchange, PACS integration, API endpoints for cloud-connected devices. Integration is where most post-market security vulnerabilities originate; input validation and authentication controls here are non-negotiable.
Application layer: the clinician-facing user interface. For clinical workflows, UI errors are patient safety issues — mislabelled values, unintuitive controls, poorly designed alert hierarchies. IEC 62366 (Usability Engineering) requires a systematic process for analysing use errors and designing the user interface to minimise the risk of use error.
Data and Storage Requirements
Medical device software handling Protected Health Information (PHI) must comply with HIPAA in the U.S. and equivalent regulations in other markets. Storage requirements:
- Encryption at rest: AES-256 (now explicitly required by HIPAA’s 2025 update)
- Encryption in transit: TLS 1.2 minimum, TLS 1.3 preferred
- Access control: role-based access with audit logging of all PHI access events
- Audit trails: tamper-evident logs with timestamps for all clinically significant events
- Data retention: medical records retention periods vary by jurisdiction — 7–10 years typical
AI and Machine Learning Considerations
For AI-enabled devices, the FDA’s AI/ML SaMD action plan introduces specific requirements beyond standard 510(k) or De Novo clearance:
Predetermined Change Control Plan (PCCP): AI models that are designed to update after market release require a PCCP that defines the scope of allowable algorithm changes, the performance monitoring methodology, and the boundaries beyond which a new submission is required. This is the mechanism that allows continuously learning models — adaptive AI that improves on new patient data — to operate without triggering a new 510(k) for every model update.
Algorithm change protocol: even for non-learning models, any post-market algorithm change that affects the device’s intended use or performance requires either a PCCP-covered change or a new submission. Model retraining on new data, threshold adjustments affecting sensitivity/specificity, and architecture changes all require evaluation.
Transparency and explainability: the FDA increasingly expects AI medical devices to provide clinicians with information about model confidence and the basis for predictions — particularly for clinical decision support. Models that produce binary outputs without confidence information face higher scrutiny.
The Software Development Lifecycle for Medical Devices
V-Model and Design Controls
The FDA’s design controls framework — now incorporated into QMSR — maps directly to a V-model software development lifecycle:
User Needs
→ Design Inputs (requirements)
→ Design Outputs (architecture, design specifications)
→ Implementation
→ Verification (does implementation meet design outputs?)
→ Validation (does the system meet user needs?)
→ Design Transfer (production-ready device)Each phase produces documented artefacts. The software development plan defines the activities, responsibilities, deliverables, and timeline. Design history file (DHF) — or Design and Development File under QMSR — accumulates all design control records.
Traceability
Full traceability between requirements, design, implementation, and test is mandatory. A requirement that cannot be traced to a test that verifies it is an audit finding. Most teams implement this in a requirements management tool (Jama Connect, Polarion, Jira with traceability plugins) that maintains bidirectional links from user need → system requirement → software requirement → design specification → test case → test result.
Version Control and Configuration Management
Medical device software version control requirements go beyond standard software practices. Configuration management must identify: the software version, all components and their versions (the SBOM), the build environment version, and the test environment version. Builds must be reproducible — given the same source version and build environment, the same binary must be produced. This typically requires containerised build environments and pinned dependency versions.
Git is the standard VCS; FDA and IEC 62304 are compatible with Git-based workflows. Teams must define branching strategy, change control process, and ensure that the version in the DHF matches the version submitted to FDA.
For the regulatory pathway for AI medical devices — including 510(k), De Novo, and PMA submissions — see our medical imaging AI guide and digital medicine overview.
How we approach this at Insoftex
The IEC 62304 lifecycle structure and design controls discipline described in this article define the development process we apply when building Software as a Medical Device. The most consistent finding from healthcare software engagements: teams that attempt to reconstruct a Design History File retroactively — documenting requirements, design decisions, and test rationale after the system is built — produce documentation that reads as fabricated, because it is. OCR and Notified Bodies are experienced at identifying DHFs where the documentation was written to match the code rather than the reverse. We build DHF documentation as a contemporaneous artefact of the development process, not as a post-build compliance activity.
The HIPAA and FHIR architecture work from our healthcare platform engagement shares the compliance-first posture that medical device software requires. The design principle is the same in both contexts: compliance constraints are architectural inputs that determine what you can build, not a review that happens after the architecture is designed. For medical device software, this means ISO 26262 functional safety requirements (for safety-classified software), IEC 62304 Class B or C requirements, and FDA cybersecurity guidance are all assessed in the Product Pilot before the architecture is finalised — because these requirements can eliminate model architectures, change the development process, and significantly extend the timeline.
The traceability requirement — bidirectional links from user need to system requirement to software requirement to design specification to test case to test result — is the documentation discipline that most consistently separates compliant medical device software builds from non-compliant ones. We implement traceability as a first-class engineering artefact in the development workflow, using requirements management tooling that maintains those links through every change, rather than as a document that is updated periodically. The difference in an audit: a requirements management system where any change to a requirement immediately flags the affected test cases is a living compliance artefact; a spreadsheet that is updated monthly is a compliance liability.
Building medical device software — SaMD, embedded firmware, clinical AI, or connected device platforms? Our Product Pilot covers architecture design, IEC 62304 lifecycle planning, FDA submission strategy, and security architecture in three weeks.
Frequently Asked Questions
What is the difference between IEC 62304 and FDA 21 CFR Part 820 / QMSR?
IEC 62304 and QMSR address different aspects of medical device software compliance. IEC 62304 defines the software development lifecycle processes — planning, requirements, architecture, implementation, verification, release, and maintenance — and the documentation required at each stage. It is an international standard recognized by FDA, EU (MDR), Health Canada, and most other markets. QMSR (which replaced 21 CFR Part 820 in February 2026) is the FDA's quality management system regulation — it governs the broader quality management system that the software development process operates within, including design controls, purchasing controls, complaint handling, corrective and preventive action (CAPA), and post-market surveillance. For medical device software teams, both apply. IEC 62304 compliance addresses the 'how you build software' question; QMSR compliance addresses the 'how you manage quality across the organisation' question. QMSR now incorporates ISO 13485:2016 by reference, making ISO 13485 effectively mandatory for U.S. market access — and aligning the U.S. framework with EU and international requirements.
What is a Software Bill of Materials (SBOM) and why does FDA require it?
A Software Bill of Materials (SBOM) is a complete, machine-readable inventory of all software components in a medical device — including first-party code, third-party libraries, open-source packages, and their dependencies — with version information for each component. The FDA began requiring SBOMs for medical device submissions as part of its cybersecurity guidance framework, finalized in 2023 and updated in 2025-2026. The security rationale: medical devices have long lifecycles — 10+ years — and are deployed in environments that are difficult to patch quickly. When a vulnerability is discovered in a library (like the Log4Shell vulnerability in Log4j), manufacturers must know immediately which of their devices contain that component. Without an SBOM, identifying affected devices requires manual code archaeology. With a current SBOM, a vulnerability search takes minutes. SBOM formats: CycloneDX and SPDX are the two dominant machine-readable formats. CycloneDX has broader tooling support in the medical device industry. SBOMs should be generated automatically at build time and stored in the Design History File alongside the software version they describe.
How does FDA regulate AI/ML medical devices that update after market release?
Traditional medical device regulatory clearances assume a fixed device — the device submitted to FDA is the device sold to hospitals. AI/ML devices complicate this: a model that continues learning from new patient data is, in a meaningful sense, a different device after each update. FDA's solution is the Predetermined Change Control Plan (PCCP), introduced in draft guidance in 2019 and finalised in 2023. A PCCP is submitted as part of the original 510(k) or De Novo submission and defines: (1) the description of planned modifications — what kinds of algorithm changes are covered (retraining on new data, threshold adjustment, architecture changes within defined bounds); (2) the methodology for implementing changes — the training, testing, and validation process that will be followed; and (3) the performance monitoring plan — how the manufacturer will detect when model performance deviates from the cleared specifications. Changes within the scope of an approved PCCP do not require a new 510(k) submission — the manufacturer implements the change, validates it per the PCCP methodology, and documents it. Changes outside PCCP scope require a new submission. The PCCP framework enables continuously improving AI medical devices to reach market and continue learning without regulatory bottleneck — but it requires careful upfront design of the model update architecture and monitoring infrastructure.
What are the IEC 62304 software safety classes and how is classification determined?
IEC 62304 requires every medical device software item to be classified into one of three safety classes based on the potential harm if the software fails. Class A: software failure cannot injure the patient or operator — administrative software, data storage systems, reporting tools that a clinician double-checks before acting on. Class B: software failure can cause non-serious injury — monitoring software where an alert failure might delay non-critical intervention, clinical decision support that a physician evaluates before acting. Class C: software failure can cause death or serious injury — any software directly controlling a device that delivers therapy, any diagnostic AI where the output directly influences a time-critical clinical decision without physician override opportunity, any software whose failure could result in dangerous misdiagnosis. The classification drives the required development activities: Class A requires basic lifecycle documentation; Class B requires full lifecycle documentation plus unit and integration testing; Class C requires all Class B activities plus complete unit testing (including statement and branch coverage), integration testing, and system testing. Most clinical AI software is Class C because misdiagnosis can be life-threatening. Teams often attempt to mitigate to Class B by designing in explicit clinician override and human-in-the-loop workflow requirements — but FDA reviewers scrutinize this classification carefully.