AI for Medical Device Design Reviews: How Top Teams Run Them

The packet went out on Monday. By Wednesday afternoon, when the review started, it described a design that no longer existed.

That is the situation this article is built around, and it is a composite, not a case study. No real team, name or result is behind it. Mechanical and quality engineers on device programs will recognize the pattern: a design review gets assembled from exports, screenshots and a spreadsheet, then goes stale the moment someone touches the CAD.

The fix is not a better template. It is holding the review where the evidence lives: against the requirement, the architecture node, the CAD change and the verification evidence, all at once. AI helps most before the meeting, when it finds what moved and what no longer has proof behind it. This piece covers what a device design review has to prove, what in-context review looks like, where AI agents fit, how to judge design review software, and what Tandem does and does not do.

A composite scenario: the review packet that was stale before the meeting started

Picture a mechanical engineer and a quality engineer preparing a design review for a handheld device housing with a sealed battery compartment. The mechanical engineer owns the enclosure in SolidWorks. The quality engineer owns the design history file and will sign the review record.

On Monday, the quality engineer builds the packet: a PDF of the requirement table, screenshots of the assembly, a verification spreadsheet, and last month's risk file. On Tuesday, the mechanical engineer thickens a rib near the battery door to fix a sink mark found in a molding trial. It is a small, sensible change. Nobody tells the packet.

On Wednesday the review opens. Someone asks whether the ingress requirement still has passing evidence. The spreadsheet says yes. The evidence it points to was gathered against the old geometry. The quality engineer notices only because the rib looks different from the screenshot. Most of the meeting goes to reconstruction instead of review.

Nobody was negligent. Each artifact was correct when it was made. The failure is structural: the packet is a copy, and copies decay. Every hand-built review packet has this flaw, and no amount of diligence removes it, because the design keeps moving while the document sits still.

The rest of this article treats that Wednesday as the problem to solve. The goal is a review where the mechanical engineer's Tuesday change is already visible to the quality engineer on Wednesday, attached to the requirements and evidence it touches.

What a medical device design review has to prove (ISO 13485 7.3.5 and FDA's QMSR on independent reviewers)

A design review in a device quality system is not a status meeting. ISO 13485 clause 7.3.5 requires systematic reviews of design and development at suitable stages, planned and documented, to evaluate whether the design results can meet requirements and to identify problems and propose actions. Participants include representatives of the functions concerned with the stage being reviewed, plus any specialist personnel needed, and the results of reviews and any necessary actions are recorded. Verification and validation sit next to it, in clauses 7.3.6 and 7.3.7.

The US side has moved. FDA's Quality Management System Regulation, which amends 21 CFR Part 820 and incorporates ISO 13485 by reference, takes effect on February 2, 2026 (FDA, QMSR final rule, 2024). The older Part 820 design review language asked for an individual who does not have direct responsibility for the design stage being reviewed. Confirm the current text against FDA's published QMSR and your own procedures. How that independence expectation carries into the new framework is exactly the kind of detail an auditor will probe.

Whatever the wording, the practical demands are the same. A review has to show:

• Which requirements and design inputs were in scope, at which revision.

• What the design looked like at that point, not a month earlier.

• What verification evidence existed, and whether it still applied.

• Who reviewed, including someone without direct responsibility for the stage.

• What was decided, and what actions came out.

That list rewards currency and linkage. A review record that cannot say which design state it examined proves very little. So the stale packet is more than an annoyance. In an audit, it becomes a record of reviewing something other than what shipped.

Holding the review in context: requirement, architecture node, CAD change and verification evidence

In-context review means the thing being reviewed is never separated from what justifies it. Four objects sit together:

1. The requirement, with its parent, owner and approval state.

2. The architecture node it is allocated to, such as the battery compartment subassembly.

3. The CAD change that touched that node.

4. The verification evidence tied to the requirement, and its relationship to the design state it was gathered against.

Run the composite scenario this way. The rib change lands against the battery compartment node. The reviewers open the ingress requirement and see the linked CAD change next to it, with the evidence attached to that requirement. The question "does this evidence still apply?" gets answered by looking, not by remembering.

This is how Tandem is built to work. It connects design intent, requirements, CAD changes and validation evidence in one system, and design reviews are held in context against the requirement, architecture node, CAD change and verification evidence they relate to. It works alongside SolidWorks, Onshape and NX rather than replacing them, with off-the-shelf integrations for those tools. Mechanical CAD is the center of gravity, including the structural and thermal risk that a rib or wall-thickness change can carry.

The same pattern appears in other review gates. See how it plays out in a Critical Design Review package or when tracing structural requirements when CAD changes. The device version adds one more reader: the person who has to defend the record to an auditor.

How AI agents and change-impact checks help mechanical and quality engineers before the review

The best use of AI in a device design review happens before anyone sits down. A review meeting is a bad place to discover what changed. It is a good place to decide what to do about it.

Tandem has two capabilities aimed at that gap. Change-impact analysis identifies what a change affects, and requirement checks run against linked CAD. AI agents can search, create and update architecture nodes, requirements, attributes and annotations. Applied to the composite: before Wednesday, the mechanical engineer's rib change is traced to the requirements allocated to the battery compartment, and the quality engineer sees which of them now need a second look.

A useful pre-review routine for the two engineers:

• Mechanical engineer: list every CAD change since the last review baseline and confirm each is linked to the node and requirements it affects.

• Quality engineer: for each affected requirement, check that its verification evidence still corresponds to the current design state, and flag any that does not.

• Both: use an agent to search for requirements and annotations that mention the changed feature, so nothing is missed because someone used different words.

• Both: write the open questions into the review agenda before the meeting, not during it.

Be precise about who does what. The agent finds and drafts. Engineers decide. Tandem does not run tests. It connects changes to the requirements and evidence they affect. Reviewers still own the judgment that a design meets its inputs. What changes is that they arrive with the list already built, and the meeting starts at the hard question instead of the discovery.

AI design review software for hardware teams: best design review software criteria, not a ranking

Searching for the best design review software returns ranked lists that mostly compare feature checklists. For a regulated device team, a ranking is the wrong instrument. Your quality system, your CAD stack and your auditor decide what fits. Use criteria instead.

Ask of any AI design review software for hardware teams:

• Does the review attach to live objects? A review that lives in a slide deck or PDF is a copy. The requirement, the architecture node, the CAD change and the evidence should be the things reviewers actually look at.

• Does it work with your CAD? If your mechanical engineers live in SolidWorks, Onshape or NX, a tool that needs a separate modeling environment adds a translation step where errors enter.

• Does it show what changed since the last baseline? Change impact should be a query, not an archaeology project.

• Can it record independent review? The record should show who reviewed and in what role, so the independence expectation is demonstrable.

• Is the AI grounded in your data? An agent that answers from your requirements and review history is useful. One that answers from general knowledge is a liability in a design history file.

• What does it explicitly not do? Vendors that state their limits are easier to trust than those that claim everything.

On that last point, a fair comparison names limits on every side. Tandem is not a QMS, so it does not replace your document control or CAPA system. It is not a PLM or PDM replacement, so it does not hold file versions or BOMs. Pair it with the systems you already run.

If you want the review gates themselves laid out, the guides on preliminary design review entrance criteria and design history file upkeep pair well with these criteria.

AI tools for mechanical engineering: where they fit in a regulated review

AI tools for mechanical engineering cover a wide range: generative CAD, simulation helpers, drawing automation, part search, tolerance analysis. Most of them produce an artifact. A regulated review needs something different: a record of why the artifact is what it is.

That gives a clean rule for where AI belongs in a device review.

It fits in preparation. Finding every requirement touched by a geometry change. Surfacing evidence that predates a design revision. Drafting annotations and keeping architecture attributes current. These are search-and-linkage problems, and agents are good at them when they are grounded in your own records.

It stops at judgment and at sign-off. Whether a wall thickness is adequate for a drop requirement is an engineering call, backed by analysis or test. Whether the review was independent and the record is complete is a quality call. Neither can be handed to a model, and an auditor will not accept "the AI said it was fine" as a rationale.

Use AI to make the review packet true. Use engineers to make the review honest.

Conclusion

Do one thing before your next device design review: take the last review packet you built and count how many of its artifacts were copies. Every copy is a place the Wednesday problem can recur.

Then run your next review in context. Bring the battery compartment, the enclosure rib, whatever your Tuesday change was, and review it against its requirement, its architecture node, its CAD change and its verification evidence in one place. That is what Tandem is for: connecting those four objects for teams working in SolidWorks, Onshape and NX, so the mechanical engineer's change and the quality engineer's record agree before the meeting starts. Book a demo with your most recent review packet and ask to see where it went stale.