Requirements management software for medical devices in Germany

Short answer: to sell a medical device in Germany you have to evidence every applicable general safety and performance requirement in Annex I of EU MDR 2017/745, meet the national provisions in the MPDG, and survive a notified body that samples your traceability in both directions. Requirements management software, known in German as Anforderungsmanagement, is how teams keep that evidence complete and current rather than rebuilding it before every audit. Matrix Req is the tool we build for that job. This page covers what the German stack asks of your requirements process, the clauses it rests on, and what to look for in a tool.

We work at Matrix One, the company behind Matrix Req, so read this as a vendor's account of its own market. We have tried to make it useful anyway by citing the regulation and the clauses rather than asserting things about ourselves, and by saying plainly further down who Matrix Req is wrong for.

What does the German regulatory stack require from your requirements process?

Nothing in the MDR or the MPDG names a tool or a category of tool. What they name is evidence. You have to show that every applicable general safety and performance requirement is met, that every risk control was implemented and verified, and that the technical documentation reflects the device you actually built. Everything else follows from that.

How do EU MDR and German national law fit together?

The MDR is a Regulation, so it applies directly in Germany with no national transposition. What Germany adds is the enforcement layer and the national provisions. The Medizinprodukterecht-Durchführungsgesetz, the MPDG, has been in force since 26 May 2021 and replaced the older Medizinproduktegesetz. It carries clinical investigation rules, vigilance duties, language obligations and penalties, and the Medizinprodukte-Durchführungsverordnung fills in the procedural detail.

What do the GSPRs in Annex I actually ask you to prove?

For each general safety and performance requirement you either show how the device meets it or record why it does not apply. Annex II then asks for the design and manufacturing information as part of the technical documentation. In practice the GSPR checklist becomes the spine of the submission, and every entry on it has to point at a real requirement, a real risk control and a real test result. Our guide to the MDR and IVDR general safety and performance requirements goes through them in detail.

Who regulates medical devices in Germany?

BfArM is the federal higher authority, handling vigilance, clinical investigation approvals and the DiGA directory. Routine market surveillance sits with the authorities of the individual Länder, which is why an inspection can arrive from a state body rather than from Bonn. Notified bodies are designated and monitored by the ZLG, and Germany hosts several of the busiest in Europe, including TÜV SÜD, TÜV Rheinland, DQS Medizinprodukte and mdc medical device certification.

What does a notified body actually check in a traceability matrix?

They sample rather than read it end to end. An auditor picks a requirement and follows it forward to verification evidence and back to the user need and the risk analysis, then does the same starting from a test result. What they are looking for is an orphan: a requirement with no verification, a risk control that never became a requirement, or a test with no requirement behind it.

This is why completeness matters more than presentation. A beautifully formatted matrix with three orphans in it fails; a plain one with none of them passes. The useful property of holding requirements as data is that the orphans are a query rather than a proofreading exercise.

Which standards does a German medical device team work to?

These are published in Germany as DIN EN versions of the international standards, and meeting them is how conformity gets demonstrated in practice.

ISO 13485 clause 7.3, design and development

Clause 7.3 is the requirements clause in all but name. Design inputs in 7.3.3, outputs in 7.3.4, review in 7.3.5, verification in 7.3.6, validation in 7.3.7 and control of changes in 7.3.9 form a chain, and an auditor reads it as a chain. Our explainer on traceability from user needs to CE marking walks that chain end to end.

ISO 14971 clause 7, risk control

Risk controls are requirements. Clause 7 requires that each control is implemented and verified and that you check it has not introduced a new hazardous situation. Clause 10 then requires production and post-production information to be collected and fed back. Neither is straightforward to evidence if the risk file and the requirements live in different systems. We cover the process in our ISO 14971 risk management guide.

IEC 62304 clause 4.3 and clause 5, software lifecycle

Software safety classification under clause 4.3, class A, B or C, decides how much of clause 5 you have to perform and document: software requirements analysis in 5.2, architectural design in 5.3, unit implementation and verification in 5.5, integration and integration testing in 5.6, and software system testing in 5.7. Traceability between system requirements, software requirements and tests is written into the standard. Our practical guide to IEC 62304 compliance goes clause by clause.

IEC 62366-1, usability engineering

Use related risks turn into a use specification and user interface requirements, and those get verified like any other requirement. Usability findings that never become requirements are among the most common gaps in a design record, and they surface the moment somebody traces a use error backwards looking for the control that was supposed to address it.

What does the DiGA route add for digital health applications?

If you are building a digital health application for the German reimbursement route, the DiGA fast track run by BfArM under paragraph 139e of Social Code Book V adds a further evidence set on top of MDR conformity: data protection, information security, interoperability, and proof of a positive healthcare effect.

Each of those becomes a requirement you have to trace and verify, and the application asks you to show it. Teams that already keep requirements, risk and test in one place find the DiGA dossier is largely an export. Teams that do not end up writing the same evidence twice, in two formats, with two chances to disagree with themselves.

Do your requirements have to be written in German?

Your internal requirements and design records do not. Information supplied to users and patients does, including instructions for use and labelling. Most German manufacturers work in English internally and control the German language outputs as approved translations of controlled content. The practical consequence for requirements management is that labelling content is itself a set of requirements with regulatory sources behind it, so a translation is a change to be controlled rather than a task that happens at the end.

Where does Matrix Req fit?

Matrix Req holds requirements, risks, test cases and results as linked data rather than as documents, so the traceability matrix is a view of the project rather than a deliverable somebody maintains, and technical documentation and the design history file are generated from that record. Matrix One is also independently certified to ISO/IEC 27001:2022 for information security management, which is the question most German quality and IT reviews reach in the first week. The Matrix Req product page covers the product in full, the risk management module covers the ISO 14971 side, and our ranking of the best requirements management software puts it against the rest of the category.

Do not buy Matrix Req if you are not building a regulated product. The whole design assumes you need design control, risk management and an audit trail, and if you do not, a general purpose issue tracker will be cheaper and lighter. If you are two people shipping a Class I device, documents and a spreadsheet will hold for a while, and the honest answer is to move when the manual version starts costing you more than the tool would.

Summary: what does requirements management in Germany come down to?

It comes down to a record that survives sampling. Annex I decides what you have to prove, the MPDG adds the national duties around it, and your notified body decides how hard the proof gets tested. Matrix Req is built so all three draw on one live record rather than documents that drift apart between audits.

1. Make the GSPR checklist a view of the record, not a spreadsheet maintained beside it.

2. Link risk to requirements to verification, because sampling runs in both directions and orphans are what get found.

3. Treat German labelling and instructions for use as controlled outputs with traceable inputs, not as a translation job at the end.

Last updated: 11 September 2026.