Design control template
Design Change Form for medical device design controls
Use this editable Design Change to run phase-gated design controls, keep your Design History File (DHF) complete, and demonstrate that your device was developed under controlled requirements.
Trace requirements to validationLink user needs, design inputs, outputs, V&V and transfer.
Support DHF integrityDocument reviews, changes and design transfer in one controlled flow.
Ready for FDA/MDR auditsAlign with 21 CFR 820.30 and MDR Annex I expectations.
- Best for: DHF management, design planning, V&V evidence capture, design review and change control.
- Includes: editable sections for inputs, outputs, planning, reviews, transfer, changes and V&V records.
- Format: editable template available through the standard WooCommerce download flow.
Lexqara helps medical device manufacturers build robust design controls that satisfy both FDA QSR and EU MDR requirements. Explore the Resource Center or review our Design Control Services.
Description:
This form controls pre-market design changes by documenting what changed, why it changed, and what evidence is needed to keep the DHF consistent.
• Capture Design Change Short Description, Change Owner, and Phase of Design Control.
• Record Origin and Reason of the Change and the full Description of the Change.
• Identify affected User Needs, Design Inputs, and Design Outputs.
• Run a structured Impact Assessment (intended use, performance, usability, safety, compliance).
• Define a dated Action Plan with owners, evidence, and “blocking for approval” flags.
• Confirm updates to risk management, traceability matrix, and D&D plan where applicable.
• Perform Design Change Review and approve transfer to DHF before Change Release.
Your needs:
• medical device design change aligned with ISO 13845 requirements
• medical device design change for MDR decision-making
• Reduce rework by aligning impacts, actions, and evidence early.
Use this form whenever a change arises during design and development before market release, especially when it may affect intended use, compliance, or verification/validation scope.
It ensures decisions are objective. An Impact Assessment documents what is affected and why it matters, while transfer to DHF confirms approved records are complete before release.
• Identify impacts on UR/DI/DO and the Traceability Matrix.
• Assess intended use, performance, usability, and safety impacts.
• Confirm regulatory strategy and standards impacts (incl. MDR roles).
• Define required new/updated verification, validation, or process validation.
• Require evidence-based closure before release.
Within Lexqara, we support design control, regulatory strategy, audits, and verification/validation planning so design change control stays lean and defensible. Use our Resource Center and Design Control Support for Start-up Companies, and consult EU MDR (Regulation (EU) 2017/745). Request a short design change impact review.
Done well, design change control protects timelines by keeping risk management updates, test scope, and DHF traceability aligned to one approved action plan.
Template preview
Template preview: Design Change
Review the key sections included in the Design Change template before downloading it. This preview shows the structure and content you will receive in the editable file.
View the full template preview
Project Name: XXXX
DHF Number: XXXX
Proposed Device Name: XXXX
Scope
This change is initiated to identify, assess, review, implement, and approve design changes arising during the design and development process, prior to market release of [Device Name].
Stage 1: Design Change Identification and Description
|
Design Change Short Description
|
XXX Change title
|
|
Phase of Design Control
|
1, 2, 3, 4, 5
|
|
Change Owner
|
XXX Owner identification
|
|
Origin and Reason of the Change
|
XXX Description of the change origin
|
|
Description of the Change
|
XXX Description of the change
|
|
Initiation Date
|
DD-Month-YYYY
|
|
Current Traceability Matrix
|
ZZZZ-TM-XXX rev.Y Enter the applicable Traceability Matrix reference and revision.
|
|
Affected User Needs
|
If applicable, indicate the user needs removed and planned to be added
|
|
Affected Design Inputs
|
If applicable, indicate the design inputs removed and planned to be added
|
|
Affected Design Outputs
|
If applicable, indicate the affected design outputs (e.g., drawings, components, labeling, packaging, etc.)
|
Stage 2: Impact Assessment
|
Assessment area
|
Change Impact?
|
Impact Description
|
What has changed?
|
|
Is the user requirement document affected by the change?
|
Yes
No
|
Describe the change comparing the previous situation to the new situation
|
Describe what is affected by the change (e.g., labeling, design input #X.Y, new test, etc.)
|
|
Is the intended use affected by the change?
|
Yes
No
|
|
|
|
Is the design input document affected by the change?
|
Yes
No
|
|
|
|
Is (are) the regulatory strategy(ies) affected by the change?
|
Yes
No
|
|
|
|
Are the existing design outputs affected by the change?
|
Yes
No
|
|
|
|
Does the change require the creation of new design outputs?
|
Yes
No
|
|
|
|
Is the design function or performance affected by the change?
|
Yes
No
|
|
|
|
Is the usability or user interface affected by the change?
|
Yes
No
|
|
|
|
Have new safety criteria been introduced by the change?
|
Yes
No
|
|
|
|
Is the compliance with regulatory requirements affected by the change?
|
Yes
No
|
|
|
|
Is the compliance with applicable standards affected by the change?
|
Yes
No
|
|
|
|
Are the risk management documents affected by the change?
|
Yes
No
|
|
|
|
Are the constituents or components affected by the change?
|
Yes
No
|
|
|
|
Are the already approved design verification activities affected by the change?
|
Yes
No
|
|
|
|
Are the already approved design validation activities affected by the change?
|
Yes
No
|
|
|
|
Does the change require the implementation of new design verification or validation activities
|
Yes
No
|
|
|
|
Does the change require revalidation of manufacturing processes?
|
Yes
No
|
|
|
|
Does the change require validation of new manufacturing processes?
|
Yes
No
|
|
|
|
Are QMS documents impacted by the change?
|
Yes
No
|
|
|
|
Is the QMS Risk Analysis affected by the change?
|
Yes
No
|
|
|
|
Are already built / released but not yet marketed units affected by the change?
|
Yes
No
|
|
|
|
XXXX
|
Yes
No
|
|
|
|
XXXX
|
Yes
No
|
|
|
|
XXXX
|
Yes
No
|
|
|
|
XXXX
|
Yes
No
|
|
|
Stages 2 and 3: Action Plan & Implementation
Detailed Action Plan
|
Stage 2
|
Stage 3
|
|
Detailed Action Plan
|
Planning
|
Implementation
|
|
Who
|
Target Date
|
Evidence
|
Closure Date
|
Blocking for approval
|
|
Design Activities Yes N/A: justification
|
|
Describe all design activities/documents affected by the change as detailed in Section 3.
e.g. new/revised design inputs, new/revised user requirement, root-cause analysis, outsourcing, etc.)
|
Assign the responsible
|
DD-Mon-YYYY
|
Include the evidence of compliance (document number + revision)
|
DD-Mon-YYYY
|
Yes No
|
|
|
DD-Mon-YYYY
|
|
DD-Mon-YYYY
|
Yes No
|
|
|
DD-Mon-YYYY
|
|
DD-Mon-YYYY
|
Yes No
|
|
|
DD-Mon-YYYY
|
|
DD-Mon-YYYY
|
Yes No
|
|
|
DD-Mon-YYYY
|
|
DD-Mon-YYYY
|
Yes No
|
|
|
DD-Mon-YYYY
|
|
DD-Mon-YYYY
|
Yes No
|
|
|
DD-Mon-YYYY
|
|
DD-Mon-YYYY
|
Yes No
|
|
Update of risk management
|
|
DD-Mon-YYYY
|
|
DD-Mon-YYYY
|
Yes No
|
|
Update of traceability matrix
|
|
DD-Mon-YYYY
|
|
DD-Mon-YYYY
|
Yes No
|
|
Update of design and development plan
|
|
DD-Mon-YYYY
|
|
DD-Mon-YYYY
|
Yes No
|
|
Design Outputs Yes N/A: justification
|
|
Describe all design activities/documents affected by the change as detailed in Section 3.
e.g., update of software version, drawing, BOM, label, IFU, etc.
|
Assign the responsible
|
DD-Mon-YYYY
|
Include the evidence of compliance (document number + revision)
|
DD-Mon-YYYY
|
Yes No
|
|
|
DD-Mon-YYYY
|
|
DD-Mon-YYYY
|
Yes No
|
|
|
DD-Mon-YYYY
|
|
DD-Mon-YYYY
|
Yes No
|
|
Design verification activities Yes N/A: justification
|
|
Describe all design activities/documents affected by the change as detailed in Section 3.
e.g., bench test, animal test, biocompatibility, software validation, cybersecurity, etc.
|
Assign the responsible
|
DD-Mon-YYYY
|
Include the evidence of compliance (document number + revision)
|
DD-Mon-YYYY
|
Yes No
|
|
|
DD-Mon-YYYY
|
|
DD-Mon-YYYY
|
Yes No
|
|
|
DD-Mon-YYYY
|
|
DD-Mon-YYYY
|
Yes No
|
|
Design Validation Activities Yes N/A: justification
|
|
Describe all design activities/documents affected by the change as detailed in Section 3.
e.g., clinical evaluation, usability
|
Assign the responsible
|
DD-Mon-YYYY
|
Include the evidence of compliance (document number + revision)
|
DD-Mon-YYYY
|
Yes No
|
|
|
DD-Mon-YYYY
|
|
DD-Mon-YYYY
|
Yes No
|
|
|
DD-Mon-YYYY
|
|
DD-Mon-YYYY
|
Yes No
|
|
Process Validation Activities Yes N/A: justification
|
|
Describe all design activities/documents affected by the change as detailed in Section 3.
|
Assign the responsible
|
DD-Mon-YYYY
|
Include the evidence of compliance (document number + revision)
|
DD-Mon-YYYY
|
Yes No
|
|
|
DD-Mon-YYYY
|
|
DD-Mon-YYYY
|
Yes No
|
|
|
DD-Mon-YYYY
|
|
DD-Mon-YYYY
|
Yes No
|
Stage 2: Action Plan Approval
|
Action Plan
|
|
Participants
|
Approval
|
Signature
|
|
Indicate at least the coreteam members involved in the phase of design control
|
Yes
No
|
|
|
Yes
No
|
|
|
Yes
No
|
|
|
Yes
No
|
|
|
Yes
No
|
|
|
Yes
No
|
|
|
Decision
|
|
Go for implementation
Go for implementation with actions
On Hold
Stop
|
Decision rationale:
Indicate the rationale and the action plan if necessary.
|
Stage 4: Design Review for Transfer to DHF
|
Date of Design Review:
|
DD-Mon-YYYY
|
|
Participants
|
Approval
|
Signature
|
|
Indicate at least the coreteam members involved in the phase of design control
|
Yes
No
|
|
|
Yes
No
|
|
|
Yes
No
|
|
|
Yes
No
|
|
|
Yes
No
|
|
|
Yes
No
|
|
|
Design Change Review
|
|
Assessment area
|
Approval
|
Comments
|
|
All design control documents have been reviewed, approved and signed?
|
Yes
No
N/A
|
|
|
Design verification, design validation and process validation activities are complete as planned?
|
Yes
No
N/A
|
|
|
Does the product meet the user requirements?
|
Yes
No
N/A
|
|
|
Do the design outputs meet the design inputs?
|
Yes
No
N/A
|
|
|
Has it been demonstrated that the change does not adversely affect the safety, performance, or usability of the device?
|
Yes
No
N/A
|
|
|
Does the device continue to meet its intended use and applicable regulatory requirements.
|
Yes
No
N/A
|
|
|
Decision
|
|
Approve for transfer
Approve for transfer with actions
Reassess
Stop
|
Decision rationale:
Indicate the rationale and the action plan if necessary to complete the change
|
Stage 5: Change Release
The design change shall not be considered closed until all required actions are completed and all approved records have been transferred to the DHF.
|
Have the approved design control documents been transferred to the DHF?
|
DHF
|
Is the DHF complete, accurate, and adequate?
|
Release Approved?
|
|
Yes No
|
XXXX-DHF rev.Y
|
Yes No
|
Yes No
|
|
Transfer to DHF and Closure of design change
|
|
Name
|
|
|
Position
|
|
|
Date
|
|
|
Signature
|
|
The complete template content is displayed above. The editable file is available after adding the product to cart.
