Il Flusso dall’inizio alla fine della pubblicazione di trasparenza in Italia

Dai dati grezzi alla submission XML su Sanità Trasparente

Per molte aziende farmaceutiche e del settore life sciences umano e animale in Italia, il ciclo di pubblicazione [reporting] della trasparenza si sta configurando come uno degli adempimenti di compliance più impegnativi del calendario. I dati relativi alle interazioni con operatori sanitari [HCP; Healthcare Professionals] e Organizzazioni sanitarie [HCO; Healthcare Organizations] arrivano alla compliance in formati diversi da sistemi differenti. Gli errori emergono tardi. Il responsabile della trasparenza passa settimane a rincorrere le correzioni manuali. E quando il file XML è finalmente pronto, non esiste un modo affidabile per verificarlo sintatticamente prima dell’invio alla piattaforma Sanità Trasparente del Ministero della Salute.

Tuttavia un numero crescente di aziende sta vivendo una realtà diversa. Con un flusso di lavoro [workflow] strutturato dall’inizio alla fine [end-to-end] e, quando non hanno esperienza della complessità dei diversi aspetti, il giusto partner di compliance nel settore life sciences, ogni ciclo di pubblicazione [submission] diventa un processo prevedibile e gestibile, invece di una rincorsa contro il tempo.

Ecco come si presenta realmente questo flusso di lavoro, passo dopo passo.

Step 1: Consolidare tutti i dati di interazione HCP/HCO in un unico database

Il primo ostacolo nel Sunshine Reporting italiano è la frammentazione. I dati sulle interazioni con HCP/HCO – inclusi i trasferimenti di valore come sponsorizzazioni di eventi, compensi per consulenze, ospitalità e viaggi – sono generalmente distribuiti su più sistemi informatici: CRM, piattaforme di gestione eventi congressuali [interne ed esterne], database ERP e strumenti di gestione spese. Ognuno utilizza formati, nomenclature e strutture dati differenti.

La soluzione non è imporre un’unica piattaforma a tutte le funzioni aziendali; piuttosto, i dati semestrali provenienti dai diversi sistemi devono essere mappati e poi consolidati in un unico database standardizzato, allineato alla tassonomia dell’Italian Sunshine Act, definita nelle specifiche tecniche del Ministero della Salute. Questo processo è eseguito una volta ad ogni periodo di reporting, tramite un’importazione dei dati strutturata che non richiede modifiche ai sistemi informatici esistenti: un vantaggio fondamentale quando le risorse IT sono già sotto pressione da parte del business.

Step 2: Rilevazione algoritmica degli errori e proposta di correzioni

Una volta consolidati i dati del periodo (es. semestrali) in una sola tabella, questo database aggregato deve essere analizzato dai team di trasparenza alla ricerca di errori, incoerenze e campi mancanti, ovvero tutte quelle criticità che potrebbero portare a un rifiuto o a una segnalazione da parte di Sanità Trasparente. A questo riguardo sta emergendo un’importante tendenza cioè dotarsi di un algoritmo che effettua queste migliaia (se non centinaia di migliaia) di controlli e segnala. Inoltre, invece di limitarsi a segnalare i problemi, il sistema propone da sé correzioni specifiche, allineate ai requisiti normativi.

In questa fase cambia in modo significativo il ruolo del team di compliance. Invece di controllare manualmente migliaia di righe, il team si concentra su un elenco pre-selezionato di modifiche proposte, le convalida o le rettifica e approva il risultato finale. Il lavoro più oneroso è gestito dall’algoritmo e da un team di supporto specializzato (anche esterno), non da una funzione interna già sovraccarica.

Step 3: Monitoraggio tramite dashboard e approvazione del management

Una volta puliti e corretti, i dati del periodo (ad esempio semestrali) sono quindi aggregati ai dati raccolti nei periodi precedenti in un unico database e visualizzati in uno o più Cruscotti visivi digitali [dashboard] che consentono sia il monitoraggio dei trend di compliance, sia la discussione con il partner di business, ma anche l’approvazione formale da parte del management di alto livello. La dashboard offre una visione chiara del profilo dei trasferimenti di valore dell’azienda nel tempo, prima che i dati siano trasmessi al Ministero.

Solo dopo l’approvazione del management si procede alla generazione del file XML. Questo step non è una formalità, ma un punto di controllo fondamentale di governance, che garantisce visibilità a livello di Senior Management prima che i dati diventino pubblici.

Step 4: Generazione XML, validazione pre-caricamento e invio a Sanità Trasparente

I dati del periodo oggetto della trasparenza cosi approvati (depurati dai dati al di sotto della soglia e arricchiti dei Trasferimenti di valore (TOV) dei precedenti semestri rilevanti [ricordiamoci che i TOV sotto la soglia unitaria devono essere pubblicati nel semestre successivo se si passa la soglia annuale]) sono estratti dal database centrale e convertiti nel formato XML richiesto da Sanità Trasparente. Le specifiche tecniche emesse dal Ministero della Salute (disponibili a tutti oramai da un anno) definiscono lo schema XSD, i campi obbligatori, le convenzioni di tassonomia [naming] e le regole strutturali. Qualsiasi deviazione – come un campo mancante, un codice provincia errato o un nome file non conforme – può comportare il rifiuto automatico.

È fondamentale testare il file XML in un ambiente di convalida informatico aziendale privato prima del caricamento nella piattaforma ufficiale. Questo è uno degli aspetti più sottovalutati di un processo robusto. Testare esclusivamente sulla piattaforma ufficiale può generare ritardi, mentre un ambiente privato consente maggiore riservatezza e iterazioni/correzioni più rapide. Individuando gli errori internamente, si evita di scoprirli solo dopo il caricamento.

Una volta convalidato, il file è pronto per l’invio. Il responsabile della trasparenza mantiene l’autorità finale di approvazione.

Comprendere la struttura della submission: due sezioni, due logiche

È fondamentale comprendere che il framework di Sanità Trasparente prevede due flussi distinti, non un unico processo:

Sezione A — Trasferimenti di valore (Articolo 3): include convenzioni, erogazioni e accordi con HCP e HCO. La comunicazione avviene su base semestrale.

Sezione B — Interessi finanziari (Articolo 4): include partecipazioni, obbligazioni e Proventi di proprietà industriale (royalty). La comunicazione avviene annualmente entro il 31 gennaio.

Questi flussi hanno tempistiche, strutture dati e logiche operative differenti. I sistemi e i processi devono tenerne conto separatamente.

Il risultato: prevedibilità, audit readiness e tempo restituito alla funzione compliance

Le aziende che adottano un workflow strutturato registrano una riduzione significativa dello stress operativo sulle risorsee un miglioramento continuo della qualità dei dati. Il database storico diventa progressivamente più solido, rendendo più efficace il monitoraggio e più semplice la gestione delle verifiche.

Ancora più importante, il ruolo del responsabile della trasparenza diventa realmente strategico: supervisione, governance e approvazione finale, invece di attività operative di poco valore aggiunto per l’innovazione del business.

Questo è il vero valore di un workflow ben progettato: non solo una submission XML corretta, ma un modo completamente diverso di gestire l’obbligo di trasparenza reporting.

Prepararsi correttamente e scegliere il partner giusto

➤ Scegliete il giusto partner di Transparency reporting per garantire invii di dati [submission] conformi sin dal primo giorno.

➤ Partecipate ai nostri eventi Italian Sunshine Reporting per lavorare direttamente su modelli operativi concreti.

➤ Richiedete supporto personalizzato per rispondere a esigenze specifiche, dalla classificazione dei dati alla gestione delle interazioni attraverso processi transfrontalieri [cross-border].