To translate Unique Device Identification information accurately, a translator must separate the language used to describe a medical device from the identifiers used to identify its model, production unit, packaging and regulatory record. Labels, instructions for use, certificates, recall notices, hospital inventory systems and regulatory databases can place UDI-DI, UDI-PI, Basic UDI-DI, lot numbers, serial numbers and device descriptions together. The descriptive language may need translation; the identifiers normally must remain exact.
This guide explains how to translate medical-device documents without changing UDI-DI, UDI-PI, Basic UDI-DI, GUDID records or machine-readable UDI carriers. It answers a distinct translation search intent: what each UDI component identifies, which fields may be localized, why the FDA’s Device Identifier and Production Identifier must not be collapsed, how the EU Basic UDI-DI differs from the label-level UDI-DI, and how multilingual device information can stay linked to the same regulated product.
The working rule is translate the human-readable medical-device information, preserve the governed identifier, keep the regulatory system visible, and verify every relationship after export. FDA guidance describes the UDI as a numeric or alphanumeric code with a fixed Device Identifier and conditional Production Identifier information; the EU likewise separates UDI-DI and UDI-PI while also using Basic UDI-DI as a higher regulatory grouping key. This specialist owner extends the Master Art of Translation architecture without becoming a broad medical-translation hub.
1. UDI is identity infrastructure, not a translated label
A Unique Device Identifier can appear as plain text, a barcode, a two-dimensional symbol, an RFID representation or another permitted carrier depending on the system and device. Its purpose is traceability and identification. Translation changes explanatory words around the UDI; it does not create a target-language version of the UDI.
The first production control is therefore classification. Before content enters machine translation or human translation, identify UDI-related fields as protected structured data. This reduces the risk that punctuation, spacing, case or application identifiers are changed because they resemble normal text.
2. UDI-DI identifies the device model or version layer
The Device Identifier is the fixed portion of the UDI. FDA describes it as the mandatory fixed portion that identifies the labeler and the specific version or model of a device. It belongs to product identity rather than production history. A translation should therefore preserve the UDI-DI exactly while localizing the device name and model description only where the regulatory and labeling rules permit.
Do not derive a UDI-DI from the translated device name. The same regulated device can have localized names across markets while retaining an identifier assigned through an accredited or designated issuing system.
3. UDI-PI identifies production-specific information
The Production Identifier is the variable portion associated with production details when those details are included on the label. Depending on the regulatory system and product, production identifiers can include lot or batch number, serial number, expiration date, manufacturing date and other defined production information. These values connect the device to manufacturing and lifecycle events.
Translate the labels “lot,” “serial,” “expiration” and “manufacture date,” but preserve the actual lot, serial and date values according to the governing formatting policy. Do not merge all production information into one generic code field.
4. UDI-DI and UDI-PI answer different questions
UDI-DI answers, broadly, “which device model or version is this?” UDI-PI answers, broadly, “which production unit, lot or production context is this?” This distinction matters in recalls. A safety action can affect an entire model, selected lots, specific serial numbers or a combination of criteria.
A translation that preserves the UDI-DI but changes the serial number can misidentify the affected unit. A translation that preserves a serial number but attaches it to another UDI-DI can create an equally serious error. Identity QA must protect relationships, not only tokens.
5. Basic UDI-DI is an EU regulatory grouping key
The European Union uses Basic UDI-DI as a higher-level regulatory identifier. It groups devices that share defined core characteristics and serves as a key across EUDAMED and regulatory documentation. It is distinct from the UDI-DI printed or encoded at the individual commercial-device level.
Translators should therefore never replace UDI-DI with Basic UDI-DI because one “looks more official.” Each belongs to a different level of the data model. Keep both when the source provides both.
6. Basic UDI-DI does not belong on the ordinary trade-item label
European Commission guidance distinguishes Basic UDI-DI from the label-level identifier. Basic UDI-DI functions in regulatory documentation and databases rather than as the barcode scanned from the trade item. This makes it especially easy for non-specialists to confuse the two when translating certificates and declarations.
Use field-aware terminology: Basic UDI-DI, UDI-DI and package UDI-DI should remain visibly distinct in the target. If the target language uses explanatory parentheticals, add them outside the protected identifier value.
7. GUDID stores DI-level reference data, not the PI itself
The FDA’s Global Unique Device Identification Database is a reference catalog for devices with UDIs. FDA guidance states that GUDID contains the Device Identifier portion used as the key to obtain device information, while it does not store the production identifier values themselves. It can store flags indicating which PI attributes appear in the UDI.
This distinction is important when translating database documentation. Saying that GUDID contains every serial number or lot number would be incorrect. Translate the database description precisely and preserve the DI as the lookup key.
8. AccessGUDID is a public retrieval layer
AccessGUDID provides public search access to device-identification information from GUDID. A translator can use it to verify device names, company information and DI records, but should not treat it as a source of patient identity. FDA explicitly notes that the public database does not contain information about who uses a device.
Use AccessGUDID as a device-reference resource, not a clinical-record system. In target text, keep device identity, patient identity and healthcare event identity separate.
9. The UDI carrier is not the same thing as the UDI concept
The carrier is the representation through which the UDI is presented for human reading and automatic data capture. The underlying identifier is the identity data; the barcode or other carrier is a method of encoding and transporting that data. Translation may affect surrounding label text but should not casually rebuild the carrier.
If a label is re-created for another market, barcode regeneration belongs to a validated labeling process using authoritative source data. It should not be generated by copying characters out of a translated PDF.
10. Human-readable and machine-readable forms must agree
UDI systems are designed so the identifier can be available in human-readable form and through automatic identification and data capture. A translation project must therefore verify both layers. A visible UDI can be correct while a barcode still contains stale template data; the reverse can also happen.
Release QA should scan the final carrier and compare its decoded content against the printed identifier and approved source data. Visual proofreading alone cannot confirm barcode payload integrity.
11. Issuing-agency syntax is part of the identifier system
UDI frameworks rely on recognized issuing entities or agencies whose standards determine syntax and data-carrier conventions. The same regulatory concept can therefore appear through different standardized formats. A translator should not normalize all UDIs into one preferred visual style unless the regulated labeling process explicitly requires that transformation.
Preserve the source identifier and its data-carrier syntax. Translate explanatory documentation about the issuing system, not the machine syntax itself.
12. Application identifiers and data delimiters are machine syntax
Some UDI carriers use application identifiers or data identifiers to distinguish device, lot, serial, expiration and other fields. Those characters are not abbreviations to be translated. They instruct scanners and software how to interpret the following data.
If a target-language label requires a human-readable description of what each field means, provide the description outside the encoded data. Never replace an application identifier with the first letter of the target-language word.
13. Lot number is not the UDI-DI
Lot or batch number is production-specific information. Multiple units with the same UDI-DI can share a lot, and one UDI-DI can appear across many lots over time. Translators should therefore retain explicit lot terminology and avoid calling every alphanumeric value on a device label “the UDI.”
In recall translation, lot boundaries can determine scope. Preserve ranges, prefixes, suffixes and excluded values exactly.
14. Serial number is unit-level identity
Where serial numbers are part of the production-identifier information, they distinguish individual units. A serial number must not be translated, rounded, reformatted or copied from translation memory. It should be populated from the current source record.
Serial numbers are especially vulnerable in repetitive service reports because every sentence around them may be identical. Treat them as variables rather than memorized content.
15. Expiration dates need controlled date handling
Expiration information can be part of UDI-PI and can also appear as human-readable labeling. Regulatory date formats and data-carrier encodings may be standardized differently from consumer-facing dates. Translators should not apply ordinary locale date formatting blindly to machine-readable production data.
If the project requires a localized display date, retain the original encoded value separately and verify that both represent the same calendar date. Avoid ambiguous numeric date formats where regulation or safety requires clarity.
16. Manufacturing date is not expiration date
Both may appear on labels and in production identifiers, but they answer different questions. A translation that swaps the terms can create a safety problem even when the numeric date remains correct. Terminology review should therefore treat manufacturing, packaging, sterilization and expiration dates as distinct concepts.
Use the source field, symbol and regulatory context together. Never infer the date type only from where it appears on the label.
17. Software as a Medical Device can use version information
UDI guidance can include software-version information within production-identification practices, depending on jurisdiction and device type. Software version strings are identifiers, not prose. Translate release notes and user guidance while preserving the version that ties the target documentation to the regulated software build.
This prevents a common localization failure: a manual translated for version 5.2 accidentally shipped with version 5.1 screenshots or identifiers because the version string was treated as decorative text.
18. Package-level identifiers need hierarchy
Different packaging levels can carry distinct identifiers under UDI systems. A single device, a box of several units and a larger package can therefore have related but different identification records. Translation should preserve each package-level identifier and translate package descriptions without flattening the hierarchy.
A warehouse target that maps the carton UDI-DI onto each individual device can create inventory and recall errors. Identity QA must understand package level.
19. Shipping container identity is not automatically UDI identity
Logistics systems can add SSCC, shipment, purchase-order or warehouse identifiers around medical-device packages. Those codes belong to supply-chain processes and should not be mistaken for UDI-DI. Keep regulatory device identity and logistics container identity in separate fields.
The target language can explain both, but a receiving system must still know which code identifies the regulated device and which code identifies the shipment.
20. Catalogue number is another manufacturer identifier
Manufacturers often use catalogue, reference or product numbers in addition to UDI-DI. These values can be familiar to hospitals and buyers, but they do not replace the UDI system. Translate the label “catalogue number” according to established terminology while preserving the code itself.
If the device name changes across languages, the catalogue number and UDI-DI provide two independent anchors that help confirm the intended product.
21. GMDN terminology is classification, not device identity
Medical-device databases can include Global Medical Device Nomenclature information. A nomenclature code describes a device category or concept rather than one specific product unit. It should not be substituted for UDI-DI. Classification helps readers understand what kind of device something is; UDI identifies the regulated product record.
Translate the nomenclature description only under the rules of the relevant terminology system. Preserve the code so that multilingual descriptions still point to the same concept.
22. Device name is translatable but regulated
Device names, model names and trade names can be subject to regulatory and branding controls. A natural-sounding translation is not automatically acceptable if it changes intended purpose, risk meaning or registered product naming. Use approved terminology and market-specific labeling content.
The UDI-DI gives translators a stable identity anchor while the approved target-language naming is managed through the labeling process.
23. Intended purpose is not encoded by the UDI alone
UDI helps identify the device, but it does not replace the regulatory statement of intended purpose or indications for use. Translating those statements requires subject-matter precision. Do not infer clinical claims from the identifier or from database category names.
Identity and meaning cooperate: the UDI tells you which device record you are reading; the approved text tells you what the manufacturer claims the device is for.
24. Risk class is another regulatory field
Device risk classification is governed by jurisdictional rules and is not contained in a simple universal reading of the UDI. Translate class descriptions and regulatory references accurately, but do not generate or alter the UDI based on perceived risk.
EU Basic UDI-DI grouping can be associated with devices sharing core characteristics including risk class, but that does not make the Basic UDI-DI a plain-language risk code.
25. Sterility status is separate from identity
Labels can state sterile condition, sterilization method or requirements for maintaining sterility. Those safety statements must be translated accurately. The UDI remains the identifier and should not be altered to make the target label “match” a translated sterility phrase.
If different sterile and non-sterile configurations have different identifiers, take those assignments from the approved device data rather than inventing a mapping from the words.
26. MRI safety terminology requires controlled translation
Databases and labels may contain MR Safe, MR Conditional or MR Unsafe information. These are safety-critical concepts with established terminology. Translate them according to approved standards and device labeling while preserving the UDI that identifies the exact device configuration.
Never transfer an MRI status from one UDI-DI to a similar-looking model. Similar names are not proof of identical safety characteristics.
27. Recall translation is where identity errors become safety errors
Medical-device recalls and field safety corrective actions can be scoped by UDI-DI, lot, serial number, date range and market. The translation must preserve every inclusion and exclusion criterion. A beautiful target that broadens or narrows the affected population is unsafe.
Create a recall identity table before translating: device identifier, affected lots, serial ranges, package levels, dates and market. Then verify that the final target reproduces the same set.
28. Adverse-event reports use multiple identifiers
Postmarket reports can contain UDI-DI, lot, serial, patient-event references, report numbers and facility identifiers. Each belongs to a different identity layer. Translate the event narrative carefully but preserve regulated and case-management identifiers exactly.
Do not expose patient information merely because a device record is public. Device identity and personal health information must remain conceptually and operationally separate.
29. Certificates and declarations can use Basic UDI-DI
In the EU system, Basic UDI-DI appears in important regulatory documentation such as declarations of conformity and certificates. When translating those documents, preserve the Basic UDI-DI exactly and distinguish it from every trade-item UDI-DI listed elsewhere.
A target document should remain auditable back to the same certificate, device family and database record. That is more important than making the identifier visually fit surrounding prose.
30. EUDAMED device registration is structured data
European device registration uses structured fields, identifiers and regulatory relationships. Translating screenshots or user guidance about EUDAMED is different from translating actual database payloads. Interface instructions can change language; field names required by integrations, identifier values and controlled lists should remain governed by the system.
As of 28 May 2026, the EU UDI/Devices module entered mandatory use under the applicable transitional framework, making correct identifier handling even more operationally important for current European device workflows.
31. FDA and EU UDI terminology overlaps but is not identical
Both systems use UDI-DI and UDI-PI concepts aligned with international principles, but regulatory databases, grouping identifiers, compliance requirements and implementation details differ. A world-facing translator should never assume that a US GUDID field maps one-to-one to an EU EUDAMED field simply because both contain “UDI.”
State the jurisdiction or database when discussing requirements. Translate common concepts consistently while preserving system-specific terms where they carry legal meaning.
32. IMDRF provides the international conceptual bridge
The International Medical Device Regulators Forum has published UDI guidance used as an important international reference. It helps translators understand the conceptual architecture across jurisdictions: device identifier, production identifier, carrier and database relationships. It does not erase jurisdiction-specific rules.
Use IMDRF concepts to orient terminology, then verify the actual target-market requirement through the relevant regulator.
33. Direct marking is not ordinary translated printing
Some reusable devices may require the UDI to be marked directly on the device under applicable rules. Direct marking is a manufacturing and regulatory operation. Translation of accompanying words does not authorize changing, replacing or re-etching the identifier.
Where the physical device has limited space, localization decisions belong to validated labeling and regulatory processes. The translator supplies accurate target text; engineering and regulatory teams control the marking.
34. Symbols can reduce language but do not remove translation work
Medical-device labels use standardized symbols for manufacturer, dates, sterility and other concepts. Symbols can reduce the amount of text needing translation, but the surrounding instructions, legends and market requirements still need careful handling.
Do not confuse a symbol with an identifier. A symbol communicates a concept; the UDI identifies the device. Both can be machine-stable, but they have different functions.
35. Instructions for use should reference the same device identity
A translated IFU can cover one device, a family or several variants. Verify that model references, UDI-DI ranges or catalogue numbers in the target still match the approved scope. Do not let a translation template bring in identifiers from a sibling device.
The safest document architecture stores identity metadata outside the prose and inserts it from the controlled product record at publication time.
36. Electronic IFU links need identity consistency
Electronic instructions can use URLs, QR codes and product identifiers to route users to the correct document. Translate the landing-page content, but preserve the product-routing identifier and verify that every locale opens the correct version for the same device.
A localized link that opens another model’s instructions is an identity failure even when both pages are perfectly translated.
37. Hospital inventory systems need stable UDI fields
Hospitals can scan UDI data into inventory, procedure and asset-management systems. Local interface language can vary, but the captured identifier must remain machine-consistent. This supports stock control, recall response and traceability.
Translation teams working on hospital software should protect UDI fields in forms, database exports and test data. Labels such as “Device Identifier” may be localized; field semantics should not.
38. Procurement documents can mix UDI and commercial references
Purchase orders can contain supplier catalogue numbers, UDI-DI, internal material codes, tender item numbers and contract references. Treat each as its own namespace. Translate product descriptions and commercial terms while preserving codes needed to order the correct device.
When a product is substituted, do not assume the same UDI-DI applies. Substitution is a procurement and clinical decision, not a translation operation.
39. ERP and master-data localization should keep one canonical device record
Enterprise systems should ideally store one canonical device identity with localized names and descriptions around it. Duplicating the device record for each language creates opportunities for identifiers, regulatory attributes and lifecycle status to drift.
The UDI-DI becomes an anchor across languages while descriptions, market names and translated documentation can be versioned independently.
40. Spreadsheet risks are substantial
UDI values can be numeric or alphanumeric. Spreadsheet software may remove leading zeros, convert long values to scientific notation, reinterpret dates or alter barcode-related strings. Import identifier columns explicitly as text and lock them from language-side formatting.
Also protect row relationships. A perfectly preserved UDI attached to the wrong device description is still wrong.
41. CSV exports need schema documentation
Columns should distinguish Basic UDI-DI, UDI-DI, package UDI-DI, lot, serial, expiration, catalogue number and local database keys. A single “UDI” column may be inadequate if the file combines several levels of identity.
Schema clarity reduces translation risk because linguists can see which columns are protected and which carry descriptions that require target-language work.
42. XML, JSON and HL7-style submissions are machine contracts
Regulatory or healthcare integrations use structured data with fixed element names, codes and identifiers. Translating the XML tags or JSON keys can break validation. Translate user documentation, comments or designated narrative fields only.
Where a standard supports coded concepts plus display text, preserve the code and localize the display under the standard’s rules. This pattern is safer than replacing the concept code with translated words.
43. OCR is a weak source for barcode-critical data
OCR can misread digits, parentheses, separators and application identifiers on device labels. If a machine-readable UDI carrier exists, scan or decode it with validated tools rather than relying only on visual transcription.
Use OCR to accelerate discovery, not to establish identity without verification. One character can change a lot or serial number and therefore change recall scope.
44. Machine translation should mask UDI data
Automated translation can leave many codes untouched, but production safety needs stronger controls than probability. Protect UDI-DI, UDI-PI components, lot, serial and barcode syntax as placeholders. Translate only the narrative around them.
After translation, compare the complete set of identifiers source-to-target. Every expected token should appear exactly where the workflow requires it.
45. Translation memory can propagate stale device identifiers
Medical labeling is repetitive, which makes translation memory valuable. The same repetition makes stale product-specific data dangerous. A segment from an older model can contain a previous UDI-DI, lot example or catalogue number.
Configure product identifiers as variables and populate them from the current master data. Never trust a 100 percent linguistic match to provide current identity.
46. Generative systems must not create missing identifiers
If a source label is blurred or a UDI value is truncated, a language model may be tempted to complete a pattern. That is unacceptable for regulated identity. Preserve the uncertainty and escalate to the authoritative label, database or regulatory record.
Fluency is not evidence. A syntactically plausible identifier can still be entirely wrong.
47. Search intent: how do I translate a UDI?
You normally do not translate the UDI value. You translate the words that tell the reader what the identifier means: Device Identifier, Production Identifier, lot, serial, expiration, model and regulatory explanations. The UDI remains the cross-language anchor.
If a target system requires a different regulatory identifier, that is a regulatory-market conversion project, not ordinary linguistic translation.
48. Search intent: what is the difference between UDI-DI and UDI-PI?
UDI-DI is the fixed device-identity portion; UDI-PI contains variable production information when required and present. The exact PI elements depend on the product and governing rules. Translators should preserve both and use target-language labels that maintain the fixed-versus-production distinction.
This distinction is more useful than treating the entire printed barcode string as one mysterious number.
49. Search intent: what is Basic UDI-DI?
Basic UDI-DI is an EU regulatory grouping identifier used as an important key for device information and documentation. It groups related devices sharing defined core characteristics and is distinct from the label-level UDI-DI.
Do not print or translate a Basic UDI-DI as if it were the consumer-scannable device code. Keep the data layer explicit.
50. Search intent: can I find a UDI in GUDID?
FDA’s public tools allow lookup of device information by Device Identifier and other fields. Remember that GUDID stores DI-level device information, not the individual PI values for every lot and serial. Use the database for what it is designed to provide.
When translating a database result, preserve the DI and localize the descriptive fields without implying that the public record identifies a patient or a specific implanted unit.
51. Worked example: multilingual device label
A device label contains product name, sterile status, catalogue number, UDI carrier, lot and expiration date. The target localizes the approved product and safety language, preserves every identifier and production value, and regenerates the final barcode only through the validated labeling system.
QA scans the finished carrier, compares its decoded payload to the source master data and verifies that the visible human-readable string matches.
52. Worked example: field safety notice
A manufacturer issues a notice affecting two UDI-DIs and selected lot ranges. The translation explains the hazard, corrective action and return process. It copies the UDI-DIs and lot ranges exactly, preserving exclusions and date boundaries.
A reviewer then checks whether the target describes exactly the same affected population. This is the core identity test for safety communication.
53. Worked example: EU declaration of conformity
A declaration lists the manufacturer, device family, Basic UDI-DI and applicable regulations and standards. The target translates the legal and technical text but preserves the Basic UDI-DI and cited standard identifiers. It does not replace the Basic UDI-DI with a package barcode value.
The final target remains traceable to the same EUDAMED device family and conformity documentation.
54. Error clinic: right identifier, wrong hierarchy
A common error is not a mistyped code but a correctly copied code placed in the wrong field: Basic UDI-DI in UDI-DI, carton DI in unit DI, or lot in serial number. Character comparison will not catch this.
Use schema-aware QA that validates the role of every identifier, not only its spelling.
55. Error clinic: localized dates break production data
Another failure occurs when software converts an encoded date into a localized display and then writes that display back into the machine field. The human-facing date may be correct while the barcode payload becomes invalid.
Maintain separate raw and display layers. Locale formatting belongs in presentation, not in the authoritative production identifier.
56. Error clinic: stale barcode from a template
Label templates can preserve an old barcode graphic while the visible text has been updated. This is why visual proofreading must be supplemented by scanning the final label. The image itself can contain the wrong device identity even when every surrounding word is accurate.
Validated publishing should generate carriers from current structured data, not from manually pasted images.
57. Vocabulary that translators should control
Core terms include unique device identifier, device identifier, production identifier, Basic UDI-DI, labeler, manufacturer, model, version, lot, batch, serial number, expiration date, manufacturing date, direct marking, packaging level, issuing entity, data carrier, automatic identification and data capture, recall and field safety corrective action.
Vocabulary accuracy helps readers understand the identifier hierarchy. For broader word-learning work, use the protected Vocabulary Learning Hub; this article remains focused on medical-device identity.
58. How English wording can hide the hierarchy
English documentation often shortens several concepts to “UDI,” even when the immediate context means UDI-DI, the full UDI carrier or the UDI system. Translators should expand mentally before choosing the target term. The surrounding sentence, field label and database schema reveal which layer is meant.
This is where the broader How English Works ecosystem matters: accurate syntax and terminology interpretation support technical identity, but the governing regulatory schema ultimately decides what each label denotes.
59. A practical preflight method
Before translation, extract every Basic UDI-DI, UDI-DI, lot, serial, date field, catalogue number and machine-readable carrier reference. Classify each by jurisdiction and hierarchy. Lock protected tokens. Translate only approved narrative fields. After layout, rescan or reparse machine-readable carriers and compare the complete identifier set to the source.
This preflight converts a complex medical-label translation into a manageable combination of language work and deterministic data validation.
60. Reference verification route
For United States requirements, use the FDA’s UDI Basics and GUDID resources. For international concepts, consult IMDRF UDI guidance. For European implementation and Basic UDI-DI, use the European Commission’s UDI and EUDAMED guidance. Always verify the target jurisdiction because compliance details differ.
61. Final rule: translate meaning, preserve regulated identity
Medical-device translation succeeds when the target becomes understandable without changing which device, model, package, lot or serial unit the text refers to. UDI-DI, UDI-PI and Basic UDI-DI give that identity structure; accurate language makes the structure usable to people.
The central discipline is the same across every language: translate what humans need to understand, protect what systems need to recognize, and verify the relationship between the two before release.