Time to Play Design Control Catch Up

I’ve written plenty of design control procedures. I understand FDA design control regulations very well. I’ve trained dozens of engineers and medical device professionals on the “rules” of design control. When to document, how to document, why to document.

And now I’m up to my eyeballs on a startup medical device product development project realizing I have to play catch up. Realizing that we are about to initiate tooling and that the design control documentation needs to get to a similar point in development.

The medical device design control purist will quickly tell you that keeping the design control documentation current and up to date with the state of the project is an absolute must. The medical device pragmatist will tell you to do the real development first and catch up the documentation later. I find myself stuck in between these two schools of thought. A few years ago, I would have been standing at the pulpit of design control advocating the need to keep documentation up to speed and current. Today, I have a very different point of view.

Don’t mishear me. I believe all the intent of design control regulations has been followed on this project. I believe there are documents, emails, notes, action items, etc. that adequately address everything that must be demonstrated with sound documentation and records. The challenge now, though, is to successfully extract this information buried deep in email messages, file folders on computer hard drives, and so on and to ensure it is placed in its proper home in the appropriate design control record.

I feel like now is the time to do so. Not to sound complacent, but I feel like I have time to take a few breaths before the strong push to the finish line. Just better make sure we have everything we need to win this race.

Medical Device Risk Management – Hazards, Harm, & Causes

One of the most critical roles I play for medical device startup clients is that of educator. And the usual topics for those involved with medical device product development include Design Controls, Risk Management, and Quality Management System. Let me dive a little more into Risk Management with this post. Specifically, I want to help explain hazard, harm, and cause.

First, a few official definitions according to ISO 14971:

  • Harm – physical injury or damage to the health of people, or damage to property or the environment
  • Hazard – potential source of harm
  • Hazardous Situation – circumstance in which people, property, or the environment are exposed to one or more hazard(s)
  • Risk – combination of the probability of occurrence of harm and the severity of that harm
  • Severity – measure of the possible consequences of a hazard

While the definitions seem pretty clear, I can assure you from personal experience the concepts because risk management and how to capture the details can sometimes get confusing. Specifically, I’ve seen time and time again where the concepts of hazard, harm, and cause can get a little muddy.

So maybe thinking about it this way might help:

  • Harm is the potential outcome of a hazard.
  • Severity is the measure of the harm.
  • Cause is what can lead to hazard.

Bootstrapping a Quality System – Advice for Medical Device Startups

Within the past few weeks, we’ve been approached by a few early stage medical device startups requesting assistance. One of the common needs of these potential clients is a FDA / ISO compliant quality system. I’ve been asked to quote a build-from-scratch quality system. I’ve also had to educate a couple others on what a quality system is and why they should even care. I suspect some quality purists would tell these startups that it is absolutely essential to implement a fully compliant quality system ASAP.

I, however, do not agree. Especially for an early stage startup. Why not?

Hiring a resource to draft and implement quality system procedures is overhead. More times than not, the capital spent establishing a FDA / ISO quality system for a very early stage startup is not the best way to spend valuable and usually limited dollars.

Don’t misunderstand me. Yes, a compliant quality system is ABSOLUTELY necessary to have in place prior to going to market. But in the world of medical device startups, this could be a very long time. In the world of medical device startups, very few quality system elements are even meaningful during the fragile product development process.

Instead, I advise my startup friends to bootstrap their quality system. In other words, build the parts and pieces as you go and as you need them. And for a startup, there are likely only a few pieces that essential during medical device product development.

In my opinion, the critical quality system components during development are:

  • Design Control / Design & Development
  • Risk Management
  • Supplier Controls (because most startups rely on a fair amount of outsourcing)
  • Document Control / Record Management

Once the startup approaches the stage of regulatory submissions, additional elements of a quality system become more pertinent. But until then, keep the quality system bare bones. Bootstrap it and build it as you go.

How to Help A Medical Device Startup Up Meet FDA Design Controls

Earlier this week, I conducted design control training for a product development firm. The company has been providing product development services for a number of years. Recently, they were hired by a medical device startup to develop custom electronics and firmware for clinical applications. The technical challenges posed by this project are well within the company’s area of expertise. However, they had some concerns about complying with FDA Design Control regulations.

The product development company decided to call Creo Quality for assistance and to provide training on the topic. The company has implemented a quality system fashioned in large part on ISO 9001 Quality Management System standard. Prior to the training, I reviewed their procedures on design and development. Because of the ISO foundation, the procedures for product development are very much in alignment with FDA Design Controls.

And this was a bit of an epiphany for the attendees during the training session. They realized that ISO design and development requirements are very similar to FDA Design Controls. In my opinion, the primary difference is terminology based. As the attendees came to this realization that their current practices were by and large in alignment with FDA expectations, I could see a collective sigh of relief from the room. The message they heard was: business as usual.

For the most part, this is correct. Yet, there is a bit of a caveat. The medical device startup who has hired them to do the development work has NO familiarity or understanding of FDA Design Control regulations. I explained that the product development firm now has a bit of a responsibility to help educate the startup. The product development company needs to know what a DHF is and what the startup will need for their 510(k) and be able to effectively communicate this.

During the training, I had a few questions and a couple concerns. Not so much regarding the product development firm. But more so about the medical device startup. The startup has only outsourced part of the development work to this firm. The overall system integration, and all the development work and documentation that goes along with it, is the responsibility of the startup. Not sure if they realize this yet.

And I think this is sometimes this is part of the challenge. Product development done by divide and conquer is often times challenging. Usually there are gaps in the documentation and testing, especially where mating components interface with one another.

This product development project will be interesting to be part of. I hope to be in a position to also help the medical device startup ensure design control compliance.