Skip to main content

Medical Imaging and AI Diagnostics with Matrix Req

An AI diagnostic is a device that keeps changing. Matrix Req keeps the clinical claim, the algorithm requirement, the model version and the evidence that proves it in one traceable chain.

Matrix Requirements
The challenge
Our solution

The device changes after you clear it, and the file has to keep up

One traceable chain from clinical need to model version

  • Software is the device. IEC 62304 applies in full, and the software safety classification argument has to be documented and defended rather than assumed.

  • Performance claims need traceable proof. Sensitivity, specificity and the intended population are claims, and each one has to connect to the requirement that specifies it and the evidence that supports it.

  • Model versions are configuration items. Which model, trained on which data, validated by which study, cleared under which submission, is a question most document based systems cannot answer.

  • Change control for a moving product. Retraining and algorithm updates have to be planned and controlled, which is what a predetermined change control plan is for, and it needs records behind it.

  • Regulation is stacking up. MDR or IVDR, IEC 62304, ISO 14971, and for many products the EU AI Act on top, all evidenced from the same design history.

  • Claims traced to evidence. Every performance claim links to the requirement that specifies it and the verification or clinical evidence that supports it.

  • Model versions as controlled items. Hold the model version, its intended use and its verification results as records in the traceability structure, linked to the release they belong to.

  • ISO 14971 for algorithm failure modes. Model hazards specific to an AI diagnostic, including incorrect classification and out of distribution input, with risk controls linked to the requirements that mitigate them.

  • Imaging hardware and software together. For teams building both a scanner or capture device and the software that reads it, one project covers both rather than two disconnected sets.

  • Traceability into the code. Links to GitHub and GitLab work and a two way Jira sync keep the requirement connected to the change that implemented it.

  • The challenge

    The device changes after you clear it, and the file has to keep up

  • Software is the device. IEC 62304 applies in full, and the software safety classification argument has to be documented and defended rather than assumed.

  • Performance claims need traceable proof. Sensitivity, specificity and the intended population are claims, and each one has to connect to the requirement that specifies it and the evidence that supports it.

  • Model versions are configuration items. Which model, trained on which data, validated by which study, cleared under which submission, is a question most document based systems cannot answer.

  • Change control for a moving product. Retraining and algorithm updates have to be planned and controlled, which is what a predetermined change control plan is for, and it needs records behind it.

  • Regulation is stacking up. MDR or IVDR, IEC 62304, ISO 14971, and for many products the EU AI Act on top, all evidenced from the same design history.

  • Our solution

    One traceable chain from clinical need to model version

  • Claims traced to evidence. Every performance claim links to the requirement that specifies it and the verification or clinical evidence that supports it.

  • Model versions as controlled items. Hold the model version, its intended use and its verification results as records in the traceability structure, linked to the release they belong to.

  • ISO 14971 for algorithm failure modes. Model hazards specific to an AI diagnostic, including incorrect classification and out of distribution input, with risk controls linked to the requirements that mitigate them.

  • Imaging hardware and software together. For teams building both a scanner or capture device and the software that reads it, one project covers both rather than two disconnected sets.

  • Traceability into the code. Links to GitHub and GitLab work and a two way Jira sync keep the requirement connected to the change that implemented it.

  • Core Features

    What Matrix Req does for imaging and AI diagnostic teams.

    IEC 62304 Evidence for a Software DeviceSoftware items, units, safety classification and verification held together, with the traceability a notified body or an FDA reviewer expects to follow.Learn more
    Model Version TraceabilityRecord which model version was verified by which evidence and shipped in which release, so the question of what is actually cleared has a documented answer.
    Risk Management for AI Failure ModesManage hazards specific to an algorithmic result to ISO 14971, with risk controls linked to the requirements and tests that address them.Learn more
    Design Control and Change ImpactBefore an algorithm or requirement change, see what it affects downstream and which verification has to be repeated, which is the record set a change control plan depends on.Learn more
    Gap Checking Against a StandardImport a standard or build your own checklist, and the AI Compliance Checker shows where the documentation does not yet answer it.Learn more
    Submission Documentation Generated From RecordsProduce the technical file, design history and traceability matrices from the live system rather than assembling a package by hand for each submission.Learn more

    Hear from our customers

    With Matrix Req, we avoid all the challenges of using manual or custom-developed tools. Instead, we get a purpose-built solution that’s designed by medical device experts, enabling much faster ISO 13485 compliance.”

    François Audéon, Chief Technology Officer

    Matrix One is trusted by 500+ Life Sciences & Medical Device Companies

    FAQ

    Can Matrix Req track which model version was validated and released?

    Yes. Model versions can be held as controlled items in the traceability structure, linked to the requirements they satisfy, the verification evidence that supports them and the release they were shipped in. That is what makes it possible to answer, months later, which algorithm version a given claim and a given submission actually refer to.

    Does Matrix Req help with a predetermined change control plan?

    It holds the records a change control plan relies on. The plan itself is your regulatory submission, and Matrix Req keeps the requirements, risk assessments, verification protocols and results that define what may change, what triggers re verification and what evidence each change produces. Impact analysis then shows what a specific change touches before it is made.

    We build both the imaging hardware and the software that reads it. Can one project cover both?

    Yes. Optical or acquisition hardware requirements, embedded firmware and the analysis software can sit in the same project with different trace rules between them, so the system level claim traces down into both the device and the algorithm rather than into two separate document sets.

    How is this different from your software as a medical device page?

    The software as a medical device page covers IEC 62304 and SaMD design control generally. This page is for teams whose device is an imaging system or an AI diagnostic specifically, where model versioning, algorithm performance claims and controlled retraining are the parts that standard SaMD guidance does not fully answer. The underlying platform is the same.

    Does Matrix Req address the EU AI Act as well as MDR?

    Matrix Req does not classify your product under the AI Act, which is a regulatory assessment you make. What it does is hold the requirement, risk and evidence records in a single traceable structure, so the overlapping obligations from MDR or IVDR, IEC 62304, ISO 14971 and the AI Act are answered from one design history rather than from three parallel document sets. For an imaging or AI diagnostic team that needs that in one place, Matrix Req is our recommendation.