Harmonised Standards and How They Work in Your Technical File

What harmonised standards actually do for you

Harmonised standards under the MDR are European standards published in the Official Journal of the EU with a reference that ties them to specific essential requirements — in MDR terms, to the General Safety and Performance Requirements (GSPRs) in Annex I. When you apply a harmonised standard in full, you get presumption of conformity with the GSPRs that standard covers. That is useful: it means a Notified Body reviewing your GSPR matrix cannot simply reject a demonstration that is correctly based on a harmonised standard. They can ask questions and verify the test was done correctly, but the standard itself is not in dispute.

The part that teams often misread is "presumption" — it is not proof of conformity, and it does not cover the entire GSPR. A harmonised standard addresses specific technical requirements within the scope of a GSPR. GSPR 1 (benefit-risk) is not something a harmonised standard covers. But ISO 10993-1 covers biocompatibility assessment and provides presumption of conformity with the biocompatibility aspects of the GSPRs that touch on biological safety. Using ISO 10993-1 does not mean you have met GSPR 1 — it means you have addressed one component of the biological safety evidence.

Which standards are harmonised under MDR

The harmonised standards list under EU MDR is published in the Official Journal of the EU. It is updated periodically, and not every medical device standard that is widely used is on the harmonised list. IEC 62304 (medical device software lifecycle), IEC 62366-1 (usability engineering), ISO 14971 (risk management), and ISO 10993 series (biocompatibility) are all referenced on the harmonised list. ISO 13485 (quality management) is also harmonised, but it relates to QMS conformity assessment rather than to technical file content directly.

The harmonised list is worth checking before you finalise your GSPR matrix, because:

• A standard you are relying on may not actually be harmonised — meaning you have no presumption of conformity, and you need to explain why the standard provides equivalent assurance
• The version of a standard you used may have been superseded by a newer version that is now on the harmonised list instead
• Some GSPRs do not yet have a fully applicable harmonised standard, which means you will need a non-standard approach and a rationale

The version problem — withdrawn and superseded standards

This is where technical files get into trouble. A standard gets revised, a new version is published and harmonised, and the old version is withdrawn from the harmonised list. If your technical file still references the old version, you no longer have presumption of conformity for those GSPRs — even though your device was certified when the old version was still valid.

At a surveillance audit, an auditor checking your GSPR matrix may find that the harmonised standard you listed for GSPR 10 was withdrawn two years ago. The new version of that standard is now in the harmonised list. The question the auditor will ask: did you assess whether the new version introduces any requirements your device does not meet? If the answer is documented — you reviewed the new version, you found no new requirements affecting your device, and you updated the matrix to note this — the finding is manageable. If the matrix still shows the withdrawn version with no commentary, that is a straightforward finding.

The practical approach: when a harmonised standard you rely on is revised, do a gap analysis against the new version. If the new version does not change anything relevant to your device, document that and update the matrix to reference the new version with a note on your gap analysis conclusion. If the new version does introduce new requirements, those need to be addressed — either by testing against the new version or by documenting a justified alternative approach.

Using non-harmonised standards and non-standard approaches

Not every demonstration of GSPR compliance can be made through a harmonised standard. For GSPRs where no harmonised standard exists or where the scope of the available standards does not fully cover your device type, you have to use something else: a non-harmonised standard, a technical specification, test data against documented acceptance criteria, or a design analysis with documented rationale.

These approaches work — Notified Bodies are accustomed to reviewing them — but the burden of justification is higher. When you use a harmonised standard, the standard's existence in the Official Journal list is the justification. When you use a non-harmonised standard or a bespoke approach, you need to explain why it provides equivalent assurance of GSPR compliance. The GSPR matrix entry needs to document this: what method you used, why it is appropriate, and what the evidence shows.

One area where non-harmonised approaches are common: cybersecurity. There is currently no harmonised standard specifically for medical device cybersecurity, so teams use MDCG 2019-16 (or its successors), IEC 81001-5-1, or equivalent approaches and document the rationale. This is acceptable, but the documentation needs to be explicit about the standards or guidance used and why they address the relevant GSPRs.

What the GSPR matrix needs to show for standards-based demonstrations

A GSPR matrix entry for a harmonised standard demonstration should show:

• The GSPR being addressed
• The harmonised standard title and the edition used — specifically the edition that was on the harmonised list when applied
• Whether the standard was applied in full or in part (if in part, which clauses and why the excluded clauses are not relevant)
• The evidence document — the test report, assessment, or record that shows compliance with the standard was demonstrated
• Any residual risk linked to the GSPR, referenced to the risk management file

The edition matters. The harmonised list specifies which editions carry the presumption of conformity. If you apply a newer edition that is not yet on the harmonised list, you have no presumption of conformity even though the newer edition is technically more current. This can happen with standards that are revised faster than the Official Journal is updated. In that case, document clearly which edition you used and note that presumption of conformity is based on the previous edition that is on the harmonised list, while the newer edition was applied as a more stringent approach.

Staying current with the harmonised list

The harmonised standards list is not static. New standards are added, editions are updated, and standards are occasionally removed or replaced. Teams that checked the list at the time of initial certification and have not checked since are likely operating with a GSPR matrix that references outdated or withdrawn standard editions.

A practical approach: include a review of the relevant harmonised standards list as a standing item in your periodic technical file review — the same review that checks whether post-market data requires a technical file update. This does not need to be a full gap analysis every time; it can be a quick comparison of the standards currently on the harmonised list against the ones referenced in your matrix, flagging any that have been superseded since the last review. The review itself, documented, is what demonstrates to an auditor that you are actively maintaining the technical file rather than leaving it static after certification.