What is the difference between Basic UDI-DI and UDI-DI?
A Basic UDI-DI groups devices with the same intended purpose, risk class, and essential design and manufacturing characteristics. A UDI-DI identifies the specific model, variation, or version. The Commission’s identifier concept infographic describes the relationship; one Basic UDI-DI can connect several UDI-DIs.
- Basic UDI-DI
- The group-level identifier used in the database and relevant documentation.
- UDI-DI
- The device identifier for a specific model, variation, or version.
- UDI-PI
- The production-identification part of a UDI, distinct from the device identifier.
- Package UDI-DI
- An identifier associated with a packaging level where applicable.
These distinctions matter because the records form a structure, not a flat list of commercial names. A group decision affects how specific devices relate to their documentation and attributes. Start with the regulatory meaning of the group, then map the individual records that belong to it.
Can a product family become one Basic UDI-DI group?
Only when it satisfies the applicable grouping criteria. A shared brand, sales category, or catalog heading does not establish a common intended purpose, risk class, or essential design and manufacturing characteristics. The official categorization guidance explains the group-level characteristics.
For a practical review, write down why each proposed group belongs together. Identify the source document for the intended purpose and classification, then ask the appropriate technical and regulatory owners to confirm the relevant design and manufacturing characteristics. This internal rationale helps expose assumptions before the structure is converted into device records.
Do not group solely to reduce the number of entries. Likewise, do not create a separate group for every sales variant without checking whether that distinction is relevant. The aim is a defensible structure supported by the applicable rules and documentation, not the largest or smallest possible number of groups.
Is the Basic UDI-DI the code printed on the label?
Do not treat the Basic UDI-DI as interchangeable with the UDI carrier or the UDI-DI used in labeling. It serves a grouping and documentation function. Labeling requirements, production identifiers, packaging levels, and device-specific exceptions need their own assessment under the applicable regulation and issuing-entity rules.
When gathering data, give each identifier its own column and an explicit source. A generic column headed “UDI” invites accidental substitution of a group identifier, a product identifier, or a code extracted from a package. Preserve the issuing entity and the exact value, including any meaningful formatting, while checking the applicable entry rules.
Ask the responsible team to reconcile the identifier mapping with the documents in which those identifiers are used. A clean upload file can still be based on an incorrect mapping. Technical validation should follow, rather than replace, the initial review of what each identifier represents.
What changes for legacy devices?
Do not assume every legacy device must be converted into the same identifier path as a Regulation device. EUDAMED has specific guidance for legacy-device identifiers, including the EUDAMED DI. The Commission’s UDI/Device registration page links the legacy datasets and identifier guidance.
Separate the regulatory route before preparing identifiers. Record whether a device is being managed under an applicable Directive transition or under the MDR or IVDR. If a model appears in more than one regulatory context, ask a qualified professional to confirm the relationships and the appropriate records. Do not infer the route from age alone.
This is particularly useful in a portfolio migration. Preserve links between the source product, its regulatory evidence, the identifiers used, and the destination record. A copied commercial name should not be the only means of recognizing whether two rows describe the same device, related devices, or different regulatory records.
Which data should you prepare for EUDAMED?
Start with the current dataset for the relevant device category, then map each required or conditional field to an authoritative internal source. The Commission publishes separate datasets for MDR, IVDR, and legacy-device routes. Use those datasets and the current Information Centre documentation rather than a generic spreadsheet assumed to fit every product.
The official UDI/Device page also identifies the European Medical Devices Nomenclature, EMDN, used for registration. Assign an owner to nomenclature and classification decisions. A convenient commercial description is not a reason to choose a code without checking its meaning and applicability.
Create a data dictionary for the project: field name, applicable records, source, owner, allowed value, and evidence of review. This is an implementation recommendation, not an additional statutory filing. It gives the team a way to distinguish missing information from a genuinely inapplicable field and reduces repeated questions during preparation.
Which structuring mistakes should you look for?
Look for identifiers placed in the wrong columns, commercial families used without a grouping rationale, and legacy records forced into a Regulation-device template. These are checks to perform, not claims about how frequently manufacturers make mistakes. A short representative sample can reveal whether your mapping approach is consistent.
Also review the relationship between basic groups, device identifiers, and packaging identifiers. Ask whether two rows are true duplicates or distinct records with similar names. Maintain an exception log where the decision is unresolved. A blank field filled with an invented value may make a file appear complete while hiding the question the team actually needs to answer.
Should you use manual entry, XML bulk upload, or M2M?
EUDAMED supports all three methods. The Information Centre’s modes-of-input page gives indicative volume guidance: the interface up to 100 devices, XML bulk for roughly 100–1,000, and M2M above 1,000. These are selection tips, rather than a statutory requirement to use M2M at a particular size.
The official data-exchange guidance distinguishes manual interface entry, semi-automated XML upload, and automatic system-to-system exchange. Consider recurring changes, existing source systems, implementation effort, and who will support the process. A one-time backlog and a continually changing portfolio can justify different choices even when their record counts are similar.
No method fixes an incorrect grouping or missing source data. Compare the total preparation, submission, error-correction, reconciliation, and maintenance work. Our M2M versus manual guide develops that decision without treating volume as the only criterion.
How should you verify that the work is complete?
Reconcile the in-scope source inventory with the resulting records and preserve unresolved exceptions. A successful file transmission is not, by itself, a complete portfolio reconciliation. Ask what the submission response shows and which records have the expected final state.
Plan the handover before the initial submission. Keep the identifier map, approved source-data version, correction history, and ongoing record owner together. That lets the next update build on the reviewed structure rather than starting with an unexplained export. For an initial orientation, request a free registration check; for professional data-structuring work, request a specialist introduction.