What Level 2 Design Controls Maturity Looks Like in Medical Device Organizations

You follow the design control procedure. You have a design plan for every project. The traceability matrix exists. So why does every design transfer feel like a scramble, and why does post-market data keep surfacing design issues that V&V should have caught?

Level 2 is the plateau that most medical device organizations occupy for years without recognizing it. The procedures are in place. The templates are filled in. The auditors find minor nonconformities, not major ones. From a distance, the design control system looks functional. Up close, the design history file tells a different story.

The Retroactive DHF

The defining characteristic of Level 2 is that the DHF is assembled, not built. Design activities happen on their own timeline — engineers designing, testing, iterating — and the documentation catches up later. Sometimes days later. Sometimes weeks. The DHF index lists the required documents. Project managers check them off as they are filed. But the filing happens after the design decisions were made, after the verification was run, after the design review concluded.

This matters because a DHF that is assembled retroactively is a compliance artifact, not a design management tool. It records what happened. It does not shape what happens. When the traceability matrix is populated after verification is complete, it cannot reveal that three design inputs have no corresponding verification test cases. When design review minutes are drafted from memory two weeks after the meeting, they capture the conclusion but lose the dissenting opinion that challenged a critical assumption.

The retroactive DHF is the reason Level 2 organizations pass audits but fail at design transfer. The documentation satisfies the inspector who reviews it after the fact. It does not serve the manufacturing engineer who needs it during transfer, because the documentation was never intended to be used in real time.

Level 2 Tells

Every Level 2 organization exhibits a recognizable pattern of symptoms. Individually, each one seems like a minor process gap. Collectively, they reveal a design control system that runs on procedure compliance rather than engineering discipline.

Design plans are templates with blanks filled in. A Class III implantable and a Class I reusable instrument get plans that differ only in the project name and the team roster. The verification strategy, the review cadence, the risk management approach — all copied from the template without critical evaluation of what this particular device demands.

Design inputs mix the specific with the vague. "The catheter shall withstand 300 psi burst pressure" sits in the same document as "the device shall be intuitive to use." Both carry unique identifiers. Both are traced in the matrix. But the second one cannot be verified as written, and everyone knows it. The team plans to deal with it during usability testing, but the usability testing plan references a different set of requirements maintained by the human factors team in a separate document.

Design reviews produce attendance sheets and action items but rarely produce documented technical challenges to the design. Reviewers receive materials the day before — or the morning of — the review. The independent reviewer signs the form. The review approves the phase gate. Three months later, verification testing reveals exactly the issue that a thorough review would have identified.

Verification protocol amendments exceed five per project. Each amendment is individually justified, individually approved, and individually filed. But the pattern reveals that the protocols were written against requirements that were not ready to be tested. The amendments are not corrections to the protocol. They are corrections to the design inputs, executed through the wrong mechanism.

Why Post-Market Signals Trace Back Here

The complaint arrives eighteen months after launch. The adhesive bond fails under conditions of sustained moisture exposure. The design verification tested bond strength at ambient conditions per the acceptance criteria in the design input document. The design input document did not specify moisture exposure because the use environment analysis was incomplete. The use environment analysis was incomplete because human factors was not integrated into the design input process. The root cause is not a manufacturing defect. It is a Level 2 design input.

This pattern repeats across the medical device industry. Post-market issues that appear to be production quality problems or isolated field failures frequently trace back to design inputs that omitted a use condition, a patient population, or an environmental factor. The V&V program tested exactly what it was asked to test. It was not asked to test the right things.

Level 2 organizations struggle to see this connection because their post-market surveillance system and their design control system operate as separate processes. Complaint data goes to CAPA. CAPA investigates the immediate cause. The investigation rarely reaches back to the design input document to ask whether the requirement was complete in the first place.

The Consistency Problem

An FDA investigator reviewing three DHFs from the same Level 2 organization will find three different levels of completeness. Project A has a thorough traceability matrix because the project lead is meticulous. Project B has a skeletal matrix because the project lead prioritized timeline over documentation. Project C has a matrix that was complete at one point but was not updated after three design changes during verification.

This inconsistency is itself a regulatory finding. It suggests that the quality system is not effectively implemented per 820.30(a), because the procedure exists but execution depends on individual diligence rather than organizational discipline. The procedure says the same thing for every project. The output varies by project. That gap is the definition of Level 2.

Breaking Through the Plateau

Advancing from Level 2 to Level 3 requires changing when documentation happens, not just whether it happens. The DHF must be built concurrently with design activities, not assembled afterward. This means the traceability matrix is updated when a design input is written, not when the project closes. It means design review materials are prepared as deliverables are completed, not compiled the week before the review. It means the DHF is a working tool that the team uses during development, not a binder that QA assembles for the file.

The second requirement is design input quality enforcement. Every input must meet defined criteria — specific, measurable, traceable, testable — before it is baselined. Inputs that fail these criteria are returned for revision before the project advances. This gatekeeping function feels like it slows the project down. In practice, it eliminates the protocol amendments, the late-stage design changes, and the post-market discoveries that cost far more time than the upfront review.

The third requirement is integrating risk management outputs as design inputs. Every risk control measure identified through ISO 14971 analysis must appear as a traceable design input with associated verification requirements. The risk file and the DHF must tell the same story, and that story must be visible in the traceability matrix.

The plateau breaks when the organization stops treating design controls as a documentation exercise and starts treating them as an engineering discipline. The procedure does not change. The relationship to the procedure changes.

Measure where your organization stands with the MedTechCMM design controls assessment at /assessments/design-controls.