Design Control Procedure

DOCUMENT NUMBER: QSP-DES-001

REVISION: 1

Design Control Procedure

Approval

Reviewed by	Title	Date	Signature

Approved by	Title	Date	Signature

Scope

This procedure defines how [Company Name] plans, performs, reviews, documents, and controls the design and development of medical devices from feasibility to market launch. It covers the Design History File, customer requirements, design and development planning, design inputs, design outputs, design verification, design validation, design reviews, design transfer, and design changes occurring before market release. Devices that are software or incorporate software shall also be managed in conjunction with the Software Development Control Procedure[7]. Changes occurring after market release are excluded from this procedure and shall be managed in accordance with the Change Control Procedure[3].

The procedure has been defined for conformity to requirements described in the Document Master List[25].

Abbreviation

Acronym	Definition
D&D	Design and Development
DHF	Design History File
DMR	Device Master Record
DVP	Design Verification/Validation Protocol
DVR	Design Verification/Validation Report
EMC	Electromagnetic Compatibility
EU	European Union
GSPR	General Safety and Performance Requirements
IFU	Instructions for Use
MDF	Medical Device File
MDR	Medical Device Regulation (EU) 2017/745
MRI	Magnetic Resonance Imaging
PCB	Printed Circuit Board
QA	Quality Assurance
QMS	Quality Management System
SBOM	Software Bill of Materials
SDS	Software Design Specification
SOUP	Software of Unknown Provenance
SRS	Software Requirements Specification
UDI	Unique Device Identification
V&V	Verification and Validation

Reference Documents

Item	Document Number	Title
Procedure(s)
	QSP-DOC-002	Record Control Procedure
	QSP-DOC-001	Document Control Procedure
	QSP-DES-004	Change Control Procedure
	QSP-RR-001	Market Access Procedure
	QSP-DES-003	Risk Management Procedure
	QSP-DOC-003	Medical Device File Procedure
	QSP-DES-002	Software Development Control Procedure
	QSP-M&A-001	Data Analysis

Item	Document Number		Title	Identification System
				Record Number	Revision number
Form(s)
	FORM-DES-015	DHF Form		ZZZZ-DHF	Incremental
	FORM-DES-002	User Requirements Form		ZZZZ-UR-XXX	Incremental
	FORM-DES-003	Design Input Form		ZZZZ-DI-XXX	Incremental
	FORM-DES-004	Design Review Form		ZZZZ-DR-XXX	Incremental
	FORM-DES-005	Design Transfer Form		ZZZZ-DT-XXX	Incremental
	FORM-DES-010	Design and Development Planning Form		ZZZZ-PL-XXX	Incremental
	FORM-DES-001	Traceability Matrix Form		ZZZZ-TM-XXX	Incremental
	FORM-DES-008	Design V&V Test Protocol Form		ZZZZ-DVP-XXX	Incremental
	FORM-DES-009	Design V&V Test Report Form		ZZZZ-DVR-XXX	Incremental
	FORM-DES-011	Design Control Form		ZZZZ-DC-XXX	Incremental
	FORM-RR-020	EU Regulatory Strategy Report		See Market Access procedure[4]
	FORM-RR-001	Technical Documentation		See Market Access procedure[4]
	FORM-DOC-002	Medical Device File		See Medical device file procedure[6]
	FORM-DES-012	Risk Management Plan		See Risk management procedure[5]
	FORM-DES-013	Risk Analysis		See Risk management procedure[5]
	FORM-DES-014	Risk Management Report		See Risk management procedure[5]
	LOG-DOC-001	Document Master List		See Document control procedure[2]

Note: Current revision of the documents is available in the Document Master List[25].

ZZZ: project number / YYYY: years / XXX: incremental number

The documents and records referenced in this procedure are retained in accordance with the retention period defined in the Record control procedure [1].

Responsibilities

The Quality Manager is responsible for maintaining this procedure up to date.

The Project Manager is responsible for leading the design control process and coordinating the activities necessary to meet the defined milestones and timeline. The Project Manager is also responsible for maintaining the DHF.

The Core Team is the team assigned to the design and development of a specific product and is composed of representatives from each [Company Name] department relevant to that product.

The Technical Support Team is composed of experts in their respective fields, under the supervision of the Core Team members, and is involved as necessary during the design control process.

Note: The Core Team and the Technical Support Team together constitute the Cross-functional Team.

The Independent Reviewer is a participant who:

• • • • is not involved in the design control process for the specific device under review;
      • is required to participate in design reviews and design transfer meetings in order to provide an independent and objective point of view; and
      • is responsible for reviewing, approving, and signing the decisions resulting from the design review and transfer.

The Design Change Owner has the same responsibilities as the Project Manager during the design change control process.

The Direct Managers of the Core Team members are responsible for making a decision when escalation is deemed necessary.

Procedure

Design History File

A DHF shall be established and maintained for each device type or device family/model. The DHF shall contain, or reference, the records necessary to demonstrate that design and development activities were performed in accordance with this procedure, and that design and development outputs meet the applicable design and development input requirements, including the requirements applicable to each design and development stage.

The DHF form[9], shall be used as the traceability index for all DHF contents.

The DHF:

• identifies each DHF record/document (title, document number, revision, approval status);
• provides the location (e.g., Medical Device File) for documents controlled outside the DHF package.

The DHF is a controlled document and shall be updated in accordance with Document Control procedure[2].

The DHF shall include, as applicable, records and/or references to:

• Customer requirements
• Design and development plan(s) and updates
• Design inputs and associated approvals
• Design outputs (including specifications, drawings, software deliverables, labeling/IFU where applicable) and associated approvals
• Design review records
• Design verification protocols and reports
• Design validation protocols and reports
• Risk management documentation
• Records of design changes during development, including rationale and evaluation of impact
• Design transfer records demonstrating readiness for production/market release (as applicable), including approvals and handover documentation
• Any required external/regulatory design and development deliverables defined in the plan (e.g., usability engineering file elements, cybersecurity documentation, biocompatibility evidence), if applicable

The DHF shall be built progressively throughout each design and development stage. At minimum:

• DHF completeness is checked at each design review and prior to design transfer and/or market release (as defined by the plan).
• prior to release, the DHF shall be reviewed to confirm that required records are present (or appropriately referenced) and approved and to determine if pending concerns must be addressed.

Upon final design approval and authorization for market release (or design transfer, as applicable), the DHF shall be formally closed and approved by the designated function(s) (i.e., all core team members or their representatives)

After closure, the DHF baseline is not altered. Any proposed modification that may impact design, performance, safety, labeling, or intended use shall be assessed and processed through Change Control process[3] or if the change is deemed significant, a new design control process can be alternatively initiated. Any change to the design is recorded in the DHF form[9].

Design Development Process

The design and development process shall be planned, executed, controlled, and documented using a phase-gated model. The process is divided into five structured phases, each with defined objectives, required deliverables, and a formal design review (phase gate) prior to progression.

This procedure must be considered in conjunction with the Risk Management Procedure[5] for conducting the risk management activities.

When the device in scope of the design control process is a standalone software or embeds a software, this procedure must be followed in conjunction with the Software Development Control Procedure[7].

Design and development records generated through these phases shall be maintained within the DHF. Anticipation of activities are authorized but they need to be finalized when required as defined in the design and development plan[14] and the required outputs of each phase (Section 5.2.6). However, any change initiated during the design control process must be controlled according to Section 5.11 and must consider the anticipated activities.

Phase 1 – Feasibility (Creativity and Strategy)

The feasibility phase explores and analyzes high-level customer needs and market opportunities. Brainstorming, strategic evaluations and competitor analysis are conducted. Key outcomes include customer requirements, high-level product vision, and go/no-go feasibility analysis are documented in the User Requirements form[10].

Activities may include:

• capture of high-level customer/user needs and intended use/intended users;
• market and competitor assessment;
• preliminary regulatory pathway assessment and applicable standards identification;
• feasibility investigations (technical, clinical, manufacturing, supply chain).

The required outputs of phase 1 are defined in Section 5.2.6.

The feasibility phase is primarily documented via the User Requirement document[10] and Regulatory Strategies[19] and officially released by the Design Review.

Phase 2 – Design (Definition of Concept and Design Inputs)

The design phase establishes the design concept and formally approves complete and unambiguous design inputs.

Activities include:

• development and selection of the concept/product architecture;
• initiation of design and development planning[14]
• initiation of the risk assessment with hazard identification[22], [23]
• definition and approval of design inputs[11], including:
  • functional and performance requirements;
  • regulatory and applicable standard requirements;
  • safety requirements, including risk control requirements from risk management;
  • usability and human factors requirements where relevant;
  • labeling/packaging requirements where applicable;
  • requirements specific to the type of product (e.g., software, implants);
  • manufacturing and service constraints where applicable.
• initiation of traceability matrix[15] linked to the user needs.

The required outputs of phase 2 are defined in Section 5.2.6.

At completion of Phase 2, the design input baseline is formally approved (“frozen”). Any changes after this point shall be controlled in accordance with Design Changes requirements in Section 5.11.

Phase 3 – Development (Design Outputs)

The development phase establishes the product design and produces design outputs that are sufficient to support verification and enable subsequent transfer to manufacturing.

Activities include:

• detailed hardware/mechanical/electrical/software development;
• prototyping and engineering builds;
• definition of manufacturing processes at a preliminary level to ensure design for manufacturability;
• creation of inspection/measurement approaches to enable verification.
• update of design control documents:
  • traceability matrix[15] linked to the design inputs
  • design and development planning[14]
  • risk assessment with risk estimation and analysis[23]
• generation of all design outputs required for each specific product design and manufacturing process.

The required outputs of phase 3 are defined in Section 5.2.6.

At completion of Phase 3, the design outputs are established and ready to be verified and validated against the design input acceptance criteria and user needs. Any changes initiated during this phase shall be controlled in accordance with Design Changes requirements in Section 5.11.

Phase 4 – Industrialization (Verification and Validation)

This phase 4 confirms the device meets specified requirements and intended use, and establishes a capable manufacturing system. Although the industrialization phase is finalized in phase 4, the process is generally initiated during phase 3.

Activities include:

• completion of design verification to demonstrate design outputs meet design inputs;
• design validation to confirm the device meets user needs and intended use (including simulated use and/or clinical evaluation, as applicable);
• usability validation where required by intended users and use environment;
• definition and qualification/validation of production processes, inspection methods, packaging, labeling, and test equipment as applicable;
• finalization of product specifications and quality controls (incoming, in-process, final acceptance).
• update of design control documents:
  • traceability matrix[15] with design verification & validation activities linked to the design outputs
  • design and development planning[14]
  • risk assessment with finalization of risk analysis[23] and risk management report[24].
• Generation of all evidence of design verification and validation test protocols[16] and reports[17].

The required outputs of phase 4 are defined in Section 5.2.6.

At completion of Phase 4, the design verification, design validation, manufacturing process are established, complete and documented. Any changes initiated during this phase be controlled in accordance with Design Changes requirements in Section 5.11.

Phase 5 – Market Launch (Design Transfer and Regulatory Approval)

The phase of market launch ensures a complete controlled transfer to production and support regulatory approval and launch readiness.

Activities include:

• formal design transfer to manufacturing, ensuring production can consistently meet specifications;
• training of manufacturing/inspection/service personnel where applicable;
• establishment of release criteria and QA release process for production lots;
• confirmation of the DHF completion
• post-transfer checks (e.g., initial production monitoring, process performance confirmation) as defined in the transfer plan.
• documentation of design transfer
• completion of technical documentation[20] and medical device file[21]
• regulatory submissions according to the market access procedure[4];

The required outputs of phase 5 are defined in Section 5.2.6.

At completion of Phase 5, the design control process is finalized, the device can be produced in lot or serial number as necessary, the first planned submissions have been initiated^[1]. Any changes initiated during this phase be controlled in accordance with Design Changes requirements in Section 5.11. Any Design Changes initiated after Phase 5 is controlled via the Change Control procedure[3].

Required Outputs of Design Control Phases

As a result, the following deliverables are required at the end of each phase and their presence will be verified during the corresponding design reviews.

The following table must be customized as necessary.

Document Type	Phase Deliverable	Phase 1 – Feasibility	Phase 2 – Design	Phase 3 – Development	Phase 4 – Industrialization	Phase 5 – Market Launch
Design planning & governance	Preliminary planning	X				X
	Design & development plan		X	X	X	X
	Traceability Matrix		X	X	X	X
	Design review	X	X	X	X	X
Design inputs	Customer requirements	X				X
	Market analysis	X				X
	Regulatory strategy (including clinical strategy)	X				X
	List of legislative requirements (legal texts, common specifications, pharmacopeia, standards)		X
	Feasibility analysis	X				X
	Device description and intended use statement		X	X		X
	Design inputs (regulatory, performance, safety, usability, standard compliance, labeling, cybersecurity, etc.)		X			X
Design outputs	Drawings			X		X
	Material specifications			X		X
	Bill of materials			X		X
	Packaging specifications			X		X
	Label specifications			X		X
	IFU specifications (including user IFU, patient leaflet, surgical procedure)			X		X
	Implant card specifications			X		X
	UDI Strategy			X
	Supplier agreement				X	X
	Risk management file		X	X	X	X
	Purchasing requirements			X		X
	Incoming inspection requirements			X		X
	Installation requirements and specifications			X		X
	Servicing requirements and specifications			X		X
Dossiers	Medical Device File					X
	DHF	X	X	X	X	X
	Technical Documentation				X	X
Design verification & validation	Performance verifications				X	X
	Biocompatibility evaluation				X	X
	Human factor evaluation (usability engineering file with formative/summative studies)				X	X
	Software validation				X	X
	Cybersecurity validation				X	X
	Penetration test specifications				X	X
	Pen test report				X	X
	Cleaning /disinfection validation				X	X
	Sterilization validation				X	X
	Stability test				X	X
	Lifetime validation test (fatigue test)				X	X
	Shipping test				X	X
	Electrical safety test				X	X
	EMC test				X	X
	MRI compatibility test				X	X
	Animal tests				X	X
	Cadaver test				X	X
	Clinical investigation				X	X
	Clinical evaluation				X	X
Production	Manufacturing flowchart				X	X
	Manufacturing instructions				X	X
	Manufacturing process specifications				X	X
	Control of environmental conditions				X	X
	List of adjuvants				X	X
	In process control specifications				X	X
	Qualification of measuring equipment				X	X
	Process FMEA				X	X
	Final control specifications				X	X
	Final release specifications				X	X
	Process validation (e.g. sterilization, packaging,…)				X	X
	Test method validation				X	X
	Training				X	X
Electrical components	Electrical schematics			X		X
	PCB layout files			X		X
	Technical sheets (e.g., power, battery, product requirements)					X
Software	Software development plan		X			X
	Software architecture			X		X
	Software requirements specifications (SRS)			X		X
	Software design specifications (SDS)			X		X
	Software system specifications			X		X
	Software anomaly/defect list				X	X
	Release notes / build & configuration records				X	X
	SOUP / third-party software list + evaluation					X
Cybersecurity	Cybersecurity requirements		X			X
	Security architecture			X		X
	Threat modeling / cybersecurity risk assessment		X	X	X	X
	Vulnerability management specifications		X			X
	Privacy requirements		X			X
	Interoperability/network requirements		X			X
	SBOM (if applicable/required)			X
	User specifications		X			X
	Cybersecurity post-market plan					X

Customer Requirements

Customer requirements shall be identified, captured, and maintained using a dedicated, controlled form during the Feasibility Phase. Customer requirements are completed in the User Requirements form[10]. In addition, the relevant Regulatory Strategies[19] define and capture market-access requirements that serve as inputs to the User Requirements Form[10].

The Project Manager with the support of Core-Team members is responsible for completing the Customer Requirements document. Additional individuals part of the Technical Support team may be involved as necessary to constitute a cross-functional team.

Customer requirements must be:

• objective

They shall be written to enable conversion into measurable design inputs, with acceptance criteria that can be objectively assessed during design validation

• complete and unambiguous

The cross-functional team shall review the customer requirements to confirm completeness, consistency, feasibility and confirm that ambiguities, conflicts, or inconsistencies are resolved. The Customer Requirements document is then approved after review by all members of the cross-functional team.

Once approved, the customer requirements are inserted in the Traceability Matrix[15] to ensure end-to-end traceability from customer requirements to design inputs and, subsequently, to design outputs, verification activities and validation activities, as applicable.

After approval, any changes to customer requirements must be controlled in accordance with Design Changes requirements in Section 5.11.

Records of customer requirements are maintained in the DHF.

Design and Development Planning

Design and Development (D&D) Planning begins at project initiation and is documented in the Design and Development Planning document[14]. The D&D Plan defines the controls and resources needed to ensure the design is developed in a controlled manner and meets applicable quality, safety, performance, and regulatory requirements. This D&D planning includes:

• Project scope, including device description, proposed intended use statement, and project framework (e.g., market of interest and corresponding requirements)
• Organization and resources, including team membership (Core Team and Technical Support team), required competencies, infrastructure, tools, software, etc.
• Assigned responsibilities, and authorities, including decision-making, escalation routes, and approval responsibilities for deliverables and phase transitions
• Interfaces between team membership throughout the design and development
• Applicable regulatory requirements, including the intended market(s), and jurisdictional requirements (e.g., MDR)
• Project timeline and milestones, including phase gates
• The design and development stages and planned design reviews
• The risk management activities throughout the design and development, including, risk management plan, risk analysis and risk management report.
• Traceability approach, including reference to the traceability matrix[15] to document links between the design outputs and design inputs
• Verification and validation strategies
• Design transfer strategy

The D&D Planning is reviewed and updated throughout the project according to the Record Control procedure[1]—at a minimum at each phase/stage transition and whenever there are significant changes to scope, requirements, risks, resources or regulatory strategy. The plan ensures controlled progress through the design lifecycle and provides objective evidence that deliverables remain aligned with quality and regulatory expectations.

An optional Operational Project Planning may be maintained to support day-to-day task execution (e.g., task lists, sprint plans, Gantt chart, or spreadsheet). This operational plan may have a flexible format; however, it shall remain consistent with the controlled D&D Planning [14].

Records of D&D Planning are maintained in the DHF.

Design Inputs

Design inputs are the documented requirements that serve as the foundation for product design. They are established from user needs, intended use, applicable regulatory requirements, and other relevant product and process requirements. Design inputs may include, as applicable:

• Functional requirements (e.g., device features, operating modes, software functions)
• Performance requirements (e.g., accuracy, sensitivity, specificity, output range, durability, reliability)
• Usability requirements (e.g., user interface characteristics, user profile considerations, use environment, human factors requirements)
• Safety requirements (e.g., electrical safety, biocompatibility, mechanical safety, cybersecurity, infection control)
• Applicable regulatory requirements (e.g., GSPR under MDR)
• Applicable standards requirements (e.g., IEC 60601 series, IEC 62366-1, IEC 62304, as applicable)
• Outputs of risk management; identified risk control measures and residual risk considerations within the design lifecycle from the risk management file shall be considered as design inputs throughout the design control process.
• Information derived from previous similar designs, where applicable, including lessons learned, complaints, nonconformities, post-market data, or prior verification and validation activities
• Any other requirements essential for the design and development of the product and associated processes (e.g., labeling requirements, packaging requirements, environmental conditions, shelf-life requirements, manufacturing constraints, servicing requirements)

Design inputs shall be complete, clear, unambiguous, and verifiable. Accordingly, they shall be stated in measurable terms and include defined acceptance criteria or limits. Such acceptance criteria may be established on the basis of applicable standards, benchmark testing, scientific non-clinical and clinical literature, clinical data, simulated use studies, engineering calculations, finite element analysis, user evaluations, questionnaires, or other justified sources.

Note: Acceptance criteria shall be established independently of the test results obtained for the device being developed.

Design inputs shall be documented in the Design Inputs document [11]. They shall be reviewed for adequacy, completeness, clarity, lack of conflict with one another, and suitability for subsequent verification. This review shall ensure that the design inputs can serve as a valid basis for design verification activities intended to confirm that design outputs meet design input requirements. Design inputs shall also be recorded in a traceable manner within the Traceability Matrix[15].

Records of Design inputs are maintained in the DHF.

Design Outputs

Design outputs are the documented results of the design and development process. They include all product characteristics and specifications necessary to ensure the safe and proper use of the device, as well as the information needed for purchasing, production, installation, servicing, and maintenance, as applicable.

Design outputs may include, as applicable:

• Drawings
• Electrical schematics, PCB layouts, and electronic circuit diagrams
• Software architecture, software specifications, and software requirements
• Cybersecurity specifications and requirements
• Material specifications
• Bill of materials
• Packaging specifications
• Labeling specifications
• Instructions for use specifications, including user instructions, patient leaflets, and surgical procedures, as applicable
• Implant card specifications, where applicable
• UDI strategy and related identification specifications
• Supplier specifications and supplier quality requirements or agreements
• Risk management file and risk control implementation records
• Purchasing requirements
• Incoming inspection requirements
• In-process and final inspection/release specifications
• Installation requirements and specifications, where applicable
• Manufacturing process specifications and work instructions
• Process validation requirements
• Environmental conditions and requirements for monitoring and measuring equipment
• Servicing requirements and specifications, where applicable

Design outputs shall define the device characteristics necessary to meet the design input requirements and to ensure the safety, performance, and intended use of the device. Where applicable, design outputs shall include acceptance criteria and specifications to be applied during purchasing, production, installation, and servicing activities, so that conformity of the device can be routinely assessed or validated.

Design outputs shall be evaluated against design input requirements through design verification activities. They shall be adequate to ensure that the device can be manufactured, inspected, released, installed, and serviced in a controlled manner. Each design output is referenced in a traceable manner within the Traceability Matrix[15] and shall be documented, reviewed, and approved prior to release, and maintained within the DHF.

Design output documents shall also serve as the basis for the Device Master Record (DMR) or Medical Device File (MDF), as applicable.

Design Verification

Design verification activities are the examinations, tests, inspections, analyses, or other objective evaluations performed to confirm that the design outputs meet the defined design input requirements. Design verification shall be conducted in accordance with the arrangements defined in the Development Planning document[14] and the documented design requirements, using the Design V&V Test Protocol[16] and Design V&V Test Report[17], as applicable.

Design verifications may include, as applicable:

• Performance verifications
• Bench testing
• Electrical safety testing and EMC testing
• MRI compatibility testing
• Software testing
• Biocompatibility testing
• Dimensional analysis
• Functional testing
• Animal testing
• Stability testing
• Shipping testing
• Lifetime or fatigue testing

Design verification activities shall be documented and, as applicable, shall include:

• Test methods
• Acceptance criteria established on the basis of design input requirements
• A rationale demonstrating the representativeness of the device(s), sample(s), or configuration(s) selected (i.e., worst-case samples) for testing
• A sampling plan established using statistical techniques, as defined in the Data Analysis procedure[8], where applicable
• Verification of the device when connected to, or interfaced with, other devices, where such connection or interface is intended or reasonably foreseeable

The design verification protocol shall be established prior to execution of the verification activities in order to define and document the test arrangements, responsibilities, methods, acceptance criteria, and records to be generated. The design verification report shall document the results obtained, any deviations observed, the assessment of conformity with acceptance criteria, and the overall conclusions. Any deviation from the approved protocol, unexpected result, or failure to meet acceptance criteria shall be documented, assessed, and justified as appropriate. Where necessary, such deviations or failures shall lead to corrective actions and/or design changes in accordance with Section 5.11 of this procedure, including re-testing where justified.

Design verification protocols and reports shall be documented, reviewed, and approved. Results and conclusions shall be clearly traceable to the applicable design input and design output requirements they address.

Each design verification is referenced in a traceable manner within the Traceability Matrix[15]. Records of design verification shall be maintained in the Design History File (DHF).

Design Validation

Design validation activities are the examinations, tests, studies, or other objective evaluations performed to confirm that the device conforms to defined user needs and intended uses, under actual or simulated use conditions. Design validation shall be conducted in accordance with the arrangements defined in the Development Planning document[14] and the documented design requirements, using the Design V&V Test Protocol[16] and Design V&V Test Report[17], as applicable.

Design validation activities may include, as applicable:

• Usability validation
• Simulated use testing
• Clinical evaluation
• Clinical investigation, where applicable
• Performance validation under actual or simulated use conditions
• Software validation
• Human factors or user interface validation
• Validation of installation and servicing procedures, where applicable

Design validation activities shall be documented and, as applicable, shall include:

• Validation methods
• Acceptance criteria established on the basis of user needs and intended use.
• A rationale demonstrating the representativeness of the device(s), sample(s), or configuration(s) selected for validation (i.e., worst case samples).
• A sampling plan established using statistical techniques, as defined in the Data Analysis procedure[8], where applicable
• Design validation performed under actual or simulated use conditions
• Traceability to the initial production units, equivalent production units, or their equivalents, as appropriate, used during Design validation

The design validation protocol shall be established prior to execution of the validation activities in order to define and document the test arrangements, responsibilities, methods, acceptance criteria, use conditions, and records to be generated. The design validation report shall document the results obtained, any deviations observed, the assessment of conformity with acceptance criteria, and the overall conclusions regarding the ability of the device to meet user needs and intended uses.

Any deviation from the approved protocol, unexpected result, or failure to meet acceptance criteria shall be documented, assessed, and justified as appropriate. Where necessary, such deviations or failures shall lead to corrective actions and/or design changes in accordance with Section 5.11 of this procedure, including additional validation or re-validation where justified.

Design validation protocols and reports shall be documented, reviewed, and approved. Results and conclusions shall be clearly traceable to the user needs, intended use, and applicable design input requirements they address.

Each design validation is referenced in a traceable manner within the Traceability Matrix[15]. Records of design verification shall be maintained in the Design History File (DHF).

Design Reviews

Design reviews are systematic and documented reviews performed at suitable stages of the design and development process in accordance with the arrangements defined in the Design and Development Planning document[14].

Design reviews shall be conducted to:

• evaluate the ability of the design and development results to meet the applicable requirements for the stage under review; and
• identify, document, and propose any necessary actions before progression to the next stage or before release of the relevant design deliverables.

Formal design reviews shall be conducted, at a minimum, at each phase gate of the design and development process described in Section 5.2. Additional design reviews may be initiated whenever necessary, including in case of significant design changes, major verification or validation failures, important risk management updates, major regulatory changes, unresolved technical issues, or whenever the Core Team determines that a formal documented review is needed to assess design status and define actions.

Participants in each design review shall include representatives of the functions concerned with the design and development stage being reviewed according to the Design and Development Planning document[14], as well as any other specialist personnel necessary to adequately assess the design. Depending on the stage under review, required participants include core-team members or their representatives and an independent reviewer.

Each design review shall be prepared and documented using the Design Review Form[12]. The review shall identify, at a minimum:

• the design under review (e.g., project name, device name, and development phase/stage);
• the objective and scope of the review;
• the availability and suitability of documents and deliverables reviewed during the phase as defined in Section 5.2.6;
• the problems, risks identified during the stage.
• the participants involved and their functions;
• the date of the review.

In practice, the design review shall be performed as follows:

• Preparation
  • the Project Manager or designated Core Team member organize the design review in accordance with the Design and Development Planning[14];
  • the Project Manager prepare the design review meeting minutes using the Design Review Form[12], identify all required design review inputs according to Section 5.2.6 and any other documents generated during the phase,
  • the Project Manager with the support of Core-team members, review the different documents and conclude on their suitability, or identify any gaps to be discussed during the Design Review meeting,
• Design Review Meeting
  • the participants systematically assess whether the outputs of the current stage are complete, adequate, approved as needed, and capable of meeting the applicable requirements;
  • the participants assess whether identified risks, open issues, and pending actions are adequately addressed or require escalation;
  • the participants determine whether:
    • the DHF is complete for the stage under review
    • the design is ready to progress to the next stage, requires additional work before progression, or should be placed on hold or stopped.

The outcome of each design review shall include a documented decision, such as:

• Go: the design may proceed to the next stage;
• Go with actions: the design may proceed subject to completion of defined actions within agreed timelines; any necessary actions resulting from the design review shall be documented in the next design review.
• On Hold: progression is suspended pending completion of required actions or resolution of identified issues; any necessary actions resulting from the design review (e.g., new action list, return to the previous design phase, design change) shall be documented in a new design review to decide if the project can be resumed.
• Stop: the project or design stage is discontinued.

Records of the results of each design review and any necessary actions shall be maintained in the DHF.

Design Transfer

Design transfer is the systematic and documented process of ensuring that the final device design is correctly translated into production specifications, manufacturing processes, quality controls, and related support activities, so that the device can be consistently manufactured, inspected, released, installed, and serviced in conformity with the approved design requirements.

Design transfer shall be conducted in accordance with the arrangements defined in the Design and Development Planning document[14] and shall be completed before commercial production and market launch, as applicable. Design transfer records shall be documented using the Design Transfer Form[13] and are referenced in the DMR, or MDF[21] and implemented according to the Medical Device File procedure[6].

Design transfer shall confirm, as applicable, that:

• approved design outputs are complete and available for production use;
• manufacturing instructions, work instructions, and process specifications are established and approved;
• purchasing specifications, supplier requirements, and incoming inspection requirements are defined and released;
• in-process controls, final inspection requirements, and release criteria are established;
• required process validation and test method validation activities are completed or planned with justified status;
• packaging, labeling, storage, handling requirements are defined and actionable in production;
• installation, and servicing requirements are defined and transferred, as applicable;
• required infrastructure, utilities, work environment conditions, monitoring and measuring equipment, and production resources are available and suitable;
• production, quality control, installation, and servicing personnel are trained, where applicable;
• residual risks, risk control measures, and risk-related production controls are implemented as required;
• the design can be consistently reproduced in production without compromising the approved design requirements.

Participants in each design transfer shall include representatives of the functions concerned with the design and development Phase 5 according to the Design and Development Planning document[14], as well as any other specialist personnel necessary to adequately assess the transfer in production. Required participants include core-team members or their representatives and an independent reviewer.

The results of design transfer shall be documented in the Design Transfer Form[13]. The record shall identify, at a minimum:

• the design under transfer (e.g., project name, device name, device family/model, version or configuration);
• the scope of the transfer;
• the documents and records reviewed;
• the availability and suitability of documents and deliverables reviewed during the phase as defined in Section 5.2.6;
• the participating functions and persons involved;
• the problems, risks identified during the stage.
• the date of transfer review;
• any open issues, deviations, or pending actions;
• the final conclusion regarding readiness for production and/or market launch.

In practice, the design transfer shall be performed in the same way as the design review. The outcome of the design transfer shall include a documented decision, such as:

• Go: the design is complete and the device is transferred in production
• Go with actions: the design is transferred in production despite non-significant pending actions that must be completed within agreed timelines.
• On Hold: progression is suspended pending completion of required actions or resolution of identified issues; any necessary actions resulting from the design transfer (e.g., new action list, return to the previous design phase, design change) shall be documented in a new design transfer to decide if the project can be finalized.
• Stop: the project or design transfer is discontinued.

Records of the results of design transfer and any necessary actions shall be maintained in the DHF for which the completeness shall be confirmed prior to design transfer and/or market release.

Design Change

Design and development changes arising during the design and development process shall be identified, documented, reviewed, and controlled to ensure that the medical device continues to meet specified design input requirements, intended use and applicable regulatory requirements.

For the purpose of this procedure, a design change is any modification to:

• approved user needs requirements or acceptance criteria (e.g., intended use, intended user profile, use environment, usability expectations),
• approved design inputs requirements or acceptance criteria (e.g., performance requirements, functional requirements, usability requirements, safety requirements, interface requirements), or
• approved design output specifications (e.g., drawings, components, labeling, packaging, manufacturing process specification),

that is generated during the design and development process.

The design change is carried out in 5 Stages:

• Stage 1: design change identification and description
• Stage 2: change impact assessment and action plan
• Stage 3: implementation of action plan
• Stage 4: design change review for transfer
• Stage 5: change release

Changes occurring after market release are not covered by this section and shall be managed in accordance with the Change Control procedure[3], as applicable.

Stage 1: Design Change Identification and Description

Any design and development change proposed during the design control process shall be formally identified and documented before implementation.

The change record shall include, as applicable:

• identification of the project, device, and affected design element(s);
• assignment of design change owner;
• description of the proposed change;
• reason and justification for the change;
• identification of the affected user needs, design inputs, design outputs and specifications;
• identification of the design phase at which the change is initiated.

Design changes shall be recorded in the Design Control Form[18].

Stage 2: Change Impact Assessment

The organization shall determine the significance of the design and development change with regard to the device, its intended use, safety and performance, and compliance with applicable regulatory requirements, as well as the documentation already generated within the design and development.

This assessment shall consider, as applicable, the effect of the change on:

• user requirements and intended use;
• design inputs and design outputs;
• device function and performance;
• usability and user interface characteristics;
• safety of the device;
• applicable regulatory requirements and applicable standards;
• risk management inputs and outputs;
• constituent parts and components;
• products in process or already released in the warehouse;
• verification and validation activities already completed or planned;
• other affected documented information, as applicable.

Based on this assessment, the organization shall:

• determine the extent of the change, verification activities, validation activities, and other actions necessary to support the change. The extent of verification and validation shall be commensurate with the nature and significance of the change;
• plan the implementation of changes (e.g., timeline, deadlines, milestones, resources), as necessary.

Stage 2: Review of Design Changes

As defined in the Design & Development Planning document[14], at least the core-team members assigned to the phase of the design and development process where the design change is initiated, shall review and discuss the impact assessment to document the decision, as follows:

• Go for implementation: the design change can be implemented.
• Go for implementation with actions: the design change can be implemented as defined, but the action plan needs to be revised for non-significant justified reasons.
• On Hold: the design change cannot be initiated and the impact assessment must be reviewed. The design change process returns to Section 5.11.2.
• Stop: the design change is cancelled with the decision to reinitiate a change or close the project.

The required participants shall approve and sign the decision in the Design Control Form[18].

Stage 3: Implementation of Action Plan

The action plan shall be implemented according to the planning and deliverables are documented in the Design Control Form[18]. At this stage, all deliverables are documented but not transferred into the DHF.

As part of the action plan, design verification, design validation, and process validation shall be carried out, as applicable to confirm that:

• the modified design outputs continue to meet design input requirements;
• the change does not adversely affect the safety, performance, or usability of the device;
• the device continues to meet its intended use and applicable regulatory requirements.

Where verification and validation are not both necessary, the rationale shall be documented.

Stage 4: Design Review for Transfer to DHF

Design changes shall not be transferred into the DHF until it has been:

1. reviewed;
2. verified;
3. validated, as appropriate;
4. approved.

When the action plan is complete and finalized, a new design review documented in the Design Control Form[18] shall be organized by the design change owner. As defined in the Design & Development Planning document[14], at least the core-team members assigned to the phase of the design and development process where the design change is initiated must be convened.

All documents generated during the design change process, including verification and validation records, are reviewed and analyzed to conclude on the decision as follows:

• approve for transfer: the design change documents must be transferred to the DHF form[9] and the design and development process can be resumed.
• approve for transfer with actions: the design change is on hold as it is not considered finalized; however, no reassessment is required. The remaining or missing actions must be identified with the decision. Once the pending actions are finalized, a new design review will be required for approval of the change.
• reassess: the design change is on hold and the impact assessment must be reviewed. The design change process returns to Section 5.11.2. The documents generated remain in the Design Change folder but are not transferred to the DHF.
• stop: the design change is closed without implementation; the project status shall be determined separately, as applicable.

The decision to authorize the transfer shall be documented in the DHF form[9] by at least the core-team members. In case of disagreement between core-team members, an escalation process with the managers of core-team members can be organized to conclude on the final decision.

Stage 5: Change Release

All approved design control documents generated or updated as part of the design change shall be transferred to the DHF. Once the transfer is completed, the Design Change Owner shall review the DHF to confirm that the transferred records are complete, accurate, and adequate to reflect the approved design change. The design change shall not be considered closed until this transfer has been completed and verified. The Design Change Owner shall then sign the Design Control Form to formally close the design change.

Process Flowchart

Revision

Revision	Effective Date	Change Description	Affected documents	Change #
1		Creation	–	–

Appendices

N/A

1. Phase 5 closure is not contingent upon market authorization in the intended countries. ↑