Design Control Guidance

If you're designing a medical device, regulatory agencies require you to have a design control process in place, in order to ensure that your product which has an acceptable level of quality. You can't simply rely on the individual skills of your design team, or on heroic engineering to get the job done.

You must have a process in place which is repeatable, and has certain characteristics built into it to ensure that what you design and build is as safe and effective as possible. Medical device regulators do not dictate the design process that you must follow, but they do specify some of the characteristics that it must include.

In the United States, the Food and Drug Administration covers this in the Quality System Regulation, 21 CFR Part 820. Rather than force you to comprehend bunch of legalese unassisted, the FDA Centre for Devices and Radiological Health has a published the document Design Control Guidance For Medical Device Manufacturers. This document is indispensable for anyone involved in the design of a medical device, and was developed with input from the Global Harmonisation Task Force, meaning its advice is applicable globally, and not just for devices intended for the US market.

The guidance document covers many important issues including: (Note that the links in this list are to related information on GreatEngineering.net rather than to the FDA Guidance document itself. I encourage you to read both).

• Its relationship to ISO 9001 and ISO 13485.

• Separation of design inputs (Requirements) from design outputs (Design Decisions)

• The hierarchical nature of the design process.

• Verification that design outputs meet their input requirements at every level.

• The relationship between Validation and Verification.

• The use of Concurrent Engineering.

• Risk Management.

• Project Management content required in the Design & Development Plan.

• Requirements (a.k.a. Design Input) management.

• Why a Marketing Product Concept document doesn't adequately capture System Design Input Requirements.

• The difference between Prototype development and Product development.

• Why designers should be responsible for codifying their input requirements.

• The three main groups of System Requirements: Functional, Performance and Interface.

• How to assess input requirements for adequacy.

• Formal design reviews, including their nature, how to conduct them, and their depth of coverage.

• Using consistent, Standards-based terminology in your organisation.

• Verification activities.

• The difference between Design Verification and Production Testing.

• Design Validation

• Document Control and Design Change Control

• Organisation of the Design History File.

---

Social Bookmark this page: