Design Controls – In the Order They Actually Happen

Step 1: Design and Development Plan

This is prepared before design work begins.

The plan explains:

• The different stages of design and development

• When design reviews, verification and validation will take place

• Design transfer activities

• Responsibilities of different people or teams

• How design changes will be controlled

The plan should be updated when the project changes or develops. These updates should also be documented.

A two-year development project with a plan that never changed may raise questions about whether the process was actually followed.

Step 2: Design Inputs

Design inputs describe what the medical device needs to achieve.

They may include:

• Functional and performance requirements

• Usability requirements

• Safety requirements

• Applicable regulatory requirements

• Applicable standards

• Risk management results

• Relevant information from previous or similar designs

Inputs must be reviewed to make sure they are:

• Complete

• Clear and unambiguous

• Verifiable

• Consistent with each other

Design inputs should be written before the solution is finalized. If they simply describe the finished product, it can appear that the requirements were created after the design was already completed.

Step 3: Design Outputs

Design outputs describe what the final design needs to deliver.

They should:

• Meet the design input requirements

• Provide the information needed for purchasing and manufacturing

• Support service activities where applicable

• Include or refer to acceptance criteria

• Identify important characteristics needed for the device to be safe and work properly

Design outputs must be reviewed and approved before they are released.

Step 4: Design Review

Design reviews are performed at planned stages of development.

People from the relevant functions should participate in the review, along with specialists when needed.

The records should show:

• Who participated

• The date of the review

• The review results

• Any actions that need to be completed

A review conducted only by the designer is generally not a strong design review. Auditors will look at who participated and whether the right functions were involved.

Step 5: Design Verification

Design verification confirms that:

“Did we build the device according to the requirements?”

Verification checks whether the design outputs meet the design inputs.

This can involve:

• Testing

• Analysis

• Inspection

• Comparison with proven designs

The verification plan should define:

• The method to be used

• Acceptance criteria

• Statistical methods, where applicable

• The reason for the selected sample size

If the device is designed to work with or connect to another device, verification should also confirm that it meets the requirements when used with that device.

Step 6: Design Validation

Design validation confirms that:

“Did we build the right device for its intended use?”

Validation checks whether the device meets the requirements for its specified application and intended use.

It should be performed using representative product, such as:

• Initial production units

• Production lots or batches

• An equivalent product, when properly justified

Where required by regulations, validation also includes appropriate clinical evaluation or performance evaluation.

Validation must be completed before the product is released for sale.

Verification vs. Validation

A simple way to remember the difference:

Verification: Did we build the device right?

Validation: Did we build the right device?

Both activities are required and should not be treated as the same thing.

Step 7: Design Transfer

Design transfer is the process of moving the approved design into manufacturing.

The process should ensure that:

• Design outputs are suitable for manufacturing

• The final production specifications are properly defined

• Manufacturing can consistently meet the product requirements

This is often an area where documentation is weak.

The key question is:

Is the device that was validated actually the same device that will be manufactured?

Step 8: Design Changes

Design changes must be:

• Identified

• Documented

• Reviewed

• Verified, where required

• Validated, where required

• Approved before implementation

The impact of a change should be assessed, including its effect on:

• Function

• Performance

• Usability

• Safety

• Regulatory requirements

• Products that have already been distributed

The last point is often missed.

A design change may affect products that are already in the market, so this impact must be properly considered.

The Design File

Each device or device family should have a design file that contains or references records showing:

• How the design requirements were met

• Design and development activities

• Reviews

• Verification and validation

• Design transfer

• Design changes

The file should provide clear evidence that the design process was properly followed.

What Auditors Usually Check

Auditors may select one device and follow the entire design history from beginning to end.

They will check the sequence:

Plan → Inputs → Outputs → Reviews → Verification → Validation → Transfer → Changes

They also check the dates and supporting records.

For example:

• Was the plan created before design inputs?

• Were inputs defined before outputs?

• Were reviews performed at the planned stages?

• Were the right people involved?

• Was verification performed against the inputs?

• Was validation performed on representative product?

• Was validation completed before release?

• Was design transfer documented?

• Were design changes properly controlled?

If the records do not follow a logical timeline, it can create doubts about whether the design control process was actually followed.

Common Design Control Weaknesses

1. Design inputs were created after the design was already completed.

2. Design reviews do not identify participants or were conducted only by the designer.

3. Verification and validation were treated as the same activity.

4. Validation was performed only on prototypes instead of representative production product.

5. Design transfer was not properly documented.

6. Design changes did not consider their impact on products already distributed.

7. There is no clear justification for verification sample sizes.

8. Risk management results were not properly considered when defining design inputs.

The key takeaway

For ISO 13485 design controls, the order matters.

A strong design history should clearly show:

What was planned → what was required → what was designed → what was reviewed → what was verified → what was validated → how it was transferred to production → how later changes were controlled.

The records should tell the same story as the actual development process.