Advertisement
Blogs
Advertisement

Controlling Costs in Medical Device Development

Mon, 02/24/2014 - 2:37pm
Joe St. Cyr, Director and Program Manager, Farm

There are dozens of factors that contribute to the cost of developing a medical device and every project is different. There’s no question that the rigor required to meet standards in the medical industry plays a huge part, but based on my experience in medical device development, I’ve identified several other issues that often influence a project’s bottom line. This is by no means a comprehensive list but I hope to highlight a few critical elements of the development process that may help you on your next project.

Managing Risk
Regardless of whether you’re an OEM, a contract manufacturer, or a consultant, time-to-market is critical in the medical device world. The time or money it takes to reduce risk in a project is always going to cost less than following blind optimism down the development path to a big, expensive roadblock. Mitigating risk can take on many forms, such as prototyping early, proper testing, or even developing parallel concepts. It takes a heavily involved program manager with proven intuition to know when to act and what mitigation strategy is appropriate for the risk at hand.

Ask the Users
Managers, key opinion leaders, designers, and engineers often believe they know what’s best for the end user or patient but there is no substitute for asking the user directly. Engaging the user early when requirements are being written and then again when deciding between various design alternatives can help transform an okay product into a great user experience. Users may not always know what they want but they often know what they don’t want and that is information you need. This is a critical and necessary part of the development process that can often be the key to a positive patient outcome and lead to wide market adoption.

‘Magic’ Technology
Have you ever worked on a next-generation device and encountered that one feature or component that you’re told by the client can't be changed because it “contains the magic?” I can’t tell you how many times I’ve heard clients tell me this! My definition of "magic" in a device is either some arcane tribal knowledge that’s broken down over time or a happy accident that resulted in something that miraculously works but you don't know why. This can be a significant hurdle to overcome in the development process; it can suppress creativity, and add excessive time spent finding a workaround. In the end, it may take less effort to investigate and understand the magic than it does to blindly accommodate it. Understanding all of the factors that make a technology work is usually better than ignoring the unknown.

Documentation
From marketing requirements to assembly instructions, the amount of documentation required to properly define a medical device can be time consuming and often overwhelming. A comprehensive design history file (DHF) is critical to accurately capturing design inputs, important decisions, and the overall development path taken to achieve the end result. For every document created there is a checking and approval process that is not only good practice but essential to maintain accuracy. The effort required for proper documentation is often overlooked but can have a significant impact on schedule, budget, and resource time. Planning ahead, defining deliverables in advance, and clearly assigning responsibility will help to make the documentation process more efficient.

Analysis
There are many types of analysis that can be applied to a given project. From tolerance analysis to structural simulations – these all play a critical part in the development process. If you choose to rely too much on a prototype or pilot build without appropriately characterizing and understanding your design, unexpected problems can arise as the build quantity increases. This can often result in you chasing your tail trying to understand the root cause. Identifying the key components and sub-systems and applying the appropriate level of analysis will give you the confidence that the design is going to meet the requirements. Understanding what makes your design work will become valuable knowledge and help save time when you encounter that inevitable problem in manufacturing.

Prototyping
Prototypes can have varying fidelity and provide different value throughout the development process. From early foam models used for preference testing to fully functional prototypes for engineering evaluation - you need prototypes to assess your design and help the team make decisions. Prototyping can take hours, days, or weeks depending on the process and the end goal. Even though prototyping takes time, there is nothing more valuable than creating something the team and the client can touch and have available for experimentation. The cost of not prototyping can be catastrophic and potentially result in lost capital or a finished product that doesn’t function as intended.

Testing
Medical devices typically have elements that are critical to the user experience or the device’s proper function. These areas should not only be prototyped but also appropriately tested. Defining what you want to learn will help you identify the right materials and testing methods, and help the team hypothesize what a successful outcome would be. Writing a test protocol will help you think through the details and reduce the chance that your intended test will be inadequate. Appropriate documentation of the elements being tested should also be in place so you know what you’re testing and can record any deviations you make along the way.

Because every project and product is different, you need to be able to react to things you didn’t expect while exercising good practices along the way. Remember that having some level of requirements or goals is always a good place to start and requirements should evolve throughout the development process. There is always a balance between planning and executing and too much of one without enough of the other can increase cost and lengthen your schedule.

Advertisement

Share this Story

X
You may login with either your assigned username or your e-mail address.
The password field is case sensitive.
Loading