Dipartimento di Sanità Pubblica

PROGETTO TECNICO

PER LA REALIZZAZIONE

DI UN SISTEMA INFORMATICO

DELLA SICUREZZA ALIMENTARE

IN REGIONE EMILIA ROMAGNA

A cura della funzione

Flussi Informativi - Direzione DSP AUSL di BOLOGNA

aggiornamento dicembre 2007

I

INDICE

1. LO SCENARIO pagina

1.01 I cambiamenti in atto ……….……………….……..…… 1 1.02 Situazione attuale dell’informatizzazione ……….…… 1

2. FINALITA’ DEL PROGETTO

2.01 Gli obiettivi …………..……….…………………………… 3 2.02 La struttura del progetto …….…...……………………… 3

3. ANAGRAFE REGIONALE DEGLI OPERATORI DI SICUREZZA

ALIMENTARE

3.01 Definizione dell’ambito produttivo …………………….... 5

3.02 Modellazione delle entità logiche del database centrale …………………………………………………... 7

3.03 Analisi dei database operativi presso i servizi ausl ..…10

3.04 Codifiche regionali delle attività con cui integrare il database centrale ………………………………………12

3.05 Modelli logici di popolamento del database centrale ……………………………………………….… 13

3.06 Fonti dati ufficiali per entità “ditte” e “strutture” …….... 18 3.06.01 infocamere – registro imprese ……………....... 20 3.06.02 bancadati nazionale - anagrafe zootecnica….. 22 3.06.03 agenzia per le erogazioni in agricoltura

(agea) agrea (r.e.r.) ...………...……… …....…. 24 3.06.04 sintesi ………………………………………….… 25

3.07 Integrazione anagrafiche locali - portale delle imprese ………………………………………………… 26

II

3.08 Ipotesi di allineamento delle anagrafiche locali col

“registro imprese” ……………………………………… 27

3.09 Aspetti organizzativi dell’allineamento delle anagrafiche …………………………………………..... 31

3.10 Aggiornamento ed integrazione delle anagrafiche

locali nell’elenco regionale delle aziende alimentari …………………………………………….… 34

4. IL SISTEMA INFORMATIVO REGIONALE INFORMATIZZATO

4.01 L’architettura del sistema centrale ……………….….. 36 4.02 Raccolta delle informazioni sulla categorizzazione

del rischio …………………………………..…..….….. 38 4.02.01 griglie di valutazione .……………….………... 39

4.03 Raccolta delle informazioni sui controlli effettuati …. 41

4.04 Raccolta delle informazioni sui campioni effettuati ………………………………………………… 47

4.04.01 sperimentazione sul campo..………………...… 47 4.04.02 integrazione tra s.i.rer e sanità veterinaria…… 49 4.04.03 flussi informativi dai laboratori…………………. 49 4.04.04 le informazioni da integrare…………………….. 53 4.04.05 le nuove informazioni raccolte dal laboratorio.. 60 4.04.06 integrazione tra izs e s.i.rer…………………….. 62

5. SISTEMA PUBBLICO DI CONNETTIVITA’

5.01 Cos’è il sistema pubblico di connettività ……...……. 64 5.02 La porta di dominio ……………………………..….…. 66

. 5.03 La cooperazione applicativa …………………..…….. 66

5.03.01 cooperazione per richiesta di servizio …..….... 68 5.03.02 cooperazione per eventi …………………..…... 69

III

5.04 Profili di collaborazione ………………………..……... 70

5.05 La busta di e-government ……………………..….….. 71

5.06 La normativa di riferimento …………………………… 73

5.07 Principali siti di riferimento ……………………...……. 74

5.08 Bibliografia ufficiale cnipa ………………………….…. 74

6. CONCLUSIONI

6.01 Fattibilità del progetto ………………………….…..…. 76 6.02 Passaggi organizzativi ……………..…………..…..… 76

6.03 Considerazioni finali …………………………………... 81

6.03.01 impatto economico ed organizzativo………….. 81 6.03.02 ipotesi di sviluppo ed applicazione graduale

del s.i. sicurezza alimentare regionale….…….. 83

IV

ALLEGATI:

A. Elenco Flussi Informativi Regionali (20 pagine) B. Classificazione delle Attività Economiche - ATECO 2002

(ISTAT 2002) (37 pagine) C. Elenco Attività nei debiti informativi Veterinari e SIAN

(Relazione di Attività annuale) (11 pagine) D. Sistema integrato IZSLER – ASL Lombarde ed Emiliane

(IZSLER – 2006) (5 pagine)

E. Sistema Pubblico di Cooperazione: Quadro tecnico d’insieme (CNIPA 2004) (24 pagine)

F. Sistema Pubblico di Cooperazione: Architettura (CNIPA 2004) (84 pagine)

G. Architettura e componenti per la cooperazione applicativa

nella Pubblica Amministrazione (White Paper Oracle – 2002) (10 pagine)

H. Interoperabilità e Cooperazione Applicativa con Microsoft

(Microsoft 2006) (9 pagine)

1

1 LO SCENARIO 1.01 I CAMBIAMENTI IN ATTO I nuovi regolamenti comunitari sulla sicurezza alimentare prevedono che l’autorità competente sul controllo ufficiale della filiera produttiva degli alimenti agisca secondo modalità operative omogenee, adeguate ed efficaci. E’ inoltre previsto che la definizione dei piani di attività sia basata sulla valutazione del rischio di ogni specifico settore produttivo e sempre sulla valutazione del rischio deve poggiare la frequenza dei controlli ufficiali nella singola impresa produttiva. Per verificare il corretto funzionamento del sistema dei controlli ufficiali è indispensabile predisporre adeguati strumenti di monitoraggio sull’andamento dei piani di lavoro così da apportare in tempi rapidi i correttivi che eventualmente si rendessero necessari. Per realizzare questo complesso insieme di iniziative volte a tutelare la salute del consumatore è necessario dotarsi di moderni sistemi informatici capaci di mettere in rete tutte le informazioni raccolte dai diversi attori impegnati nel campo della sicurezza alimentare (Aziende USL, Regione e Ministero). 1.02 SITUAZIONE ATTUALE DELL’INFORMATIZZAZIONE Attualmente sono attive diverse banche dati, locali, nazionali, comunitarie, che raccolgono dati di interesse settoriale. La Regione Emilia Romagna ha avviato un percorso per omogeneizzare la raccolta dei dati in modo da renderli confrontabili. Un apposito progetto, svolto in collaborazione con ARPA e IZS, intende mettere in rete le Aziende USL con i laboratori pubblici. I vari attori che cooperano al sistema della sicurezza alimentare condividono in parte le stesse informazioni, distribuite tuttavia nelle

2

diverse banche dati non comunicanti tra di loro. Tale situazione rende oneroso ed inefficiente l’aggiornamento dei diversi archivi. Oltre a ciò, la necessità di un monitoraggio sulla qualità e quantità dei controlli ufficiali, impone la realizzazione di un sistema che permetta in modo automatico e frequente la raccolta e l’analisi delle informazioni relative a tali attività, per poterne valutare l’appropriatezza e l’efficacia. Solo attraverso la corretta elaborazione di questa grande mole di informazioni derivante da tutto il territorio regionale, sarà possibile affinare e rendere sempre più potente ed utilizzabile nel tempo lo strumento della “analisi del rischio”, inteso come asse portante della sicurezza alimentare nella filosofia comunitaria. Tutte queste esigenze rendono dunque impellente la necessità di esplorare i possibili livelli di interazione tra le varie banche-dati, al fine di automatizzarne lo scambio di informazioni ancora in gran parte cartaceo. Lo scenario disegnato dalle più recenti applicazioni tecnologiche nel campo dello scambio dati informatizzato, infatti rende opportuno compiere una indagine preliminare sulla realizzabilità di una rete regionale dei dati relativi alla sicurezza alimentare. Tali bisogni sono sempre più pressanti se si considera la mole di informazioni che, con frequenza variabile da “in tempo reale” ad “annuale”, vengono raccolte in vario modo, nella grande maggioranza dei casi secondo il flusso di seguito indicato: Servizio Veterinario AUSL � Serv. Vet. Regionale � Ministero della Salute Molte di queste informazioni risiedono in banche dati esterne all’AUSL, e sono descritte nei 48 punti dell’ ALLEGATO A “Elenco Flussi Informativi Regionali”.

3

2. FINALITA’ DEL PROGETTO 2.01 GLI OBIETTIVI Gli obiettivi del presente studio si possono così individuare: - Verificare la fattibilità di un sistema che permetta la creazione e

l’aggiornamento in tempo reale di una banca-dati regionale per la registrazione delle imprese che operano nel campo della sicurezza alimentare (Operatori di Sicurezza Alimentare, di seguito detti OSA), ai sensi di quanto previsto dal Reg. 852/2004 e dal relativo Accordo applicativo della Conferenza Stato-Regioni n. 2470 del 9-2-06. Tale sistema dovrà essere per quanto possibile integrato con le altre banche-dati ufficiali esistenti ed integrabile con quelle di prossima realizzazione.

- Disegnare il nucleo di una rete informatizzata dei principali soggetti

che cooperano sul controllo ufficiale nel settore della sicurezza alimentare.

- Verificare la fattibilità di un sistema che permetta l’acquisizione

automatica e frequente dei dati di attività dei Servizi Veterinari e Servizi di Igiene degli Alimenti e Nutrizione delle AUSL.

2.02 LA STRUTTURA DEL PROGETTO Lo studio si articola in una prima parte in cui si valutano le modalità di costruzione di un’Anagrafe Regionale degli Operatori di Sicurezza Alimentare (A.R.O.S.A.), ufficiale ed aggiornabile, condiviso tra banche dati dei Servizi AUSL e Servizio Regionale. La seconda parte analizza la possibilità di creazione modulare di un vero e proprio SISTEMA INFORMATIVO REGIONALE INFORMATIZZATO che permetta lo scambio dei dati tra Sistemi Informatici locali delle AUSL ed un Centro Servizi Regionale, relativamente alla CATEGORIZZAZIONE DEL RISCHIO delle attività svolte presso le

4

imprese alimentari, nonché alla registrazione dei CONTROLLI e dei CAMPIONAMENTI ivi svolti. La terza parte del lavoro descrive la tecnologia ed i riferimenti bibliografici utili allo sviluppo del sistema informativo regionale all’interno del SISTEMA PUBBLICO DI CONNETTIVITA’ E COOPERAZIONE APPLICATIVA, secondo quanto previsto per gli enti pubblici dal progetto di e-Government europeo. Nell’ultima parte si trattano le CONCLUSIONI ricavabili dal presente studio di fattibilità.

5

3. ANAGRAFE REGIONALE DEGLI OPERATORI DI SICUREZZA ALIMENTARE

3.01 DEFINIZIONE DELL’ AMBITO PRODUTTIVO Al fine della creazione di un elenco completo delle aziende che ricadono nell’ambito dei controlli per la sicurezza alimentare, secondo la normativa vigente, occorre che in esso siano comprese le imprese che operano nelle seguenti tipologie produttive:

A) OSA con aziende soggette a RICONOSCIMENTO ai sensi 853/2004.

B) OSA con aziende soggette a REGISTRAZIONE ai sensi

852/2004 in precedenza regolamentate dalla L. 283/62 e dal D.P.R. 327/80:

B.01.01 Lavorazione. B.01.02 Deposito. B.01.03 Confezionamento. B.01.04 Trasporto. B.01.05 Vendita (ingrosso e dettaglio). B.01.06 Ristorazione. B.01.07 Consumo alimenti e bevande. B.01.08 Preparazione Pasti.

C) Altri OSA con aziende soggette a REGISTRAZIONE ai sensi 852/2004 (con esclusione delle attività ad esclusivo uso famigliare):

C.01.01 Allevamenti. C.01.02 Aziende agricole produttrici di alimenti

destinati al consumo umano. C.01.03 Aziende agricole produttrici di alimenti

destinati alla zootecnia.

Le informazioni relative alle attività di tipo (A) sono presenti e presumibilmente aggiornate negli archivi dei servizi. Le informazioni relative alle attività di tipo (B) sono presenti negli archivi dei servizi, ma presentano le seguenti criticità:

6

- possono essere in vari casi duplicate se gli archivi dei servizi Veterinari e SIAN sono separati;

- In passato sfuggivano all’aggiornamento le attività che cessavano

senza essere sostituite da altre, soggette ad autorizzazione sanitaria sindacale: dunque mentre per le aperture di nuove attività e per i casi di cosiddetta “voltura” (cioè di apertura di nuova attività al posto di una precedente attività cessata) le procedure autorizzative permettevano di registrare gli aggiornamenti informativi, ciò non era garantito per le cessazioni totali di attività in un a struttura, senza subentro di altre attività soggette ad autorizzazione. Tale situazione di vuoto informativo dovrebbe essere scongiurata con il nuovo sistema di D.I.A. (Dichiarazione di Inizio Attività) previsto dal 852/2004, che prevede l’obbligo di comunicazione anche per le cessazioni, oltre che per le variazioni di proprietà o del ciclo produttivo stesso.

Dunque dal punto di vista informativo le informazioni attualmente in possesso dei servizi, relativamente a questa tipologie di attività, sono incomplete, ma tendono a diventare complete, in funzione del successo del sistema delle D.I.A. per quanto riguarda i casi di cessazione delle attività senza sostituzione di altre attività alimentari e i casi di variazione del ciclo produttivo. Le informazioni relative alle attività di tipo (C ) si differenziano tra di loro nel senso che le attività di tipo C.01 si distinguono a loro volta in:

debito informativo

R.E.R. C.01.01 Allevamenti bovini (presenti in BDN) (17) C.01.02 “ “ suini (presenti in BDN) (19-33) C.01.03 “ “ ovi-caprini (presenti in BDN) (19-33) C.01.04 “ “ equini (in futuro presenti in BDN) C.01.05 “ “ avicoli (presenti in BDN) (33) C.01.06 “ “ cunicoli C.01.07 “ “ selvaggina C.01.08 “ “ ittici e molluschi C.01.09 “ “ altro.

Le attività che prevedono l’inserimento delle relative informazioni in BDN, sono registrate sulla base di procedure ufficiali che ne garantiscono la

7

veridicità e la certificabilità, mentre le altre attività non sono censite con tale sistema e sono state inserite negli archivi locali senza una procedura che ne garantisca la totale attendibilità. Per quanto riguarda invece le aziende agricole del tipo C.02 e C.03, esse non sono state in passato oggetto di controlli dei servizi, se non in piccolissima percentuale da parte del SIAN, per cui non esiste presso di loro alcun tipo di informazione utile al fine di realizzarne un elenco completo.

3.02 MODELLAZIONE DELLE ENTITA LOGICHE DEL DATABASE CENTRALE

Dal punto di vista delle informazioni e della loro struttura, occorre raggruppare in forma logica le informazioni stesse, secondo un modello teorico che riesca a descrivere le diverse realtà e gli eventi che si possono verificare presso di esse. L’obiettivo è descrivere quindi delle entità logiche che rappresentino in maniera esaustiva tali realtà. La prima entità da prendere in considerazione è la realtà fisica che è OGGETTO del CONTROLLO: essa possiamo definirla come la STRUTTURA , ovvero il luogo fisico presso cui vengono svolte le attività oggetto del controllo, con le seguenti informazioni di base che la caratterizzano: STRUTTURE

Indirizzo via e numero civico (interno) Comune La seconda sono le ATTIVITA’, cioè le varie tipologie di lavorazione che vengono svolte presso la STRUTTURA. ATTIVITA'

Descrizione dell'Attività L’ultima delle entità fondamentali è la DITTA, cioè l’entità che raccoglie i dati sociali dell’impresa che esercita le ATTIVITA’ nella STRUTTURA.

8

DITTE

Denominazione della Ditta Indirizzo via e numero civico Comune

Per ogni entità logica occorre definire un’informazione, od un insieme di informazioni, che la rendano inconfondibile con un’altra presente in archivio: la cosiddetta “Chiave Primaria” o “Primay Key” (PK) . Per quanto riguarda le STRUTTURE il problema presenta in realtà parecchie soluzioni con implicazioni che verranno affrontate in seguito, al momento pensiamo semplicemente di definire in via teorica un campo numerico progressivo che sia il codice univoco (COD_STRUTTURA). L’ambito delle ATTIVITA’ dispone di una codifica ufficiale nazionale e comunitaria: la classificazione delle attività economiche ATECO, che è una tipologia di classificazione adottata dall'Istituto Nazionale di Statistica italiano (ISTAT) per le rilevazioni statistiche nazionali di carattere economico. È la traduzione italiana della Nomenclatura delle Attività Economiche (NACE) creata da Eurostat, adattata da ISTAT alle caratteristiche specifiche del sistema economico italiano. Attualmente è in uso la versione ATECO 2002, adottata nel 2002, che sostituisce la precedente ATECO 1991. Si tratta di una classificazione alfa-numerica con diversi gradi di dettaglio: le lettere indicano il macro-settore di attività economica, mentre i numeri (che vanno da due fino a cinque cifre) rappresentano, con diversi gradi di dettaglio, le articolazioni e le disaggregazioni dei settori stessi. In tale entità, il campo (COD_ATECO) funge da PK. La relazione con l’entità STRUTTURE è di tipo “uno (STRUTTURA) a molti (ATTIVITA’)”. Per completezza documentale si rimanda all’ALLEGATO B “Classificazione delle attività economiche ATECO 2002”. Con riferimento alle DITTE queste possiedono una codifica univoca nazionale che è il Codice Fiscale rilasciato al momento della creazione della Ditta stessa e che quindi può fungere da PK. La relazione che intercorre tra STRUTTURE ed ATTIVITA’ e del cosiddetto tipo “uno a molti”, cioè in una stessa struttura possono essere effettuate diverse attività.

9

La relazione tra DITTE e STRUTTURE è del tipo “molti a molti” cioè, oltre ai casi più comuni in cui una ditta opera in una sola struttura, vi sono casi in cui una stessa ditta opera in più strutture, ma anche casi più rari in cui più ditte operano nella stessa struttura, per cui la relazione stessa deve tener conto in maniera “ridondante” di tutti i possibili casi. Il modello logico può essere dunque così rappresentato:

Al fine di procedere all’informatizzazione di tale base logica occorre prevedere tabelle di interfacciamento molti-a-molti che implementano in questo modo la base dati iniziale:

A questo livello di articolazione si sono volutamente tralasciate le informazioni relative ad entità quali le PERSONE che esercitano ruoli nelle DITTE o nelle STRUTTURE.

10

3.03 ANALISI DEI DATABASE OPERATIVI PRESSO I

SERVIZI AUSL Come considerazione preliminare, non ci si può certo attendere che la struttura delle entità logiche presso i database locali dei servizi sia univoca e identica a quella sopra illustrata: la modellazione delle entità infatti risente moltissimo dei diversi fattori che indirizzano le analisi in fase di creazione dei sistemi. Ad esempio, per i servizi che utilizzano il programma Sfera Carta, la gestione delle informazioni anagrafiche è operata da una tabella chiamata “Utenti” che raggruppa le informazioni della Struttura con quelle della Ditta di appartenenza.

UTENTI

distretto

ced

ragione_sociale istat indirizzo cap frazione civico telefono filler (codice fiscale) quartiere posizione cod_cciaa data_cciaa addetti sede ult_codice stato data_inizio data_fine aggiornato

11

codice_aziendale fax gradi_lat primi_lat secondi_lat gradi_long primi_long secondi_long altitudine filler8 conto_economico flag_export reg_azienda

Tale situazione non impedirebbe, comunque, un corretto scambio dati con il Db normalizzato centrale, per le Ditte la cui sede fiscale corrisponde con la Struttura; si otterrebbe infatti una solo ridondanza di Ditte a fronte di un corretto numero di Strutture. Appare invece impossibile gestire, con una logica di questo tipo, le informazioni per le Ditte con sede fiscale diversa dalla sede operativa, in quanto il Comune di tale struttura potrebbe risultare esterno al range dei comuni della regione, creando così false strutture fuori regione, che in realtà sarebbero sedi fiscali. Conforta comunque l’uso dello standard ISTAT per definire il Comune (campo “istat” della tabella). Viene garantita inoltre una buona standardizzazione dalla distinzione tra la denominazione dell’indirizzo e numero civico (campi “indirizzo” e “civico”), anche se non viene presa in considerazione l’aspetto della tipologia di indirizzo (via, viale, piazza, ecc…) sganciato alla denominazione stessa dell’indirizzo. Vi è il riferimento al Codice Fiscale, però non esiste la garanzia che il campo sia popolato nel Db operativo (cioè non è un campo obbligatorio e non può fungere da chiave univoca di ricerca dei record, essendo questa l’accoppiata “distretto” e “ced”). Esistono i riferimenti alla registrazione c/o CCIAA (“cod_cciaa” e “data_cciaa “) con le stesse riserve legate al C.F.

12

Esiste un riferimento al codice aziendale inteso come codice attribuito dal ministero o dai servizi (campo”codice_aziendale”). 3.04 CODIFICHE REGIONALI DELLE ATTIVITA’ CON CUI

INTEGRARE IL DATA-BASE CENTRALE Situazione di rilievo è rappresentata dal fatto che le codifiche delle attività previste per i flussi informativi sanitari, regionali e ministeriali sono diverse e più dettagliate di quelle ATECO. Questi sono ricavabili in primis dalla reportistica annuale regionale che disegna aggregazioni di tipologia produttiva diverse dalle codifiche ATECO e non sovrapponibili ad esse: a titolo esemplificativo si riporta l’elenco previsto per il flusso regionale del SIAN:

PRODUZIONE PRIMARIA

1 Aziende agricole 2 Acquacoltura in acqua dolce / in acqua salata

TRASFORMAZIONE, LAVORAZIONE, CONFEZIONAMENTO

3 Lavoraz.,trasf.,conserv. frutta e verdura 4 Produzione di estratti alimentari ed affini 5 Produzione di alimenti surgelati 6 Produz. di alimenti per l'infanzia e dietetici 7 Trattamento latte e conservazione latte fresco 8 Trasformazione del latte 9 Produzione gelati ed affini (Lab.artigianali)

10 Mulini e lavorazione affini 11 Produzione di pasta fresca (Lab.artigianali) 12 Industria delle paste alimentari 13 Produzione di pasticceria (Laboratori artigianali) 14 Produzione di pasticceria (Laboratori industriali) 15 Produzione di pane e prodotti da forno 16 Industria del vino 17 Imbottigliamento acque minerali naturali

17 Bis Imbottigliamento acque potabili 18 Produzione di semilavorati per industria alimentare 19 Altri comparti

13

RISTORAZIONE

20 Ristoranti ed affini 21 Bar ed affini

22 Mense / centri produzione pasti / terminali di distribuzione:

fino a 250 pasti/giorno da 251 a 1000 pasti/giorno più di 1000 pasti/giorno terminali di distribuzione

23 Gastronomia 24 Fiere-festival-sagre popolari

COMMERCIO

25 Commercio al minuto 26 Supermercati 27 Commercio all'ingrosso prodotti alimentari, frigoriferi

TRASPORTI

28 Trasporti merci su strada

Per quanto riguarda quello dei Veterinari esso si desume dalla relazione SISVET ed è formato da oltre 200 voci. Per completezza documentale si rimanda all’ALLEGATO C “Elenco Attività RER”. 3.05 MODELLI LOGICI DI POPOLAMENTO DEL DB CENTRALE Si consideri ora la modalità con cui il DB locale possa popolare con i propri dati il DB centrale, prescindendo per il momento dalle questioni relative alle eventuali tecnologie impiegabili per svolgere tale attività. Nel caso di maggiore difformità delle entità, come per servizi che utilizzano SferaCarta od Avelco, in cui la tabella UTENTI raggruppa sia informazioni sulle STRUTTURE che sulle DITTE, ogni riga (record) della tabella UTENTI nel DB locale creerà una corrispondente riga con le informazioni per la tabella STRUTTURE sul DB centrale. La correlazione tra il DB locale e quello centrale andrà mantenuta attraverso la PK della tabella locale UTENTI (che è data dai due campi “distretto” e “ced”, eventualmente integrabile durante la fase di

14

importazione dei dati dal db locale con la specifica della “AUSL” e del “servizio” di riferimento per rendere tale chiave univoca anche sul DB centrale, tramite una specifica funzione sul DB centrale) che dovrà essere riportata nella tabella centrale STRUTTURE.

Dunque con una funzione di sincronizzazione sul DB centrale si può in questo modo popolare la tabella STRUTTURE. Occorre a questo punto definire quali ATTIVITA’ vengono svolte all’interno delle STRUTTURE e per fare ciò dobbiamo considerare prima di tutto che ogni DB locale avrà una propria CODIFICA DELLE ATTIVITA’ che certamente sarà diversa dagli altri, per cui per riuscire a normalizzare, cioè a rendere coerente tale informazione sul DB centrale, occorre predisporre una TABELLA DI DECODIFICA DELLE ATTIVITA’ LOCALI. Essa dovrà considerare tutte le possibili diversificazioni nei diversi DB locali che possano verificarsi per il fatto di essere in AUSL diverse in distretti diversi ed in servizi diversi

15

In tal modo, a fronte di diversi codici riferibili a servizi diversi di diverse AUSL, è possibile attribuire automaticamente alle diverse strutture lo stesso codice regionale di riferimento, ad es. la stessa attività RER (101 - MACELLERIA ) viene individuata in modo univoco pur in presenza di due diversi codici usati in due diversi DB locali uno dal servizio Veterinario a Piacenza (15 - NEGOZIO DI MACELLERIA) e l’altro dal SIAN di Rimini (29 – ESERCIZIO DI VENDITA CARNI).

DECODIFICA ATTIVITA’ AUSL

AUSL

Distretto

Servizio

Codice Attività AUSL

Descrizione Attività AUSL

Codice Attività RER

Descrizione Attività RER

PIACENZA

8

VET

15

NEGOZIO DI MACELLERIA

101

MACELLERIA

RIMINI

2

SIAN

29

ESERCIZIO DI VENDITA

CARNI

101

MACELLERIA

Criticità prevedibili per questo tipo di impostazione sono eventuali aggiunte di nuove codifiche, dopo la fase di popolamento iniziale del DB, che potrebbero gestite nei seguenti modi:

DECODIFICA ATTIVITA’ AUSL

AUSL

distretto

servizio

Codice Attività AUSL

Descrizione Attività AUSL

Codice Attività RER

Descrizione Attività RER

16

a) con la generazione di eccezioni risolvibili solo tramite l’intervento

diretto dell’Amministratore Centrale del sistema, semplice ma potrebbe generare panico presso i servizi locali, a fronte di record respinti dal sistema centrale.

b) con l’esportazione da parte del DB locale dei soli nuovi codici locali

di attività inseriti; tale soluzione appare però realizzabile solo dove il db locale sia gestito da un applicativo particolarmente evoluto

c) con l’importazione automatica dei nuovi codici tramite una funzione

del DB centrale che ad ogni aggiornamento dei dati importa nuovamente tutte le codifiche ed individua le nuove, aggiungendole poi automaticamente e segnalandole all’Amministratore centrale di sistema per il completamento con la codifica RER; questa soluzione in fondo appare la più solida.

Risolto il problema della decodifica delle Attività, esaminiamo la modalità di attribuzione di Attività alle STRUTTURE del DB centrale, tenendo presente che nei DB locali tale informazione può essere gestita sostanzialmente in due modi:

a) viene considerata solo una attività prevalente per ogni struttura, e spesso tale informazione è riportata all’interno della stessa tabella UTENTI locale.

b) Vengono registrate più attività possibili per ogni struttura e nel

DB locale esiste una tabella che mette in relazione le due entità UTENTI ed ATTIVITA’ AUSL.

In entrambe i casi, con la stessa chiave usata in precedenza “AUSL” - “distretto” - “ced”- “servizio” è possibile generare dal database locale una tabella di “UTENTI ATTIVITA’ AUSL”.

17

Quest’ultima tabella “UTENTI ATTIVITA’AUSL troverà sul DB centrale una corrispondente tabella “STRUTTURE ATTIVITA’AUSL” che si relaziona in rapporto molti a uno con STRUTTURE (molte attività sono possibili in un’unica struttura) secondo il seguente schema.

18

In questo modo per ogni Utente del Db locale sarà possibile creare un corrispondente record nel Db centrale e qualsiasi attività riferibile ad esso (in qualsiasi maniera sia codificata e definita nel Db locale) sarà possibile riportarla nel Db centrale in maniera “normalizzata” secondo le codifiche di attività specifiche della regione. Tuttavia risultano attualmente in fase di nuova definizione dei codici Ateco da parte del team di sviluppo del Portale Imprese. Nel caso queste fossero ritenute utilizzabili per gli archivi locali delle AUSL, sarebbe automaticamente superato il problema della decodifica centrale delle Attività, con l’adozione di queste ultime in tutti i livelli del sistema.

3.06 FONTI DATI UFFICIALI PER ENTITA’ “DITTE” E

“STRUTTURE” Sotto l’aspetto della qualità, le informazioni destinate a popolare questa tabella, non possono che essere validate da un processo ufficializzato di creazione ed aggiornamento che ne assicuri l’ufficialità che, a sua volta, ne garantisca : - Veridicità - Completezza - Aggiornamento

Informazioni tale natura riferibili alle informazioni sociali delle imprese produttive sono presenti in vari tipologie di archivi ufficiali, i più interessanti, da questo punto di vista, sono:

1) Fonte certa per eccellenza quello denominato REGISTRO DELLE IMPRESE (R.I.) gestito da INFO-CAMERE per conto dell’ente “UNION CAMERE” (Unione Italiana delle Camere di Commercio Industria, Artigianato e Agricoltura) ed è l’Anagrafe delle Attività Economiche e Produttive (AAEP) che ospita più di 5 milioni di imprese italiane attive appartenenti a tutti i settori produttivi;

19

(InfoCamere - Registro delle Imprese: copertura delle imprese alimentari in regione emilia romagna)

2) Altra fonte certa di informazioni è l’Anagrafe delle Imprese Agricole

utilizzata dall’Agenzia per le Erogazioni in Agricoltura (AGEA) la cui emanazione regionale è AGREA che ospita, a livello regionale, circa 70.000 imprese del settore agricolo;

3) Altra fonte certa di informazioni è la BANCA DATI NAZIONALE

(BDN) Anagrafe Zootecnica gestita centralmente dall’Istituto Zooprofilattico Sperimentale (IZS) di Teramo, che ospita gli allevamenti attivi delle specie da macello;

4) Altra fonte certa di informazioni è SINTESI che gestisce i

riconoscimenti degli stabilimenti che rientrano nell’ambito di competenza del Regolamento n. 853/2004/CE.

20

3.06.01 InfoCamere – Registro Imprese L’archivio costituisce la base del Portale Imprese Nazionale, ed è organizzato secondo il seguente diagramma relazionale:

(tratto da Toselli – Conferenza Utenti SIT - Provincia di Bologna – gennaio 2002)

In particolare nelle entità Impresa e Unità Locale troviamo le seguenti informazioni:

21

Nella tabella IMPRESA la chiave primaria ed univoca è il CODICE FISCALE che rimane immutato durante tutto l’arco della sua esistenza, anche a fronte di cambiamenti della Sede Legale (mentre la P.IVA cambia ogni volta che la ditta trasferisca a propria sede legale in un’altra provincia). Nella tabella UNITA’ LOCALE la chiave primaria ed univoca è un identificativo progressivo a livello nazionale “ID_UNITA_LOCALE”; essa si relaziona in rapporto molti a uno con la tabella IMPRESA tramite la chiave esterna CODICE FISCALE; nel campo “tipo localizzazione” viene specificato se si tratta di “sede legale” (codice “0”) o di “sede secondaria” o di “unità produttiva locale”; nel campo “tipo U.L.” si classifica la struttura (per es. “azienda agricola, ambulatorio, ufficio tecnico, ecc.”); vengono poi riportati nella tabella “ATTIVITA’ ISTAT U.L.” i codici Istat di attività Ateco2002 per ogni U.L. Punti forti: - L’archivio offre la copertura pressoché totale sul numero di imprese

presenti sul territorio. - Il sistema è integrato con la banca dati Sistema Informativo Agricolo Nazionale (SIAN) che garantisce in particolare la copertura anche per le imprese agricole

- Utilizzo del codice univoco di impresa che è il CODICE FISCALE:

in conclusione L’Impresa corrisponde univocamente alla ns. DITTA.

22

- Per ogni impresa sono riportate le attività produttive dichiarate. Punti deboli: - Le informazioni sono incentrate sulla Impresa (la ns. Ditta), cioè

sulle informazioni sociali, per cui le Unità Produttive in cui le Imprese operano sono “figlie” delle Imprese stesse e vengono registrate con un codice progressivo nazionale univoco. Il punto di debolezza è che per un luogo fisico reale in cui operino due o più Imprese, esistono due o più diverse UU.PP. che non hanno nessuna relazione tra di loro (teoricamente sarebbe possibile associare due o più UU.PP. attraverso l’indirizzo ammesso che questo fosse rigidamente normalizzato): in conclusione la UU.PP. non corrisponde in modo univoco alla ns. STRUTTURA (su questo aspetto però si ha notizia di uno sviluppo in corso per consentire l’allineamento con SINTESI, nell’ambito del progetto del cosiddetto “portale delle imprese”, il che deve prevedere forzatamente il superamento di tale limite).

- Le informazioni sulle attività produttive ivi svolte non sono sufficientemente dettagliate; il loro livello di esattezza e di aggiornamento è migliorato rispetto agli anni passati essendo stato messo in atto l’allineamento con la banca dati di INPS e con la banca dati di INAIL che aggiorna, quest’ultima, in tempo reale le Posizioni Assicurative Territoriali (PAT) di ogni UU.PP. delle Impresa (contestualmente ad ogni inizio o cessazione di rapporto lavorativo individuale).

3.06.02 Banca Dati Nazionale - Anagrafe Zootecnica

Altra fonte certa di informazioni è la Banca Dati Nazionale (BDN) Anagrafe Zootecnica gestita centralmente dall’Istituto Zooprofilattico Sperimentale (IZS) di Teramo, che ospita gli allevamenti attivi delle specie da macello. In questo archivio le entità “ALLEVAMENTI”, “AZIENDE”, “SPECIE” e “TIPO DI PRODUZIONE” sono quelle che contengono le informazioni di interesse per definire rispettivamente le ns. DITTE, le STRUTTURE e le ATTIVITA’.

23

Possiamo trovare finalmente la centralità dell’AZIENDA / STRUTTURA intesa come Unità Epidemiologica oggetto di controllo sanitario con la sua univocità espressa dalla chiave primaria “AZIENDA_ID” attribuita dalla BDN ribadita dal “CODICE” inteso come “Codice aziendale assegnato dall'Azienda USL“; essa si relaziona con diversi ALLEVAMENTI/DITTE con chiave primaria “ALLEV_ID” attribuita dalla BDN ribadita dall’”ID_FISCALE” che coincide con il codice fiscale del proprietario: in un’unica Azienda possono operare dunque più Allevamenti. L’archivio è organizzato secondo il seguente diagramma relazionale:

(schema tabelle BDN tratto da documenta- zione ufficiale IZS – Teramo 2002)

24

Questo tipo di architettura appare dunque, nella logica, opposto a quello del R.I. e, per contro, non permette di gestire da un unica entità normalizzata le informazioni relative alla DITTA che opera in più AZIENDE. Tuttavia anche in questo caso è in corso di sviluppo l’integrazione con il Registro Imprese nel Portale Imprese che necessariamente dovrà prevedere il superamento di tale limitazione. Punti forti: - L’archivio offre la copertura completa per gli allevamenti zootecnici

(ad esclusione, per il momento, di conigli e selvaggina a pelo). - Le informazioni ufficiali contenute sono complete, ufficiali ed

aggiornate. Punti deboli: - La copertura informativa riguarda solo i suddetti allevamenti

zootecnici. 3.06.03 Agenzia per le Erogazioni in Agricoltura (AGEA) –

AGREA (R.E.R.) Altra fonte certa di informazioni è l’Anagrafe delle Imprese Agricole dell’Agenzia per le Erogazioni in Agricoltura (AGEA) la cui emanazione regionale è AGREA che ospita, a livello regionale, circa 70.000 imprese del settore agricolo. l’Agenzia svolge attività di: - organismo pagatore per la Regione di aiuti, contributi e

premi comunitari previsti dall’Unione Europea e finanziati dal FEOGA;

- rilascio dei nulla osta, esecuzione e contabilizzazione

dei pagamenti autorizzati dagli Enti delegati (Province e Comunità Montane);

- collegamento e scambio informativo con l’AGEA, il

Ministero dell’Economia e delle Finanze, la Banca d’Italia circa i flussi di denaro;

25

- collegamento con il Sistema Informativo Agricolo

Nazionale (SIAN).

Punti forti: - Le informazioni ufficiali contenute sono validate ed aggiornate. - Le informazioni relative alle ATTIVITA’ SVOLTE sono dettagliate,

complete ed aggiornate; esse costituiscono in buona sostanza il valore aggiunto di questa banca-dati.

- Le PARTICELLE TOPOGRAFICHE cui fanno riferimento le diverse

colture praticate in ogni Azienda sono geo-referenziate per l’utilizzo in sistemi di cartografia informatizzata GIS (Sistema Informativo Geografico).

Punti deboli: - L‘archivio è incentrato sulle figure fiscali intestatarie delle domande

che corrispondono alle DITTE del modello generale; mentre dal punto di vista informatico-informativo non esiste una entità corrispondente alle STRUTTURE, che è sostituita dalle diverse PARTICELLE TOPOGRAFICHE cui fanno riferimento le diverse colture praticate in ognuna di esse: ciò significa che mancano i “confini” della Struttura, il che rende impossibile distinguere quindi diverse Strutture della stessa Ditta sia all’interno dello stesso comune che a cavallo di comuni limitrofi. In conclusione le ATTIVITA’ SVOLTE sono sicuramente riferibili alla DITTA e corrispondono a quelle svolte dalla STRUTTURA solo nel caso in cui essa corrisponda alla DITTA stessa. Tuttavia non ci si può che attendere un prossimo ed inevitabile sviluppo sul piano dell’integrazione col Registro Imprese.

3.06.04 SINTESI Altra fonte SINTESI che gestisce le informazioni relative agli stabilimenti riconosciuti ai sensi del Regolamento n. 832/2004/CE, e 853/2004/CE).

26

L’archivio è in fase avanzata di integrazione col Registro Imprese nell’ambito di un progetto di cooperazione applicativa con CNIPA attraverso lo strumento del Portale delle Imprese, di cui costituirà parte integrante, per tutta la procedura di registrazione. Punti deboli: - L’archivio è riferito solo ad una parte delle imprese operanti nel

campo della sicurezza alimentare. - Sino ad ora, nella descrizione della DITTA, era consentito l’utilizzo

della Partita IVA in alternativa al Codice Fiscale; ciò risulta tuttavia in fase di superamento, proprio al fine di rendere possibile l’interfacciamento col Registro Imprese.

Punti forti: - Le informazioni ufficiali contenute sono validate ed aggiornate. - Contiene l’”Approval Number” univoco per ogni STRUTTURA

autorizzata. - Le informazioni relative alle ATTIVITA’ SVOLTE sono dettagliate,

complete ed aggiornate; esse costituiscono in buona sostanza il valore aggiunto di questa banca-dati.

3.07 INTEGRAZIONE ANAGRAFICHE LOCALI - PORTALE

DELLE IMPRESE

Pur con i limiti attuali dei citati archivi informatici (es. codifica delle attività ed estrazione di set di dati) si può ragionevolmente asserire che tutte le imprese soggette agli obblighi del regolamento 852/04 e 853/04 sono già registrate in almeno un archivio tra quelli elencati (INFOCAMERE) e nel caso esse compaiano in uno o più degli altri tre, questi aggiungono informazioni solo sul piano delle ATTIVITA’ PRODUTTIVE ivi svolte, integrando quanto presente sul primo. Proprio per il fatto che la stessa impresa possa essere presente su più di un database, i gestori degli archivi hanno da tempo previsto una correlazione delle rispettive anagrafiche in modo tale da garantire la sincronizzazione dei dati: tale progetto è seguito dal CNIPA (Centro Nazionale per l’Informatica nella Pubblica Amministrazione) costituito nel

27

2003 ed operante presso la Presidenza del Consiglio dei Ministri per l’attuazione delle politiche del Ministro per l’Innovazione e le tecnologie. Il progetto, co-finanziato dal Ministero delle infrastrutture e dal Ministero della salute, è in fase avanzata di sviluppo ed in buona parte già operativo; esso fa riferimento al sito “www.impresa.gov.it” ed è comunemente denominato come PORTALE delle IMPRESE. Esso è rivolto ad utilizzare un punto di accesso unico delle imprese, per la registrazione delle aziende sottoposte agli obblighi del regolamento 852/04 ed il riconoscimento ai sensi del regolamento 853/04. Da tutto ciò deriva la opportunità di valutare attentamente il possibile utilizzo delle informazioni residenti nel Registro Imprese (RI) esposto come servizio dal Portale delle Imprese (PI), al fine di integrare da un lato le anagrafiche locali delle AUSL e dall’altro, secondo la filosofia del Sistema di Pubblica Cooperazione (SPC), di contribuire all’aggiornamento del RI stesso. E’ inoltre in fase avanzata di predisposizione l’utilizzo, da parte degli enti locali della RER, del portale di servizi web PARIX GATE, per l’accesso alle informazioni residenti nel Imprese (RI) stesso; tale possibilità trae origine da una convenzione recentemente stipulata tra RER ed InfoCamere, proprio al fine di aggiornare i dati all’interno dei propri archivi di Aziende. 3.08 IPOTESI DI ALLINEAMENTO DELLE ANAGRAFICHE

LOCALI COL “REGISTRO IMPRESE” Tale attività deve prevedere necessariamente due fasi distinte:

A) Fase di allineamento dei dati storici già presenti in RI.

B) Fase di mantenimento dell’allineamento dei dati futuri rispetto ad un tempo iniziale di utilizzo on line del sistema (T-0).

La PRIMA FASE (A) a sua volta prevede varie azioni:

AZIONE A.01) Implementazione di una tabella di INTERFACCIA tra RI (nell’ambito del PI) e anagrafica AUSL, dalla quali risulti

28

la corrispondenza (molti a molti) tra le UNITA’ LOCALI di RI che abbiano una corrispondenza nei record della tabella UTENTI di AUSL. Tale tabella dovrebbe essere costituita essenzialmente dai campi che individuano le chiavi univoche (PK) di entrambe le tabelle (“ID UNITA LOCALE” per RI da un lato e la combinazione di “AUSL-DISTRETTO-CED-SERVIZIO” per UTENTI dall’altro).

Si rappresenta di seguito lo schema delle informazioni considerate:

Tale azione sarebbe completamente manuale con costi di data entry rilevanti soprattutto per gli archivi SIAN locali, mentre per gli allevamenti Veterinari si potrebbe operare con automatismi da BDN incrociando il CODICE ALLEVAMENTO o recuperando in parte l’incrocio con il CODICE FISCALE della Ditta.

AZIONE A.02) Verifica dell’ALLINEAMENTO delle ATTIVITA’ registrate su RI rispetto ad AUSL, con la conseguente VALIDAZIONE delle CORRISPONDENZE ed EVIDENZIAZIONE delle INCONGRUENZE.

29

AZIONE A.03) Attivazione di una procedura di VERIFICA finalizzata a concludersi con la certificazione su RI della attività realmente svolta dall’impresa ed allineata presso AUSL.

AZIONE A.04) Inserimento delle imprese del settore alimentare presenti in RI e NON PRESENTI in precedenza su UTENTI di AUSL. Tale azione sarebbe completamente automatica e con costi che si presume nulli (almeno per l’ottenimento dei dati) legati alla convenzione in atto tra l’ente Regione Emilia Romagna ed UnionCamere.

L’azione si svilupperebbe col seguente schema operativo:

E’ sottintesa, oltre che automatica, l’importazione su AUSL anche di tutte le ATTIVITA’ registrate su RI per ogni UNITA’ LOCALE .

Al termine di tale azione, negli archivi AUSL sarebbero presenti tutte le imprese che operano nel settore primario fino ad ora estranee o solo marginalmente coinvolte dai controlli alimentari (az. Agricole con soli prodotti vegetali).

30

AZIONE A.05) Attivazione di una procedura di ANALISI degli UTENTI presso AUSL che non hanno trovato riscontro su RI, al fine di:

• definirne la “cessazione”

• trovare un nuovo allineamento su RI

• mantenere tale UTENTE su AUSL registrandone il motivo di assenza su RI.

Criticità:

Gli UTENTI presenti in doppio su AUSL (diversi distretti o diversi servizi possono riportare occasionalmente gli stessi utenti) devono avere una codifica ALIAS che identifichi uno solo dei record presenti in AUSL come il principale a cui riferirsi per mantenere una “univocità informativa” riferita al luogo oggetto di controllo da parte di diverse componenti dell’AUSL (operatori di diversi servizi o distretti).

Meglio ancora, se la tempistica lo consente, sarebbe procedere prima ad una pulizia dell’archivio ditte locale presso la AUSL e solo in un secondo momento all’importazione dei dati nell’archivio centrale AROSA.

Terminata la prima, inizia la SECONDA FASE (B) , che prevede:

AZIONE B.01) Attivazione di un servizio di SCAMBIO DATI in tempo reale tra RI e anagrafica AUSL locale (attraverso la tecnologia della “porta di dominio” descritta più avanti). Deve quindi essere attivo un meccanismo che funzioni in modo da proporre all’attenzione dell’AUSL l’evento di:

- REGISTRAZIONE di una nuova Impresa del settore alimentare (evento Insert su database RI);

- MODIFICA di dati anagrafici (SEDE o VOLTURA) o di dati produttivi (ATTIVITA’) (evento Update su database RI) ;

- CANCELLAZIONE (evento Delete su database RI).

I dettagli tecnici di tale azione andranno necessariamente richiesti al gestore del PI.

31

Con tale fase si assicurerà il mantenimento dell’allineamento dal momento T0 in poi.

Alla luce del recente aggiornamento della normativa regionale, in adempimento con quanto previsto dalla normativa europea, gli OSA attualmente devono inviare alla AUSL di riferimento territoriale la NOTIFICA di inizio/modifica/cessazione di attività, ricevendo di ritorno il NUMERO di REGISTRAZIONE della notifica stessa.

Contestualmente a tale evento l’AUSL potrebbe in questo modo verificare l’allineamento tra quanto notificato e quanto registrato presso RI, importando direttamente i DATI SOCIALI ed aggiornando o segnalando eventuali difformità relativamente ai DATI di ATTIVITA’ su RI (d’intesa con InfoCamere).

Criticità:

Và comunque fatta salva negli applicativi AUSL la possibilità di forzare i controlli predisposti per mantenere l’allineamento, al fine di consentire l’inserimento/modifica/cancellazione di UTENTI che non abbiano un corrispondente in RI (ad es. il Privato cittadino o l’ente oggetti di attività da parte dei servizi).

3.09 ASPETTI ORGANIZZATIVI DELL’ALLINEAMENTO DELLE ANAGRAFICHE

L’allineamento delle anagrafiche locali AUSL con quella ufficiale di RI si presenta come l’elemento strategico fondamentale al fine di predisporre un sistema informativo regionale che abbia al centro la qualità delle informazioni sulle imprese oggetto dei controlli (ufficialità, completezza, aggiornamento) nonché l’implementazione automatica delle informazioni stesse in futuro. L’investimento su questo versante appare ampiamente giustificato. L’ordine di grandezza del lavoro da svolgere si può quantificare in 250.000 unità anagrafiche da verificare ed allineare, per cui occorre attuare la massima ottimizzazione possibile delle risorse, sfruttando al massimo le possibilità di automazione (per es. l’incrocio delle

32

informazioni relative agli indirizzi) nel tentativo di ridurre al minimo l’intervento manuale. A tal fine la soluzione ottimale potrebbe essere quella di operare per “strati” di informazioni e con “delocalizzazione” degli interventi, come si descrive di seguito.

1) Inizialmente si deve disporre (utilizzando lo specifico accordo con UnionCamere nell’ambito della convenzione con RER) dell’elenco completo delle IMPRESE registrate su RI e delle relative UU.LL. ed ATTIVITA’, nonché dell’elenco completo di UTENTI di ogni servizio AUSL, filtrato per le sole attività alimentari.

2) A questo punto si considerano i soli UTENTI che in AUSL possiedono codifiche ufficiali (CODICE AZIENDA, CODICE FISCALE, PARTITA IVA, CCIAA ) che permettano di trovare rapidamente la corrispondenza con IMPRESA ed una o più UNITA’ LOCALE (UU.LL.) di RI, fermo restando la necessità di convalida manuale dell’allineamento. Questa operazione può essere resa più veloce da una applicazione specifica, da creare a tale scopo, che permetta di procedere alla selezione dell’ UU.LL. tramite mouse, da una griglia di possibili UU.LL. selezionabili. Poiché le informazioni da confrontare (Denominazione dell’Impresa, Indirizzo della UU.LL.) sono ben comprensibili da parte dell’operatore, questa operazione potrebbe essere delocalizzata dall’AUSL ed affidata ad un gruppo ristretto e specializzato che operi per tutte le AUSL della RER. Al termine di questa fase sarà stato allineato il primo strato di UTENTI, che si stima tuttavia non superiore al 5% del totale.

3) L’azione successiva si sviluppa con le stesse modalità organizzative della precedente, confrontando tutti gli UTENTI rimasti con la Denominazione della Ragione Sociale dell’Impresa e l’Indirizzo della UU.LL. su RI (filtrando preventivamente il Comune). Si stima che si possa allineare in questo modo un secondo strato i UTENTI non inferiore ad un altro 50% del totale (soprattutto per il SIAN), in cui i dati confrontati diano la certezza della identificazione e quindi dell’allineamento.

33

Il restante 45% sarà costituito da tutti gli UTENTI che non hanno trovato un riscontro certo su RI per i seguenti motivi:

• Ragione Sociale corretta o simile su RI, Indirizzo UULL diverso (terzo strato 10%).

• Ragione Sociale troppo diversa su RI, Indirizzo UULL trovato (quarto strato 10%).

• Nessun riferimento riscontrato su RI (Ragione Sociale, Indirizzo UULL, Attività) (quinto strato 25%).

4) Questi insiemi di Utenti “con eccezioni” dovranno essere gestiti dai Servizi locali che li verificheranno direttamente, provvedendo quindi alla loro validazione con allineamento rispetto ad RI, oppure alla loro esclusione da tale processo.

5) Per contro risulteranno su RI Imprese alimentari con UU.LL. senza riscontro negli archivi locali. Queste si dividono sostanzialmente in due sotto-insiemi:

• Imprese che non esercitano attività alimentari, le cui informazioni saranno da aggiornare su RI.

• Imprese che esercitano attività alimentari, che saranno da importare negli archivi locali. Tra queste ultime in particolare troveremo tutte le imprese del settore primario che non esercitano attività di allevamento.

Questo allineamento si presenta come la parte più impegnativa per i Servizi locali e necessita di una accurata pianificazione che preveda una serie di test mirati a quantificare le risorse effettivamente necessarie. Tali prove vanno effettuate su campioni significativi di Utenti nelle diverse anagrafiche locali.

Criticità’:

Il fattore critico principale di questa operazione consiste sicuramente nella QUANTITA’ di UTENTI presenti negli archivi locali, che non corrispondono ad Aziende oggetto di controllo, ma sono presenti perché oggetto di prestazioni occasionali (ad es. privati cittadini che richiedono

34

interventi per inconvenienti igienici, o proprietari di cani morsicatori, o allevatori di suini per consumo famigliare). La soluzione a questo problema consiste in un’attenta politica di esportazione dei dati da sottoporre ad allineamento, filtrando ed escludendo i possibili “falsi UTENTI” confondenti.

Un altro aspetto che presenta problemi tecnici è dato dal fatto che le Aziende presenti in BDN, mantengono sugli archivi locali delle AUSL la struttura logica di BDN (al fine di consentirne il dialogo per l’aggiornamento reciproco dei dati): ciò significa che esse non corrispondono alla “forma” degli altri OSA, perché le Aziende sono puri contenitori di Attività di Allevamento che possono essere esercitate da OSA differenti. Tale questione necessita di una condivisione preventiva col gestore regionale per valutare eventualmente di considerare i singoli Allevamenti come OSA e non le singole Aziende BDN.

La soluzione ipotizzata infatti appare più coerente con il resto dell’archivio AROSA, pur prevedendo una parziale autonomia da quanto registrato su R.I.

3.10 AGGIORNAMENTO ED INTEGRAZIONE DELLE

ANAGRAFICHE LOCALI NELL’ ELENCO REGIONALE DELLE AZIENDE ALIMENTARI

Una volta allineate le diverse anagrafiche locali, queste potranno essere accorpate in un database centrale secondo il modello precedentemente analizzato che permetterà di agganciare le informazioni presenti sulla replica disponibile centralmente di Registro Imprese con l’Interfaccia di decodifica degli archivi locali delle AUSL.

Saranno disposti sistemi di aggiornamento dei dati dal Registro Imprese, al Portale Regionale che provvederà a mantenere aggiornate le base dati delle AUSL per gli eventi di:

• Creazione di una nuova Impresa Alimentare o UU.LL della stessa;

• Modifica di dati (sociali, o strutturali, o di attività);

• Cessazione della stessa.

35

La tecnologia utilizzabile per queste operazioni automatiche sarà descritta più dettagliatamente nel capitolo che tratterà del Sistema Pubblico di Connettività (SPC) e Cooperazione Applicativa, che segna la nuova frontiera della integrazione telematica disegnata dal progetto europeo di eGovernment.

In alternativa, appena mature le condizioni tecnologiche, sarà preferibile una interazione diretta tra gli applicativi locali delle AUSL ed i dati esposti da RI attraverso i web services esposti dal portale PARIX GATE, grazie al suddetto accordo intervenuto tra RER ed Union Camere.

S.I. RER

36

4. IL SISTEMA INFORMATIVO REGIONALE INFORMATIZZATO

4.01 L’ARCHITETTURA DEL SISTEMA CENTRALE

Attorno alla implementazione della Anagrafe degli OSA in un registro centrale regionale, potrà svilupparsi in maniera modulare, e giungere a realizzare in tempi successivi, la raccolta delle informazioni relative alle Imprese stesse (quali oggetti controllabili), e dei controlli in esse effettuati dagli organi preposti, in modo da configurare un vero e proprio Sistema Informativo Regionale Informatizzato.

Tutta l’architettura del sistema mirante ad una integrazione tra centro e periferia, pur nella salvaguardia e nel mantenimento delle scelte applicative autonome e diversificate delle AUSL, si basa sulla adozione di una base dati centrale la cui struttura sia interfacciabile dalle diverse banche dati locali periferiche attraverso l’esposizione di servizi web, od in una prima fase transitoria, per le realtà meno evolute dal punto di vista telematico, attraverso l’esportazione su di essa di un tracciato record condiviso.

In particolare tale sistema si può distinguere in due grandi aree funzionali:

A) Il DATABASE

intesa in senso tradizionale, che raccoglie tutte le tabelle relative alle Imprese Alimentari (allineate ed aggiornate), ed ai relativi controlli ivi effettuati. Questa può essere interrogata con gli strumenti più svariati di quering (da Access a Business-Objects) e reporting (ad es. Crystall Report). Su di essa possono poi innestarsi tutti i possibili strumenti di front-end (maschere windows o web) senza limiti di implementabilità.

37

B) La PORTA di DOMINIO

che, attraverso un apposito CENTRO SERVIZI REGIONALE (CSR) ufficiale (per la cui descrizione si rimanda al capitolo del Sistema Pubblico di Connettività), permette di raccogliere gli aggiornamenti del Registro Imprese, mantenere allineato la propria base dati centrale di cui al punto precedente ed infine mettere a disposizione tali aggiornamenti sulle Imprese per le banche dati delle AUSL, tramite semplici web services, od eventualmente con l’utilizzo di specifiche PORTE di DOMINIO delle AUSL.

Oltre a ciò il CSR è in grado di acquisire a sua volta gli aggiornamenti dai diversi S.I. delle AUSL, relativi ai controlli effettuati.

Le informazioni potranno essere caricate sul database regionale, in modalità modulare, cioè per blocchi specifici attivabili in tempi successivi; tali ambiti potranno riguardare la categorizzazione del rischio di ogni azienda alimentare, i controlli e gli audit ivi effettuati nel tempo, nonché le verifiche ed i campionamenti svolti.

Compatibilmente con le rispettive possibilità tecniche, le AUSL potranno autonomamente e preventivamente interagire col Registro Imprese come già detto, utilizzando la convenzione stipulata tra RER ed Union Camere per l’accesso a RI tramite PARIX GATE.

38

4.02 RACCOLTA DELLE INFORMAZIONI SULLA CATEGORIZZAZIONE DEL RISCHIO

Il primo blocco di informazioni attivabile potrebbe essere proprio quello relativo alla categorizzazione del rischio per ogni azienda alimentare. Oltre alla completezza intrinseca di un archivio informativo del genere, occorre pensare alla possibilità di effettuare confronti sia di tipo trasversale, che permettano di valutare il valore medio e le principali variabili statistiche riferite ad ogni tipologia produttiva, sia di tipo verticale (confronto sui valori attribuiti da organi di controllo di diversi ambiti territoriali, a tipologie produttive analoghe). Mentre la prima valutazione produrrebbe indicazioni di carattere gestionale (cioè si saprebbe in quali tipologie produttive sarebbe più opportuno concentrare i controlli, col suffragio di una base informativa regionale di portata globale), la seconda farebbe emergere gli scostamenti dal giudizio medio (ovvero quali organizzazioni esprimono giudizi sul rischio particolarmente diversi dagli altri, con riferimento ad una certa tipologia produttiva). Tale informazione risulterebbe particolarmente utile per mirare audit regionali nei confronti di tali situazioni, al fine di valutare se esiste un grado di rischio aderente a quanto dichiarato dall’organo di controllo, oppure se esiste un problema di disomogeneità nella composizione del giudizio stesso, cui porre rimedio con opportuni interventi formativi. Dunque in sintesi la prima indicazione permetterebbe ai Servizi Regionali di svolgere il proprio compito di indirizzo delle azioni locali, con un approccio scientifico e trasparente; la seconda indicazione aumenterebbe l’efficenza e l’efficacia delle azioni legate al compito di controllo delle azioni locali stesse. Per procedere alla acquisizione della informazione relativa al grado di rischio ricoperto dalle attività alimentari svolte presso ognuna delle UU.LL. presenti nell’Anagrafe Regionale, si possono adottare due diverse strategie:

a) Raccogliere nel database centrale solo il giudizio sintetico sul grado di rischio rilevato.

39

b) Raccogliere nel database centrale l’intera griglia di valutazione compilata per ogni attività registrata.

4.02.01 GRIGLIE DI VALUTAZIONE Qualsiasi opzione venga scelta, si dà per acquisito il fatto che presso tutti gli operatori debbano essere utilizzate griglie specifiche per ogni tipo di attività e di rischio individuato, e che soprattutto queste siano condivise ed ufficiali. Per poter raccogliere le informazioni relative alla categorizzazione del rischio, inoltre occorre risolvere preliminarmente il problema di riuscire trasformare la struttura delle informazioni di partenza da una griglia a matrice (una griglia per ogni attività di ogni azienda, con informazioni nelle colonne ed altre nelle righe, come rappresentata nella illustrazione seguente) …

… ad una struttura tabellare, tipica dei database relazionali, in cui tutte le informazioni sono su un unico vettore dove vengono elencati i “campi”, mentre ogni riga rappresenta un diverso soggetto.

40

Nell’esempio sopra riportato, si mostra la soluzione tabellare che rappresenta la parte iniziale della griglia di valutazione relativa al rischio di un’azienda che alleva bovini da latte. Nel database centrale dunque ogni specifico rischio può essere codificato in una specifica LISTA DI RISCHIO ed ogni azienda può essere messa in correlazione con un numero illimitato di LISTE DI RISCHIO attraverso una tabella RISCHI, dove attraverso una chiave primaria costituita da ”ID UNITA LOCALE” e “COD. ATTIVITA AUSL”, ad ogni attività svolta in ogni Unità Locale, corrispondono le relative liste di rischio, secondo lo schema rappresentato a fine paragrafo. A tale forma strutturata delle informazioni nel database regionale centrale, i diversi sistemi locali delle AUSL dovrebbero improntarsi secondo specifiche funzioni di estrazione dei dati ed esportazione (in tempo reale, attraverso web services e/o porta di dominio per le realtà più evolute, oppure periodica, con spedizione di files ASCII su specifico tracciato record).

41

(Schema del database per la gestione della categorizzazione del rischio tramite LISTE di RISCHIO)

4.03 RACCOLTA DELLE INFORMAZIONI SUI CONTROLLI EFFETTUATI

La stessa infrastruttura tecnologica con interfacciamento dei dati locali in una struttura condivisa e disponibile centralmente, permetterebbe di raccogliere tutti i controlli effettuati nelle UU.LL. alimentari.

Tali informazioni potrebbero essere raccolte nelle seguenti maniere:

42

A) in forma sintetica ed aggregata come nei report cartacei attualmente in uso

i. Vantaggi: viene mantenuto l’attuale impostazione del debito informativo tra AUSL e RER.

ii. Criticità: questo metodo necessita di una procedura di aggregazione dei dati unica per tutte le diverse banche dati locali, difficilmente praticabile, per poter effettuare confronti utili tra le diverse realtà organizzative.

1. Il difetto principale di questo sistema è che per ogni colonna (per es. ”Ispezione della struttura ed attrezzature”) scatta una unità nella rilevazione sia che venga effettuata una ispezione approfondita, sia che essa sia stata più sbrigativa, dunque l’informazione è intrinsecamente ambigua e come tale mina alla base la credibilità e l’utilità del sistema.

43

B) sotto forma di schede di controllo e di non conformità informatizzate.

44

Vantaggi: con questo metodo, si hanno informazioni puntuali (si ottengono cioè delle tabelle in cui ogni riga rappresenta un controllo) e si possono effettuare confronti tra le modalità operative impiegate (oggetto delle verifiche, frequenza dei controlli e delle verifiche); oltre a ciò è possibile entrare nel merito delle non conformità riscontrate.

Criticità: questo metodo fornisce solo informazioni “di superficie” sulle verifiche effettuate, ovvero descrive l’ambito della verifica effettuata, ma non la sua profondità; oltre a ciò (e questo è sicuramente il limite maggiore di questo sistema) non si riesce a codificare (se non per ambito di controllo) l’irregolarità riscontrata, che viene infatti descritta in maniera discorsiva: non è quindi aggregabile una informazione puntuale relativa all’oggetto della irregolarità riscontrata, nonché alla gravità della stessa.

45

C) sotto forma di LISTE DI RISCONTRO (Check list)

Vantaggi: con questo metodo, si hanno tutte le informazioni di base relative ai controlli, alle verifiche ed ai loro esiti, in maniera perfettamente codificata e facilmente elaborabile.

Criticità: questo metodo presuppone

• un investimento in termini di risorse umane da parte dei Servizi Regionali ed AUSL, finalizzato alla redazione di liste di riscontro condivise, per le varie tipologie produttive oggetto di controllo.

• un investimento in termini tecnologici da parte dei Servizi AUSL, per l’acquisizione di un idoneo software utilizzabile con palmari, in grado di assistere l’operatore nella registrazione delle informazioni, durante le ispezioni.

• un investimento per le AUSL in termini di formazione degli operatori e di apparecchiature (palmari e stampanti portatili).

46

Di seguito si rappresenta lo schema che dovrebbe avere la base dati per riuscire a gestire un numero illimitato di Liste di Riscontro e di Provvedimenti riferibili ad ogni controllo effettuato in qualsiasi UU.LL. in Anagrafica.

Per la raccolta delle informazioni relative ai controlli effettuati, si può ipotizzare una gradualità che preveda le tre diverse soluzioni applicate a distanza di tempo, partendo dalla prima fina alla terza.

In realtà se analizziamo bene la prima soluzione ci rendiamo conto che essa non costituisce nulla di più di una trasmissione telematica dell’attuale reportistica, dunque tale soluzione (al di là delle valutazioni sulla utilità maggiore o minore delle informazioni aggregate) non risolve l’attuale problema nell’ottenere automaticamente la reportistica cartacea dai sistemi in uso presso le AUSL. Ci si riferisce in particolare alla produzione automatica delle schede SISVET, che si presenta come un annoso problema, e che rappresenta la pre-condizione necessaria (anche se non sufficiente) per sviluppare

47

qualsiasi metodo di raccolta dati informatizzato a livello centrale regionale. Al momento con i programmi attualmente in uso ciò non appare scontato, anche se le aziende che operano nel settore stanno iniziando ad implementare i loro prodotti attraverso l’utilizzo di database aderenti allo standard SQL (Structured Query Language) che facilitano enormemente la produzione di report automatici ed esportabili nei più comuni protocolli di scambio dati (ad. es. XML - eXtensible Markup Language). 4.04 RACCOLTA DELLE INFORMAZIONI SUI

CAMPIONAMENTI EFFETTUATI La creazione di un flusso di dati informatizzato che alimenti il database centrale del S.I. RER non può che intendersi con il risultato di un processo di informatizzazione che veda come attori sia i Servizi delle AUSL che i relativi LABORATORI di riferimento (ARPA ed IZS - Istituto Zooprofilattico Sperimentale di Brescia). 4.04.01 SPERIMENTAZIONE SUL CAMPO Si ha notizia di un progetto avviato dall’IZS, cui partecipa l’AUSL di Parma, per la Regione Emilia Romagna, che sembra possedere tutte le caratteristiche per servire da paradigma sia per uno sviluppo in tal senso nei confronti di ARPA, sia per tutte le altre AUSL della regione. Come documentato nell’Allegato D “Sistema integrato IZSLER – ASL Lombarde ed Emiliane”, nello scorso anno è partito un progetto che mira a permettere l’integrazione dello scambio dati tra l’applicativo “DARWin” in uso presso l’IZS e quelli delle applicazioni locali nelle Ausl, attraverso l’utilizzo di web services “consumabili” direttamente dai diversi programmi in uso. Tale sistema, già in fase di test avanzato, prevede due modalità di funzionamento, a seconda delle necessità operative:

1) Prima modalità, cosiddetta di “PRE-ACCETTAZIONE” del

campione, così strutturata:

48

a) Fase di PRE-ACCETTAZIONE, in cui le informazioni relative al campionamento vengono copiate dal Verbale di Prelevamento ed inserite manualmente in un programma locale c/o la Ausl (Servizi Veterinari) che attraverso web-services manda i dati al laboratorio dell’IZS.

b) Fase di ACCETTAZIONE da parte del Laboratorio al momento

della ricezione del campione per l’analisi, che verifica la congruità dei dati inseriti dall’Ausl ed aggiunge informazioni di pertinenza (data, ora e modalità del conferimento, temperatura del campione, ecc.).

c) Fase di REFERTAZIONE automatica con invio dei dati relativi agli esiti, dal Laboratorio all’Ausl.

2) Seconda modalità, detta di “ACCETTAZIONE MINIMALE” del campione, formata da:

a) Fase di ACCETTAZIONE MINIMALE, in cui il

laboratorio riceve il campione prima che l’AUSL abbia caricato i dati sul proprio sistema, e procede quindi ad una registrazione di alcuni parametri preliminari relativi al campione stesso conferito (conferente, data, ora e modalità di consegna, finalità, ricerche richieste, ecc.) indispensabili per avviarne il processo di analisi, e resta in attesa del completamento delle informazioni da parte dell’Ausl.

b) Fase di POST-ACCETTAZIONE in cui l’AUSL carica

nel proprio programma locale i dati relativi al campione conferito.

c) Fase di PERFEZIONAMENTO della ACCETTAZIONE, in cui il sistema dell’IZS, dialogando con quello dell’Ausl, completa i dati mancanti nella fase (a).

d) Fase di REFERTAZIONE automatica con invio dei dati relativi agli esiti, dal Laboratorio all’Ausl.

49

L’aspetto più interessante dal punto di vista dell’analisi informativa svolta, è rappresentato dalla soluzione adottata per allineare l’Anagrafe degli UTENTI dell’AUSL con quella dell’IZS; in questo caso infatti si è deciso di mantenere sempre traccia del Codice AUSL dell’UTENTE tra i dati del campione e del referto analitico, quindi il referto informatizzato si “aggancia” automaticamente all’UU.LL dell’Anagrafica oggetto del campione.

4.04.02 INTEGRAZIONE TRA S.I.RER E SANITA’ VETERINARIA Quanto sopra esposto nel progetto con particolare riferimento al punto 4, si presta a costituire il nucleo di un vero e proprio Sistema Informatico Regionale Integrato di Sanità Pubblica Veterinaria sia in ambito di controllo della Sicurezza Alimentare, sia della Sanità Animale: infatti quanto riferito alla raccolta di informazioni derivante dall’attività di campionamento in campo alimentare, si applica analogamente anche a tutta l’attività di prelevamento matrici nell’ambito della sanità animale. Inoltre, a questo proposito, occorre evidenziare un significativo elemento di analisi, già evidenziato a pagina 34, in relazione alla modalità di registrazione degli Allevamenti nelle Aziende BDN. Infatti le strutture oggetto di controllo in questo caso sono gli Allevamenti, (intesi come le specifiche Attività svolte da società o persone fisiche all’interno delle Strutture Aziendali stesse), mentre negli archivi locali le strutture oggetto di controllo possono impropriamente risultare essere le Aziende stesse. Tali aspetti necessitano dunque di uno specifico approfondimento al fine di definire in maniera univoca e condivisa l’entità da importare sull’archivio centrale regionale come OSA (che non potrà che essere l’Allevamento stesso). In questo campo comunque non occorrerebbe procedere all’allineamento con il R.I., provenendo già i dati da una procedura ufficiale (BDN di Teramo).

50

4.04.03 FLUSSI INFORMATIVI DAI LABORATORI Appare dunque di estremo interesse analizzare quanto le informazioni attualmente in possesso dei laboratori IZS siano già di per sé stesse sufficienti ad alimentare i flussi informativi regionali, ed eventualmente di quali integrazioni necessiterebbero a tal fine.

A tal proposito si riporta di seguito il lungo elenco dei flussi informativi regionali che coinvolgono i campionamenti / prelievi di matrici animali.

CODICE FLUSSO

DENOMINAZIONE

FLUSSO INFORMATIVO

7 Controlli veterinari Stabilimenti carni fresche 9 Piano Nazionale Residui 11 Piano Nazionale Alimentazione Animale 12 Vigilanza su alimentazione animale in materia di BSE 13 Dati di sintesi sul controllo ufficiale dei prodotti alimentari 16 Piano di controllo ufficiale su commercio ed impiego prodotti

fitosanitari 22 Piani di eradicazione della Tubercolosi, Brucellosi e Leucosi

Bovina Enzootica 23 Piano Nazionale di Sorveglianza della WEST NILE DISEASE 24 Piani di sorveglianza Malattia Vescicolare Suina. Peste Suina

Classica 25 Piano Nazionale di controllo della salmonella nei gruppi da

riproduzione della specie Gallus gallus 26 Indagine di riferimento sulla diffusione della salmonella in

tacchini nella UE 27 Piano regionale di sorveglianza Salmonelle galline ovaiole da

consumo 28 Indagine di riferimento sulla diffusione della salmonella in suini

al macello nella UE 29 Indagine di riferimento sulla diffusione della salmonella in

esemplari da carne di Gallus gallus (broilers) 30 Sorveglianza TSE 32 Piano di controllo della Malattia di Aujeszky 34 Sorveglianza Influenza aviare Piano nazionale monitoraggio 38 Piano di sorveglianza sulla fauna selvatica, in attuazione del

Regolamento 42 SISVET (Sistema informativo Servizio Veterinario Regionale)

51

43 Sistema Regionale di sorveglianza Micotossine nei mangimi, latte, prodotti a base di latte, cereali, altri prodotti vegetali e derivati

44 Misure di controllo per Listeria monocytogenes nei formaggi 45 Salmonella e Listeria nelle carni USA 46 Piano di monitoraggio Contaminazione carni con tessuto

nervoso 47 Piano Nazionale genotipizzazione Scrapie 48 Piano Regionale di controllo ufficiale degli alimenti e mangimi

per la ricerca di OGM

Dalla quantità di flussi informativi regionali alimentati da informazioni relative ai campionamenti ed alle analisi di laboratorio, si comprende l’importanza di un sistema che permetta la raccolta presso gli IZS delle informazioni utili a tal fine e lo scambio automatico delle stesse con il S.I. RER centrale. Attualmente i laboratori dell’IZS mettono a disposizione dei Servizi AUSL, che conferiscono loro i campioni /prelievi, le seguenti informazioni, indipendentemente dall’area di riferimento (sicurezza alimentare o sanità animale), in un file che può essere trasmesso in aggiunta alla tradizionale certificazione cartacea sull’esito degli esami richiesti. L’invio dei dati informatizzati, secondo la frequenza concordata (anche giornaliera), è asincrono (e più veloce) rispetto alla fornitura della certificazione cartacea che comunque viene sempre prodotta. Le informazioni presenti nel suddetto file sono raccolte in un’unica tabella strutturata nei seguenti campi:

CAMPIONI_IZS

Anno Conferimento

Numero_Conferimento

Data_Conferimento

Distretto

Data_Prelievo

Proprietario

Verbale

52

Codice_Allevamento

Campione

Prova

Tecnica

Esito

Metodo_di_Prova

Istanza

Reparto_IZSLER

Laboratorio_IZSLER

Dettaglio_P

Dettaglio_S

Fine_Analisi

Destinatario_RDP Ogni record della tabella è costituito da una RICERCA relativa ad un certo campione conferito, e vi è riportato lo specifico ESITO. La logica di creazione dei record è la seguente: Le prime otto informazioni sono relative alle informazioni fisse contenute nel VERBALE di conferimento. Vengono riportati sia gli estremi del conferimento dal punto di vista del IZS (ANNO_CONFERIMENTO e NUMERO_CONFERIMENTO, DATA_CONFERIMENTO) che le informazioni presenti nel Verbale dell’AUSL (VERBALE, inteso come numero dello stesso, DISTRETTO e DATA_PRELIEVO), nonché i riferimenti della struttura soggetta al controllo (PROPRIETARIO e CODICE_ALLEVAMENTO, nel caso si tratti di un allevamento). Di particolare interesse il fatto che viene trascritto il numero progressivo del CAMPIONE che identifica ognuno dei campioni citati nel Verbale (ad es. le 10 provette con prelievi di sangue per 10 soggetti presenti in un allevamento, vengono numerate da 1 a 10). Vengono quindi descritte la PROVA condotta e la TECNICA utilizzata per rispondere alla ricerche richieste, per cui se nell’esempio precedente per ogni campione viene richiesta la ricerca di Brucellosi e Leucosi, per ogni campione avremo un record relativo alla PROVA di ricerca “Brucellosi bovina e bufalina da B.abortus/melitensis (anticorpi)” con la tecnica “FdC”, uno relativo alla stessa PROVA di ricerca, ma con la tecnica “SAR”, nonché un terzo

53

record per la PROVA di ricerca “Leucosi Bovina Enzootica (anticorpi)” con la tecnica “AGID”. Per ogni record viene riportato inoltre il relativo ESITO, nonché il METODO DI PROVA ed il riferimento al reparto ed alla sezione di laboratorio che ha condotto l’esame. Per completare l’esempio avremo, in risposta dall’IZS, 30 records di esiti di prova relativi ai 10 campioni conferiti con un unico verbale. Come si può vedere il livello informativo è dettagliato al massimo e permette qualsiasi successiva aggregazione di livello superiore. Nel paragrafo successivo analizzeremo quali altre informazioni necessitano per alimentare i flussi informativi regionali. 4.04.04 LE INFORMAZIONI DA INTEGRARE Come si evidenzia dalla suddetta raccolta del debito informativo regionale, ogni flusso informativo possiede un proprio specifico CODICE di FLUSSO. Ogni flusso va pensato come una aggregazione informativa completamente isolata dalle altre, che deve essere alimentata da uno specifico percorso noto sin dal primo evento rappresentato dall’esecuzione del campione/prelievo: il flusso informativo deve essere quindi indicato quale MOTIVO che origina l’evento stesso. Sarebbe sufficiente riportare nel verbale questo codice, per indirizzare dunque in maniera certa la corretta aggregazione delle informazioni ad esso relative. A questo punto infatti con questa semplice integrazione informativa, dal file dell’IZS si ricaverebbero:

a) il numero di STRUTTURE controllate in un certo periodo per un certo flusso informativo;

b) il numero di CAMPIONI eseguito; c) il numero e la tipologia di PROVE condotte ed i relativi ESITI; d) il servizio (disaggregato per “distretto”) autore dei campioni stessi e

quindi DESTINATARIO del RAPPORTO DI PROVA;

Tali informazioni possono definire in maniera certa ed in tempo reale lo stato di avanzamento del PIANO di CONTROLLO eventualmente definito per ogni flusso informativo. All’occorrenza sarebbe possibile

54

anche definire più piani di controllo all’interno dello stesso flusso informativo, identificabili con uno specifico SUB-CODICE. Particolare attenzione meritano i flussi informativi 13 e 42 (SIAN e SISVET) per le loro implicazioni con i sistemi informativi dei Servizi IAN e Veterinari delle AUSL. Per quanto riguarda le schede SIAN 5 e 7 sotto riportate si nota che i campioni vengono distinti dai tamponi ambientali, che sono aggregati per comparto produttivo e che sono divisi tra “regolari” e “non regolari”. Dunque per rispondere a questo debito informativo occorre aggiungere nel verbale di conferimento il CODICE del COMPARTO (da 1 a 28), nonché la matrice del campionamento, che permette così di differenziare un campione di alimento da un tampone ambientale.

Comparti produttivi (classificati per attività prevalente)

TOTALE CAMPIONI

TOTALE TAMPONI AMB.

PRODUZIONE PRIMARIA

1 Aziende agricole

2 Acquacoltura in acqua dolce / in acqua salata

TRASFORMAZIONE, LAVORAZIONE, CONFEZIONAM.

3 Lavoraz.,trasf.,conserv. frutta e verdura

4 Produzione di estratti alimentari ed affini

5 Produzione di alimenti surgelati

6 Produz. di alimenti per l'infanzia e dietetici

7 Trattamento latte e conservazione latte fresco

8 Trasformazione del latte

9 Produzione gelati ed affini (Lab.artigianali)

10 Mulini e lavorazione affini

11 Produzione di pasta fresca (Lab.artigianali)

12 Industria delle paste alimentari 13 Produzione di pasticceria (Laboratori artigianali) 14 Produzione di pasticceria (Laboratori industriali)

15 Produzione di pane e prodotti da forno

16 Industria del vino

17 Imbottigliamento acque minerali naturali

17 Bis Imbottigliamento acque potabili

55

18 Produzione di semilavorati per industria alim.

19 Altri comparti

RISTORAZIONE

20 Ristoranti ed affini

21 Bar ed affini

22 Mense / centri produzione pasti / terminali di distribuzione:

fino a 250 pasti/giorno

da 251 a 1000 pasti/giorno

più di 1000 pasti/giorno

terminali di distribuzione

23 Gastronomia

24 Fiere-festival-sagre popolari

COMMERCIO

25 Commercio al minuto

26 Supermercati

27 Commercio all'ingrosso prodotti alim., frigoriferi

TRASPORTI

28 Trasporti merci su strada

(Tratto da SIAN 5)

(Tratto da SIAN 7)

Per quanto riguarda in particolare il debito informativo dei Servizi Veterinari si fa riferimento alle schede CAMP 1-1 , CAMP 1-2 E CAMP 2, di cui si riportano di seguito le parti relative agli esami di laboratorio effettuati su campioni/prelievi.

CAMPIONI PRELEVATI totale non regolari PRODUZIONE PRIMARIA

TRASFORMAZ., LAVORAZ., CONFEZION.

BAR - RISTORAZIONE VELOCE RISTORAZIONE TRADIZIONALE RISTORAZIONE COLLETTIVA COMMERCIO AL DETTAGLIO COMMERCIO ALL'INGROSSO TRASPORTI TOTALE

56

(Tratto da CAMP1.1 1Tot. campioni

prelevati) PC: Piani di controllo; VIN: Vincoli sanitari; PV: misure di Polizia Veter. o ind. Epidemiol.; RICH: richiesta di privati

BOVINO Motivo controllo: PC

Motivo controllo: VIN

Motivo controllo: PV

Motivo controllo: RIC

Malattia Negativi Positivi Negativi Positivi Negativi Positivi Negativi Positivi Afta Epizootica Blue Tongue PPCB Paratubercolosi IBR - IPV BVD-MD Brucellosi Leucosi B. E. TBC

(Tratto da CAMP1.1 - 2. Accertamenti diagnostici SIEROLOGICI per alcune malattie infettive)

Campioni non conformi per:

Riferimento normativo

Campioni prelevati

Carica batterica

Cellule somatiche Proteine Grasso

Aflatossina M1

Residui di

Antibiotici Residui di antiparass. PCB Altro: Altro:

DM 185/1991 DPR 54/1997 PNR Altro:

Altro:

(Tratto da CAMP1.1 - 4. Controlli sul latte Bovino)

BOVINI

Matrice

Campioni prelevati per PC

Campioni prelevati per VIN

Campioni prelevati per PV

Campioni prelevati su RIC

Totale campioni

Sangue/siero 0Urine 0Feci 0Latte 0Testa/SNC 0Organi 0Altro: 0Necroscopie 0

57

(Tratto da CAMP1.2 – 2.1 CAMPIONI PER CONTROLLI SULL'ALIMENTAZIONE ANIMALE)

(Tratto da CAMP2 - 1.1 CAMPIONI IN IMPIANTI DI MACELLAZIONE) in giallo vengono indicate MATRICI che in “macellazione” sono separate analiticamente, mentre negli altri comparti produttivi vengono accorpate come SPECIE (es. “CARNE BOVINA”)

MATRICE_MATERIALE

FORAGGIO

FIENO

INSILATO

SIERO DI LATTE

LATTE IN POLVERE

FARNA CARNE

FARINA OSSA

FARINA SANGUE

ALTRI MANG. SEMPLICI

MAN. SEMP. MEDICAT

MAN. COMP.COMPL

MAN. COMP COMP MED

MANG COMPLEM

MANG COMPL. MEDIC

PROD. INTERMEDIO

PREMISCELE

PREM. MEDICATE

RES. LAVOR. INDUST

GRASSI U.Z.

ACQUA ABBEV.

MANG. ANIM. AFFEZ

MANG. ACQUACOLT

MATRICE_MATERIALE

MUSCOLO

VISCERI

PROSTATA -GH.

TIROIDE

PLASMA

URINA - FECI

TESSUTO ADIPOSO

58

(Tratto da CAMP2 - 3.4 CAMPIONI SU LAVORAZIONE-VENDITA CARNI, PREPARAZ. DI CARNE E PROD. BASE CARNE - 3.4 CAMPIONI SU LAVORAZIONE-VENDITA ALTRI PRODOTTI DI ORIGINE ANIMALE) In buona sostanza ciò che permette le diverse aggregazioni richieste in tutti i debiti informativi sin qui analizzati, sono il tipo di MATRICE e la sua SPECIE di riferimento (CAMP1.1 e CAMP2) sotto riepilogate, oltre al MOTIVO del prelievo (CAMP1.1), oppure al COMPARTO produttivo

MATRICE_MATERIALE

CARNE BOVINA

CARNE SUINA

CARNE EQUINA

CARNE OVI-CAP

CARNE POLLAME

CARNE TACCHIN0

CARNE CONIGLI

SELVAGGINA

CARNE TRITATA

CARNE SURGELATA

INSACC. FRESCHI

INSACC. STAGION.

INSACC. COTTI

PROD. STAGIONATI

PROD. COTTI

CONSERVE CARNE

ALTRI PRD. B.C.

TAMPONI AMBIENT

ALTRO

MATRICE_MATERIALE

PROD. ITTICI ALL.

PROD. ITTICI PESC

PROD ITTICI SURG

MOLLUSCHI

CONS. ITTICHE

LATT DES TRAT TER

LATT TRATT TERM

LATT. DA TRASF.

LATTE FERMENT

BURRO - ECC.

FORMAG. FRESCHI

FORMAG STAGION

ALTRI PROD B LATT

UOVA

OVOPRODOTTI

MIELE

TAMP. AMBIENT.

ALTRO

59

presso cui è stato effettuato il prelievo (SIAN e CAMP2) o a specifiche richieste analitiche (CAMP1.1 ). Si riportano di seguito le specifiche necessarie per effettuare l’aggregazione delle informazioni per SPECIE.

In ogni caso è in corso di definizione un elenco standard condiviso di matrici e di ricerche di laboratorio, da parte di un gruppo specifico di lavoro organizzato dai Servizi Veterinari delle Regioni Lombardia ed Emilia Romagna e dall’Istituto Zooprofilattico di Brescia (in linea con quanto previsto dal suddetto progetto di scambio dati informatizzato). Tale lavoro avrà sicuramente nel prossimo futuro un profondo ma utile impatto sugli applicativi locali delle AUSL e sarà inevitabile seguirne lo sviluppo per anticipare presso il Sistema Regionale Centrale le necessarie soluzioni.

MATRICE_SPECIE

BOVINI Camp1.1 Camp2

EQUINI Camp1.1 Camp2

SUINI Camp1.1 Camp2

OVI-CAPRINI Camp1.1 Camp2

POLLAME Camp1.1 Camp2

CONIGLI Camp1.1 Camp2

ITTICI Camp1.1

SELVAGGINA Camp1.1

CANI-GATTI Camp1.1

API Camp1.1

60

4.04.05 LE NUOVE INFORMAZIONI RACCOLTE DAL LABORATORIO

Uno specifico Gruppo di Lavoro Regionale ha condotto una analisi mirante a definire le informazioni da inserire nel verbale di prelevamento ha elaborato un modello regionale unico per SIAN e SV, di cui si riportano le informazioni collegabili alla analisi del paragrafo precedente. (Tratto da FACSIMILE NUOVO VERBALE DI PRELEVAMENTO) --------------------------------------------------------------------------------------------------

VERBALE DI PRELEVAMENTO N° ________ DEL_________

In data _____________ alle ore ________,

Codice macro gruppo ___________

� Programmato � A pagamento � Disposto da:___________________________________________ � piano di campionamento nazionale/regionale n°__________

Campione ufficiale di _______________________________________ Prelevato presso _____________________________________________

sito _______________________in via ___________________________

Codice comparto attività: _______

Titolare / Legale rappresentante___________________________

nato a ____________________________________il ________________

residente a via

Ditta Produttrice / Confezionatrice Distributrice:

sita a ______________________________in via _________________________________

tel./fax _____________________________________________

Ricerca Parametri:

------------------------------------------------------------------------------------------------

61

Come si può notare è stato inserito un CODICE di MACROGRUPPO che permette di definire la MATRICE prelevata attraverso una codifica che consenta la corretta aggregazione nelle schede SISVET. La SPECIE va comunque inserita nella descrizione della matrice stessa. E’ poi stata prevista la definizione del MOTIVO dell’intervento: vi è qui la possibilità di specificare il PIANO di CAMPIONAMENTO e comunque il codice del FLUSSO INFORMATIVO REGIONALE. Unico fattore di criticità potrebbe essere rappresentato da una generica indicazione relativa all’Autorità che ha disposto il campionamento, che potrebbe non essere descritta in modo sufficiente a definire se il motivo dell’intervento sia stato per “VIN: Vincoli sanitari” o “PV: misure di Polizia Veterinaria o ind. Epidemiologiche”, mentre è chiaro se è stato per “PC: Piani di controllo” oppure “RICH: richiesta di privati”, secondo quanto previsto nella scheda CAMP1.1. Inoltre importantissimo risulta essere il CODICE del COMPARTO di ATTIVITA’ ivi riportato. Da tutto ciò si ricava infine che l’attuale raccolta di informazioni da parte dei laboratori potrebbe essere sufficiente ad alimentare i flussi informativi regionali, a patto di una integrazione dell’attuale file prodotto dall’IZS con le nuove informazioni (riportate in coda ed evidenziate in giallo), peraltro dunque già presenti nel verbale di conferimento:

CAMPIONI_IZS

Anno Conferimento

Numero_Conferimento

Data_Conferimento

Distretto

Data_Prelievo

Proprietario

Verbale

Codice_Allevamento

Campione

Prova

62

Tecnica

Esito

Metodo_di_Prova

Istanza

Reparto_IZSLER

Laboratorio_IZSLER

Dettaglio_P

Dettaglio_S

Fine_Analisi

Destinatario_RDP

Codice_Piano

Codice_Comparto

Matrice_Cod_MacroGruppo

Matrice_Materiale

Matrice_Specie

Occorre tuttavia attivare la verifica di fattibilità presso l’IZS in riferimento sia della effettiva possibilità di registrare sul proprio sistema informatico tali nuove informazioni, sia delle modalità di trasmissione delle stesse presso il Sistema Informativo Regionale. A tale proposito si espongono nel prossimo paragrafo alcune diverse soluzioni possibili. 4.04.06 INTEGRAZIONE TRA IZS E S.I.RER L’attuale modalità di scambio dati tra AUSL e IZS prevede l’invio di un file via e-mail (secondo la frequenza concordata, da giornaliera a semestrale) costituito da una tabella contenente le informazioni sopra citate.

63

Con le poche integrazioni indicate, dunque, già col sistema attuale di scambio dati, l’invio di quei files (relativi a tutte le AUSL regionali) ad un unico punto centrale regionale potrebbe permettere un monitoraggio PERIODICO dello stato di avanzamento delle attività di campionamento, direttamente dai Laboratori. In tal caso sarebbe sufficiente infatti prevedere un applicativo centrale regionale da cui lanciare upload periodici per caricare sul sistema centrale il file inviato dall’IZS, di volta in volta, ad un gestore regionale ufficialmente incaricato dell’operazione. Un metodo sicuramente più avanzato sarebbe l’esposizione di web services da parte del S.I.RER ed il loro consumo da parte di un applicativo IZS che potrebbe fornire gli aggiornamenti automatici IN TEMPO REALE sui campioni conferiti e sull’esito degli esami condotti. In questo caso occorre prevedere una sinergia tra RER e IZS nello sviluppo dell’applicativo informatico presso IZS stesso. Un aspetto di importanza strategica in quest’ultima ipotesi è che tale sistema potrebbe permettere ad IZS anche il consumo di altri WS come ad esempio quelli che permetterebbero l’allineamento della propria Anagrafica con quella ufficiale degli Allevamenti presente in BDN, oppure l’allineamento con quella delle altre Imprese Alimentari tramite il Portale delle Imprese, di cui è previsto il collegamento attraverso la Porta di Dominio RER. Mentre la prima soluzione dell’upload centrale avrebbe costi limitati e compresi nell’applicatico regionale, la seconda prevederebbe invece un investimento mirato per la realizzazione di un applicativo presso IZS in grado di interloquire con la banca-dati di produzione (DarWin) ed i Web Services regionali: tale impegno è stimabile tra i 20.000 ed i 30.000 euro. In termini generali dunque la gestione delle informazioni relative ai campionamenti permette sia una integrazione col resto del S.I.RER, sia una fruizione completamente autonoma e svincolata da esso.

64

5. SISTEMA PUBBLICO DI CONNETTIVITA’ 5.01 COS’E’ IL SISTEMA PUBBLICO DI CONNETTIVITA’ Il Sistema Pubblico di Connettività (SPC) è la rete che collega tra loro tutte le amministrazioni pubbliche italiane, consentendo loro di condividere e scambiare dati e risorse informative. Istituito e disciplinato dal Decreto legislativo del 28 febbraio 2005, n. 42, esso viene definito come "l'insieme di infrastrutture tecnologiche e di regole tecniche per lo sviluppo, la condivisione, l'integrazione e la diffusione del patrimonio informativo e dei dati della pubblica amministrazione, necessarie per assicurare l'interoperabilità di base ed evoluta e la cooperazione applicativa dei sistemi informatici e dei flussi informativi, garantendo la sicurezza, la riservatezza delle informazioni, nonché la salvaguardia e l'autonomia del patrimonio informativo di ciascuna pubblica amministrazione". Il SPC, indicato a volte come Sistema Pubblico di Connettività e Cooperazione, viene gestito dal Centro Nazionale per l'Informatica nella Pubblica Amministrazione (CNIPA). Esso è basato sui seguenti principi:

1. Sviluppo architetturale ed organizzativo atto a garantire la natura federata, policentrica e non gerarchica del sistema.

2. Economicità nell'utilizzo dei servizi di rete, di interoperabilità e di

supporto alla cooperazione applicativa.

3. Sviluppo del mercato e della concorrenza nel settore delle tecnologie dell'informazione e della comunicazione.

Esso persegue i seguenti obiettivi:

• Fornire un insieme di servizi di connettività condivisi dalle Pubbliche Amministrazioni (PA) interconnesse, graduabili in modo da poter soddisfare le differenti esigenze.

65

• Garantire l'interazione della PA centrale (PAC) e locale (PAL) con tutti gli altri soggetti connessi a internet, nonché con le reti di altri enti, promuovendo l'erogazione di servizi di qualità per cittadini e imprese.

• Fornire un'infrastruttura condivisa di interscambio che consenta

l'interoperabilità tra tutte le reti delle PA esistenti. • Fornire servizi di connettività e cooperazione alle PA che ne

facciano richiesta, per permettere l'interconnessione delle proprie sedi e realizzare così anche l'infrastruttura interna di comunicazione.

• Realizzare un modello di fornitura dei servizi multifornitore

coerente con l'attuale situazione di mercato e le dimensioni del progetto stesso.

• Garantire lo sviluppo dei sistemi informatici nell'ambito del SPC

salvaguardando la sicurezza dei dati, la riservatezza delle informazioni, nel rispetto dell'autonomia del patrimonio informativo delle singole amministrazioni.

Per garantire autonomia alle singole Amministrazioni, lasciando inalterato il loro patrimonio informativo, si definisce il DOMINIO come "l'insieme delle risorse (in particolare le procedure, i dati e i servizi) e delle politiche di una determinata organizzazione". Il dominio è anche il confine di responsabilità di un'organizzazione, in particolare per quanto riguarda le politiche che definiscono il suo sistema informativo. Secondo questo modello, la comunicazione avviene tra entità omogenee (i domini appunto) e lo scopo dell'architettura cooperativa è abilitare l'integrazione degli oggetti informativi (procedure e dati) e delle politiche di domini diversi.

66

5.02 LA PORTA DI DOMINIO La Porta di Dominio ha lo scopo di assicurare che lo scambio elettronico di informazioni tra le Pubbliche Amministrazioni abbia le stesse caratteristiche di quello tradizionale (carta, firma, protocollo, fax….). In questo modo l’amministrazione che invia le informazioni in modo elettronico ad un’altra, sarà garantita del fatto che la destinataria (e non altri) le abbia ricevute, così come la ricevente potrà trattare le informazioni elettroniche ricevute con pari dignità di quelle che oggi riceve con i metodi tradizionali, considerati fino ad ora gli unici probanti ai fini del procedimento amministrativo. Questo dovrà essere possibile indipendentemente da come viene realizzata la porta di dominio (fornitore, linguaggi, tecnologia…) in quanto la sua interfaccia è stata definita. Come trattato nell’ ALLEGATO E (SPCoop - Quadro d’Insieme v1.0) ed ancora più specificatamente nell’ ALLEGATO F (SPCoop - Architettura v1.0) il CNIPA definisce le principali linee guida per le amministrazioni che vogliano realizzare servizi on-line interagendo con i sistemi informativi di altre amministrazioni. In tali indicazioni la Porta di Dominio costituisce l'elemento tecnologico che realizza la cooperazione. Ogni porta di dominio a livello concettuale funge da proxy per l'accesso alle risorse applicative che si trovano all'interno dello stesso dominio (un proxy è un programma che si interpone tra un client ed un server, inoltrando le richieste e le risposte dall'uno all'altro; il client si collega al proxy invece che al server, e gli invia delle richieste; il proxy a sua volta si collega al server e inoltra la richiesta del client, riceve la risposta e la inoltra al client).

5.03 LA COOPERAZIONE APPLICATIVA

La Porta di Dominio consente a ciascuna PA che espone i propri servizi ad altre PA di comunicare facilmente con loro condividendo e adottando gli stessi protocolli (dove "protocolli" è usato in senso lato). Ogni ente è in grado di fungere sia da fornitore sia da consumatore di un dato servizio. È quindi facile comprendere che la PDD è un componente a due facce: quella esterna deve aderire ad un set di

67

standard per consentire l'interoperabilità con le PDD di altre PA, mentre quella interna è dipendente dalle risorse interne dell'ente. La "Cooperazione Applicativa" (la logica che abilita applicazioni e infrastrutture diverse ad interagire) prevede che ogni Porta di Dominio sia logicamente suddivisa in una componente di Cooperazione ed una di Integrazione: la prima, rivolta verso l'esterno della PDD, è incaricata delle comunicazioni fra Porte di Dominio, mentre la seconda interagisce con la logica e l'architettura dell'infrastruttura che deve servire. A seconda che una data PDD svolga il ruolo di fornitore o di consumatore è chiamata, rispettivamente Porta Applicativa o Porta Delegata. Le comunicazioni avvengono sempre fra Porte Delegate e Porte Applicative. Dunque la PORTA APPLICATIVA svolge la funzione di rendere accessibili i SERVIZI APPLICATIVI agli altri domini, ricevendo le richieste delle Porte Delegate delle altre, mentre la PORTA DELEGATA svolge la funzione do consentire agli utenti interni di un dominio, di accedere ai servizi esterni esposti da altri domini, dunque attraverso di essa partono tutte le richieste che una PA effettua verso le altre PA.

Tra la funzione la porta applicativa ed i sistemi “legacy” (cioè le applicazioni preesistenti proprietarie della PA interrogata), si interpone lo strato del cosiddetto GATEWAY APPLICATIVO/DELEGATO che si

68

occupa di operare sulla basedati e di gestire la risposta alla PA interrogante. I paradigmi di cooperazione applicativa che devono essere supportati dalle porte di dominio sono riconducibili a due tipologie principali: la richiesta di servizio e la comunicazione di evento. In base a ciò conseguono due diversi scenari di cooperazione:

A) Cooperazione per richiesta di servizio B) Cooperazione per Eventi

Passiamo dunque alla descrizione di tali modalità operative. 5.03.01 COOPERAZIONE PER RICHIESTA DI SERVIZIO

La richiesta di servizio consiste nella richiesta (messaggio) prodotta da una applicazione di un dominio cliente e diretto ad una applicazione di un dominio servente. Il messaggio determina l'esecuzione di una applicazione del dominio servente che, in base alle informazioni contenute nel messaggio, esegue una procedura ed invia una risposta destinata all'applicazione cliente. La risposta è un'indicazione certa che l'applicazione servente ha attuato la richiesta e che abbia avuto esito positivo/negativo. Dal punto di vista dell'interazione amministrativa, la richiesta di servizio è sempre sincrona. La richiesta di servizio può essere di due tipi:

• INTERROGAZIONE: richiesta di servizio finalizzata all'acquisizione di un'informazione del dominio servente ma che non modifica alcun oggetto applicativo interno allo stesso dominio servente;

• TRANSAZIONE: richiesta di servizio destinata a produrre una variazione permanente in un oggetto applicativo del dominio servente.

69

Ogni ente è in grado di fungere sia da "fornitore" che da "consumatore" di un dato servizio. La porta di dominio che invoca la richiesta di servizio deve dapprima contattare il CATALOGO SERVIZI (detto anche “Elenco dei Servizi”) per ricavarne i dettagli tecnici e le interfacce necessarie alla comunicazione. Vediamo quindi una schematizzazione della sequenza degli scambi dal punto di vista di un'amministrazione che desideri utilizzare un certo servizio informativo esposto da un altro ente:

1) L'amministrazione A necessita di un servizio da parte dell'amministrazione B e ricerca nel Catalogo Servizi se B è in grado di fornirlo;

2) Il Catalogo Servizi fornisce un link contenente la descrizione della

amministrazione B e l'indirizzo internet (una URL) cui è possibile inviare le richieste per usufruire del servizio cercato. L'amministrazione B aveva infatti in precedenza pubblicato le specifiche di utilizzo del proprio servizio nel Catalogo Servizi.

3) La porta di dominio di A esamina il formato richiesto da B per

formulare la richiesta di servizio. Dalle informazioni inserite nella struttura di descrizione del servizio, A è in grado di comporre una richiesta di servizio e decifrare opportunamente la risposta fornita da B.

5.03.02 COOPERAZIONE PER EVENTI Un EVENTO è il cambiamento di valore di un oggetto applicativo in un dominio sorgente che ha significato anche per altri domini detti destinatari. La comunicazione di un evento NOTIFICA DI EVENTO consiste nell'invio di un messaggio da parte di un'applicazione allo scopo di informare altre applicazioni di uno o più domini destinatari dell'avvenuto cambiamento delle informazioni relative ad un oggetto applicativo o della creazione di un nuovo oggetto applicativo. Il messaggio inviato contiene anche le informazioni, nuove o modificate, che descrivono l'evento stesso.

70

L'interazione tra gli interlocutori avviene in modo indiretto, intermediata da una infrastruttura di servizio (detta di Publish and Subscribe) che fornisce servizi per la pubblicazione di un evento e di sottoscrizione agli eventi stessi. In questo scenario ad esempio un Comune, a fronte della richiesta di cambio residenza da parte di un cittadino, pubblica l'evento Cambio Residenza, insieme a tutti i dati ad esso relativi, sul sistema di Publish and Subscribe. Quest'ultimo si occupa di notificarlo poi, in modo opportuno, a tutte le amministrazioni che avevano preventivamente sottoscritto quell'evento specifico. La notifica dell'evento non prevede la risposta da parte dei destinatari. 5.04 PROFILI DI COLLABORAZIONE In termini generali, si assume che ciascuna collaborazione applicativa preveda lo scambio di una coppia di messaggi: una richiesta inviata da una porta di dominio a cui fa seguito una risposta da parte di un'altra porta di dominio. Si prevedono collaborazioni realizzate tramite lo scambio di messaggi in modalità sincrona e asincrona. Per convenzione, il sincronismo viene visto dal punto di vista della porta presso la quale ha inizio ogni episodio di collaborazione:

• in uno scambio sincrono la porta del dominio cliente invia la propria richiesta applicativa ed attende la risposta della porta del dominio servente;

• in uno scambio asincrono, la risposta della porta del dominio servente può essere inviata in un tempo successivo e la porta del dominio cliente non rimane quindi in attesa.

La scelta della modalità sincrona o asincrona può dipendere da aspetti legati alla latenza delle procedure amministrative (ad esempio la necessità di intervento umano per l'apposizione della firma digitale di un pubblico ufficiale).

71

Tuttavia, in linea di principio, tale scelta può dipendere anche da scelte di carattere esclusivamente tecnologico. 5.05 LA BUSTA DI e-GOVERNMENT Per scambiare messaggi applicativi fra porte di dominio viene utilizzata la busta di eGovernment che è la definizione del formato di codifica e del contenuto dei messaggi SOAP (Simple Object Access Protocol), utilizzati per implementare, sotto forma di Web services, i servizi esposti dalle Porte Applicative delle amministrazioni. Il formato della busta di eGovernement è stata definita dal Centro Tecnico (CNIPA) nei documenti di linee guida a supporto dell'implementazione dei progetti di eGovernment. Ogni messaggio scambiato tra porte di dominio si compone di due parti principali:

1. una parte di BUSTA, che contiene le indicazioni relative al mittente, il destinatario (intese come porte di dominio), al servizio richiesto ed al profilo di collaborazione utilizzato; tale busta viene in generale gestita dalle componenti di collaborazione delle porte di dominio e deve quindi essere il più generale possibile;

2. una parte di CONTENUTO applicativo, rappresentato dalle

informazioni effettive previste per quel tipo di servizio e di scambio (per es. i dati identificativi personali di una richiesta di informazioni anagrafica).

Lo strumento utilizzato per definire un formato dei dati condiviso tra tutte le amministrazioni, a prescindere dai sistemi "legacy" e dalle basi dati, è XML (eXtensible Markup Language). SOAP è invece utilizzato come standard per veicolare le informazioni codificate con XML sulla rete Internet, mediante il protocollo http (Hyper Text Transfer Protocol). In generale, il tipo di struttura da utilizzarsi per busta e contenuto dipende dal tipo di messaggio e dalle esigenze di carattere normativo. In questo senso, in base alla normativa vigente possono essere definiti tre tipi di messaggi:

72

1. messaggi che non richiedono l'uso della firma digitale; 2. messaggi che richiedono l'uso della firma digitale come sola

garanzia di provenienza delle informazioni (ai sensi del D.P.R. 445/2000);

3. messaggi che richiedono l'apposizione della firma digitale da parte

di un pubblico ufficiale.

Si noti che i messaggi di tipo 1) e 2) si prestano ad un trattamento interamente automatizzato, mentre i messaggi di tipo 3) richiedono, tipicamente, un intervento manuale di firma da parte di un pubblico ufficiale. I documenti a valore legale possono essere firmati digitalmente come allegati binari PKCS #7 (in base della circolare AIPA CR/24); gli altri contenuti XML possono essere firmati digitalmente per fornire una prova della loro provenienza. Una firma opzionale può essere inclusa nell'intestazione utilizzando gli standard XML SOAP Security e XML Signature e potrebbe, ad esempio, essere usata per garantire la fonte di provenienza delle informazioni (art. 43 del D.P.R. 445/2000). La scelta delle strutture specifiche per la busta di e-government da utilizzare nello scambio dei messaggi costituisce una parte integrante della definizione preliminare dei servizi e non può costituire una variante da negoziarsi per ciascuno scambio. Dal punto di vista amministrativo, la struttura XML SOAP incorpora anche il ruolo della segnatura informatica in formato XML del messaggio in quanto riporta i dati minimi della registrazione di protocollo. La struttura XML SOAP può inoltre essere inclusa in una struttura MIME allo scopo di allegare al messaggio uno o più documenti applicativi, in base allo standard XML SOAP with attachments.

73

5.06 NORMATIVA DI RIFERIMENTO Viene riportato qui di seguito un elenco di documenti di riferimento relazionati con il componente di porta di dominio:

• Linee guida per la Rete Nazionale (C.U.18 gennaio 2001); • Allegato tecnico Rete Nazionale (C.U.18 gennaio 2001); • DPR 28 dicembre 2000 n. 445: Testo unico delle disposizioni

legislative e regolamentari in materia di documentazione amministrativa; pone implicitamente la necessità di una forte interazione informatica tra le P.A. per poter soddisfare i requisiti di legge;

• Il DPCM 31/10/2000 e la circolare AIPA CR/28 del 7/5/2001

disciplinano le modalità di interconnessione tra diversi sistemi di protocollo informatico e la loro integrazione con la posta elettronica e la firma digitale. In particolare, la normativa prevede la possibilità di trattamento automatico delle informazioni scambiate tra sistemi di protocollo diversi;

• Il DPCM 8/2/1999: "Regole tecniche per la formazione, la

trasmissione, la conservazione, la duplicazione, la riproduzione e la validazione, anche temporale, dei documenti informatici"; disciplina tra le altre cose le modalità tecniche di apposizione e verifica della firma digitale;

• La circolare AIPA CR/24 del 19 giugno 2000: stabilisce le linee

guida fondamentali per l'interoperabilità dei sistemi basati sulla firma digitale. Tale circolare stabilisce tra l'altro il formato di riferimento per i certificati X.509, che riportano le chiavi pubbliche di sottoscrizione e le informazioni salienti riguardo al sottoscrittore, ed il formato dei documenti digitali firmati, con riferimento alla specifica pubblica PKCS#7.

74

5.07 PRINCIPALI SITI DI RIFERIMENTO Si riporta di seguito l’elenco dei principali siti, ufficiali e non ufficiali, di riferimento per il Sistema Pubblico di Connettività:

• Ministro per l'Innovazione e le tecnologie • Centro Nazionale per l'Informatica nella Pubblica Amministrazione

(Al link “Servizi di interoperabilità evoluta e cooperazione applicativa”)

• Sviluppo OpenSource della Porta Di Dominio • Proposta di un'Interfaccia standard per la Porta Di Dominio

5.08 BIBLIOGRAFIA UFFICIALE CNIPA Si ritiene indispensabile fare riferimento alla seguente bibliografia ufficiale di CNIPA, ai fini della implementazione della Porta di Dominio Regionale. Di seguito si riportano i documenti ufficiali aggiornati presenti sul sito www.cnipa.gov.it :

• SPCoop-AccordoServizio_v1.0_20051014 • SPCoop-Architettura_v1.0_20041125_ • SPCoop-Busta e-Gov_v1.1_20051014 • SPCoop-EsercizioGestione_v1.0_20051014 • SPCoop-ExecutiveSummary_v2.1_20041125_1 • SPCoop-LicenzaUso_v1.0_20051014 • SPCoop-NomenclaturaSemantica_v1.0_20051014 • SPCoop-Organizzazione_v1.0_20041125_

75

• SPCoop-PortaDominio_v1.0_20051014 • SPCoop-QuadroInsieme_v1 0_20051014 • SPCoop-ServiziRegistro_v1.0_20051014 • SPCoop-ServiziSicurezza_v1.0_20051014 • SPCoop-Standard_v1.0_20041125_1 • SPCoop-TerminiDefinizioni_v1.0_20051014

76

6. CONCLUSIONI 6.01 FATTIBILITA’ DEL PROGETTO Tutto quanto esposto finora, lascia intendere che, dal punto di vista tecnico, esiste oggi la possibilità di implementare un Sistema Informativo Regionale Informatizzato che permetta la registrazione e l’aggiornamento presso le AUSL (e contestualmente presso un archivio centrale regionale), delle Imprese che operano in campo alimentare. Si è inoltre individuato che tale archivio è realizzabile nell’ambito del Sistema Pubblico di Connettività e Cooperazione Applicativa, attraverso una integrazione nativa con il Registro Imprese di UnionCamere attraverso i servizi esposti dal Portale Parix-Gate. Tale soluzione assicura la ufficialità e la certificabilità nonché l’aggiornamento delle informazioni utilizzate; oltre a ciò essa garantisce, anche in un’ottica di lungo periodo, la validità dell’investimento (e quindi la sua intrinseca economicità). Sono state analizzate inoltre le informazioni gestite dai vari soggetti che cooperano nei controlli ufficiali nel settore della sicurezza alimentare (Servizi Regionali, Servizi Igiene degli Alimenti e Nutrizione, Servizi Veterinari, Laboratori Ufficiali IZS ed ARPA) e si è disegnato, attorno alla suddetta “Anagrafe Regionale degli Operatori di Sicurezza Alimentare”, il nucleo della rete informatica in grado di permettere lo scambio informativo automatico e completo tra i soggetti stessi, nell’ambito delle attività svolte per la sicurezza alimentare, completando in tal modo il progetto di “Sistema Informatico della Sicurezza Alimentare in Regione Emilia Romagna”. 6.02 PASSAGGI ORGANIZZATIVI In sede conclusiva appare fondamentale definire le azioni da porre in essere dal punto di vista organizzativo al fine di attivare la realizzazione tecnica descritta nel presente studio tecnico.

77

Si identificano tre gruppi di azioni:

• Organizzazione Preliminare • Realizzazione dell’ Anagrafe Regionale degli Operatori di

Sicurezza Alimentare • Completamento del S.I. Sicurezza Alimentare R.E.R.

Si presentano di seguito le schematizzazioni relative.

Organizzazione Preliminare

FASE DURATA SEQUENZA ATTORE

1 Comunicazione del progetto al fine di reperire il finanziamento necessario.

durata non determinabile

Direzione Servizio RER + Direzione CED RER

2 Definizione del modello da proporre in base alle opzioni compatibili col finanziamento ottenuto.

da 1 sett. ad 1 mese

dopo step 1 Direzione Servizio RER + Direzione CED RER

3 Individuazione del partner informatico per lo sviluppo centrale in Regione E. R.

da 1 a 3 mesi dopo step 2 Direzione Servizio RER + Direzione CED RER

4 Individuazione dei partner informatici per lo sviluppo locale presso ogni AUSL.

da 1 a 3 mesi dopo step 2 Direzione Servizio RER + Direzione CED RER

5 Definizione delle modalità di accesso al Servizio di Cooperazione tra AUSL e Parix-Gate, al fine di erogare/fruire servizi applicativi relativi al Registro delle Imprese.

da 1 a 3 mesi dopo step 2 Direzione Servizio RER + Direzione CED RER

6 Condivisione del progetto con le AUSL, in fase avanzata di maturazione.

da 1 a 3 mesi dopo step 2 Direzione Servizio RER + Direzione CED RER

78

Realizzazione dell’ Anagrafe Regionale Imprese Alimentari

FASE DURATA SEQUENZA ATTORE

7 Allineamento delle Anagrafiche locali.

1 anno Team di Allineamento

8 Realizzazione piattaforma centrale:

a Modellazione database centrale.

1 mese contemporaneo a 7

Team di sviluppo CED RER

b Progettazione e realizzazione Centro Servizi di Cooperazione Pubblica centrale.

5 mesi dopo 8a Team di sviluppo CED RER

c Modellazione interfaccia-operatore centrale.

6 mesi dopo 8b Team di sviluppo CED RER

9 Realizzazione piattaforme periferiche

da 2 a 6 mesi (variabile x partner)

dopo 8b Partner informatico dell'AUSL

10 Fase di test per Sincronizzazione finale delle Anagrafiche locali con Registro Imprese

2 mesi dopo 9 Team di sviluppo CED RER + Partner informatico dell'AUSL

79

Completamento del S.I. Sicurezza Alimentare R.E.R.

FASE DURATA SEQUENZA ATTORE

11 Implementazione piattaforma centrale:

a Modellazione database centrale.

2 mese Team di sviluppo CED RER

b Progettazione e realizzazione Servizi aggiuntivi di Cooperazione Pubblica centrale.

4 mesi dopo 11a Team di sviluppo CED RER

c Modellazione interfaccia-operatore centrale.

6 mesi dopo 11b Team di sviluppo CED RER

12 Realizzazione piattaforme periferiche

da 2 a 6 mesi (variabile x partner)

dopo 11b Partner informatico dell'AUSL

13 Fase di test per sincronizzazione Controlli

2 mesi dopo 12 Team di sviluppo CED RER + Partner informatico dell'AUSL

80

81

6.03 CONSIDERAZIONI FINALI 6.03.01 IMPATTO ECONOMICO ED ORGANIZZATIVO In conclusione dunque si identifica il contenimento dell’ impatto economico sulle AUSL come il fattore chiave da governare per ottenere il successo della informatizzazione del Sistema Informativo Regionale sulla Sicurezza Alimentare. A questo proposito occorre tuttavia sottolineare che si ha notizia di una tensione, presso alcune AUSL della regione, verso l’acquisizione autonoma di nuove piattaforme software già predisposte al genere di implementazione sopra descritto. Tale pulsione trae origine da una accoppiata di necessità ormai giudicate irrinunciabili:

1) utilizzare sistemi gestionali in grado di permettere ottimizzazioni nel governo delle risorse e dei servizi erogati;

2) disporre di software che consentano una facile

modellabilità, al fine di aumentare l’autonomia dal fornitore, con conseguente risparmio economico.

Per il primo aspetto, tale esigenza viene esaudita da appositi sistemi di quering e reporting in grado di analizzare sotto molteplici prospettive i dati raccolti nei database relazionali, che costituiscono l’infrastruttura di tali programmi. Oltre a ciò è possibile organizzare la reportistica in modo che sia strutturata per i diversi livelli gerarchici di responsabilità. Per quanto riguarda il secondo punto i moderni applicativi si basano su workflow engine, ovvero utilizzano un modello strutturale che segue il “flusso di lavoro”, ovvero come diremmo noi “ragiona per processi”. Tale concezione, ormai ben acquisita in altri ambiti, inizia a proporsi anche in sanità pubblica, dove sta emergendo sempre più forte l’esigenza di tutelare la “qualità” dei servizi erogati al fine di giungere alla loro “certificabilità”. In tale ottica il processo che porta alla erogazione di uno qualsiasi di tali servizi può essere scomposto in “passi elementari” o “step” tra di loro coniugati in vario modo:

82

• il secondo non può avvenire se non è avvenuto il primo; • il secondo non può avvenire se non è terminato il primo; • il secondo può avvenire anche se non è terminato il primo;

Ogni passo a sua volta viene svolto da una specifica risorsa umana e quindi, in ultima analisi, ogni processo declina una tabella a matrice in cui le colonne sono le figure professionali coinvolte (“chi fa”) e ogni riga rappresenta un singolo step (“che cosa”). In estrema sintesi, l’applicazione di questa logica alla registrazione delle attività svolte presso i Servizi AUSL, permette di modellare i processi in modalità parametrica, ovvero un qualsiasi utente del programma, con le dovute conoscenze di base e con gli specifici permessi di utilizzo, è in grado di creare, modificare od eliminare uno specifico processo. Ciò significa, in linea di principio che una volta acquistato il programma, non occorreranno più investimenti per la sua modellazione futura in caso di cambiamenti operativi nei servizi erogati. Tale prospettiva appare sempre più convincente nell’orientare le prossime scelte informatiche dei Servizi, sia per l’efficacia nel raccogliere le informazioni generate dalla mole dei processi attualmente erogati, sia per l’elasticità garantita nel gestirne la continua evoluzione ed innovazione. Considerato tutto ciò, appare fondamentale riuscire a condividere sinergicamente i bisogni di evoluzione dei sistemi informatici Centrale e Locali, orientando i rispettivi investimenti verso obiettivi condivisi. Da un lato infatti tale condivisione può aiutare a percepire come “accettabili”, gli importanti investimenti proposti, dall’altro essa può generare la forza organizzativa necessaria per poter proporre ai fornitori condizioni tali da realizzare le economie di scala auspicabili, ed indispensabili per la realizzazione del progetto illustrato nel presente lavoro. Infine tutti gli attori (pubblici e privati) di questo scenario, devono essere pienamente responsabilizzati e vincolati al perseguimento dei risultati attesi, al fine di garantire la validità dell’investimento compiuto.

83

6.03.02 IPOTESI DI SVILUPPO E APPLICAZIONE GRADUALE

DEL S.I. SICUREZZA ALIMENTARE REGIONALE Quanto esposto nel progetto con particolare riferimento alla realizzazione del SISTEMA INFORMATIVO REGIONALE INFORMATIZZATO (v. capitolo 4), appare come una evoluzione logica della informatizzazione dell’ ANAGRAFE REGIONALE degli OPERATORI di SICUREZZA ALIMENTARE (v. capitolo3). Come già analizzato, quest’ultima in particolare prevede due fasi particolarmente onerose in termini organizzativi ed economici:

1) la condivisione e l’allargamento alle AUSL della Porta di Dominio Regionale per interfacciarsi con il Registro delle Imprese sul portale Parix-Gate;

2) l’allineamento delle Anagrafi Locali delle AUSL, col Registro

Imprese. Tali operazioni porterebbero ad una piena certificabilità ed aggiornabilità delle Anagrafi AUSL, ma vanno inquadrate come azioni migliorative del sistema, non come fattori limitanti ed indispensabili per il suo decollo iniziale. Ovvero esse potrebbero essere posticipate e programmate per un successivo futuro, alla luce della disponibilità economica complessiva e della disponibilità al cambiamento organizzativo da parte dei diversi Utenti. Con riferimento ai passaggi organizzativi del paragrafo 6.02, in cui si giunge alla definizione del modello da sviluppare in funzione dell’entità del finanziamento eventualmente ottenuto, si illustrano di seguito i diversi scenari di sviluppo tecnicamente possibili:

84

a) Il primo scenario è quello ideale che non risente di alcuna limitazione negli investimenti, e comprende quindi tutte le possibili fasi del progetto. Questa soluzione rappresenta di sicuro il risultato massimo ottenibile in termini di qualità del sistema. La porta di Dominio Regionale, come detto, assicura certificabilità ed aggiornabilità delle Anagrafi AUSL, IZS ed ARPA.

FASE 1

Condivisione AUSL della Porta di Dominio RER

2 Predisposizione Anagrafica Regionale

3 Popolamento Anagrafica Regionale

4 Allineamento Anagrafiche Locali con

Registro Imprese

5 Predisposizione Categorizzazione del

Rischio su S.I.RER

6 Predisposizione Controlli su S.I.RER

7 Predisposizione Campionamenti su

S.I.RER

8 Predisposizione di Web Services per

AUSL-IZS-ARPA su S.I. RER

9 Predisposizione programmi Locali (AUSL-IZS-ARPA) per S.I. RER

85

b) Scenario senza Porta di Dominio RER popola l’anagrafica regionale con i dati locali delle AUSL.

Dal punto di vista della completezza informativa questo sistema è sostanzialmente paragonabile al precedente, pur evitando, o posticipando ad un secondo periodo, le fasi relative alla predisposizione della Porta di Dominio Regionale e dell’ Allineamento delle Anagrafiche Locali con il Registro Imprese.

FASE 1

Predisposizione Anagrafica Regionale

2 Popolamento Anagrafica Regionale

3 Predisposizione Campionamenti su

S.I.RER

4 Predisposizione di Web Services per

AUSL-IZS-ARPA su S.I. RER

5 Predisposizione Categorizzazione del

Rischio su S.I.RER

6 Predisposizione Controlli su S.I.RER

7 Predisposizione programmi Locali (AUSL-IZS-ARPA) per S.I. RER

86

c) Scenario con il S.I. RER alimentato dal solo IZS, si costruisce autonomamente sulla raccolta delle informazioni per i flussi informativi derivanti dai campionamenti/prelievi. Sicuramente è lo scenario più semplice e produttivo rispetto all’investimento relativamente piccolo che comporta (in termini economici ed organizzativi) ed ai risultati che produce. Poiché una volta realizzato quanto previsto nello scenario 3, nulla impedirebbe di sviluppare in un secondo periodo le altre componenti del sistema, questo si candida ad essere il primo di una serie di tre moduli evolutivi così distinguibili: MODULO A: Destinato ad assicurare la gestione dei flussi informativi regionali legati ai campionamenti. Si caratterizza a sua volta per una possibile progressività nelle modalità di scambio dati, da un iniziale scambio manuale di file al consumo finale di web services regionali. MODULO B: Determina la realizzazione sostanziale del S.I. RER nei diversi ambiti operativi (anagrafica aziende, categorizzazione del rischio, controlli). MODULO C: Caratterizza il sistema attraverso i servizi che ne assicurano la qualità delle informazioni anagrafiche grazie all’allineamento con banche dati certificate.

FASE 1

Predisposizione Campionamenti su S.I.RER

2 Predisposizione di Web Services per

IZS su S.I. RER

3 Predisposizione programma Locale

IZS per S.I. RER

87

FASE 1

Predisposizione Campionamenti su S.I.RER

2 Predisposizione di Web Services per IZS su S.I.

RER MODULO A

3 Predisposizione programma Locale IZS per S.I.

RER

FASE 1

Predisposizione Anagrafica Regionale

2 Popolamento Anagrafica Regionale

3 Predisposizione di Web Services per AUSL-

ARPA su S.I. RER

4 Predisposizione Categorizzazione del Rischio su

S.I.RER

5 Predisposizione Controlli su S.I.RER

MODULO B

6 Predisposizione programmi Locali (AUSL-ARPA)

per S.I. RER

FASE 1

Predisposizione Porta di Dominio RER

MODULO C

2 Allineamento Anagrafiche Locali con Registro

Imprese

Grazie dunque a tale impostazione, è possibile assicurare la scalabilità realizzativa del sistema stesso e la necessaria gradualità sia a livello economico che organizzativo. _________________________________________________________