- Binding source for EUDAMED submission timing, malfunction procedures, test and training websites, machine-to-machine data exchange conditions, and IT security obligations.
"websites for testing and training"
Under the EU MDR, manufacturers use UDI assignments, device registration, technical documentation, and EUDAMED records to identify and trace devices placed on the EU market.
Use this page to align Basic UDI-DI, UDI-DI, EUDAMED actor records, label data, importer checks, and QMS controls without inventing unsupported deadlines or loose compliance labels.
Structured answer sets in this page tree.
Cited legal and guidance references.
EUDAMED and UDI work under the MDR is a data-control exercise: identify the legal actor, assign and govern the Basic UDI-DI and UDI-DI, register device data in the right EUDAMED module, keep label and technical-file references consistent, and preserve evidence for authority, notified-body, importer, vigilance, and post-market use.
EUDAMED is the MDR database architecture for actor registration, UDI and device registration, notified bodies and certificates, clinical investigations, vigilance and post-market surveillance, and market surveillance. For this artifact, the working scope is the actor and UDI/device-registration data that identifies a device, the responsible economic operators, and the records that later connect to certificates, vigilance, PMS, and public transparency.
The Commission UDI/device-registration page states that the MDR introduced a UDI-based identification system for traceability and that manufacturers must submit UDI/device information in EUDAMED for devices they place on the EU market. It also identifies the UDI/Devices module as mandatory to use from 28 May 2026, after the functionality notice and transition period described in the EUDAMED materials.
Separate the identifiers before assigning owners. The Basic UDI-DI groups devices with the same intended purpose, risk class, and essential design and manufacturing characteristics, and it appears in MDR evidence such as the declaration of conformity, technical documentation, certificates, SSCP and PSUR where applicable. The UDI-DI identifies the specific device model or package configuration for EUDAMED registration and traceability.
A new UDI-DI is needed when a change could cause device misidentification or ambiguity in traceability. MDCG 2022-7 lists examples including changes to name or trade name, device version or model, single-use labelling, sterile packaging, need for sterilisation before use, and package quantity. That makes UDI change control a release-gate question, not a post-launch database cleanup.
The manufacturer owns the MDR UDI and registration baseline: Article 10 requires manufacturers to comply with UDI obligations and device-registration obligations, and the QMS must verify UDI assignments and keep information submitted for device registration consistent and valid. For non-EU manufacturers, the authorised representative and competent-authority validation path affect actor registration; for importers, the MDR requires checks that the manufacturer has assigned a UDI where applicable and that the device is registered in the electronic system.
Actor data is not just an admin form. The actor module Q&A states that manufacturer names used in actor registration must match the name on the device label and official documents such as certificates and technical documentation. It also explains that an economic operator with multiple roles needs separate registration requests and receives a specific SRN for each actor role.
UDI governance should be embedded in design control, label approval, packaging control, declaration and certificate preparation, technical documentation maintenance, and post-market workflows. MDCG 2021-19 links UDI integration to the QMS and states that the UDI and Basic UDI-DI should be referenced across the technical file, declaration, reports, certificates, SSCP and PSUR where applicable.
The practical control is a cross-reference table, not a memo. For each device and packaging level, keep the Basic UDI-DI, UDI-DI, UDI-PI logic, issuing entity, EMDN code, risk class, intended purpose, label artwork reference, IFU reference, technical-file section, EUDAMED record state, release owner, and change trigger. Reconcile the table before label release, certificate updates, importer onboarding, vigilance submissions, and market withdrawals or recalls.
Use this checklist when a device is first registered, when an existing UDI record is changed, when an importer joins the supply chain, or when a label, certificate, technical file, market, or EUDAMED module status changes. The output should be a reconciled device-data pack that quality, regulatory, labelling, supply-chain, and vigilance teams can use without reinterpreting the MDR record.
Use the EUDAMED and UDI record as a governed device-data pack across regulatory, quality, labelling, supply-chain, vigilance, and post-market workflows.
"websites for testing and training"
"separate registration requests are required"
"Sign in to EUDAMED"
"Registration process"
"integration of the UDI within an organisation"
"UDI and Eudamed"
"ensuring consistency and validity of information"