Editor's note: This is the first installment in David Amor's Med-Dev from Scratch: Compliant Innovation column dedicated to helping entrepreneurs build their medical device companies in a compliant and streamlined way.

If the medical device industry consisted of a ”who has the coolest and groundbreaking idea” contest, I would be a multi-billionaire based on the countless crumpled up napkins that litter my office. Part of falling far short of this financial goal is the realization that in a highly regulated industry, how a product is developed (and how that development is documented!), is just as important as the product idea itself. After all, part of FDA’s job is to ensure prospective patients remain safe during use of a medical device.

Although this concept is clear to me and other compliance consultants and professionals, some companies still struggle with the concept of design controls, establishing and maintaining a formal and objective methodology to develop a safe and effective medical device. The waterfall model for design controls—an “old faithful” depiction crammed into every possible Powerpoint presentation on the topic—is a simple tool used for decades that demonstrates how design inputs translate into design outputs (Figure 1).

This model has been misinterpreted in so many ways that the number of design control citations in warning letters has surged to new highs over the past several years. In 2013 alone, design-control-related warning letter violations account for 13 instances in 10 warning letters issued so far. An obvious question emerges: Why is it that design violations occur so frequently in an era when technology advances have allowed companies to produce safer and more effective products?

FDA defines design inputs as “the physical and performance requirements of a device that are used as a basis for device design [820.3(f)].” Your design inputs can be anything from packaging considerations to electrical continuity requirements within your active implantable device. The most important point for design inputs is that they must be unambiguous, verifiable and traceable to an input source. For example, in a 2012 FDA warning letter, a company was found to have design inputs that “…did not meet specification, were not adequately tested, or did not show quantifiable results.” How can other companies avoid this predicament?

Remove Unclear Terminology from Design Inputs. Ambiguity in describing design inputs leads to downstream issues. For example, suppose I have an intravenous delivery kit and I propose a design input that indicates: “The set shall be capable of delivering fluid.” Theoretically, I could fill this set with paint thinner and as long as it’s capable of administering the paint thinner at a predetermined flow rate and volume, it meet the requirement. However, the missing link is that this input is not consistent with the intended use of the device. All design inputs need to be explicit and support the clinical need for the device.

Establish Acceptance Criteria. While drafting design inputs, ensure you establish clear acceptance criteria for any requirements you list. For example, instead of saying, “The catheter must not break when excess movement occurs,” place a verifiable objective in its stead, such as “The catheter must not break or separate after axial force application of < 5 N.” The question that usually arises is “Where did that value come from?” The answer: it depends. Many design input sources exist, including competitive benchmarking, voice of customer surveys and bench-top testing, and historical evidence. However, the key understanding is that it is just as important to ensure that your design inputs can be traced to a certain source and that this tracing is documented! Here’s a tip: establish a market or user requirements document that lists the high-level user needs and stakeholder needs. These can then be tied to additional technical specifications, which take the requirements in the user document and translate them into engineering terms. Per FDA, “a set of design input requirements, when converted to engineering terminology, finalized and accepted as part of the device master record is called a device or product specification.” Let’s take a look at a generic – but useful – example (Figure 2).

Create a Trace Matrix. A trace matrix is a controlled document that lists all verification activities and ties them directly back to design inputs. This is a great audit-ready document that demonstrates complete oversight over your product development program. It is a tool that says, “Hey, we had certain requirements from the user; we turned those into product and technical specifications and created a product that we tested thoroughly to confirm that we met our input.” Trace matrices are excellent tools that also allow you to notice deficiencies in your program immediately if a trace is missing or non-existent.

Don’t Jump into Testing. Design verification is a crucial step in your product development program. It is the confirmation that your product is performing as intended. Consider everything that comes before design verification first. This is a good time to take a step back and ask yourself the following questions:

The considerations above are only some of the key insights to review while developing a product. You should also take a look at relevant standards, regulations, and other design inputs that are particular to your device. Always remember that product development is more than invention and that the three D’s should always be used: design, develop, and document.

David Amor is a medical device consultant who has worked with companies such as Boston Scientific, St. Jude Medical, and Hospira to develop quality management systems and product development infrastructures. A graduate of the Senior Innovation Fellows program at the University of Minnesota Medical Device Center, Amor was one of MD+DI's "40 Under 40" medical device innovators in 2012. He founded MEDgineering, a niche quality consulting firm focusing on FDA remediation, quality staffing and consulting, and med-tech investment due diligence. He holds a BS and MS in biomedical engineering from the University of Miami with a focus on innovating around clinical needs. Amor currently serves as chief operating officer of ReMind Technologies, a mobile health start-up dedicated to tackling medication adherence by using smart-device based medication dispensing units and software applications.