Our articles & white papers

As a global thought leader in medical product development, Suttons Creek produces extensively researched writing that explores important business & technology issues.

Brainstorming for risks: A bad idea

Risk analysis is a key component of any complex engineering endeavor, but is particularly so when considering technology that may be life sustaining (or life-threatening when something goes wrong) such as many medical devices.

Indeed, there is an entire ISO standard dedicated to guiding the medical device manufacturer on how to design a risk management systems, and increasingly additional standards mandate a continuous risk management process as well.

As any manufacturer begins a risk analysis for a product or component of a product, the first step is necessarily to identify what the risks are, before they can be categorized by safety and occurrence. And though the process may be embellished via various SOPs, it usually amounts to putting a cross-functional product team in a room in brainstorming various potential risks, guided either by formal documentation (FMEA, FTA) or experience (as in the case of a clinical or sales representative who has substantial experience observing customers use the product).

But this is a mistaken approach. Even a well-meaning effort, with a very good team comprised of representatives throughout the company and people who have seen 100’s of customers is going to suffer from absence blindness. Without a structured process for risk identification, the risk analysis will suffer.

So what does that process look like? We’ll explore this in a series of posts on our blog, but as a teaser, it needs to start with evaluating the following sources:

  • Design Documentation
  • Any Pre-Clinical or Clinical Study Observations
  • Complaint Data for this or similar product
  • Complaint Data for competitor’s products in the same field – search via FDA MAUDE database
  • Literature Searches
  • Design Change History
  • Physical and Functional Modeling
  • Use Cases

We’ll cover what we mean by each of these, starting with Use Cases, in a later series.

VIEW ALL ARTICLES