Medical Device Software Development: SaMD, IEC 62304 & FDA

Medical device software development is the engineering discipline of building clinical algorithms, mobile applications, cloud backends, and embedded firmware under a regulated Quality Management System (QMS) where every requirement, architectural boundary, third-party package, and automated test traces directly to a patient safety risk analysis. What turns ordinary health software into a regulated medical device is never the programming language or cloud host; it is the product's intended use and the clinical claims made in its user interface and marketing materials.

An iOS app that logs daily blood glucose numbers entered manually by a patient so they can show a PDF table to their endocrinologist is typically not a regulated medical device. If that exact same codebase adds a function that calculates a patient-specific rapid-acting insulin bolus dose or predicts nocturnal hypoglycemia from a continuous glucose monitor (CGM) stream, it becomes Software as a Medical Device (SaMD) subject to FDA premarket clearance, IEC 62304 lifecycle controls, and ISO 14971 risk management. Understanding where your product sits on that regulatory boundary before writing code is the single highest-leverage decision in digital health engineering.

The short version

• Intended use defines device status: software that diagnoses, treats, prevents, or mitigates disease (or drives clinical management using patient signals) is a regulated medical device, divided into standalone SaMD and hardware-embedded SiMD.
• IEC 62304 sets engineering rigor by safety class: software modules are classified as Class A (no injury possible), Class B (non-serious injury possible), or Class C (death or serious injury possible), dictating unit verification, architectural segregation, and SOUP tracking.
• FDA 2023 Premarket Guidance uses two documentation tiers: the FDA replaced its legacy Minor/Moderate/Major Levels of Concern with Basic Documentation and Enhanced Documentation, requiring full unit-level design and test deliverables for Enhanced submissions.
• EU MDR Rule 11 eliminated the Class I loophole: under Regulation (EU) 2017/745 Annex VIII Rule 11, nearly all diagnostic, triage, and physiological monitoring software moved from self-certified Class I to Class IIa, IIb, or III, requiring a Notified Body audit.
• Traceability can be automated in Git and CI: under ISO 13485 and ISO 14971, every User Need and Hazard Control traces forward to Software Requirements, Architecture, Code, and CI Test Evidence, compiled into the Design History File (DHF).
• Cybersecurity and AI lifecycle plans are now statutory: FDA Section 524B mandates machine-readable SBOMs, threat models, and OTA patching for connected devices, while Predetermined Change Control Plans (PCCPs) let AI/ML models retrain safely post-market without triggering a new 510(k) on every update.

SaMD vs SiMD and the FDA Cures Act non-device CDS boundary

Before setting up an ISO 13485 quality system or hiring regulatory counsel, an engineering and product team must classify the software's functional boundary across three distinct regulatory buckets:

1. Software as a Medical Device (SaMD): Defined by the International Medical Device Regulators Forum (IMDRF) as software intended to be used for one or more medical purposes that performs these purposes without being part of a hardware medical device. SaMD runs on general-purpose computing platforms: smartphones, clinician workstations, or cloud servers. Examples include an AI dermatology app that scores melanoma risk from smartphone photos, an ECG arrhythmia detection algorithm, a radiation therapy treatment planning suite, or a prescription digital therapeutic (PDT) cleared to treat substance use disorder or insomnia.
2. Software in a Medical Device (SiMD): Embedded firmware, real-time operating system (RTOS) code, or FPGA logic that controls or forms an integral part of a physical medical device. Examples include closed-loop insulin pump firmware, pacemaker pulse-generator code, ventilator pressure-control loops, and bedside vital-sign monitor firmware. SiMD is never cleared standalone; it is evaluated as part of the complete hardware-software system under IEC 60601-1 and IEC 62304.
3. Non-Device Health Software and Clinical Decision Support (CDS): General administrative tools (such as medical practice management software and revenue cycle management software), general wellness trackers, and qualifying non-device Clinical Decision Support tools.

The four-criterion test for non-device Clinical Decision Support (CDS)

Many digital health founders assume that putting a disclaimer in the footer ("For informational use by clinicians only; not a substitute for professional medical judgment") exempts their clinical software from FDA regulation. Following the FDA's September 2022 Final Guidance on Clinical Decision Support Software (implementing Section 3060 of the 21st Century Cures Act, 21 U.S.C. § 360j(o)(1)(E)), a footer disclaimer does not protect you.

To be excluded from the statutory definition of a medical device in the United States, a CDS software function must satisfy all four criteria simultaneously:

• Criterion 1 (No signal/image acquisition): The software is not intended to acquire, process, or analyze a medical image (DICOM CT, MRI, pathology slide), a signal from an in vitro diagnostic (IVD) device, or a pattern/signal from a signal acquisition system (such as continuous ECG waveforms, PPG photoplethysmography streams, or continuous CGM sensor currents).
• Criterion 2 (Medical information handling): The software is intended for the purpose of displaying, analyzing, or printing medical information about a patient or other medical information (such as peer-reviewed clinical practice guidelines or FDA-approved drug labeling).
• Criterion 3 (HCP-facing recommendation): The software is intended solely to support or provide recommendations to a healthcare professional (HCP) about prevention, diagnosis, or treatment of a disease or condition, and is not intended to provide time-critical, single-output directives where clinical urgency prevents independent review.
• Criterion 4 (Independent review of basis): The software is intended for the purpose of enabling the healthcare professional to independently review the basis for the recommendations so that it is not the intent that the clinician rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient.

Notice the engineering consequences of Criterion 3 and Criterion 4. If your software runs a black-box deep-learning model that outputs "Patient has a 87% probability of sepsis within 4 hours" without exposing the deterministic clinical rules, published guideline citations, and underlying patient inputs in a way a physician can verify during a non-urgent workflow, it fails Criterion 4 and is a regulated SaMD. Similarly, any diagnostic or dosing recommendation delivered directly to a patient or caregiver fails Criterion 3 and is regulated as SaMD.

IEC 62304 safety classes and the FDA 2023 premarket documentation mapping

Once intended use places your software inside medical device jurisdiction, two harmonized frameworks dictate your day-to-day software engineering lifecycle and premarket submission deliverables: IEC 62304 (Medical device software: Software life cycle processes, recognized by both FDA and EU Notified Bodies) and the FDA June 2023 Final Guidance on Content of Premarket Submissions for Device Software Functions.

IEC 62304 Software Safety Classes (A, B, and C)

IEC 62304 assigns every software system (and individual decomposed software item) a safety class based on the worst-case severity of harm that a software defect or failure could contribute to, evaluated before external software risk controls are applied:

• Class A: The software system cannot contribute to a hazardous situation, or a hazardous situation cannot result in injury.
• Class B: The software system can contribute to a hazardous situation that results in non-serious injury (reversible harm that does not cause permanent impairment).
• Class C: The software system can contribute to a hazardous situation that results in death or serious injury (life-threatening harm, permanent impairment of a body function, or permanent damage to a body structure).

Architectural segregation (de-classifying non-critical modules): A critical rule in IEC 62304 Clause 4.3 is that an entire monolithic codebase inherits its highest safety class (usually Class B or Class C) unless you architecturally segregate high-risk software items from lower-risk items. If your mobile app has a Class C insulin bolus calculation engine alongside a Class A UI theme manager and appointment reminder module, isolating the dosing calculator into a sandboxed, memory-protected library with strict input/output contracts and demonstrating in your ISO 14971 risk file that a failure in the Class A UI layer cannot corrupt the Class C dosing output lets you apply heavy Class C unit verification strictly to the dosing module rather than every screen in the app.

FDA Basic vs Enhanced Documentation Levels (2023 Final Guidance)

In June 2023, the FDA retired its 2005 Level of Concern (Minor, Moderate, Major) framework and replaced it with a risk-based binary model: Basic Documentation and Enhanced Documentation.

Your device requires Enhanced Documentation if it meets any of four triggers:

1. The device is a component of a combination product,
2. The device is intended for use with blood/tissue donor suitability or transfusion,
3. The device is a Class III device, or
4. A failure or latent flaw of the device software function(s) could present a hazardous situation with a probable risk of death or serious injury to a patient, user, or other person, assessed prior to the implementation of risk control measures.

For all other device software functions, Basic Documentation applies. Here is the exact engineering deliverable matrix across IEC 62304 classes and FDA documentation tiers:

EU MDR (2017/745) Rule 11 classification traps

If your commercial roadmap includes the European Union or the UK, you must design for Regulation (EU) 2017/745 (EU MDR) alongside the FDA. Under the legacy European Medical Device Directive (MDD 93/42/EEC), most standalone medical software entered Europe as Class I self-certified devices, meaning startups affixed a CE mark without an external Notified Body audit.

Annex VIII, Chapter III, Rule 11 of the EU MDR (Regulation (EU) 2017/745) closed that path:

"Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as class IIa, except if such decisions have an impact that may cause: death or an irreversible deterioration of a person's state of health, in which case it is in class III; or a serious deterioration of a person's state of health or a surgical intervention, in which case it is classified as class IIb."

Under MDCG 2019-11 guidance interpreting Rule 11, virtually any software that processes clinical data to inform diagnosis, triage symptoms, recommend therapy, or monitor physiological metrics is at minimum Class IIa, and often Class IIb. That triggers three immediate obligations:

1. Mandatory Notified Body assessment: Class IIa, IIb, and III software requires an audited ISO 13485:2016 Quality Management System and review of your Annex II/III Technical Documentation and Annex XIV Clinical Evaluation Report (CER) by an EU Notified Body (such as BSI, TÜV SÜD, or DEKRA).
2. Harmonized IEC 62304 + IEC 82304-1 evidence: Notified Bodies verify compliance with IEC 62304 (lifecycle), IEC 82304-1 (health software validation), and IEC 62366-1 (usability engineering).
3. Unified FDA + EU MDR DHF: Because Notified Body queues run 6 to 12 months, dual-market teams maintain one unified Design History File (DHF) / Technical File so the same SRS, SAD, ISO 14971 risk matrix, and CI test reports satisfy both an FDA 510(k) eSTAR filing and an EU MDR audit.

ISO 14971 risk management and automated Git/CI traceability

In medical device engineering, untraceable code cannot ship. Under ISO 14971:2019 (Application of risk management to medical devices) and ISO 13485:2016 Clause 7.3, regulators audit your Traceability Matrix, proving that every identified patient hazard has a verified software risk control and every software requirement traces back to a user need and forward to a passing test.

Building a "Living DHF" inside Git and CI/CD

Managing a Traceability Matrix in manual spreadsheets stalls sprints. High-performing SaMD teams automate the Design History File (DHF) directly inside Git and CI (using Docs-as-Code or ALM tools like Matrix Requirements or Jama):

1. User Needs & Intended Use (UN-xxx): Clinical requirements verified via Summative Usability Testing (IEC 62366-1) and Clinical Validation.
2. ISO 14971 Hazard Analysis (HAZ-xxx -> RC-xxx): Every hazardous situation (e.g., HAZ-014: CGM BLE packet corruption displays stale glucose as current, causing wrong insulin dosing) maps to a software Risk Control (RC-014: CRC-32 check + 5-minute freshness lock) and a Software Requirement (SRS-042).
3. Software Requirements Specification (SRS-xxx): Testable specs stored in version-controlled Markdown/YAML or ALM, tagged with safety class (Class C) and linked to UN-xxx and RC-xxx.
4. Architecture & Pull Request Linkage (SAD-xxx): Pull requests reference SRS-xxx IDs, enforced by CI linters and independent peer review.
5. Automated Verification Evidence (VER-xxx): Unit and integration tests embed requirement IDs in test descriptors (describe('[SRS-042][RC-014] CGM freshness check', ...)). On every release tag, CI executes the test suite, generates signed JUnit/XML reports, verifies 100% traceability coverage, and exports the immutable Traceability Matrix into the DHF.

IEC 62304 does not forbid agile sprints or continuous integration. What kills velocity is keeping your code in Git while keeping your requirements and ISO 14971 risk controls in disconnected Word files. When requirements, hazard controls, and test IDs live in the same CI pipeline, generating a 510(k) traceability report takes three minutes instead of three months.

BLE medical sensor integration and FDA Section 524B cybersecurity

Many modern medical device software products are connected systems: a smartphone app communicating over Bluetooth Low Energy (BLE) with a wearable ECG patch, pulse oximeter, smart inhaler, or blood pressure monitor, syncing telemetry to a HIPAA-compliant cloud backend.

Engineering the BLE and cloud bridge for a regulated medical device requires three hardware-software safeguards:

• Authenticated GATT characteristics and payload encryption: Standard BLE "Just Works" pairing is vulnerable to MitM injection. Regulated devices use LE Secure Connections with Out-of-Band (OOB) or Numeric Comparison pairing, plus application-layer AES-GCM signing provisioned via a hardware secure element.
• Deterministic packet sequencing and clock sync: Because iOS CoreBluetooth and Android BluetoothGatt throttle background execution, sensor firmware must buffer timestamped ring-buffers in flash memory, attach sequence numbers and CRC checksums to GATT frames, and reconcile RTC clock drift against NTP server time.
• COTS mobile OS hazard controls: Because SaMD runs on unmanaged consumer phones, your ISO 14971 risk file must mitigate low-battery shutdowns, Do Not Disturb muting clinical alarms, OS permission changes, and exhausted local storage.

FDA Section 524B: mandatory SBOMs, threat modeling, and OTA patching

Under Section 524B of the FD&C Act (21 U.S.C. § 360n-2) and the FDA's September 2023 Final Cybersecurity Guidance, any connected software device ("cyber device") requiring a premarket submission (510(k), De Novo, PMA) must include three mandatory cybersecurity deliverables:

1. Secure Product Development Framework (SPDF): A formal STRIDE Threat Model across sensor, mobile app, cloud API, and EHR interfaces, a Cybersecurity Risk Assessment scoring exploitability, SAST/DAST reports, and third-party penetration test evidence.
2. Machine-Readable Software Bill of Materials (SBOM): An automated CycloneDX or SPDX SBOM covering all commercial and open-source components (aligned with your IEC 62304 SOUP list), verified against the CISA KEV and NVD CVE catalogs with documented support lifecycles.
3. Cryptographically signed OTA patching: Proven capability to deliver signed firmware and software updates in the field under a coordinated vulnerability disclosure SLA.

Cloud backends storing identifiable patient telemetry must also enforce the HIPAA Security Rule (45 CFR Part 164 Subpart C) and NIST SP 800-66 Rev. 2, covered in HIPAA-compliant software development, while summary reports written to hospital charts follow the FHIR R4 patterns in EHR integration.

FDA Predetermined Change Control Plans (PCCP) for AI/ML medical software

For AI/ML SaMD (such as radiology triage models or predictive deterioration algorithms), legacy 510(k) rules froze neural network weights at clearance; retraining on new clinical cohorts required filing a new 510(k). Under FDORA Section 3308 and the FDA's Predetermined Change Control Plan (PCCP) guidance, manufacturers include three components inside their initial 510(k), De Novo, or PMA submission:

1. Description of Modifications: Bounded post-market updates planned for the model (e.g., retraining to support new imaging hardware or demographic sub-populations).
2. Modification Protocol: Data management rules (strict training/test segregation, ground-truth clinical labeling), retraining triggers, and minimum validation guardrails (sensitivity, specificity, AUROC confidence bounds).
3. Impact Assessment: Analysis of how updates interact with the ISO 14971 risk file and prevent regressions.

Once cleared with a PCCP, your team can retrain models, validate them against the locked Modification Protocol, log the evidence in your ISO 13485 QMS, and deploy to production without filing a new 510(k) as long as updates stay within the pre-approved bounds.

2026 cost and timeline realities for SaMD and medical device software

Scoping a regulated medical device software build requires budgeting for both code implementation and Design History File (DHF) verification:

(Engineering budgets cover software development, automated verification, cybersecurity testing, and technical file engineering; they exclude clinical trials, Notified Body fees, and FDA MDUFA user fees.)

Because IEC 62304 and ISO 14971 verification adds 30% to 45% in engineering effort compared to unregulated builds, team structure drives capital efficiency. Across European hubs, Eurostat's labour cost index (Eurostat lc_lci_lev) highlights the hourly cost advantage of staffing senior regulated-software engineers in Central and Eastern Europe compared to US coastal or Western European hubs while maintaining identical ISO 13485 traceability and FDA/MDR documentation quality.

At Idealogic, our healthcare software development and custom software development teams run the intended-use analysis, IEC 62304 safety classification, and automated Git traceability setup in Sprint Zero. We have shipped regulated healthcare and cryptographic platforms across US and EU frameworks, including AddMed (covered in the AddMed case study) and Chaindoc (detailed in the Chaindoc case study), and our technical due diligence practice regularly audits SaMD codebases preparing for 510(k) and Series A milestones.