Medical Device Tracking in Türkiye: Separating ÜTS from Brand Authentication

The first decision in medical device tracking is not which software to buy. It is which record should answer which question. Türkiye's official Product Tracking System, ÜTS, sits at the centre of regulatory registration and reporting duties for medical devices, while a brand-owned authentication layer serves a different purpose and cannot replace those duties.

A sound architecture keeps ÜTS records, internal batch and serial movements, and customer-facing authentication distinct, then connects them through governed product identifiers where appropriate. This prevents teams from treating a regulatory notification as a warehouse event, or an authentication signal as conclusive proof about a physical device.

What should a medical device tracking system solve?

Medical device tracking is the set of processes that keeps a device identity traceable from manufacture or import through distribution and use. In this article, medical products means medical devices. Medicines are governed through different official tracking processes and should not be folded into the same requirements without a separate assessment.

A business searching for one tracking system may actually have several needs. Regulatory staff may need ÜTS registration and movement reporting, operations may need inventory and returns, and a brand team may want a user to check a code on the pack. Those activities can exchange selected data, but they do not carry the same evidential value or ownership.

Separate the three concepts before buying

ÜTS, internal traceability, and brand authentication can complement one another without being the same system. ÜTS is the national infrastructure for in-scope regulatory records and notifications. ERP, warehouse, and quality systems govern a company's own movements. Authentication connects a brand-controlled physical identity to a user result and a reviewable event.

If this boundary is missing from the request for proposal, suppliers will answer different questions. One platform may offer strong inventory movements but no user authentication. Another may display authentication events but perform no official ÜTS transaction.

What does ÜTS govern?

Article 34 of Türkiye's Medical Device Regulation requires relevant parties to fulfil their national ÜTS obligations, with the operational requirements defined by the competent authority. A manufacturer, importer, or distributor should therefore check the current TİTCK rules that apply to its exact role and device scope.

The official ÜTS portal provides access to registered company and product information. Türkiye's Ministry of Health also describes ÜTS as infrastructure designed to track medical devices and cosmetics from manufacture or import onward. A private authentication claim cannot substitute for an official record or notification.

What additional need does brand authentication address?

Brand authentication does not create a new official regulatory status. It presents an identity controlled by the brand at a customer or field touchpoint. When a unique QR code and concealed PIN are correctly paired with a sales pack, the user can query the code and the brand can route validity, prior-use, time, and permitted location signals into its review process.

The value lies in the different touchpoint, not in competing with ÜTS. If support sees a previously used code, it can compare the event with the product, order, authorised channel, return, and packaging records. That signal does not declare a counterfeit; it tells the team where evidence gathering should begin.

How should batch, serial, and authentication codes relate?

A product number may identify a device model, a batch number a production group, a serial number a particular device, and an authentication code a particular sales pack. They should not be collapsed into one field. The batch and serial tracking guide explains the operational difference between group-level and item-level identity.

At minimum, the mapping should document:

• The official product number and the internal product master
• The batch or serial and its manufacturing or import event
• The physical sales pack and its unique authentication code
• The dispatch or delivery record and expected channel
• The authentication event and its support or investigation case

A scan cannot explain an event when one of those links is missing. A valid code may have been applied to the wrong product, or a correct serial may sit beside an authentication label assigned elsewhere. Acceptance tests should inspect both the physical pack and its digital relationships.

How do the four record layers work together?

The first layer contains official obligations and should be owned by the team accountable for regulatory and TİTCK processes. The second holds manufacturing, quality, warehouse, dispatch, and return records. The third handles customer authentication. The fourth classifies, investigates, and closes unusual events.

Integration should not copy every field into every system. ÜTS notification data, internal operational data, and authentication events should be shared only for a defined purpose. Patient or health information should not enter a brand authentication workflow unless a necessary, explicit purpose and lawful basis have been established.

What is the right implementation sequence?

Implementation should begin with scope and a data dictionary, not with a label order. Define the device family, the company's role as manufacturer, importer, or distributor, the product-batch-serial fields already in use, and the results that a user may see.

1. Name the device family and owner of each official obligation.
2. Map fields across ÜTS, ERP, warehouse, quality, and authentication systems.
3. State which physical unit the code on the pack represents.
4. Define first use, legitimate recheck, wrong PIN, return, and cancellation scenarios.
5. Assign an investigation owner and acceptable evidence to every signal.
6. Run end-to-end acceptance tests on real packaging and a limited product group.

The product authentication API integration guide offers a framework for code lifecycle, error handling, and acceptance tests. Integration must still reconcile official reporting separately rather than assume it happened because an internal call succeeded.

How should packaging and label decisions be made?

A security label must not obscure mandatory product information, instructions, a barcode, or other readable content. Because placement can affect a sterile barrier, tamper feature, surface, or storage performance, quality and regulatory specialists should approve the location on the real pack.

The QR code should remain readable, while the concealed PIN stays protected until intended use. Line controls should match the work order, product master, and issued code set to prevent a label from reaching the wrong device. Surplus, rejected, and cancelled labels need separate statuses and must be blocked from reuse.

Which records deserve daily review?

A useful daily workflow goes beyond counting authentication events. To distinguish explainable behaviour from a risk signal, reviewers should combine code state, product match, prior use, time, permitted location, dispatch channel, return, and support context.

• A code or pack that does not match the product master
• A cancelled code or one not yet released for use
• Repeated use with an unexplained time or channel difference
• A support request following unsuccessful PIN attempts
• A new authentication event on a returned product

None of these events proves counterfeiting by itself. Each case should close with a controlled outcome such as legitimate recheck, user error, operational record mismatch, possible label copying, or insufficient evidence.

Where does xBarkod fit?

The xBarkod product authentication and brand protection system supports a unique QR code and concealed scratch-off PIN for each product, user verification, and company-side review of events with product, time, and location context. It also checks whether the code has been used before.

xBarkod is not ÜTS, a quality management system, a warehouse platform, or a patient record. Its appropriate role is the brand authentication layer connected to governed product master data and an incident review process. Start with one device family, real packaging, and written normal-versus-suspicious scenarios so the boundary is visible.

What should buyers ask suppliers?

Compare proposals through record ownership and failure modes, not the number of features. Ask a supplier to demonstrate incorrect mapping, offline processing, code cancellation, return, data export, and service termination alongside the normal journey.

• Are product, batch, serial, and authentication code separate fields?
• Who records code creation, activation, and cancellation?
• How is previous use explained to the user and the company?
• Can access be separated by regulatory, quality, operations, and support role?
• How are events reconciled with company records?
• How do export, retention, and deletion processes work?

Answers should be supported by a demonstrable workflow, sample data dictionary, and acceptance test. Any claim of certification, ÜTS compliance, or guaranteed regulatory conformity should be independently reviewed by the person who owns the official obligation.

Frequently asked questions about medical device tracking

Does a ÜTS record prove that the physical item is authentic?

A ÜTS query provides official product and company record information. The physical pack, serial or batch, and sales channel still need to match the relevant record. A single lookup does not eliminate every counterfeit risk.

Does xBarkod fulfil ÜTS obligations?

No. xBarkod provides brand-controlled QR codes, concealed PINs, user authentication, and company dashboard visibility. Applicable ÜTS registration and notification duties remain in the official system and must follow current TİTCK requirements.

Should a medical device use a batch or serial number?

The answer depends on applicable tracking requirements, production design, and the business need. A batch identifies a group, while a serial identifies one device. The authentication code must also be tied to a physical unit that is consistent with that decision.

Does repeated use of a code mean the product is counterfeit?

Not by itself. A user may recheck a result, support may test the journey, or a product may have been returned. Unexplained repeats should be reviewed with product, time, permitted location, dispatch, and support context.

Can a security label be placed on sterile packaging?

Not without a product-specific quality and regulatory assessment. The label must not harm the sterile barrier, required information, seal, or safe use, and adhesion plus readability should be tested under actual storage and use conditions.

What should be the first document in a tracking project?

Start with a data and record map showing the source, owner, destination, and evidential purpose of every field. It exposes false expectations between ÜTS, company operations, and brand authentication before procurement.

Conclusion: Build the boundaries, not a mythical single system

Reliable medical device tracking does not come from forcing every record into one tool. ÜTS is the home of official obligations, operational systems hold physical movements, authentication manages the user touchpoint, and the incident file explains how a suspicious signal was resolved.

Before committing, map product, batch, serial, and code relationships for one device family, then test first use, recheck, return, and cancellation on the real pack. Expand the xBarkod layer only when it creates an explainable, reviewable authentication journey without being mistaken for an ÜTS process.