Medical Device Software Development in 2026: IEC 62304, FDA SaMD, and What to Expect

Medical device software sits at the intersection of software engineering and regulatory science. The software itself may not be more complex than a consumer app — but the processes surrounding it (documentation, validation, change control, risk management) are significantly more rigorous. Here is what that actually means for a development project.

Is Your Software a Medical Device?

The first question is whether your software qualifies as a medical device under FDA or EU MDR regulations. Software is a medical device (SaMD) if it meets the intended use definition:

FDA definition: Software that is intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.

Key trigger questions:

• Does the software provide a diagnosis, treatment recommendation, or clinical decision?
• Does it analyze patient-specific data to produce a clinical output?
• Is it intended to affect the structure or function of the body?

Examples of SaMD: AI diagnostic imaging tools, clinical decision support that recommends specific treatments, software controlling drug dosing, remote patient monitoring that alerts clinicians to deterioration.

Examples of software that is NOT SaMD: Hospital administrative software, general wellness apps without clinical claims, medical education software, clinical communication tools.

If your software triggers the SaMD definition, stop development until you have a regulatory strategy. Building without classification certainty means you may have built a non-compliant product.

IEC 62304 Software Lifecycle Requirements

IEC 62304 defines what a compliant software development process looks like. The standard assigns safety classes based on the potential severity of harm from software failure:

Class A: No injury or damage to health is possible. Example: administrative healthcare software. Class B: Non-serious injury is possible. Example: software driving a non-life-critical alert. Class C: Death or serious injury is possible. Example: software controlling drug infusion, diagnostic AI for critical conditions.

Required deliverables by safety class:

Activity	Class A	Class B	Class C
Software development plan	Required	Required	Required
Software requirements	Required	Required	Required
Software architecture	Not required	Required	Required
Software detailed design	Not required	Not required	Required
Unit testing	Not required	Required	Required
Integration testing	Not required	Required	Required
System testing	Required	Required	Required
Change request tracking	Required	Required	Required
Traceability matrix	Required	Required	Required

Class C adds design documentation at the function/module level and requires bidirectional traceability from every requirement through design, implementation, unit test, and system test.

The Documentation Reality

Most development teams underestimate documentation scope. For a mid-complexity Class B medical device software:

• Software Development Plan: 15–30 pages defining development methodology, tools, roles, and process
• Software Requirements Specification: Each requirement numbered, testable, and linked to clinical need
• Software Architecture Document: System decomposition, interfaces, rationale for architecture decisions
• Hazard Analysis: Risk assessment per ISO 14971 — what can fail, what is the harm, what are mitigations
• Test Plans: Unit test plan with pass/fail criteria; integration test plan; system test plan
• Test Results: Documented evidence of each test execution
• Traceability Matrix: Requirement → design → implementation → test — every row must be complete at submission

Estimate 30–50% of total project cost in documentation, process compliance, and validation activities for Class B. Class C: 50–70%.

Development Process Adjustments

Compliant medical device development requires specific process controls:

Change control: Every code change after baseline is a formal change request with impact assessment. The casual "push a fix to production" workflow does not exist in medical device development. Changes require documented justification, impact analysis on safety, regression testing, and approval before deployment.

Version control as regulatory evidence: Every release must be reproducible from version control. Your git history, build scripts, and dependency lockfiles are regulatory records.

Defect tracking: All software problems (bugs) must be tracked, classified by severity, and resolved or formally accepted through a review process. A bug tracker is a regulatory requirement, not just a project management tool.

Software release process: Each software release requires a Software Release Checklist confirming all requirements tested, all known defects dispositioned, documentation complete, and authorized approver sign-off.

Regulatory Pathway Options

FDA 510(k) Substantial Equivalence: For Class II devices. Demonstrates your device is substantially equivalent to a legally marketed predicate device. Timeline: 6–12 months average (FDA review target is 90 days, but cycles of questions extend this).

FDA De Novo: For novel Class II devices without a predicate. More rigorous than 510(k). Timeline: 12–24 months.

FDA PMA (Premarket Approval): For Class III devices. Full clinical evidence required. Timeline: 24–36+ months. Rarely the right path for software-only devices.

EU MDR CE Marking: For European market. Requires a Notified Body review for Class IIa and above. QMS certification per ISO 13485 required. Timeline: 12–24 months for Notified Body review.

---

Ortem Technologies works with medical device and health tech companies on regulated software development. We can engage for full IEC 62304-compliant development or for specific phases (architecture, software requirements specification, validation testing) alongside your existing team.

Discuss your medical device software project → | Healthcare software development →