Engineering, Design Controls & Validation: Building the Evidence for Clearance
Category: Engineering
The most expensive medical-device engineering problems are rarely caused by a missing document.
They are caused by decisions that were never clearly defined, challenged, tested, or connected.
A design requirement remains ambiguous. A test begins before the worst-case device is identified. A supplier changes a manufacturing process after verification. A failure mode appears during testing but never makes its way back into the risk analysis. Engineering completes a technically successful project, only to learn that the evidence does not fully support the proposed regulatory submission.
By then, the company may be facing redesign, repeated testing, delayed clearance, lost launch revenue, or an uncomfortable discussion with investors.
A rigorous design-control process is intended to prevent that outcome.
Design controls should not operate as a quality-system layer placed around engineering. They should function as the structure through which engineering decisions are planned, reviewed, verified, validated, transferred, and improved.
When implemented correctly, design controls do more than reduce compliance risk.
They make product development more disciplined, regulatory submissions more defensible, and commercialization timelines more credible.
Design Controls Are an Engineering System
Some development teams view design controls primarily as a collection of required forms:
A design plan
User needs
Design inputs
Design outputs
Review minutes
Verification reports
Validation reports
Change records
A Design History File
Those records matter, but the documents are not the process.
The real design-control system is the logic connecting them:
Clinical need → user need → design input → design output → risk control → verification → validation → design transfer → post-market feedback
Every important product requirement should move through that chain.
For example, if a spinal implant must resist migration, the development record should show:
Why migration is a relevant hazard
Which design features reduce that risk
How those features are defined in measurable requirements
Which drawings and specifications implement them
How the requirements are verified
How the device is validated under representative use conditions
How complaints and post-market data will be monitored after launch
When that chain is incomplete, the company may have evidence without traceability—or traceability without sufficient evidence.
Neither is enough.
The Regulatory Framework Has Evolved
FDA’s Quality Management System Regulation became effective on February 2, 2026. The QMSR incorporates ISO 13485:2016 by reference and applies its design-and-development framework to applicable medical devices. FDA also replaced its former Quality System Inspection Technique with a new inspection process aligned with the QMSR. (U.S. Food and Drug Administration)
Under the QMSR terminology, organizations maintain a design and development file for each medical-device type or family. FDA has explained that the revised regulation no longer uses certain legacy terms, including “Design History File,” although the underlying records and controls remain addressed through ISO 13485’s design-and-development requirements. (U.S. Food and Drug Administration)
Many companies will continue using the familiar term DHF, particularly in internal procedures and industry communication. Regardless of the label, the objective is the same: maintain a controlled record showing that the design was planned, developed, reviewed, verified, validated, transferred, and changed in accordance with applicable requirements.
The file should tell the complete engineering story—not merely contain a folder for every required heading.
1. Design History File Development
A strong DHF or design-and-development file should allow a knowledgeable reviewer to understand:
What the company intended to develop
Why the product was needed
Which requirements governed the design
How risks influenced development
Which alternatives were considered
How the final design was selected
How requirements were verified and validated
How changes were controlled
Whether the design was successfully transferred into production
FDA describes the design and development file as the history of the device type or family, containing or referencing evidence that the organization met applicable design-and-development requirements, including those related to changes. (U.S. Food and Drug Administration)
The DHF should be built during development
A common mistake is attempting to reconstruct the DHF shortly before a regulatory submission, certification audit, FDA inspection, or acquisition.
At that point, teams may be searching through:
Emails
Personal folders
Meeting notes
Supplier correspondence
Old CAD models
Prototype reports
Laboratory data
Unapproved presentations
The documents may show that significant engineering work occurred, but they may not demonstrate that the work was planned, reviewed, approved, and connected to controlled requirements.
Retrospective reconstruction can also create inconsistencies. Dates do not align. Design inputs were approved after testing. Reviews appear to have occurred after the relevant decision. Test samples cannot be connected confidently to released drawings.
The better approach is to define the DHF structure in the design and development plan and populate it as the project progresses.
What a defensible DHF typically includes
Depending on the product and development model, the file may contain or reference:
Design and development plan
Project responsibilities and interfaces
User needs
Regulatory and standards strategy
Design inputs
Design outputs
Risk-management records
Design reviews
Prototype evaluations
Test-method development records
Verification protocols and reports
Validation protocols and reports
Clinical or simulated-use evidence
Software documentation, when applicable
Biocompatibility, sterilization, packaging, and shelf-life evidence
Design-transfer records
Design-change records
Traceability matrices
Unresolved anomaly or deviation assessments
Final design review or release approval
The file does not need to duplicate every controlled record. It can reference documents maintained in other validated systems, provided those records remain identifiable, controlled, retrievable, and connected.
A file is not the same as a narrative
A DHF may contain hundreds of documents and still be difficult to defend.
The most effective files include a clear index or roadmap showing:
The current approved design
The development stages
Major design decisions
Applicable records
Key changes
Verification and validation status
Open items
Final release status
The goal is not merely to prove that documents exist.
It is to demonstrate that the company maintained control over the development process.
2. Test-Method Development and Evaluation
A device can pass a poorly designed test.
That does not make the evidence reliable.
Before using a method to support design verification, the team should establish confidence that the method can evaluate the requirement consistently and meaningfully.
This is especially important when:
No established consensus standard exists
A standard must be modified
The device has novel geometry or materials
The measurement depends heavily on fixtures or operator technique
The expected differences are small
The method will generate a critical regulatory endpoint
The test is performed internally
The method combines several sources of uncertainty
Test-method development should answer a basic question:
Can this method reliably determine whether the device meets the requirement?
Begin with the requirement—not the available equipment
Testing laboratories frequently offer familiar packages based on recognized standards. Those methods may be appropriate, but the development team must still determine whether they answer the specific engineering and regulatory question.
A sound test-method plan should define:
The requirement being evaluated
The relevant failure mode
The test article
The worst-case rationale
The test setup
Fixtures and interfaces
Environmental conditions
Sample conditioning
Measurement equipment
Number of samples
Data collection
Acceptance criteria
Failure criteria
Statistical approach
Deviations and limitations
The method should produce data that can be interpreted against a predefined requirement.
“Test completed” is not an engineering conclusion.
Evaluate the method before relying on it
The appropriate level of test-method evaluation depends on risk and complexity. Activities may include:
Feasibility testing
Fixture evaluation
Range and resolution assessment
Repeatability studies
Reproducibility studies
Operator comparisons
Measurement-system analysis
Sensitivity analysis
Destructive-test evaluation
Protocol challenge testing
Reference-sample testing
Boundary or limit testing
The objective is not to create unnecessary statistical work.
It is to identify whether the method itself could mask a failure, create a false failure, or produce results that cannot be reproduced.
Document failures as engineering information
Unexpected test results are not simply obstacles to be removed from the final report.
A failure may reveal:
An incorrect design assumption
A new hazard
An inadequate risk control
A manufacturing inconsistency
An unsuitable fixture
Excessive test variability
An incorrect worst-case selection
An unrealistic acceptance criterion
Every significant failure should be investigated proportionately and routed back into the appropriate design-control processes.
The most credible development programs do not hide iteration.
They show that the company identified problems, understood them, implemented justified changes, and confirmed the effectiveness of those changes.
3. Design Verification and Validation Planning
Verification and validation are often grouped together, but they answer different questions.
Verification asks: Did we design the product correctly according to the approved requirements?
Validation asks: Did we design the correct product for the user and intended use?
FDA has described verification as confirming design outputs against design inputs through objective, measurable evidence. Design validation establishes that the resulting device satisfies user needs and intended uses under defined operating conditions and should use production units, lots, batches, or their equivalents. (U.S. Food and Drug Administration)
Both activities require more than a collection of final reports.
They require an integrated strategy.
Build a V&V matrix before testing
A verification and validation matrix should connect each requirement to its planned evidence.
A useful structure may include:
RequirementRisk or rationaleVerification or validation methodTest articleAcceptance criterionEvidenceImplant withstands specified static loadingFracture or loss of supportMechanical bench testWorst-case implant and constructPredetermined load or comparative benchmarkApproved test reportInserter securely retains implantImplant release or malpositionSimulated-use and retention testingFinal implant and instrumentNo unintended disengagementValidation reportSterile barrier remains intact through shelf lifeLoss of sterilityPackaging and aging validationFinal packaging configurationMeets integrity and strength criteriaPackaging reportsUser can complete locking step correctlyIncomplete fixationHuman-factors or simulated-use studyProduction-equivalent systemCritical task completed without serious use errorValidation report
This matrix exposes gaps early.
It also prevents the common situation in which several tests appear relevant to the same requirement while another important requirement has no evidence at all.
Define acceptance criteria before seeing the data
Acceptance criteria should be established in the approved protocol—not selected after reviewing the results.
Criteria may be based on:
Design inputs
Risk controls
Recognized standards
Predicate performance
Scientific literature
Clinical requirements
Engineering analysis
Historical product performance
Statistically justified limits
For orthopedic implants, compliance with a test standard does not necessarily establish the minimum acceptable performance level. A consensus standard may define the method without defining what result is sufficient for a particular device.
The team should separate two questions:
Was the device tested correctly?
Does the result demonstrate acceptable performance?
Passing the first does not automatically answer the second.
Select the appropriate worst case
Worst-case selection should be specific to the failure mode.
For orthopedic implants, relevant variables may include:
Implant diameter
Length
Height
Footprint
Lordosis
Graft-window size
Material thickness
Porosity
Lattice orientation
Fixation span
Screw angulation
Construct configuration
Manufacturing orientation
Sterilization exposure
Reprocessing cycles
The largest device is not automatically the worst case. Neither is the smallest.
One device may represent the worst case for fatigue, another for subsidence, another for insertion, and another for cleaning or sterilization.
Worst-case rationales should be approved before testing and supported with engineering analysis.
Use production-equivalent devices
Validation should represent the product the user will actually receive.
That means considering:
Final materials
Final manufacturing processes
Final surface treatments
Final cleaning
Final sterilization
Final packaging
Released software
Final labeling
Commercial instruments
Intended users
Intended use environment
A prototype manufactured through a different process may be suitable for early engineering evaluation but unsuitable for final design validation.
When production-equivalent devices are not available, the company should document why the selected units are equivalent and assess any differences that could affect the results.
4. Integrating ISO 14971 Risk Management
Risk management should not be a separate quality activity performed after engineering is complete.
ISO 14971:2019 establishes a lifecycle process for identifying device hazards, estimating and evaluating associated risks, implementing risk controls, and monitoring the effectiveness of those controls. (ISO)
That process should be integrated directly into design and development.
Risk management should influence design inputs
If the risk analysis identifies a potential hazardous situation, the resulting controls may create requirements for:
Implant strength
Locking performance
Dimensional limits
Instrument retention
Packaging integrity
Label visibility
Software alarms
Sterilization
Cleaning
User training
Inspection
Manufacturing controls
Those requirements should appear in the design-input documentation rather than remaining only in the risk file.
The MDSAP design-and-development audit framework specifically expects risk-management outputs and risk-control measures to be used as inputs to design and development. (U.S. Food and Drug Administration)
Risk controls must be verified
A risk-control measure is not complete simply because it appears in a risk table.
The company should identify:
The control
Where it is implemented
How implementation is verified
Whether the control is effective
Whether the control introduces new risks
Whether residual risk is acceptable
How relevant post-market information will be monitored
For example, “locking mechanism prevents screw backout” is not merely a risk statement. It should connect to:
A design requirement
Engineering drawings
Manufacturing tolerances
Inspection criteria
Mechanical testing
Simulated use
Surgical instructions
Post-market monitoring
Risk management should evolve with the design
Risk records should be reviewed when:
Design inputs change
New failure modes appear
Verification fails
Validation reveals use difficulties
Suppliers or processes change
Manufacturing nonconformities occur
Complaints are received
New clinical information becomes available
A field action or CAPA is initiated
A risk file that never changes during a complex development project is unlikely to reflect the actual engineering process.
5. Design-Control Process Implementation
A design-control procedure should be detailed enough to establish control but flexible enough to support different product-development models.
A minor instrument improvement should not necessarily require the same project structure as a novel implant platform. The process should scale according to product risk, technical complexity, regulatory pathway, and development stage.
Establish clear development stages
A practical process may include:
Research and feasibility
Explore concepts before formal development requirements are established.Project initiation
Approve the business objective, intended use, regulatory strategy, responsibilities, and design plan.Requirements development
Establish user needs, design inputs, regulatory requirements, and risk-related requirements.Concept and design development
Generate outputs, evaluate alternatives, develop prototypes, and conduct design reviews.Verification readiness
Confirm design maturity, test methods, worst-case devices, protocols, and production equivalence.Verification and validation
Execute approved protocols, investigate deviations and failures, and document conclusions.Design transfer
Translate the approved design into controlled production specifications and processes.Commercial release
Confirm that design, regulatory, manufacturing, labeling, and quality requirements are satisfied.Lifecycle maintenance
Control changes and use post-market information to maintain the design and risk files.
FDA’s current QMSR training materials emphasize that design and development should be planned and controlled and that the stages interact with risk management, verification, validation, transfer, and changes. (U.S. Food and Drug Administration)
Define roles and authority
The process should clearly identify responsibility for:
Project leadership
Engineering
Quality assurance
Regulatory affairs
Risk management
Manufacturing
Clinical or medical input
Supplier management
Document approval
Test approval
Design release
Change approval
Cross-functional participation is particularly important at design reviews.
A design review should not be a presentation where the project team reports that everything is on schedule. It should be a documented technical evaluation with sufficient independence to challenge assumptions, identify unresolved issues, and determine whether the project is ready to proceed.
Control design changes
Changes should be evaluated for their potential effect on:
User needs
Design inputs
Design outputs
Risk controls
Verification
Validation
Biocompatibility
Sterilization
Packaging
Shelf life
Software
Manufacturing
Suppliers
Labeling
Regulatory submissions
Existing inventory
Previously distributed devices
A change that appears minor on a drawing may have significant regulatory or mechanical consequences.
For example, changing the size of a graft window could affect implant strength. Changing a thread profile could affect insertion, fixation, manufacturing inspection, or predicate comparison. Changing an additive-manufacturing parameter could affect mechanical properties, surface characteristics, cleaning, and biocompatibility.
The impact assessment should occur before implementation—not after the new design has entered production.
Common Design-Control Failures
Starting formal design controls too late
The company treats early development as informal research even after commercial requirements, regulatory claims, and final design directions are already being established.
Writing vague design inputs
Requirements use terms such as “strong,” “easy to use,” “low profile,” or “biocompatible” without measurable criteria.
Testing before design maturity
Verification begins while critical dimensions, materials, instruments, or manufacturing processes are still changing.
Confusing test completion with verification
A report is placed in the file without clearly identifying which requirement was evaluated or whether the acceptance criterion was met.
Using the same worst-case rationale for every test
The company selects one convenient configuration without evaluating the failure mode associated with each method.
Treating risk management as an FMEA exercise
The team completes a table but does not connect risk controls to design requirements, verification evidence, labeling, and post-market monitoring.
Validating prototypes instead of the commercial product
The tested device does not represent final manufacturing, sterilization, packaging, software, or labeling.
Failing to evaluate test methods
The method produces results, but repeatability, sensitivity, fixtures, and measurement capability are not adequately understood.
Reconstructing the DHF after development
Records may exist, but the sequence of decisions, approvals, reviews, and changes cannot be demonstrated reliably.
Allowing design changes to bypass regulatory review
Engineering approves a technical change without assessing whether previous testing, clearance, labeling, or registration remains applicable.
A Practical Engineering Readiness Checklist
Before beginning formal verification, confirm that:
The design and development plan is current.
Responsibilities and cross-functional interfaces are defined.
User needs and intended uses are approved.
Design inputs are complete, measurable, and traceable.
Regulatory and standards requirements are identified.
Risk analysis reflects the current design.
Risk controls are translated into design requirements.
Design outputs are sufficiently complete.
Essential outputs have been identified.
The design has undergone appropriate review.
Test methods have been developed and evaluated.
Acceptance criteria are approved.
Worst-case devices are justified for each test.
Test samples are traceable to controlled specifications.
Production-equivalence considerations are documented.
Suppliers and manufacturing processes are sufficiently mature.
Protocol deviations and failure investigations have defined workflows.
The V&V matrix accounts for every requirement.
The design file is current and audit-ready.
Before commercial release, confirm that:
Verification is complete.
Validation supports user needs and intended uses.
Residual risks have been evaluated.
Design changes are resolved.
Design transfer is complete.
Manufacturing specifications are approved.
Production processes and inspections are established.
Packaging, sterilization, and shelf-life evidence are complete where applicable.
Labeling reflects the validated design and intended use.
Regulatory authorization requirements are satisfied.
Post-market monitoring responsibilities are defined.
The final design review authorizes release.
Better Design Controls Produce Better Business Decisions
The commercial value of design controls extends beyond compliance.
A disciplined development system gives leadership better visibility into:
Technical risk
Regulatory risk
Remaining evidence
Testing costs
Supplier readiness
Project dependencies
Realistic submission dates
Realistic launch dates
It also helps prevent false progress.
A project may appear 90% complete because the CAD model is finished. In reality, the company may still lack approved requirements, validated test methods, production-equivalent samples, sterilization evidence, or a defensible worst-case strategy.
Design controls expose those gaps while there is still time to address them.
They replace optimism with evidence.
Build the Product and the Evidence Together
A medical device is not truly ready because the engineering team believes the design works.
It is ready when the company can demonstrate—through controlled, traceable, objective evidence—that the device meets its requirements, addresses identified risks, satisfies user needs, and can be produced consistently.
That evidence should not be assembled after engineering.
It should be created by engineering.
A strong design-control process makes the Design History File a natural output of development. It makes verification and validation the planned confirmation of requirements rather than a last-minute testing campaign. It makes risk management part of technical decision-making rather than an isolated compliance document.
Most importantly, it gives regulators, auditors, partners, investors, and company leadership confidence that the product was not merely invented.
It was systematically engineered.
Engineering and Design-Control Support
Texas BioVentures helps orthopedic, spine, and medical-device companies establish and strengthen design-control programs, including:
Design History File and design-and-development file creation
Design-control procedure implementation
User-needs and design-input development
Test-method development and evaluation reports
Design verification and validation planning
Protocol and report preparation
Worst-case and acceptance-criteria justification
ISO 14971 risk-management integration
Traceability-matrix development
Design-review facilitation
Design-transfer and design-change assessments
Regulatory submission readiness reviews
A focused engineering and design-control assessment can identify missing requirements, weak test strategies, unsupported risk controls, and documentation gaps before they become repeated testing, audit findings, or regulatory delays.
This article is provided for general informational purposes and does not constitute legal, regulatory, certification, or engineering advice for a specific medical device.