The EU is planning to use the UDI system to impose an obligation to identify and register medical devices that goes far beyond what is required today.
Even for stand-alone software, the Medical Device Regulation MDR requires a UDI. Read about what you need to prepare for here.
The EU wants to be able to track medical devices quickly and easily – from manufacturer to user. This will allow a quick reaction in the event of an incident, as
One or more organizations should operate a system that assigns UDIs. The organization must do this over a period of at least 10 years.
Addendum: The transitional provisions in Article 120 (12) state: Until the Commission has designated the allocation bodies in accordance with Article 27(2), GS1, HIBCC and ICCBBA will be deemed to be designated allocation bodies.
At this point, manufacturers obtain a unique identification number for each medical device, but also for each higher-level packaging (with the exception of containers). The MDR only waives the UDI for custom-made devices and products for clinical trials.
Manufacturers must include the Basic UDI in their declaration of conformity and maintain a list of all assigned UDIs as part of the technical documentation for each medical device.
The EU encourages member states to also require operators to store the UDIs of medical devices used or purchased.
The EU must operate a database in which all UDIs are stored. It specifies which attributes per medical device must be at least taken into account. The use of this database (at least access to it) should be free of charge and public.
Manufacturers must store the Basic UDI and associated information such as product name, product version, classification (e.g. as sterile or suitable for reuse) in the database and keep it current.
The EU formulates the requirements for the UDI system in Article 27 and in Annex VI.
Annex VI consists of several parts:
The MDR distinguishes between the two Unique Device Identifiers UDI-DI and UDI-PI:
Read more below about the difference between Basic UDI-DI and UDI-DI.
Specific rules apply to stand-alone software.
A new UDI-DI should be assigned whenever there is a change in:
As examples, the MDR cites changes to:
On the other hand, “only” a new UDI-PI would be necessary for small changes such as
As a manufacturer, all changes to the third digit of the version number can be said to result in a new UDI-PI, everything else in a new UDI-DI.
Therefore, there is no requirement to allocate a unique UDI for each installation.
The manufacturer must present the UDI(s):
The EU and its Medical Device Coordination Group (MDCG) have published several guidance documents, which you will find below with comment under “News.”
MDR and IVDR distinguish between Basic UDI-DI (“Basic UDI-DI”) and UDI-DI. The Basic UDI-DI is intended to provide a bracket for multiple variants of a medical device. Examples of such variants are:
The MDR defines the UDI as follows:
The Basic UDI-DI is the primary identifier of a product model. It is the product’s identification, which is assigned at the unit of use level. It is independent of packaging units and is also the most important ordering feature for records in the UDI database.
The Basic UDI-DI must be shown in the relevant certificates and EU declarations of conformity.
Each UDI-DI belongs to exactly one Basic UDI-DI.
The MDR and IVDR require the Basic UDI-DI to be specified in the following cases:
Unlike the UDI-DI, the Basic UDI-DI does not appear on the label or packaging.
According to the Guideline of the UDI Working Group, the different UDI-DIs contain the following data elements:
Basic UDI-DI | UDI-DIs | UDI DIs (container package DI) |
|
|
|
Table 1: The mandatory fields are noted in bold; bold and italic are the fields that are mandatory if they are applicable. The data elements where changes result in a new UDI-DI are underlined.
Thus, multiple variants of a product may only display a common Basic UDI-DI if the following fields are the same:
However, this does not mean that manufacturers are permitted to attach a common Basic UDI-DI to all products with the same data elements specified above. The Basic UDI-DI should only group together products with the same intended purpose.
Interestingly, manufacturers must define the “Medical Device Nomenclature” at the device level (UDI-DI) and not at the product group level (Basic UDI-DI).
This nomenclature appears to be more granular than the “Generic Device Group” and “Category of Devices” introduced by the MDR.
Read more about product groups and product categories here.
Much still seems unclear:
In the meantime, there is another nomenclature for medical devices which is intended to be used for EUDAMED. In addition, some standards have been published in the broader context of UDI:
Some allocation bodies have now published the formats for the UDI (HRI and AIDC). You can download the specifications here as a zip file.
The requirements for using the UDI are spread across lots of MDR articles and annexes. This table may serve as a quick overview:
English | German | Article, reference |
Technical Documentation | Technische Dokumentation | Appendix II |
Declaration of Conformity | Konformitätserklärung | Article 19, Annex IV |
Free Sales Certificate | Freiverkaufszertifikate | Article 60 |
Summary of Safety and Clinical Performance (SSCP) | Kurzbericht über Sicherheit und klinische Leistun | Article 32 |
Patient Information / Implant Card | Patienteninformation, Implatationsausweis | Article 18 |
Periodic Safety Update Report (PSUR) | Regelmäßig aktualisierter Bericht über die Sicherheit | Article 86 |
Reports regarding serious incident, Periodic Summary Report | Meldung von schwerwiegenden Vorkommnissen und Sicherheitskorrektur-Maßnahmen im Feld | Article 87 |
Post-Market Clinical Follow-up (PMCF) Update Report | Bericht über die klinische Nachbeobachtung nach dem Inverkehrbringen | Annex XIV Part B |
Field Safety Corrective Action (FSCA), Field Safety Corrective Notice | Sicherheitsrelevante korrektive Maßnahme im Feld, Sicherheitsinformationen | Article 87 |
Repair, Refurbish, Maintenance Report | Reparatur-, Aufbereitungs- und Wartungsdokumente | |
Logistic Documents (Delivery Note, Invoice, Production Order) | Logistik-Dokumente (Lieferscheine, Rechnungen, Fertigungsaufträge) |
Thanks to Martin Tettke from Berlin Cert for this overview
February 2020
The article on MDR transition periods also addresses transition periods for UDI and UDI carriers.
April 2019: Another publication from the MDCG
The MDCG proposes that the EUDAMED be amended to allow manufacturers to register “legacy products” in EUDAMED without a Basic UDI-DI and UDI-DI:
[The] MDCG considers it appropriate to adapt the Eudamed design to allow the registration of legacy devices in Eudamed in the absence of a (Basic) UDI-DI.
Source: MDCG 2019-05
Another MDCG publication (MDCG 2019-04) addresses when EUDAMED is mandatory. This clarification is necessary because Article 123 is misleading. For more, see the article on EUDAMED.
The Medical Device Coordination Group MDCG published no less than five documents in October, which we would like to briefly present to you here:
The first of the new documents addresses systems and procedure packs. It repeats the definitions of the terms and mentions one exception: If a natural or legal person makes several products (e.g. medical devices) available “together” specifically for a particular customer, this would not be designated as placing on the market.
Other “clarifications” include:
The MDCG 2018-4 document goes into more detail about the attributes just mentioned.
Even after reading this publication several times, it is not clear what the point of it is. In the document, it seems as if the authors are letting readers participate in their own learning process. The results are banal. The requirements regarding the UDI for stand-alone software are already formulated sufficiently clearly in the MDR (and IVDR):
Article 16 of the MDR or IVDR is entitled “Cases in which the manufacturer’s obligations also apply to importers, distributors or other persons.” In these cases, economic operators (e.g. distributors, importers) are required to comply with the requirements of the MDR that otherwise apply to manufacturers. This includes the requirements for the UDI and registration of these economic operators.
The MDCG states that economic operators are exempt from this obligation if there is a corresponding agreement with the manufacturer and the manufacturer is indicated as such on the label.
It is not entirely clear why this “clarification” is needed. Everything is stated in Article 16(1)a).
The MDCG notes that essentially only three (of the public) data elements in EUDAMED allow free text. Since one of the goals of EUDAMED is to provide transparency to European citizens, the question arises as to the language in which these free texts are to be stored.
The MDCG proposes that this data be provided in both English and the languages of the countries in which the product is sold. The same applies to the warnings. The MDCG is considering that universally understood symbols could also be considered.
How much these documents really provide “guidance” can be questioned. The documents do not explain what ambiguities actually exist that need to be resolved. Outsiders cannot understand the choice of topics either.
Are these really the biggest problems we have in interpreting the MDR and IVDR? Would it not be more urgent to define the API and the format for the “bulk uploads,” or at least make recommendations for them? How else are manufacturers supposed to convert their IT systems in time to meet the regulatory requirements regarding EUDAMED and UDI?
The MDCG has given some thought to the Basic UDI-DI. The relevant documents are presented above.
The FDA requires a unique number for medical devices, the Unique Device Identification (UDI). This may work well for physical products. It is not a problem to affix stickers on the packaging or on the device. But with software? Where would you put a UDI on a virtual product? You could clearly label the DVDs, but that would ban all downloads.
Fortunately, the FDA has clarified the “UDI requirements” to the effect that “unlike most devices, software will only have to exhibit a means of displaying the UDI [...] it can also be within the software itself”.
It is therefore sufficient to display the UDI within the software. However, when it comes to associating this number with a customer (for example, to be able to contact them in the event of a product recall), this alone is not sufficient. A download without authentication / registration is therefore not useful.
Possible solutions: You could assign a unique UDI during registration and enter it in the software to display it under “Help > About,” for example.
The EU has established a helpdesk.
Johner Institute helps manufacturers meet UDI regulatory requirements quickly and securely. It responds to brief questions in particular in Micro-Consulting regularly and even free of charge.
Change history