EUDAMED Readiness: perché le registrazioni falliscono

In molte aziende EUDAMED viene ancora trattato come un progetto IT: un portale nel quale caricare dati man mano che la scadenza si avvicina. Questa interpretazione è alla radice del problema. La banca dati europea dei dispositivi medici (EUDAMED) non è uno strumento di upload, bensì il canale prescritto per gli obblighi regolatori già esistenti. Dal 28 maggio 2026 le segnalazioni di vigilanza, il Periodic Safety Update Report (PSUR) e il Post-Market Surveillance Report (PMSR) transitano obbligatoriamente attraverso la banca dati. Chi a quel punto non dispone di una registrazione completa non fallisce per ragioni tecniche, ma per il mancato rispetto delle scadenze.

EUDAMED è un obbligo, non un'opzione

La base giuridica è contenuta nell'art. 33 del Regolamento (UE) 2017/745 (MDR) per i dispositivi medici e nell'art. 30 del Regolamento (UE) 2017/746 (IVDR) per i diagnostici in vitro. EUDAMED raccoglie sei moduli: registrazione degli attori, registrazione UDI e dei prodotti, organismi notificati e certificati, indagini cliniche, studi delle prestazioni, vigilanza e post-market surveillance.

L'attivazione progressiva dell'uso obbligatorio di questi moduli è stata avviata dal Regolamento (UE) 2024/1860. L'ordine è determinante: la registrazione degli attori è il presupposto per qualsiasi altra attività in EUDAMED. Senza di essa un'azienda semplicemente non esiste nella banca dati, e non è possibile presentare alcuna UDI, alcuna segnalazione di vigilanza e nessun rapporto.

Sono interessati i fabbricanti, i mandatari e gli importatori dei settori MedTech e IVD. Per gli IVD è inoltre rilevante la classe di rischio: la IVDR scagliona i periodi di transizione per classe, cosicché l'obbligo pieno decorre a date diverse a seconda del prodotto. Proprio qui si generano i primi fraintendimenti, perché le aziende con portafoglio misto assumono che un'unica scadenza valga per tutto.

Quattro cluster in cui le registrazioni si bloccano

Nei progetti di implementazione riscontriamo gli stessi quattro schemi, quasi indipendentemente dalla dimensione aziendale.

• Registrazione degli attori incompleta. Senza un valido Single Registration Number (SRN) ai sensi dell'art. 31 MDR non si procede. Spesso mancano il numero EORI o dati del registro commerciale non coerenti, il che blocca la domanda. I fabbricanti extra-UE necessitano inoltre di un mandatario con SRN propria ai sensi dell'art. 11 MDR. Se questa configurazione non è impostata correttamente, l'intero progetto si ferma prima ancora di cominciare.

• Dati UDI non coerenti. Basic UDI-DI e UDI-DI vengono confusi o attribuiti in modo errato. Le modifiche al prodotto, i nuovi formati di confezione o le versioni software non vengono aggiornati tempestivamente, cosicché il record EUDAMED non riflette più la versione effettivamente in commercio. L'attribuzione UDI avviene tramite enti di attribuzione designati quali GS1, HIBCC o ICCBBA (Decisione di esecuzione (UE) 2019/939). In caso di ispezione, una discrepanza tra etichettatura, scope del certificato e record della banca dati viene valutata come carenza documentale, non come irregolarità minore.

• Workflow di vigilanza non migrato. Molti fabbricanti segnalano ancora gli incidenti gravi e le azioni correttive sul campo (FSCA) via e-mail alle autorità nazionali. Dal 28 maggio 2026 la segnalazione elettronica ai sensi dell'art. 87 MDR avviene tramite EUDAMED. I brevi termini di notifica rimangono invariati. Chi non ha adeguato il workflow non può rispettarli formalmente attraverso il canale prescritto, anche se il team di vigilanza è operativamente pronto. Le definizioni concettuali in materia sono contenute nella MDCG 2023-3.

• Documentazione PMS non caricabile. Il PMSR per la classe I ai sensi dell'art. 85 MDR e il PSUR per le classi superiori ai sensi dell'art. 86 MDR vengono presentati tramite EUDAMED. Rapporti contenutisticamente validi risultano tuttavia spesso incompatibili, perché struttura e formato non soddisfano i requisiti della banca dati. L'adeguamento richiede più tempo del previsto, specialmente quando non esiste un'interfaccia con l'eQMS e tutto deve essere trasferito manualmente.

Perché confonderlo con un progetto IT diventa costoso

Chi vede in EUDAMED un problema puramente informatico ne sbaglia la tempistica. Il nodo centrale è raramente l'upload in sé, bensì la qualità dei dati: la coerenza tra Basic UDI-DI, etichettatura del prodotto e scope dei certificati. Garantire questa coerenza è attività regolatoria e richiede anticipo, perché implica il coordinamento con l'organismo notificato, con il sistema di gestione della qualità e in parte con i fornitori.

Si aggiunge la natura continuativa dell'obbligo. EUDAMED non è un progetto una tantum con una data di chiusura. Le modifiche ai prodotti, le segnalazioni di vigilanza e i cicli di reporting devono essere aggiornati in modo continuativo. In assenza di una responsabilità chiaramente assegnata si creano esattamente in questi punti lacune che emergono alla successiva ispezione. Per portafogli di grandi dimensioni il problema si aggrava, perché la doppia manutenzione manuale in assenza di un'interfaccia eQMS non è solo onerosa, ma anche soggetta a errori.

Cosa fare adesso

E' opportuno un confronto modulo per modulo tra lo stato attuale e quello obiettivo, con prioritizzazione in base al tempo residuo. In concreto:

• SRN prima di tutto. Assicurare la registrazione dell'attore ai sensi dell'art. 31 MDR; per i fabbricanti extra-UE verificare la configurazione del mandatario ai sensi dell'art. 11 MDR. Tutto il resto si costruisce su questa base.
• Pulizia dei dati UDI. Mappatura da Basic UDI-DI a UDI-DI, allineamento con etichettatura e scope dei certificati ai sensi degli artt. 27 e 29 MDR, poi migrazione strutturata.
• Adeguamento di vigilanza e PMS al canale di notifica. Revisione delle SOP per gli incidenti e le segnalazioni FSCA verso il reporting EUDAMED ai sensi dell'art. 87 MDR; verifica della compatibilità al caricamento di PSUR e PMSR ai sensi degli artt. 85 e 86 MDR; test prima della messa a regime.

Entourage accompagna fabbricanti, mandatari e importatori di MedTech e IVD attraverso tutti e sei i moduli, dalla SRN al workflow di vigilanza. Il punto di partenza è di norma un'analisi dei gap che registra lo stato per ciascun modulo e definisce una sequenza realistica fino al soddisfacimento degli obblighi di notifica. Dove si applicano gli obblighi paralleli della IVDR vale la stessa logica per attori, UDI e vigilanza, con l'art. 30 IVDR come base giuridica EUDAMED per i diagnostici in vitro.