Medtronic: Managing a Global Requirements Engineering Operation for a Diversified Medical Device Portfolio
What enterprise-scale requirements engineering actually looks like when lives depend on traceability
Medtronic is not one company in any engineering sense. It is closer to fifteen companies operating under shared regulatory accountability. The cardiac rhythm management division builds implantable defibrillators governed by software safety standards, electromagnetic compatibility requirements, and decades of clinical evidence obligations. The diabetes division manages closed-loop insulin delivery systems that now include embedded algorithms subject to Software as a Medical Device (SaMD) classification. The surgical robotics group is integrating real-time imaging, robotic kinematics, and surgeon-interface software into a single device submission. Each of these is a distinct engineering domain. All of them must satisfy overlapping regulatory frameworks, and all of them are Medtronic’s problem simultaneously.
Understanding how an organization at this scale manages requirements engineering is useful not because most teams will face the same scope, but because the pressures Medtronic operates under — regulatory traceability at volume, distributed development teams, multi-standard compliance, portfolio-wide change management — are directionally identical to what mid-size medical device companies encounter as they grow. The difference is magnitude, not kind.
The Current State: Compliance at Portfolio Scale
Medtronic operates across more than 150 countries, maintains several hundred active product registrations at any given time, and routinely manages concurrent submissions to FDA, the European notified body system under MDR, and regulatory bodies in Japan, China, and Brazil. Each submission requires traceable, auditable evidence that product requirements were correctly derived, correctly implemented, and correctly verified.
The three frameworks that govern most of this work — IEC 62304 (software lifecycle processes for medical device software), ISO 14971 (risk management), and FDA 21 CFR Part 820 (quality system regulations, now supplemented by the Quality Management System Regulation finalized in 2024) — are not simply documentation standards. They impose specific engineering obligations that must be reflected in how requirements are structured, linked, and managed across the product lifecycle.
IEC 62304 requires that software requirements be traceable to system requirements and to software architecture, that each requirement be linked to verification evidence, and that the classification of software safety class (A, B, or C) drive the rigor of the entire development process. For a company like Medtronic, this means maintaining software safety class determinations — and all the downstream process obligations they trigger — across hundreds of software items spanning products that may be ten to twenty years old.
ISO 14971 adds a layer that is architecturally distinct from functional requirements management: every identified hazard must be traceable to risk control measures, and those measures must themselves appear as requirements in the product specification. The risk file and the requirements specification are not separate artifacts. They are the same artifact, viewed from two angles. Organizations that treat them as separate documents create audit findings and, more seriously, create the conditions under which a risk control measure gets implemented incompletely because no engineer knew it was a requirement.
21 CFR Part 820, and the newer QMSR alignment with ISO 13485:2016, requires that design inputs be unambiguously stated and traceable through design outputs to verification and validation records. The language is familiar to anyone who has read a design history file, but the operational reality of maintaining a compliant design history file for a product with thousands of requirements, dozens of subsystems, and a development history spanning multiple regulatory submissions is a significant information management problem.
What’s Actually Happening vs. the Organizational Ideal
The official model for how a medical device company like Medtronic manages this is clean: requirements flow from user needs to system requirements to subsystem requirements to software and hardware requirements, each level linked to the one above, verification methods defined, test cases executed, results recorded. Regulatory affairs reviews the chain. A submission package is assembled. An auditor can walk the full trace.
The operational reality is more complicated. Medtronic’s product lines span devices that were designed before requirements management tools existed in any mature form, devices that were acquired through merger and carried their own tooling and process histories, and new development programs that may be adopting current-generation approaches. The cardiac rhythm management portfolio alone contains products whose original design files were created in formats that predate the concept of linked requirements. Legacy device maintenance — required as long as the device is on the market — means someone is actively managing requirements for products designed before the engineers maintaining them were in the industry.
This creates a class of problem that is distinct from greenfield requirements management: the legacy reconciliation problem. When a change is required — a component obsolescence, a software patch, a label update with regulatory implications — the change must be traced through a requirements structure that may be partially reconstructed from historical documentation rather than natively linked. The risk is not that the change is made incorrectly in isolation. The risk is that a change to one requirement has downstream effects on others that the current team cannot see because the original linkages were never captured in a queryable form.
Geographic distribution compounds this. Medtronic’s engineering centers span the United States, Ireland, Switzerland, India, and China, among others. A cardiac device developed primarily in Minneapolis may have software components maintained in Galway and regulatory submissions managed in parallel for North America and Europe. Requirements that change for one market submission must be assessed for impact on others. Without a common, authoritative requirements repository with controlled access and version history, this kind of cross-geography impact assessment is done through email and meetings — which is to say, it is done inconsistently.
How the Systems Engineering and Regulatory Affairs Interaction Works
At Medtronic’s scale, systems engineering and regulatory affairs cannot operate as sequential handoffs. The FDA review process for a PMA supplement, a 510(k), or a De Novo classification requires that regulatory affairs understand the technical substance of what is being submitted deeply enough to respond to reviewer questions, identify information requests before they arrive, and make real-time decisions about what evidence will satisfy a given reviewer concern.
This requires regulatory affairs staff who understand requirements architecture, not just document structure. It also requires systems engineers who understand what a particular regulatory pathway demands, so that they make the right traceability decisions during development rather than reconstructing them retroactively for submission.
In practice, this integration is structural at Medtronic. Regulatory affairs is involved at design input review, not only at submission assembly. Risk management is reviewed against requirements at each design phase gate, not as a final compliance check. This is not unique to Medtronic — it is the intent of the frameworks — but executing it consistently across a diversified portfolio requires organizational design, not just policy.
The practical mechanism is the design history file review cycle. At each major phase gate, a cross-functional team including systems engineering, software engineering, risk management, and regulatory affairs reviews the state of the requirements against the regulatory pathway for that specific product and market. Gaps identified at phase gates are engineering problems, not paperwork problems. This distinction matters. A gap in traceability identified at a phase gate is a requirements engineering failure that must be corrected in the product record, not a documentation gap to be filled with a memo.
Practical Implications for Requirements Tool Strategy
The tool landscape for medical device requirements management is dominated by IBM DOORS and DOORS Next Generation, Jama Connect, and Polarion, with Codebeamer gaining significant traction in companies that need tighter integration between requirements and software development workflows. Each of these tools has genuine strengths, and at Medtronic’s scale, the likelihood is that multiple tools are in use across different divisions, with integration and cross-tool traceability itself becoming an engineering problem.
The structural limitation of document-centric and spreadsheet-adjacent tools becomes acute at enterprise portfolio scale. When a requirement exists in a document — even a well-linked document — querying the full impact of a change across the portfolio requires navigating the document structure manually or building custom reports. This is tractable for a single product. For a portfolio of hundreds of products with shared components, shared software modules, and shared risk control measures, it is not.
The industry is moving toward graph-based requirements models, where requirements, risks, hazards, verification records, and design elements are nodes in a connected data structure rather than sections of linked documents. This model makes impact analysis computable: a change to a shared software component can be queried against all products that include that component, all requirements that reference it, and all verification records associated with those requirements. Tools like Flow Engineering implement this graph-native approach specifically for hardware and systems engineering contexts, where the density of cross-domain dependencies makes document-based traceability operationally unworkable at scale. For a company managing the volume and diversity of the Medtronic portfolio, the architectural choice between document-centric and graph-native requirements management is not a preference — it is a scalability question.
Honest Assessment
Medtronic’s requirements engineering operation is not a solved problem that others should emulate uncritically. It is an ongoing engineering challenge that the company manages through organizational structure, process discipline, and significant investment in tooling and training. The challenges are real: legacy products with incomplete traceability, geographic distribution that creates synchronization problems, multi-standard compliance that requires requirements to serve multiple analytical frameworks simultaneously, and a regulatory environment that continues to evolve.
What Medtronic does well, and what the broader industry can learn from at any scale, is the structural integration of regulatory requirements into engineering process. Requirements traceability is not a submission artifact at Medtronic — it is an engineering deliverable at each phase gate. Risk management is not a parallel document — it is a requirements source. Regulatory affairs is not a downstream reviewer — it is a concurrent engineering function.
These are process and organizational decisions, not tool decisions. The tool infrastructure matters, and the move toward graph-based, AI-assisted requirements management is directionally correct for the complexity of modern medical device portfolios. But the tools serve the process. The companies that manage requirements engineering well at scale are the ones that have resolved the organizational question — who is accountable for traceability, when is it reviewed, and what does a gap mean for the program — before they resolve the tool question. Medtronic’s scale makes its approach visible. The underlying logic applies to any team managing more than one product under a compliance framework where traceability failure has consequences.