Technical debt
Technical debt"Technical debt" is a concept from software development that refers to the price you pay for decisions that optimise for delivery, at the expense of long term factors. The costs of technical debt can effectively put a product's long term viability in question. It's rarely deliberate, often being the accumulation of decisions taken within projects to get a product through launch. Nonetheless, it needs attention and consideration.
I believe this concept can be applied to medtech products too - not just software - implants, surgical devices - anything that needs certification to be sold. This is because the same idea of maintaining code in software applies to maintaining certifications for medical devices. You don't just achieve certification then forget about it - a lot of work goes into post market data, risk analysis, clinical evaluation etc. These all function better if you give them their due attention in the first place. Furthermore, if you need to make a change to the device later (say, a new manufacturing site or a new indication), you've made more barriers to get your change approved.
Fowler's debt quadrant [https://martinfowler.com/bliki/TechnicalDebtQuadrant.html] extends this idea in an interesting way. Technical debt can be through recklessness or prudence, deliberate or inadvertent. I think this clearly applies to medtech products too:
Prudent deliberate: We don't have the data for this indication - let's leave it out now, collect more data, and apply for it later.
Prudent inadvertent: Through a lack of clear understanding, we missed the application of part of GSPR 23.4s - we'll correct it now.
Reckless deliberate: We don't have time to file all the raw data - just put it in folders in the cupboard.
Reckless inadvertent: We don't really need to do transit testing, it's just a tool used by the surgeon.
Regulatory submissions have a view of all inputs, and can see where corners were cut and which cans were kicked down the road. Whilst our QMS' prompt us to have logs of CAPAs, change controls and non-conformances, we don't routinely keep track of our technical debt - or why an issue was deferred, and what the risks are. Technical debt might therefore be a good category to add to a risk register (you do have one, right?).
Opportunity cost
But why is technical debt relevant to the business case? Opportunity cost.
Opportunity cost, at least as it is relevant here, is the price the organisation pays because it is not able to exploit a new opportunity as a result of the need to service technical debt. This is acutely clear in many medtech organisations - remediation work for a particular project becomes mandatory as a result of the severity or proximity of the deadline. As a result, resource is not available to work on a new product that could allow valuable expansion; or temporary resource is secured at increased cost.
This doesn't just apply to regulatory affairs - it applies to any department in the product development flow. What percentage of time do you think your product development, quality, and regulatory affairs teams are spending keeping legacy files just good enough? Even manufacturing - how much time are they spending keeping processes and programmes functional, instead of excelling?
Long-term horizons
I suspect that technical debt is not visible to senior leaders until a crisis hits - either a major compliance issue, or a serious opportunity cost. From what I've seen, it typically falls to middle managers to juggle the priorities of technical debt and new projects.
I don't think it's often that leaders get to sit down and plan resource across a long term period - say 5-10 years. But for sustained, stable growth of a business, that's what you need to do. Perhaps performing this type of activity more routinely would highlight the cost of technical debt. When considering headcount and resource available for NPD over that timeframe, it becomes immediately obvious what your opportunity cost is.
But what do you do about it? Well, something like:
Detect technical debt - go looking for it. Symptoms include very frustrated RA staff when dealing with products that are already on the market.
Quantify how much time departments spend on it.
Plan long term resource. Not just 3 years - 5 or more. Work out how much time to dedicate to correcting the technical debt, and when and how you can taper it off.
Get to work. Complete items with the biggest time impact first, as the benefit will snowball from there.
If you need a justification to business leadership to do this - look at the end goal - time freed up to work on value-added activities such as new product development, manufacturing efficiency, or capacity projects.
Final thoughts
Is the pain of MDR/IVDR attributable to technical debt?
You could say that, had manufacturers not had a large amount of technical debt (e.g. lack of clinical data, overclaiming, lack of testing per state of the art standards), the MDR assessments wouldn't have been so painful. On the other hand, many devices had been on the market years or decades; at the time they were designed, some of the standards didn't exist.
I think the response of notified bodies to this issue has varied (perhaps even varied within NBs). In my team at BSI, we tried to be cognisant of this; use of post market data could be permissible, but give me your justification as to why testing to that new standard is not needed. I think this can be brought back to technical debt though. If the manufacturer had applied a robust process of detecting changes in state of the art, that rationale would already be written and available.
Conclusion
Consideration of technical debt is underrated. Furthermore, technical debt, and the opportunity cost of it, is not visible to senior leaders until it is too late. A potential route forward is to proactively log known technical debts, instead of filing them away into the mountain of (electronic) paperwork. RA are in a good place to do this - when they compile submissions, or when they respond to a post market issue, they detect technical debt.
The proactive measure would be to go out and look for it, and as a management team, plan for it. I wonder how many organisations are brave enough, and look far enough ahead, to take that view.