Building Compliant IEC 62304 Embedded Software for Medical Devices

Why IEC 62304 is the cornerstone of UK medical software compliance

As we’ve seen across the board in this series centred on medical device compliance, integration and privacy, a persistent myth in product development is that software is somehow a secondary layer added to the ‘real’ hardware. The MHRA (Medicines and Healthcare Products Regulatory Agency) doesn’t see it that way, nor do the Approved Bodies designated to assess product conformity. Alongside clinical efficacy (i.e., intended use), safety and reliability are arguably the most important aspects of a medical device’s functionality, and IEC 62304 embedded software is the standard that ensures compliance throughout its lifecycle.

In the UK, it operates as a designated standard under the Medical Devices Regulations 2002; the regulatory framework governing medical devices in Great Britain since January 2021. The MHRA works closely with BSI (the UK national standards body) to maintain IEC 62304 as the primary mechanism by which manufacturers demonstrate that their software development processes meet regulatory requirements.

The standard applies to software that is either embedded within a medical device (software in a medical device – SiMD) or constitutes a standalone Software as a Medical Device (SaMD). If your product has a microcontroller making clinical decisions, for example, processing ECG data, controlling an infusion pump, interpreting wireless sensor readings from a BLE-connected wearable, IEC 62304 applies to every line of code running on it.

What the standard doesn’t do is tell you how to write software. It tells you what your process must demonstrate: that software was planned, designed, implemented, tested, and maintained in a controlled and documented manner proportional to the risk it presents to patients. That distinction — process over prescription — is what trips up most engineering teams encountering the standard for the first time.

For teams already working within the wireless medical device ecosystem described in earlier posts in this series (designing BLE connectivity, integrating wireless charging under IEC 60601, or embedding privacy-by-design principles), IEC 62304 is the connective tissue that makes the software layer of those systems auditable. It is, in that sense, unavoidable.

The UK regulatory landscape for medical devices

Understanding IEC 62304’s role in the UK requires understanding the regulatory environment it sits within, which is no simple feat, given that the landscape is actively evolving.

Great Britain (England, Wales, Scotland) is now regulated under the UK MDR 2002, with the MHRA as the sole regulatory authority. Devices require MHRA registration and must carry the UKCA conformity assessed mark for new products entering the GB market. CE-marked devices retain transitional acceptance (generally until June 2028 for higher-risk devices certified under the EU MDD, and June 2030 for IVDs), but these windows are closing, and the MHRA has been clear that manufacturers should not treat them as a long-term strategy.

Northern Ireland is different. Under the Windsor Framework, Northern Ireland continues to follow EU medical device regulations. CE marking and EU MDR 2017/745 requirements remain necessary for the NI market. For teams designing products for UK-wide deployment, this creates a dual-track consideration. It must be resolved at the architecture stage, not at submission.

The MHRA’s Software and AI as a Medical Device Change Programme, launched in 2021 and updated with a roadmap published in December 2024, is the most consequential ongoing regulatory development for embedded software teams. The programme is explicitly designed to ensure IEC 62304 and other standards remain fit for purpose in the context of modern software development, SaMD, and AI as a medical device (AIaMD). The MHRA has stated that new guidance will not replace IEC 62304 but will identify areas where current best practice may not yet meet regulatory expectations. In practice, this means the standard is the floor, not the ceiling.

For teams building connected medical devices for international markets (UKCA for GB, CE for EU and Northern Ireland), it is worth noting that while the standards are practically convergent (both reference IEC 62304), the regulatory frameworks around them differ in meaningful ways. The MHRA is actively developing an international reliance framework that, from 2027 onwards, may allow devices already approved by Comparable Regulator Countries (CRCs), such as the FDA, the EU, Health Canada, or the TGA, to access the GB market through a streamlined route. SaMD is currently excluded from this framework, reinforcing the importance of a properly documented UK-specific compliance position for software-containing devices.

The three-class model: Getting safety classification right

Everything in IEC 62304 flows from a single decision: the safety classification of your software.

The standard defines three classes based on the severity of harm that could result from a software failure:

• Class A: Software that cannot directly cause a dangerous scenario – often because it does not control a physical device or because robust safety mechanisms are in place, and no injury or damage to health is possible. For example, a hospital inventory management system, or a simulation tool to help doctors learn new techniques.
• Class B: This applies to devices where software failure can lead to hazardous situations, but the potential harm is considered reversible or non-permanent. For example, sleep apnea monitoring apps, diagnostic visualisation tools or a general health logging app where software failure could lead to injury, but not serious injury or death.
• Class C: Software that directly manages patient safety and controls/influences therapeutic devices, where failure could result in death or permanent severe harm. For example, the operating system inside a ventilator used to keep a patient alive, or an automated insulin pump, where an incorrect calculation could lead to fatal hypoglycemia.

The classification is derived from the risk analysis conducted under ISO 14971 and must be revisited whenever the intended use, operating environment, or architectural boundary changes. A Class A software item that is later modified to take part in a safety-critical function must be reclassified, and that reclassification triggers the full Class B or C lifecycle obligations retrospectively.

Under UK MDR 2002 and UKCA conformity assessment, Approved Bodies will scrutinise software safety classification as a primary review point. The MHRA’s guidance on SaMD qualification and classification, developed as part of the Change Programme mentioned above, reinforces that the intended purpose statement, which drives device classification, must be defined with sufficient specificity to make software safety classification defensible.

For connected medical wearables (i.e., the kind that integrate BLE, wireless charging, and biometric sensing discussed earlier in this series), most embedded firmware will fall into Class B or Class C. A glucose monitoring algorithm driving a dosing alert is Class C. A display rendering battery status is Class A. Both can coexist within the same physical device, which is where the standard’s concept of software items becomes operationally important.

Decomposition hierarchy of IEC 62304 embedded software: Systems, items, and Units

Software decomposition is the process of breaking down complex, high-level software systems into smaller, more manageable parts – such as systems, items, and units to improve maintainability and comprehension. This hierarchy often follows the IEC 62304 standard, which structures software into architectural components, moving from high-level subsystems down to individual, non-decomposable units: software system → software items → software units.

A software system is the totality of software in scope. Software items are logical subdivisions—you define their boundaries. Software units are the lowest-level testable components. The standard requires different levels of rigour at each layer, but the critical engineering discipline it enforces is that these boundaries must be defined, documented, and maintained.

For embedded firmware on a microcontroller (e.g., an nRF52-series SoC handling both BLE communication and sensor fusion for a Class C cardiac monitor), this decomposition might look like:

• Software System (Top Level): The entire software product or a distinct, high-level subset of the device software (I.e., device firmware v2.x)
• Software Items:Subdivisions of the software system that can be further decomposed, e.g.,BLE stack integration layer / Sensor acquisition module / Clinical algorithm module / Power management module
• Software Units (Lowest Level): The smallest part of the software (e.g., an individual file, function, method) that cannot be further decomposed. Software units are the primary focus for detailed design and unit testing.

The decomposition determines what gets unit-tested, what gets integration-tested, what gets reviewed, and what gets change-controlled. For Class C, every software unit requires documented unit testing. For Class B, the requirement is less prescriptive, but Approved Body expectations have hardened over time.

SOUP: The Hidden Compliance Surface

For medical device manufacturers, product development is a constant balancing act: leveraging proven third-party software solutions to accelerate development and reduce costs, while maintaining control over patient safety and regulatory compliance.

If IEC 62304 has a single area where teams consistently underestimate the workload, it is SOUP (software of unknown provenance). The standard defines SOUP as any software item not developed under a lifecycle compliant with IEC 62304, risk management compliant with ISO 14971 or for which the development record is insufficient. In practice, for embedded medical device firmware, SOUP includes:

• Third-party BLE stacks (Nordic SoftDevice, Zephyr BLE subsystem).
• RTOS kernels (FreeRTOS, Zephyr, ThreadX).
• Cryptographic libraries (Mbed TLS, wolfSSL).
• USB middleware, FAT file systems, CMSIS-DSP libraries.
• Any open-source component pulled into the build.

The MHRA’s Software and AI Change Programme specifically flags open-source code as an area requiring regulatory clarity around manufacturer responsibility. If open-source code is integrated and subsequently modified, the entity that makes the modification may assume manufacturer responsibilities under the UK MDR 2002. This is not a theoretical concern, but a live issue for teams building on community-maintained embedded frameworks. The SOUP register is the mechanism through which this liability is made visible and managed.

The standard does not prohibit SOUP. It requires that you identify it, evaluate the risks its use introduces, specify the functional and performance requirements you depend on, and document the testing you have performed to verify it meets those requirements in your specific context.

This matters particularly for the wireless integration scenarios covered in earlier posts in this series. The BLE stack handling encrypted data transmission in a medical wearable is almost certainly SOUP. The IEC 60601-1-2 EMC constraints shaping the RF environment interact with the behaviour of that stack. The privacy-by-design obligations explored in the last post depend on that stack’s correct implementation of pairing and bonding procedures. If you haven’t evaluated your SOUP against these functional requirements and documented the evaluation, you have a gap — not just in IEC 62304 compliance, but in the integrated risk picture.

Medical software traceability chain: The spine of the technical file

Medical device software traceability links every software artefact, i.e., requirements, risks, design, code, and tests, ensuring compliance with IEC 62304 and ISO 14971 standards. This chain, often managed via a Traceability Matrix, links user needs to validation tests, connects software builds to specific device serial numbers for post-market surveillance, and demonstrates a closed-loop system that ensures software is safe and performs as intended.

IEC 62304 requires bidirectional traceability between software requirements, software architecture, software items, and the tests that verify them. For UKCA conformity assessment, this traceability chain is a primary review target for UK Approved Bodies. The chain typically runs:

1. Requirements to Risks: Initial user needs and regulatory requirements are linked to safety risk management (ISO 14971), showing which risk controls have been implemented.
2. Requirements to Design & Code: Each requirement is traced to specific software architecture, detailed design documents, and, finally, source code modules (IEC 62304).
3. Design to Verification & Validation (V&V): Each code unit and functional requirement must be linked to a specific test case (unit test, integration test, or system test), ensuring complete verification coverage.
4. Release and Configuration Management: Traceability records software versions, builds, patches, and configurations, ensuring that a specific software version is linked to the hardware it was used on

For a Class C device, this chain must be complete and verifiable. A software requirement with no corresponding test is a gap. A software unit that cannot be traced to a requirement is suspect code and either shouldn’t be there or indicates a missing requirement.

The inextricable link between software architecture and risk

IEC 62304 requires a documented software architecture for Class B and Class C systems. The architecture must be sufficiently detailed that the decomposition into software items is justified and the interfaces between items are defined. Every architectural decision carries inherent risks that can impact performance, security, scalability, and success (i.e., a device that performs its intended function efficiently). A risk-driven approach to device architecture focuses on identifying potential failures early in the development lifecycle when they’re cheaper and easier to fix.

This is where IEC 62304 formally intersects with ISO 14971. If the risk analysis identifies that an incorrect algorithm output could lead to patient harm, risk control may be implemented in software, such as a bounds check, a redundant calculation path, or a watchdog. That software risk control must be incorporated into the architecture, implemented in a traceable software item, and tested to demonstrate that it functions correctly under the failure conditions it addresses.

For wireless medical devices, architecture decisions carry particular risk implications. A software architecture processing safety-critical sensor data over a wireless link must address what happens when that link is absent or degraded. The fallback behaviour (fail-safe state, alarm, data buffering) is a safety-relevant architectural decision that requires documentation, risk assessment, and testing. The interaction between the wireless stack (likely SOUP), the application layer, and the safety-critical algorithm is an interface that requires explicit definition.

Version Control, Change Management, and Configuration Management

In the medical device industry, Version Control, Change Management, and Configuration Management are regulatory requirements that ensure every modification to a product is documented, safe, and traceable.

• Configuration Management (the umbrella) is the comprehensive system for maintaining the consistency of a product’s performance and functional attributes throughout its lifecycle.
• Change Management (the process)is the formal procedure used to evaluate and approve modifications to a released product or process.
• Version control (the foundation) is the technical mechanism for tracking specific changes to individual artefacts (code, documents, drawings).

IEC 62304 requires a configuration management system that identifies all software items under control, controls changes to them, and enables the reproduction of any prior release. For embedded firmware, this means the version control system (Git being the norm) must be used in a controlled manner: branching strategy, commit discipline, release tagging, and a change control process that determines whether a change requires re-verification of dependent items.

Change impact analysis is a specific obligation under the standard. When a software unit changes, you must assess which other units depend on it, and whether those dependencies require regression testing. For teams using automated test infrastructure — unit test suites running against every commit — this is manageable. For teams relying on manual testing, change management becomes the primary bottleneck to iteration speed.

The post-market dimension has become significantly more demanding under the June 2025 UK PMS regulations. Firmware updates to UKCA-certified medical devices are not routine maintenance releases: safety-relevant changes require a PMS-aligned change assessment, and depending on the nature of the change, may trigger MHRA vigilance reporting obligations or require Approved Body notification. Building that process into the SDLC from day one is considerably less painful than retrofitting it when the first field update is needed.

Verification, Validation, and the Testing Hierarchy

IEC 62304 distinguishes verification (did we build it right?) from validation (did we build the right thing?), and requires both. For embedded medical device software, this translates to:

• Software unit testing — each software unit is tested against its specification, with documented test cases, test procedures, and results.
• Software integration testing — software items are tested together to verify that interfaces behave as defined.
• System testing — the integrated software system is tested against system-level requirements, typically in the target hardware environment.
• Usability/validation — confirmation that the software meets the clinical needs it was designed to address, usually within the broader design verification and validation (V&V) activity under IEC 60601-1-6 and relevant usability standards.

For Class C firmware, the unit testing obligation is specific: every unit must be tested. For Class B, the standard allows more flexibility, but UK Approved Body expectations have aligned with the tougher end of the interpretive range. Test coverage metrics (branch coverage, statement coverage, MC/DC for the most safety-critical algorithms) are not explicitly mandated by IEC 62304 but are expected by MHRA technical reviewers for Class C devices. Demonstrate that testing is adequate, not just that testing occurred.

Where IEC 62304 fits the UK regulatory picture

IEC 62304 sits within a web of intersecting standards and UK-specific regulatory obligations that connected medical device teams need to hold simultaneously:

• UK MDR 2002 (as amended) is the primary legislation. UKCA conformity assessment against this framework is the route to GB market access, and IEC 62304 compliance is the principal mechanism for demonstrating that software meets UK MDR essential requirements for safety and performance.
• MHRA Software and AI as a Medical Device Change Programme is actively evolving the regulatory expectations that sit above IEC 62304. Teams building devices now should be reading the Change Programme roadmap updates, not just the standard.
• June 2025 Post-Market Surveillance Regulations have introduced mandatory PMS documentation, vigilance reporting timelines, and PSURs for higher-risk device classes. Software update management and anomaly tracking are within scope.
• MHRA Cybersecurity guidance (developed with NCSC) requires cybersecurity controls to be traceable software requirements — particularly relevant for any device with a wireless interface, which describes the entire connected medical device category discussed in this series.
• ISO 14971 (risk management) provides the risk analysis that drives software safety classification and identification of software-implemented risk controls. Without a robust ISO 14971 file, the IEC 62304 software safety classification is indefensible.
• Northern Ireland divergence requires that products sold into the NI market meet EU MDR 2017/745 requirements, which reference IEC 62304 within a different conformity assessment process. For dual-market products, the standards are convergent — but the regulatory submissions and Approved Body/Notified Body routes are distinct.

Teams building for international markets (GB + EU + potentially FDA) should note that IEC 62304 compliance is broadly recognised across all three jurisdictions, though the surrounding documentation requirements differ. The MHRA’s planned international reliance framework, expected to become active from 2027, explicitly excludes SaMD from the streamlined route, meaning software-containing devices will continue to require substantive UK-specific regulatory engagement regardless of FDA or TGA status.

Common failure modes in achieving IEC 62304 compliance

The most common mistakes and pitfalls that prevent teams from achieving IEC 62304 compliance are instructive precisely because they are not exotic:

1. Late engagement with the MHRA framework. Teams that treat IEC 62304 compliance as documentation assembled before submission, rather than a process followed during development, produce files that are technically extensive but unconvincing. Under UKCA assessment, UK Approved Bodies review the development process, not just its artefacts.
2. Inadequate Software Safety Classification: Teams often misclassify software as Class A (lowest risk) when it should be Class B or C, leading to insufficient documentation and testing. The class should be based on the potential harm, not the functionality.
3. Lack of End-to-End Traceability: Inability to demonstrate a clear link from software requirements to architecture, detailed design, implementation, and finally to verification testing (and back) is a common failure
4. Ignoring the Change Programme. The MHRA’s Software and AI Change Programme is not background reading. It is actively shaping what Approved Body reviewers expect to see in technical files, particularly around intended purpose specificity, cybersecurity traceability, and AI/ML governance. Teams not tracking it are building to a standard that is moving under them.
5. Disconnected Risk Management: Failing to integrate IEC 62304 with ISO 14971, specifically in not connecting software-level risks directly to system-level hazards. Risk controls must be verified by testing and documented.
6. PMS is treated as a post-submission concern. Under the June 2025 regulations, the PMS plan is a pre-market requirement for MHRA registration, not an afterthought. For software-containing devices, the PMS plan must address how firmware updates are managed, how anomalies are tracked, and how safety-relevant changes trigger the appropriate vigilance pathway.
7. SOUP was managed as an afterthought. The SOUP register assembled from library manifests the week before submission is a liability document, not a managed asset. Build it alongside the architecture.

Final Thoughts: Software as the Integration Layer

Across the previous insights posts in this series, we have built up a picture of the technical obligations bearing on connected medical device development in the UK: BLE architecture and its clinical-grade reliability requirements; wireless charging design within IEC 60601’s leakage current and EMC constraints; the integrated wireless safety case under IEC 60601-1-2; and the privacy-by-design obligations that shape how patient data is handled from collection through to post-market. Obligations that sit alongside MHRA requirements and are reinforced by the ICO’s guidance on data protection in health tech.

IEC 62304 is the framework that makes the software layer of all those systems auditable and defensible under UK MDR 2002. The BLE stack is SOUP that must be managed. The privacy controls are software requirements that must be traced. Wireless safety-critical behaviour is an architectural decision that must be documented and risk-assessed. The firmware update process is both a change management obligation and, under the June 2025 PMS regulations, a vigilance consideration.

None of this should be treated as regulatory overhead. A software development process that meets IEC 62304 ( traceability, controlled change management, systematic testing, SOUP evaluation) is simply good embedded software engineering, applied with the rigour that patient safety and the MHRA’s evolving framework jointly demand.

If you are at the architecture stage of a medical device, firmware and embedded systems development and need to establish an IEC 62304-compliant device, we’re here to help.