--- title: Essential Requirements vs. General Safety and Performance Requirements: What Changed from MDD to MDR description: The MDR replaced the MDD's Essential Requirements with General Safety and Performance Requirements (GSPRs) — here are the specific changes and what they mean for your compliance strategy. authors: Tibor Zechmeister, Felix Lenhard category: MDR Fundamentals & Regulatory Strategy primary_keyword: canonical_url: https://zechmeister-solutions.com/en/blog/essential-requirements-vs-gspr source: zechmeister-solutions.com license: All rights reserved. Content may be cited with attribution and a link to the canonical URL. --- # Essential Requirements vs. General Safety and Performance Requirements: What Changed from MDD to MDR *By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.* If you have any experience with the old MDD framework — or if you inherited documentation from a legacy device — you will encounter references to "Essential Requirements" (ERs). The MDR replaced these with "General Safety and Performance Requirements" (GSPRs) in Annex I. This was not a cosmetic rename. The content changed significantly, and understanding the differences matters for anyone transitioning documentation from MDD to MDR or building an MDR compliance strategy from scratch. Here is what changed, what was added, and what this means for your startup. ## What Were the MDD Essential Requirements? The MDD contained Essential Requirements in its Annex I. These were organized into general requirements and requirements for design and construction. The structure was relatively compact — about 13 sections covering general safety, design requirements for specific device types, and information supplied with the device . The ERs set out the fundamental safety and performance expectations for medical devices but left significant room for interpretation. Many requirements were broadly worded, allowing manufacturers considerable flexibility in how they demonstrated compliance. ## What Are the MDR General Safety and Performance Requirements? The MDR's Annex I is substantially more detailed. The three-chapter structure (General Requirements, Design and Manufacture Requirements, Information Requirements) covers the same ground as the MDD ERs but with more specificity, more sub-requirements, and several entirely new areas. Key structural differences: **More sections, more detail.** The MDR Annex I contains approximately 23 sections , compared to the MDD's approximately 13. The additional sections cover areas that the MDD either addressed superficially or did not address at all. **Explicit sub-requirements.** Where the MDD often stated a general principle, the MDR breaks it down into specific sub-requirements. For example, the MDD's general requirement for biological safety is expanded in the MDR to cover specific aspects of biocompatibility, including chemical, biological, and physical characterization of materials. **New areas covered.** The MDR added requirements for: - Software and electronic programmable systems (more detailed than MDD) - Devices connected to or incorporating networked systems (cybersecurity) - Devices intended for lay users (specific usability requirements) - Devices incorporating nanomaterials - Devices with a diagnostic or measuring function (expanded requirements) - Environmental and use condition considerations ## What Specific Requirements Were Added or Strengthened? ### Software Requirements (Sections 14 and 17) The MDD's treatment of software was minimal. The MDR dedicates specific sections to software requirements, reflecting the explosive growth of software-based medical devices since the MDD was written. Section 14 requires software to be developed according to the state of the art, taking into account development lifecycle, risk management, information security, verification, and validation. For software used on mobile computing platforms, manufacturers must consider the specific features of the platform and external factors related to use . This is a direct response to the rise of medical apps and cloud-based medical devices that did not exist when the MDD was drafted. ### Cybersecurity and Connected Devices (Section 17.4) The MDD had no explicit cybersecurity requirements. The MDR addresses this gap by requiring that devices incorporating electronic programmable systems, including software, and devices that are software themselves, be designed to ensure repeatability, reliability, and performance in line with their intended use. For networked devices, the MDR requires appropriate measures against unauthorized access . ### Benefit-Risk Determination (Sections 1–8) The MDD required an acceptable risk-benefit ratio but did not specify how to determine it. The MDR is more prescriptive, requiring a structured benefit-risk determination that considers: - The intended purpose and foreseeable misuse - The state of the art - Alternative solutions available - The intended patient population and user profile - The elimination or reduction of risks as far as possible without adversely affecting the benefit-risk ratio ### Devices with a Diagnostic Function (Section 14.2) For devices with a diagnostic function, the MDR requires sufficient accuracy, precision, and stability to achieve their intended purpose. Specifically, the MDR requires sensitivity and specificity to be determined, and any limitations in accuracy to be communicated to the user . The MDD was less specific about performance characterization for diagnostic devices. ### Lay User Requirements (Section 5) The MDR adds explicit requirements for devices intended for use by lay persons (non-professionals). These devices must be designed and manufactured to perform appropriately for their intended purpose taking into account the skills and the means available to lay users and the influence resulting from variation that can reasonably be anticipated in lay user's technique and environment . For startups building consumer-facing medical devices, this is significant. You must demonstrate that your device is safe and effective when used by untrained users in non-clinical settings. ### Environmental Considerations The MDR adds requirements for devices to consider the environmental conditions in which they will be used — transport, storage, operating conditions, including temperature, humidity, pressure, and exposure to light. The MDD had similar but less detailed requirements. ## How Does This Affect Your GSPR Assessment? If you are building your GSPR assessment from scratch (which most startups are), the expanded requirements mean: **More sections to address.** You must address every section and subsection of Annex I, not just the sections that were in the MDD. Even if a section does not apply to your device, you must document why. **More specific evidence needed.** Because the requirements are more detailed, your evidence must be more specific. "Compliant with biocompatibility requirements" is not sufficient — you must demonstrate compliance with each specific sub-requirement related to material characterization, biocompatibility testing, and residual risk evaluation. **New documentation areas.** If your device includes software, you need a documented software development lifecycle per IEC 62304. If your device connects to networks, you need cybersecurity risk analysis and mitigation documentation. If your device is used by lay persons, you need usability engineering evidence per IEC 62366-1 with specific attention to lay user scenarios. ## What About Transitioning MDD Documentation to MDR? If you have inherited technical documentation from a legacy MDD device and need to transition it to MDR compliance, here is the practical approach: **1. Map the old ERs to the new GSPRs.** The European Commission published a correlation table mapping MDD Essential Requirements to MDR GSPRs . Use this as your starting point. **2. Identify gaps.** The GSPRs that have no corresponding ER are your gap areas — these require new documentation, new evidence, and potentially new testing. **3. Assess the depth of existing evidence.** Even where MDD ERs map to MDR GSPRs, the MDR may require more detailed evidence. A compliance statement that was sufficient under the MDD may not be sufficient under the MDR. **4. Prioritize by risk.** Address the highest-risk gaps first — software lifecycle, cybersecurity, clinical evidence, and benefit-risk determination are the areas where auditors focus most heavily. ## The Practical Difference for Startups From a startup perspective, the shift from ERs to GSPRs means one thing: the bar is higher, but the expectations are clearer. The MDD's Essential Requirements were sometimes vague enough that manufacturers could claim compliance with minimal evidence. The MDR's GSPRs are specific enough that you know exactly what is expected — which actually makes compliance planning easier, even if compliance execution is more work. Tibor's advice is consistent: do not view the GSPRs as obstacles. View them as your product's specification sheet. If your device meets every applicable GSPR, it is safe, it performs as intended, and it provides the information users need. That is not a regulatory burden — that is good product design. The startups that struggle are those that treat the GSPR assessment as a separate compliance exercise disconnected from their engineering work. The startups that succeed are those that integrate GSPR awareness into their design process from day one. When your engineer makes a design decision, they should know which GSPR that decision relates to. When your quality team documents a test, they should know which GSPR that test supports. Build the GSPR awareness into your team, not just your documents. Next: [Who Are the Key Players in the MDR Ecosystem? Competent Authorities, Notified Bodies & More](/blog/013-mdr-ecosystem-key-players). --- *This post is part of the [MDR Fundamentals & Regulatory Strategy](https://zechmeister-solutions.com/en/blog/category/mdr-fundamentals) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*