EU MDR and IVDR General Safety and Performance Requirements

The GSPRs define the safety and performance outcomes

Article 5 of both the MDR and IVDR requires a device to meet the General Safety and Performance Requirements that apply to it, taking account of its intended purpose. Those requirements are set out in Annex I.

The GSPRs are legally binding product requirements. They describe outcomes such as acceptable risk, intended performance, suitable materials, reliable software, protection against infection, usable information and safe operation across the claimed lifetime. They do not prescribe one universal development process or one fixed set of tests.

Conformity is demonstrated by the complete body of evidence. The GSPR matrix is an index and rationale that makes that evidence navigable; it is not the evidence itself.

MDR and IVDR share a framework but differ in emphasis

A product may also be subject to other Union legislation. Identify those interfaces explicitly rather than assuming that MDR or IVDR conformity automatically covers every legal obligation.

Applicability starts with a stable intended purpose

A defensible applicability decision depends on knowing what the device is, what it does, for whom, under which conditions and with which claims. When the intended purpose, system boundary or configuration changes, the GSPR assessment may also change.

• Confirm whether the product is governed by the MDR, IVDR or another regulatory framework.
• Define the medical purpose, indications, contraindications and intended clinical benefit.
• Identify patients, specimens, intended users and reasonably foreseeable misuse.
• Define use environments, operating conditions, transport, storage, installation and maintenance.
• Identify accessories, connected systems, mobile platforms and required infrastructure.
• Define patient-contacting materials, sterility and biological or chemical characteristics.
• Identify active, measuring, software, diagnostic, therapeutic or implantable functions.
• Define variants, configurations, combinations and claimed lifetime.

Use MTL-102 — Intended Purpose, Users and Use Environments before finalising applicability. An unexplained “not applicable” is weak; the rationale should show why the device characteristic or claim addressed by the requirement is absent.

Build an applicability-and-evidence matrix

Annex II requires the technical documentation to identify applicable GSPRs, explain why others do not apply, state the conformity methods, identify harmonised standards, common specifications or other solutions, and cross-reference the precise controlled evidence.

A useful matrix is specific enough for an independent reviewer to follow without searching the complete technical file. Avoid vague references such as “risk file”, “test report” or “ISO 14971”. Identify the exact record and the relevant section, result or conclusion.

The matrix should also distinguish full, partial and non-use of a standard. When a standard does not fully cover the regulation’s requirement, identify the additional method and evidence used to close the gap.

Chapter I establishes the overall safety argument

The general requirements establish that devices must achieve their intended performance, be suitable for their intended purpose and provide a high level of protection of health and safety. Risks must be acceptable when weighed against benefits and assessed against the generally acknowledged state of the art.

• Define measurable safety and performance claims.
• Establish and maintain a lifecycle risk-management system.
• Apply the required risk-control priority: safe design, protective measures, then information for safety.
• Address risks arising from intended use and reasonably foreseeable misuse.
• Consider user capabilities, ergonomics and use environments.
• Maintain safety and performance throughout the claimed lifetime.
• Protect the device through transport and storage.
• Evaluate individual residual risks and overall residual risk against benefits.

These are not introductory statements to cite once. They connect the intended purpose, benefit–risk determination, risk-management file, verification, clinical or performance evaluation, lifetime claims and post-market system.

Risk management is continuous and product specific

Annex I embeds risk management as an iterative lifecycle process. The manufacturer must plan the work, identify known and foreseeable hazards, estimate and evaluate risks, implement controls, assess residual risk and use production and post-market information to keep the analysis current.

“As far as possible” does not mean reducing every risk regardless of consequence to benefit. The regulations connect risk reduction to the benefit–risk ratio and require the safety-control hierarchy to be followed. A warning does not replace a practicable design control.

• Link every applicable GSPR safety issue to the relevant hazards and hazardous situations.
• Translate selected risk controls into approved design or process requirements.
• Verify the implementation and effectiveness of each control.
• Assess risks introduced by controls and the combined effect of multiple residual risks.
• Ensure communicated residual risks are consistent across the risk file, evaluation reports and information supplied.
• Define how production, complaints, vigilance, literature and post-market activities trigger review.

Use MTL-302 — ISO 14971 Risk Management for the standards-based framework and MTL-105 — Medical-device Risk Management for the practical lifecycle process.

Chapter II turns product characteristics into engineering obligations

Chapter II should be reviewed by the people who understand the design, not completed by regulatory affairs in isolation. Applicability and evidence span materials, contamination, sterility, substances, measurement, radiation, software, active functions, mechanical and thermal risks, energy delivery, lay use and other device-specific characteristics.

Use MTL-103 — User Needs and Design Inputs and MTL-104 — Design Controls and Technical Documentation to connect legal requirements to controlled development evidence.

Performance evidence differs materially between MDR and IVDR

For an IVD, bench testing alone is not the complete performance evaluation. Scientific validity, analytical performance and clinical performance form a connected evidence set. The level and quality of evidence should be justified for the device and intended purpose.

Software, information security and platforms are explicit design concerns

Both regulations require electronic programmable systems and software devices to provide repeatability, reliability and performance appropriate to intended use. Development must reflect the state of the art, including lifecycle processes, risk management, information security, verification and validation.

• Define software functions, safety contributions, interfaces and operating states.
• Control architecture, implementation, configuration, anomalies and released versions.
• Specify supported hardware, operating systems, mobile platforms and network characteristics.
• Define IT-security measures needed for the software to run as intended.
• Address unauthorised access that could impair safety or intended performance.
• Verify normal operation, fault responses, data integrity, updates and recovery.
• Maintain security, compatibility and performance across the supported lifetime.

Use MTL-107 — Software Lifecycle, MTL-108 — Medical-device Cybersecurity and MTL-121 — Data, Connectivity and Interoperability for the detailed engineering threads.

Physical and active-device safety needs a technology-specific argument

Applicable requirements can address measurement accuracy, radiation, energy sources, electrical shock, electromagnetic disturbance, mechanical and thermal hazards, alarms, controls, connections, environmental conditions and single-fault behaviour.

A declaration that a recognised product standard was tested is useful only when the device configuration, standard edition, collateral and particular requirements, deviations, essential performance or equivalent safety functions, and residual gaps are clear.

• Identify functions whose loss or degradation can create unacceptable risk.
• Define accuracy, limits, alarms, protective functions and fault responses.
• Test representative configurations in the intended electromagnetic and physical environments.
• Address installation, maintenance, calibration, accessories and connected equipment.
• Trace test results and deviations to risk controls and design conclusions.

Use MTL-113 — Essential Performance and Safety Concepts, MTL-118 — Electrical Safety and Electromagnetic Compatibility and MTL-304 — IEC 60601 Electrical Safety and EMC.

Biological, chemical, infection and sterility requirements are connected

Material selection cannot be separated from manufacturing residues, degradation, patient contact, medicinal substances, specimens, cleaning, sterilisation, packaging, transport, shelf life and disposal. The evidence must represent the finished device and its actual exposure conditions.

Use MTL-117 — Biocompatibility and Chemical Safety to build the body-contact and chemical-safety evidence.

User capability and use environment affect both design and evidence

The GSPRs require consideration of ergonomic features, user knowledge, experience, education, training, medical and physical condition, and the environment in which the device will be used. MDR requirements for lay users and IVDR requirements for self-testing and near-patient testing add specific expectations.

• Define user groups and the tasks each group performs.
• Identify critical tasks, foreseeable use errors and their possible consequences.
• Reduce risk through the user interface before relying on warnings or training.
• Account for lighting, noise, mobility, stress, protective equipment and other environmental factors.
• Ensure results, device states, warnings and failures can be recognised and acted upon.
• Evaluate representative users performing representative tasks with the final interface and information.

Use MTL-116 — Usability and Human Factors and MTL-305 — IEC 62366-1 Usability Engineering.

Information supplied is part of the risk-control system

MDR requirement 23 and IVDR requirement 20 cover labels and instructions for use. The content, medium, format, legibility and location must suit the device, intended purpose and intended users. Required information also includes device identification, manufacturer details, safe-use information and relevant warnings, precautions, contraindications and residual risks.

Labels and instructions should be derived from the same controlled sources as design, risk, clinical or performance and regulatory claims. Contradictions between the GSPR matrix, risk file, evaluation report and information supplied undermine the conformity argument.

• Map each required item to the label, packaging, instructions or electronic information.
• Use controlled terminology, symbols, units, warnings and translations.
• Verify content and readability; validate safety-critical use information where appropriate.
• Keep claims, intended purpose, residual risks and operating limits consistent.
• Control website and electronic information where relied upon.
• Assess labelling changes for effects on usability, risk and regulatory evidence.

Standards provide methods—not a substitute for Annex I

Harmonised standards whose references are published in the Official Journal can provide a presumption of conformity for the requirements or parts of requirements they cover. Common specifications can also establish means of meeting regulatory requirements. Other standards can provide valuable state-of-the-art methods without carrying that presumption.

Start with the legal requirement, then select the method. Do not assume that certification to ISO 13485, use of ISO 14971 or a passing product-standard report demonstrates every applicable GSPR.

• Record the standard, edition, amendment and European adoption used.
• Confirm whether and to what extent it is harmonised for the applicable regulation.
• Use the standard’s annex mapping cautiously and verify the covered GSPR text.
• Document exclusions, deviations and requirements only partially addressed.
• Add product-specific methods where standards do not fully cover the claim or risk.
• Monitor changes to legislation, common specifications, harmonisation and state of the art.

MDCG documents help explain a common regulatory understanding but are not themselves legally binding. Record why particular guidance is relevant and how it influenced the chosen solution.

Build one connected conformity argument

Traceability does not require every artefact to repeat the regulation’s wording. It requires a reviewer to follow the logic from legal requirement to device-specific interpretation, implementation, evidence and conclusion without unsupported jumps.

GSPR conformity is cross-functional work

One person can coordinate the matrix, but no single function has enough knowledge to justify every applicability decision and evidence conclusion alone.

The GSPR assessment must remain current after release

Conformity is not frozen at the date of initial approval. Production experience, complaints, vigilance, clinical or performance follow-up, cybersecurity monitoring, supplier changes, new standards and changes in the state of the art can affect the original conclusions.

• Define triggers and ownership for review of the GSPR matrix.
• Assess design, software, supplier, material, process and labelling changes.
• Update evidence references when documents are revised or replaced.
• Review whether new hazards, failure rates or performance information affect applicable requirements.
• Reassess benefit–risk and overall residual risk using post-market information.
• Monitor regulatory amendments, common specifications, harmonised standards and relevant guidance.
• Keep the Declaration of Conformity and technical documentation aligned with the released device.

A changed evidence reference is not merely administrative if the new report covers a different configuration, method, acceptance criterion or conclusion.

Common misconceptions

Practical implementation checklist

• Is the applicable regulation and device qualification clear?
• Is the intended purpose stable enough to support applicability decisions?
• Does the assessment cover the complete device, accessories, software and required infrastructure?
• Is every Annex I requirement marked applicable or not applicable with a technical rationale?
• Are methods and adopted solutions identified separately?
• Are standards, common specifications and other methods identified with exact editions?
• Are partial coverage, deviations and gaps visible?
• Does every evidence reference identify a controlled document and relevant location?
• Are GSPRs translated into design inputs, risk controls and acceptance criteria?
• Are clinical or IVD performance claims supported by the appropriate evaluation evidence?
• Are software, cybersecurity, usability, biological, electrical, mechanical and information requirements addressed where applicable?
• Are residual risks and limitations consistent across all documents and information supplied?
• Have cross-functional owners reviewed the entries within their competence?
• Are open items controlled before the Declaration of Conformity is signed?
• Are lifecycle review triggers defined for changes, post-market information and state-of-the-art developments?