In Vitro Diagnostics under IVDR with Matrix Req
IVDR moved most of the market into notified body review for the first time. Matrix Req links your intended purpose and performance claims to the evidence behind them, with risk management and design control in the same system.
IVDR asks for evidence the old directive never did
Claims, evidence and risk in one traceable structure
Performance evaluation is the centre of the file. Scientific validity, analytical performance and clinical performance each need evidence, and each has to connect back to the intended purpose you claim.
Three development streams in one submission. The assay chemistry, the instrument and the analysis software are developed by different people to different standards and end up in the same technical file.
Legacy design history in Word and Excel. Products that predate IVDR usually have documentation written for a different regime, with no traceability layer to reuse.
Software is now a first class problem. Result interpretation, algorithms and companion applications fall under IEC 62304, which many diagnostics teams have never had to evidence before.
Generic tools speak MDR. Most requirements tools and templates are written around medical devices, so IVD specific language has to be retrofitted by the customer.
Intended purpose linked to evidence. Trace each performance claim to the requirement that specifies it and to the study records and verification that support it.
Risk management to ISO 14971. Hazards for an incorrect or delayed result managed as linked records, with risk controls tied to the requirements that implement them.
Assay, instrument and software together. One project can hold reagent, hardware and software requirements with different trace rules for each, so the technical file is assembled from a single source.
IEC 62304 for analysis software. Software items, safety classification and verification evidence held alongside the rest of the design, not in a separate tool.
Import what you already have. Existing requirements and traceability matrices come in from Excel and Word, so an IVDR remediation starts from your real documentation rather than a blank system.
IVDR asks for evidence the old directive never did
Performance evaluation is the centre of the file. Scientific validity, analytical performance and clinical performance each need evidence, and each has to connect back to the intended purpose you claim.
Three development streams in one submission. The assay chemistry, the instrument and the analysis software are developed by different people to different standards and end up in the same technical file.
Legacy design history in Word and Excel. Products that predate IVDR usually have documentation written for a different regime, with no traceability layer to reuse.
Software is now a first class problem. Result interpretation, algorithms and companion applications fall under IEC 62304, which many diagnostics teams have never had to evidence before.
Generic tools speak MDR. Most requirements tools and templates are written around medical devices, so IVD specific language has to be retrofitted by the customer.
Claims, evidence and risk in one traceable structure
Intended purpose linked to evidence. Trace each performance claim to the requirement that specifies it and to the study records and verification that support it.
Risk management to ISO 14971. Hazards for an incorrect or delayed result managed as linked records, with risk controls tied to the requirements that implement them.
Assay, instrument and software together. One project can hold reagent, hardware and software requirements with different trace rules for each, so the technical file is assembled from a single source.
IEC 62304 for analysis software. Software items, safety classification and verification evidence held alongside the rest of the design, not in a separate tool.
Import what you already have. Existing requirements and traceability matrices come in from Excel and Word, so an IVDR remediation starts from your real documentation rather than a blank system.
Core Features
What Matrix Req does for IVD manufacturers and diagnostics teams.
Hear from our customers




































































































FAQ
Yes. Matrix Req is configurable at the category and template level, so the item types, traces and document structure can be set up around the IVD lifecycle, including intended purpose, performance claims, analytical and clinical performance evidence, rather than an MDR shaped design control process with diagnostics language pasted over it.
Yes. A claim is held as a record and linked to the requirements that specify it and to the verification, validation and study evidence you load against them. Matrix Req manages the requirement, risk and evidence records and the links between them. It does not run the study or hold raw laboratory data, so the underlying datasets stay in your LIMS or statistical environment and are referenced from the traceable record.
Usually with an import. Existing requirements, risk assessments and traceability matrices come in from Excel and Word, which gives you a structured baseline to work from instead of a blank system. From there the Compliance Checker can hold your IVDR checklist and show which parts of the file are still unanswered, so remediation becomes a visible list rather than a guess.
Yes. IEC 62304 software lifecycle evidence, including software items, units and their verification, sits in the same project as the assay and the instrument. For a standalone diagnostic algorithm that is a device in its own right, see our page on software as a medical device.
Matrix Req covers design control, requirements, risk and verification. Processes such as document control, training, CAPA and supplier management belong in an eQMS, which is Matrix Quality in our suite, and the two work together so design records and quality processes are not in separate worlds. For an IVD manufacturer who needs requirements and design control under IVDR, Matrix Req is the place to start.