The Medical Device Regulation (MDR) is an EU directive that will come into force on 26 May 2020 (edit: postponed to 2021) and represents a further large-scale revolution in the industry. In addition to some reclassifications and high demands on data management, Unique Device Identifiers (UDI) on medical devices will also become mandatory. UDI labeling was introduced in the USA as early as 2013.
The MDR combines two EU directives and replaces them with one single directive. Besides, there is a new EU regulation for in vitro diagnostics that 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)
The new regulation changes 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). 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 if they´re used, i.g., for diagnosis or predicting diseases. Instruments and implants also fall under this category.
What will the UDI look like?
The MDR covers the premise of labeling medical devices individually, precisely, equipping them with a Unique Device Identifier. The UDI module intends to make the life cycle of the products comprehensible, and, for example, to simplify recalls. Counterfeits can also be better detected, as is the case with drug serialization, or it will be more difficult to bring them into the legal supply chain. The requirements for the UDI are as follows:
– plain text
– on all packaging parts of the product
– 2 components: DI (Device Identifier) and PI (Production Identifier – GTIN)
The Device Identifier is the product identifier and serves to identify the medical device. Also, the UDI-DI is the key identifier to get product information stored within the EUDAMED. 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 as a barcode. The UDI-DI of a medical device is either alphanumeric or numeric individual code. 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
MDR also 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. Also, 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.