“You can pay me now, or you can pay me later”

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:

  1. The submission will be delayed until the DHF documentation gets done.
  2. The submission will be denied or endure more questions and more scrutiny.
  3. 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:

  1. Understanding where and when things need to be “done.”
  2. 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.

About the author

Succeeding despite relentless change is the goal of 21st century organizations. Mike helps achieve those successes by working with leaders of start-ups to Fortune 20 companies and national governments. His aim is to help them re-imagine and create adaptive, innovative enterprises that increase profitability and value across the quadruple bottom line: customers, employees, owners/shareholders, and communities.

SoftwareCPR Training Courses:

IEC 62304 and other emerging standards for Medical Device and HealthIT Software

Our flagship course for preparing regulatory, quality, engineering, operations, and others for the activities and documentation expected for IEC 62304 conformance and for FDA expectations. The goal is to educate on the intent and purpose so that the participants are able to make informed decisions in the future.  Focus is not simply what the standard says, but what is meant and discuss examples and approaches one might implement to comply.  Special deep discount pricing available to FDA attendees and other regulators.

3-days onsite with group exercises, quizzes, examples, Q&A.

Instructor: Brian Pate

Next public offering:  TBD

Call or email now to schedule a private, in-house class. The fall schedule is filling up!

Email training@softwarecpr.com to request a special pre-registration discount.  Limited number of pre-registration coupons.

Registration Link:

TBD

 


 

Being Agile & Yet Compliant (Public or Private)

Our SoftwareCPR unique approach to incorporating agile and lean engineering to your medical device software process training course is now open for scheduling!

  • Agile principles that align well with medical
  • Backlog management
  • Agile risk management
  • Incremental and iterative software development lifecycle management
  •  Frequent release management
  • And more!

2-days onsite (4 days virtual) with group exercises, quizzes, examples, Q&A.

Instructors: Mike Russell, Ron Baerg

Next public offering: TBD

 


 

Medical Device Cybersecurity (Public or Private)

This course takes a deep dive into the US FDA expectations for cybersecurity activities in the product development process with central focus on the cybersecurity risk analysis process. Overall approach will be tied to relevant standards and FDA guidance documentation. The course will follow the ISO 14971:2019 framework for overall structure but utilize IEC 62304, IEC 81001-5-1, and AAMI TIR57 for specific details regarding cybersecurity planning, risk characterization, threat modeling, and control strategies.

2-days onsite with group exercises, quizzes, examples, Q&A.

Instructor: Dr Peter Rech, 2nd instructor (optional)

Next public offering:  TBD

Corporate Office

15148 Springview St.
Tampa, FL 33624
USA
+1-781-721-2921
Partners located in the US (CA, FL, MA, MN, TX) and Canada.