For Japanese-affiliated companies that register and sell medical devices in Thailand, “where do we even start with medical device UDI compliance” has quietly become a live operational question. The trigger is a new labeling requirement that took effect on 20 June 2026. But the notification behind it does not cover medical devices in general. It applies only to SaMD (Software as a Medical Device) in risk classes 2 to 4. This article draws that boundary precisely first, then explains what compliance actually consists of — building and owning an internal issuing ledger for DI and PI — and shows, through a fictional model company, roughly how much effort the work takes.
What medical device UDI compliance actually changed — an overview of the Thai MOPH notification B.E. 2568
Thailand’s Ministry of Public Health issued a notification requiring UDI (Unique Device Identification) marking for SaMD (Software as a Medical Device) in risk classes 2 to 4. The notification was published in the Thai Government Gazette on 22 December 2025 and came into force on 20 June 2026.
Let me put the single most important point of this article up front. What this notification covers is SaMD (Software as a Medical Device) in risk classes 2 to 4 — not medical devices in general. Physical, hardware-based medical devices were not newly brought under a UDI marking obligation by this notification. Physical devices remain subject to the existing medical device registration regime and labeling rules, which apply separately. This notification sits alongside that framework and deals with an identification problem specific to software-based medical devices.
This distinction matters because the practical blast radius is completely different in each case. If the message that circulates internally is the rough version — “Thailand has mandated UDI for medical devices” — two failure modes follow. A label revision project gets spun up for physical products that were never in scope. Or, in the opposite direction, a software team concludes “we only ship software, so medical device regulation is not our problem” and the SaMD work never starts. The worst outcome is a mismatch in scope understanding between the Thai subsidiary and the Japanese head office that goes unnoticed for months.
Why software became the subject now
The background is a global shift in what a medical device physically is. Blood glucose and ECG analysis, diagnostic imaging support, dosage calculation assistance — functions that used to be embedded in dedicated hardware are increasingly delivered as smartphone apps and cloud services. Once that happens, the traditional identification method of stamping a serial number onto a housing no longer works. Software has no housing, and its contents keep changing long after release.
The international response to the question “how do you uniquely identify a product that has no housing and keeps changing” has been the UDI framework. Thailand’s notification can be read as an application of that international direction to SaMD (Software as a Medical Device) in risk classes 2 to 4. For companies that already obtain and operate UDI codes in the United States, the EU, and other IMDRF-aligned markets, the underlying concept will be familiar.
Sort out the effective date and the transition period before anything else
The notification took effect on 20 June 2026. A transition period sits on top of that date, and if you misread who the transition applies to, the entire premise of your compliance schedule collapses. Use the following breakdown.
| Category | When it applies | What it means in practice |
|---|---|---|
| Existing registrations of SaMD in risk classes 2 to 4 | Labels and instructions for use that complied with the 2020 notification may continue to be used for up to two years from the effective date, i.e. until around June 2028 | No need to reprint labels immediately. The preparation window can be planned and used deliberately |
| New registrations of SaMD in risk classes 2 to 4 | The new requirements apply from the effective date of 20 June 2026 | There is no grace period for products registered from now on. Compliance must be in place before the registration application |
| SaMD in risk class 1 | Outside the scope of this notification | No new UDI marking obligation arises from this notification |
| Physical medical devices (hardware) | Outside the scope of this notification | The existing medical device registration and labeling rules apply separately |
The row most often overlooked is the second one. What spreads internally is usually only the first row — “we have two years” — and then, days before a new product’s registration filing, someone discovers that no UDI has been issued. New registrations have no grace period. If you have any plan to bring a new SaMD in risk classes 2 to 4 to the Thai market, this is work to start immediately.
Which SaMD is in scope, and how the risk classes work
This is the pivotal section of the article. The goal here is to get concrete enough that you can determine whether your own products are in scope.
Thai medical device regulation sorts devices into four levels according to degree of risk. The UDI marking obligation created by this notification reaches SaMD (Software as a Medical Device) falling into risk class 2 (moderate risk), risk class 3 (moderate to high risk), and risk class 4 (high risk). SaMD in risk class 1 (low risk) is outside the scope of this notification.
So the determination has two stages. Stage one asks whether the product is SaMD at all. Stage two asks whether that SaMD falls in risk class 2 to 4. If the answer to either is no, this notification creates no UDI marking obligation for that product.
Stage one — is the product SaMD
The general framing is that SaMD refers to software that serves a medical purpose in its own right, rather than software embedded as part of a hardware medical device. The delivery form does not matter — smartphone app, PC software, a service running in the cloud.
In practice, the hard calls tend to look like the following.
| Product form | General way of thinking about it | What to look at when deciding |
|---|---|---|
| Control software embedded in a measuring instrument | Usually treated as embedded software integral to the device | Is it distributed and updated on its own, or only usable together with the device |
| A standalone app that analyzes data from a measuring instrument | May qualify as SaMD if it serves a medical purpose independently | Can it inform a clinical judgment without the instrument |
| A viewer that only records and displays | May fall outside the medical device definition if it plays no part in clinical judgment | Does it analyze, recommend, or warn — in other words, participate in a judgment |
| A back-office system handling hospital appointments and billing | Usually falls outside the medical device definition if it makes no medical judgment | Does it affect patient diagnosis or treatment decisions |
This determination has a wide gray zone, and the final answer is ultimately a matter for the Thai authority and regulatory specialists within the registration process. Use this table only as a starting point for an internal discussion.
Stage two — how to think about risk classification
Risk classification turns on how serious an impact the information the software produces could have on a patient. In very broad terms, the following sense of direction is enough to get an internal conversation moving.
| Risk class | Broad character | UDI marking obligation under this notification |
|---|---|---|
| Risk class 1 | Low risk. Limited to supplementary information for health management | Out of scope |
| Risk class 2 | Moderate risk. Provides information that supports treatment decisions | In scope |
| Risk class 3 | Moderate to high risk. Participates in judgments about serious conditions | In scope |
| Risk class 4 | High risk. Participates in judgments with direct life-and-death consequences | In scope |
The “broad character” column is an orientation aid for internal discussion, not the authority’s own definitional text. Actual classification follows the definitions in Thai medical device regulation and the authority’s determination.
In most cases your products’ risk class has already been fixed during the Thai medical device registration process. Check the registration certificate or the application file and the class will be stated there. There is no need to redo a classification exercise from scratch. Start instead by taking an inventory of the registration information you already hold.
Keep the scope determination as a standing list
The more products a company handles, the more value there is in recording these determinations as a per-product list. The UDI issuing ledger discussed later in this article is built outward from that scope determination list. Writing down why a product was judged out of scope is what pays off years later, whether during an interaction with the authority or during an internal handover.
What UDI really is — DI as the fixed identifier, PI as the variable data, and how it relates to lot and serial control
When people hear “UDI compliance,” most first picture the task of adding a barcode to a label. That is the last ten percent of the work. The substance is issuing identifiers and holding an internal ledger that tracks their history.
Internationally, UDI is made up of two elements
In the international UDI framework, UDI is generally understood as consisting of two broad elements. The frameworks put forward by bodies such as IMDRF and GS1 share this two-element structure.
| Element | Content | When it changes |
|---|---|---|
| DI (Device Identifier, the fixed identifier) | A fixed code pointing uniquely at the product itself, representing the combination of manufacturer and product model | Does not change as long as the product is the same |
| PI (Production Identifier, the variable data) | Lot number, serial number, version number, manufacturing date, expiry date and similar information that changes with each shipment unit | Changes with each shipment unit or release |
DI answers “what is this product.” PI answers “which specific unit or version of it.” Only with both in place can a product in the market be uniquely pinned down.
One distinction is worth stating explicitly here. The DI and PI split itself is the general framing of the international UDI framework — it is not a division that the Thai notification uniquely specifies. What the Thai notification specifies for SaMD (Software as a Medical Device) in risk classes 2 to 4 is the set of items to be shown on the label. Specifically, the product name and intended use, the lot number, version or serial number, and the manufacturing date and expiry date.
In practice, then, the work has two layers. You design your internal identification scheme within the international DI and PI framework, while making certain you satisfy the label content items that the Thai notification requires for SaMD (Software as a Medical Device) in risk classes 2 to 4. For a company that already holds UDI codes in the United States or the EU, that design work is effectively already done, and the main remaining task for the Thai market is reported to be the submission of master data to the Thai FDA’s UDI database.
Your existing lot and unit control know-how transfers directly
This is the good news for manufacturers. The DI and PI structure is structurally identical to the lot control and serial control that factories have practised for decades.
| Shop-floor concept | Its counterpart in UDI | The shared management principle |
|---|---|---|
| Part number, drawing number | DI (the fixed identifier) | Once set, do not change it casually. Define the criteria for changing it in a written rule |
| Lot number | PI (lot, version) | Define the issuing rule and hold a ledger that prevents duplicate assignment |
| Serial number | PI (serial) | Decide on cost-benefit grounds whether tracking down to the individual unit is required |
| Shop travellers and shipping labels | UDI labels and instructions for use | Manage the display medium and the displayed items as separate concerns |
Whether to track by lot or by individual unit is a classic question in manufacturing traceability design, and we cover that economic judgment in detail in Introducing unit-level traceability management in 2026. For SaMD, the same question reappears as “do we track by version, or all the way down to each issued licence,” but the skeleton of the reasoning is unchanged.
The software-specific difficulty is that it never stops changing
Software also brings a difficulty that physical products do not have. It keeps being updated after shipment.
With a physical product, the specification of a given unit is fixed the moment it ships. SaMD, by contrast, updates in the user’s hands. What was v2.3.1 yesterday is v2.4.0 today. How to handle the PI portion of the UDI in that situation is a genuine design question.
The more troublesome half of this is that many organizations have no clear internal definition of what counts as a release. Development teams increment a patch number with every bug fix, and a ledger that treats every one of those as a regulatory release will not survive. Development and quality assurance need to agree in advance on where the line falls between a change that should update the PI for regulatory purposes and a change that is merely an internal patch.
Four practical steps for medical device UDI compliance
Building on the above, here are the four steps a company holding SaMD (Software as a Medical Device) in risk classes 2 to 4 should actually work through.
Step 1 — inventory your products and determine scope
List every medical device you have registered in Thailand, with columns for whether it is SaMD, what its risk class is, and whether it is an existing registration or an upcoming new one. At this stage the products covered by the transition period separate cleanly from those that need compliance with no grace period. How long it takes depends on the number of products, but a company whose registration records are in order can finish in a few days.
Step 2 — design the DI and PI issuing rules and write them into an internal procedure
Decide what scheme you will use to assign DI to your products and what PI will contain. The items to settle are roughly these.
- Which format the DI will follow (choosing an internationally accepted format such as the GS1 GTIN is the practical answer)
- At what granularity DI is split across products (per product model, or per delivery form)
- What PI contains (version number, release date, per-licence serial, and so on)
- How large a change triggers a PI update (whether major, minor, or patch releases count as regulatory releases)
- Who owns the ledger (development or quality assurance)
Step 2 is not finished until that design is documented and lands as an internal procedure. Skip this and go straight to implementation, and later nobody will be able to explain the basis on which numbers were assigned in the first place.
Step 3 — build the ledger and put it into your systems
Following the issuing rules you designed, create the actual ledger. A spreadsheet is acceptable to start with, but because this is a document that gets updated at every release, it needs a mechanism that prevents missed updates. In parallel, implement the functionality that displays the UDI on the application’s startup screen, its settings screen, and the instructions for use.
The way you go about “building a ledger and putting it into a system” has a great deal in common with traceability construction generally, regardless of industry. Our four-layer model and the thinking behind a 90-day roadmap are set out in Traceability system build cost and how to proceed. Reading this article for the medical-device-specific regulatory requirements and that one for how to run the system build is the efficient division.
You will also, at some point, need to consider how the identifier is physically represented. SaMD itself is displayed mainly on screen, but delivery forms that involve physical media — boxed editions, licence cards — require a choice of barcode type. The criteria for choosing between QR codes, direct marking, and RFID are set out in Choosing between barcode, QR and RFID for traceability in 2026.
Step 4 — register master data in the UDI database
Submit your product master data to the Thai FDA’s UDI database. For companies that already hold UDI codes in markets such as the United States and the EU, this is reported to be the main remaining task for the Thai market. For a company starting from zero, completing steps 2 and 3 is the precondition for being able to submit at all.
The relationship between the four steps looks like this.
| Step | Primary owner | Deliverable | Prerequisite |
|---|---|---|---|
| 1 Product inventory | Regulatory affairs and quality assurance | Scope determination list | Collecting existing registration certificates and application files |
| 2 Issuing rule design | Quality assurance and development jointly | Internal procedure, DI and PI scheme | Step 1 |
| 3 Ledger build and system rework | Development, IT | Issuing ledger, UDI display function | Step 2 |
| 4 Database registration | Regulatory affairs | Submitted master data | Steps 2 and 3 |
This ordering cannot be rearranged. In particular, deferring step 2 and starting system rework first is a reliable way to generate rework.
Compliance cost and effort seen through a model case
From here we look at concrete numbers for how much effort compliance takes. “Company D” below is a fictional hypothetical company created for illustration. It is not a real case, and all effort and cost figures are our own estimates, not published statistics or survey results.
Company D’s situation
Company D is a Japanese medical device manufacturer with a subsidiary in Thailand. It develops a smartphone app that supports blood glucose management, has registered it with the Ministry of Public Health, and sells it in Thailand. The app has functionality that supports a physician’s treatment decisions, and it is a standalone software medical device with no accompanying hardware — in other words, SaMD. Its risk class is 2.
Company D also manufactures its own physical blood glucose meter, and that product has been under lot number control for years. On the app side, however, the development team merely manages versions through Git tags. Neither the issuing of a DI (fixed identifier) as a regulatory matter nor the concept of registration in a UDI database existed anywhere in the organization.
In other words, Company D holds solid traceability know-how for physical products, yet none of it is connected to the software side. Among medical device manufacturers that handle both hardware and software, this is an easy pattern to fall into.
Before and after
Here is what changed once Company D put a UDI issuing ledger in place.
| Item | Before (current state) | After (with the UDI issuing ledger in place) |
|---|---|---|
| Identifier design | Only the development team’s Git tags, e.g. v2.3.1. No fixed DI for regulatory use | One DI issued in GS1-compliant GTIN format. A ledger that appends a PI (version number plus release date) for each release |
| Where it is displayed | Only the version number, shown on the in-app settings screen | UDI (DI plus PI) shown on the label, the instructions for use, and the app startup screen |
| Database registration | Not done | Master data submitted to the Thai FDA’s UDI database |
| Internal owner | Doubled up with the development lead, with no standing as a regulatory responsibility | Quality assurance owns the UDI issuing ledger and updates it at every release |
The biggest change in this comparison is actually the bottom row. Deciding who holds the ledger does more to determine whether the practice survives than any technical implementation does. Leave it doubled up with the development lead and the ledger update slips during the crunch before a release, and before long it no longer matches reality.
Effort required for the initial work
Company D’s initial effort broke down as follows. All figures are our own estimates.
| Work item | Effort | Content |
|---|---|---|
| Issuing rule design | 3 person-days | Settling the DI and PI scheme, writing the internal procedure |
| System rework | 10 person-days | Adding UDI display to the app startup screen and the instructions for use |
| UDI database registration work | 2 person-days | Preparing and submitting master data |
| Total | 15 person-days | — |
The total is 15 person-days. If the work were outsourced to external system development and regulatory consulting, and assuming an engineer day rate of THB 30,000 to THB 50,000 per person-day, the cost lands at an estimated THB 450,000 to THB 750,000. This is our own estimate resting on an assumed day rate, and any real quotation will move with product configuration and the scope handed to the vendor.
What deserves attention in that breakdown is that 10 of the 15 person-days — two thirds — sit in system rework. Put the other way, understanding the regulation and designing the issuing rules is 3 person-days, and is not particularly heavy work. The heavy part is reflecting the rules you decided on into the application and the instructions for use.
The transition period can compress the rework cost
And this is where the practical leverage sits. If those 10 person-days of rework are timed to coincide with the next major version release, they can be carried out as part of that release’s development work, compressing the additional rework cost to close to zero — that is what the estimate supports. What can be compressed is the rework portion. The 3 person-days of issuing rule design and the 2 person-days of database registration remain necessary work whenever you do them.
Existing registrations of SaMD in risk classes 2 to 4 have a transition period of up to two years from the effective date of 20 June 2026, that is, until around June 2028. If even one major release is planned within those two years, folding the UDI display function into that release’s scope is the most economical route available.
That said, and to repeat the point, this transition period applies only to existing registrations of SaMD in risk classes 2 to 4. New registrations of SaMD in risk classes 2 to 4 are subject to the new requirements immediately from the effective date, so the compression tactic is not available to them. If a new product registration is coming up, UDI compliance has to be built into that development schedule from the outset.
Comparing three patterns of approach gives the following.
| Pattern | Situation it fits | Outlook for rework cost |
|---|---|---|
| Time it to a major release within the transition period | Existing registration, with a large development effort already planned before around June 2028 | The additional cost of the 10 person-days of rework compresses to close to zero. The 3 person-days of design and 2 person-days of registration remain |
| Run it as a standalone project within the transition period | Existing registration, with no large development effort planned | Roughly 15 person-days, THB 450,000 to THB 750,000 as a guide |
| Comply immediately alongside a new registration | SaMD in risk classes 2 to 4 that you are about to register | The registration schedule is the binding constraint, so starting early is mandatory |
Which pattern applies to you is settled automatically once you complete the step 1 product inventory. Start with the inventory.
Practical points for running this in Thailand
Even once the substance of the UDI marking obligation for SaMD (Software as a Medical Device) in risk classes 2 to 4 is clear, the stage of actually working through the procedures in Thailand throws up several issues that do not behave the way they would at home. Here are four points worth having in hand locally.
Point 1 — do not misidentify who the transition period covers
This has already been said more than once, but in terms of local project management this is where accidents happen most often. The transition period runs for up to two years from the effective date, and it applies only to existing registrations of SaMD in risk classes 2 to 4. New registrations of SaMD in risk classes 2 to 4 are subject to the requirements immediately from the effective date.
When you share a schedule between the Japanese head office and the local subsidiary, always state per product whether it is an existing registration or a new one. If the single sentence “we have until June 2028” is what travels on its own, the new registrations are the ones that fall behind.
Point 2 — confirm the display language requirements
On display language for SaMD (Software as a Medical Device) in risk classes 2 to 4 that falls in scope, the reported position is that home-use products require Thai-language display, while products intended for healthcare professionals may be displayed in Thai or English.
This has a direct effect on implementation. If the same app is offered both to consumers and to healthcare institutions, the display language requirement can differ by recipient. The safe move is to design the label and instructions-for-use equivalent screens, including the UDI display area, for multilingual output from the start of UI design.
Where a delivery form involves physical labels or inserts, every revision of displayed content brings a label version to manage. In factories where label issuing is still handled manually, keeping up with those revisions becomes a chronic load. The approach of systematizing label operations themselves and automating version control is covered in Label printing systems for the factory in 2026, which is worth reading alongside this article.
Point 3 — the practicalities of UDI database registration are still in flux
For SaMD (Software as a Medical Device) in risk classes 2 to 4 that falls in scope, submitting master data to the Thai FDA’s UDI database is the final step of compliance. However, industry media have reported practitioner comments that the Thai FDA’s electronic submission system does not yet handle UDI-related procedures. Because that comes from industry commentary rather than a primary source, it cannot be stated as settled fact, but it is worth preparing along the following lines.
- Assume the submission format is not final, and hold your master data internally in a structured form covering product name, DI, PI scheme, intended use, manufacturing date and so on
- Allow for the possibility that submission is not limited to electronic filing, and prepare materials that would also work for a paper submission
- Check the current status of the procedure periodically through local regulatory consultants or industry associations
The sensible posture, in short, is not to wait for the final step’s procedure to settle before starting on the ledger. Build the ledger first and be in a position to submit the moment the procedure firms up. With the ledger in hand, a change in submission format is manageable.
Point 4 — whether you already hold UDI abroad changes the workload dramatically
Among companies handling SaMD (Software as a Medical Device) in risk classes 2 to 4, those that already hold UDI codes in the United States, the EU, or other IMDRF-aligned markets are reported to find that the main remaining task for the Thai market is submitting master data to the Thai FDA’s UDI database. The DI scheme already exists and PI operations are already running, so there is little need to design anything new for Thailand.
By contrast, a company like the model case of Company D — present only in Thailand and Japan, with no UDI framework anywhere in the organization — has to start from building the ledger. What separates the two is whether step 2 issuing rule design and step 3 system rework are needed in full, and the effect on effort is not small.
Check first which of the two you are. If a group company sells similar products in the United States or the EU, there is a real chance you can reuse their issuing scheme. Before the Thai subsidiary starts its own study in isolation, it is well worth asking head office regulatory affairs whether a global UDI issuing scheme already exists.
Common mistakes
Here are the ways companies are likely to stumble when working through UDI compliance for SaMD (Software as a Medical Device) in risk classes 2 to 4 in Thailand.
Mistake 1 — telling the organization that “UDI is now mandatory for all medical devices”
This misunderstanding is easy to fall into. The notification covers SaMD (Software as a Medical Device) in risk classes 2 to 4 only. SaMD in risk class 1 is out of scope, and physical medical devices are not covered by this notification either. Physical products remain subject to the existing medical device registration and labeling rules, which apply separately.
Simply writing the first line of the internal announcement accurately — “the scope is SaMD in risk classes 2 to 4” — prevents both the pointless project launch and the missed compliance work.
Mistake 2 — treating it as a labeling job and handing it to a vendor
This is the case where UDI compliance is understood as a label design revision and passed to a printing company or a design agency. In substance it is identifier issuance and ledger operation design. Printing is the final stage. Nobody outside your organization can decide your issuing rules, and if they did decide them for you, your organization could not operate them.
Mistake 3 — pushing ahead with implementation without naming a ledger owner
The system rework is finished, but nobody has been assigned to update the ledger at each release. Six months later the ledger and the actual versions have diverged, and there is no way to explain the discrepancy when the authority asks. Moving ownership to quality assurance in the Company D model case is exactly what avoids this outcome.
Mistake 4 — piping development patch numbers straight into the PI
This is the design that fails to distinguish regulatory releases from internal patches and pours Git tags directly into the ledger. The record count balloons and updates fall behind. Decide in a written procedure, in advance, what granularity of change constitutes a PI update.
Mistake 5 — reading the two-year transition period as two years of doing nothing
It is true that existing registrations of SaMD in risk classes 2 to 4 have a transition period of up to two years, but it is a preparation window. And, as the estimate above shows, timing compliance to a major release within that window can compress the additional cost of the 10 person-days of rework to close to zero — used deliberately, the window has real economic value. Spend two years doing nothing and you end up stacking roughly 15 person-days of work into a standalone project just before the deadline.
Mistake 6 — assuming new registrations are covered by the transition period
Alongside mistake 1, this is the misreading with the largest consequences. New registrations of SaMD in risk classes 2 to 4 are subject to the new requirements from the effective date. The worst-case scenario is discovering just before filing that no UDI is ready, and having the registration application itself stall.
Frequently asked questions
Does Thailand’s UDI requirement apply to all medical devices sold in Thailand
No. The notification that took effect on 20 June 2026 covers SaMD (Software as a Medical Device) in risk classes 2 to 4 only. SaMD in risk class 1 is out of scope. Physical medical devices themselves are also not covered by this notification, and remain subject to the existing medical device registration and labeling rules, which apply separately.
Where does the UDI for SaMD have to be displayed
For SaMD (Software as a Medical Device) in risk classes 2 to 4 that falls in scope, the Thai notification lists the items to appear on the label as the product name and intended use, the lot number, version or serial number, and the manufacturing date and expiry date. In the model case of Company D — a fictional hypothetical company — the configuration displays the UDI (DI plus PI) on the app startup screen in addition to the label and the instructions for use. For a software product, designing the display to include the screens the user actually sees is the practical approach.
How is medical device traceability different from UDI
Traceability is the general concept of being able to track where a product or part came from and where it went. UDI is the international convention on how identifiers are assigned so that such tracking can work at all. Internationally, UDI is generally understood as consisting of two elements, DI (the fixed identifier) and PI (the variable data), and that structure is the same reasoning used in factory lot control and serial control. For the design procedure of traceability as a whole, see Traceability system build cost and how to proceed.
What is needed for UDI database registration
For SaMD (Software as a Medical Device) in risk classes 2 to 4 that falls in scope, you submit master data to the Thai FDA’s UDI database. As a precondition, the DI and PI issuing rules must be settled and the identifiers for each product organized into a ledger. Note also that industry media have reported practitioner comments that the Thai FDA’s electronic submission system does not yet handle UDI-related procedures, so we recommend confirming the current state of the submission procedure through a local regulatory specialist.
We already hold UDI codes in the United States and the EU — what do we need to do in Thailand
For SaMD (Software as a Medical Device) in risk classes 2 to 4 that falls in scope, companies already holding UDI codes in the United States, the EU, or other IMDRF-aligned markets are reported to find that the main remaining task for the Thai market is submitting master data to the Thai FDA’s UDI database. Because the issuing scheme already exists, the workload is dramatically lighter than for a company building a ledger from scratch. Start by checking whether head office or a group company already has an issuing scheme in place.
When does the two-year transition period end, and which products does it apply to
Labels and instructions for use for existing registrations of SaMD in risk classes 2 to 4 that complied with the 2020 notification may reportedly continue to be used for up to two years from the effective date of 20 June 2026, that is, until around June 2028. This transition period applies to existing registrations only. New registrations of SaMD in risk classes 2 to 4 are subject to the new requirements from the effective date.
Does an SaMD label have to be in Thai
For SaMD (Software as a Medical Device) in risk classes 2 to 4 that falls in scope, the reported position is that home-use products require Thai-language display, while products intended for healthcare professionals may be displayed in Thai or English. If the same product is offered both to consumers and to healthcare institutions, the requirement can differ by recipient, so it is safer to design for switchable multilingual display.
How much effort does UDI compliance take
In the case of Company D, the fictional hypothetical company in this article holding one SaMD product in risk class 2, our own estimate came to 3 person-days for issuing rule design, 10 person-days for system rework, and 2 person-days for UDI database registration work, for a total of 15 person-days. If outsourced, the cost guide is THB 450,000 to THB 750,000, assuming an engineer day rate of THB 30,000 to THB 50,000 per person-day. It varies considerably with the number of products and the management structure already in place.
Summary
We have worked through the UDI marking obligation that took effect in Thailand on 20 June 2026 for SaMD (Software as a Medical Device) in risk classes 2 to 4, from a practical standpoint. Here are the points to carry away.
First, this notification covers SaMD (Software as a Medical Device) in risk classes 2 to 4 only. SaMD in risk class 1 is out of scope, and physical medical devices themselves are not covered by this notification either — they remain subject to the existing medical device registration and labeling rules, which apply separately. The reading that “UDI is now mandatory for medical devices in general” is simply wrong.
Second, the substance of compliance is not putting a barcode on a label. It is holding an internal ledger that issues and manages DI (the fixed identifier) and PI (the variable data). You build on the international framework in which UDI consists of two elements, DI and PI, and design so as to satisfy the label content items the Thai notification specifies for SaMD (Software as a Medical Device) in risk classes 2 to 4.
Third, operating that ledger has the same structure as lot control and serial control on the shop floor. A company that has run traceability for physical products can carry that know-how straight across to software version management.
Fourth, existing registrations of SaMD in risk classes 2 to 4 have a transition period of up to two years from the effective date, while new registrations of SaMD in risk classes 2 to 4 are subject to the new requirements from the effective date. Do not confuse the two. If a major release is planned inside the transition window, the estimate supports including the UDI display implementation in that release and compressing the additional cost of the 10 person-days of rework to close to zero.
There is one thing to do first. List the products you have registered in Thailand and fill in, for each, whether it is SaMD, what its risk class is, and whether it is an existing or a new registration. That alone determines whether you have a grace period or not.
Whether your products fall in scope, how to design the DI and PI issuing ledger and which department should own it, how it connects to your existing production management system and label printing setup — the answers to all of these shift with product configuration and internal structure. TOMAS TECH supports Japanese manufacturers in Thailand in building traceability and physical-item management, and we regularly work with companies that want to use a regulatory deadline as the occasion to reorganize their internal identification scheme. It is entirely fine if you are at an early stage with requirements still unsettled — if you would like to work through the situation together, please get in touch through our contact page.
References
- Tilleke and Gibbins, Thailand Introduces UDI Labeling Requirements for Software as a Medical Device
- Mondaq, Thailand Introduces UDI Labeling Requirements For Software As A Medical Device
- Siam Development, industry commentary including practitioner remarks on Thai FDA UDI procedures
- Thai FDA, Food and Drug Administration of Thailand official site
- IMDRF, International Medical Device Regulators Forum official site
- GS1 Healthcare, identification standards for the healthcare sector
- Ratchakitcha, Thai Government Gazette official site
