Unique Device Identification (UDI) FAQ
Unique Device Identification, or "UDI", is a series of numeric or alphanumeric characters that represents device information and production information and is applied to the device label and all levels of packaging in both machine readable (barcode) and human readable forms. It is the ‘key’ to information about the device which is stored in a UDI database (AusUDID).
Patient safety will be strengthened through the establishment of aUDI system for medical devices. When used throughout the healthcare and supply chain it will allow for tracking and tracing of medical devices including those implanted in to patients. This will enhance the ability for doctors to notify patients quickly if there is a safety issue with a medical device. 2017-18 2.8 million devices funded privately and many more public.
Within Australia, GS1 Australia is one of three approved issuing bodies for UDI. HIBCC and ICCBBA are also issuing agencies for UDI numbers within Australia. Please refer to the regulator in your trading market if trading UDI mandated devices outside Australia.
For UDI issuing agencies, please see the below contact details
EU: xxx
US: xxx
The UDI will be the identifier used in business and clinical transactions. For example, in discharge summaries, patient records, registries, clinical notes and records, purchase orders, invoices, inventory maintenance/management.
For consumers, healthcare professionals, researchers, industry and regulators include:
A reduction in medical and surgical errors by being able to quickly trace and obtain vital information about a device.
The ability for patients and consumers to more easily find information relating to devices, through the AusUDID.
Improved post-market surveillance due to the ability to identify models of devices on a national and global basis.
A more robust and secure global distribution chain.
Improved ability for data sharing across regulators and the healthcare industry.
Enhanced research and analysis through the uniform documentation of devices in electronic health records, clinical information systems, registries and other data sources.
Voluntary compliance concluded December 2023 for medical devices supplied in Australia, mandatory compliance begun July 2024 for implantable devices.
1 July 2026: Class III and Class IIb devices
1 July 2027: Class IIa devices
1 July 2028: Class Is (sterile) devices and IVD Class 4 and 3
Reusable devices requiring direct part marking have an additional two years from the applicable date for its respective class.
Medical devices will be placed into one of five main classifications depending on the level of risk they pose. The higher classification level, the more stringent the requirements will be.
Factors determining classification:
What does the manufacturer intend the medical device to be used for?
How invasive will it be in the body (e.g. is it a bandage to be placed on the skin, or a catheter to be inserted into the body)?
Where on (or in) the body will it be used?
How long will it be used for?
E.g. low = tongue depressor - high = pacemaker
For GS1 members, you will already have a GS1 Company Prefix, which uniquely identifies your business globally. You may also be assigning GTINs to your devices, and encoding them in a barcode. The GTIN is your UDI-DI Device Identifier, the first part of the UDI. The second part is the UDI-PI Production Identifier, which can include things like batch number, serial number, manufacturing date, or expiry date. Every product variation and packaging level needs its own unique UDI for traceability in the supply chain from manufacturer to the patient that receives the device.
A UDI has two main parts:
The Device Identifier (UDI -DI), which identifies the manufacturer and specific device model.
The Production Identifier (UDI-PI), which can include batch numbers, serial numbers, manufacturing dates, or expiry dates.
The UDI-PI details included depend on the manufacturer and regulatory requirements. The UDI appears both as readable text and as a scannable barcode, usually something like a GS1 DataMatrix or GS1-128 barcode — because healthcare really does love an acronym and a barcode.
A new UDI-DI is required whenever there is a change that could lead to misidentification of the device.
For Example:
Number of items in a pack
Name
Version or model
Labelled as single use
Packaged sterile
Need for sterilization before use
Critical warnings
Formulation changes
The core UDI principles are aligned globally, but implementation specifics do vary by region.
The FDA uses the GUDID database, the EU uses EUDAMED and includes the Basic UDI-DI requirement, and Australia’s TGA framework is being introduced progressively as of 1 July 2026 onward.
Most global manufacturers aim for one harmonised approach that can work across multiple jurisdictions, and GS1 GTIN’s are widely recognised across all of these systems.
The BASIC UDI-DI does NOT need to be captured in a barcode (AIDC). It is for EUDAMED only. Using the GS1 standards the UDI-DI is the GTIN, and the Basic UDI-DI is the GMN (Global Model Number).
You can find out more at: https://www.gs1.org/services/gmn- generator
The general rule is that if you place product information on the label to meet the labelling requirements/regulations they should be captured in the barcode.
The GS1 standards allow for the capture of different data elements within a GS1-128 linear barcode or a GS1 DataMatrix 2D barcode using the GS1 Application Identifier (AI) standards. GS1 DataMatrix is commonly used for smaller healthcare products and direct part marking, while GS1-128 is often used for cartons and logistics packaging. EAN-13 may still apply for retail medical devices.
All the data in the AUSUDID is publicly available. .
Manufacturers typically submit details like the Device Identifier, brand and model information, risk classification, packaging hierarchy, sterility status, configuration details, and regulatory status.
This will depend on the specific barcode standard used, please refer to the current GS1 General Specifications here - https://ref.gs1.org/standards/genspecs/