Design Verification Traceability in Medical Device Programs

The email arrives on a Tuesday, three weeks into verification. The design engineer has changed the seal material on the housing, from one elastomer to another, because the original compound failed a compatibility check with the cleaning agent. The CAD model is updated. The drawing note is updated. Everyone is relieved.

You are the quality engineer, and you are not relieved. You have a protocol that was executed against the old seal. You have results that were signed, and evidence files that reference a part revision that no longer exists. You have to decide, by the end of the week, what still stands.

This is the real test of design verification traceability in a medical device program. It isn't whether you can produce a traceability matrix on a calm day. It's whether you can re-prove the chain from requirement to verification method to test case to result to evidence after something moves. Most teams can build the chain once. Few can rebuild it quickly when the design changes underneath it.

The Late Change: A Seal Material Swap in the Middle of Verification

Take the scenario concretely. A handheld diagnostic device has a two-part housing sealed with an elastomer gasket. Verification is underway. Ingress protection testing is complete. Drop testing is half done. A cleaning-agent compatibility result comes back showing the gasket swelling, and the team swaps the seal material. The wall thickness at the groove is adjusted by 0.2 mm to hold the same compression.

That is a small change on paper. It is not small for you. A seal material affects compression set, ingress performance, biocompatibility if the seal touches a patient-contact path, cleaning and disinfection requirements, and drop behavior, because a softer or harder seal changes how the housing absorbs shock. A wall thickness change touches stiffness, thermal behavior and fit.

The design engineer will tell you what they think is affected. Treat that as a starting list, not an answer. Your job under design controls is to show that the verification record is still valid for the design that will actually ship, and to show it in a way an auditor can follow without you in the room.

The question is never "did we change something?" The question is "which verified claims are now unverified?" Everything else in this article is about answering that second question fast, with evidence you can defend.

The Chain You Have to Re-Prove: Requirement, Method, Test Case, Result, Evidence

Verification traceability is a chain with five links. Break any one and the claim collapses.

Requirement. A statement of what the design must do, such as "the enclosure shall resist ingress of liquids per the specified rating after the defined cleaning cycles." It has a parent, usually a user need or a system requirement, and it may have children that allocate it to the housing and the seal.

Verification method. Test, analysis, inspection or demonstration. The choice matters because it determines what a design change invalidates. A requirement verified by analysis may need only a re-run of a calculation with the new material properties. One verified by test may need physical re-testing. Our guide to verification methods covers how to choose among them.

Test case. The specific protocol: configuration under test, sample size, acceptance criteria, setup. It should reference the design revision it was written against.

Result. What happened when it ran, with pass or fail against the criteria.

Evidence. The raw data, photos, instrument records and signatures that let someone else believe the result.

Now apply the seal change. For each requirement the change touches, you ask four questions. Does the requirement text still hold? Is the method still appropriate? Was the test case run on a configuration that matches the new design? Is the evidence attached to a revision that still exists?

A result is not an eternal fact. It is a statement about a specific design revision at a specific time. When the revision changes, the result becomes a historical record, valid for the old design and silent about the new one. Your job is to identify which results fall into that category, and the answer has to come from the links, not from memory.

What Breaks When CAD, Requirements and Test Records Live in Three Places

In many programs the three halves of this chain live in different systems. Geometry lives in CAD. Requirements live in a requirements tool, or a document, or a spreadsheet. Test protocols and results live in word-processed reports and shared drives. Nothing in the system knows the others exist.

Watch what happens when the seal changes.

The CAD change is visible to the design engineer. It is invisible to the requirements tool, because nothing told it. So no requirement is flagged. The test records reference a part number and a revision typed by hand into a header, which means only a person reading carefully can notice that a test has gone stale.

So you do it by hand. You open the requirements list and read each one, asking whether the seal could matter. You open the protocols and check which ones used the old gasket. You email the test technician to ask which samples had the old material. You search the shared drive for evidence files and find two copies of a report with slightly different names. You rebuild the traceability matrix in a spreadsheet, and by the time you finish, it is a snapshot that starts going stale immediately.

The failure is rarely a missing document. It is a missing link that nobody noticed was missing until an auditor pulled on it. A requirement that reads "verified" because its test passed, when the test ran on a configuration that no longer matches the design, is worse than an open requirement. It is a false assurance, and it sits in your design history file looking legitimate.

Three places also means three sets of timestamps, three permission models and three opinions about which version is current. Reconciling them is your unpaid second job during every late change.

Working the Change Impact: Requirements, Stale Tests, FMEA Rows and the DHF

A disciplined change impact has four passes. Run them in this order.

Pass one: requirements. Start from what changed in the design and walk outward to the requirements that depend on it. For the seal: ingress, cleaning compatibility, drop performance, biocompatibility if relevant, and any requirement on housing stiffness or assembly force. Write down each one and why it is in or out. "Out" needs a reason, because an auditor will ask.

Pass two: stale tests. For every in-scope requirement, find the test cases and results linked to it and mark each as valid, partially valid or stale. A result is stale if the tested configuration differs from the new design in a way that could affect the outcome. Some stale results need a full re-run. Some need a rationale and a smaller confirmation test. Decide which, and record the decision.

Pass three: risk. Revisit the FMEA rows tied to the affected requirements. A new seal material can introduce failure modes (extractables, degradation under the cleaning agent) and change the severity, occurrence or detection of existing ones. Our design FMEA guide covers keeping those rows tied to requirements so they surface in this pass instead of being rediscovered later.

Pass four: the record. Update the design history file so it describes the design that will ship, the change, the rationale and the revised verification plan. The design history file guide walks through keeping it current as the design moves.

If you also face a gate review, the revised plan has to survive it. A test readiness review is the natural checkpoint to confirm the re-verification scope before samples are built. When all four passes are done, you should be able to write a short, defensible statement: here is what the change touched, here is what we re-verified, here is why the rest still stands.

How Tandem Keeps the Verification Chain Connected

The manual version of those four passes is slow because the links live in people's heads. Tandem puts the links in one system, so the passes start from a graph instead of a blank spreadsheet.

In Tandem, requirements carry a parent and child hierarchy, and FMEA and risk tables are trace-linked to them. Test case management and test execution are linked to the same requirements, and validation evidence is stored in the same system. So the chain from requirement to test case to result to evidence is a set of connections you can follow, not a matrix you rebuild.

The CAD side is where the seal swap gets interesting. Tandem's CAD plugins (SolidWorks, Onshape, CATIA, NX and Fusion) capture design changes. The Design Changes view shows a before and after 3D CAD diff with a plain-language summary and the affected requirements and annotations. When the gasket material and groove wall thickness change, you start from the list of requirements the change is linked to, not from a guess.

Requirements are also verified continuously against live attributes from CAD, Excel or Google Sheets, and telemetry. If a requirement depends on a wall thickness or a material property, a change in that attribute shows up against the requirement instead of waiting for someone to notice.

Every edit to a requirement lands in a redlined change history, usable for FDA audit documentation. Design reviews run in a browser 3D viewer that needs no CAD license, so a reviewer in quality can place annotations directly on the gasket geometry. When the change is approved, Tandem generates ECOs, ECNs and documentation from the captured CAD changes, in your own templates.

Tandem doesn't replace your QMS or your PLM. It runs alongside them and connects the engineering record they don't hold together.

What to Look For in Change and Design Review Software

If you are evaluating tools after a painful late change, judge them by whether they would have shortened your week, not by feature count. Four tests work.

Does the change reach the requirements on its own? If a CAD change does not point to the requirements it affects, you are still doing pass one by hand. This is the core of engineering change order software that earns its place: the ECO should arrive already carrying its impact, not as a form you fill in from memory.

Can you see stale verification without reading every report? Ask the vendor to show a requirement, its test cases, its results and its evidence, then change the design and show what happens to the status.

Do design reviews put comments on geometry? The best design review software for quality work lets non-CAD users annotate the 3D model, ties those annotations to requirements, and keeps the thread. Screenshots pasted into slides don't meet that bar.

Is the history auditable? Requirements need a redlined, attributable change history. Anything you would have to reconstruct for an auditor is a liability.

On AI tools for mechanical engineering, ask specific questions. An agent that can search and update requirements, attributes and annotations and run impact analysis is useful to a quality engineer. A chat window that summarizes documents is not. Ask what the agent can read, what it can change, and whether every change it makes lands in the same audit trail as a human edit.

Conclusion

The seal material swap will happen on your next program too, and how that week goes depends on what you built before it. If the links between requirement, method, test case, result and evidence live in people's heads, you will rebuild them under deadline and hope you caught everything. If they live in one connected system, you start from the affected requirements and spend your time on judgment.

Run the exercise before the next late change finds you. Pick one requirement in your current program, change one attribute in CAD, and time how long it takes to list every stale test, FMEA row and DHF entry. If the answer is longer than an afternoon, book a Tandem demo and bring that requirement with you.