Serializzazione (FMD) per grossisti: gestione alert NMVS, verifiche e decommissioning senza errori

Se in accettazione scansionate una confezione e compare “Unknown pack” oppure “Pack Already Inactive”, il primo rischio non è tecnico: è organizzativo.

Il rischio vero è che qualcuno dica: “Sarà il sistema, mettila via e andiamo avanti.”
E quello, in audit, diventa: assenza di controllo su possibili falsificati o anomalie di supply chain.

In 30 secondi

• Per un grossista, FMD non è “scansionare tutto”: è sapere quando devi verificare e quando devi decommissionare.
• Gli alert NMVS vanno gestiti con un workflow da qualità: quarantena + triage + evidenza + escalation.
• Il mito pericoloso: “La serializzazione è un tema da farmacia” (falso: il grossista ha obblighi specifici e punti critici propri).

Vocabolario ispettivo (LSI) che devi padroneggiare

Falsified Medicines Directive (2011/62/UE), Regolamento Delegato (UE) 2016/161, Unique Identifier (UI), DataMatrix 2D, GTIN, NMVS, EMVO, decommissioning, verification, alert status, tamper-evident, risk-based verification, aggregazione, exception handling, Sistema Farma / flussi XML, dual system (bollino + DataMatrix).

Il punto che genera più errori: confondere “verification” e “decommissioning”

Molte deviazioni nascono da un fraintendimento semplice:

• Verification = controllo che il codice esista e sia valido nel sistema.
• Decommissioning = cambio di stato (es. “export”, “supplied”, ecc.) che rende quel pack non più dispensabile in EU.

In fase di audit, il problema che riscontro più spesso è la mancanza di una matrice decisionale chiara, applicata in modo uniforme dagli operatori.

Tabella decisionale (pronta da trasformare in SOP)

Scenario operativo	Azione FMD tipica	Rischio se sbagli
Acquisto da produttore/MAH e vendita a farmacia	spesso nessuna azione pack-by-pack (salvo policy interne)	inefficienza se scansionate tutto senza valore aggiunto
Acquisto da grossista “secondario” / intermediario	verification (spesso anche campionaria risk-based)	ingresso in filiera di pack non validi
Fornitura a soggetti non dispensatori (es. medico, nave, strutture particolari)	decommissioning (es. “supplied”)	pack che rientra e risulta duplicato/incoerente
Export extra-UE	decommissioning (tipicamente “export”)	rischio reintroduzione / mismatch di stato
Alert NMVS su pack in ricevimento/picking	quarantena immediata + gestione alert	potenziale falso ignorato = rilievo critico
Resi (se applicabile al vostro modello)	workflow dedicato: valutazione GDP + eventuale gestione UI secondo regole e condizioni di controllo	reinserimento improprio

Nota operativa: le regole esatte dipendono dal vostro ruolo nella catena e dalla configurazione nazionale. L’obiettivo qui è rendere “auditabile” il razionale e il controllo.

Playbook alert NMVS: cosa fare (davvero) quando compare un errore

Quando scatta un alert, serve una risposta standardizzata. Non “l’eroe del turno”.

Workflow in 8 step (skimmable, ma completo)

1. Stop & segregazione
• Il pack va in quarantena fisica (o area dedicata “FMD alert / sospetti”) con etichetta “ON HOLD”.
2. Evidenza immediata
• Screenshot/foto dell’errore, data/ora, postazione, ID scanner, operatore.
3. Second scan / double check controllato
• Non per “far sparire” l’errore, ma per confermare ripetibilità e ridurre falsi tecnici.
4. Verifica integrità confezione
• Controllo tamper-evident (sigillo/manomissione), condizioni packaging, segni di rework.
5. Apertura evento qualità
• Deviazione / segnalazione in QMS con classificazione (potenziale falsificato vs errore tecnico).
6. Triage tecnico (IT/fornitore)
• Verifica connettività, latenza, aggiornamenti software, sincronizzazioni.
7. Escalation regolatoria/filiera
• Contatto helpdesk nazionale + coinvolgimento MAH/fornitore se richiesto dal vostro processo.
8. Disposition tracciata
• Rilascio (se falso allarme comprovato) oppure gestione come sospetto falsificato/ritiro secondo procedura.

Contrarian insight: la pratica obsoleta è “resettare lo scanner e riprovare finché passa”.
È rischiosa perché cancella la cultura del dato: in audit, vi chiederanno quanti alert avete avuto, come li avete gestiti, in quanto tempo e con quali evidenze.

Integrazione scanner–software: il rischio nascosto è l’ergonomia (non la norma)

FMD fallisce spesso per motivi “banali”:

• scanner lenti
• postazioni insufficienti
• software non integrato → doppia scansione → operatori che “bypassano”
• risposta NMVS con latenza alta → pressione operativa → scorciatoie

Cosa funziona in pratica (da prospettiva di magazzino)

• Hardware 2D adeguato e manutenzione (scanner “stanchi” = errori).
• Integrazione con WMS o middleware per evitare doppie registrazioni.
• Gestione di picchi: più postazioni nei momenti di carico.
• Procedure di exception handling (cosa fare se NMVS non risponde, se rete down, ecc.).

Italia: DataMatrix + bollino (dualità che crea deviazioni “silenziose”)

In Italia la componente amministrativa (bollino/SSN) e quella anti-falsificazione (DataMatrix) possono convivere e generare:

• ridondanze operative
• errori di riconciliazione
• flussi incompleti verso sistemi centrali

Dalla prospettiva della compliance, non è “burocrazia”: è tracciabilità.
Un RP solido pretende:

• ownership chiara dei flussi (chi invia cosa, quando, con quale controllo)
• riconciliazione periodica tra movimentazioni e trasmissioni
• gestione scarti/errore file come deviazioni o incident log (se impattano tracciabilità)

KPI utili (che in audit fanno la differenza)

• Alert NMVS per 10.000 scansioni
• % alert chiusi entro X giorni
• Tempo medio di triage
• % operatori formati e riqualificati su FMD
• Numero di eccezioni per postazione/scanner (per individuare problemi tecnici o di processo)

“Da ricordare”

• FMD in un grossista è soprattutto: decisioni corrette + evidenze.
• Un alert non è “fastidio”: è un evento qualità finché non dimostri il contrario.
• Se la tecnologia rallenta troppo, il processo si “autobypassa”: e in audit lo paghi.

FAQ 

È obbligatorio scansionare ogni confezione in uscita?
Non necessariamente: molti modelli prevedono obblighi mirati e controlli risk-based. L’importante è avere una procedura coerente e dimostrabile.

Cosa significa “Pack Already Inactive”?
È un segnale che richiede gestione controllata: può essere un problema tecnico o un’anomalia reale. La risposta corretta è sempre quarantena + triage + evidenza.

Conviene implementare l’aggregazione?
Non sempre è obbligatoria, ma può ridurre tempi e errori se avete volumi alti (attenzione: va governata bene, altrimenti sposta solo il problema).