General Safety and Performance Requirements Checklist
GSPR Checklist
Systematically evaluate compliance with essential safety and performance requirements for EU market access.
Summary
The General Safety and Performance Requirements (GSPR) Checklist is a comprehensive evaluation tool that demonstrates your medical device’s compliance with EU MDR Annex I requirements. This document systematically reviews each GSPR requirement, determines its applicability to your device, identifies relevant standards, provides evidence of conformity, and justifies any deviations from the requirements.Why is GSPR Checklist important?
The GSPR Checklist serves as the cornerstone of EU MDR compliance by ensuring your device meets all fundamental safety and performance requirements before market entry. European regulators require this systematic evaluation to verify that manufacturers have thoroughly considered every applicable safety requirement and implemented appropriate risk controls. The checklist provides transparent documentation of your compliance strategy, making it easier for notified bodies to assess your technical file and for you to maintain ongoing compliance throughout your device’s lifecycle.Regulatory Context
Under 21 CFR Part 820 (Quality System Regulation):
- No direct equivalent to GSPR checklist exists in FDA regulations
- However, 510(k) submissions must demonstrate substantial equivalence and safety
- Design controls (820.30) require systematic evaluation of device requirements
- Risk analysis must be documented as part of design controls
Special attention required for:
- Software devices must comply with FDA software guidance documents
- Cybersecurity requirements under FDA premarket guidance
- Usability engineering per FDA Human Factors guidance
- Predicate device comparison for substantial equivalence
Guide
Understanding GSPR Structure
The GSPR checklist follows the three-chapter structure of MDR Annex I: General Requirements (GSPRs 1-9), Design and Manufacture Requirements (GSPRs 10-22), and Information Requirements (GSPR 23). Each requirement must be evaluated for applicability, standards compliance, evidence provision, and deviation justification.Determining Applicability
For each GSPR, you must determine whether it applies to your device based on its intended use, design characteristics, and risk profile. Software medical devices typically have “No” applicability for physical requirements like biocompatibility, sterilization, or mechanical properties, but must carefully address software-specific requirements in GSPRs 17-18.Identifying Applicable Standards
When a GSPR applies to your device, identify the harmonized standards that provide presumption of conformity. Key standards for software devices include EN 62304 (medical device software lifecycle), IEC 82304-1 (health software general requirements), EN ISO 14971 (risk management), and EN 62366-1 (usability engineering). Reference the Official Journal of the European Union for the current list of harmonized standards.Providing Evidence of Conformity
Your evidence must demonstrate objective compliance with each applicable GSPR. This includes referencing specific documents from your technical file such as risk management files, clinical evaluation reports, verification and validation reports, usability engineering files, and design documentation. Ensure your evidence is traceable, verifiable, and current.Justifying Deviations
When a GSPR is not applicable or when you deviate from standard approaches, provide clear, technical justification. For software devices, common justifications include “device is software and not susceptible to [physical requirement]” or “device does not contain [specific component/substance]”. Avoid generic statements and provide device-specific reasoning.Key Considerations for Software Devices
Software medical devices must pay particular attention to GSPR 17 (electronic programmable systems and software), which requires compliance with software development lifecycle standards, risk management including cybersecurity, and verification and validation. Address mobile platform considerations (GSPR 17.3) if your software runs on mobile devices, including screen size limitations and environmental factors.Integration with Other Documentation
Your GSPR checklist must align with other technical documentation including your risk management file, clinical evaluation, usability engineering file, and verification and validation reports. Ensure consistency in claims, evidence references, and compliance statements across all documents.Example
Scenario
You are developing a mobile application that analyzes medical images and provides diagnostic support to healthcare professionals. The app processes uploaded images, applies AI algorithms for analysis, and displays results with confidence scores. It does not store patient data locally and requires internet connectivity for processing.Example GSPR Checklist Entry
GSPR 17.1: Electronic Programmable Systems| Element | Content |
|---|---|
| Requirement | Devices that incorporate electronic programmable systems, including software, or software that are devices in themselves, shall be designed to ensure repeatability, reliability and performance in line with their intended use. |
| Applicable | Yes |
| Applicable Standards | EN 62304:2006+A1:2015 IEC 82304-1:2016 EN ISO 14971:2019 |
| Evidence of Conformity | Software Development and Maintenance Plan (DOC-001) Software Architecture Document (DOC-015) Software System Test Report (DOC-045) Risk Management File (DOC-008) |
| Rationale for Deviations | No deviations |
| Element | Content |
|---|---|
| Requirement | Devices shall be designed and manufactured in such a way as to ensure that the characteristics and performance requirements referred to in Chapter I are fulfilled, with particular attention to choice of materials, toxicity, and flammability. |
| Applicable | No |
| Applicable Standards | N/A |
| Evidence of Conformity | N/A |
| Rationale for Deviations | The device is software-only and does not contain physical materials susceptible to toxicity, flammability, or other chemical and physical properties. |
Q&A
What happens if I mark a GSPR as not applicable but a notified body disagrees?
What happens if I mark a GSPR as not applicable but a notified body disagrees?
If a notified body questions your applicability assessment, you must provide additional technical justification or revise your evaluation. Document your reasoning clearly and be prepared to demonstrate why specific requirements don’t apply to your device design and intended use.
How do I handle GSPRs that are partially applicable to my device?
How do I handle GSPRs that are partially applicable to my device?
Break down the GSPR into its component parts and evaluate each separately. Mark the overall GSPR as “Yes” if any part applies, then provide detailed justification explaining which aspects apply and which don’t, with specific evidence for applicable portions.
Can I use non-harmonized standards as evidence of GSPR compliance?
Can I use non-harmonized standards as evidence of GSPR compliance?
Yes, you can use non-harmonized standards, but you must provide additional justification demonstrating how they ensure GSPR compliance. Harmonized standards provide presumption of conformity, while non-harmonized standards require you to prove equivalence.
How often should I update my GSPR checklist?
How often should I update my GSPR checklist?
Update your GSPR checklist whenever you make significant design changes, when new harmonized standards are published, or when regulatory guidance changes. Minor software updates typically don’t require GSPR checklist updates unless they affect safety or performance claims.
What if my software device has measuring functions?
What if my software device has measuring functions?
If your device has measuring functions with claimed accuracy, you must address GSPR 15 requirements. This includes demonstrating sufficient accuracy, precision, and stability for your intended purpose, and expressing measurements in legal units where applicable.
How do I address cybersecurity requirements in the GSPR checklist?
How do I address cybersecurity requirements in the GSPR checklist?
Cybersecurity is primarily addressed through GSPR 17.2 (software development lifecycle) and GSPR 18.8 (protection against unauthorized access). Reference your risk management file, cybersecurity documentation, and relevant standards like IEC 80001-1 for network security.