A new UDI-DI may be needed depending on some regulatory/legislative rules of thumb. I'll add some additional thoughts to the good feedback you've gotten thus far.
To definitively answer, we need to know which jurisdiction(s) you are targeting, as there are jurisdictional nuances that can impact the approach. This particular topic and its associated requirements can be rather dynamic and sometimes subjective; thus we should be careful not to oversimplify this topic.
First, further explanation is needed regarding your version progression 4.0 to 4.1 to 4.0.1. Are you simultaneously maintaining and marketing two sub-versions (i.e., 4.0 and 4.1) whereby each can evolve independent of the other and each are being marketed?
For Europe's Union, MDCG guidance plainly contains a trigger for a new UDI-DI when there is a change to the software version number. This seems to be driven by the actual legislations' [Regulations 2017/745 and 2017/746 Annexes VI.C.3.9(b)] requirements prescribing that a new UDI-DI is required if the change includes a change in the UDI database data element for device version or model, as these legislations state that such a change could lead to misidentification of the device and/or ambiguity in its traceability. Accordingly, be sure you have given due consideration to this specific European software UDI-DI change trigger regarding changes to the software version number.
At potential odds with Europe's aforesaid plain trigger regarding changes in the software version number is the legislations' [MDR Annex VI.C.6.5; IVDR Annex VI.C.6.2] additional parameters for managing software UDI and changes to the UDI-DI. These additional parameters more sensibly focus on the basic nature of the change [see MDR Annex VI.C.6.5.2/3 or IVDR Annex VI.C.6.2.2/3] rather than the impact to the version number or UDI database. Ultimately, I recommend focusing most on the basic nature/impact of the change, more so than on whether the change includes a changed version/model number (notwithstanding a plan for reconciling with the version number change trigger I mentioned in the preceding paragraph; for that, consider leveraging if appropriate the MDR/IVDR parameter linking the UDI to the system level of the software which may open opportunities to avoid linking the UDI to the subsystem / sub-version level). Indeed, I've seen different clients give different meanings to their software versioning schemes, and I've seen that those variable schemes don't always track clearly to the definitions (or lack thereof) of "version" or "model" in applicable UDI regulations / legislation.
For these reasons and purposes, we need to know precisely what has changed in your software rather than focusing on labels like "no significant changes" or "no major significant change", as those leave open the possibility for subjectivity, ambiguity, and inconsistent interpretations.
I mentioned Europe's approach to the basic nature of software changes. By comparison, the United States for example requires a new UDI-DI when there is a change to the "version or model", where "version or model" is defined (21 CFR 830.3) as all devices that have specifications, performance, size, and composition, within limits set by the labeler. Much can be said about this U.S. FDA threshold. But suffice it to say that when promulgating the FDA UDI regulations, FDA ultimately concluded that it should be left to the UDI labeler (rather than overly prescriptive regulations or other interpretations) to decide if a change results in a new "version or model" for UDI purposes. Thus again, focus on whether the basic nature of the change would constitute a new version or model based on your pre-defined and documented (i.e., in your UDI SOP) application of FDA's definition of software "version" and on the "limits" you have set therein for that threshold.
------------------------------
Kevin Randall, ASQ CQA, RAC (Europe, U.S., Canada)
Principal Consultant
Ridgway, CO
United States
© Copyright 2023 by ComplianceAcuity, Inc. All rights reserved.
------------------------------
Original Message:
Sent: 26-Oct-2023 09:23
From: Dan O'Leary
Subject: UDI-DI software versions
The best approach is to make decision based on the user's point of view. The US regulation requires a new UDI-DI for each "version or model" and has some information about that.
However, it usually comes down to two things. First is whether the user would consider the product after change as different from before the change; this is a new version or model. If so, this needs a new UDI-DI. In addition, the change will often create a new part in your company's sales catalog. For many companies there is a one-to-one correspondence between the catalog number and the UDI-DI.
------------------------------
Dan O'Leary CQA, CQE
Swanzey NH
United States
Original Message:
Sent: 25-Oct-2023 12:21
From: Anonymous Member
Subject: UDI-DI software versions
This message was posted by a user wishing to remain anonymous
hello RAPS,
we have software major version 4.0 with assigned Basic UDI-DI, UDI-DI. We made revision 4.1 - a minor revision (no significant changes). Does the new UDI-DI should be assigned for revision 4.1? what about the next revision 4.0.1 (no major significant change)- is the new UDI-DI required?
thank you!