The International Medical Device Regulators Forum (IMDRF) developed a UDI framework for a globally harmonized system for the identification of medical devices. Adopted in principle by regulatory authorities in many countries, the implementation of UDI regulations and supporting databases is at varying stages of implementation across the globe.
UDI Components
Establishing a UDI strategy involves understanding requirements for both labeling and regulatory database reporting in each country in which your devices will be marketed.
UDI labeling
The UDI is typically presented as a barcode label on device packaging or the device itself (depending on specific requirements). The UDI consists of two major components:
- UDI-DI - This is the static portion of the UDI which identifies the manufacturer along with the specific device version. The UDI-DI (device identifier) is assigned by an approved organization, such as GS1, and contains a company prefix and the manufacturer's internal product code. The UDI-DI is the primary identifier to be used in looking up device attributes in country-specific databases and is assigned prior to placing a product on the market.
As GS1 is widely recognized as an issuing agency across global regulators and industry, the UDI-DI is often referred to in the GS1 nomenclature of Global Trade Item Number (GTIN). - UDI-PI - This is the dynamic portion of the UDI which is assigned by the manufacturer and identifies a manufacturer’s lot number, serial number, manufacturing date, expiration date, or other data as required. The UDI-PI actual values do not appear in country-specific UDI databases, but these databases often require information about the type of data that the UDI-PI represents on the device label.
UDI regulatory database requirements
Many countries have established, or are in the process of establishing, databases to store UDI data. In the United States, use of the Global Unique Device Identification Database (GUDID) is mandated for medical devices. In the EU, EUDAMED consists of multiple modules with one specifically established for UDI. The UDI module is currently available for voluntary use, with mandated compliance scaled in transitional periods through 2026.
Currently, the US GUDID database provides for machine-to-machine (M2M) transmission of data, allowing manufacturers to upload product UDI data directly into the database. The EU has established requirements for M2M transmission as well, but these requirements are not finalized. Most other countries do not have M2M capabilities at this time.
Universal UDI ®
While each country defines specific UDI data requirements, there is a core set of data that is consistent across many markets. At Rimsys, we refer to this data as the Universal UDI® data. Storing Universal UDI® data separately from any country-specific UDI data is an important data management strategy. This ensures that data is single-sourced and consistently applied across submissions to regulatory UDI databases and in other locations in the manufacturers’ quality management system where the data may be needed.
When storing UDI data locally, consider that the same information may be required in different formats in different country regulatory databases. Currently, Rimsys supports the specific data requirements of the US, EU, Saudi Arabia, China, South Korea, and Singapore. Additional countries, which are expected to have similar IMDRF style requirements, will be added as those databases are established by regulators and brought to the industry. Some examples of these countries are Australia, Switzerland, UK, Brazil, and India.
Note that outside of the US’s GUDID, UDI databases are in flux in most countries. This means that having a central RIM system to track known and well-established UDI data is increasingly important.
Machine to machine transmission of UDI data
Machine to machine (M2M) transmission is the process in which data is transmitted from a company’s internal database, typically a RIM or PIM/PLM system, to the regulatory UDI database. Currently, the GUDID database in the US is the only database for which machine to machine (M2M) transmission has been fully developed and is fully supported. Rimsys offers M2M data transmission for GUDID and is currently working to establish M2M transmission with EUDAMED.
Synchronizing UDI data
It is important to note that there are really no requirements for a medical device manufacturer to keep a quality record of the UDI data submitted to regulatory databases (the official data of record is the data that has been reported to and is retrievable from the regulatory database). This means that it is up to the manufacturer to declare the actual source of data for the quality system and to ensure that data is in sync where required.
One of the strategies that can be used when implementing a new RIM system, such as Rimsys, is to export data from GUDID, EUDAMED, and other regulatory UDI databases. That data then forms the basis for the UDI data that is input into the RIM system, ensuring consistency in the application of data across other countries’ UDI databases.
Maintaining and updating submitted UDI data
It is important to implement procedures to ensure data in a product’s UDI record is consistently applied throughout your internal systems as well as with the various regulatory databases. While a single data point should be stored in as few places as possible, everything should be done to minimize the chances that data will get out of sync.
Any product data changes must be evaluated for, among other things, the effect on existing UDI data submissions to regulators. The data changes must be evaluated to determine if the UDI-relevant data can be updated in impacted regulatory databases or if an entirely new UDI-DI and record must be reported. In some cases, such as a change to the product’s catalog number or contact phone number, an existing UDI record may simply need an update. In other cases, such as a change to the sterilization requirements, a new UDI-DI and a new record may be required.
EUDAMED considerations
The EUDAMED database and M2M requirements for UDI are still not finalized, but they are much more static than they were even a month or two ago. We believe that it is beneficial for medical device manufacturers to establish and organize the data needed to submit their products to EUDAMED as soon as possible.
Legacy devices are those medical devices and In Vitro Diagnostic (IVD) devices that are compliant to previous directives (MDD, AIMDD, IVDD) that are being placed on the EU market under the allowed transitional period. With the compulsory application of EUDAMED identified in the 2026 timeframe and the expiry of the transitional period in 2024, there was no need for manufacturers to register legacy devices in the EUDAMED system. Today, with the extension of the transitional period for the certification of devices under MDR and IVDR through 2027, legacy devices may now again be subject to submission of UDI data in EUDAMED.
There will be a 24-month transition period for manufacturers to apply UDI data to EUDAMED once all modules go live. However, if you have any type of action requiring interaction with the Vigilance module of EUDAMED, the required UDI information for those devices must be present in EUDAMED prior to that interaction. The Vigilance module is intended to manage all types of vigilance reports, including Manufacturer’s Incident Reports (MIR) and Field Safety Corrective Action (FSCA) reporting. This also includes and requires post market surveillance reporting submission to the Vigilance module such as Periodic Safety Update Reports (PSUR) and Post Market Surveillance Reports (PMSR).
Manufacturers may be surprised with a shortened transitional period for compliance to EUDAMED’s UDI module due to this requirement and should place priority on higher-risk devices due to the increased likelihood of an interaction with EUDAMED’s Vigilance Module.
For additional resources, watch a replay of our webinar, Why UDI is a regulatory concern, not just an operation process - or read our eBooks, The Ultimate Guide to EU MDR/IVDR UDI and The China NMPA UDI System.
GET IN TOUCH
.avif)
