Progetto SDK

Area: DISPOVIGILANCE

Flusso Logico: Rapporto Operatore Segnalazione Incidente

Specifiche Funzionali

Indice

1.** Introduzione 4****

1.1 Obiettivi del documento 4

1.2 Acronimi 5

2. Architettura SDK 6**

2.1 Architettura funzionale 6

2.2 Architettura di integrazione 7

3. Funzionamento della soluzione SDK 9**

3.1 Tracciato input a SDK 9

3.2 Controlli di validazione del dato (business rules) 30

3.3 Flussi di Output per alimentazione MdS 69

3.4 Scarti di processamento 71

3.5 Informazioni dell’esecuzione 71

Storia del documento

1. Introduzione

2. Obiettivi del documento

Il Ministero della Salute (MdS) metterà a disposizione degli Enti da cui riceve dati applicazioni SDK specifiche per flusso logico e tecnologie applicative (Java, PHP e C#) per verifica preventiva (in casa Ente) della qualità del dato prodotto.

Nel presente documento sono fornite la struttura e la sintassi dei tracciati previsti dalla soluzione SDK per avviare il proprio processo elaborativo, nonché i relativi schemi xsd di convalida e i controlli di merito sulla qualità, completezza e coerenza dei dati.

Gli obiettivi del documento sono:

• fornire una descrizione funzionale chiara e consistente dei tracciati di input a SDK;
• fornire le regole funzionali per la verifica di qualità, completezza e coerenza dei dati;

In generale, la soluzione SDK è costituita da 2 diversi moduli applicativi (Access Layer e Validation Engine) per abilitare

• l’interoperabilità con il contesto tecnologico dell’Ente in cui la soluzione sarà installata;
• la validazione del dato ed il suo successivo invio verso il MdS.

La figura che segue descrive la soluzione funzionale ed i relativi benefici attesi.

1. Acronimi

Nella tabella riportata di seguito sono elencati tutti gli acronimi e le definizioni adottate nel presente documento.

1. Architettura SDK

   1. Architettura funzionale

Di seguito una rappresentazione architetturale del processo di gestione e trasferimento dei flussi dall’ente verso l’area MdS attraverso l’utilizzo dell’applicativo SDK, e il corrispondente diagramma di sequenza.

![A picture containing graphical user interface


1. L’utente dell’ente caricherà in una apposita directory (es. /sdk/input/) il flusso sorgente. L’utente avvierà l’SDK passando in input una serie di parametri descritti in dettaglio al paragrafo 3.1
2. La componente Access Layer estrae dalla directory indicata il file e ne salva una copia sulla cartella flussi elaborati (es. /sdk/run/). Per ogni elaborazione, SDK genererà un identificativo (ID_RUN) a fini di logging
3. I record del flusso verranno sottoposti alle logiche di validazione e controllo definite nel Validation Engine. Nel processare il dato, Validation Engine acquisirà da MdS eventuali anagrafiche di validazione del dato stesso.
4. Generazione del file degli scarti contenente tutti i record in scarto con evidenza degli errori riscontrati. I file di scarto saranno memorizzati in cartelle ad hoc (es. /sdk/esiti).
5. Tutti i record che passeranno i controlli verranno inseriti in un file xml copiato in apposita cartella (es /sdk/xml_output), il quale verrà eventualmente trasferito a MdS utilizzando la procedura messa a disposizione dal MdS. A fronte di un’acquisizione, il MdS fornirà a SDK un identificativo (ID_UPLOAD) che sarà usato da SDK sia per fini di logging che di recupero del File Unico degli Scarti.
6. A conclusione del processo di verifica dei flussi, il Validation Engine eseguirà le seguenti azioni:
7. Aggiornamento file contentente il riepilogo dell’esito dell’elaborazione del Validation Engine e del ritorno dell’esito da parte di MdS. I file contenente l’esito dell’elaborazione saranno memorizzati in cartelle ad hoc (es. /sdk/run).
8. Consolidamento del file di log applicativo dell’elaborazione dell’SDK in cui sono disponibili una serie di informazioni tecniche (Es. StackTrace di eventuali errori).
9. Copia del file generato al punto 5, se correttamente inviato al MdS, in apposita cartella (es. /sdk/sent).

Ad ogni step del precedente elenco e a partire dal punto 2, l’SDK aggiornerà di volta in volta il file contenente l’esito dell’elaborazione.

Nota: l’SDK elaborerà un solo file di input per esecuzione.

In generale, le classi di controllo previste su Validation Engine sono:

• Controlli FORMALI (es. correttezza dei formati e struttura record)
• Controlli SINTATTICI (es. check correttezza del Codice Fiscale)
• Controlli di OBBLIGATORIETÀ DEL DATO (es. Codice Prestazione su flusso…)
• Controlli STRUTTURE FILE (es. header/footer ove applicabile)
• Controlli di COERENZA CROSS RECORD
• Controlli di corrispondenza dei dati trasmessi con le anagrafiche di riferimento;
• Controlli di esistenza di chiavi duplicate nel file trasmesso rispetto alle chiavi logiche individuate per ogni tracciato.

Si sottolinea che la soluzione SDK non implementa controlli che prevedono la congruità del dato input con la base date storica (es non viene verificato se per un nuovo inserimento la chiave del record non sia già presente sulla struttura dati MdS).

1. Architettura di integrazione

La figura sottostante mostra l’architettura di integrazione della soluzione SDK con il MdS. Si evidenzia in particolare che

• Tutti i dati scambiati fra SDK e MdS saranno veicolati tramite Porta di Interoperabilità (PDI);
• Il MdS esporrà servizi (API) per il download di dati anagrafici;
• SDK provvederà ad inviare vs MdS l’output (record validati) delle proprie elaborazioni. A fronte di tale invio, il MdS provvederà a generare un identificativo di avvenuta acquisizione del dato che SDK memorizzerà a fini di logging.

1. Funzionamento della soluzione SDK

Di seguito la descrizione del processo di inoltro delle segnalazioni da parte dell’operatore sanitario al sistema nazionale Dispovigilance.

Vengono di seguito descritti i dettagli di funzionamento della soluzione suddivisa nella parti in cui essa si compone. Ogni esecuzione sarà associata ad un progressivo (ID_RUN) a fini di logging.

1. Tracciato input a SDK

Il flusso di input avrà formato csv e una naming convention libera a discrezione dell’utente che carica il flusso senza alcun vincolo di nomenclatura specifica (es nome_file.csv).

Il separatore per il file csv sarà il carattere tra doppi apici : “~“.

In fase di caricamento del file verrano impostati i seguenti parametri che andranno in input al SDK in fase di processamento del file:

Nella tabella seguente sono indicati i dettagli dei campi di business del tracciato di input atteso.

La colonna Posizione nel file la quale rappresenta l’ordinamento delle colonne del tracciato di input da caricare all’SDK.

La seguente tabella contiene i valori del dominio della classe:

Acquisito il dato di input, il Validation Engine di SDK procederà ad implementare i controlli descritti nel file che segue. Al verificarsi anche di un solo errore, tra quelli descritti il record oggetto di controllo sarà inserito tra gli scarti con il codice di errore riportato nella tabella seguente.

Le Business Rule transazionali non vengono implementate nell’SDK.

I controlli applicativi saranno implementati a partire dall’acquisizione dei seguenti dati anagrafici disponibili in ambito MdS e retrievati con servizi ad hoc (Service Layer mediante PDI):

• Anagrafiche Nazione, Regione, Provincia, Comune
• Tabella Codifica Istat
• Anagrafica Luoghi Incidente
• Anagrafica Strutture competenti
• Anagrafica Dispositivi Medici
• Classificazione CND del dispositivo
• Anagrafica Classi incidente
• Anagrafica Aziende

Il dato anagrafico sarà presente sottoforma di tabella composta da tre colonne:

• Valore (in cui è riportato il dato, nel caso di più valori, sarà usato il carattere # come separatore)

• Data inizio validità (rappresenta la data di inizio validità del campo Valore)

• Formato: AAAA-MM-DD

• Notazione inizio validità permanente: 1900-01-01

• Data Fine Validità (rappresenta la data di fine validità del campo Valore)

  • Formato: AAAA-MM-DD
  • Notazione fine validità permanente: 9999-12-31

Affinchè le Business Rule che usano il dato anagrafico per effettuare controlli, siano correttamente funzionanti occorre sempre controllare che la data di competenza (Anno, Mese di riferimento i quali rappresentano anno e mese di erogazione del farmaco) del record su cui si effettua il controllo, sia compreso tra le data di validità.

Di seguito viene mostrato un caso limite di anagrafica in cui sono presenti delle sovrapposizioni temporali (verde) e contraddizioni di validità permanente/specifico range (in rosso)

Diremo che : il dato presente sul tracciato di input è valido se e solo se:

∃ VALUE_R = VALUE_A “tale che” VALID_FROM(senza giorno)<= DATA_COMPETENZA <= VALID_TO(senza giorno)

(Esiste almeno un valore compreso tra le date di validità)

Dove:

• VALUE_R (rappresenta i campi del tracciato di input coinvolti nei controlli della specifica BR)

• VALUE_A (rappresenta i campi dell’anagrafica coinvolti nei controlli della specifica BR)

• VALID_FROM/VALID_TO (rapresentano le colonne dell’anagrafica)

Per l'installazione e l'avvio dell'engine seguire la documentazione tecnica dettagliata disponibile all'url INSTALL.md.

NOTA BENE:

Per la trasmissione del flusso Dispovigilance è previsto che il parametro “soglia.invio.mds” nel file di configurazione “/sdk/properties” sia impostato con il valore 100 per permettere uno scarto totale del file di input anche in presenza di un solo record non corretto evitando in questo modo acquisizioni parziali e scongiurando inconsistenze dei dati nel Sistema.

Questo progetto è rilasciato sotto licenza BSD 3-Clause License così come definita BSD 3-Clause License.

I contributi sono benvenuti. Si prega di consultare il file CONTRIBUTING.md per le linee guida su come contribuire al progetto.

Per ulteriori informazioni, contattare:

• Service Desk - Ministero della Salute: [email protected]
• Amministrazione titolare: Ministero della Salute

Accenture SpA until January 2026