Developing software for the medical device industry requires a careful balance between innovation and safety. As healthcare technology rapidly evolves, manufacturers must meet strict guidelines to maintain software reliability. Achieving these goals demands a clear, structured approach to software development—one that anticipates potential risks, ensures high-quality outcomes and aligns with the evolving expectations of regulators worldwide. In many cases, a medical device consists of hardware and sophisticated software that must function seamlessly to uphold clinical standards.

At Scythe, our primary service is comprehensive embedded software development, and the majority of our customers are exactly medical device manufacturers or startups. As medical device software is what we do daily, we introduced ISO 13485:2016 and of course, we do our work in the IEC 62304 regime.

Below, we explore how a risk-based approach, robust security measures, and well-aligned strategies can shape software and medical device software that comply with IEC 62304. Additionally, the standard’s applicability to various forms of medical electrical equipment underscores its role in promoting consistency across the healthcare sector.

 

What is IEC 62304?

IEC 62304:2006 is an internationally recognized software lifecycle standard that provides (not so clear :)) guidance on the processes, activities, and tasks essential for creating and maintaining software used in medical devices. By prescribing a risk-based approach, it helps developers structure their implementation phase, refine software architecture, and ensure robust software system testing, all while maintaining a high level of security.

Adhering to IEC 62304 underscores a commitment to patient safety and regulatory readiness. It’s widely recognized in the medical device industry by regulators. In the European Union, the Medical Device Regulation (MDR 2017/745) and In Vitro Diagnostic Regulation (IVDR 2017/746) harmonized this standard and the US FDA also recognizes it as a consensus standard.

The expansion of the full name of the standard is “Medical Device Software – Software Life Cycle Processes”.

 

What does IEC 62304 regulate for medical device software development?

The standard provides a framework for developers to establish life cycle processes, which include activities for the safe creation and post-market maintenance of the device. Each cycle has life cycle requirements. A single process consists of several activities, and a single activity consists of tasks.

The following processes are defined in the IEC 62304 medical device software standard:

 

1. Software Development Process
2. Software Maintenance Process
3. Software Risk Management Process
4. Software Configuration Management Process
5. Software Problem Resolution Process

The standard requires equipment manufacturers to create and maintain technical documentation that will be submitted to regulatory bodies. We will write more about the content of the documentation later in the post.

If you’re looking for an IEC 62304:2006 PDF with the content with the standard, I have to disappoint you. You must purchase it on your own as each copy is marked in a way that you shouldn’t copy it. I don’t necessarily like it, but it’s not a huge cost after all.

 

IEC 62304 Processes for Medical Device Software Development

 

Why IEC 62304 matters to you?

IEC 62304 compliance is increasingly required in both domestic and global markets. Regulators such as the FDA in the United States and the European Commission expect proof of a robust software development framework when approving medical equipment or devices for sale. Demonstrating compliance with IEC 62304 can:

 

• Speed up regulatory approval through structured regulatory submissions.
• Build trust with stakeholders (healthcare providers, investors, patients).
• Reduce software failure risks and prevent serious injury.
• Have a structured and repeatable software development process.

In short, IEC 62304 is a must-have for any business serious about being in the medical devices market.

 

IEC 62304 Basics

Let’s now have a look at some of the most basic yet essential information that you should know to have an idea of what you’re talking about.

 

Safety Classes (A, B, C)

IEC 62304 categorizes medical device software into three safety classes. Manufacturers should classify products based on hazardous situations and potential harm.

 

• Class A: No injury or damage to health can occur if the software fails.
• Class B: Software failure could cause non-serious injury.
• Class C: Software failure could cause death or serious injury.

The classification level determines the level of documentation and rigor required in the development process. For example, Class C devices require more stringent verification and validation than Class A or B as the risk to patients is higher.

The particular regulations like the European MDR or FDA, introduce their own classification. In the US there are also three classes (I, II, III) while in the EU there is one extra intermediate one (I, IIa, IIb, III). In both cases, class C is more or less equivalent to class III while class A is the least-harmful class corresponding with class I.

 

Safety Classes Acording To IEC 62304

 

Technical Documentation

The IEC 62304 requires you to document a number of various things. Key elements of the documentation include:

 

• Software Requirements Specification (SRS); A structured document that defines all functional and non-functional requirements of the software.
• Safety risk assessment; A systematic evaluation of potential hazards, their causes, and mitigations to ensure software safety.
• Software Detailed Design (SDD); A document outlining the internal structure, architecture, and design elements of the software, ensuring traceability to requirements.
• Cybersecurity threats assessment; An analysis of potential security vulnerabilities and attack vectors to ensure data integrity, confidentiality, and protection against cyber threats.
• Traceability matrix; A document linking software requirements to design, implementation, verification, and validation activities to ensure full coverage and compliance.
• Core review, static code analysis, unit and integration testing reports; Documentation of software code reviews, automated code analysis results, and test reports verifying correctness, performance, and compliance.
• Surveillance plan; A post-market monitoring strategy to track software performance, detect failures, and implement necessary updates or corrective software changes.

Of course, it is not a complete list. Many of those topics shall be split into separate documents. How you organize the documentation is more up to you.

 

Software Architecture

As IEC 62304 is a common framework in medical device software development, you should only with that it tells you about document your medical device architecture. It’s not that scarry and later on I explain how to deal with the blurriness of this standard. Of course, it all depends on the medical device classification and its complexity.

The main point that you have to note is that the software architecture should be based on the requirements. So first you have to analyze what features your device has to serve before you specify how to actually satisfy this. As the minimum, software architecture should identify software items – bigger chunks of your projects, and how they interact with each other. By that I mean connectivity interfaces (physical/wireless, Bluetooth/TCP/IP/MQTT – you name it).

 

Example high-level design

 

Risk Management

IEC 62304 requires robust risk management. The standard aligns closely with ISO 14971 the internationally recognised risk management standard for medical devices. Developers must:

 

• Identify potential hazards associated with software functionality.
• Assess and evaluate the risks.
• Implement measures to reduce or mitigate these risks.
• Document all risk-related activities and outcomes.

This structured risk management approach means emerging risks can be quickly identified and mitigated reducing hazardous situations. Risk management is a base for classification.

 

IEC 62304 Software Development Process

The IEC 62304 requires that the medical software systems development process consists of several key lifecycle requirements:

 

Planning

Effective planning sets the foundation for a successful project. In this phase, teams define the scope of the software, its intended use, required safety classification, and the activities necessary to meet IEC 62304 requirements. By creating detailed project plans, resource allocations, and schedules, organizations establish clear expectations for stakeholders and developers.

 

Requirements Analysis

Once planning is done, we move on to writing requirements. Requirements should be:

 

• Traceable to user needs and risk controls;
• Clear and justified;
• Reviewed and approved before proceeding.

Requirements are not only about features – they cover multiple aspects to ensure safety, usability, performance, and compliance. Saying about features we can distinguish between functional requirements (features), non-functional requirements (performance, UX/UI, security), interface requirements or maintenance.

 

Architectural Design

The architectural design phase defines the high-level structure of the software, including the components, interactions, and data flow. This step ensures the software is modular, scalable, and meets safety and performance requirements. We document the architecture to maintain traceability and enable risk assessments, so we can ensure critical parts of the system (e.g. fault tolerance and redundancy) are properly considered.

 

Detailed Design

In the detailed design phase, we refine the architectural components into software modules and define their internal logic, data structures, and interactions. We consider software safety mechanisms, exception handling,g and cybersecurity controls. By documenting each module, we enable testing, maintenance, and compliance verification so the software behavior meets both functional and regulatory requirements.

 

Implementation

Implementation involves writing and compiling the source code according to the approved design. In this phase, developers usually follow coding standards and best practices relevant to the medical device context. Code reviews, static analysis, and integration checks maintain quality and prevent defects that could compromise safety.

 

Testing and Validation

Verification checks whether the software meets specified requirements, validation confirms it fulfills its intended use in real-world scenarios. The level of testing detail depends on the safety classification:

 

• Unit testing for individual components.
• Integration testing to ensure modules work together as intended.
• System testing for end-to-end functionality against requirements.
• User acceptance testing (UAT) to test real-world performance.

All these testing activities cover validation requirements and must be documented for regulatory scrutiny.

 

Release and Maintenance

Even after the final software release, the device requires ongoing monitoring and maintenance. IEC 62304 emphasizes the need for:

 

• Post-market surveillance: Collect user feedback and incident reports to identify emerging risks.
• Corrective and preventive actions: Fix issues before they become significant.
• Updates and patches: Address vulnerabilities, regulatory changes, and usability improvements throughout the product’s lifetime.

 

IEC 62304:2006 Software Development Process

 

How to Develop Medical Device Software and Don’t Go Crazy?

Well, at first glance introducing processes according to IEC 62304:2006 might seem like an impossible task. You are there and you don’t want what to start with. Before you start questioning all your life choices, let me explain why the formal part of medical device software development is so cumbersome and how to deal with it.

First of all, I have to admit that after years of being commercially involved in embedded software design, it is still challenging and each project is different. Companies struggle to design software architecture, design UX/UI and look of the devices, do the electronics, implement device software, and perform robust tests, so if we add extra regulatory effort, analyses, and risk control measures on top of that… Some might think that it’s not even worth starting. It’s exactly the problem: the amount of work (varies from device to device) and unfamiliarity with the standard. That’s why I wrote this article.

My remedy for this is the following: Take training and do it together with key people in your team, so you all understand at least high-level information about the standard. I have seen smart individuals successfully doing all the documentation on their own after the training and doing their own research. If you don’t have time, or skills or just want to have a partner in this process, consider hiring software consultants with experience in medical device software development.

Another problem with IEC 62304 is that development practices in other industries are often different and many developers, software engineers, and managers are not used to medical device development flow enforced by the standard. With all the requirements, risk management, assessments, and planning that have to be completed first, the Waterfall model seems a natural way to develop medical device software. However, most of the developers without a background in health software rather prefer Agile-like models. Standard tells you that especially for safety critical systems elements you should first do detailed design, but the truth is that you often don’t know how to implement a particular feature beforehand.

My answer to this one is the following: Proper planning is beneficial. Once you learn how to do it you are going to find a lot of value in this. You should also involve the engineers at this stage, so even if they’re not yet sure how to do a particular thing (whether it’s a software item or some risk control measures), they can test out proof of concepts at this stage. Also, no one says that something written once, can’t be corrected as long as we ensure traceability.

The Agile software development process can be successfully adapted during the implementation activity. You can prepare the next versions of your medical device and present it to stakeholders once in a while to get feedback and then proceed with the next functionalities.

 

 

Building Safe Medical Software: Choose a Development Partner Who Puts Efficiency First

Choosing the right development partner can make all the difference to your IEC 62304 compliance. If you really care and I bet you do, look for a team that:

 

• Has medical device software expertise: They should understand clinical workflows, patient safety, and regulatory requirements.
• Has out-of-the-shelf components: They should have solutions like software libraries, preferred hardware targets, templates, and know-how to quickly accelerate your project, so you can benefit from smaller costs.
• Has a proven track record: References or case studies of IEC 62304 documented projects.
• Has an integrated quality management system (QMS): An established QMS (e.g. ISO 13485) ensures design controls.
• Is competent, scalable, and flexible: They should adapt to your product evolution from initial design to post-launch maintenance.

By choosing experienced professionals who put compliance and innovation first you will lay the foundation for building safe and market-ready medical software. Better think of a partner that is capable of keeping the balance between regulatory requirements and the work efficiency.