The Medical Device Regulation (MDR) is an EU directive that will come into force on 26 May 2021 and represents a further large-scale industry revolution. In addition, to some reclassifications and high demands on data management, Unique Device Identifiers (UDI) on medical devices will also become mandatory. The USA introduced UDI labeling as early as 2013.

The MDR combines two EU directives and replaces them with one single one. Besides, a new EU regulation for in vitro diagnostics will not come into force until 2022.

• Directive 93/42/EEC on medical devices (Medical Device Directive, MDD)
• Directive 90/385/EEC on active implantable medical devices (AIMD)

New regulations change a lot for manufacturers. This includes the reclassification of some products and medical devices that must be identifiable and traceable, like drug serialization. The corresponding data is exchanged via the Unique Device Identifier Database (UDID). Furthermore, the UDI database is a component of the EUDAMED database in which the data must be stored by the end of May 2020. The product labeling obligation is staggered over several years, but the data must already be stored from 2020 onwards. Each medical device is therefore assigned a unique identifier, a UDI (Unique Device Identifier), which must be stored accordingly in the EUDAMED database.

Transition Periods for UDI

• Class III and implants: May 2021
• Class IIa and IIb: May 2023 
• Class I: May 2025 

Medical devices also include medical software, i.g., for diagnosis or predicting diseases and instruments and implants also fall under this category too. 

What Will the UDI Look Like? 

The MDR covers the premise of labeling medical devices individually, precisely equipping them with a Unique Device Identifier. These UDI module intends to make the life cycle of the products understandable and, for example, simplify recalls. Furthermore, counterfeits can also be better detected, as is the case with drug serialization, or it will be more challenging to bring them into the legal supply chain. The requirements for the UDI are as follows:

• Plain Text
• Machine-Readable
• On all packaging parts of the product
• 2 components: DI (Device Identifier) and PI (Production Identifier – GTIN)

The Device Identifier is the product identifier which identifies the medical device. Also, the UDI-DI is the key identifier to obtain product information stored within the EUDAMED. Additionally, the Production Identifier is the manufacturing identifier and thus contains the date of manufacture and expiry as well as the serial number. The machine-readable code can be applied either as a data matrix code or barcode. The UDI-DI of a medical device is either an alphanumeric or numeric individual code. Moreover, the UDI-DI contains both the product identifier and the master data. These include: 

• Manufacturer Name 
• Type of Control 
• Quantity Per Pack 
• Clinical Size (length, width, volume, diameter) 
• Warning Notices if Required 

Is a Software System Mandatory? 

Master data management within the framework of UDI is a challenge for manufacturers. It is possible to meet this challenge via an internal solution. There are two ways to organize the data in order to comply with the regulation. The first option is to collect all relevant data in an Excel list. The second option is to use external software to manage the data. A software solution is ideal because all UDI, assigned by a manufacturer, must be collected centrally in a list. Distributors also must deal with the manufacturer data. When goods are received, they must check whether the label data matches the product data stored in EUDAMED.

Besides, if something changes in the master data, a new UDI-DI may have to be assigned. Changes that require a new UDI allocation:

• (Trade-)Name- Product model/version
• Need for sterilization before use
• Warnings- Contraindications
• Product quantity in a packaging

Also, the MDR requires that the data must be up-to-date and consistent across systems. Depending on the product portfolio, a simple Excel list could quickly reach its limits and then no longer meet all requirements. In addition, a Single Point of Truth, i.e., centrally managing all data at one location, is less complicated and prevents different data from being entered at various locations.