The software development lifecycle under IEC 62304

IEC 62304 defines the lifecycle processes for medical device software and scales the required rigor to how much harm the software could cause. It is a process standard, not a product standard: it tells you what activities and documentation are required, not how to write your code.

The current edition sorts software into three safety classes:

• Class A: no injury or damage to health is possible.
• Class B: non-serious injury is possible.
• Class C: death or serious injury is possible.

Your class determines how much of the standard’s lifecycle you must formally execute and document: planning, requirements analysis, architectural design, detailed design, implementation, integration and testing, verification, release, and ongoing maintenance.

The big shift on the horizon is Edition 2, expected around August 2026. It replaces the three safety classes with two process rigor levels, adds explicit requirements for AI and machine learning lifecycles, deepens cybersecurity expectations, and widens the scope to cover all health software rather than only formally regulated devices. The practical takeaway: if you are starting a build in 2026, architect your documentation with Edition 2 in mind so you are not retrofitting a year from now.

Design controls, documentation, and traceability

FDA design controls require you to prove, with documented traceability, that the software you built matches the software you specified. This is where regulatory theory becomes daily engineering practice.

At the center sits the Design History File, the record that demonstrates the design was developed according to your plan. It links design inputs (what the software must do) to design outputs (what you actually built) to verification and validation (evidence that the outputs meet the inputs and the user’s real needs). The connective tissue is a traceability matrix that maps every requirement to its design element and its test.

The teams that struggle are almost always the ones that treat documentation as a submission-week scramble. Reconstructing traceability after the fact is slow, error-prone, and a red flag to reviewers. Documenting as you build is faster overall and produces a cleaner submission.

Cybersecurity is now a legal requirement

Under Section 524B of the Federal Food, Drug, and Cosmetic Act, cybersecurity is a mandatory part of premarket submissions for cyber devices. It is no longer an optional layer you can defer to a later release.

Three expectations sit at the core:

• A Software Bill of Materials (SBOM): a complete inventory of the components in your software, including open-source and third-party code, so vulnerabilities can be tracked across the product’s life.
• Secure-by-design and threat modeling: demonstrating that you identified threats and designed controls against them, rather than bolting on security at the end.
• Postmarket vigilance: a plan for monitoring, patching, and coordinated vulnerability disclosure after launch.

The supporting standard here is IEC 81001-5-1, which sets out the security activities across the health software lifecycle. If your product connects to a network, syncs to the cloud, or receives updates, plan for 524B from day one.

Building AI and machine learning into medical device software

AI-enabled medical software can be updated after clearance without filing a new submission, provided the changes were pre-authorized in a Predetermined Change Control Plan (PCCP). This is one of the most important regulatory developments for modern health software, because a learning model that never changes defeats the purpose of using AI at all.

Historically, a meaningful change to an algorithm counted as a change to the device and could trigger a fresh 510(k), De Novo, or PMA supplement. The PCCP framework, detailed in the FDA’s final guidance for AI-enabled device software functions, lets you define your intended changes up front and get them authorized alongside the initial submission.

A PCCP has three parts:

1. Description of Modifications: the specific changes you plan, such as retraining on new data.
2. Modification Protocol: how you will develop, validate, implement, and monitor those changes.
3. Impact Assessment: an analysis of the benefits and risks of the planned changes.

The urgency is grounded in data. A 2025 study in JMIR Medical Informatics that analyzed 27 years of FDA recall data found that device design and software design root causes accounted for 50 percent of recalls among AI and machine learning enabled devices. In other words, AI raises the stakes on disciplined development, and the PCCP is the FDA’s mechanism for keeping iteration safe. Pairing a PCCP with early FDA feedback through the Q-Submission Program is one of the most effective ways to de-risk an AI build.

HIPAA and data privacy for connected health software

If your software creates, stores, or transmits protected health information, HIPAA compliance sits on top of FDA requirements, not instead of them. A product can be a cleared medical device and still be non-compliant with HIPAA, and vice versa.

The technical safeguards that matter most are encryption in transit and at rest, role-based access control, and complete audit logging of who touched what data and when. Just as important, every cloud provider, analytics vendor, or third party that handles PHI on your behalf needs a Business Associate Agreement in place. For a deeper walkthrough of building to this standard, see Ailoitte’s approach to HIPAA-compliant software development.

The FDA submission pathway, step by step

Reaching the US market follows a repeatable sequence. Knowing the order helps you plan resourcing and avoid rework.

1. Classify the device and confirm the pathway (510(k), De Novo, or PMA).
2. Stand up your quality management system aligned to QMSR and ISO 13485.
3. Execute the IEC 62304 lifecycle with documentation built as you go.
4. Build the risk management file under ISO 14971.
5. Assemble cybersecurity documentation, including your SBOM and threat model.
6. Consider a pre-submission (Q-Sub) meeting to get FDA feedback before you file, especially for novel products or AI.
7. Submit your application with all supporting evidence.
8. Respond to FDA review questions and secure clearance or approval.
9. Set up postmarket surveillance, including adverse event reporting and, for connected devices, vulnerability monitoring.

Early engagement pays off. The Q-Submission Program lets you validate your regulatory strategy, and your proposed PCCP, before you have sunk the full cost of a submission.

Compliance mistakes that blow up timelines and budgets

Most medical device software delays come from process gaps discovered late, not from the code itself. Across builds, the same avoidable mistakes recur:

• Documenting after the fact. Reconstructing design history and traceability before a submission burns weeks and invites reviewer scrutiny.
• Misclassifying the device. Picking the wrong class or pathway can mean redoing testing and evidence from scratch.
• Deferring cybersecurity and usability. Both are now core design activities, not launch-week cleanup.
• Assuming ISO 13485 equals QMSR readiness. The FDA-specific additions still need to be met.
• Building AI with no change-control plan. Without a PCCP, every model improvement risks becoming a new submission.

The common thread is treating compliance as a phase at the end rather than a discipline woven through the build. Teams that bake regulatory thinking into sprint planning ship faster and cleaner.

Choosing a development partner

The right partner brings regulatory fluency and quality-system discipline, not just engineering capacity. When evaluating a medical device software development team, look for a QMS-aligned process, demonstrated IEC 62304 and ISO 14971 experience, security certifications, and a verifiable delivery record in regulated healthcare.

This is where a track record matters more than a pitch. Ailoitte builds HIPAA-ready healthcare software backed by ISO 27001 and ISO 9001 certifications, with more than 300 products delivered across 21 countries. That includes work like the Utsah Smart Ring, built with Sri Sri Tattva, which achieved 95 percent accuracy on heart rate and HRV and 90 percent accuracy on sleep tracking, exactly the kind of connected, sensor-driven health product where getting compliance and quality right is non-negotiable.

What medical device software costs and what drives it

Cost is driven less by feature count than by device class, software safety class, and documentation burden. A Class I administrative tool and a Class C AI diagnostic sit in entirely different cost universes even if their feature lists look similar on paper.

The biggest cost drivers are the device classification and submission pathway, the IEC 62304 safety class, the presence of AI or machine learning, and the scope of cybersecurity and clinical validation required. For a full breakdown of estimates and the variables behind them, start with Ailoitte’s ultimate guide to healthcare software development.

Building for the US market with confidence

Building medical device software for the United States is demanding, but the path is well-defined: classify your device, build against the compliance stack, document as you go, and plan for cybersecurity and AI change control from the start. The 2026 shift to QMSR and the maturing rules around AI make this the right moment to build to current requirements rather than yesterday’s.