Medical Device Design Controls: My Review

When I finished my M.S. degree in Biomedical Engineering from Cal Poly, I thought I knew what “design controls” were. I’d taken classes on them, I’d seen guest speakers from the FDA talk about them, and I’d been tested on them during exams.

I was wrong.

It has taken me YEARS of working in the industry to finally grasp what Design Controls are, why they’re useful/required, and how good documentation practices can make audits a lot easier.

For others out there who are curious about Medical Device Design Controls, I’ll lay out the basics here at a very high level.

In essence, Design Controls establish that:

·???????Your medical device is safe

·???????Your medical device is effective

·???????Your medical device satisfies user needs and requirements

In order to discuss Design Controls, first I need to mention the Quality System.

At least four aspects of a good Quality System include the following:

1.?????Design Controls

2.?????Risk Management

3.?????Document Control & Records Management

4.?????Supplier Management

The rules for your Quality System are defined by the FDA (21 CFR, Part 820), and are required if you plan to sell your product in the US. If you plan to sell outside the US, Europe for example, you must follow ISO 13485:2016's guidelines. Luckily, 21 CFR, Part 820 and ISO 13485:2016 are very similar.

You can not have a safe/effective/high quality medical device product that delivers intended results to customers without a solid Quality System, and therefore, Design Controls.

It would be nice if your medical device product had no issues and functioned flawlessly, but this is not realistic. There will be issues, and there will be risks. So how do you mitigate these risks?

Risk Management must be integrated into your Design Controls in order for you to detect, assess, investigate, and moderate potential product issues. It is a good rule of thumb that good design controls reduce product risks.

Evaluating risks is no simple task, especially for more complex medical devices. Risk Controls that help mitigate and reduce risk are often:

·???????Design Outputs

·???????Design Verification

·???????Design Validation

Now that we’ve established how we will mitigate risk, we need to talk about the overall Product Development Process. This process can vary from company to company but usually follows these phases:

1. Planning: Come up with the project scope
2. User Needs: Identify user requirements
3. Design Input: Define and design product specifications
4. Design Output: Identify design outputs and verification methods
5. Design Verification: Proves that the product matches the design inputs
6. Design Validation: Proves that the product meets the user needs
7. Market Release: Launch into production and sell to customers

During your Product Development Phase, you’ll need a place to keep all of your Design Controls. This is what is called the Design History File (DHF). Design Controls should all be related and linked, and the DHF is where you can demonstrate these relationships.

I know all of this is very structured, and for me, when I’m dealing with Design Controls, I feel closer to the product than the patient. However, User Needs are what brings me back closer to the patient, and this is the reason I’m in this industry in the first place: to help people.

User Needs should include Intended Use and Indications for Use.

·???????Intended Use: the purpose of your medical device

·???????Indications for Use: identifies the condition or disease the med device product will detect, treat, prevent, or alleviate.

It’s a good rule of thumb that Design Reviews should be happening during this entire process. The FDA does not require any certain number of Design Reviews but they advise that you have Design Reviews after each stage of the Product Development Process.

When you host Design Reviews, you must document that you’ve included all Design Controls as part of these Design Reviews.

Now let’s get into the specifics (and my favorites): Design Inputs, Design Outputs, Verification, and Validation. These, in my opinion, are the meat and bones of Design Controls.

Design Inputs are the requirements and features of your product. Remember that User Needs are a major element that feed into Design Inputs. As a good rule of thumb, Design Inputs should be quantitative and not subjective. Design Inputs function as a “road map” that a designer uses to develop the product.

Alternatively, Design Outputs are the concrete instructions, specs, and drawings that are used to build or assemble your medical device. The Design Outputs functions as the initial Device Master Record. An easier way to think about this is the “recipe” for your product.

Next, we move onto Design Verification. This is about demonstrating your Design Outputs match the Design Inputs. Validation, on the other hand, demonstrates your product meets your user requirements.

I used to confuse Verification with Validation but a simple way to remember the difference is:

Verification deals with Design Inputs/Outputs and Validation demonstrates that User Needs have been met. I remember the acronyms VERDIO and VALIDUN. VERification Design Inputs/Outputs…VALIDation User Needs. Got it? Good!

We’re almost at the end of Pre-Market Design Controls...

Lastly comes Design Transfer: if you complete this stage, you’ve signified that you’re ready to leave the development stage and enter a manufacturing production environment. After finishing Design Transfer, your Design History File (DHF) is the proof that you’ve fulfilled your Design Controls.

And that concludes my review and summary of medical device Design Controls.

Source: https://www.greenlight.guru/blog/design-controls

**The postings on this site are my own and may not represent the opinions or positions of the company I work at.**