Medical Device Software Development

What Is Medical Device Software Development?

Medical device software development turns software that meets the legal definition of a medical device into a product regulators can authorize. Two early decisions shape the whole project: the device's form and how much evidence regulators will expect for its risk. Settling both early keeps rework out of the submission stage.

Device software comes in two forms. Software as a Medical Device (SaMD) performs a medical purpose on its own, such as an app that detects atrial fibrillation from a smartwatch ECG. Software in a Medical Device (SiMD) runs inside hardware and controls or monitors it, such as the firmware in an insulin pump. Both follow the same core lifecycle standard, IEC 62304, but they differ in how they are tested and updated.

The groundwork shared with all medical software development, such as hazard analysis and requirement-to-test traceability, still applies. Device status adds a regulatory submission and its review on top.

What Does Medical Device Status Change for a Software Team?

• The code becomes part of a legal record. Every requirement and test result is kept in controlled documents that regulators and auditors can inspect for the life of the product. Engineers write for that audience as well as for each other.

• Marketing claims are tied to the intended use. The software can be promoted only for its documented intended use. Adding a clinical claim later, such as moving from displaying a reading to flagging a condition, usually needs a new FDA submission or notified body review.

How Does Medical Device Software Development Work?

• Design controls frame the project. Since February 2, 2026, the FDA's Quality Management System Regulation incorporates ISO 13485, whose design and development clause requires planned inputs, outputs, reviews, verification and validation. Each step leaves a record in the design and development file.

• The FDA documentation level is set early. The FDA's software premarket guidance assigns each submission a Basic or Enhanced documentation level. Enhanced applies when a software failure could present a probable risk of death or serious injury, judged before risk controls are applied, and it adds a software design specification plus unit and integration test documentation.

• Architecture isolates the riskiest parts. IEC 62304 lets a team give lower-risk components a lower safety class if the architecture keeps them separate from higher-risk ones. A well-documented boundary between, say, a dosing algorithm and a reporting dashboard reduces the testing burden on the dashboard.

• Third-party software is documented as SOUP. Every library and operating system the device depends on is listed with its version and its known anomalies. The FDA's off-the-shelf software guidance sets out what the submission must say about each one.

• Cybersecurity is designed in. Teams turn a threat model into security requirements and maintain a software bill of materials alongside the code. For devices with cybersecurity risk, the FDA's cybersecurity guidance makes these part of the premarket submission.

• Changes after release are assessed for submission impact. Each update is checked against the FDA's guidance on when a software change needs a new 510(k). Under the FDA's 510(k) rule, a change that "could significantly affect" safety or effectiveness, or makes a major change to the intended use, needs a new submission.

What Tools Do Teams Use for Medical Device Software Development?

• Static analysis and code verification. Parasoft C/C++test, LDRA (now part of TASKING) and MathWorks Polyspace check embedded and safety-related code against coding standards and find runtime errors before testing. Their reports serve as verification evidence in the design file.

• Threat modeling. The Microsoft Threat Modeling Tool and IriusRisk help teams map how an attacker could target a device and turn each threat into a security requirement.

• Embedded and hardware-in-the-loop testing. VectorCAST automates unit and integration tests for embedded code, and NI TestStand runs system tests against the device hardware. Their results supply the unit and integration test records an Enhanced-level submission needs.

What Are the Key Characteristics of Medical Device Software Development?

• Release baselines are frozen. Each released version is tied to an exact set of source files and build tools, so the manufacturer can rebuild and investigate any version still in the field.

• Known bugs are disclosed. Submissions include a list of unresolved anomalies with an explanation of why each one is acceptable. Teams ship with known defects only when the risk rationale is written down.

• Hardware shapes SiMD design. Firmware for pumps or ventilators runs under timing and memory limits, and it is tested together with the hardware under electrical safety standards such as IEC 60601-1.

• AI models need a change strategy. An AI-enabled device either ships with a locked model or with a Predetermined Change Control Plan describing which model updates the FDA has authorized in advance.

What Are the Benefits of Medical Device Software Development?

• The right to make clinical claims. Only a legally marketed device can be promoted as diagnosing or treating a condition. Clinicians can then use the product for the diagnosis or treatment it was cleared for.

• Access to device-specific payment. Some Medicare payment codes require an FDA-cleared or FDA-authorized product, such as the codes CMS added in 2025 for digital mental health treatment devices.

• A head start on competitors. A competitor with similar code still has to build its own quality system and submission record. Once a device is cleared, though, competitors can cite it as the predicate for their own 510(k), which shortens their path.

• Fewer field failures. Risk-driven verification concentrates test effort on the functions whose failure could harm a patient, which is where a field defect costs the most.

What Are the Challenges of Medical Device Software Development?

• Documentation cost rises with risk. Enhanced-level documentation and a higher IEC 62304 class add design and test records to the first submission and to every change after it. Segregation work done early limits that overhead on later releases.

• SOUP updates carry regulatory weight. Patching an operating system or library means re-running the affected verification and updating the SOUP list. FDA guidance treats a change made only to strengthen cybersecurity as unlikely to need a new 510(k), but the team still records that assessment for every patch.

• AI rules are still settling. The FDA issued its lifecycle guidance for AI-enabled device software as a draft in January 2025. The EU's Digital Omnibus on AI moved the AI Act's high-risk obligations for AI-enabled medical devices from August 2, 2027 to August 2, 2028. Teams designing now build to the FDA draft, at the risk of rework when the final guidance lands.

• Legacy code lacks the record. Software written before the team adopted IEC 62304 needs retrospective documentation and gap analysis. The standard allows this path for legacy software, but retrofitting the records is slow when the original design reasons were never documented.

What Is the Difference Between SaMD and SiMD?