SaMD Saturday: UDI-DI and UI language
How many acronyms can I fit into one title?
Applying medical device regulations to Software as a Medical Device (SaMD) can often be an exercise in fitting a square peg in a round hole. In this series I’d like to explore some of these difficult areas and offer interpretations and methods for successful compliance. Apologies if the topics seem haphazardly chosen; I’ll write about what I find interesting and what I have experience dealing with, which won’t necessarily be comprehensive. And as usual, none of this is legal advice, just food for thought. Do your own research!
This week I’d like to explore whether or not SaMD manufacturers need to change a product’s UDI-DI when adding new translated variants of the product to market. I’ve seen very different interpretations of MDR’s requirements in this area, and want to give it a thorough magnification.
UDI background
Unique Device Identifier (UDI) is a traceability concept shared by many medical device regulations globally, most notably FDA 21 CFR 820 and EU MDR 2017/745. While the concept has ballooned in complexity over the last few years, the basic premise has remained the same: Each medical device should have a unique identifier that can be used by the manufacturer, regulators, and end users to find information on the device. The UDI is made up of two parts:
UDI-DI (“Device Identifier”): The identifier that marks the device model. In order to ensure that this identifier is unique across manufacturers worldwide, med device regulations require an identifier to be generated from a qualified international database, such as GS1’s Global Trade Item Number database. This UDI-DI is required to be used in the manufacturer’s regulatory documentation, technical file submissions to regulatory bodies, and filed in governmental databases such as AccessGUDID and EUDAMED.
UDI-PI (“Production Identifier”): The identifier that marks the specific device instance. This allows pinpointing of a specific device to its manufacturing origins. There are a few options, such as batch code, date of manufacturer, software version, or serial number.
For example, if I am a manufacturer of x-ray machines, before launch of a specific model, I would generate a GTIN identifier from GS1 to be assigned as the UDI-DI for that model. Let’s say I generate a GTIN of 00148222736188. That is now the model’s UDI-DI. When I start manufacturing these machines, each machine’s label will have the UDI-DI as well as that specific machine’s UDI-PI on it. If I choose to use Date of Manufacture for my UDI-PI and manufacture a machine on 2022-10-11, my full UDI will look something like this on the label:
(01)00148222736188(10)221011
Note that the two parts of the string in parentheses are GS1 application identifiers, which help humans and machines know what the meaning of the following segments are. In this case, 01 indicates GTIN and 10 indicates Date of Manufacture.
If an end user gets this machine in the field and has a problem with it, or if the machine causes an adverse medical event, that end user can now look up the GTIN in the GS1 database or the relevant device database for their country. From there they can find out who the manufacturer is and how to contact them. Once they contact them, the UDI-PI can be used to pinpoint the manufacturing origins of the machine to aid in the investigation of the issue.
When does the UDI-DI need to change?
Medical device manufacturers are constantly making updates to their devices. EU MDR 2017/745 has some requirements on when an update actually requires the manufacturer to assign a new UDI-DI. The Medical Devices Coordination Group, an official European Commission entity composed of EU Member State representatives, states in their UDI for software guidance that:
In accordance with Annex VI Part C, Section 6.5 of the MDR and Section 6.2 of the IVDR, a new UDI-DI is required whenever there is a modification that changes the original performance, the safety of the software or the interpretation of data. Such modifications include new or modified algorithms, database structures, operating platforms, architecture, user interfaces and new channels for interoperability.
The idea here is that any of these “significant” changes are really creating a new device. If a device has been changed in any of these ways, it would be confusing or misleading to group it with the previous version of the device, and would potentially cause identification problem during investigation of a field report. The guidance goes on to provide examples of changes specific to software:
…in the specific case of software, a change to the name or trade name, version or model number, critical warnings or contra-indications, user interface language would require a new UDI-DI.
The intent behind some of these are obvious. For example, if the contra-indications of my device are changing, the group of patients who could use the old version of the device is now different than the group of patients who could use the new version of the device. We should consider the new version to be a new device, since the two are not interchangeable in the field, and therefore assign a new UDI-DI to the new version.
However, some of these elements are a little trickier. The inclusion of “user interface language” poses some challenges, depending on the system architecture and deployment method of your SaMD product. The intent is that a device with an English user interface should not be considered the same device as one with an Italian user interface, and should therefore require different device identifiers. This is because of the “interpretation of data” part of the “significant modification” definition; if there is a possibility that critical data (such as UI instructions or clinical data) could be interpreted differently because of the translation, you want to maintain unique traceability so that you know exactly what device variant is being used in the case of an adverse event. On a more basic level, two devices with different UI languages are not interchangeable in the field since only certain users can use each.
Applying these requirements to SaMD
This is straightforward for hardware devices that have unique UI languages. If I have an X-ray machine model that has a UI in English but want to make one for the Italian market, I can simply assign a new UDI-DI for the Italian machine. But what about for software devices where only one device is distributed but the UI language is programmatically chosen based on the user’s input or location? For example, many mobile apps have strings that are translated in a database and displayed based on the user’s location setting. As a manufacturer, if my app is available in English and I want to add an Italian translation, I am still deploying the same device but the content is configured automatically based on user information. In many cases the user can even change the language themselves directly in the app’s settings. How do we manage the requirement to update the UDI-DI in this case? Here are our options:
We could just replace the previous UDI-DI with a new one when adding a new language to meet the letter of the law. But it’s hard to imagine what kind of value this adds for traceability. We’d still have one UDI-DI for the app, including all of its languages, so what does updating the UDI-DI do for us? It won’t change how we distribute the app and it won’t give us any information about the user’s language.
We could add a unique UDI-DI for each language available in the app. Should the UDI-DI automatically change in the app labelling depending on the language chosen? Would this provide any value to device traceability or field report investigation? It would add complexity and risk, but I’m not sure what value it would add.
We could leave the UDI-DI alone when adding a new language. With devices like these, the manufacturer should ensure that the user’s language is stored in the system’s backend database, and use this database in investigating adverse events in the field.
As you can see, I’m in camp 3. I believe that documenting this shows a good justification for not changing the UDI-DI, and preserves the intent of the regulation. I’m open to hearing other thoughts, since this is a bit of complex issue.