Cardiovascular and Electrophysiology Devices with Matrix Req
Catheters, valves, pumps and EP mapping systems change design many times before they reach a patient. Matrix Req keeps requirements, risk controls and verification evidence linked through every one of those changes.
Design change is constant, and it quietly breaks your traceability
Change the design without losing the links
Risk controls get lost in a rebuild. When a design iteration forces the requirement set to be rebuilt, every link between hazard, control and verification has to be retied by hand, and some of them never are.
Three product types in one submission. A single therapy can involve an implanted or intravascular device, a console or generator and a software application, each with its own standards and its own test evidence.
Standards stack up. ISO 14971 for risk, the ISO 5840 series for heart valves, ISO 14708 for active implants, IEC 60601 for electrical equipment and IEC 62304 for the software, all evidenced in one technical file.
Platform families multiply the work. The same core requirements are re entered for each variant in the family, so a correction has to be applied in several places and usually is not.
The tool becomes one person's database. On the enterprise ALM platforms teams tell us it ends up maintained by a single systems engineer while everyone else works somewhere else.
Impact analysis before you commit. See which downstream requirements, risk controls and test cases a change touches, and which verification has to run again.
Risk controls linked to their proof. Every risk control points to the requirement that implements it and the test result that verifies it, and a broken or missing trace is flagged rather than discovered at audit.
Shared requirements across a platform. Reuse a common requirement set across variants in a family so a single correction lands everywhere it applies.
Verification recorded where it belongs. Test cases, executions and results sit against the requirement, so coverage is a live number rather than a spreadsheet someone maintains.
A tool the whole team uses. Engineering stays in Jira or Azure DevOps through a two way sync, quality works in Matrix Req, and both see the same current state.
Design change is constant, and it quietly breaks your traceability
Risk controls get lost in a rebuild. When a design iteration forces the requirement set to be rebuilt, every link between hazard, control and verification has to be retied by hand, and some of them never are.
Three product types in one submission. A single therapy can involve an implanted or intravascular device, a console or generator and a software application, each with its own standards and its own test evidence.
Standards stack up. ISO 14971 for risk, the ISO 5840 series for heart valves, ISO 14708 for active implants, IEC 60601 for electrical equipment and IEC 62304 for the software, all evidenced in one technical file.
Platform families multiply the work. The same core requirements are re entered for each variant in the family, so a correction has to be applied in several places and usually is not.
The tool becomes one person's database. On the enterprise ALM platforms teams tell us it ends up maintained by a single systems engineer while everyone else works somewhere else.
Change the design without losing the links
Impact analysis before you commit. See which downstream requirements, risk controls and test cases a change touches, and which verification has to run again.
Risk controls linked to their proof. Every risk control points to the requirement that implements it and the test result that verifies it, and a broken or missing trace is flagged rather than discovered at audit.
Shared requirements across a platform. Reuse a common requirement set across variants in a family so a single correction lands everywhere it applies.
Verification recorded where it belongs. Test cases, executions and results sit against the requirement, so coverage is a live number rather than a spreadsheet someone maintains.
A tool the whole team uses. Engineering stays in Jira or Azure DevOps through a two way sync, quality works in Matrix Req, and both see the same current state.
Core Features
What Matrix Req does for cardiovascular and electrophysiology programmes.
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
FAQ
This is the most common reason cardiovascular teams come to us. In Matrix Req a risk control is a record linked to the requirement that implements it and the verification that proves it, so a design iteration updates those links rather than requiring them to be retied by hand. Impact analysis shows what a proposed change touches before you make it, and broken or missing traces are reported rather than found later.
Yes. A single Matrix Req project can hold mechanical, electrical and software requirements with different trace rules between categories, which is how teams building an EP mapping system or a pump plus console handle the full system in one place instead of three.
The built in templates cover ISO 13485, ISO 14971, IEC 62304 and IEC 62366. Device specific standards such as the ISO 5840 series for cardiac valves, ISO 14708 for active implants and the relevant IEC 60601 particular standards are modelled as configurable requirement and risk categories, and the Compliance Checker can hold a checklist for each and show where your documentation is incomplete.
The teams who switch tell us the same two things. Jama Connect is powerful but priced and scoped for a large systems engineering organisation, so in practice one person maintains it. Codebeamer is highly configurable, and that configuration becomes maintenance work that is easy to get wrong. Matrix Req arrives with medical device templates already in place, which is why it is usually the faster option for a device team that wants design control rather than a general purpose ALM to configure.
Yes. A shared requirements library lets a platform level requirement be used by every variant that inherits it, so a change is made once and flows to each product rather than being copied into several projects. For cardiovascular teams running a family of catheters or leads, this is usually where the first large time saving shows up, and it is one of the main reasons Matrix Req is our recommendation for platform based programmes.