There's an old saying in product development: "a dollar spent in development saves ten dollars in operations". Some will argue it's a hundred dollars. Others with a flair for the dramatic will swear it's a thousand. The point is that product development is the best place to work out the bugs, particularly when it comes to medical devices. But there's a lot of pressure on a small biotech company still on venture money to bring something to market as fast as possible. And that usually means to "get out of development as fast as you can".
One thing to keep in mind though - if a high tech start-up brings something to market before the bugs are worked out, people tend to accept that because it's cutting-edge technology. If an IVD product comes to market with flaws, you could get a warning letter, or have to do a product recall. The consequences of a poorly developed IVD product go well beyond a few negative postings in a blog.
To cut the time-to-market down, some start-ups have chosen the CLIA LDT path rather than a tradition FDA submission. Lately though, there are some rumblings that those days might be drawing to a close, that IVDMIA is coming soon. Yet there's an even more compelling reason: the CLIA only route might not actually save all that much time and money after all. The product can cost a lot to manufacture and support. Your market is often limited. And reimbursement can be a real challenge.
When designing a product, it's best to consider where you'll end up, not just the first stop on the road. For IVD product development, that means following design control under a quality system, so that you can one day build a kit out of your CLIA LDT. But wait, I know what you're thinking. Won't that strategy take another six months and cost twice as much? Not to mention the two or three resources that you'll need to develop and maintain a quality system. Best save that for the next version of the product. Not necessarily.
That's all true if you don't carefully plan the quality system implementation like any other project. Consider how much time and money it will cost if you decide to take that CLIA LDT through the FDA, and you didn't follow design control. How much will repeating product development cost you? Can you even get those clinical samples again? Spending some extra time and money at this stage will yield a lot more product options down the road should the market (or regulatory) conditions change.
So, how do you implement design control / quality systems without derailing your vital product development activities? Here's a few tips to make the process less painful:
- It's okay to lay tracks in front of a moving train. This is one of my favorite analogies for young companies developing infrastructure and products in parallel. Plan the design control implementation process out just like any project, including the key milestones and drop-dead dates. You don't have to have the whole system finalized before you start development, just the one you need at that moment. Remember, having a design review SOP in place just before the review is fine, as long as it's before.
- It's a business, not a democracy. While it's nice that everyone feels like they have a stake in the product, not everyone has to review everything. Set up your document and project review systems to ensure that the key stakeholders, and only the key stakeholders, are required to approve a document or stage review. It's a lot easier to get three signatures than thirty.
- Really, really think about your doc control system. How many companies have put some key infrastructure piece like document control in place on the fly, only to regret the decision two years later. If you think it takes too much time to design and implement a really good doc control system, trying cleaning up after a bad one. A system that relies on someone walking documents around to eight different people for signatures gets old fast, especially when you're up to hundreds of documents. Yikes! Get this one right and you'll save a lot of time and money in the future.
- Hire some savy, experienced people that multi-task well. Design control and quality systems are not where you want to put young, energetic people fresh out of college. At least not without some experienced mentors. There's no substitute for people that have gone through the pain of a bad quality system. Whether you hire full-timers with the skill sets or (ahem) experienced consultants, this is one area where you don't want to overlook the "old-timers". They tend to know the secrets to make it go smoothly.
- There's no "i" in team, so form one. While it may seem like a good idea to hand the quality system project off to the new guy with twenty years in quality assurance, trust me, it's not so good. Like any development project, you'll want a cross-functional team made up of people with various experiences in designing, implementing and using quality systems. I've been part of these teams and trust me, you'll end up with a system that's innovative, efficient and yes, compliant.
Finally, keep in mind that while it might seem like a burden to put a regimented design control / quality system in place, what you typically get at the end is a well designed product. And those tend to delight your customers, and be less expensive to make and support, as well as make regulators happy. Maybe it is a thousand dollars after all...