UDI Basics: Basic UDI-DI and UBB Codes

1. Key takeaways

On the coding side of Turkish device compliance, three verifiable statutory actions fall due, and all of them must be completed before the device is placed on the market. Getting the sequence and the terminology right at this stage prevents the most common cascade of defects: codes that exist but do not match the technical file, the declaration of conformity or the databases in which they are supposed to appear.

• Three coding-side actions stand out: assign the Temel UDI-DI (Basic UDI-DI), enter it into the UDI database together with the basic data elements set out in Part B of Annex VI (Ek VI B), and place the UDI carrier on the label or packaging.
• Paragraph 1 of Madde 29 requires that, before placing non-custom devices on the market, the manufacturer assign a Basic UDI-DI as defined in Part C of Annex VI, in accordance with the rules of the designated issuing entities, and enter it into the UDI database together with the basic data elements of Part B of Annex VI.
• Paragraph 1 of Madde 27 defines the two-part structure of the UDI system: the UDI-DI (device identifier, pointing to the manufacturer and the device) and the UDI-PI (production identifier, pointing to the production unit and, where applicable, the packaging).
• The timetable rests expressly on Madde 111, paragraph 1, point (c), corresponding to paragraph 4 of Madde 27: Class III and implantable devices from 2021-05-26; Class IIa and IIb from 2023-05-26; Class I from 2025-05-26; and reusable devices that are themselves supplied with a UDI carrier, in three tiers taking effect in 2023 / 2025 / 2027.
• UBB belongs to the product coding concepts on the ÜTS side; its generation rules are operative-layer matters governed by the TİTCK guide (practical estimate).

2. Legal basis

Three instruments sit behind the coding obligations examined in this article: the Medical Device Regulation itself, the amendment regulation that adjusted the transitional timetable, and the parallel IVD regulation with its own coding provisions. The table records each one with its official reference and the specific articles on which the analysis draws.

3. Expert insights

Insight one: the Basic UDI-DI and the UDI-DI are two levels of coding with distinct functions. The Basic UDI-DI points to a group of devices of the same model family and serves as the linking key across documentation, certificates and databases; the UDI-DI points to the specific device instance at a given packaging level. Confusing the two causes the numbers in the technical documentation, the declaration of conformity and the databases to stop corresponding with one another. Reviewers on both the notified body side and the authority side follow these keys across the file, so a single level error propagates through every document that cites the code.

Insight two: the coding of system procedure packs is independent. Under paragraph 2 of Madde 29, non-custom systems or procedure packs must, before being placed on the market, be assigned their own Basic UDI-DI and entered into the UDI database. Combination businesses must therefore open a separate line for the pack itself in the coding ledger. A pack assembled from components that each carry correct codes is still incomplete from the coding standpoint until its own identifier exists and its own database entry has been made.

Insight three: the IVD timetable runs longer. Under the IVD Regulation, Class D falls due from 2023-05-26, Classes B and C from 2025-05-26, and Class A from 2027-05-26. Set against the MD side, a symmetry emerges: the lowest-risk tiers at both ends — Class I on the MD side and Class A on the IVD side — fall on the 2025 and 2027 nodes respectively, but Class A arrives 2 years later than Class I. Businesses covering both regulations therefore face staggered coding deadlines that must be tracked on separate calendars.

4. Practical recommendations

• Build a three-tier coding ledger: Basic UDI-DI (device group) → UDI-DI (packaging level) → UDI-PI (batch / serial number).
• Open a separate coding line for every system or procedure pack, and mark the position of the pack-level UDI carrier in the label artwork.
• Check go-live dates class by class against Madde 111 paragraph 1 point (c), and list any items past their due date as corrective actions.

5. Verification checklist

• □ A Temel UDI-DI has been assigned for each device group in accordance with the rules of the designated issuing entities.
• □ The basic data elements of Part B of Ek VI have been entered into the UDI database together with the Temel UDI-DI.
• □ The UDI carrier has been placed on the label or packaging (Madde 27).
• □ A separate Temel UDI-DI has been assigned for each system or procedure pack (Madde 29, paragraph 2).
• □ Whether the product line has passed its due date has been checked against the 2021 / 2023 / 2025 / 2027 nodes.

Regulatory information verified to 29 October 2026. The provisions and dates listed in this article were checked against the current text on the Turkish legislative information system (MevzuatNo 38657 and 38658); operative-layer numbering rules such as UBB, for which no official original text was obtained, are handled as a practical estimate.

How GRZAN can help. GRZAN provides medical device and IVD registration, quality system, authorised representative and local testing support for the Turkish market. Our team prepares CE/UTS-compliant documentation, and supports post-market vigilance obligations. Business enquiries: info@grzanglobal.com