The Ultimate Guide To Design Controls For Medical Device Startups

http://www.medicaldevicesummit.com/Main/Blogs/57.aspx">http://www.medicaldevicesummit.com/Main/Blogs/57.aspx</a>; Contact Detail webinars@globalcompliancepanel.com http://www.globalcompliancepanel.com; Phone: 800-447-9407 Fax: 302-288-6884 1000 N West Street | Suite 1200 | Wilmington | DE | USA | 19801 " data-medium-file="" data-large-file="" class="wp-float-right wp-image-156 size-full" src="https://blog.greenlight.guru/hs-fs/hub/495719/file-2827114026-jpg/blog-files/design-control-tile-0-1.jpg?t=1501006593298&width=210&height=210&name=design-control-tile-0-1.jpg" alt="design-control-tile-0 (1)" width="210" height="210" align="right" />

What’s this guide about anyway?

Back in 1998, I started my career as a medical device product development engineer.

At that time the FDA Design Controls regulations were still fairly new — not only to me — but the industry in general.

In those days, we all struggled to understand how and what to do with respect to Design Controls.

As my career progressed, I started to understand the purpose and intent regarding Design Controls. But it didn’t happen overnight.

Over the past 17 years, I’ve been fortunate to have played a part in getting 40+ medical devices through FDA clearance as a product development engineer, through my consultancy, and more recently as co-founder of greenlight.guru.

However, for many, Design Control is still a topic that is as confusing today as it was for me many years ago.

With this guide, I plan to share valuable insights to explain what Design Controls are, how to address them, and how they benefit your medical device product development efforts.

You have an idea for a new medical device. Now what?

Congratulations! You have an idea for a new medical device.

Chances are you believe your idea will have a significant impact on the quality of our lives in some way. Chances are your product will help solve some current problem and address unmet needs.

What do you do now?

Throughout the world, there are agencies that govern and regulate medical devices. For example, in the United States, medical devices are regulated by the Food & Drug Administration (FDA).

These regulatory agencies have defined rules and regulations that you and others developing and manufacturing medical devices must follow.

And these regulatory agencies have defined rules and regulations about how medical devices are classified and what is required before the products are sold into the marketplace.

Most notably, since you have an idea that you want to develop further, there are regulations established for you to follow during the product development process. These regulations are known as Design Controls.

This may sound confusing and discouraging. I get that.

And I don’t want you to be confused or discouraged.

This is what drove me to create this “Ultimate Guide to Design Controls for Medical Device Startups.”

In this guide, I will share with you the necessary background about Design Controls from a global regulatory perspective.

I will provide you with knowledge and information that will arm you with more than just the basics.

http://www.globalcompliancepanel.com; Phone: 800-447-9407 Fax: 302-288-6884 1000 N West Street | Suite 1200 | Wilmington | DE | USA | 19801 " data-medium-file="" data-large-file="" class="wp-float-right wp-image-135 size-full" src="https://blog.greenlight.guru/hs-fs/hub/495719/file-2827114041-jpg/blog-files/design-control-tile-1.jpg?t=1501006593298&width=210&height=210&name=design-control-tile-1.jpg" alt="design-control-tile-1" width="210" height="210" align="right" />

Some explanation about a Quality System

Yes, I know — this guide is supposed to focus on Design Controls. And it does.

I just need to spend a few minutes explaining what a quality system is and how this relates to your medical device product development efforts.

What is a Quality System?

A medical device company has to establish a quality system.

A quality system is a set of processes and procedures you define and implement to describe how your company addresses medical device regulations, including Design Controls.

FDA defines the rules in 21 CFR Part 820. And if you plan to go to market in the U.S., these regulations are required.

Outside the U.S., Europe requires a quality system be established to meet the medical device directives. Many medical device companies choose to implement a quality system and have it certified to ISO 13485 to satisfy EU needs.

Canada — same thing. The expectation is that a quality system be established. Canada is a little different, requiring you to establish ISO 13485 certification and the Canadian Medical Devices Conformity Assessment System (CMDCAS).

The good news is this… FDA 21 CFR Part 820 and ISO 13485 are very similar. Meaning you can establish a “one size fits all” quality system, encompassing Design Controls too.

Build your Quality System as you go

The quality system expectations is that you have all parts and pieces defined and implemented by the time you go to market.

Yes, there are parts of the FDA regulations and ISO requirements that do apply to you, even if you are pre-market.

If you are going through medical device product development, there are at least 4 parts of a quality system that you need to put in place:

Design Controls
Risk Management
Document Control & Records Management
Supplier Management

The term I use is “bootstrapping a QMS”. I encourage this approach. Early on, you don’t need to spend too much time implementing a robust quality system. You need to be focused on product development.

And as you get closer and closer to going to market, there are software tools, like greenlight.guru and others, you can use to gradually implement more and more of a QMS.

Just make sure you always keep your quality system in mind from the beginning, so you don’t have to learn how to free yourself from a quality system nightmare down the road.

design-control-tile-2

What are Design Controls?

So far in this ultimate guide, I have spent very little time discussing Design Controls. Yes, this is deliberate.

The stuff I covered so far about understanding medical device product classification and quality systems is very important for you to have some grasp on as you pursue your new medical device idea.

If that information did not discourage you and you are still reading, rest assured.

The rest of this guide is devoted to Design Controls. Really more than just Design Controls.

I will share with you why Design Controls even matter and how they will help you during your medical device product development.

Design Controls – Comparing FDA and ISO

It is important that you design and develop a medical device that is safe. FDA, European Commission, Health Canada, and all other regulatory bodies throughout the world will want some assurances that your medical device is safe before you bring the product to market.

And this is really the essence of Design Controls. Proof that you have designed a safe product that meets user needs and requirements.

Technically speaking “Design Controls” is a FDA term and defined in FDA 21 CFR 820.30 (the 21 CFR stuff is FDA terminology to describe where in the code of federal regulations the topic is addressed).

In ISO 13485 speak, the terminology and intent is similar and covered in section 7.3 Design and Development.

The table below compares the FDA clauses for Design Controls to ISO 13485 clauses regarding Design & Development.

http://www.aviva.co.uk/risksolutions/consultancy/health-and-safety/bs-ohsas-18001-gap-analysis.html">http://www.aviva.co.uk/risksolutions/consultancy/health-and-safety/bs-ohsas-18001-gap-analysis.html</a>; <a href="http://rynmag.co.za/index.php/understanding-ohsas-18001-gap-analysi...; Contact Detail webinars@globalcompliancepanel.com http://www.globalcompliancepanel.com; Phone: 800-447-9407 Fax: 302-288-6884 1000 N West Street | Suite 1200 | Wilmington | DE | USA | 19801 " data-medium-file="" data-large-file="" class="wp-float-center wp-image-181 size-full" src="https://blog.greenlight.guru/hs-fs/hub/495719/file-2827114341-jpg/blog-files/fda-820.30-vs.-iso-13485.jpg?t=1501006593298&width=626&name=fda-820.30-vs.-iso-13485.jpg" alt="FDA 820.30 vs. ISO 13485 - greenlight.guru" width="626" />

Both FDA Design Controls regulations and ISO 13485 Design & Development requirements expect you to keep documentation and records throughout the product development process.

The Design History File (DHF) is a great place to keep all of your Design Controls “evidence”.

As you can see, there is consistency regarding Design Controls. Although ISO 13485 does not explicitly call for a DHF, it is expected that you maintain records of design and development.

An industry best-practice is to construct a traceability matrix to show the linkages and relationship between User Needs, Design Inputs, Design Outputs, Design Verification, and Design Validation.

Building and maintaining your traceability matrix using tools like Excel or Google Docs a is fairly straightforward task during the early months of product development.

But as your project progresses, you’ll soon find using these general purpose tools often take days, and in some cases weeks, to keep your traceability matrix properly updated and maintained.

This marks a time in your project where switching to a software solution built specifically to meet the unique regulatory needs of a medical device company, like greenlight.guru, can result in significant gains in time to market while reducing risk.

Product Development versus Design Controls

I’d like to spend a few minutes discussing product development versus Design Controls. Is there a difference? Or are these terms synonymous?

The short answers to these questions depends on who you ask.

And I’m telling you the answers really don’t matter all that much.

When you have an idea for a medical device that you want to turn into an actual product, you will follow some sort of product development process. And I highly encourage you to map your product development process and WRITE IT DOWN.

As an example, I like to define the product development process in major phases:

http://www.isranalytica.org.il/Isranalytica2012/2012%20CMoore%20Isranalytica%20Analytical%20QBD%20%28Tel%20Aviv%29.pdf">http://www.isranalytica.org.il/Isranalytica2012/2012%20CMoore%20Isranalytica%20Analytical%20QBD%20%28Tel%20Aviv%29.pdf</a>; " data-medium-file="" data-large-file="" class="wp-float-center wp-image-184 size-full" src="https://blog.greenlight.guru/hs-fs/hub/495719/file-2827114361-jpg/blog-files/product-development-process-phase.jpg?t=1501006593298&width=753&name=product-development-process-phase.jpg" alt="medical device product development process - greenlight.guru" width="753" />

During product development, you will construct some prototypes, do some testing, get some feedback, etc. Always trying to get to the next step towards launching your medical device.

As noted above, Design Controls are all about ensuring the medical device you are developing is safe.

All about making sure you have proven your medical device meets the requirements you define.

All about making sure you have proven your medical device meets the user needs and product’s intended use.

All about making sure you will be able to manufacture your medical device that you designed and developed.

But since I posed the question about product development versus Design Controls, I’ll give you my opinion.

http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=820.184">http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=820.184</a>; <a href="http://www.mddionline.com/article/clarifying-device-history-record-...; Contact Detail webinars@globalcompliancepanel.com http://www.globalcompliancepanel.com; Phone: 800-447-9407 Fax: 302-288-6884 1000 N West Street | Suite 1200 | Wilmington | DE | USA | 19801 " data-medium-file="" data-large-file="" class="wp-float-center wp-image-186 size-full" src="https://blog.greenlight.guru/hs-fs/hub/495719/file-2827114381-jpg/blog-files/product_development_vs_design_controls.jpg?t=1501006593298&width=575&name=product_development_vs_design_controls.jpg" alt="product development vs design controls - greenlight.guru" width="575" />

It’s my opinion that Design Controls fits within the broader medical device product development process.

Product development includes much, much more than just Design Controls. Things like budget, timeline, business development, marketing, sales, and so on.

http://www.foodsafetymagazine.com/article.asp?id=291&sub=sub1">http://www.foodsafetymagazine.com/article.asp?id=291&sub=sub1</a>; Contact Detail webinars@globalcompliancepanel.com http://www.globalcompliancepanel.com; Phone: 800-447-9407 Fax: 302-288-6884 1000 N West Street | Suite 1200 | Wilmington | DE | USA | 19801 " data-medium-file="" data-large-file="" class="wp-float-right wp-image-239 size-full" src="https://blog.greenlight.guru/hs-fs/hub/495719/file-2827114076-jpg/blog-files/design-control-tile-31.jpg?t=1501006593298&width=210&height=210&name=design-control-tile-31.jpg" alt="design-control-tile-3" width="210" height="210" align="right" />

Maintaining a Design History File

What is a Design History File (DHF)? When you read FDA Design Controls regulations, the part about DHF is mentioned towards the end. And ISO 13485 doesn’t officially talk about a DHF.

I want to cover DHF now so that you understand what it is and why it matters.

A Design History File is, simply put, the place where you keep all your Design Controls.

A DHF should be organized and accessible to the entire project team.

A DHF is the place where you will show the linkages and relationships between all the Design Controls.

Demonstrating traceability of all your Design Controls throughout the product development process is expected and required.

Whether you use a paper-based approach, general purpose tools, or a software solution designed specifically with Design Controls traceability in mind like I mentioned before, know that the responsibility to prove this is yours.

Keep the DHF separate from project file

My comments about product development versus Design Controls may seem somewhat trivial.

Except that it isn’t.

And the DHF is my main reason for saying so.

Yes, Design Controls and the DHF where these documents and records are maintained are important.

The DHF is the central hub for all the things medical device regulators care about.

Which is why it is so important to keep your Design History File as a stand-alone thing.

Going through medical device product development, you seldom consider how to maintain documentation and why it even matters.

And after you launch your medical device, the DHF is important in the event the project is ever audited by the FDAor others.

The last thing you want to do when finishing up a project is to spend weeks going back organizing documentation and records, including the Design History File.

I’m telling you that if you do not keep things shipshape as you go, you will not go back to clean it up.

This is why I recommend building your Design Controls traceability matrix early and keeping it up to date as you go. With this approach, you won’t stress about the possibility of being audited because your DHF will always be up to date and audit ready.

https://globalcompliancepaneltraining.files.wordpress.com/2012/09/globalcompliancepanel_logo.jpg"><img class="size-full wp-image" src="https://globalcompliancepaneltraining.files.wordpress.com/2012/09/g...; alt="Image" /></a> API Process Inspection –what does the FDA expect? Ironical as it may sound; there is no API-specific GMP guideline from the FDA! It has only some broad, yet clearly laid out rules and expectations, which have to be adhered to. The FDA and API Process Inspection Rules regarding what the FDA expects are mentioned clearly in the document that lays down the principles of an FDA API process inspection, namely FDA Program Guidance Manual (Program 7356.002F). So, the FDA sticks to what is prescribed in this document: – GMP is a must for the FDA – It recognizes Q 7 as the primary API GMP. If you cannot follow Q 7, you can expect an equivalent activity, but are expected to demonstrate that the alternative activity you used did not in any way violate the basic requirements set out in this document. – This program manual is applicable for API manufactured by synthesis/fermentation and not for dosage forms – This document applies to domestic and foreign inspections – Uses a six-system approach Other requirements – Expects compliance with FDA regulations – Compliance with Q 7 or equivalent – Procedures and documents must be clearly written down – Should have appropriate Quality System in conformance with Q 7, to ensure that an international or domestic guidance is adhered to – Should have sound Quality Practices – A sound and documented QMS that is “shown to work” – Appropriate Change Control Systems – Cleaning systems and records – Appropriate Validation and Qualification performed and documented – Written contracts and Quality Agreements where appropriate – Auditing programs and documentation Systems that will be examined During an FDA API process inspection, it inspects the following types of systems: – Quality System – Facilities and Equipment – Materials System – Production – Packing and labeling – Laboratory Control System Reference: <a href="http://www.fda.gov/downloads/ICECI/ComplianceManuals/ComplianceProg...; " data-medium-file="" data-large-file="" class="wp-image-193 size-full" src="https://blog.greenlight.guru/hs-fs/hub/495719/file-2827114401-jpg/blog-files/traceability-matrix-greenlight.guru-copy.jpg?t=1501006593298&width=644&name=traceability-matrix-greenlight.guru-copy.jpg" alt="Design Controls Traceability Matrix - greenlight.guru" width="644" />

A Traceability Matrix Using greenlight.guru (Click here to get a free demo)

Ensure the DHF is organized and accessible

Ensuring Design Controls documentation and records are stored in a DHF is very important.

Keeping the DHF in a place where your entire product development project team can access it is also important. Why? Throughout product development, your team will be contributing valuable content to include in the DHF, and accessing this same content to conduct product development.

Be sure you are deliberate in how you plan to keep the DHF organized and accessible.

Do you plan to use a paper-based approach? If so, be sure you are aware of the challenges paper systems pose.

Do you plan to store electronic records on a company server or some type of electronic document management system? There are also challenges with this approach as well.

Do your homework. Choose your solution wisely.

http://www.asqlongisland.org/seminars/2010_11_05_CAPA_TimMohnWritingCAPAs.pdf">http://www.asqlongisland.org/seminars/2010_11_05_CAPA_TimMohnWritingCAPAs.pdf</a>; <a href="http://medxu.com/medcon/files/2011/04/a.-Jimenez-Ongoing-Challenges...; " data-medium-file="" data-large-file="" class="wp-float-right wp-image-138 size-full" src="https://blog.greenlight.guru/hs-fs/hub/495719/file-2827114091-jpg/blog-files/design-control-tile-4.jpg?t=1501006593298&width=210&height=210&name=design-control-tile-4.jpg" alt="design-control-tile-4" width="210" height="210" align="right" />

Why capturing User Needs sets the stage

Remember when you had the idea for your new medical device, you came up with this wonderful product because you want to address unmet clinical needs. There are two terms that you should understand: intended use and indications for use.

Intended Use is the general purpose of the medical device or its function (what you “claim” the medical device does)

Indications for Use describe the disease or condition the medical device will diagnose, treat, prevent, cure, or mitigate, including a description of the target patient population

All of this relates to the User Needs for your medical device and are part of Design Controls.

Now you can do a lot of digging to try to get a better understanding of what User Needs really are. FDA doesn’t really define User Needs in the 820.30 regulations per se. User Needs are shown kicking off the Design Controls process in the classic “waterfall diagram.”

http://www.globalcompliancepanel.com; Phone: 800-447-9407 Fax: 302-288-6884 1000 N West Street | Suite 1200 | Wilmington | DE | USA | 19801 " data-medium-file="" data-large-file="" class="wp-image-196 size-large" src="https://blog.greenlight.guru/hs-fs/hub/495719/file-2827114421-jpeg/blog-files/design_control_waterfall_greenlight_guru-1024x750.jpeg?t=1501006593298&width=674&name=design_control_waterfall_greenlight_guru-1024x750.jpeg" alt="design controls waterfall diagram - greenlight.guru" width="674" />

Classic Design Controls waterfall diagram originally published by Health Canada & published in FDA Design Controls Guidance

The best place, aside from this guide, for you to get some insights about what User Needs are is the FDA Design Controls Guidance.

And when you read the FDA guidance, just about every reference involving User Needs is tied directly to Design Validation. Validation proves your medical device meets User Needs and intended uses.

Documenting User Needs

Okay, so let me get into documenting User Needs. When documenting User Needs, think about your medical device product idea.

User needs describe how your medical device is going to be used. User needs help establish the framework for your medical device product design. Intended use describes the clinical issue your product addresses. Indications for Use pertain to clinical applications use, environment, and end user.

Here are some questions to help you better understand User Needs.

What do you want it to do?
Who is going to use it?
When will it be used?
What important features and attributes should be considered?
How will the user and patient interact with the device?
What type of procedures will the device be used?
What type of environment will the device be used?
When will the device be used?
Is the device used one time or over and over?
What other products will the device interact and interface with?

There likely are dozens and dozens more questions you need to ask.

And answer! Document your responses to all the questions.

Your responses become the information you should consider as the User Needs for your medical device idea, and included as part of your Design Controls.

Looking again at the waterfall diagram, you see that the proposed next major step after User Needs is Design Inputs. Logically, User Needs are the lead into Design Inputs.

And many medical device product development professionals will share with you how important Design Inputs are to the success of a new device.

Do not be too worried about whether or not your User Needs are exactly correct. Do not get too hung up on the format and wording.

Do realize that one day in the future, you will need to demonstrate that the product you develop addresses the User Needs you define.

The traceability matrix described earlier in this guide starts with the User Needs. User Needs feed into Design Inputs. Design Validation proves User Needs are met.

http://www.globalcompliancepanel.com; Phone: 800-447-9407 Fax: 302-288-6884 1000 N West Street | Suite 1200 | Wilmington | DE | USA | 19801 " data-medium-file="" data-large-file="" class="wp-float-right wp-image-139 size-full" src="https://blog.greenlight.guru/hs-fs/hub/495719/file-2827114116-jpg/blog-files/design-control-tile-5.jpg?t=1501006593298&width=210&height=210&name=design-control-tile-5.jpg" alt="design-control-tile-5" width="210" height="210" align="right" />

The purpose behind Design & Development Planning

In my experience, the topic of Design & Development Planning is very misunderstood. When most medical device product developers think about Design & Development Planning, the first thing that comes to mind is this:

Project schedule.

Since there is confusion about this, let me share what FDA and ISO state about Design & Development Planning.

FDA 21 CFR 820.30(b) Design & Development Planning: Each manufacturer shall establish and maintain plans that describe or reference the design and development activities and define responsibility for implementation. The plans shall identify and describe the interfaces with different groups or activities that provide, or result in, input to the design and development process. The plans shall be reviewed, updated, and approved as design and development evolves.

ISO 13485:2003 7.3.1 Design and development planning: The organization shall establish documented procedures for design and development.

The organization shall plan and control the design and development of product.

During the design and development planning, the organization shall determine

a) the design and development stages,

b) the review, verification, validation, and design transfer activities (see NOTE) that are appropriate at each design and development stage, and

c) the responsibilities and authorities for design and development.

The organization shall manage the interfaces between different groups involved in design and development to ensure effective communication and clear assignment of responsibility.

Planning output shall be documented, and updated as appropriate, as the design and development progresses.

NOTE – Design transfer activities during the the design and development process ensure that design and development outputs are verified as suitable for manufacturing before becoming final production specifications.

Did you come across anything that suggests project schedule? Or timeline?

Your product development schedule is definitely important. Don’t mishear me.

Remember where I shared some thoughts about product development versus Design Controls earlier in this guide?

Project schedule versus Design & Development Planning is in the same vein. Project schedule is a product development thing. Yet there is also a definite relationship with Design & Development Planning.

What goes into a Design & Development Plan?

Let me pick out the important aspects about Design & Development Planning from what FDA and ISO state about the topic:

Identify Design & Development stages and activities
Define responsibility for Design & Development activities
Define the resources required; this includes project team members, as well as vendors
Plans should evolve throughout Design & Development

A Design & Development Plan describes all the Design Controls, including when Design Reviews are expected. The plan describes who the team members are, including roles and responsibilities. The plan is not a “one and done” and needs to be revisited and updated throughout the project.

http://www.globalcompliancepanel.com; Phone: 800-447-9407 Fax: 302-288-6884 1000 N West Street | Suite 1200 | Wilmington | DE | USA | 19801 " data-medium-file="" data-large-file="" class="wp-float-right wp-image-140 size-full" src="https://blog.greenlight.guru/hs-fs/hub/495719/file-2827114136-jpg/blog-files/design-control-tile-6.jpg?t=1501006593298&width=210&height=210&name=design-control-tile-6.jpg" alt="design-control-tile-6" width="210" height="210" align="right" />

Understanding the role and importance of Design Reviews

Design Reviews are moments in time for you to evaluate the progress of your medical device project as it progresses through development.

During Design Reviews, you and the project team are formally reviewing — and agreeing to — Design Controls.

Design Reviews are also a time in a project to bring the team together in order to scrutinize and evaluate the state of the medical device and ensure that what needs to be done has been addressed.

How many? Who is involved?

How many Design Reviews does your medical device product development project need? This is a good question to ask. I do not have the answer for your project.

Here’s what I can tell you about Design Reviews.

How many Design Reviews to have depends on numerous factors. Factors like what the product is and who the players are need to be considered when determining timing of Design Reviews.

The expectation is that your Design Review include the right functions (engineering, marketing, manufacturing, etc.). Also, you need to include a resource who is independent.

When should Design Reviews happen?

All Design Controls must be included as part of a Design Review. As noted, I cannot for certain tell you exactly when to have Design Reviews. If you press me to provide a definitive response on this question, I will defer to the what is suggested by the Design Controls waterfall diagram.

I will advise you to have a Design Review when User Needs are drafted.

I will advise you to have a Design Review after Design Inputs are established.

And after Design Outputs. After Design Verification. After Design Validation…and before going to full production.

1 member likes this