Article 5(2) of the MDR requires a device to meet the general safety and performance requirements (GSPR) in Annex I that apply to it, taking into account its intended purpose. MDCG 2019-15 rev.1, the MDCG guidance for class I manufacturers, says that demonstration of conformity with Annex I "should typically be presented in the form of a checklist".
A GSPR checklist that lists standard numbers is not evidence. This article explains what the checklist must contain, how to handle requirements that do not apply, how standards fit in, and what software rows look like.
Where the checklist comes from
Three provisions drive the checklist:
Article 5(2): the device must meet the GSPR that apply to it, given its intended purpose.
Annex II Section 4: the technical documentation must contain the information demonstrating conformity with the GSPR, including the methods and solutions used, harmonised standards and common specifications.
Article 10(9)(b): the quality management system must cover identification of the applicable GSPR and the options for addressing them.
In our view, the checklist is the index to the technical documentation. Every applicable row should lead to a controlled document and section. Our article on EU MDR requirements covers the other Article 10 obligations.
How Annex I is organised
| Chapter | Sections | Content |
|---|---|---|
| I | 1 to 9 | General requirements, including safety and performance, benefit-risk and risk management |
| II | 10 to 22 | Requirements regarding design and manufacture, including software (Section 17) |
| III | 23 | Information supplied with the device: label and instructions for use |
Source: MDR Annex I.
What each row needs
According to MDCG 2019-15 rev.1, the checklist should list all requirements in Annex I and specify:
| Column | What it records |
|---|---|
| 1. Applicability | Whether the requirement applies to the device, with the reason if it does not |
| 2. Solution adopted | How the manufacturer meets each applicable requirement |
| 3. Standards or common specifications | Any harmonised standard or common specification applied, in full or in part |
| 4. Evidence location | Where the evidence of the solution sits in the technical documentation |
Source: MDCG 2019-15 rev.1.
In our view, the evidence column is where most checklists fail. "See risk management file" is a title, not evidence. The row should name the document ID, version and section, so a reviewer can open it and find the answer.
Requirements that do not apply
Every Annex I requirement should appear on the checklist, including those that do not apply. A bare "N/A" tells a reviewer nothing. Write one sentence that ties the exclusion to the intended purpose and the device description.
For a software-only device, for example: "Not applicable: the device is standalone software with no physical contact with the patient." Reopen these rows whenever the device description changes, for example when a hardware accessory is added.
Standards and common specifications
Under Article 8(1), only harmonised standards whose references are published in the Official Journal give a presumption of conformity, and only for the requirements they cover. Check the Commission's list of MDR harmonised standards at each review. The Annex Z of each EN standard shows which requirements it covers.
Under Article 9, devices that conform to common specifications are presumed to conform to the requirements they cover. Manufacturers must comply with applicable common specifications unless they justify adopting solutions that ensure at least an equivalent level of safety and performance.
Standards that are not harmonised can still be used as evidence of the state of the art, with a rationale. For example, EN 62304 is not on the Commission's summary list of MDR harmonised standards. Our article on IEC 62304 explains how it is cited instead.
In our view, the row label should always be the Annex I requirement, not the standard. The standard is the method, in its own column. Article 10(9) also requires changes in harmonised standards to be taken into account in a timely manner, so record the edition used on each row.
Software rows
For software, three requirements carry most of the weight:
| Annex I | Requirement (summary) | Typical evidence |
|---|---|---|
| 17.2 | Software developed and manufactured in accordance with the state of the art, taking into account the development life cycle, risk management including information security, and verification and validation | IEC 62304 lifecycle records, IEC 81001-5-1 security records, verification and validation reports |
| 17.4 | Minimum requirements for hardware, IT network characteristics and IT security measures needed to run the software as intended | Specification of the operating environment and security measures |
| 23.4(ab) | Information on those minimum requirements in the instructions for use | The specific IFU section, for the matching software version |
Source: MDR Annex I.
Our articles on IEC 81001-5-1 and SaMD technical documentation cover the evidence behind these rows.
Keeping the checklist current
The checklist is a controlled document, not a one-off deliverable. In our view, revise the affected rows when:
a software release changes hazards, controls or the user interface;
a cited standard is revised or a new harmonised standard is published;
a common specification is adopted or changed;
the intended purpose or device description changes.
Each revision should be versioned and linked to the change that triggered it. The EU declaration of conformity rests on the same evidence, so both must stay in step.
For manufacturers outside the EU, the authorised representative must verify under Article 11 that the technical documentation has been drawn up. MedQAIR's Digital AR service gives the authorised representative direct access to that documentation.
A hypothetical example
Hypothetical example: a Dutch company develops a standalone app that estimates skin-lesion risk from photos for GPs.
Applicability: it marks the sterile and physical requirements as not applicable, with one sentence each tied to its software-only, non-contact device description.
Section 1 and 8 rows: these point to the benefit-risk conclusion in the dated clinical evaluation report.
Section 3 row: this points to the current risk management file version and the residual risk evaluation.
Section 17.2 row: this cites IEC 62304 and IEC 81001-5-1 records, with a note that neither is harmonised under the MDR.
Section 17.4 and 23.4(ab) rows: these point to the operating environment specification and the IFU section on minimum IT requirements, for the released version.
Change: when a new photo-quality check is added, the Section 3 and 17.2 rows are updated and linked to the change record.
Conclusion
The GSPR checklist is the index to the technical documentation. Every Annex I requirement gets a row, every applicable row gets a solution, a standard where relevant, and a precise evidence location, and every non-applicable row gets a reason.
In our view, a good checklist lets a reviewer open any row and land on the evidence in one step.
If you need help building or reviewing your GSPR checklist, our regulatory strategy team can help, or contact MedQAIR.
Frequently asked questions
Is a GSPR checklist mandatory under the MDR?
The MDR requires the technical documentation to demonstrate conformity with the applicable GSPR (Annex II Section 4). MDCG 2019-15 rev.1 says this should typically be presented as a checklist.
What columns should a GSPR checklist have?
Applicability, the solution adopted, any harmonised standards or common specifications applied in full or in part, and the location of the evidence in the technical documentation.
Can I mark requirements as not applicable?
Yes, but each one needs a reason tied to the intended purpose and device description. A bare "N/A" is not enough.
Does citing a standard prove conformity?
Only harmonised standards published in the Official Journal give a presumption of conformity, and only for the requirements they cover. Other standards need a rationale and evidence.
How often should the checklist be updated?
Whenever the device, its intended purpose, a cited standard or a common specification changes, under change control.
