Knowing which harmonized standards exist is one thing. Using them effectively to build your compliance case is another. This post is the practical companion to our overview of harmonized standards. It walks through the mechanics of how startups actually apply standards to demonstrate MDR conformity, from GSPR mapping to Notified Body submissions.
The Mechanism: Presumption of Conformity
MDR Article 8 establishes the presumption of conformity: devices that are in conformity with relevant harmonized standards (or relevant parts thereof) referenced in the Official Journal of the European Union shall be presumed to be in conformity with the MDR requirements covered by those standards (or parts).
This is powerful. The word "presumed" means the Notified Body and market surveillance authorities start from the position that your device meets the relevant requirements. Unless there is specific evidence to the contrary. You do not need to prove compliance from scratch; you need to demonstrate that you followed the standard.
But "presumption" has boundaries:
-
It only covers the requirements the standard addresses. ISO 14971 covers risk management requirements, not software lifecycle requirements. You get the presumption for risk management, not for software.
-
It only applies if you follow the standard correctly. Claiming to follow ISO 13485 but not actually implementing the processes described in the standard does not create any presumption.
-
It can be rebutted. If evidence suggests that despite following the standard, your device does not meet a specific MDR requirement, the presumption falls away for that requirement.
The GSPR Checklist: Your Master Compliance Document
The General Safety and Performance Requirements (GSPRs) are in MDR Annex I. They are organized into three chapters:
- Chapter I: General requirements (risk management, design for safety, chemical and material requirements, infection and microbial contamination, and more)
- Chapter II: Requirements regarding design and manufacture (various specific requirements depending on device type)
- Chapter III: Requirements regarding the information supplied with the device (labeling, IFU)
Your GSPR checklist is a systematic document that lists every GSPR, assesses its applicability to your device, and for each applicable requirement identifies the evidence demonstrating conformity. Including references to harmonized standards.
How to Build the GSPR Checklist
Column 1: GSPR reference. The specific section and paragraph of Annex I.
Column 2: Applicability. "Applicable" or "Not applicable". With a justification for non-applicability. Do not just mark requirements as not applicable without explaining why. Example: "GSPR 11.1 (protection against radiation). Not applicable: device does not emit ionizing radiation and does not incorporate radioactive substances."
Column 3: Method of compliance. How you demonstrate conformity. This is where harmonized standards appear. Example: "Conformity demonstrated through application of EN ISO 14971:2019 + A11:2021 (harmonized under MDR), as documented in the Risk Management File (Document Ref: RMF-001)."
Column 4: Evidence reference. Specific documents in your technical file. Example: "Risk Management File RMF-001, sections 4.1-4.7; Risk Management Report RMR-001."
Column 5: Harmonized standard or other standard reference. The specific standard, its edition, and whether it is harmonized. Include the OJEU reference if harmonized.
Example GSPR Checklist Entries
Here is what a few entries might look like for a software medical device:
| GSPR | Applicable | Method | Evidence | Standard |
|---|---|---|---|---|
| 1 (General safety) | Yes | Risk management per harmonized standard; design measures | RMF-001, Design File | EN ISO 14971:2019 + A11:2021 (harmonized) |
| 14.1 (Software lifecycle) | Yes | Software development per validated standard | Software Development File, V&V reports | EN 62304:2006 + A1:2015 |
| 17.1 (Electronic programmable systems) | Yes | Software validation per standard | Software V&V reports | EN 62304:2006 + A1:2015 |
| 5 (Usability) | Yes | Usability engineering per standard | Usability Engineering File | EN 62366-1:2015 + A1:2020 |
| 23.1 (Labeling) | Yes | Labeling per standard symbols | Labeling specifications | EN ISO 15223-1 |
Applying a Harmonized Standard: What "Following" Actually Means
Claiming to follow a harmonized standard requires more than listing it in your GSPR checklist. You must actually apply the standard to your device. Meaning:
1. Obtain and Read the Standard
Standards are copyrighted documents that must be purchased from national standards bodies (Austrian Standards International, DIN, BSI, etc.) or from ISO/IEC directly. They are not free. Budget for this. A single standard typically costs EUR 100-300, and you may need 10-20 standards for a typical device.
Do not rely on summaries or secondhand descriptions. Read the actual standard text.
2. Identify Applicable Clauses
Most standards have both mandatory requirements ("shall" statements) and informational guidance ("should" or "may" statements, guidance annexes). Identify which mandatory requirements apply to your device. Some clauses may not be applicable. Document why.
3. Implement the Requirements
Actually do what the standard says. If ISO 14971 requires a risk analysis using a defined methodology, perform the analysis. If EN 62304 requires software unit testing for Class C software, perform unit testing. If EN 62366-1 requires a formative usability evaluation, conduct the evaluation.
4. Document the Implementation
Create records that demonstrate you followed the standard. For each applicable requirement, your technical documentation should contain evidence of implementation. Test reports, analysis documents, design records, process records. These are the evidence that backs up your GSPR checklist claim.
5. Reference the Standard in Your GSPR Checklist
Close the loop by referencing the standard and the specific evidence documents in your GSPR checklist. The GSPR checklist is the bridge between MDR requirements and your technical documentation. It must be traceable in both directions.
Partial Application of Standards
You do not always need to apply an entire standard to claim a presumption of conformity. MDR Article 8 specifically mentions "relevant parts". You can apply the parts of a standard that address the GSPRs relevant to your device and claim the presumption for those specific requirements.
For example, ISO 10993 is a multi-part series. If your device has patient skin contact only, you may only need to apply the parts relevant to skin contact (cytotoxicity, irritation, sensitization) rather than the parts relevant to blood contact or implantation.
Document which parts you applied and why. Your GSPR checklist should be specific: "EN ISO 10993-5 (cytotoxicity) and EN ISO 10993-10 (irritation and sensitization) applied; EN ISO 10993-4 (hemocompatibility) not applied. Device does not contact blood or blood components."
When Standards Conflict or Overlap
Multiple standards sometimes address the same topic. For example, both ISO 14971 and IEC 62304 address risk management for software. When this happens:
-
Identify the primary standard for each GSPR. Usually, the more specific standard takes precedence for its area of expertise (ISO 14971 for overall risk management, IEC 62304 for software-specific risk management within the development process).
-
Ensure consistency. If you apply multiple standards that touch on the same area, make sure your approach is consistent. Your risk management methodology should not change between documents.
-
Document the relationship. In your technical file, explain how the standards complement each other and how you have applied them consistently.
Notified Body Expectations
Notified Bodies assess your use of standards as part of their technical documentation review. Here is what they look for:
They check your GSPR checklist. Is it complete? Does it cover all applicable GSPRs? Are the standard references correct (right edition, harmonization status)?
They check your evidence. Does the evidence actually demonstrate what the GSPR checklist claims? If you cite ISO 14971, is there actually a risk management file that follows ISO 14971?
They check for gaps. Are there GSPRs for which you have no standard coverage and no alternative evidence? Gaps are findings.
They check the edition. Are you referencing the current edition of the standard? Using an outdated edition (especially when the current edition has been harmonized) creates questions.
They assess competence. Can your team explain how the standard was applied? During the audit, the NB may ask team members to walk through their application of specific standards. If the team cannot explain it, the NB may doubt whether the standard was actually followed.
Tibor's auditor perspective: "When I audited companies, the GSPR checklist told me everything I needed to know about their regulatory maturity. A well-built GSPR checklist with correct standard references, specific document citations, and thoughtful applicability assessments told me this company understood what they were doing. A generic GSPR checklist with vague standard references and no document citations told me I was going to find problems."
The State of the Art Requirement
MDR Annex I GSPR 1 requires that devices achieve the performance intended by the manufacturer and be designed and manufactured in such a way that, during normal conditions of use, they are suitable for their intended purpose. This includes reflecting the state of the art in safety and performance.
Harmonized standards represent one aspect of the state of the art. They codify accepted technical practices. But the state of the art can evolve faster than standards are updated. If new scientific evidence, new techniques, or new technologies have emerged that are relevant to your device's safety, you may need to address them even if the harmonized standard has not yet been updated to reflect them.
This is rare for most startups, but it is worth being aware of. If a significant safety-relevant development occurs in your device's field, relying solely on a harmonized standard that predates that development may not be sufficient.
Practical Workflow for Startups
Here is a step-by-step workflow for using harmonized standards in your MDR compliance:
- List all applicable GSPRs from Annex I for your device
- For each applicable GSPR, identify candidate standards that address the requirement
- Check the harmonization status of each standard against the current OJEU listing
- Prioritize harmonized standards. Use them wherever available
- For gaps without harmonized standards, use recognized international standards with appropriate GSPR mapping documentation
- Obtain the standards (purchase from standards bodies)
- Read and apply the standards to your device development
- Document implementation through your technical documentation
- Build the GSPR checklist linking requirements to standards to evidence
- Review with your Notified Body during pre-submission discussions if you have questions about standard applicability or harmonization status
The Bottom Line
Harmonized standards are your most efficient path to demonstrating MDR compliance. They provide recognized methods, accepted criteria, and a presumption of conformity that simplifies both your documentation and your Notified Body review.
The key to using them effectively is disciplined traceability: from GSPR to standard to evidence to technical documentation. Every link in that chain must be documented, accurate, and verifiable.
Do the mapping work upfront. It is not glamorous. It is not exciting. But a well-built GSPR checklist with solid standard references is the backbone of a successful conformity assessment. And it will save you time, money, and stress when the Notified Body comes to review.