Requirements management software for medical devices in Germany
One traceable record from user need to verification evidence, built for EU MDR, the MPDG and a German notified body audit.
Medical device manufacturers selling in Germany work to three things at once: EU MDR 2017/745, the national provisions in the Medizinprodukterecht-Durchführungsgesetz, and a notified body that will sample your traceability line by line. Matrix Req is requirements management software built for exactly that job, holding one connected record from user need to risk control to verification evidence, with technical documentation generated from the record rather than assembled by hand.
This page covers what the German regulatory stack asks of your requirements process, the standards a German manufacturer is expected to meet, and what to look for in a tool.
Why requirements management is a regulatory problem in Germany
The MDR is a Regulation, so it applies directly in Germany with no national transposition needed. What the German system adds is the enforcement layer: BfArM at federal level, the authorities of the individual Länder for market surveillance, and notified bodies designated and supervised by the ZLG.
None of that asks you to buy software. All of it asks you to produce evidence that every requirement traces to its source, to its risk controls and to its verification, and that the evidence is current at the moment somebody asks for it.
That is where document based processes struggle. A traceability matrix maintained by hand is out of date the day after it is written, and an auditor samples in a direction you did not prepare for.
The German regulatory stack that shapes your requirements process
EU MDR 2017/745 and the general safety and performance requirements
Annex I of the MDR sets the general safety and performance requirements, the GSPRs. For each one you have to show either that it applies and how you met it, or that it does not apply and why. Annex II then asks for design and manufacturing information as part of the technical documentation. In practice the GSPR checklist becomes the spine of your submission, and every entry on it needs to point at a real requirement, a real risk control and a real test result.
The MPDG and the German national provisions
The Medizinprodukterecht-Durchführungsgesetz has been in force since 26 May 2021, replacing the older Medizinproduktegesetz. It carries the German provisions that sit alongside the MDR, covering clinical investigations, vigilance duties, language obligations and the penalties that apply when they are not met. The Medizinprodukte-Durchführungsverordnung fills in the procedural detail.
BfArM and the Länder authorities
BfArM is the federal higher authority for medical devices. It handles vigilance, clinical investigation approvals and the DiGA directory. Routine market surveillance sits with the individual state authorities, which is why a German inspection can arrive from a Land body rather than from Bonn.
Notified bodies designated in Germany
Germany hosts several of the busiest MDR notified bodies, among them TÜV SÜD, TÜV Rheinland, DQS Medizinprodukte and mdc medical device certification. They are designated and monitored by the ZLG. Whichever one you work with, the audit pattern is much the same. An auditor picks a requirement, walks it forward to verification evidence, walks it back to the user need and the risk analysis, and sees whether the record holds.
Standards a German manufacturer is expected to meet
These are published in Germany as DIN EN versions of the international standards. Meeting them is how conformity gets demonstrated in practice.
ISO 13485 design and development
Clause 7.3 is the requirements clause in everything but name: design inputs, design outputs, review, verification, validation, transfer, change control, and the design history file that holds the result. Auditors read it as a chain, so a gap anywhere along it becomes a finding.
ISO 14971 risk management
Risk controls are requirements. Every control you introduce to reduce a risk has to be implemented, verified, and shown not to have introduced a new risk. If your risk file and your requirements live in separate systems, that link is manual and it will drift.
IEC 62304 software lifecycle
If your device contains software, IEC 62304 sets the lifecycle: software requirements derived from system requirements, architecture, detailed design, unit implementation and verification, then integration and system testing. The software safety class, A, B or C, decides how much of that you have to document. The traceability expectation is explicit rather than implied.
IEC 62366-1 usability engineering
Use related risks become use specifications and user interface requirements, and they need verification like anything else. Usability findings that never turn into requirements are one of the more common audit gaps.
Requirements management for DiGA 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.
German language obligations
Germany requires information for users and patients in German, including instructions for use and labelling. That matters for requirements management because labelling content is itself a set of requirements with regulatory sources behind it, and translation is a change that has to be controlled rather than a task that happens at the end. Treating your instructions for use as a controlled output with traceable inputs costs less than treating it as a document that one person owns.
What to look for in requirements management software for the German market
Matrix Req was built to meet all eight of these, which is why they are the list we would hand to any German team running a selection.
Live traceability rather than a generated report. If your matrix is a document you produce, it is stale. If it is a view of the data, it is current.
Risk in the same system as requirements, so ISO 14971 controls link to requirements and verification without a manual step.
IEC 62304 structure available out of the box, including software safety class and the software item hierarchy.
A GSPR view, so you can answer Annex I from the tool instead of from a separate spreadsheet.
Document output your notified body will accept: technical documentation, design history file and traceability exports.
Change control with a real audit trail, because the audit question is usually why something changed and who approved it.
Integrations with the tools your engineers already use, so requirements do not get entered twice.
A data model that fits a medical device rather than a general purpose engineering tool bent into shape.
How Matrix Req fits a German medical device team
One record, live traceability
Requirements, risks and tests sit in the same system and link to each other directly. The traceability matrix is a view of that data, so it reflects the state of the project rather than the state of the last export.
Technical documentation and the design history file
Documents are generated from the live record, which means the design history file is current by default and the technical documentation you hand a notified body matches what your engineers actually did.
Software under IEC 62304
Software requirements, architecture and test evidence carry the structure the standard expects, with safety classification held against the software items rather than tracked on the side.
Ready for an audit
Because sampling runs in both directions, the useful property is completeness: no requirement without verification, no risk control that never became a requirement, no test with nothing behind it. Those gaps are visible in the tool before an auditor finds them.
Certified information security
Matrix One is independently certified to ISO/IEC 27001:2022 for information security management, which is the question most German quality and IT reviews reach within the first week.
Common questions
Does EU MDR require requirements management software?
No. The MDR names no tool and no category of tool. It requires design controls, traceability and technical documentation that are complete and current. You can meet that with documents and spreadsheets, and plenty of small manufacturers do. Teams move to software because the manual version gets expensive to keep accurate as the device and the team grow, and audit exposure rises with every stale link.
Do our requirements have to be written in German?
Your internal requirements and design records do not. Information supplied to users and patients does. Most German manufacturers work in English internally and control the German language outputs as approved translations of controlled content.
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.
We already use Jira. Does that change the answer?
Jira handles engineering workflow well and it is not a design control record. Matrix Req has native two way integrations with Jira, Azure DevOps, GitHub and GitLab, so development work stays where your engineers are while the regulatory record stays complete.
Does any of this apply to in vitro diagnostics?
The pattern is the same, but the regulation is the IVDR, 2017/746, with its own Annex I performance requirements and its own classification rules. The German national layer and the authorities are unchanged.
Matrix Req is used by medical device teams working to MDR, ISO 13485, ISO 14971 and IEC 62304, and it is built so the traceability a German notified body asks for is a view of your live data rather than a document you rebuild before every audit. If you want to see it against your own device and your own notified body, book a demo.