Embedded Software in Medical Devices: Regulatory Fundamentals

Embedded and Standalone Software as Medical Devices

Embedded Software (SW) is an integral component of a medical device (hardware) and serves to control or influence its function, often possessing its own medical purpose. It differs from Standalone Software (SaMD – Software as a Medical Device), which functions independently as a medical device (e.g., an app for patient data analysis). Both Embedded SW and Standalone SW that pursue a medical purpose fall under the definition of a medical device or an in vitro diagnostic device and must meet the requirements of the MDR or IVDR, respectively, to be placed on the market in the EU. The intended purpose of the product, as defined by the manufacturer, is the fundamental criterion for qualification as a medical device.

The Regulatory Significance of the Intended Purpose

The intended purpose defines the specific medical goals for which the software (or the device containing the software) was developed, e.g., for diagnosis, prevention, monitoring, treatment, or alleviation of disease or injury. This is the decisive factor in determining whether the product qualifies as a medical device at all and how it must be classified.

CE Declaration of Conformity and Regulatory Requirements

The CE marking is a mandatory sign affixed by the manufacturer to declare that the medical device meets the applicable requirements of the MDR or IVDR. It is not a “certificate” in the traditional sense, but rather a declaration of conformity issued by the manufacturer itself.

The CE Conformity Assessment Process

To issue the EU Declaration of Conformity and affix the CE mark, the manufacturer must undergo a comprehensive conformity assessment procedure, which includes the following steps:

1. Qualification and Classification: It must be clarified whether the product is a Medical Device (MD) or an In Vitro Diagnostic Device (IVD) and what risk class applies (Classes I, IIa, IIb, III for MD; Classes A, B, C, D for IVD).
2. Quality Management System (QMS): The manufacturer must establish and maintain a QMS according to ISO 13485. This is the basis for all processes, including the software lifecycle.
3. Technical Documentation: Creation and maintenance of complete technical documentation that demonstrates conformity with the General Safety and Performance Requirements (GSPR) of Annex I of the MDR/IVDR.
4. Involvement of a Notified Body: For products in Classes IIa, IIb, III (MDR) or B, C, D (IVDR), a Notified Body must be involved in the conformity assessment procedure. Their identification number must be appended to the CE mark on the product.
5. Risk Management: Implementation and application of a risk management process according to ISO 14971 throughout the entire product lifecycle.

The EU Declaration of Conformity is the formal document by which the manufacturer officially confirms that the product (including the Embedded SW) has met all applicable regulatory requirements.

Software Regulation and Harmonised Standards

Harmonised standards are of particular importance for Embedded Software:

• IEC 62304: Defines the requirements for the Medical Device Software (MDSW) lifecycle process, from development to maintenance. It is central to demonstrating the conformity of software development.
• ISO 14971: Requires a risk management process to be applied to the software to assess and control potential hazards (e.g., SW malfunctions) and the resulting risks.
• IEC 62366-1: Addresses Usability Engineering and the minimization of risks arising from faulty or difficult operation (including the software user interface).
• MDCG Guidance Documents: Specific guidance from the Medical Device Coordination Group, such as MDCG 2019-11 on software qualification and classification, help in interpreting the regulations.

Classification: Not Considered Non-IVD or Non-MDR

The assumption that Embedded Software in a medical device could automatically be considered “Non-IVD” or “Non-MDR” is misleading and incorrect if the overall device or the software itself serves a medical purpose.

Medical Device (MDR) vs. In Vitro Diagnostic Device (IVDR)

Classification depends on the type of device and its intended purpose:

• MDR (Medical Device): Applies to most medical devices used directly on or in the human body (e.g., imaging devices, monitors, active implants). The Embedded SW in this case controls the hardware of the MDR device or provides medically relevant information.
• IVDR (In Vitro Diagnostic Device): Applies to devices, reagents, and software used for the in vitro examination (outside the body) of human body samples to provide information about physiological or pathological states (e.g., laboratory equipment for blood analysis). The Embedded SW here would control the analysis processes or interpret the results.

Embedded SW is, by definition, a part of a medical device or IVD. It falls under the same class as the product it controls or whose application it influences (Art. 10 Para. 2 MDR). It is therefore inseparable from the MDR or IVDR conformity of the overall device.

Why Classification is Difficult

Rule 11 of the MDR for software classification is complex. If the Embedded Software additionally pursues an independent medical purpose alongside its control function (e.g., image analysis for diagnosis), it must be classified separately according to Rule 11. If this software class is higher than that of the hardware device, the entire product must be classified into the higher class. This assumes of a “Non-MDR” status impossible, as the software directly determines the regulatory class and thus the requirements for the overall product.

Labelling

The labelling requirements for Embedded Software are indirect, as the software itself is usually not labelled as a separate, physical product, but rather as part of the entire medical device.

The MDR and IVDR require that the labelling and instructions for use contain all relevant information (Annex I, Chapter III). This includes:

• CE Mark: On the device and/or the sterile packaging, if applicable with the Notified Body number.
• UDI (Unique Device Identification): Product identification must also be assigned for software according to MDCG 2018-5 and specified on the labeling/instructions for use.
• Software Identification: The specific software version must be clearly identifiable (e.g., on the splash screen or in the system settings of the device) to ensure unambiguous traceability.
• Intended Purpose: Must be clearly communicated.

Since the Embedded SW is part of the product, the labelling requirements primarily apply to the overall product but must include the software version as critical information for safety and traceability.

The Specific Challenge of Embedded Software

Embedded Software is often considered more difficult to manage than standalone software, mainly due to its deep entanglement with the hardware and the physical product lifecycle.

1. Inseparable Coupling: Changes to the Embedded SW almost always require a re-evaluation of the entire hardware device, as the device’s function is directly controlled by the software. With Standalone Software, the separation of hardware (e.g., a standard smartphone) and software is often simpler.
2. Validation and Verification: The validation of the Embedded SW (proving that it fulfils its purpose) cannot take place in isolation but must be carried out in the context of the entire device. According to IEC 62304, the Embedded SW itself is only verified, while the entire medical device containing the Embedded SW is validated.
3. Hardware Dependency: The software must be closely tailored to specific hardware components (microcontrollers, sensors, actuators). This increases complexity during updates or the correction of software errors, as these may require a renewed review of the hardware-software interaction.
4. Legacy Systems: Older medical devices with Embedded SW that were approved under the previous Directive (MDD) must now be transitioned to the stricter requirements of the MDR, which can represent enormous effort for software deeply integrated into the hardware.
5. Cybersecurity: Embedded systems are increasingly networked and thus vulnerable to cyberattacks. The MDR demands robust security measures. Implementing cybersecurity in resource-constrained embedded systems is often a greater challenge than in modern standalone platforms.

Endnote

Embedded Software in medical devices is subject to the full regulatory requirements of the MDR and IVDR, as it is an integral part of a medical device and directly affects its safety and performance. Assuming a “Non-MDR” status is ruled out, as the software can determine the classification of the overall device.

Managing the CE Declaration of Conformity requires a strict, documented lifecycle process (IEC 62304) and comprehensive risk management (ISO 14971), embedded within a certified QMS (ISO 13485). The deep-rooted dependence on the hardware and the necessity of validating the overall system are the main reasons why the management of Embedded Software in the medical context is considered particularly complex

Disclaimer. The views and opinions expressed in this article are solely those of the author and do not necessarily reflect the official policy or position of Test Labs Limited. The content provided is for informational purposes only and is not intended to constitute legal or professional advice. Test Labs assumes no responsibility for any errors or omissions in the content of this article, nor for any actions taken in reliance thereon.