5 EU MDR Medical Device Software (MDSW) Requirements

EU MDR defines medical device software (MDSW) as a software with medical purpose, whether standalone or embedded in a device. MDSW is regulated as an active medical device. Its classification is primarily determined by Rule 11 of Annex VII. Most diagnostic or therapeutic software are placed in Class IIa or higher depending on the risk of harm. Additionally, MDSW manufacturers must demonstrate compliance with General Safety and Performance Requirements, covering risk management, usability, cybersecurity, and lifecycle rigor. Moreover, technical documentation should be robust and per EU MDR requirements. Thus, medical device software development under MDR requires a risk-driven, standards-based, and fully documented approach. This is vital to ensure patient safety, performance, and regulatory approval.

What is medical device software (MDSW) under EU MDR?

Software that is intended to be used, alone or in combination, for a medical purpose as specified in the definition of a “medical device” in EU MDR is a medical device software (MDSW). The term “Software as a Medical Device” (SaMD) is not explicitly used in EU MDR. Instead, the regulation and guidance documents use medical device software (MDSW). We have highlighted some of the key elements of MDSW.

• Medical purpose: The software must be intended for diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation of disease, injury, or disability.
• Independence: MDWS can be standalone (installed on general computing platforms like smartphones, PCs, or cloud) or embedded in a hardware medical device.
• Active device: MDR states that medical device software is considered an active device because it processes input data and generates output data.

Examples: The following software are within the scope of MDSW: imaging analysis software that detects tumors, apps calculating insulin dosage, software monitoring vital signs and alerting clinicians, etc.

Therefore, MDSW under EU MDR is any software with a medical purpose, whether standalone or embedded, and it is regulated as a medical device. Notably, MDSW must undergo classification under Rule 11, comply with General Safety and Performance Requirements, and follow standards, such as IEC 62304, for lifecycle processes. Additionally, manufacturers must prepare a technical file with risk management, usability, cybersecurity, and clinical evaluation evidence.

Classification of medical device software (MDSW) under EU MDR

Under the EU MDR, medical device software (MDSW) is classified primarily using Rule 11 of Annex VIII.

1. Rule 11 of MDR Annex VIII for medical device software classification

• Class IIa: Software providing information used for diagnostic or therapeutic decisions or used for monitoring physiological processes are classified as IIa.
• Class IIb: If the software information-based decisions could cause serious deterioration of health or require surgical intervention, the MDSW will be classified Class IIb.
• Class III: If the software information-based decisions could cause death or irreversible deterioration of health, the MDSW will be classified Class III.
• Class I: All other software not covered above.

2. MDCG 2019-11 guidance

The Medical Device Coordination Group (MDCG) has clarified how to apply Rule 11. Medical purpose is key, i.e., only software with a medical intended use qualifies as MDSW. Examples of MDSW include diagnostic imaging software, apps calculating drug dosages, monitoring tools for chronic diseases. Examples of non-MDSW software are general wellness apps, administrative hospital software, fitness trackers without medical claims.

3. Factors influencing medical device software (MDSW) classification

• Intended purpose: Defined by the manufacturer in labeling and instructions.
• Impact of malfunction: Severity of harm if the software fails.
• User type: Professional vs layperson use can affect risk profile.
• Integration: Whether software operates independently (SaMD) or as part of a device (SiMD).

Therefore, most diagnostic/therapeutic software is at least Class IIa. Furthermore, high-risk apps (e.g., oncology decision support) often fall into Class III. Notably, Class I software is rare, usually limited to low-risk supportive tools. Many software developers underestimate classification level. However, notified bodies scrutinize Rule 11 classifications closely. Hence, manufacturers must justify risk assessments with traceability and clinical evidence.

Higher classes require extensive technical files, risk management, and clinical evaluation. Thus, manufacturers must carefully document intended use, risk analysis, and justification for classification to satisfy regulators.

GSPRs requirements for medical device software (MDSW)

General safety and performance requirements (GSPRs) demand that medical device software be safe, effective, reliable, and secure throughout its lifecycle.

1. General principles: The medical device software (MDSW) must achieve its intended purpose without compromising patient safety. Requirements apply from design and manufacture to post-market surveillance. Medical device software development must follow current best practices (e.g., IEC 62304, ISO 14971).
2. Design and manufacturing requirements: Identify hazards, assess risks, and implement mitigations (ISO 14971 alignment).Interfaces must minimize user error (IEC 62366-1).Software must perform consistently and reliably. Additionally, protection against unauthorized access, data breaches, and integrity loss (MDCG 2019-16 guidance) is vital. Furthermore, safe integration with other devices, platforms, and operating systems is required.
3. Requirements specific to software: Repeatability, reliability, and consistent performance are necessary. Fault tolerance is required to reduce risks in case of single-point failures. Medical device software development must follow lifecycle, verification, and validation principles. Updates and patches must be controlled and documented. Encryption of data at rest and in transit is necessary. Furthermore, post-market monitoring of vulnerabilities is required.
4. Documentation and evidence: In the technical file, manufacturers are required to provide software architecture and design specifications as well as verification and validation reports (unit, integration, system testing). If software impacts diagnosis or therapy, clinical evaluation evidence will be required. Post-market surveillance plan for continuous monitoring and updates.
5. Information supplied to users: Labeling and IFU must specify intended purpose and limitations, compatible platforms and restrictions, update and patch management, and warnings about risks and contraindications.

Standards applicable to medical device software development

• IEC 62304: Lifecycle processes for medical device software (planning, design, verification, maintenance).
• ISO 13485: Quality management system framework for medical device software.
• ISO 14971:2019: Risk management for medical devices.
• IEC 82304-1: Health software safety and security.
• ISO/IEC 27001: Information security management; relevant for connected devices

Technical documentation requirements for medical device software (MDSW) under EU MDR

1. General documentation: The technical file must cover device description and specification, intended purpose, indications, target population, and user profile. Software type (standalone SaMD vs embedded SiMD) has to be mentioned. Information for safety and performance should cover risk management file (ISO 14971), usability engineering file (IEC 62366-1), and cybersecurity risk assessment (MDCG 2019-16). Design and manufacturing information section should cover software lifecycle documentation (IEC 62304), development plan, requirements, architecture, design, implementation, verification and validation evidence. Additionally, a GSPR checklist mapping each requirement to evidence will be required. Labeling and IFU along with warnings, contraindications, and limitations have to be provided.
2. Software specific documentation: This section should include software safety classification (IEC 62304: A, B, C), verification and validation reports, configuration management, and version control. Procedures for bug fixes, patches, and upgrades will be required.
3. Risk and cybersecurity documentation: A robust risk management file covering hazards, mitigations, and residual risks will be required. Cybersecurity documentation file covering secure design principles will be necessary. Post-market surveillance monitoring anomalies, vulnerabilities, and user feedback is necessary.
4. Clinical evaluation: If the software claims diagnostic/therapeutic benefit, a clinical evaluation section will be required. The equivalence claims must be justified with comparative analysis.

Thus, medical device software (MDSW) under the EU MDR is rigorously regulated owing to its direct impact on patient safety and clinical outcomes. Traceability, cybersecurity vigilance, and post-market surveillance are necessary throughout the software lifecycle. Hence, EU MDR MDSW requirements are extensive. Need help understanding the EU MDR medical device software regulatory requirements? Email at [email protected] or call/Whatsapp on 9996859227 for guidance. Additionally, our team will be more than happy to help you secure the necessary approvals for marketing your medical device software in EU. Furthermore, we provide document preparation support.