IEC 62304 demystified

Planning is where the team decides how the software work will be performed and controlled.

For the wearable system, the software development plan should explain things such as:

• Which lifecycle model the team will use,
• Which deliverables will be created,
• How requirements will be traced to tests and risk controls,
• How configuration and change management will work,
• How third-party software will be handled,
• How anomalies and problem reports will be managed,
• How verification will be planned.

IEC 62304 requires the development plan to cover processes, deliverables, traceability, configuration and change management, and problem resolution. It also requires planning for verification and software risk management.

For a modern team, this plan does not need to be a heavy document that nobody reads. It can reference existing procedures, templates, tools, and workflows. What matters is that the team can show a controlled way of working.

A good software development plan should answer practical questions:

• Where do requirements live?
• How are risks linked to requirements and tests?
• Which tools are under configuration control?
• Who approves changes?
• What is the definition of done for safety-related work?
• How are releases built and archived?
• How are bugs assessed after release?

The plan should help the team work, not only help the auditor review.

2. Software requirements

Requirements are where many projects either become manageable or painful.

A requirement is not just a feature idea. In medical device software, requirements need to be clear enough to design, implement, verify, and trace.

For the wearable monitor, software requirements may include:

Functional requirements

• The wearable shall measure heart rate at defined intervals.
• The mobile app shall display the latest synchronized measurement.
• The cloud service shall store timestamped measurements for clinician review.

Safety-related requirements

• The system shall detect loss of sensor contact and mark affected measurements as unreliable.
• The app shall notify the user if data synchronization has failed for a defined period.
• The alert service shall prevent duplicate alerts from hiding a higher-priority alert.

Cybersecurity requirements

• Data shall be encrypted in transit between device, app, and cloud.
• Pairing shall require authentication.
• Clinician access shall require appropriate authorization.
• Security-relevant events shall be logged.

Usability requirements

• A critical alert shall be distinguishable from a general notification.
• The app shall explain when measurements are unavailable or unreliable.
• The clinician portal shall show when data was last received.

IEC 62304 expects software requirements to cover, as appropriate, functionality, inputs and outputs, interfaces, alarms, security, user interface requirements, data and database requirements, installation, maintenance, IT-network aspects, user maintenance, and regulatory requirements.

Good requirements do not need to be complicated. They need to be testable, unambiguous, traceable, and useful.

A weak requirement might say:

The app shall show health data clearly.

A stronger requirement might say:

The app shall display the timestamp of the latest synchronized heart-rate measurement next to the displayed value.

The second version is easier to implement, easier to test, and easier to connect to a risk control if stale data could mislead the user or clinician.

3. Architecture

Architecture describes how the software is structured.

For a connected medical device, architecture is more than a block diagram. It should explain how data moves, where decisions are made, where risk controls are implemented, and how software items are separated.

In our wearable system, important architectural questions include:

• Which calculations happen on the wearable, in the phone, and in the cloud?
• What happens if Bluetooth disconnects?
• What happens if the cloud is unavailable?
• Which component generates alerts?
• Which component stores the audit trail?
• How are software updates delivered?
• Can a failure in a non-critical feature affect a safety-critical function?

Segregation is especially important. A cosmetic app feature should not be able to interfere with a clinical alert. A cloud analytics experiment should not silently change released medical functionality. A debug interface should not create a route to manipulate patient data.

IEC 62304 allows a software system to be decomposed into software items with different safety classes, but the rationale must be documented. The standard also explains that architecture is central to understanding the role, interfaces, and safety relevance of each software item.

For example, the cloud platform may contain both safety-related and non-safety-related services. A trend visualization service may be less critical than an alert-routing service. If the manufacturer wants to classify them differently, the architecture must support that separation and the rationale must be credible.

4. Detailed design, implementation, and unit verification

Once architecture defines the main software items, the team designs and implements the software units.

For lower-risk software, the required level of detail may be lighter. For Class C software, IEC 62304 expects more rigor in detailed design and verification.

In our wearable example, a Class C signal-processing algorithm may require:

• documented design,
• defined inputs and outputs,
• handling of boundary conditions,
• documented assumptions,
• unit verification,
• review of error handling,
• and tests for abnormal or noisy sensor data.

A non-safety-related settings screen may not require the same level of detail.

This is one of the strengths of IEC 62304: it does not require every part of the software to be treated as equally critical. It asks the team to apply the right level of control based on risk.

For developers, this means that the question is not only "does the code work?". It is also:

• Which requirement does this code implement?
• Could this code contribute to a hazardous situation?
• Which assumptions does it depend on?
• What happens when the input is invalid, late, missing, or corrupted?
• How will we know if a later change breaks it?

5. Integration and system testing

Unit tests are useful, but they are not enough.

A connected product can fail in the gaps between components:

• The sensor works, but the app misinterprets the value.
• The app works, but the cloud rejects data after an API change.
• The cloud stores data correctly, but the clinician portal displays the wrong time zone.
• The alert rule works, but notifications are delayed when the phone is offline.

IEC 62304 requires integration testing for Class B and C software and software system testing to verify that requirements are covered. The standard also requires test records, anomaly handling, and regression testing when appropriate.

For the wearable system, integration testing should include realistic scenarios:

• weak Bluetooth signal,
• low battery,
• corrupted data packets,
• cloud downtime,
• delayed synchronization,
• app background restrictions,
• patient changing phone,
• clinician access from different environments,
• and software updates.

The point is not only to test the happy path. Medical device software must also behave safely when things go wrong.

6. Release

A release is not simply "the code was merged".

For medical device software, the manufacturer needs to know exactly what was released, how it was built, what anomalies remain, which tests were run, and whether the software can be delivered without corruption or unauthorized change.

For the wearable device, this could include:

• firmware version,
• mobile app version,
• backend service version,
• cloud configuration,
• database migration version,
• third-party library versions,
• build environment,
• release notes,
• known residual anomalies,
• and installation or update procedure.

IEC 62304 requires the released software version to be documented. For Class B and C software, it also requires evaluation of residual anomalies, documentation of how released software was created, completion of activities and documentation, archiving, and procedures for reliable delivery.

This is especially important for IoT products, where updates may happen many times during the product lifetime.

A release process should make it possible to answer a simple question months or years later:

What exactly was running in the field, and what evidence did we have before we released it?

7. Maintenance is part of the lifecycle

Medical device software is never truly done.

Phones change. Operating systems change. Cloud platforms change. Security vulnerabilities are discovered. Bluetooth behavior differs between devices. Users report unexpected behavior. Clinical workflows evolve.

IEC 62304 treats maintenance as a core process, not an afterthought. The standard's introduction explicitly notes that many field incidents are related to service or maintenance, including inappropriate updates and upgrades.

For the wearable monitor, maintenance may involve:

• app updates for new iOS or Android versions,
• firmware updates,
• cybersecurity patches,
• cloud infrastructure changes,
• changes to alert thresholds,
• fixes for synchronization issues,
• changes to third-party libraries,
• or end-of-life handling for unsupported phones.

Each change needs to be evaluated. Does it affect safety? Does it affect existing risk controls? Does it require regression testing? Does it change the software safety classification of any item?

IEC 62304 requires software changes, including changes involving SOUP, to be analysed for new potential causes of hazardous situations and for possible interference with existing risk controls.

This does not mean every bug fix becomes a major regulatory project. It means every change needs an appropriate level of assessment.

For connected devices, maintenance planning should also include cybersecurity monitoring. A dependency that was safe enough at release may later become vulnerable. A cloud configuration that was correct at launch may drift. A mobile operating system update may change permissions, notifications, or Bluetooth behavior.

Can coding start before everything is nailed down?

Yes. IEC 62304 does not require a rigid waterfall process.

This is one of the most useful points to understand. The standard does not prescribe a specific lifecycle model. It is the manufacturer's responsibility to select a lifecycle model and map IEC 62304 processes, activities, and tasks onto it.

The standard also recognizes that activities can overlap, interact, and be performed iteratively or recursively.

So yes, coding can start before every requirement is finalized. A team may prototype the Bluetooth connection, build the first version of the mobile app, or implement a cloud ingestion service while other requirements are still being refined.

But there is a condition: the work must become controlled, consistent, and traceable before release.

IEC 62304 guidance explains that non-waterfall lifecycles can produce outputs before all inputs are available. For example, a software item may be specified, classified, implemented, and verified before the full architecture is finalized. The risk is that later changes can invalidate earlier outputs, so configuration management and consistency between process outputs are essential.

In practical terms:

• Prototyping is allowed.
• Iteration is allowed.
• Agile development is allowed.
• CI/CD practices can be useful.
• Coding before every detail is known is allowed.

What is not allowed is uncontrolled development where no one can later show what was required, what was built, what was tested, what changed, and why the remaining risk is acceptable.

Research on DevOps in ISO 13485-regulated medical device environments reaches a similar conclusion: modern development approaches can be valuable, but their adoption requires proper anchoring in management, regulatory understanding, and iterative learning rather than simply importing consumer-software practices unchanged.

A good rule of thumb is:

IEC 62304 does not demand that everything happens in sequence. It demands that everything important is eventually connected, reviewed, verified, and controlled.

Is it allowed to use AI-generated code?

Yes - but not as an unmanaged shortcut.

IEC 62304 does not forbid the use of AI coding assistants. The standard does not prescribe a specific development method, documentation format, organizational structure, or lifecycle model. What it requires is that the manufacturer can show that the required software lifecycle activities have been performed in a controlled way, according to the software safety class.

That means AI-generated code is not automatically a problem. But it is also not automatically acceptable just because it compiles or looks correct.

The important question is not:

Was this code written by a human or suggested by AI?

The important question is:

Can we understand it, control it, verify it, trace it, maintain it, and show that it does not introduce unacceptable risk?

For medical device software, the responsibility always remains with the manufacturer and the development team. An AI tool cannot take responsibility for a requirement, a risk control, a design decision, a test result, or a released software version.

AI as a development tool is different from AI inside the product

There is an important distinction.

Using an AI assistant to help write source code is one thing. For example, a developer may ask an AI tool to suggest a parser, generate unit-test ideas, explain a Bluetooth API, or draft boilerplate code.

Using AI as part of the medical device function is something else. For example, a wearable health monitor may include an algorithm that estimates the probability of a cardiac event based on sensor data. In that case, AI is not just helping the development team. It is part of the product's medical functionality.

Regulators treat AI-enabled medical device functions as an important and evolving area. The FDA notes that AI and machine learning can transform healthcare, but also that the complex development, deployment, use, and maintenance of AI technologies benefit from careful management throughout the medical product lifecycle. The FDA has also published guidance and draft guidance specifically for AI-enabled medical device software functions.

This section focuses on the first case: AI used as a coding aid during development.

Treat AI-generated code like any other source code - then add extra caution

Once AI-generated code is accepted into the codebase, it should be treated as product source code. It needs to follow the same engineering process as code written manually:

• it should be reviewed,
• it should be traceable to requirements where relevant,
• it should follow the architecture and design,
• it should be tested,
• it should be under configuration management,
• and it should be included in risk analysis where it can affect safety.

IEC 62304 requires planning for development methods, tools, verification, configuration management, documentation, and risk management. For Class B and C software, the standard also requires control of supporting tools, items, or settings that could impact the medical device software. Amendment 1 also adds a requirement to identify categories of defects that may be introduced by the selected programming technology and to document evidence that such defects do not contribute to unacceptable risk.

That requirement is very relevant to AI-assisted coding.

AI coding assistants can introduce new types of development risk: code that looks convincing but misunderstands the requirement, incomplete error handling, insecure defaults, incorrect assumptions about APIs, hidden edge cases, or test cases that simply confirm the AI's own misunderstanding.

GitHub's documentation for Copilot makes the same practical point: generated suggestions must be reviewed and validated before acceptance, and generated code should be reviewed and tested carefully, especially in critical or sensitive applications.

A practical example: AI-generated code in a wearable health monitor

Imagine the team developing our connected wearable health monitor.

A developer asks an AI assistant to generate code for decoding Bluetooth packets from the sensor. The generated code looks clean, compiles, and passes a simple test. Can the team use it?

Yes - but not directly and not blindly.

The team still needs to check whether the code:

• implements the correct packet format,
• handles corrupted or incomplete packets,
• behaves safely when values are out of range,
• does not silently discard important sensor data,
• does not expose sensitive information,
• fits the architecture,
• and is covered by meaningful tests.

If the parser is only used for a non-critical dashboard view, the risk may be limited. If the same parser feeds an alert chain that can warn about a serious health condition, the bar is much higher. In that case, a defect could contribute to a hazardous situation, so the review, verification, and risk analysis need to reflect that.

This is the same mindset IEC 62304 uses throughout the software lifecycle: the required level of control depends on the software's safety relevance.

AI-generated code is not automatically SOUP

IEC 62304 defines SOUP as software that is already developed and generally available, not developed specifically for the medical device, or previously developed software where adequate development records are not available.

AI-generated source code that the team accepts, reviews, modifies, owns, and maintains as part of its own codebase is usually better treated as internally developed code, not as a separate SOUP item.

However, AI tools often suggest third-party libraries, package dependencies, copied patterns, or code that may resemble public source code. Those cases need extra attention.

If the AI suggestion introduces a third-party library, that library may need to be handled as SOUP or open-source software. If the suggestion matches public code, the team must consider licensing and IP implications. GitHub's documentation describes code reference features that can show when suggestions match publicly available code and display license information where available.

For medical device development, this is not just a legal detail. Unknown dependencies and unclear provenance can also affect maintainability, cybersecurity, and long-term support.

The main risks of AI-generated code

AI-generated code can be useful, but it can also fail in ways that are easy to miss.

Plausible but wrong code — The code may look correct but misunderstand the requirement
Missing edge cases — Sensor dropouts, invalid data, timing issues, and boundary values may be mishandled
Security weaknesses — Generated code may include insecure patterns or poor handling of sensitive data
Poor maintainability — Code that nobody fully understands becomes hard to change safely
Hidden dependencies — AI may suggest libraries or APIs without considering lifecycle control
Licensing uncertainty — Some suggestions may resemble public code with unknown or incompatible licenses
Weak tests — AI-generated tests may test the implementation rather than the actual requirement

GitHub's documentation warns that generated code may appear valid but may not be semantically or syntactically correct, may not reflect the developer's intent, and may not always be secure. It also recommends review, testing, secure coding, and code review practices.

A sensible policy for regulated development

A good rule is:

AI may assist the developer, but it must not bypass the development process.

For a medical device project, an AI coding policy could include:

1. Use approved tools only. The organization should decide which AI tools may be used, under what terms, and for which types of work.

2. Do not send sensitive information to public tools. Patient data, credentials, proprietary algorithms, unreleased product details, and confidential customer information should not be pasted into tools unless the legal, security, and contractual setup allows it.

3. Do not allow AI to commit directly to release branches. A human developer should own every accepted change.

4. Review AI-generated code like externally suggested code. The reviewer should understand what the code does, why it is needed, and how it affects the system.

5. Apply static analysis, dependency scanning, and security review. This is especially important for connected devices handling health data.

6. Check licensing and public-code matches where relevant. This is particularly important for larger generated snippets or common algorithm implementations.

7. Require stronger evidence for safety-related code. Code affecting alarms, clinical calculations, sensor interpretation, risk controls, or health-data integrity needs deeper verification than cosmetic UI code.

8. Document the approach in the development process. For Class B and C software, AI-assisted coding should be considered when defining development methods, tools, defect categories, review activities, and verification expectations.

This does not need to become bureaucratic. The goal is not to create paperwork around every autocomplete suggestion. The goal is to make sure AI assistance does not create uncontrolled software changes.

Can AI be used to generate tests and documentation?

Yes, and this is often one of the safer and more useful applications.

AI tools can help draft unit tests, suggest edge cases, explain legacy code, or create first versions of technical documentation. GitHub's documentation also describes generated unit-test suggestions as a possible use case.

But generated tests should not be accepted as proof just because they were generated. A test is only useful if it verifies the right thing.

For example, if an AI assistant generates tests for a heart-rate calculation function, the team still needs to check:

• whether the expected values are clinically and mathematically correct,
• whether boundary values are covered,
• whether invalid sensor input is covered,
• whether timing and missing-data behavior are covered,
• and whether the tests trace back to requirements and risk controls.

AI can help write the test. It cannot decide that the test evidence is sufficient.

The practical conclusion

AI-generated code is allowed in principle, but it must be used with engineering discipline.

For IEC 62304 projects, the safest position is:

AI-generated code may be used when it is reviewed, understood, verified, traceable where needed, controlled under configuration management, and assessed for risk like any other code.

For our wearable health monitor, that means AI might help the team move faster when writing a Bluetooth parser, a mobile-app view, a cloud API handler, or a set of unit tests. But the released medical device software still needs to meet the same requirements for safety, cybersecurity, maintainability, and evidence.

AI can be a useful assistant.

It should not become an undocumented developer, an unreviewed supplier, or an invisible shortcut around the quality system.

SOUP: third-party software, open source, and cloud components

Modern products rarely consist only of code written in-house.

The wearable monitor may depend on:

• a real-time operating system,
• a Bluetooth stack,
• a mobile operating system,
• encryption libraries,
• analytics frameworks,
• cloud SDKs,
• database engines,
• container images,
• monitoring tools,
• and open-source packages.

IEC 62304 calls this type of reused or externally developed software SOUP: software of unknown provenance. In simple terms, SOUP is software that was not developed specifically for the medical device, or software where the manufacturer does not have adequate records of the original development process.

SOUP is not forbidden. In fact, avoiding it completely is usually unrealistic.

But it must be controlled. The team needs to know what SOUP is used, which version is used, what role it plays, what known issues exist, and whether it can contribute to risk.

For example, an encryption library used for health data transmission is not just a technical dependency. A vulnerability or incorrect configuration could affect confidentiality, integrity, availability, and potentially patient safety.

For a connected wearable product, a useful SOUP record may include:

• component name,
• version,
• supplier or source,
• intended use,
• safety relevance,
• known anomalies or vulnerabilities,
• update strategy,
• license,
• and verification evidence for the intended use.

SOUP management is also closely connected to cybersecurity. If a vulnerability is discovered in a component used in the field, the manufacturer needs to know whether the product is affected and what action is needed.

Cybersecurity is not separate from safety

For connected devices, cybersecurity cannot be treated as a separate IT topic that is added at the end.

A security weakness can become a safety issue. If an attacker modifies health data, blocks alerts, changes configuration, drains the battery, or prevents clinicians from accessing relevant information, the medical function may be compromised.

MDCG cybersecurity guidance for medical devices explains that MDR and IVDR introduced stronger focus on cybersecurity risks. It also states that devices incorporating software, or software that is a device in itself, must be developed and manufactured according to the state of the art, taking into account development lifecycle, risk management, information security, verification, and validation.

The FDA's cybersecurity guidance similarly addresses cybersecurity device design, labeling, and documentation for premarket submissions, with the goal of helping ensure marketed medical devices are resilient to cybersecurity threats.

For our wearable health monitor, cybersecurity requirements may include:

• authenticated pairing,
• encrypted communication,
• protection against replay attacks,
• secure firmware updates,
• vulnerability monitoring,
• access control for clinicians,
• audit logging,
• cloud hardening,
• and a process for security patches.

IEC 62304 does not solve cybersecurity on its own. But its lifecycle processes, requirements, risk management, change control, configuration management, and maintenance activities provide a structure where cybersecurity can be handled systematically.

The practical message is simple: for connected medical devices, cybersecurity work should be connected to the same requirements, risk, verification, and maintenance framework as the rest of the software.

Traceability: the thread through the whole project

Traceability is one of the most important practical concepts in IEC 62304.

A safety-related requirement should not float around as an isolated statement. It should be connected to design, implementation, risk control, verification, and release evidence.

For example:

Hazardous situation: A clinician acts on incorrect oxygen saturation data.
Possible software cause: Data corruption during transmission or incorrect timestamp handling.
Risk control: Validate message integrity and mark stale data clearly.
Requirement: The system shall detect invalid or stale SpO2 data and prevent it from being displayed as current.
Design: Data packets include integrity checks and timestamps.
Verification: Tests cover corrupted packets, delayed uploads, and clock differences.
Release evidence: The tested software version and configuration are recorded.

This is what traceability makes possible. It lets a reviewer, auditor, developer, or product owner follow the reasoning from risk to requirement to implementation to evidence.

Research on traceability in medical software development highlights why this is challenging in modern continuous-development environments. Tools and workflows need to support developers without losing the documentation needed for regulatory purposes.

Traceability does not need to mean a giant spreadsheet that nobody trusts. It can be built into modern tools and workflows. The key is that the links are real, maintained, and useful.

Legacy software

Many medical device projects do not start from a blank page. A company may already have firmware, an app, a cloud platform, or an algorithm that was developed before IEC 62304 was fully implemented in the organization.

IEC 62304:2006+A1:2015 added specific handling for legacy software. The amendment introduced a route where manufacturers can assess feedback, perform risk management activities, conduct a gap analysis, close necessary gaps, and document a rationale for continued use.

For our wearable example, legacy software might be an existing mobile app framework or cloud service originally built for a wellness product. If the product is later repositioned for medical monitoring, the team cannot simply assume the old software is acceptable. It needs to be assessed in light of the new intended purpose and risk profile.

A legacy software assessment may ask:

• What version of the software is being reused?
• What objective evidence already exists?
• What is missing compared with IEC 62304 expectations?
• What field feedback or incident data exists?
• Which risk controls depend on the legacy software?
• What additional testing or documentation is needed?
• Is there a justified rationale for continued use?

Legacy software can be used, but it must be understood.

Common mistakes when applying IEC 62304

Starting documentation after the product is almost finished

It is possible to reconstruct documentation, but it is usually painful and less reliable. IEC 62304 works best when requirements, risks, architecture, tests, and changes are captured as the product evolves.

Treating cloud software as outside the device

For connected medical devices, cloud functions may be part of the medical device software or may influence the medical function. MDCG guidance is clear that software may be on a mobile phone, in the cloud, or on another platform. Location alone does not decide whether it is medical device software.

Confusing wellness features with medical claims

The technical product may look the same, but the intended purpose changes the regulatory picture. "Track your sleep quality" and "detect deterioration in a respiratory condition" are not the same claim.

Testing only the happy path

Connected systems fail in messy ways: poor connectivity, delayed uploads, low battery, expired certificates, invalid data, race conditions, API changes, or incompatible phones. These scenarios should be considered in risk analysis and verification.

Ignoring SOUP

Third-party components are part of the system reality. They need identification, version control, risk evaluation, known-issue monitoring, and update strategy.

Treating release as a button press

A release must be reproducible and controlled. The team needs to know exactly what was released, how it was produced, and which known anomalies remain.

Letting AI-generated code bypass review

AI-generated code should not be accepted simply because it looks plausible. It needs the same review, verification, configuration control, and risk-based scrutiny as other code.

What good IEC 62304 implementation feels like

Good IEC 62304 implementation should not feel like paperwork added on top of engineering. It should feel like disciplined engineering.

The team knows what the software is intended to do.
The team knows what could go wrong.
The architecture reduces the chance that failures spread.
Requirements are testable.
Risk controls are verified.
Third-party software is understood.
Changes are reviewed.
Releases are reproducible.
Problems are tracked and trended.
Maintenance is planned.

For connected IoT medical devices, this discipline is not just about passing an audit. It helps build products that can be trusted over time, even as phones, networks, cloud platforms, cybersecurity threats, and clinical expectations continue to change.

Final thoughts

IEC 62304 can look intimidating at first. It contains many processes, activities, and documentation expectations. But the underlying idea is straightforward:

Develop medical device software in a controlled, traceable, risk-based way - and keep it controlled throughout its life.

For a smart wearable health monitor, that means more than writing good firmware or building a polished app. It means understanding the intended medical purpose, identifying what could harm the user or patient, designing the system to control those risks, verifying that the controls work, and managing updates long after the first release.

The standard does not prevent modern software development. It does not force a strict waterfall process. It does not ban open source or cloud services. It does not require every component to be treated as equally critical. It also does not forbid AI-assisted coding.

It asks for something more practical: know what you are building, know why it is safe enough, and keep the evidence to prove it.

At Svep, this is how we prefer to approach medical device software: combine strong embedded, mobile, cloud, and connectivity engineering with the discipline needed for regulated development. The goal is not to slow innovation down. The goal is to make sure innovation is safe, maintainable, and ready for the real world.