Five Tips for Medical Device Engineers on FDA Design Controls

If you’re in the medical device industry, you may think that design controls are a confusing imposition on your processes. But they’re a necessary part of your requirements as a medical device developer, and I’ve noticed that this area tends to be rife with misconceptions, confusion, and generally making things into a bigger deal than they really need to be.

[ad:29851]

That being said, there are some areas that I’d like to address to help medical device engineers navigate their way more easily through design controls requirements. Let’s take a look:

1. Don’t believe the misconceptions

Probably the biggest misconception about design controls is that they equal a heavy load of burdensome documentation. People who believe this also often believe statements like: “Following good design controls will only slow down our product development” and, “Design controls will stifle innovation in our business.”

The thing is, if you believe these statements to be true, then your own design controls processes and practices are out of date and need to be overhauled. There is no need for design controls to be overly burdensome to medical device developers because there are simple ways of keeping yourself compliant.

Design controls are essentially about demonstrating that your product is safe, effective, and meets its intended use. You could sum all of this up in an “intended use statement” and then use that statement as your pillar. You then have the basis to formulate your user needs, which feed directly into your design outputs. Coming full circle, you then have design validation that ensures that your product meets user needs.

In this way, design controls in fact aid product development and innovation. Your goal has to be to create a product that meets that specific “intended use statement” and is proven to be safe and effective. Design controls are the evidence to support your claims that this is so.

A robust design control practice aligns with regulations and allows you to be flexible and innovative. These controls shouldn’t be treated as an afterthought, but rather should align naturally throughout the design process.

2. Keep your plan fluid

Companies often make the huge mistake of treating design controls as a chore to get out of the way. With regard to a design plan, this is often done at the beginning of a project then locked away. This fails to acknowledge that plans change; in fact, most companies will find themselves making a number of pivots.

Think about how a project is broken into phases. Without specifying preference for any particular methodology, there is a beginning, middle, and end. In the beginning, you’re in your discovery phase. You have ideas, perhaps crude prototypes, and an idea for intended use. You don’t know what you don’t know, and as such, those things you discover become fuel for your design criteria.

Even keeping intended use as the pillar for your design ideas, you may go through various pivots throughout the middle phase(s) of product development. This is why your design and development plan should be dynamic, developed, and updated throughout each phase of the project. It is a living document, open to change.

It’s also worth clearing up another misconception: There’s often confusion about what a design and development plan actually is. The plan identifies the process that you will go through, resources required, and design to be used. It is not just a project schedule. I often see companies presenting a “plan” that is in fact just a schedule, often in the format of a Gantt chart. This might be helpful in terms of keeping product development on track, but it is not the intent of a design plan. The design plan should describe what is actually happening rather than appear as a schedule.

3. Recognize user needs vs. design inputs

Another concept to be aware of is the difference and relationship between user needs and design inputs. There is a great concept of the “user story,” which describes the things that the user will do with respect to the product, whether the user is a medical professional, patient, or someone who assists the patient. Think about what users will do, how they will interact with the product, and answer the question, “What is important for them?” All that information is what you need to capture as user needs.

A common practice is to define these stories in vague ways, using terms like “better” and “easier to use.” Start with somewhat vague statements as user needs is actually a good way to begin. User stories become the foundation for establishing design inputs. To state this another way, design inputs make the user stories more specific and measurable.

The inputs are quite simply the requirements for your device design. They must be objective and stated in a way that can be demonstrated through testing or analysis. You can see where terms such as “better” simply do not cut it when it comes to design inputs.

I wrote more about defining user needs, including eight questions you should ask, here.

4. Recognize design inputs vs. design outputs vs. design verification

People get confused as to what design outputs are. They want to capture, through testing, items that prove inputs have been met and show these as design outputs. This is a complete mix-up of terminology.

Let’s break it down:

Design inputs. These define all the performance criteria, requirements, and features of your medical device product. As mentioned earlier, they should stem directly from user needs. Good design inputs provide the foundation for a strong and successful medical device.

Design outputs. I like to think of design outputs as a “recipe” for your medical device. Design outputs consist of all the parts, components, inspection procedures, and other materials or procedures that go into creating your medical device. They are the documents you would give to someone who has the job of assembling your device.

Design verification. The goal of design verification is to prove design outputs meet design inputs. It includes all of the testing, analysis, and inspections that serve as your proof to demonstrate that your medical device has been designed correctly.

As you can see from these definitions, people often make the mistake of mixing up design outputs and verification. It might seem like semantics, but it’s important in terms of having your paperwork completed correctly.

5. Start design controls early

Another relatively common assumption of medical device developers is thinking that they can afford to delay design controls until after a working prototype is established.

The idea is often: “Let’s stay in the research phase for as long as possible. When we’re sure we have a working prototype, we’ll document design controls.”

This is a mistake for a couple of reasons. First, it’s not so easy to play “catch up” on design controls because there are often so many moving parts that something is bound to be forgotten. Second, you miss the entire point of keeping the design controls.

Through each iteration you are learning something, and your design controls become an important record of learning. You might not nail your prototype the first or even the fourth time around, but you surely learned something with each version. Capture this in documentation so you have a good record of it.

Final thoughts

Design controls do not have to be the big, imposing task that they are often made out to be. In fact, setting them up the right way can encourage innovation and speedy product development rather than slowing it down.

Establish your design controls early, preferably with a centralized electronic system that allows access to all who need to be involved. Staying on top of design controls right from prototyping will not only help to keep you compliant, but will also help to enhance your learning experience over the course of development.

First published March 6, 2016, on greenlightguru.com.

About The Author