Design Control: learn from my mistakes

/in , /by
Innovation, efficiency, and safety can coexist when a team uses effective design controls. In this article, I apply modern design controls to a product I co-invented and commercialized in 2004 using lessons learned in 15 years.
I describe that product in another article. This article helps you learn from my mistakes.

My Mistakes

In 2004 I managed both engineering and marketing for a small medical device company. We developed products faster than competitors, rapidly grew sales, achieved twice the profit margin as competitive products, and were acquired by a large company for $42 Million.
Our board members profited, employees moved on to higher levels of responsibility in new companies, and I became president of a company formed around technologies I invented and co-invented.

Years later, I would learn that our first medical device eventually caused unnecessary pain and suffering for many patients and added unnecessary expenses to America’s healthcare costs. In this article, I re-analyze our product using modern design controls, risk management, and the European Union Medical Device Regulation; and I share lessons learned in leadership and entrepreneurship.

Design controls must begin with a plan, so I applied a modern plan to our 2004 product. Like all examples, this is only for discussion of main points, not intended to replace understanding fundamentals. It has many simplifications. Search my blog for other examples, such as an overview of design controls.

Design Plan


This is a simplified example. For the sake of time and ease of understanding, I focus on concepts rather than details.

Scope
This design plan is for the Viper distal radius plating system, a medical device to treat distal radius fractures of the wrist. The product has been available commercially, but with limited documentation. This plan collects existing data and applies design controls for work going forward.

References

  • Product history
  • Risk Management Plan
  • Design Controls overview
  • Verification & Validation Trace Matrix document, VerVal-TraceMatrix.doc
  • Design and Manufacturing Master Validation Plan, DM-MasterVVplan.doc
  • Manufacturing processes, ManufacturingProcess.doc
  • Manufacturing process validation plan, ManufacturingProcessValidationPlan.doc
  • List your quality system policies, standards used or referenced, etc.

Indications for Use

The Viper is intended to treat distal radius fractures of the wrist or patients between 16 and 70 years old, between 120 lbs and 250 lbs, with strong bone quality and no evidence of osteoporosis or other bone-weakening diseases. The surgeon should be provided Viper instructions for use prior to surgery.

Product Description

The Viper distal radius system is a plate with two sizes of screws, 5.6mm diameter screws for the longbone and 2.5mm diameter screws for the distal end of the bone. The implant system comes with an instrument tray, screw drivers, screw drill guides, and a locking key to lock the 2.5mm screws to the plate.
For the sake of space and time, this example will focus on the plate, 2.5 mm screws, and screwdriver.

Design Input

Design inputs are listed in DesignInput-Document.doc.
For this example, I’ll list design inputs in this section of the plan. But design inputs are usually given in a separate document. Link that input document to this plan, and link this plan to that input document, creating a closed-loop process of continuous improvement.

Design Inputs should include at least two things:

    1. User Needs, including risk management
    2. Regulatory Requirements, including company policies for design and risk

Your company may include business needs, but should focus on the two main inputs.

User Needs:

  • UN#1: Allows faster healing than casts
  • UN#2: Has fewer complications than casts
  • UN#3: As safe or safer than alternative treatments


User Needs are usually high-level, the same as a person considering that they’d like to purchase an automobile that’s fuel-efficient and inexpensive. User needs are refined to requirements that can be used to design a product to meet their needs, and must include features intended to minimize risk that a user may not be aware of.

Requirements:

  • Plate-RQ#1: the plate shall be less than 1.5mm in thickness
  • Plate-RQ#2: all corners of the plate shall be rounded to no sharper than 0.25mm radius
  • Screw-RQ#1: shall be variable to +/- 20 degrees with respect to the plate holes
  • Screw-RQ#2: each screw shall be able to lock into the plate
  • ScrewDriver-Risk-RQ#1: The screw driver shall be designed to minimize probability of stripping screws

Risk is sometimes grouped as a separate category, ensuring future teams know which design features addressed risk. Those risk requirements could either be further be refined as unambiguous input requirements, or the generalized requirements could be validated through validation testing and post-market surveillance of assumptions. Generally, requirements should be clear, easy to understand, and unambiguous, i.e. use numbers with values that could be measured in verification testing.

Design Output

  • Plate drawing .dwg
  • Screw drawing .dwg
  • Screw driver drawing .dwg
  • Instructions for Use .doc
  • Verification Test Protocols .doc
  • Validation Test Protocols .doc

You’d add all design outputs, which are all drawings, test methods, instructions, etc. that would be required to satisfy design input requirements.

Verification & Validation

  • Verification & Validation Trace Matrix document, VerVal-TraceMatrix.doc
  • Design and Manufacturing Master Validation Plan, DM-MasterVVplan.doc

Note to readers:

All design inputs shall be either verified or validated, and many people are confused on the difference between verification and validation.

Verification confirms meeting design inputs by measuring numbers, values, and features that won’t change over time, such as rounded edges called out on a drawing, or the length of screws.

Validation requires testing a representative sample of your product and applying statistics to predict that your results will apply to all designs. In this example, the design input “ScrewDriver-Risk-RQ#1: The screw driver shall be designed to minimize probability of stripping screws” can not be verified, therefore it must be validated with a user test or post-market surveillance of how the screw driver functions in use.

You may prove that all design inputs were either verified or validated by using a master V&V plan, a trace matrix, or this your plan. Just make it easy to follow your logic, ensuring nothing slips through without verification or validation, and that there’s an opportunity to update this plan and all tests based on new information.

Design Transfer

  • Verification & Validation Trace Matrix document, VerVal-TraceMatrix.doc
  • Design and Manufacturing Master Validation Plan, DM-MasterVVplan.doc
  • Manufacturing processes, ManufacturingProcess.doc
  • Manufacturing process validation plan, ManufacturingProcessValidationPlan.doc

Device Master Record

  • Current or final product,
    • All drawing of the parts .doc
    • All instructions for use .doc
    • All critical features, inspection criteria, etc.

The Device Master record begins as everything defining your product at the moment of design transfer, the version of your product that went through verification and validation testing.  It will evolve as products improve or change. Some changes to the Device Master Record document may require that you re-validate the design. Base any decision of whether or not to re-validate based on risk to the patient, and ensure that your plan includes your risk assumptions so that future teams can make risk-driven decisions.

Design History File

  • Original design plan .doc
  • This design plan .doc
  • Histories of each Device-Master-Record.com
  • Histories of test data, iterations, etc. maintained in document control

A design history file is simply evidence that you had a plan and followed it, with history of each change to your plan. In this example, I use this plan, updates to this plan, and this section as a design history file.

Continuous Improvement

Assumptions used in design, such as reducing risk, shall be continuously updated by linking this design plan to the product risk management plan, updating this plan whenever updating the risk management plan. This is not required by design controls, but I encourage it in my workshops and consulting.

Lessons Learned

In the 15 years since launching this product, I’ve taught design controls to students in college and high school, R&D teams, and corporate executives. Many lessons are difficult to convey in words, such as the nuance between too many restrictions on design controls and not enough restrictions on design controls. Your inputs should be clear enough to set unambiguous boundaries, but open-ended enough to allow creative thought and contributions. The balance between too many restrictions and too much freedom is the middle way, the path to innovative designs and efficient teams.
For quality assurance, the shortest version of lessons learned is the importance of documenting methods for continuous improvement in each product’s plan.
  • Any acquiring company must either adhere to the plan or justify why they change it, and all changes must be maintained in their document system for future teams to access.
  • Long-term efficiency improves with effective plans. Quick meetings are short-sighted; the time saved moving forward that week costs many months of inefficiency and miscommunications later.
This sounds simple enough, but what one person considers to be a clear, easy to understand, and unambiguous plan may not be what another person considers to be a clear, easy to understand, and unambiguous plan.

The most important areas for continuous improvement is reducing risk to patients. Our product had additional risks compared to what was already on the market. I cover Risk Management in another article based on this product: Risk Management: learn from my mistakes.
Lessons learned aren’t limited to quality assurance, they includes leadership techniques and managing “up,” leading executives when you’re middle-management. I share those lessons throughout my blog, including tips for patenting new inventions and methods to accelerate development. But no amount of reading beats real-world experience, continuously improving based on real-world data, the same thing that an effective quality system does to a company.

Parting Thoughts

Today, I consult healthcare corporations on international medical regulations and teach entrepreneurship at universities and in under-served schools. I allow companies to pay nonprofits in equitable healthcare and education instead of paying me. My goal is to help people who help others, and I hope my blog helps you identify unmet patient needs, innovate solutions, and advance healthcare for all of society. I wish you luck.
Please share this if you think others would find it useful.