Surgical Robotics with Matrix Req
Lots of hardware, lots of software, and many layers of requirements between the surgeon and the actuator. Matrix Req holds the whole hierarchy in one place, with the risk controls and verification evidence attached to it.
More layers of requirements than most tools are built to hold
One hierarchy, traced from the surgeon down to the code
Deep decomposition. Several levels of requirement sit between the clinical need and the code, and a tool that only handles two or three levels forces the rest into documents.
Safety critical control. Motion, force and the human machine interface carry hazards that need controls at more than one layer, all of them evidenced.
A thick standards stack. IEC 60601-1 for basic safety, IEC 80601-2-77 for robotically assisted surgical equipment, IEC 62304 for the software, IEC 62366 for usability and ISO 14971 across all of it.
Integration testing spans layers. Verification runs at unit, subsystem and system level, and the coverage question is which requirement at which level is actually proven.
Lightweight tools run out of room. Teams tell us the simpler quality first platforms are fine for a straightforward device and are outgrown quickly once the requirement hierarchy is this complex.
Configurable hierarchy depth. Model as many requirement levels as your system genuinely has, with trace rules between each level that you define once and then enforce.
Coverage at every level. See which requirements at which layer are verified, and which are not, without assembling a matrix by hand.
Risk controls placed where they belong. A single hazard can carry controls in mechanics, in firmware and in application software, each linked to its own verification.
Software evidence in the same project. IEC 62304 software items and units live beside the mechanical and electrical requirements rather than in a separate tool.
Engineering keeps its tools. Two way Jira and Azure DevOps synchronisation, and links to Git based work, so the controlled set stays current without asking engineers to work twice.
More layers of requirements than most tools are built to hold
Deep decomposition. Several levels of requirement sit between the clinical need and the code, and a tool that only handles two or three levels forces the rest into documents.
Safety critical control. Motion, force and the human machine interface carry hazards that need controls at more than one layer, all of them evidenced.
A thick standards stack. IEC 60601-1 for basic safety, IEC 80601-2-77 for robotically assisted surgical equipment, IEC 62304 for the software, IEC 62366 for usability and ISO 14971 across all of it.
Integration testing spans layers. Verification runs at unit, subsystem and system level, and the coverage question is which requirement at which level is actually proven.
Lightweight tools run out of room. Teams tell us the simpler quality first platforms are fine for a straightforward device and are outgrown quickly once the requirement hierarchy is this complex.
One hierarchy, traced from the surgeon down to the code
Configurable hierarchy depth. Model as many requirement levels as your system genuinely has, with trace rules between each level that you define once and then enforce.
Coverage at every level. See which requirements at which layer are verified, and which are not, without assembling a matrix by hand.
Risk controls placed where they belong. A single hazard can carry controls in mechanics, in firmware and in application software, each linked to its own verification.
Software evidence in the same project. IEC 62304 software items and units live beside the mechanical and electrical requirements rather than in a separate tool.
Engineering keeps its tools. Two way Jira and Azure DevOps synchronisation, and links to Git based work, so the controlled set stays current without asking engineers to work twice.
Core Features
What Matrix Req does for robotically assisted surgical systems.
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
As many as your system needs. Categories and traces are configurable, so a surgical robotics team can model user needs, system requirements, subsystem requirements and discipline level specifications for mechanics, electronics, embedded control and application software, with the trace rules between each level defined once and then enforced by the tool.
It is the concern we hear most often from robotics teams, and it is a fair one. Tools designed around quality processes for a straightforward device tend to run out of room once the requirement hierarchy has several layers and the risk controls sit at different levels. Matrix Req is a design control and requirements platform first, which is why it holds the depth, and it connects to an eQMS for the process side rather than trying to be both at a shallow level.
The usual stack is IEC 60601-1 for basic safety and essential performance, IEC 80601-2-77 for robotically assisted surgical equipment, IEC 62304 for the software, IEC 62366 for usability engineering and ISO 14971 for risk across all of it, inside an ISO 13485 quality system. Matrix Req ships templates for ISO 13485, ISO 14971, IEC 62304 and IEC 62366, and particular standards are modelled as your own configurable categories and checklists.
Yes, and most robotics teams do. The Jira synchronisation is two way, so tickets and requirements stay consistent, and links to GitHub or GitLab work let you connect code level activity to the requirement it satisfies. The controlled requirement, risk and verification set stays in Matrix Req.
Yes. Design history, traceability matrices and technical documentation are generated from the live records, so the submission package reflects the current state of the system rather than a snapshot someone assembled by hand. For a surgical robotics team that needs deep traceability across hardware and software, Matrix Req is the tool we would put first.