By Ron Baerg and Mike Russell
“You can pay me now, or you can pay me later” was the punch line of a memorable TV commercial by the FRAM® company about their oil filters around 50 years ago. The “me”: a car mechanic.
Their point: paying (a little) now to replace your oil filter regularly was a far better choice than paying (a lot) later to repair the car.
It’s a great way to remember that there are always tradeoffs in business generally and in medical device development particularly. You can “tradeoff” doing something now and maybe, or maybe not, take care of it later with little added cost/impact. The commercial punch line implies the odds are not in your favor, and that you will pay much, much more later.
The FDA has raised the stakes on one of those tradeoffs: DHF documentation.
“DHF documentation that is created retrospectively or following a prolonged period of time after actual software development, verification, and validation efforts could raise concerns regarding whether a developer has adequate control of their design process.”
Content of Premarket Submissions for Device Software Functions,
June 14, 2023.
This was usually an assumption in submission reviews … now it’s stated directly.
The odds are now even less in your favor that waiting to do any DHF documentation is a good tradeoff.
Why it can cost more to wait
Not doing DHF documentation may help speed up the device development process initially, but doing that will eventually slow things down (and probably cost more) for at least three reasons:
- The submission will be delayed until the DHF documentation gets done.
- The submission will be denied or endure more questions and more scrutiny.
- The submission may get approved, but the device is deficient in some way leading to major reinvestment, recalls, or worse.
We have seen many clients recently with delayed submissions for the first reason. Software documentation is often the culprit, and the increase in SaMD type products increases the odds that inadequate software DHF documentation will be a holdup.
Software is an area particularly prone to people delaying documentation at any level and of any type. The approach is often to finish the “work” – design and development – then document what was done. The thinking is this will save time during development and also save time from updating documentation along the way … then “catching up” will be a quick process when needed. It usually isn’t. Worse yet, there may be product problems found during the documentation process that add even more time to resolve.
The second reason is more obvious but more underappreciated … at least until the recent guidance made it clearer. The design process and controls affect the entire submission. Therefore, if one part of the submission is suspect, then all areas are likely to become suspect and subjected to more review. More review = more time. Answering more reviewer questions = more time. Any corrections = more time. Regulator review of corrections = more time. The more review and remediation cycles, the more time.
The third reason is the subtle and very dangerous one. Using a design process where the documentation is created retrospectively can result in a device being shipped that is unsafe or that has other critical design flaws. Or – all too often – a defect gets added during an update to already released software because the documentation doesn’t provide good support for software maintenance. For a startup this can be a company killer, but even large companies can struggle after a safety incident. Even if people weren’t harmed, it could take a major investment to redesign the product to a safe state.
What can be done?
Does this mean that “agile” approaches should not be used in medical device development, especially for software?
No – just the opposite. Agile and compliant approaches can help by emphasizing two things:
- Understanding where and when things need to be “done.”
- Understanding to what level things need to be “done.”
Here are some software examples:
- One example where the “pay me later” approach can lead to problems (or disaster) is in the area of software requirements. If we identify missing requirements late in the development process it can require a lot of rework. If we don’t find requirements that should have been there, then the software may be released with a severe defect. In the “pay me now” approach we create requirements before or as they’re needed at the same time as we’re designing and developing the software (the latter being a common agile approach). We can update, improve, or correct them as we go and learn more.
- A second example of “pay me later” problems is in risk management documentation. Since risk management documentation ties in so many different parts of the development (requirements, architecture, testing, traceability) it can be tempting to maybe do a little bit of preliminary risk management, develop the software, and then “fix everything up later”. But it is precisely because risk management ties in so many parts that taking the “pay me now” approach can save a lot of time and money in the end. From an agile perspective, the key is to start and then add/update as more is learned throughout development.
- Another advantage of “pay me now” risk management is when it is coupled with “pay me now” architecture. The key here is to have an architecture where software items with higher safety risk are partitioned from software items with lower safety risk. This then allows taking advantage of IEC 62304’s built-in support for scaling process activities based on risk level. Creating the software architecture and performing the risk analysis before software development can then save a lot of time, especially if a large percentage of the software has a lower safety risk.
- As we’ve mentioned, the “pay me now” philosophy can align really well with an iterative development approach, such as Agile. “Pay me now” doesn’t mean doing everything up-front all-at-once (you hopefully don’t need to replace your oil filter, wind-shield wipers, and tires all at the same time). You can start your DHF documentation with what you know now, and then add to it over time. This can produce higher quality results more efficiently (and less painfully) than using the “pay me later” approach.
The best of both
The best approach is often a “pay some now and pay some later as we go” approach. This blends both compliance and leveraging activities for a better, safer product and avoids a massive payment later.
Want to learn more or need help with your software process?
SoftwareCPR offers training and consulting to help you tune your development activities to achieve both compliance and agility.
