General Safety and Performance Requirements: What Annex I Actually Demands

The foundation everything else rests on

Before classification, before conformity routes, before clinical evaluation — every device has to meet the General Safety and Performance Requirements (GSPRs) of Annex I. These are the basic obligations that apply to every medical device placed on the EU market, regardless of class. Your technical documentation, risk management file, and clinical evaluation all exist partly to demonstrate that you have met them.

The GSPRs are organised into three broad sections: general requirements (devices must achieve their intended purpose and not compromise health and safety when used as intended), requirements for design and manufacture (covering mechanical safety, sterility, shelf life, software, usability, radiation, active devices, and more), and requirements for information supplied with the device (labelling and instructions for use). The list runs to over 20 individual requirements and several dozen sub-requirements. The practical challenge is that many of them are open-ended: you have to demonstrate conformity, but the regulation does not always specify exactly how.

How manufacturers demonstrate conformity

The standard approach is a GSPR checklist — a document that lists every applicable requirement, states whether it applies to your device, and if so, explains how you have demonstrated conformity. For most requirements, conformity is demonstrated by a combination of: applying a relevant harmonised standard (which gives you a presumption of conformity for the parts it covers), internal testing and verification, and design documentation.

Harmonised standards are important here. If a standard is listed in the Official Journal as harmonised under MDR, applying it gives you presumption of conformity with the GSPRs it covers. This does not mean you must use harmonised standards — you can use other methods — but if you do not, you need to demonstrate an equivalent level of safety and performance through alternative means. Notified Bodies will examine this closely.

One thing that catches teams off guard: the checklist is not a one-time exercise. If your device changes — in design, materials, intended purpose, or manufacturing — the GSPR analysis needs to be revisited. A checklist written at initial certification that has not been updated to reflect design changes is a significant audit finding.

Requirements that get underestimated

The usability and human factors requirements (section 5 of Annex I) are regularly underestimated, especially by teams coming from a purely technical engineering background. MDR requires that devices are designed to minimise the risks associated with use error — and demonstrating this requires usability engineering documentation, including formative and summative evaluations. Many manufacturers treat this as a minor supplement to their design verification. Notified Bodies increasingly treat it as a core technical requirement that needs rigorous evidence.

Software-related GSPRs (section 17) are another area where shortfalls appear. If your device contains or is software, you need to demonstrate conformity with requirements covering software development lifecycle, cybersecurity, minimum hardware requirements, IT security, and data protection. The depth expected scales with your device class and the software's role in delivering the intended purpose. A Class IIb software-driven device will face far more scrutiny here than a Class I device with a minor software component.

The requirements for information supplied with the device — particularly labelling requirements under section 23 — are frequently treated as an afterthought. MDR's labelling requirements are detailed and specific. Missing a required element on the label or IFU is a non-conformity, even if everything else in the technical file is solid.

The link to risk management

The GSPRs and risk management are inseparable. Annex I requires that devices are designed to eliminate or reduce risks as far as possible (inherently safe design first, then protective measures, then information for safety). This is the same hierarchy that ISO 14971 — the risk management standard — uses. Your risk management file and your GSPR conformity demonstration need to be consistent and cross-referenced. If your risk management file identifies a residual risk that relates to a GSPR requirement, your GSPR analysis needs to acknowledge it and explain why the residual risk is acceptable.

When Notified Bodies audit the GSPR checklist, they are not just ticking boxes — they are tracing the thread between each requirement, your design documentation, your test results, your risk management file, and your clinical evaluation. Gaps in that thread show up clearly. The teams that do this well treat the GSPR analysis as a live map of their technical documentation, not as a standalone compliance document.

Practical starting point

If you are building your GSPR analysis for the first time or updating an existing one, start with MDCG 2022-2, which provides the authoritative interpretation of each Annex I requirement. Work through each requirement against your specific device — note which apply, which do not (with justification), and for those that do apply, document the evidence. Cross-reference your harmonised standards, test reports, and risk management documents. Assign clear ownership for keeping the analysis current. It is a significant body of work, but it is also the clearest single view of whether your device actually meets the regulation's baseline demands.