Medical Device Hardware Is Getting More Complex and the FDA Is Paying Attention
Combination products, AI-enabled diagnostics, and connected implantables are pushing medical device hardware into territory that legacy device frameworks were not designed for.
The FDA’s 510(k) and PMA frameworks were built in an era when a cardiac monitor was a cardiac monitor. It measured, it displayed, it alarmed. The hardware was the device. Software, if present, was firmware—embedded, static, and thoroughly subordinate to the physical artifact being cleared.
That era is over.
Today’s medical device hardware increasingly contains or communicates with AI inference engines that adapt post-clearance. It connects to hospital networks, patient smartphones, and cloud platforms in ways that create novel failure modes. It combines drug delivery with sensing in single-patient-contact assemblies that don’t map cleanly to any single FDA regulatory pathway. The hardware hasn’t gotten simpler. The regulatory surface around it has expanded dramatically.
Engineers at medical device OEMs are now managing requirements and traceability obligations that span FDA Center for Devices and Radiological Health (CDRH), the Center for Drug Evaluation and Research (CDER), cybersecurity guidance, SaMD frameworks derived from the International Medical Device Regulators Forum (IMDRF), and a growing body of AI/ML-specific agency action plans. Many are doing this with tools—DOORS, Word, Excel—that were designed for a different problem.
The companies getting ahead of this curve are not just buying new software. They are rethinking how requirements relate to one another across hardware, software, and regulatory touchpoints. That architectural shift is the real story.
What’s Actually Changed in the Regulatory Landscape
SaMD and the Collapsing Hardware/Software Boundary
Software as a Medical Device, as defined by IMDRF and adopted by FDA, is software that performs a medical purpose without being part of a hardware device. That definition sounds clean until you try to apply it to a continuous glucose monitor that pairs with a smartphone app that provides dosing recommendations. The sensor hardware is a device. The app may be SaMD. The system that emerges from their interaction is a combination that doesn’t fit either bucket neatly.
FDA’s 2021 guidance on AI/ML-based SaMD introduced the concept of the predetermined change control plan (PCCP)—a mechanism that lets manufacturers propose upfront how their AI will be modified post-clearance without triggering a new submission for each update. The intent is to accommodate the reality that machine learning models improve over time. The practical burden on hardware engineers is significant: they must now document not just what the device does at time of clearance, but the envelope of changes the hardware can support, what validation those changes require, and how changes to the AI component propagate to hardware performance claims.
For hardware engineers used to writing requirements against a fixed design, this is a structural change in how requirements work. A requirement is no longer a statement about a static design. It is a node in a system that must accommodate planned evolution.
Combination Products: One Product, Three Regulatory Centers
Combination products—devices that combine drug, device, and/or biological components—are assigned a primary mode of action and routed to a lead FDA center, with consulting review from the others. That administrative clarity does not reduce engineering complexity. A drug-eluting vascular stent requires hardware documentation meeting device standards AND chemistry/manufacturing/controls documentation meeting drug standards, in a single integrated package.
The Office of Combination Products (OCP) has been progressively tightening expectations on how combination product manufacturers document and demonstrate that the constituent parts function as an integrated system. The 2022 final rule on Current Good Manufacturing Practice for combination products reinforced that manufacturers must have a unified quality system—not parallel silos. Engineers building combination products now need a requirements architecture that traces from top-level system requirements down through both device-constituent and drug-constituent specifications in a way that satisfies reviewers from both centers simultaneously.
This is not a problem Word and Excel solve gracefully. Reviewers from different centers will look at the same submission and apply different lenses. If your traceability lives in separate documents, gaps appear. If it lives in a connected model, reviewers can navigate it from their entry point and arrive at consistent answers.
Connected Implantables and the Cybersecurity Overlay
The 2022 Omnibus spending bill gave FDA explicit authority to require cybersecurity documentation as a condition of medical device submission acceptance. The March 2023 refuse-to-accept guidance that followed means submissions for devices with network connectivity—including connected implantables like neurostimulators, cardiac rhythm devices, and cochlear implants with remote management capabilities—must include a software bill of materials (SBOM), a description of the cybersecurity architecture, and a plan for post-market updates.
For hardware engineers, cybersecurity requirements are not software requirements that can be delegated to the firmware team. The hardware security architecture—secure boot roots, cryptographic key storage, physical tamper resistance, interface isolation—must be specified in hardware requirements and traced to system-level security claims. If those hardware security requirements don’t exist as traceable artifacts, they cannot be verified, and the submission has a gap FDA will find.
Connected implantables also face the possibility of simultaneous SaMD classification if their software component makes diagnostic or therapeutic inferences. A cardiac implantable electronic device that uses onboard AI to detect arrhythmia patterns and adjust therapy may find that its AI module is subject to PCCP expectations at the same time its connectivity is subject to cybersecurity submission requirements. Managing those two regulatory threads through a single coherent traceability structure is not optional—it is what a complete submission requires.
What Companies Ahead of the Curve Are Actually Doing
Treating Requirements as a Live System, Not a Document
The distinguishing process characteristic of medical device companies that handle complex regulatory submissions well is that they have moved away from document-centric requirements management. Their requirements live in a connected structure where relationships between requirements, design elements, verification records, and regulatory citations are explicit and navigable.
This matters for a specific operational reason: FDA reviewers increasingly ask questions that require tracing from a clinical claim backward to design verification evidence. “How does the device ensure this safety claim holds when the AI model is updated?” is not answerable by pointing to a PDF. It requires a live trace from the clinical claim through the PCCP to the hardware performance envelope to the verification protocol that bounds the hardware’s contribution to system safety.
Companies with graph-structured requirements architectures can answer that question in hours. Companies with document-based RTMs answer it in days—or don’t answer it fully, which generates a major deficiency letter.
Building Cross-Constituent Traceability from Day One
Combination product manufacturers who have been through OCP scrutiny have learned that retrofitting unified traceability onto separately developed constituent documentation is expensive and error-prone. The companies ahead of this problem start the program with a single requirements hierarchy that explicitly identifies which nodes are device-constituent, which are drug-constituent, and which are system-level claims that span both.
This requires more upfront discipline. It also requires that the requirements tool can handle the structural complexity—requirements with multiple parent-child relationships, requirements tagged to regulatory citations from different centers, and verification records that may be generated by different teams with different workflows.
Legacy tools like IBM DOORS can technically represent this structure, but the operational overhead of maintaining it correctly—especially as the design evolves—is high enough that many teams let it slip. The RTM becomes stale. The submission reflects a design that no longer matches the current state.
Designing for Post-Market Surveillance Traceability
The FDA’s 2025 post-market AI/ML guidance reinforced something that forward-looking device manufacturers had already internalized: the regulatory relationship doesn’t end at clearance. For AI-enabled devices, post-market performance data feeds back into the change management process. Hardware engineers need to ensure the requirements and verification artifacts from pre-market are structured in a way that supports post-market change impact analysis.
A hardware engineer changing a sensor component two years after clearance needs to know, quickly, which system-level performance claims that component contributes to, which clinical claims those performance claims support, and whether the change falls within the hardware envelope defined in the PCCP. If the requirements structure doesn’t support that analysis, the change triggers a full re-evaluation—which delays time to market and increases regulatory risk.
How Modern Tooling Addresses This
Tools like Jama Connect and Polarion have both invested in features designed for medical device traceability—configurable review workflows, audit trails, and templates that align with IEC 62304 (software lifecycle) and ISO 14971 (risk management). Both are credible choices for teams with mature processes and dedicated regulatory affairs personnel who can manage the configuration overhead.
Innoslate has gained traction with systems engineering teams who need behavioral modeling alongside requirements, which is relevant for combination products where device constituent interactions need to be simulated before physical integration.
For teams managing the AI/ML complexity layer specifically—where requirements must accommodate planned change, where the traceability surface includes a PCCP, and where post-market feedback loops need to connect back to pre-market requirement structures—the tooling requirements are more demanding. The graph needs to be live and queryable, not a static document export.
Flow Engineering was built specifically for hardware and systems engineering teams who need that kind of connected, AI-native requirements structure. Its graph-based architecture means that when a hardware requirement changes, the downstream effects—on verification plans, on system-level claims, on regulatory citations—are immediately visible rather than requiring a manual audit of linked documents. For medical device programs managing the intersection of SaMD, combination product, and cybersecurity requirements, that live connectivity is not a convenience feature. It is what makes the traceability audit survivable.
Flow Engineering’s current focus is on the requirements and traceability layer rather than full document generation for regulatory submissions, which means teams will still need a downstream process for formatting submission packages. That’s a deliberate specialization, not a gap—the requirements graph feeds that downstream work rather than trying to replace it.
What FDA Reviewers Are Actually Finding
Conversations with regulatory affairs professionals who have navigated recent CDRH submissions for AI-enabled devices and combination products point to consistent themes in deficiency letters:
Incomplete impact analysis for AI changes. PCCPs that describe what will change but don’t trace those changes to hardware performance boundaries generate questions about whether the hardware was designed to support the proposed change envelope.
Cybersecurity requirements that stop at software. Hardware security architecture—secure element specifications, key management hardware, interface isolation—is frequently missing from requirements traceability even when the submission includes a cybersecurity architecture narrative.
Disconnected constituent documentation in combination products. Submissions where the device constituent documentation and the drug constituent documentation are internally consistent but don’t trace to a common system-level specification create reviewer confusion and generate cross-center coordination delays.
Post-market surveillance plans that don’t connect to pre-market claims. Reviewers from CDRH’s Digital Health Center of Excellence are asking how performance monitoring data connects to the specific clinical performance claims made in the submission. Teams that can answer that question with a traceable link have a structural advantage.
Honest Assessment
The regulatory complexity facing medical device hardware engineers is real, substantial, and still evolving. FDA’s AI/ML action plan commitments, the combination product CGMP rule, and the cybersecurity refuse-to-accept policy are not hypothetical pressures—they are showing up in actual submission interactions right now.
The honest reality is that no tooling change alone resolves this. The underlying problem is that hardware engineering teams are being asked to manage a requirements architecture of substantially greater structural complexity than what most programs have historically maintained. A better tool helps, but only if the team also rethinks how requirements are structured, how they relate to regulatory touchpoints, and how they stay live through a program lifecycle that now explicitly includes post-market evolution.
Companies that are ahead of this curve have done both. They have better tooling and a different process philosophy—one that treats the requirements structure as a system to be maintained rather than a document to be produced. The teams still building RTMs in Excel for programs that include AI inference engines and wireless connectivity are carrying regulatory debt that will come due, if not at clearance, then at the first post-market change request.
The FDA is paying attention. The teams that will navigate the next five years of medical device hardware development with the least friction are the ones building traceable, live, graph-structured requirements architectures now—before a deficiency letter explains why they should have.