Part 2: The Three-Headed Monster Called Design Control

Welcome to Part 2 of the four part series on making the transition from LDT to IVD. If you haven’t read the first two blogs on LDT regulation, you should really go back and take a look. Don’t worry,  I’ll wait.

Ready? Great, let’s dive into design control!

First we’ll start with the now obligatory reference to Fallout. Specifically, in Fallout 76 (which by the way is a really underrated game), there’s a boss named Earle Williams that you have to face to finish a quest line. Earle is a three-headed monster that lives in an abandoned mine, which conveniently is on fire. He’s surrounded by his minions, who constantly attack you, and are generally very annoying. And Earle is really, really difficult to bring down, at least when you’re an early stage player. 

For most labs that are contemplating what to do to prepare for the FDA’s move to regulate LDTs, their Earle is called design control. And much like Earle, it’s a three-headed monster that can be tough to tackle, particularly if you’re new to IVD devices. But like Earle, design control can be vanquished if you go in with a solid plan (and some help from your friends).

The first thing to realize about design control is that, while it’s best practice to implement it at the start of a project, you can bring any test under control at any time. Yes, you will need design inputs, a design and development plan (DDP), and risk management - together the three-headed monster. But you don’t have to start over from the beginning just because you didn’t have the test under design control from the start. Depending on the level of testing you’ve done, and the documentation around that testing, you might be further along than you think.

Here are some tips for you to assess the amount of work you’ll need to do to bring your design documentation up to an IVD level:

  • Put together the design input requirements. It’s okay to base your initial design inputs off the specifications you have for your existing test. There are plenty of instances where CLIA tests were submitted to the FDA with design history files that were built - at least to some degree - retrospectively. The important thing here is that you establish your design requirements and that you revisit them periodically throughout the design process. Particularly after you perform risk analysis.

  • Build your risk management plan. The toughest part of doing a risk assessment and building a management plan is being honest about the risks posed by your device. Most start-ups spend their whole time talking to investors about how great their test is. Now they need to think honestly about its flaws. But good risk management is just that. It’s assessing the impact of false results, user errors, critical processes, etc. And it’s also about mitigating those risks effectively. I’ve seen some great risk assessments that were never fully mitigated. That’s a missed opportunity to make a really great, high quality product.

  • Build a design and development plan. One of the first things you’ll need to do when looking at your gaps in design control is review the reports and other documentation that you’ve already collected. Most CLIA labs have a good set of reports that can be used to demonstrate at least verification of the design inputs. But one thing to keep in mind - most CLIA validations are considered design verifications to the FDA. That’s because the agency expects you to verify the inputs and then validate those outputs (specifications) in your final testing. So it’s possible that your DDP will describe some additional studies involving a new sample cohort in order to validate your results.

  • Repeat the first three steps until you’re done. The biggest mistake most people make when they are new to IVDs is that they build a beautiful set of design documents at the beginning of a project, and then never look at them again. Remember, the keys to design control are iteration and learning. The FDA, and other regulatory agencies, expect that your design inputs and risk management looks kind of rough at the start. But as you do more testing and learn more about your test, those documents should look pretty polished at the end. Keep things somewhat general at the beginning, and get more specific at the end. It’s harder to broaden a narrow spec than it is to widen a narrow one!

One last thing. Before I talked about bringing down Earle being tough when you’re a new player. But keep in mind that Earle, and a lot of the boss fights in Fallout 76 are designed to be done with other players. It’s a multiplayer online platform. First time I went up against Earle I was way over my head. Fortunately there were some high level players there to bail me out.

The same is true for design control. There are a lot of folks out there with experience in doing this. Seek them out. Hire them as consultants or staff or both. They can tell you if you’ve got enough documentation, or if you’re going to need to do some more studies to fully characterize your IVD device. A couple of experienced people can really help you beat the three-headed monster.