COVID-19 (ReLaS-CV)

Progetto per la realizzazione di una Rete Regionale dei Laboratori per gli esami

COVID-19 (ReLaS-CV)

ATS

Data: 2020-09-30 17:12:19.0, PG/2020/226737

Progetto Esecutivo

Progetto Rete dei Laboratori COVID-19

Doc. _2020_09_30_Rete_COVID-19_Progetto_Esecutivo.docx Data 30/09/2020 Pagina 1 di 37

Sommario

1. Dati identificativi del progetto 4

1.1. Dati di progetto 4

1.2. Responsabili e referenti 4

1.2.1. Responsabili per l’esecuzione del progetto 4

1.3. Obiettivi di realizzazione 4

1.4. Documentazione di riferimento 4

1.5. Dati identificativi del documento 5

1.6. Acronimi e abbreviazioni 5

2. Premessa 6

3. Introduzione 6

4. Applicativi coinvolti 7

4.1. DNLab 7

4.2. Galileo 7

4.3. Picasso ESB 7

5. Contesto generale 7

6. Mutamenti del contesto 8

7. Realizzazione della rete di interoperabilità COVID-19 10

7.1. Interoperabilità tra LLU: soluzione realizzativa 11

7.2. Operatività da parte dei Laboratori 12

7.3. Operatività da parte dei Reparti Richiedenti 13

7.4. Punti di accettazione 13

7.5. Zone 15

7.6. Piani di Lavoro per lo smistamento verso altro HUB 15

7.7. Contenitori 16

7.8. Sistemi e Flussi per la pubblicazione richieste e la ricezione dei risultati 16

7.9. Pubblicazione e ricezione (richieste e risultati) 16

7.10. ESB – Configurazione dei canali 17

7.10.1. Flusso delle richieste 18

7.10.2. Flusso dei risultati 18

8. Richieste di esami COVID-19 19

8.1. Richieste per ricoverati 19

8.2. Richieste per esterni 20

8.3. Esecuzione dei Tamponi 25

8.4. Tamponi e test rapidi in mobilità 26

8.4.1. Tamponi in mobilità	26
8.4.1.1. Tamponi in mobilità: soluzione INPECO	27
8.4.1.2. Tamponi in mobilità: soluzione Service Life-DEDALUS	27
8.4.1.3. Nuove funzionalità sul modulo MAM	27
8.4.2. Test rapidi in mobilità	28
9. Rappresentazione dei dati		28
10. Integrazione col Sistema di Gestione dei casi: Realizzazione applicativo per alimentazione SIDI		28
11. Integrazione del Laboratorio dell’Istituto Zooprofilattico Sperimentale		28
12. Realizzazione piattaforma per l’indagine ISP		29
13. Piano delle attività		30

13.1. Realizzazione della rete di interoperabilità per esami COVID-19 30

13.2. Rilascio moduli aggiuntivi per tamponi ed esami rapidi 31

13.2.1. Opzione moduli aggiuntivi per tamponi ed esami rapidi 33

13.3. Realizzazione Cruscotto COVID-19 33

13.4. Realizzazione del DWH Centrale 34

13.5. Integrazione col Sistema di Gestione dei casi: realizzazione applicativo per alimentazione SIDI 34

13.6. Realizzazione piattaforma per Indagine Ministeriale ISP 35

13.7. Integrazione dell’Istituto Zooprofilattico Sperimentale della Sardegna 35

13.8. Nuove funzionalità sul modulo MAM 35

13.9. Modello organizzativo e funzionale 35

13.10. Figure coinvolte 36

14. Criticità 36

1. Dati identificativi del progetto

1.1. Dati di progetto

Acronimo di progetto	ReLaS-CV
Descrizione del progetto	Progetto per la realizzazione di una Rete Regionale dei Laboratori per gli esami COVID-19
Stazione Appaltante	ATS Sardegna (Unione d’acquisto con AOU Sassari, AOU Cagliari, AO Brotzu)
Aggiudicatario	Service life S.r.l.
Data inizio attività	15/04/2020
Data termine attività	15/10/2020
Importo netto	€ 187.500,00 + IVA

1.2. Responsabili e referenti

1.2.1. Responsabili per l’esecuzione del progetto

Responsabile procedimento Stazione Appaltante	Xxxx. Xxxxxxxxxxx Xxxxxxxxxxxxx
Direttore esecuzione contratto Stazione Appaltante	Xxxx. Xxxxx Xxxxx
Responsabile contratto Aggiudicatario	Xxxxxx Xxxxx
Capo progetto Aggiudicatario	Xxxxxx Xxx

1.3. Obiettivi di realizzazione

Rif. Descrizione

1 Rete interoperabilità esami COVID-19

2 Realizzazione Data Warehouse regionale COVID-19

3 Attivazione moduli per esami rapidi e tamponi in mobilità

4 Integrazione con Sistema regionale di Gestione dei casi mediante alimentazione del sistema SIDI

5 Realizzazione piattaforma per indagine Ministeriale di Siero-Prevalenza (ISP)

6 Eventuali altri che si dovessero determinare in corso d’opera

1.4. Documentazione di riferimento

Tipo	Rif e data	Descrizione
Progetto	22/04/2020	Progetto Tecnico
Offerta	22/04/2020	Stima economica e cronoprogramma
Delibera	ATS N.38 del 28/05/2020	Delibera di approvazione progetto
	UO_DIP_ICT-2020-35

Ordine

Ordinativo Stazione Appaltante

del 17/6/2020

1.5. Dati identificativi del documento

Tipo data Descrizione Versione

Progetto Esecutivo

30/09/2020 Progetto esecutivo Rete COVID-19 1

1.6. Acronimi e abbreviazioni

LLU Laboratorio Logico Unico

LIS Laboratory Information System

ESB Enterprise Service Bus

MPI Master Patient Index

LLUR Laboratorio Logico Unico Regionale

PDQ Patient Demographics Query

PIX Patient Identifier Cross Referencing

XML eXtensible Markup Language

HL7 Health Level Seven

O.E. Order Entry

CDA Clinical Document Architecture

PdA Punto di Accettazione

PdL Piano di Lavoro

UCL Unità di Crisi Locale

UCR Unità di Crisi Regionale

USCA Unità Speciali di Continuità Assistenziale

SISP Servizio Igiene e Sanità Pubblica

ASSL OT Area Socio Sanitaria Locale di Olbia

ASSL SS Area Socio Sanitaria Locale di Sassari

ASSL OG Area Socio Sanitaria Locale di Lanusei

ASSL NU Area Socio Sanitaria Locale di Nuoro

ASSL VS Area Socio Sanitaria Locale di Sanluri

ASSL OR Area Socio Sanitaria Locale di Oristano

ASSL CA Area Socio Sanitaria Locale di Cagliari

ASSL CI Area Socio Sanitaria Locale di Carbonia

AOUCA Azienda Ospedaliero Universitaria di Cagliari

AOUSS Azienda Ospedaliero Universitaria di Sassari

CUP Centro Unico di Prenotazione

ATS Azienda per la Tutela della Salute

DWH DataWareHouse

2. Premessa

Durante l’emergenza COVID-19, il Dipartimento ICT dell’ATS Sardegna, in collaborazione con le altre Aziende Sanitarie (x.xx. AOU di Sassari), prese atto della necessità di dare una prima risposta, di tipo emergenziale, per affrontare i temi più urgenti ed importanti che hanno caratterizzato la fase più acuta dell’epidemia in Sardegna, con particolare riguardo alla gestione delle determinazioni diagnostiche per il COVID-19.

Ben presto, dopo i primi interventi di risoluzione immediata ed emergenziale delle attività di supporto ai Servizi di Igiene Pubblica nelle attività di prelievo, accettazione ed inoltro dei campioni ai Laboratori di Riferimento, ci si rese conto che l’emergenza doveva essere affrontata in modo sistemico e completo; si passò quindi ad una difficile e complessa fase progettuale di un intervento organico (oggetto del presente Progetto), caratterizzata da continue trasformazioni delle configurazioni operative emergenziali e da novità di uno scenario del tutto inedito.

Alla fase progettuale prese parte attiva il Dipartimento ICT di ATS Sardegna, che ha indirizzato, in collaborazione con le altre Aziende Sanitarie, il progetto verso la sua forma attuale, cercando - il più possibile, tenuto conto dello scenario in continuo movimento - di contestualizzarlo alla realtà dei processi e degli atti regionali (Assessorato e Unità di Crisi Regionale) e locali (Unità di Crisi Locali e ASSL).

Si arrivò così alla stesura di un progetto tecnico che venne consegnato ufficialmente in data 22/04/2020, unitamente ad una stima economica e ad una prima ipotesi di cronoprogramma.

Il progetto, previa dichiarazione della Direzione Generale dell’Assessorato che lo indicò alle Aziende Sanitarie quale progetto strategico per la lotta alla pandemia in atto - venne presentato ed approvato da tutte le Aziende Sanitarie della Sardegna.

Il 28 maggio 2020 la Delibera n. 38 dell’ATS (come capofila dell’Unione d’acquisto), approvava il progetto e la sua stima economica. Seguì, il 17 giugno u.s., l’ordine formale di ATS Sardegna al fornitore individuato Service Life.

Dallo scorso 8 luglio, a seguito di una riunione cui hanno preso parte tutte le Aziende Sanitarie coinvolte (presentazione e relativo verbale in allegati A e B), il progetto è entrato nella sua fase esecutiva.

Nel frattempo, la risposta del Sistema Sanitario Regionale all’epidemia è in costante divenire.

Essa è cambiata notevolmente nel corso del tempo ed ora si attesta nel pieno della c.d. “Fase 3”, ossia la ripresa delle attività di ogni genere nel rispetto delle norme e raccomandazioni orientate al contenimento dei contagi, e – in questo momento – fortemente caratterizzata da una ripresa della curva epidemica che, specie in Sardegna, ha assunto dimensioni di rilievo.

Quindi, sia per la recrudescenza del fenomeno, sia per un possibile ulteriore innalzamento del livello di rischio per il prossimo autunno, il progetto di realizzazione della rete di Laboratori COVID- 19 è più che mai attuale e risulta essere di fondamentale importanza nella gestione dell’attuale nuova impennata dei contagi.

Il presente documento costituisce il Progetto Esecutivo per la realizzazione di quanto previsto, con le indispensabili integrazioni e modifiche imposte dalle mutate condizioni che si sono determinate tra l’approvazione del Progetto e la data di questo Progetto Esecutivo.

3. Introduzione

Nei paragrafi successivi verranno descritti tutti i passi progettuali previsti nel progetto ReLaS-CV, nonché l’architettura necessaria per implementare la rete dei Laboratori di Analisi in riferimento all’emergenza COVID-19; l’obiettivo è quello di creare un circuito di interoperabilità che consenta, ad ogni Laboratorio richiedente (Laboratorio Inviante), di usufruire di attività analitica dei tamponi COVID-19 svolte presso un Laboratorio di Riferimento regionale o presso altro Laboratorio (Laboratorio Erogante).

4. Applicativi coinvolti

4.1. DNLab

Il LIS DNLab è progettato per supportare le attività sanitarie, amministrative e gestionali caratteristiche del ciclo di gestione delle prestazioni di diagnostica di un moderno Laboratorio di Analisi.

Le principali funzionalità dei software sono:

▪ Accettazione ed inserimento delle richieste di esami per pazienti interni;

▪ Accettazione ed inserimento delle richieste di esami per pazienti esterni e gestione del ticket;

▪ Inserimento dei risultati;

▪ Stampa del referto;

▪ Gestione delle statistiche e produzione dei flussi informativi.

4.2. Galileo

Galileo è il Clinical Data Repository la cui funzione di Order Entry è utilizzata per le richieste di esami di Laboratorio dei pazienti ricoverati o per particolari tipologie di richieste di esami relativi a pazienti non ricoverati (x.xx. richieste di esami del Medico Competente per i personale dipendente). I pazienti esterni generalmente seguono un percorso diverso, a partire dall’accettazione che avviene principalmente presso gli sportelli del CUP regionale o negli ambulatori autorizzati alla richiesta di esami.

L’attuale emergenza, a sportelli CUP parzialmente riaperti in modalità contingentata, può essere gestita direttamente da Galileo, sfruttandone le funzionalità per l’identificazione dei pazienti e la richiesta dell’esame COVID-19, specie per gli esami determinati dall’Igiene Pubblica per sospetti positivi e per operazioni di screening in condizioni di focolai attivi e/o presso strutture particolarmente critiche (x.xx. RSA o Case di Riposo per anziani).

4.3. Picasso ESB

Per realizzare l’interoperabilità tra gli LLU, o meglio tra i Laboratori “aggiunti” o ordinari ed i Laboratori Centri di Riferimento COVID-19, si propone l’utilizzo dell’Enterprise Service Bus (ESB) Xxxxxxx, installato presso tutte le Aziende Sanitarie regionali, ed in grado di essere implementato in tempi rapidi per l’emergenza sanitaria in corso. Esso viene preferito alla soluzione SILUS2, per le motivazioni descritte più avanti nel presente documento.

Come è noto, le istanze locali di Xxxxxxx si occupano di governare tutte le integrazioni locali. In questo caso dovranno interfacciarsi tra di loro per creare la rete di integrazione/comunicazione che è la base del presente Progetto.

5. Contesto generale

L’emergenza sanitaria in atto richiede di aumentare la produttività e l’efficienza dei laboratori di analisi designati come Centri di Riferimento, creando le condizioni per garantire flussi informativi coerenti e automatismi che riducano il più possibile le attività amministrative.

Per quanto riguarda i Centri di Riferimento la situazione è in divenire. Il progetto originale prendeva atto del fatto che i tamponi erano processati dai seguenti Laboratori:

▪ Laboratorio di Virologia dell’AOU Sassari (Laboratorio Centro di Riferimento area Nord);

▪ Laboratorio di Analisi del P.O. San Xxxxxxxxx di Nuoro;

▪ Laboratorio di Analisi del P.O. SS. Trinità di Cagliari;

▪ Laboratorio di Analisi dell’AOU di Cagliari (Laboratorio Centro di Riferimento area Sud). Vista la crescente richiesta, i Laboratori, nell’intento di fornire i risultati nel minor tempo possibile, si scambiano i tamponi dirottandoli dove, nel dato momento, è disponibile personale e reagenti in grado di assolvere all’impegno di massima tempestività.

Di conseguenza, i conferimenti sono dinamici, e nessuna struttura ha in questo momento un Centro di Riferimento che possa dirsi unico, anche se – ovviamente – i Laboratori sono tutti, dal punto di vista dell’accreditamento e della sorveglianza, associati ad uno dei due Laboratori di Riferimento regionali (prima indicati).

Il Progetto di interoperabilità tra i Laboratori COVID-19 intende ricondurre a una gestione di processi totalmente informatizzati:

▪ le richieste degli esami, con la relativa pre-accettazione o accettazione;

▪ I tamponi e i campioni sierologici (in caso si esami di screening);

▪ la processazione dei tamponi e dei campioni sierologici;

▪ i risultati con la validazione tecnica degli stessi;

▪ i referti, con la relativa apposizione della firma digitale.

Le azioni proposte si riferiscono a tutte le strutture dei Laboratori di parte SSR della regione Sardegna.

6. Mutamenti del contesto

Il SSR ha predisposto ed attuato alcune migliorie alla Rete dei Laboratori con l’obiettivo di gestire al meglio i pazienti ricoverati, i propri operatori sanitari ed i pazienti territoriali.

I principali Laboratori di Analisi della regione sono stati messi in grado di eseguire tamponi ed esami sierologici in urgenza, mediante l’acquisizione di macchinari “a bassa produttività”. Tali esami sono quindi riferibili a ricoverati (anche e soprattutto provenienti dal Pronto Soccorso), ed al personale sanitario ed amministrativo afferente alle varie Aziende ed Aree Socio Sanitarie Locali.

Il prossimo obiettivo sarà di permettere alle varie ASSL (componenti l’ATS Sardegna), di gestire direttamente i pazienti del proprio territorio di afferenza.

Obiettivo della Rete dei Laboratori COVID-19 è quello di garantire:

▪ nella situazione attuale, il conferimento degli esami dei pazienti territoriali ai Laboratori COVID-19 di riferimento;

▪ nella situazione immediatamente futura, la disponibilità di una rete in grado di permettere lo smistamento di campioni e tamponi verso altri Laboratori, nel caso in cui se ne presentasse la necessità (x.xx. presenza di focolai sul territorio, carenza di personale o reagenti di altri laboratori, ecc.).

Ad oggi, la mappa dei Laboratori COVID-19 definita dall’Assessorato alla Igiene e Sanità è la seguente:

Laboratorio	referente	Tipo Laboratorio	Laboratorio di riferimento	UCL di riferimento	Produttività
S.C. Microbiologia e Virologia Laboratorio Virologia -Speciale Centro Influenza - AOU di Xxxxxxx - Xxxxx xxx Xxxxxx 00/X Palazzo Infettivologia – Sassari 079 229807	Prof.ssa Xxxxxxxx Xxxxx	laboratorio di riferimento		Sassari	ALTA

Laboratorio	referente	Tipo Laboratorio	Laboratorio di riferimento	UCL di riferimento	Produttività
Laboratorio Generale (HUB) di analisi chimico cliniche e microbiologia - P.O. Xxxxxx Xxxxxx - AOU di Cagliari X.X. 000 Xx. 0,000 - Xxxxxxxxxx (XX) 070 51096471	Xxxx. Xxxxxxxxxx Xxxxx 070 51096471	laboratorio di riferimento		Cagliari	ALTA
Laboratorio di analisi Ospedale Civile "X. Xxxxx" di Ozieri - xxx Xxxxx Xxxxxxxxxx 00000 Xxxxxx (XX) 000 000000	Dott.ssa Xxxxxxxxxx Xxxxx	laboratorio aggiuntivo accreditato	AOU Sassari	Sassari	BASSA
Laboratorio di analisi Ospedale Civile di Alghero - xxx Xxx Xxxxxxx 00000 Xxxxxxx (XX) 079 9955111	Xxxx. Xxxxx Xxxxxx Xxxxxx	laboratorio aggiuntivo in fase di accreditamento	AOU Sassari	Sassari	BASSA
Laboratorio di analisi Ospedale “Xxxxxxxx Xxxxx XX” di Olbia- xxx Xxxxxxx Xxxxxxx, xxx. Xxxxxxxx 00000 Xxxxx (XX) 0789 552200	Xxxx. Xxxxxx Xxx	laboratorio aggiuntivo in fase di accreditamento (accreditato per indagine ISP)	AOU Sassari	Sassari	BASSA
Laboratorio analisi Xxxxxxxx Xxx Xxxxxxxxx Xxx Xxxxxxxxx 00000 Xxxxx 0784 240369, 0784 240265	Xxxx. Xxxxxxxx Xxxxxx	laboratorio aggiuntivo accreditato	AOU Sassari	Sassari	ALTA
Laboratorio di analisi Ospedale “N.S. della Mercede” di Lanusei - xxx Xxxxxxxx Xxxxx 0 00000 Xxxxxxx (XX) 0782 490206	Dott.ssa Xxxx Xxxxx	laboratorio aggiuntivo accreditato	AOU Sassari	Sassari	BASSA
Laboratorio di analisi Ospedale San Xxxxxxx - ATS Sardegna - ASSL Oristano Xxx Xxxxxxxxxxx 00 - Xxxxxxxx 0783 317319	Xxxx. Xxxxxxx Xxxx tel. 0000 00000	laboratorio aggiuntivo accreditato	AOU Cagliari	Cagliari	MEDIA
Laboratorio di analisi Ospedale Nostra Signora di Bonaria - San Xxxxxx Xxxxxxxx - ATS Sardegna - ASSL Sanluri Xxx Xxxx – Xxx Xxxxxx Xxxxxxxx 070 9378229	Xxxx. Xxxxxxxxx Xxxxxx	laboratorio aggiuntivo accreditato	AOU Cagliari	Cagliari	BASSA
Laboratorio di analisi Ospedale “Sirai” di Carbonia - via dell’Ospedale 09013 Carbonia (CA) 0781 6681	Dott.ssa Xxxxxxxx Xxxxx	laboratorio aggiuntivo in fase di accreditamento	AOU Cagliari	Cagliari	NULLA
Laboratorio di analisi Ospedale Santissima Trinità - Xxx Xx Xxxxxxxxx, 00 00000 Xxxxxxxx 070 609 5934	Dott.ssa Xxxxxxxxxx Xxxx 070 6095997	laboratorio aggiuntivo accreditato	AOU Cagliari	Cagliari	ALTA
Laboratorio di analisi Xxxxxxxx Xxx Xxxxxxx - Xxxxxxx Xxxxxxxxxxx Xxxxxx Xxxxxxxx Xxxxxx ,0 Cagliari 070 539812 -804- 806	Dott.ssa Xxxxxxxx Xxxxxxxxx - Dott.ssa Xxxxxxxxx Xxxxxxx	laboratorio aggiuntivo accreditato	AOU Cagliari	Cagliari	BASSA

Laboratorio	referente	Tipo Laboratorio	Laboratorio di riferimento	UCL di riferimento	Produttività
Laboratorio diagnostica, Istituto Zooprofilattico Sperimentale della Sardegna - Xxx Xxxx xxxxx Xxxxxxx, 0 00000 Xxxxxxx 079 289200	Xxxx. Xxxxxxx Xxxxxxxxx Xxxx.Xxxxxxx Xxxxxx	laboratorio aggiuntivo accreditato	AOU Sassari	Sassari	MEDIA
Laboratorio di analisi del Mater Olbia Hospital SS 125 Orientale sarda, Xxxxxxxx Xxxxxxxxxxxx 00000 Xxxxx 0789 1899701	Xxxx. Xxxxxxxx Xxxxxx	laboratorio aggiuntivo (con limitazione della operatività ai propri dipendenti e pazienti assistiti nella struttura).	AOU Sassari	Sassari	BASSA
Policlinico Sassarese della LABOR SPA Xxxxx Xxxxxx, 00, 00000 Xxxxxxx SS - (ingresso diagnostica di laboratorio in via Porcellana) 079 222700	Dott.ssa Xxxxxxx Xxxxxxxxxx, dott.ssa Xxxxx Xxxxx	laboratorio aggiuntivo con limitazione della operatività ai propri dipendenti e pazienti assistiti nella struttura, ed esclusivamente per il periodo dell'emergenza	AOU Sassari	Sassari	BASSA
Laboratorio di analisi della Casa di cura Polispecialistica Sant'Elena Viale Marconi 160, 09045 Quartu Sant’Elena	Dott.ssa Xxxxx Xxxxxxxx Xxxx	laboratorio aggiuntivo con limitazione della operatività ai propri dipendenti e pazienti assistiti nelle strutture del gruppo Kinetika Sardegna, ed esclusivamente per il periodo dell'emergenza	AOU Cagliari	Cagliari	BASSA

Figura 1 – Mappa Laboratori COVID-19

Per quanto riguarda i debiti informativi e l’integrazione con la Piattaforma Regionale per la gestione dei casi realizzata da SardegnaIT, è stata approntata sul sistema regionale SIDI (Sistema Informativo Debiti Informativi) una struttura specifica per accogliere il flusso informativo (denominato Flusso DCL – File T) relativo agli esami COVID-19 eseguiti in tutto il territorio regionale.

Per consentire a ciascun Laboratorio l’alimentazione del SIDI, nell’ambito del Progetto, in anticipo di fornitura per estrema urgenza, è stato realizzato un applicativo (denominato COVID-FLOW), che permette l’estrazione dei dati nel formato richiesto, per il successivo caricamento nel SIDI.

Tale applicativo è entrato in produzione lo scorso 5 giugno 2020, in tempi più che adeguati alla emergenza in atto.

7. Realizzazione della rete di interoperabilità COVID-19

La rete di interoperabilità COVID-19 è basata – come detto - sulla rete degli ESB Xxxxxxx, che realizzano una federazione mediante l’utilizzo dell’HUB di ATS Sardegna, già previsto in altro Progetto ATS, come HUB regionale.

L’architettura è quella rappresentata di seguito:

Figura 2 – Rete di Interoperabilità

Questa componente del Progetto rappresenta una declinazione specifica di quanto già previsto nel Progetto di Riorganizzazione dei Laboratori di Analisi di ATS Sardegna, basata su una convenzione CONSIP “SGI – Lotto 5 – Sanità Sud” (con RTI la cui capogruppo è DXC SpA), in via di riattivazione operativa dopo il periodo di sospensione dovuto all’approvazione di una nuova struttura organizzativa della Rete dei Laboratori di Analisi dell’ATS Sardegna, in vista della applicazione della Riforma del SSR recentemente approvata.

7.1. Interoperabilità tra LLU: soluzione realizzativa

Al fine di evitare che i campioni debbano essere rietichettati, è necessario configurare i sistemi DNLAB in modo tale che riservino alcune numerazioni delle richieste specificamente per gli esami COVID-19 da scambiare con gli altri LLU.

Solitamente il codice identificativo della richiesta è una stringa di 8 caratteri numerici; la configurazione dei Punti di Accettazione prevede la possibilità di gestire la tipologia degli intervalli di generazione degli identificativi da assegnare (rif. capitolo a seguire).

E’ quindi necessario:

▪ armonizzare la numerazione delle richieste/campioni per ogni LLU in modo tale da assegnare ad ogni Impianto un range numerico che non si sovrapponga con quelli assegnati agli altri Impianti;

▪ garantire il riconoscimento, da parte di ogni impianto, dei range numerici utilizzati dagli altri Impianti;

▪ garantire la corretta gestione anagrafica per ogni Assistito dispetto tenuto conto della possibile differenza fra i diversi identificativi XMPI a lui associati;

▪ garantire la connettività fra le componenti del Sistema.

7.2. Operatività da parte dei Laboratori

La modalità di utilizzo della soluzione in corso di implementazione non deve discostarsi dall’attuale operatività dei LLU che inviano all’esterno campioni da processare, e dei LLU che ricevono, dall’esterno, gli stessi campioni da processare (ad esempio, tra le ASSL di Lanusei e Nuoro).

I punti fondamentali per la corretta gestione del flusso sono i seguenti:

▪ Laboratorio Inviante:

− E’ necessario che i campioni da inviare vengano raccolti nel Laboratorio di afferenza del Reparto COVID-19 che ha effettuato i tamponi;

− Il Laboratorio Inviante, una volta ricevuti i tamponi, si occupa di effettuare il Check-In e stampare la lista dei Campioni/Analisi che devono essere eseguiti dal Laboratorio Erogante;

− Il Laboratorio Inviante si occupa di tutta la fase Preanalitica necessaria prima dell’invio dei campioni;

− Il Laboratorio Inviante consegna i campioni al Corriere.

▪ LIS/ESB del Laboratorio Inviante:

− Il DNLab si occupa di creare un messaggio relativo ad ogni richiesta di Reparto contenente campioni da smistare verso il Laboratorio Erogante;

− Xxxxxxx ESB del Laboratorio Inviante procede con l’invio dei messaggi al Picasso ESB Centrale, che si occupa dell’inoltro del messaggio al Picasso ESB del Laboratorio Erogante previsto.

▪ ESB/LIS del Laboratorio Erogante:

◦ Xxxxxxx ESB del Laboratorio Erogante riceve il messaggio da Xxxxxxx ESB Centrale;

▪ Laboratorio Erogante:

− Il DNLab del Laboratorio Erogante riceve gli Orders da Xxxxxxx ESB locale;

− Il Laboratorio Erogante riceve dal Corriere i campioni e la lista prodotta dal Laboratorio Inviante;

− Il Laboratorio Erogante esegue il Check-In dei campioni e li mette in lavorazione;

− Il Laboratorio Erogante produce i risultati;

− Il DNLab si occupa della pubblicazione dei risultati verso Xxxxxxx ESB locale;

▪ LIS/ESB Laboratorio Erogante vs ESB/LIS Laboratorio Inviante via Picasso ESB Centrale:

− Xxxxxxx ESB si occupa dell’invio del messaggio contenente i risultati al Xxxxxxx ESB Centrale;

− Il Picasso ESB Centrale invia i risultati al Picasso ESB del Laboratorio Inviante;

− Il DNLab del Laboratorio Inviante riceve i risultati e procede con il completamento delle richieste (Firma Digitale del Referto).

Per quanto concerne la gestione dei risultati da parte del Laboratorio Erogante, non sono previste modifiche dell’operatività (a meno di eventuali specifiche richieste in corso d’opera): il Laboratorio Erogante si occuperà di firmare digitalmente le richieste provenienti dal Laboratorio Inviante; i risultati ed i Referti verranno inviati a Xxxxxxx

7.3. Operatività da parte dei Reparti Richiedenti

La modalità di utilizzo della soluzione in corso di implementazione deve prevedere, per i Reparti degli LLU che inviano all’esterno dei campioni da lavorare, quanto segue:

▪ Reparti COVID-19 INT (utilizzano l’O.E. Xxxxxxx): le analisi COVID da smistare verso altri LLU Eroganti devono essere presenti sulle Pagine di Richiesta;

▪ Reparti COVID-19 EXT (utilizzano l’O.E. Xxxxxxx): i codici analisi da smistare verso altri HUB LLU Eroganti devono essere disponibili in accettazione.

Nel seguito del presente paragrafo si riepilogano le configurazioni attive e si delineano le configurazioni da implementare e vengono definiti i Sistemi ed i Flussi per la generazione e la ricezione degli appropriati messaggi HL7 da configurare su ogni LLU.

7.4. Punti di accettazione

L’obiettivo è la definizione di un range di numerazione, comune a tutti gli Impianti, da dedicare alle richieste che dovranno essere prodotte al fine di procedere con la lavorazione dei relativi campioni di Ricerca del COVID-19 da processare.

Avere un Punto di Accettazione (PdA) comune a tutti gli Impianti significa avere una numerazione facilmente leggibile/interpretabile da parte del Personale di ogni HUB e di ogni Spoke.

Per quanto concerne la numerazione del PdA, da dividere in base agli Impianti ed alla tipologia di utilizzo, si valuta che:

▪ Identificativi da 6 cifre con azzeramento giornaliero (xxxxxx<g<zzzzzz) o annuale (xxxxxx<a<zzzzzz): vengono a priori scartati poiché non consentono una agevole suddivisione;

▪ Identificativo da 8 cifre con progressivo da 4 che si azzera giornalmente (MMDDxxxx): sono i range più ampiamente utilizzati da parte degli Impianti e per tale motivo da scartare;

▪ Identificativo con sequenziale assoluto da 8 cifre (xxxxxxxx<IA<zzzzzzzz): i range di questo tipo sono di uso comune sugli Impianti, ma la scelta deve essere effettuata previo assessment delle configurazioni al fine di identificare un range comune non al momento utilizzato;

▪ Identificativo con sequenziale assoluto da 10 cifre (xxxxxxxxxx<IA<zzzzzzzzzz): tali range non sono di uso comune sugli Impianti.

La configurazione più sicura per l’interscambio dei campioni di Ricerca del COVID-19 è quindi l’ultima proposta.

L’utilizzo di tale numerazione potrebbe essere alla base di un futuro ampliamento del parco analisi da gestire con l’Interoperabilità fra i Laboratori finalizzata alla possibilità di usufruire delle competenze in attività analitica di alta specializzazione attualmente non comune su tutti gli Impianti sardi.

La suddivisione in base agli Impianti è necessaria, poiché è fondamentale soddisfare le seguenti condizioni:

▪ univocità della richiesta da generare nell’ambito dell’insieme dei Laboratori che lavorano, ognuno, con il proprio DNLAB;

▪ possibilità per più Impianti di lavorare sia le proprie richieste di Ricerca di COVID-19 che quelle provenienti da altri Impianti (Impianti che hanno generato la richiesta o Impianti che l’hanno ricevuta ma, per cause esterne, sono costretti a spostarne la lavorazione su un terzo Impianto).

Per quanto concerne la tipologia di utilizzo si evidenzia che:

▪ Interni – è consolidato l’utilizzo dell’Order Entry di Xxxxxxx per le accettazioni dei Pazienti Interni;

▪ Esterni – la necessità di approdare ad una soluzione veloce e sicura limita la scelta alle sole interfacce SILUS.

Analogamente al CUPWEB, le altre tipologie di Integrazione con Sistemi Esterni che colloquiano con il LIS DNLab inviando richieste (p.e.: il SIT gestito con EmoNet x Xxxxx), non rientrano nel perimetro della presente analisi.

In funzione di quanto sopra riportato e visto che per i Centri di Riferimento e per gli altri Laboratori la situazione è in divenire, segue un esempio di configurazione:

Struttura	Richieste	Range iniziale	Range finale
ASSL Sassari	Interni	0000000001	0001000000
	Esterni	0001000001	0002000000
	Interoperabilità	0002000001	0022000000
ASSL Olbia	Interni	0002000001	0003000000
	Esterni	0003000001	0004000000
	Interoperabilità	0002000001	0022000000
ASSL Nuoro	Interni	0004000001	0005000000
	Esterni	0005000001	0006000000
	Interoperabilità	0002000001	0022000000
ASSL Lanusei	Interni	0006000001	0007000000
	Esterni	0007000001	0008000000
	Interoperabilità	0002000001	0022000000
ASSL Oristano	Interni	0008000001	0009000000
	Esterni	0009000001	0010000000
	Interoperabilità	0002000001	0022000000
ASSL Sanluri	Interni	0010000001	0011000000
	Esterni	0011000001	0012000000
	Interoperabilità	0002000001	0022000000
ASSL Carbonia	Interni	0012000001	0013000000
	Esterni	0013000001	0014000000
	Interoperabilità	0002000001	0022000000
ASSL Cagliari	Interni	0014000001	0015000000
	Esterni	0015000001	0016000000
	Interoperabilità	0002000001	0022000000
AOU Sassari	Interni	0016000001	0017000000
	Esterni	0017000001	0018000000
	Interoperabilità	0002000001	0022000000
AOU Cagliari	Interni	0018000001	0019000000
	Esterni	0019000001	0020000000
	Interoperabilità	0002000001	0022000000
AO Brotzu	Interni	0020000001	0021000000
	Esterni	0021000001	0022000000
	Interoperabilità	0002000001	0022000000

Figura 3 – Esempio di configurazione – Range di numerazione

Su ogni LLU si procederà alla configurazione dei range utilizzati per l’inserimento delle Richieste (ogni range della precedente tabella potrà essere suddiviso ulteriormente in base alle esigenze del LLU che lo utilizza; non è necessario che sul Laboratorio Erogante venga estesa tale configurazione aggiuntiva).

Per il Laboratorio Erogante è necessaria la configurazione di range, dedicati alle richieste provenienti da altrettanti Laboratori HUB Richiedenti, che comprendono la numerazione delle richieste che riceverà tramite l’Interoperabilità.

L’assegnazione dei range verrà definita come segue:

• PdL DNTerritorio – verrà assegnato il PdA Xxxxxxx (o un suo sottoinsieme);

• O.E. Galileo – a seguito dell’attivazione dei nuovi Reparti denominati COVID-19-INT verrà assegnato il PdA Interni (o un suo sottoinsieme);

• Utenti che effettuano accettazioni dirette sul DNLab (hanno la facoltà di modificare il PdA predefinito in configurazione durante la fase di accettazione delle Richieste) – verrà assegnato il PdA Xxxxxxx (o un suo sottoinsieme) come default.

7.5. Zone

La definizione, sul LLU Inviante, delle Zone relative agli altri LLU è necessaria poiché legata a:

• Gestione documentale:

◦ sulle etichette relative ai Campioni è utile che compaia il Laboratorio Erogante;

◦ sul Referto Firmato Digitalmente deve comparire il Laboratorio che ha provveduto alla lavorazione dell’analisi smistata;

◦ i Report di Consultazione Richieste e le Statistiche di Produzione hanno come filtro la Zona di Esecuzione delle Analisi (oltre la Zona di Accettazione);

• Gestione Flusso di Pubblicazione delle Richieste: tramite la creazione dei PdA da utilizzare per richiamare la Procedura di Pubblicazione Invia Richieste del Package iseScambioRichieste.

A completamento della configurazione del LIS DNLab deve essere utilizzata la funzionalità relativa allo “Smistamento Analisi-Zone” del LLU Inviante.

Gli Utenti del Laboratorio avranno la possibilità di consultare le Richieste/Campioni/Analisi ed effettuare la creazione (con inserimento “random” - controllato dall’Operatore tramite la lettura di ogni Campione - o “automatico” - gestito automaticamente dal LIS - in base alle esigenze del Laboratorio Inviante) e stampa dei PdL.

7.6. Piani di Lavoro per lo smistamento verso altro HUB

Come accennato nel paragrafo precedente, la configurazione di uno o più PdL per ogni Zona relativa agli altri tre LLU è funzionale all’attivazione del Flusso di Pubblicazione delle Richieste.

La possibilità di configurare più PdL per ogni LLU HUB Erogante garantisce maggiore flessibilità nel caso in cui il Laboratorio HUB Erogante sia strutturato su più di una Sede:

• Il Laboratorio Inviante popola il PdL relativo ad ogni Settore/Sede (p.e.: “HUB SUD – Sierologia Padiglione A” e “HUB SUD – Infettivologia Padiglione H”) e ne consegna la stampa, assieme ai Campioni letti, al Corriere;

• Ogni Settore/Sede del Laboratorio HUB Erogante riceve i Campioni corredati dalla stampa del relativo PdL prodotto nel Laboratorio Inviante contenente la lista dei Pazienti e delle Analisi che devono essere eseguite;

• Il Laboratorio Inviante ha disponibilità del PdL stampato sul LIS e lo può ristampare a video per qualsiasi verifica.

Per la configurazione dei PdL il LIS DNLab necessita della definizione di:

• Stazione Analitica;

• Settore.

La struttura da configurare prevederà quindi:

• Almeno un Settore per ogni LLU HUB Erogante;

• Una Stazione Analitica (una per ogni Settore del punto precedente);

• Uno o più PdL per Zona legati alle Stazioni Analitiche definite.

7.7. Contenitori

Come accennato l’identificazione del set di analisi da smistare dal Laboratorio Inviante al LLU HUB Erogante prevede la necessità di dettagliare come le analisi sono raggruppate nei campioni e quindi come sono configurati i Contenitori del Laboratorio Erogante.

La configurazione del Laboratorio Inviante dovrà ricalcare fedelmente quanto in produzione sul Laboratorio Erogante.

Come già definito per i PdA, a garanzia dell’univocità e della lavorabilità di ogni campione, verranno impostati gli identificativi in base alla sede anatomica del tampone.

Identificativo	Materiale
98	Tampone orofaringeo
99	Tampone rinofaringeo

In base a quanto su riportato seguono gli esempi:

Impianto Richiedente	Reparto	Materiale	Esempio ID Richiesta	Relativo ID Campione
ASSL Olbia	Interno	Tampone orofaringeo	0002000012	000200001298
ASSL Lanusei	Esterno	Tampone rinofaringeo	0007000004	000700000499
ASSL Olbia	Esterno	Tampone rinofaringeo + Tampone orofaringeo	0003000025	000300002599 000300002598

Figura 4 – Esempio identificativi

7.8. Sistemi e Flussi per la pubblicazione richieste e la ricezione dei risultati

Su ogni LLU HUB Inviante dovranno essere definiti i Sistemi relativi a:

• pubblicazione delle richieste e ricezione dei risultati relativi agli LLU HUB Erogante;

• ricezione delle richieste e pubblicazione dei risultati relativi ai tre LLU HUB Invianti.

In funzione dei Sistemi definiti, dovranno essere configurati i relativi flussi di integrazione per la produzione/ricezione dei messaggi.

La pubblicazione delle richieste avviene mediante la creazione di apposito messaggio OML^O21 che l’HL7Gateway del Laboratorio Inviante provvede ad inoltrare all’ESB Picasso locale.

La ricezione dei risultati avviene mediante gestione di apposito messaggio OUL^R22 che l’HL7Gateway del Laboratorio Inviante riceve dall’ESB Picasso locale.

7.9. Pubblicazione e ricezione (richieste e risultati)

Pubblicazione Richieste e acquisizione Risultati

Per il Laboratorio HUB Inviante, come trattato nei precedenti paragrafi, verranno organizzate le configurazioni di uno o più PdL per la pubblicazione delle richieste.

Il LIS DNLab mette a disposizione la Procedura InviaRichieste che verrà richiamata in JOB con una schedulazione automatica di 60 minuti unitamente alla Procedura di Transcodifica:

begin

ISEScambioRichieste.InviaRichieste

('SistemaDestinazione', 'SistemaEsterno', bytidlab,

'PdL sulla Zona di Destinazione', data creazione PdL da, data creazione PdL a, '', 'WKS di Pubblicazione','USER di Pubblicazione');

ISETranscodifica

('SistemaDestinazione','SistemaEsterno (p.e.: LAB)', 'WKS di Pubblicazione', 'USER di Pubblicazione');

end;

Analogamente è disponibile la procedura AcquisisciRisultati richiamata sempre mediante JOB:

ISEScambioRichieste.AcquisisciRisultati('SistemaDestinazione',

'SistemaEsterno (p.e.: LAB)', bytidlab,

'PdL sulla Zona di Destinazione', bytupdrisultati, NULL, 'WKS di Acquisizione', 'USER di Acquisizione', 'Stazione Analitica sulla Zona di Destinazione');

Acquisizione Richieste e pubblicazione Risultati

Per il Laboratorio HUB Erogante, come trattato nei precedenti paragrafi, verranno utilizzate le configurazioni già in essere per la gestione delle richieste acquisite.

Il LIS DNLab mette a disposizione la procedura AcquisisciRichieste richiamata sempre mediante JOB:

ISERichieste.AcquisisciRichieste ('SistemaDestinazione (p.e.: LAB)',

'SistemaEsterno',

'WKS di Acquisizione', 'USER di Acquisizione');

Analogamente è disponibile la procedura PubblicazioneRisultati richiamata sempre mediante JOB:

ISERisultati.PubblicazionRisultati('SistemaDestinazione (p.e.: LAB)',

'WKS di Pubblicazione','USER di Pubblicazione');

7.10. ESB – Configurazione dei canali

Il presente paragrafo ha lo scopo di attestare l’analisi dell’infrastruttura per la gestione dello scambio messaggi, inerenti al COVID-19, tra i LIS presenti nelle aziende Ospedaliere.

L’analisi fornirà i dettagli sull’infrastruttura, la messaggistica e le informazioni sui filtri da applicare ai messaggi per l’identificazione del laboratorio richiedente e del Laboratorio Erogante.

Per poter rendere l’architettura operativa occorre che vengano individuati gli attori che effettuano le analisi dei campioni (eroganti) e da quali strutture vengo inviati (richiedenti).

Le integrazioni da realizzare prevedono:

▪ sul Picasso locale mittente una configurazione di tipo uno a uno;

▪ sul Xxxxxxx federato una configurazione di tipo uno a molti;

▪ sul Picasso locale destinatario una configurazione di tipo uno a uno.

I canali Picasso utilizzeranno una modalità asincrona per la gestione dei messaggi. Tale modalità prevede che, alla ricezione di un messaggio inviato verso Xxxxxxx, venga inviato immediatamente un ACK di risposta, per poi inoltrare il messaggio al destinatario. Inoltre, tali canali sfrutteranno le potenzialità, descritte in precedenza, dell’istanza Picasso federata, tali sviluppi hanno come prerequisito la connettività tra le istanze locali e quella federata.

Di seguito verranno descritti gli schemi generali di funzionamento.

7.10.1. Flusso delle richieste

La figura mostra lo schema generale della nuova integrazione su XXXXXXX.

Figura 5 – Schema Integrazione ESB Picasso – Flusso richieste

Nello schema precedente viene descritta, a titolo esemplificativo, la casistica che prevede l’invio della richiesta al laboratorio di AOU Cagliari da parte di un laboratorio richiedente.

In questa architettura tutti i laboratori richiedenti, tramite il relativo Picasso Locale, possono inviare un messaggio di tipo OML^O21 al Picasso Centrale. Secondo la discriminante del reparto richiedente presente all’interno del messaggio HL7, il sistema centrale individuerà l’hub di riferimento (erogante) a cui inoltrare la richiesta di analisi.

In questo flusso, in particolare, il tipo messaggio inviato sarà di tipo OML^O21 in versione PIPE 2.5.

7.10.2. Flusso dei risultati

La figura mostra lo schema generale della nuova integrazione su XXXXXXX.

Figura 6 – Schema Integrazione ESB Xxxxxxx – Flusso risultati

L’implementazione realizzata sull’ESB PICASSO per questo flusso prevede una architettura analoga a quella descritta nel punto precedente.

Nello schema precedente viene descritta, a titolo esemplificativo, la casistica che prevede l’invio dei risultati dal laboratorio di AOU Cagliari verso il laboratorio richiedente.

In questa architettura tutti i laboratori eroganti, tramite il relativo Picasso Locale, possono inviare i risultati con un messaggio di tipo OUL^R22 al Picasso Centrale. Secondo la discriminante del reparto richiedente presente all’interno del messaggio HL7, il sistema centrale individuerà il laboratorio a cui inoltrare i risultati delle analisi.

In questo flusso, in particolare, il tipo messaggio inviato sarà di tipo OUL^R22 in versione PIPE 2.5.

8. Richieste di esami COVID-19

8.1. Richieste per ricoverati

Per quanto riguarda le richieste, si propone l’attivazione di un nuovo raggruppamento su DNLab e Galileo denominato COVID-19-INTx (dove x è l’identificativo della struttura).

Tale raggruppamento, che funzionerebbe come un reparto “logico”, potrebbe accogliere, tramite le già conosciute funzioni di Galileo (MAP – Modulo Accettazione Paziente), tutti i degenti per i quali è stato richiesto un esame COVID-19. Al reparto accederebbero solo le strutture abilitate, che potrebbero così inoltrare al Laboratorio di riferimento i tamponi eseguiti.

Dal Laboratorio, in modo automatico, riceverebbero dentro lo stesso Xxxxxxx i referti (sarebbe possibile anche la pubblicazione dei risultati validati) di tutti i pazienti per i quali è stata effettuata la richiesta.

In alternativa, o in aggiunta, per diminuire l’impatto del progetto, è necessario lasciare che le strutture continuino ad operare come già fanno.

Sarà necessario, come sempre, prestare molta attenzione all’atto dell’accettazione, lavorando per codice fiscale e preferendo sempre i pazienti con codice prefissato da XMPI, in quanto si tratta in questi casi di anagrafiche certificate dal modulo ADT di SISaR.

8.2. Richieste per esterni

Il processo di esecuzione e tracciabilità già attivo per i pazienti esterni, nel caso del COVID-19, subisce alcune modifiche dovute alle seguenti circostanze:

1) i Centri Prelievo lavorano a regime limitato (su appuntamento);

2) di conseguenza, in molti casi, le richieste non passano per il CUPWEB;

3) i tamponi possono essere eseguiti fuori dal perimetro delle AS, o direttamente a casa dei pazienti, o in strutture colpite dal contagio (Residenze per anziani, RSA, ecc) ad opera di soggetti non inquadrati nelle Aziende Sanitarie (Esercito, Protezione Civile, ecc.).

Per poter eseguire le operazioni in sicurezza, mantenendo la tracciabilità degli eventi e dei campioni, si propone di agire come segue.

Ipotesi N.1: Disponibilità preventiva dei dati anagrafici dei pazienti:

▪ Si definiscono su tutti i Galileo e DNLab una serie di reparti denominati “COVID-EXTX YYY” (dove X rappresenta l’Area/Azienda e YYY il centro di riferimento COVID-19. In tali reparti verranno raggruppati tutti i pazienti per i quali è stato richiesto un tampone.

▪ Sui Centri di riferimento viene inoltre creato un reparto denominato “COVID-19 EXT XXX” (dove XXX rappresenta l’Area/Azienda) per i pazienti esterni accettati sul Laboratorio locale.

▪ La struttura che deve eseguire il tampone (infermieri della struttura RSA o altro, medici ed infermieri dell’esercito, ecc.), identifica i pazienti mediante raccolta dei dati anagrafici prima del tampone (almeno nome, cognome e codice fiscale);

▪ I dati vengono trasmessi al Laboratorio più vicino, che provvede ad attivare su DNLab le procedure di preaccettazione e stampa delle etichette barcode da apporre ai tamponi prelevati (o ai contenitori);

▪ La struttura che deve eseguire il tampone va in Laboratorio e ritira le etichette (o i contenitori etichettati);

▪ I tamponi vengono riportati presso il Laboratorio che provvede a processarli o inoltrarli al Laboratorio di riferimento (vedi succ. Movimentazione dei campioni);

▪ Risultati e referti tornano automaticamente sul reparto Galileo COVID_EXTnn richiedente.

Ipotesi N.2: Indisponibilità preventiva dei dati anagrafici dei pazienti:

▪ Si definiscono su tutti i Galileo e DNLab una serie di reparti denominati “COVID-EXTX YYY” (dove X rappresenta l’Area/Azienda e YYY il centro di riferimento COVID-19. In tali reparti verranno raggruppati tutti i pazienti per i quali è stato richiesto un tampone.

▪ Sui Centri di riferimento viene inoltre creato un reparto denominato “COVID-19 EXT XXX” (dove XXX rappresenta l’Area/Azienda) per i pazienti esterni accettati sul Laboratorio locale.

▪ I Xxxxxxx vengono eseguiti, e nel frattempo vengono collezionate le informazioni anagrafiche dei pazienti (almeno nome, cognome, data e luogo di nascita e codice fiscale);

▪ Xxxxxxx e dati anagrafici vengono consegnati agli operatori autorizzati (Dipartimento di Igiene pubblica e prevenzione);

▪ Gli operatori autorizzati si collegano a Galileo, selezionano il reparto corretto (provenienza e destinazione del tampone), ed eseguono la preaccettazione del tampone, con etichettatura dei contenitori;

▪ Il tampone viene spedito al Centro di riferimento individuato;

▪ Il Laboratorio fa il checkin del campione e lo processa;

▪ Risultati e referti tornano automaticamente sul reparto Galileo COVID_EXT richiedente.

Anche in caso di accettazioni eseguite direttamente su DNLAB, il tampone verrà diretto verso uno dei Centri di Riferimento mediante scelta del reparto COVID-EXT. Su Galileo il paziente verrà transcodificato sulla base dei dati anagrafici provenienti da DNLab.

I reparti devono avere su DNLab un Laboratorio di Riferimento: significa che i reparti sotto elencati spediranno richieste al loro Laboratorio di riferimento.

Quest’ultimo, a seconda della destinazione, farà automaticamente una richiesta per l’esame COVID-19 al Centro di erogazione prescelto. Il Laboratorio Erogatore restituirà al Laboratorio Inviante il risultato validato dell’esame richiesto, ed il Laboratorio Inviante produrrà il referto, previa apposizione della firma digitale (anche per alimentare il relativo FSE dell’assistito).

Nella formulazione originale del Progetto, i reparti da creare su Galileo e DNLab erano i seguenti:

Azienda/Area	Descrizione	Provenienza verso destinazione	Centro di riferimento
AOU Sassari	COVID-19 INT22	Interni AOU Sassari verso AOUSS	Laboratorio di Virologia AOU SS
	COVID-19 EXT AOUSS	Esterni AOU Sassari verso AOUSS
	COVID-19-EXTA NU	Esterni AOUSS verso NU
	COVID-19-EXTA CA	Esterni AOUSS verso CA
	COVID-19-EXTA AOUCA	Esterni AOUSS verso AOUCA
ASSL Sassari	COVID-19 INT1	Interni Alghero verso AOU SS
	COVID-19 INT2	Interni Ozieri verso AOU SS
	COVID-19-EXT1 AOUSS	Esterni SS verso AOUSS
	COVID-19-EXT1 NU	esterni SS verso AOUSS
	COVID-19-EXT1 CA	esterni SS verso CA
	COVID-19-EXT1 AOUCA	esterni SS verso AOUCA
ASSL Olbia	COVID-19 INT3	Interni Olbia verso AOUSS
	COVID-19 INT4	Interni Tempio verso AOUSS
	COVID-19 INT5	Interni La Maddalena verso AOUSS
	COVID-19-EXT2 AOUSS	esterni OT verso AOUSS
	COVID-19-EXT2 NU	esterni OT verso NU
	COVID-19-EXT2 CA	esterni OT verso CA
	COVID-19-EXT2 AOUCA	esterni OT verso AOUCA
ASL Nuoro	COVID-19 INT6	Interni Nuoro verso NU	Laboratorio del P.O. San Xxxxxxxxx
	COVID-19 INT7	Interni Sorgono verso NU

Azienda/Area	Descrizione	Provenienza verso destinazione	Centro di riferimento
	COVID-19 EXT Nuoro	esterni NU verso NU
	COVID-19-EXT3 AOUSS	esterni NU verso AOUSS
	COVID-19-EXT3 CA	esterni NU verso CA
	COVID-19-EXT3 AOUCA	esterni NU verso AOUCA
ASL Lanusei	COVID-19 INT8	Interni Lanusei verso NU
	COVID-19-EXT4 AOUSS	esterni OG verso AOUSS
	COVID-19-EXT4 NU	esterni OG verso NU
	COVID-19-EXT4 CA	esterni OG verso CA
	COVID-19-EXT4 AOUCA	esterni OG verso AOUCA
ASL Oristano	COVID-19 INT9	Interni Oristano verso NU
	COVID-19 INT10	Interni Bosa verso NU
	COVID-19 INT11	Interni Ghilarza verso NU
	COVID-19-EXT5 AOUSS	esterni OR verso AOUSS
	COVID-19-EXT5 NU	esterni OR verso NU
	COVID-19-EXT5 CA	esterni OR verso CA
	COVID-19-EXT5 AOUCA	esterni OR verso AOUCA
ASL Sanluri	COVID-19 INT12	Interni Sanluri verso CA	Laboratorio del P.O. SS Trinità
	COVID-19-EXT6 AOUSS	esterni VS verso AOUSS
	COVID-19-EXT6 NU	esterni VS verso NU
	COVID-19-EXT6 CA	esterni VS verso CA
	COVID-19-EXT6 AOUCA	esterni VS verso AOUCA
ASL Carbonia	COVID-19 INT13	Interni Iglesias verso CA
	COVID-19 INT14	Interni Carbonia verso CA
	COVID-19-EXT7 AOUSS	esterni CI verso AOUSS
	COVID-19-EXT7 NU	esterni CI verso NU
	COVID-19-EXT7 CA	esterni CI verso CA
	COVID-19-EXT7 AOUCA	esterni CI verso AOUCA
ASL Cagliari	COVID-19 INT15	Interni SST verso CA
	COVID-19 INT16	Interni Marino verso CA
	COVID-19 INT17	Interni Binaghi verso CA
	COVID-19 INT18	Interni Isili verso CA
	COVID-19 INT19	Interni Muravera verso CA
	COVID-19 EXT Cagliari	Esterni Ca verso CA
	COVID-19-EXT8 AOUSS	esterni CA verso AOUSS
	COVID-19-EXT8 NU	esterni CA verso NU

Azienda/Area	Descrizione	Provenienza verso destinazione	Centro di riferimento
	COVID-19-EXT8 AOUCA	esterni CA verso AOUCA
AOU Cagliari	COVID-19 INT20	Interni AOUCA verso AOUCA	Laboratorio del P.O. Monserrato
	COVID-19 EXT AOUCA	esterni AOUCA verso AOUCA
	COVID-19-EXTC AOUSS	esterni AOUCA verso AOUSS
	COVID-19-EXTC NU	esterni AOUCA verso NU
	COVID-19-EXTC CA	esterni AOUCA verso CA
AOB	COVID-19 INT21	Interni Brotzu verso AOUCA
	COVID-19-EXTB AOUSS	esterni da AOB verso AOUSS
	COVID-19-EXTB NU	esterni da AOB verso NU
	COVID-19-EXTB CA	esterni da AOB verso CA
	COVID-19-EXTB AOUCA	esterni da AOB verso AOUCA

Figura 7 – Reparti COVID-19 – Formulazione Originale Progetto

Le varianti introdotte in corso d’opera nella Rete dei Laboratori COVID-19dall’Assessorato Igiene e Sanità induce la revisione delle tratte da realizzare per lo spostamento dei campioni.

Xxxx tratte tengono conto ;

✓ dalla territorialità, realizzando i percorsi verosimili per le aree geografiche del Nord (AOU Sassari, ATS-ASSL di Sassari, Olbia, Nuoro) e del Sud (AOU Cagliari, AOB, ATS-ASSL di Cagliari, Oristano, Sanluri e Carbonia);

✓ dello stato attuale, cioè delle tratte attualmente attive anche tra Laboratori aggiuntivi: in particolare attualmente Lanusei conferisce i tamponi a Nuoro.

Per quanto riguarda gli esami accettati dal personale ospedaliero o dei Centri Prelievo Territoriali, si lascerà la possibilità di utilizzare le strutture già in uso, in modo tale da non complicare il lavoro degli operatori stessi o del personale del Laboratorio di Analisi.

Come previsto nel progetto iniziale, per quanto riguarda i prelievi o i tamponi eseguiti da personale SPS o USCA, si ipotizza di utilizzare strutture create ad hoc per consentire il trasferimento degli esami verso i Laboratori Eroganti. La tabella che segue evidenzia i percorsi da realizzare in entrambe le direzioni, con i reparti da creare per le accettazioni.

Ad esempio, la prima riga significa che:

1. Il Laboratorio dell’AOU di Sassari, per spedire esami al Laboratorio dell’AOU di Cagliari, utilizzerà il reparto COVID-EXT-AOUCA;

2. Il Laboratorio dell’AOU di Cagliari, per spedire esami al Laboratorio dell’AOU di Sassari, utilizzerà il reparto COVID-EXT-AOUSS.

Prog	AS/ASSL richiedente/esecutore	Reparto richiedente Andata	AS/ASSL richiedente/esecutore	Reparto richiedente Ritorno
1	AOU Sassari	COVID-EXT-AOUCA	AOU Cagliari	COVID-EXT-AOUSS
2(*)	ASSL Sassari AHO	COVID-EXT-AHOAOUSS	AOU Sassari	COVID-EXT-ASSLSSAHO
3(*)	ASSL Sassari OZ	COVID-EXT-OZAOUSS	AOU Sassari	COVID-EXT-ASSLSSOZ
4	ASSL Olbia	COVID-EXT-AOUSS	AOU Sassari	COVID-EXT-ASSLOT

Prog	AS/ASSL richiedente/esecutore	Reparto richiedente Andata	AS/ASSL richiedente/esecutore	Reparto richiedente Ritorno
5	ASSL Nuoro	COVID-EXT-AOUSS	AOU Sassari	COVID-EXT-ASSLNU
6	ASSL Lanusei	COVID-EXT-AOUSS	AOU Sassari	COVID-EXT-ASSLOG
7	AOB	COVID-EXT-AOUCA	AOU Cagliari	COVID-EXT-AOB
8	ASSL Cagliari	COVID-EXT-AOUCA	AOU Cagliari	COVID-EXT-ASSLCA
9	ASSL Oristano	COVID-EXT-AOUCA	AOU Cagliari	COVID-EXT-ASSLOR
10	ASSL Sanluri	COVID-EXT-AOUCA	AOU Cagliari	COVID-EXT-ASSLVS
11	ASSL Carbonia	COVID-EXT-AOUCA	AOU Cagliari	COVID-EXT-ASSLCI

Figura 8 – Schema percorsi Richiedente - Esecutore

(*) In questo caso, insistendo al momento i due LLU sulla stessa piattaforma, l’integrazione è nativa, e non passerà per l’ESB Xxxxxxx; successivamente alla separazione dei LLU prevista in altri progetti, si ricorrerà alla modalità interoperabile qui descritta

L’implementazione delle tratte verrà realizzata attraverso i seguenti passi:

1. Creazione dei reparti su Xxxxxxx e DNLab così come sopra evidenziati;

2. Modifiche dei piani di numerazione delle richieste sugli LLU per evitare duplicati e la rietichettatura dei campioni;

3. Generazione messaggio OML^O21 da parte del Picasso richiedente;

4. Gestione del messaggio OML^O21 da parte del Picasso Centrale sulla base del reparto di provenienza, ed invio al Picasso locale corretto;

5. Generazione del messaggio di ritorno dei risultati validati dal laboratorio erogante ed invio al Picasso locale;

6. Trasferimento del messaggio al Picasso Centrale;

7. Inoltro al Laboratorio richiedente tramite Picasso Locale;

8. Pubblicazione dei risultati su Xxxxxxx, con intercettazione del messaggio HL7 ed inoltro a Picasso Centrale;

9. Inoltro del messaggio di pubblicazione risultati al gateway HL7 del DWH Centrale, per alimentazione del cruscotto direzionale.

La realizzazione dei canali di interconnessione tra i Laboratori verrà realizzata mediante l’allestimento di un sito-pilota, ed il successivo deploy sui restanti siti.

Per quanto riguarda la scelta del sito-pilota, si decide di considerare due tratte attualmente utilizzate, una nel Nord Sardegna ed una nel Sud:

▪ XXXX Xxxxxxx, la quale, disponendo di strumentazione a bassa produttività, conferisce i tamponi al Laboratorio dell’Ospedale San Xxxxxxxxx di Nuoro;

▪ ASSL di Olbia, la quale conferisce i tamponi all’AOU di Sassari.

In riferimento ai flussi regionali (Flusso DLC - File T), ed in particolare per quanto riguarda la possibilità di tracciare:

▪ la provenienza dei campioni (strutture sanitarie o assistenziali, domicilio o residenza del paziente, ecc.);

▪ la tipologia di paziente (ospite di struttura sanitaria o assistenziale, dipendente, ecc.);

il DNLab ed i prodotti della suite che sovraintendono ai processi di accettazione, non contemplano la raccolta di informazioni di questo tipo.

Per ovviare a questo inconveniente, nel Progetto sono stati inclusi i moduli aggiuntivi MCT e MAM (ved. successivo par. 8.2.1), che offrono invece la possibilità di raccogliere le informazioni sulla provenienza del campione e sulla tipologia di paziente. Tali informazioni saranno trasmesse al DNLAB da Xxxxxxx, e saranno memorizzate nel database di DNLAB in modo tale che possano essere recuperate in fase di estrazione dei dati per l’invio al SIDI (ved. Successivo par. 8.2.1.2).

8.3. Esecuzione dei Tamponi

In relazione all’organizzazione della struttura deputata all’esecuzione dei tamponi si potranno definire due possibili scenari:

− Scenario N. 1 🡪 La struttura, mediante apposite Postazioni di Xxxxxx, esegue le pre- accettazioni sui reparti logici, e stampa le etichette per i campioni;

− Scenario N. 2 🡪 Il laboratorio di analisi più vicino alla struttura esegue le pre-accettazioni sui reparti logici, e stampa le etichette per i campioni.

L’identificazione del paziente avviene mediante la rilevazione dei dati anagrafici, a seconda del caso contingente, prima dell’esecuzione del tampone, o contestualmente.

Di seguito vengono elencati i passi relativi ai due scenari descritti, con le due ipotesi:

Ipotesi N.1: Disponibilità preventiva dei dati anagrafici dei pazienti:

▪ La struttura che deve eseguire il tampone (SISP, USCA, infermieri della struttura RSA o altro, medici ed infermieri dell’Esercito, ecc.), identifica il paziente mediante raccolta dei dati anagrafici prima del tampone (almeno nome, cognome, data e luogo di nascita, sesso, e codice fiscale);

▪ Su Galileo o DNLab vengono effettuate le pre-accettazioni:

− Dagli operatori SISP, qualora dispongano di postazioni di accettazione (eventualmente dotata di stampante di etichette);

− Dagli operatori del laboratorio più vicino, qualora le informazioni anagrafiche gli vengano trasmesse a questo scopo;

▪ Gli operatori di pre-accettazione stampano le etichette barcode da apporre ai tamponi prelevati (o comunque ai contenitori);

▪ La struttura che deve eseguire il tampone, se necessario, va in laboratorio e ritira le etichette (o i contenitori etichettati);

▪ I tamponi vengono riportati presso il laboratorio che provvede a processarli o inoltrarli al laboratorio di riferimento (vedi in seguito, Movimentazione dei Campioni);

▪ Il tampone viene eventualmente spedito al laboratorio di riferimento individuato;

▪ Il Laboratorio effettua il checkin del campione e lo processa;

▪ Risultati e referti tornano automaticamente sul reparto Galileo COVID-19 EXTX YYY o COVID- 19-EXT XXX richiedente.

Ipotesi N.2: Indisponibilità preventiva dei dati anagrafici dei pazienti:

▪ Vengono eseguiti i tamponi, e contestualmente vengono collezionate le informazioni anagrafiche dei pazienti (almeno nome, cognome, data e luogo di nascita, sesso e codice fiscale);

▪ Xxxxxxx e dati anagrafici vengono consegnati agli operatori autorizzati (es. SISP);

▪ Gli operatori autorizzati attraverso Xxxxxxx, selezionano il reparto logico corretto (provenienza e destinazione del tampone), ed eseguono la pre-accettazione del tampone, con relativa etichettatura dei contenitori;

▪ Il tampone viene spedito al Centro di Riferimento individuato;

▪ Il Laboratorio effettua il checkin del campione e lo processa;

• Risultati e referti tornano automaticamente sul reparto Galileo COVID-19 EXTX YYY o COVID- 19-ext XXX richiedente.

Anche in caso di accettazioni eseguite direttamente su DNLab, il tampone verrà diretto verso uno dei Laboratori di Riferimento mediante scelta del reparto logico COVID-EXT. Su Galileo il paziente verrà transcodificato sulla base dei dati anagrafici provenienti da DNLab.

8.4. Tamponi e test rapidi in mobilità

E’ da subito risultata evidente la necessità di disporre di procedure e strumenti per l’esecuzione dei tamponi o esami (eseguiti con kit istantanei) in mobilità.

L’utilizzo di dispositivi mobili deve però garantire la corretta identificazione dei pazienti, la tracciabilità di tutti gli eventi e la disponibilità da parte del software di Laboratorio di Analisi di tutti i dati strutturati del processo, in modo tale da poterli rendere disponibili agli organismi di controllo.

Altra caratteristica preferibile delle procedure in mobilità è la possibilità di funzionamento “offline”, ossia in assenza di collegamento alla rete Aziendale o Internet.

I processi da prendere in esame per questo tipo di strumenti sono sostanzialmente due:

1. Esecuzione tamponi da spedire ai Laboratori di riferimento COVID-19;

2. Esecuzione di esami con kit per test rapidi.

8.4.1. Tamponi in mobilità

Per l’esecuzione di un tampone in mobilità che soddisfi i requisiti sopra evidenziati è necessaria una soluzione hardware/software in grado di:

▪ identificare il paziente collegandosi all’Anagrafe Ospedaliera;

▪ formulare una richiesta di esame al Laboratorio di afferenza;

▪ stampare un’etichetta da apporre al tampone;

▪ trasferire la richiesta al Laboratorio di afferenza.

La procedura potrà attivarsi ovunque le UCL abbiano disposto l’esecuzione di tamponi (Case di Cura, Residenze per anziani, ecc.).

Per quanto riguarda il funzionamento “offline”, si possono immaginare due diverse soluzioni:

SOLUZIONE 1:

• Pre-accettazione in Laboratorio (ciò comporta di conoscere a priori i dati anagrafici delle persone da sottoporre ai tamponi);

• Scarico della worklist sul dispositivo mobile;

• Identificazione del paziente (sulla base della worklist) e stampa dell’etichetta;

• Esecuzione del tampone.

SOLUZIONE 2:

• Georeferenziazione dei tamponi;

• Identificazione del paziente (con lettura della TS e l’aggiunta di ulteriori dati) e stampa dell’etichetta;

• Esecuzione del tampone.

• Non appena il dispositivo torna online, trasferimento al Laboratorio di riferimento della pre-accettazione.

E’ evidente che il percorso 2 rappresenta l’optimum, per diverse ragioni:

1. Non necessita di pre-accettazione;

2. Non necessita dello scarico della Worklist;

3. Georeferenzia il tampone eseguito.

8.4.1.1.Xxxxxxx in mobilità: soluzione INPECO

La società INPECO ha messo a disposizione dell’AOU di Sassari una procedura già sviluppata e collaudata, funzionante su dispositivi portatili, che implementa buona parte dei processi descritti:

▪ richiede una pre-accettazione sul Laboratorio di afferenza;

▪ identifica il paziente sulla base della worklist del Laboratorio;

▪ stampa l’etichetta in mobilità;

▪ può funzionare offline scaricando preventivamente la worklist. Questa soluzione sarà integrata con il LIS DNLAB presso l’AOU di Sassari.

8.4.1.2. Tamponi in mobilità: soluzione Service Life-DEDALUS

Service Life ha sviluppato una propria soluzione, denominata MAM (Mobile Acceptance Module) con le seguenti caratteristiche:

▪ non necessita di pre-accettazione, ma lavora in collaborazione con ESB Xxxxxxx che invia al Laboratorio le pre-accettazioni in HL7; in questo modo non vi è alcuna necessità di conoscere preventivamente i dati anagrafici dei paziente da sottoporre a tampone, con evidenti vantaggi relativi sia all’elasticità della soluzione (ad es., in fase di pre-accettazione si può dimenticare l’esatta composizione di un nominativo), sia alla gestione dei dati sensibili (GDPR);

▪ georeferenzia i tamponi; è importante conoscere la provenienza di esecuzione di ogni singolo tampone: attualmente tale dato viene annotato all’atto della pre-accettazione sul LIS, ma non è obbligatorio e potrebbe essere omesso;

▪ identifica il paziente, attraverso ESB Xxxxxxx, riconciliandolo con la vista XMPI EXT_ANAGRAFE, o il DB anagrafico del LIS;

▪ funziona su qualunque dispositivo Android, IOS e Windows o in ambiente Cloud su postazioni fisse appositamente allestite in punti di prelievo esterni (x.xx. drive-trought).

La procedura è inoltre in grado di lavorare offline, identificando il paziente con lettura della TS, e l’aggiunta di alcuni dati anagrafici di riferimento, e stampando etichette con numeri di richiesta preassegnati ed esclusivi per il dispositivo. In questo caso, non appena online, si potranno innescare le procedure di riconciliazione dei pazienti ed invio delle pre-accettazioni al LIS, sempre ad opera di ESB Xxxxxxx.

8.4.1.3.Nuove funzionalità sul modulo MAM

La Direzione Lavori ha organizzato una riunione per la presentazione del modulo MAM alla Direzione Sanitaria di ATS e ad una rappresentanza dei Direttori di Laboratorio dell’area Sud, nell’amnbito di un piano di presentazione del Progetto agli utenti.. Durante la presentazione sono state richieste due modifiche importanti al modulo MAM:

1) In fase di identificazione del paziente, il modulo, ove sia possibile (presenza di connettività internet), dopo aver letto la TS, farà accesso ad un Web Service del sistema AnagS per

completare l’Anagrafica in modo automatico (recuperando Nome, Cognome, residenza e domicilio);

2) L’operatore, in fase di autenticazione, dovrà poter scegliere da una lista il Laboratorio al quale dovrà inviare i campioni per quella sessione.

Le richieste sono state prese in carico dal RUP, il quale, una volta ottenute le stime per lo sviluppo, ne ha autorizzato la realizzazione.

8.4.2. Test rapidi in mobilità

Su specifica richiesta dell’AOU di Sassari, Service Life ha inoltre sviluppato un modulo software denominato MCT (Mobile Clinical Test) che consente la gestione dei test rapidi secondo il seguente processo:

▪ scarico della worklist da LIS su dispositivo mobile (smartphone o tablet), a seguito di richieste precaricate con l’OE Galileo;

▪ autenticazione dell’esecutore (con le stesse credenziali di Xxxxxxx);

▪ effettuazione degli esami, ed immissione immediata, a bordo letto, del risultato;

▪ ritorno presso la sala medici o infermieri, e scarico degli esami effettuati, che saranno trasferiti al Laboratorio, che non emetterà alcun referto.

In questo modo, anche questi dati verranno convogliati sul Datawarehouse regionale, e saranno quindi disponibili per il monitoraggio tramite cruscotto.

9. Rappresentazione dei dati

Per quanto riguarda la rappresentazione dei dati è previsto lo sviluppo di un apposito cruscotto regionale. Tale cruscotto raggrupperà i dati degli esami richiesti dalle Aziende o Xxxx insistenti nel territorio di pertinenza dell’unità stessa.

Saranno rappresentati i dati dei pazienti, la loro provenienza, il Laboratorio richiedente, il Centro di riferimento erogante, la positività o negatività, ed i campioni in lavorazione.

10. Integrazione col Sistema di Gestione dei casi: Realizzazione applicativo per alimentazione SIDI

Nell’ambito del progetto, vista l’emergenza sanitaria è stata realizzata in urgenza l’alimentazione del Sistema Regionale di Gestione dei Casi con un flusso (denominato “Flusso DCL – File T”), contenente tutti i dati disponibili sugli esami sierologici e sui tamponi effettuati in ambito SILUS per le Aziende Sanitarie SSR (con l’eccezione dell’Istituto Zooprofilattico che non possiede l’ambiente SILUS).

Inizialmente il flusso veniva generato da una semplice query sul database del LIS DNLAB. Successivamente, una volta formalizzato il Disciplinare del Flusso DCL - File T cre prevede il formato ASCII come obbligatorio, si è proceduto nello sviluppo di un modulo software dedicato, denominato COVID-FLOW.

11. Integrazione del Laboratorio dell’Istituto Zooprofilattico Sperimentale

Il Laboratorio dell’IZS di Sassari è stato arruolato come Laboratorio di riferimento COVID-19.

Esso, al contrario di tutti gli altri, non dispone del software SILUS, ma dispone di un proprio sistema denominato SIGLA, adottato anche da altri IZS a livello nazionale.

Per far sì che tutti i dati relativi alle lavorazioni presso l’IZS possano rientrare nella disponibilità delle UCL, è necessario allestire una soluzione per recepire in SILUS i risultati dei campioni eseguiti dall’IZS.

Esistono due ipotesi:

▪ la prima è che l’IZS disponga di un gateway HL7 tramite il quale possa inviare i risultati;

▪ la seconda è che l’IZS metta a disposizione una vista sul proprio DB contenente il risultato dell’esame e l’identificativo della richiesta: in tal modo sarà possibile che l’ESB Xxxxxxx legga la tabella e componga i messaggi HL7 per il trasferimento al LIS del risultato degli esami.

In un contesto non prioritario (IZS Sassari produce regolarmente in autonomia il File T) si valuterà l’effettiva necessità di completare l’integrazione anche con il sistema SIGLA dell’IZS di Sassari.

12. Realizzazione piattaforma per l’indagine ISP

Il Ministero della Salute, in collaborazione con Croce Rossa Italiana (CRI), ha intrapreso nel mese di luglio 2020 un’indagine epidemiologica in tutta la nazione, volta ad una migliore comprensione dell’effettiva incidenza dei contagi sulla popolazione sulla base di prelievi sierologici effettuati ad un campione rappresentativo della popolazione nazionale.

L’indagine è nota come Xxxxxxxx Xxxxx Xxxxxxxxxx (ISP), e viene condotta su un campione di popolazione selezionato dall’ISTAT. I cittadini vengono contattati dalla CRI, che chiede l’adesione al progetto, e, in caso il soggetto dia il proprio consenso, provvede al prelievo di un campione di sangue da mandare presso alcuni Laboratori selezionati, che per la Sardegna sono:

▪ S.C. Microbiologia e Virologia Laboratorio Virologia -Speciale Centro Influenza - AOU di Sassari;

▪ Laboratorio Generale (HUB) di analisi chimico cliniche e microbiologia - P.O. Xxxxxx Xxxxxx

- AOU di Cagliari;

▪ Laboratorio di Analisi dell’Xxxxxxxx Xxxxxxxx Xxxxx XX xx Xxxxx-XXX Xxxxxxxx-XXXX Xxxxx.

A seguito dell’esecuzione degli esami, il programma prevede:

1. La generazione di un referto, a cura delle AS erogatrici;

2. La consegna o l’inoltro del referto al paziente;

3. Il caricamento dei risultati degli esami su una piattaforma messa a disposizione dal Ministero della Salute (NSIS);

4. L’aliquotazione dei campioni sierologici, con successiva spedizione all’Istituto “Spallanzani” di Roma per successive indagini.

I numeri identificativi delle provette gestite dal progetto ISP e dalla piattaforma del Ministero della Salute sono risultate incompatibili con il LIS regionale.

Per questa ragione, per poter gestire l’intero processo diagnostico in modo corretto e tracciato, si è deciso di eseguire le accettazioni sul LIS rietichettando i campioni, e tenendo traccia dei codici ISP per poter alimentare correttamente la piattaforma ministeriale con i risultati degli esami.

La Regione Sardegna, dopo diverse valutazioni, ha optato – su indicazione dell’ATS Sardegna - per la gestione dell’indagine mediante la piattaforma Screening Arianna, attivata per gli screening oncologici nell’ambito dei Piani Regionali di Prevenzione.

Quest’ultima, già integrata con il software gestionale di Laboratorio, garantisce infatti la possibilità di registrazione di tutti gli eventi, fino alla spedizione del risultato con lettera (tramite POSTEL), così come avviene normalmente per gli Screening.

L’esperienza già maturata presso L’ASSL di Olbia presso la quale si era realizzata un’integrazione tra Screening e Laboratorio per la gestione degli esami per la ricerca del sangue occulto, ha reso

possibile la realizzazione delle integrazioni in tempi rapidi e con certezza del risultato, evidenziando quindi una eccellente flessibilità dell’applicazione è un ottima condizione di riuso dello stesso anche in altri contesti applicativi.

I casi positivi vengono presi in carico dalle strutture apposite dei SISP, già operanti sul territorio regionale. I referti vengono consegnati tramite FSE con il meccanismo di integrazione già operante.

13. Piano delle attività

Il progetto prevede le seguenti azioni:

▪ Realizzazione della rete di interoperabilità per esami COVID-19 (in fase di test);

▪ Rilascio moduli aggiuntivi per tamponi ed esami rapidi (in fase di test);

▪ Realizzazione Cruscotto COVID-19 (in esercizio presso AOU Sassari e in rilascio alle altre AS);

▪ Realizzazione DWH Centrale (in corso di completamento);

▪ Integrazione con Sistema Regionale di Gestione dei Casi mediante realizzazione applicativo per alimentazione SIDI (completata ed in esercizio);

▪ Realizzazione piattaforma per gestione Indagine Ministeriale di Siero-Prevalenza (ISP) (variante progettuale in corso d’opera, (completata ed in esercizio);

▪ Integrazione del Laboratorio dell’Istituto Zooprofilattico Sperimentale (da avviare);

▪ Rilascio nuove funzionalità sul modulo MAM (in corso di completamento).

Le azioni evidenziate hanno le seguenti dipendenze:

▪ Realizzazione della rete di interoperabilità per esami COVID-19: disponibilità della rete federata, compreso l’ESB Centrale, con connettività bidirezionale;

▪ Rilascio moduli aggiuntivi per tamponi ed esami rapidi: nessuna

▪ Realizzazione Cruscotto COVID-19: nessuna

▪ Realizzazione DWH Centrale: disponibilità dei server per Il DWH Centrale (Oracle DB) e per il relativo gateway HL7 (le specifiche sono state comunicate per le vie brevi).

▪ Integrazione con sistema regionale di gestione dei casi mediante realizzazione applicativo per alimentazione SIDI: nessuna

▪ Realizzazione piattaforma per gestione Indagine Ministeriale di Siero-Prevalenza (ISP): nessuna

▪ Integrazione del Laboratorio dell’Istituto Zooprofilattico Sperimentale: nessuna

▪ Rilascio nuove funzionalità sul modulo MAM: rilascio versione base del modulo MAM.

13.1. Realizzazione della rete di interoperabilità per esami COVID-19

La rete di interoperabilità verrà realizzata, come descritto in precedenza, mediante utilizzo della rete degli ESB Xxxxxxx.

Il Progetto interseca e traguarda parti di progetti preesistenti:

▪ Installazione della componente centrale del sistema federato ESB;

▪ Realizzazione BUS di integrazione tra LLU.

Seguirà la configurazione dei LIS (nuovi reparti e nuovo piano di numerazione delle richieste), dei Picasso ESB (attivazione dei canali di integrazione), dei Galileo (allineamento dei reparti con i LIS).

Come descritto, le tratte pilota sono state individuate in:

▪ Nuoro - Lanusei

▪ Olbia – AOU Sassari

Le tratte verranno validate mediante uso di una Checklist di test concordata con il DEC.

A valle del completamento della Checklist senza errori, si potrà procedere al deploy su tutte le tratte previste nel progetto.

13.2. Rilascio moduli aggiuntivi per tamponi ed esami rapidi

Verranno rilasciati i moduli:

▪ MCT (Mobile Clinical Test);

▪ MAM (Mobile Acceptance Module).

Ciascuna Azienda partecipante al progetto esprimerà la propria volontà se aderire o meno alla proposta prevista nel progetto approvato. I moduli sono infatti opzionali.

I moduli verranno sottoposti a test di buon funzionamento prima della consegna in produzione, secondo checklist concordate.

Per quanto riguarda l’installazione:

▪ il modulo MCT, strettamente legato all’ambiente SILUS, dovrà essere installato nella rete dell’Azienda fruitrice;

▪ il modulo MAM potrà essere rilasciato in ambiente Cloud, in un’unica installazione. La macchina sulla quale i moduli saranno installati dovrà comunicare con tutti gli ESB locali delle Aziende fruitrici.

Di seguito il macro schema che identifica le linee generali dell’architettura e della sicurezza:

Figura 9 – Schema generale – Architettura e sicurezza

Per poter utilizzare MAM, i client dovranno utilizzare un comune browser e accedere a un indirizzo fornito dal cliente o dall’infrastruttura nel quale sarà installato l’applicativo. Il layer di comunicazione tra client e webserver sarà HTTPS, il quale è un protocollo per la comunicazione sicura. La porta utilizzata è la 443.

L’autenticazione dei client è stata implementata tramite CDP (Captcha Design Pattern), più nello specifico reCaptcha v3 fornita da Google. L’autenticazione con l’utilizzo di reCaptcha consente che tutte le chiamate API verso il back-end siano realmente effettuate da una persona reale che utilizza l’applicativo e non da un bot.

Quanto all’applicativo MAM, l’application server che lo ospita può essere installato presso una webfarm convenzionata con le strutture ospedaliere; l’unica porta che viene esposta su internet è la 443 ovvero la porta di comunicazione per consentire l’accesso ai client tramite il protocollo HTTPS.

Il MAM si basa su due componenti principali, il back-end ed il front-end.

Il back-end include tutte le logiche di business necessarie alla gestione del sistema, è realizzato in Node.js, un framework per applicazioni in JavaScript. La piattaforma è basata sul JavaScript Engine V8, il runtime di Google utilizzato anche da Chrome.

L’Application Server non è esposto direttamente su internet, le richieste REST provenienti dal web vengo instradate tramite un reverse proxy (Apache o Nginx) presente sull’indirizzo a cui risponde l’applicativo, solitamente viene utilizzato il pattern “https://{xxxxxxxxxxxx.xxx}/api/*”. Le chiamate REST attualmente supportate sono: POST, PUT, DELETE e GET.

Il back-end oltre a fornire un servizio REST per il client, interagisce con un database installato all’interno del Application server e con il sistema Picasso Centrale tramite chiamate SOAP.

Il front-end è l’interfaccia grafica che gli utenti utilizzeranno per l’interazione con il sistema. È realizzato tramite il framework Angular che consente la fruizione della stessa tramite: smartphone, tablet e web browser desktop. Il front-end risponde ai client tramite un web server (Apache o Nginx), tutto il traffico è instradato tramite il protocollo HTTS descritto in precedenza.

Per quanto riguarda infine le configurazioni dell’ESB, Xxxxxxx centrale è già installato presso la struttura Ospedaliera ASSL-SS, espone al back-end un endpoint di tipo SOAP per l’invio dei risultati o referti da parte dell’applicativo MAM. Il protocollo di comunicazione tra i due è di tipo SOAP-HTTP.

Le rispettive infrastrutture che ospiteranno il back-end di MAM e Xxxxxxx Centrale dovranno poter comunicare tra di loro tramite, ad esempio, connessioni VPN.

Inoltre, tra le due strutture sarà possibile implementare tutte le opportune regole di sicurezza per preservare il sistema Picasso Centrale.

Trattandosi di moduli opzionali, il DEC/RUP dovrà comunicare a Service Life le Aziende Sanitarie che intendono fruirne. Installazione e configurazione dei moduli non fanno parte del presente progetto.

13.2.1. Opzione moduli aggiuntivi per tamponi ed esami rapidi

Alla data di emissione del presente Progetto Esecutivo, la situazione riguardo l’espressione della volontà di acquisire i moduli MAM e MCT è la seguente:

Azienda	Volontà espressa
ATS Sardegna	SI
AOU Sassari	NO
AOU Cagliari	SI/NO (ha richiesto alcune modifiche)
AO Brotzu	NO

13.3. Realizzazione Cruscotto COVID-19

E’ stato già realizzato un prototipo del Cruscotto Direzionale COVID-19 previsto nel progetto. Esso, aggregando i dati degli esami presenti sul DWH Centrale, sia in grado di evidenziare l’andamento dell’epidemia e le performance dei Laboratori coinvolti.

Lo sviluppo è stato condotto sulla piattaforma QlikView di ATS Sardegna, e sul Database DNLab di AOU Sassari - ASSL Sassari.

Per questa ragione, su questi ambienti è stata consegnato il cruscotto in versione Beta. Si prevede che la versione possa essere consolidata entro 30 giorni dalla consegna, avvenuta con PEC in data 20/07/2020.

Il cruscotto, rilasciato alla Stazione Appaltante completo di codice sorgente, e di proprietà del SSR, potrà essere distribuito a qualunque Azienda partecipante al progetto, che potrà utilizzarlo collegandolo al proprio database DNLab, per disporre dei dati aggregati della propria struttura.

Per quanto riguarda gli esami in stato di esecuzione (o non ancora refertati), il sistema, che intercetta messaggi HL7, non sarà in grado di alimentare il DWH con tutti i messaggi di accettazione, in quanto parte di essi proverrà da applicativi (DNWeb, DNTerritorio) nativamente integrati con DNLab.

Per questa ragione, la rappresentazione presente nel Cruscotto Direzionale COVID-19 regionale sarà limitata al numero di esami in corso per ciascun LLU, omettendo il dettaglio di ogni singolo esame (dati anagrafici, data della richiesta, numero, ecc.).

Tale dettaglio potrà essere invece disponibile qualora la Stazione Appaltante decidesse di distribuire il cruscotto ai singoli LLU. Questi ultimi potranno essere interrogati includendo tutte le informazioni di dettaglio sugli esami in corso.

E’ previsto il rilascio di un Manuale Utente.

13.4. Realizzazione del DWH Centrale

In fase di analisi, si è valutata positivamente l’idea di realizzare il Data Warehouse centrale mediante l’utilizzo di un Database DNLab, al fine di sfruttarne la struttura e le funzionalità di alimentazione (in particolare il Gateway HL7).

Una volta allestito l’ambiente su Oracle Cloud (è la scelta definita), sarà necessario:

▪ configurare, con un client di servizio, gli esami COVID gestiti nella Regione;

▪ configurare Picasso Centrale per la gestione delle Transcodifiche;

▪ attivare delle viste sugli esami eseguiti su ciascun impianto. Per quanto riguarda l’alimentazione del DWH Centrale, si prevede:

▪ una procedura batch per il recupero dello storico: su ciascun impianto verrà creata una vista con tutti gli esami COVID-19 eseguiti dal 1 gennaio 2020. Tale lista verrà presa in carico dal Xxxxxxx Locale e processata in batch, al fine di recuperare tutti i dati e alimentare il DWH;

▪ un sistema automatico di alimentazione, in cui il Picasso locale intercetta i messaggi HL7 di trasferimento dei risultati a Xxxxxxx, e li duplica verso il Picasso Centrale per permettere l’aggiornamento continuo del DWH. A tale proposito, è bene portare all’attenzione della Stazione Appaltante che:

− per quanto riguarda ATS, il porting dell’integrazione DNLab-Galileo su Xxxxxxx è previsto nel progetto ESB dell’ATS, in quanto funzionale al presente progetto;

− per quanto riguarda AOU Sassari, l’integrazione dovrà essere migrata su Xxxxxxx;

− per quanto riguarda AOU Cagliari, l’integrazione dovrà essere migrata su Xxxxxxx;

− per quanto riguarda AO Brotzu, l’integrazione dovrà essere migrata su Xxxxxxx.

Le migrazioni non incluse in alcun progetto parallelo, dovranno essere proposte alle Aziende che ne necessitano come attività di manutenzione straordinaria.

▪ una query da eseguire su ciascun Database (a cura di Xxxxxxx), temporizzata per 1-2 volte al giorno, per aggiornare i sistemi sul numero di esami in esecuzione (vedi par. precedente).

13.5. Integrazione col Sistema di Gestione dei casi: realizzazione applicativo per alimentazione SIDI

Nell’ambito del progetto, vista l’emergenza sanitaria in atto, è stato anticipato il rilascio dell’applicativo denominato COVID-FLOW, secondo le seguenti specifiche.

L’applicativo COVID-FLOW è stato realizzato utilizzando le nuove tecnologie quali Angular e NodeJS, che consentono all’utilizzatore finale la fruizione di quest’ultimo tramite le nuove tecnologie di uso quotidiano come PC, smartphone e tablet.

L’applicativo è accessibile attraverso i browser più diffusi sul mercato. L’RDBMS di riferimento per le tabelle interne è MYSQL.

L’applicativo è stato rilasciato in data 5 giugno 2020, e risulta in produzione in tutte le strutture. Per ulteriori informazioni si rimanda al manuale d’uso.

13.6. Realizzazione piattaforma per Indagine Ministeriale ISP

La piattaforma è stata rilasciata tra il 3 giugno (ASSL Olbia - Pilota), il 10 giugno (AOU Sassari), ed il 12 giugno 2020 (AOU Cagliari). Ad oggi la piattaforma risulta in piena operatività, senza alcuna segnalazione di criticità.

13.7. Integrazione dell’Istituto Zooprofilattico Sperimentale della Sardegna

Per quanto riguarda l’integrazione dell’IZS, sarà necessario un assessment dei processi attualmente in essere, al fine di individuare una soluzione al problema tra quelle ipotizzate al precedente par. 12.

L’IZS già eroga il flusso T verso la Regione (passando per AOU Sassari), quindi il COVID-FLOW non sarà oggetto di rilascio verso stesso Istituto.

13.8. Nuove funzionalità sul modulo MAM

Le migliorie richieste da AOU Cagliari sono le seguenti:

1. In fase di identificazione del paziente, il modulo, ove sia possibile (presenza di connettività internet), dopo aver letto la TS, farà accesso ad un Web Service del sistema AnagS per completare l’Anagrafica in modo automatico (recuperando Nome, Cognome, residenza e domicilio);

2. L’operatore, in fase di autenticazione, dovrà poter scegliere da una lista il Laboratorio al quale dovrà inviare i campioni per quella sessione.

Esse verranno soddisfatte nella prossima release del prodotto.

13.9. Modello organizzativo e funzionale

La struttura organizzativa coinvolta, si prefigge di assicurare:

▪ L’ottimale presidio nella progettazione, fornitura, installazione e collaudo dei sistemi proposti, in linea con i requisiti espressi;

▪ La gestione ottimale dei servizi di assistenza all’avviamento e l’espletamento del servizio e manutenzione dell’intero sistema;

I principali elementi distintivi della soluzione organizzativa adottata, sono:

▪ Composizione di un Gruppo di Progetto che, riferendo al Project Manager, sarà dedicato alla realizzazione del progetto. Ulteriori risorse esterne al Gruppo, potranno essere coinvolte se in grado di apportare valore aggiunto alla conduzione delle attività ed al miglioramento continuo delle stesse. Tali figure potranno essere, ad esempio, i responsabili della Gestione della Qualità e della Gestione della Sicurezza.

▪ Presenza di un Project Manager esperto nella gestione di progetti di elevata complessità e con specifica esperienza nel campo dei sistemi ICT Sanità che fungerà da interfaccia unica

per l’Amministrazione. Egli monitorerà anche il corretto avanzamento lavori ed avrà la responsabilità del Gruppo di Progetto Service life.

▪ Organizzazione agile e di tipo “process driven”: la struttura organizzativa è stata definita per operare e reagire rapidamente, dalla fase di progettazione alla fase di assistenza all’avviamento fino a quella di gestione a regime del sistema, grazie a:

− Un numero limitato di livelli di riporto gerarchico;

− L’assegnazione di responsabilità chiare alle differenti unità;

− La presenza di figure di “interfaccia” immediatamente identificabili dall’Ente appaltante;

− L’orientamento prevalente ai processi/attività che costituiscono l’oggetto della fornitura.

▪ Disponibilità di risorse qualificate ed in possesso di skill tecnico-specialistici diversificati, necessari all’espletamento delle numerose attività richieste per condurre con successo il progetto.

13.10. Figure coinvolte

La messa in opera del sistema proposto, presenta molteplici aspetti sia di carattere tecnico che organizzativo che devono essere tenuti in considerazione. La struttura organizzativa capace di gestirli, deve necessariamente comprendere le seguenti figure/funzioni:

▪ Project Manager. Gestisce le attività in tutti gli aspetti: la definizione del progetto esecutivo, il coordinamento delle attività di installazione, collaudo ed avviamento. Il monitoraggio dei livelli di servizio e delle performance del sistema, la definizione di azioni correttive, ed in generale di tutte le attività successive al collaudo. Il Project Manager agirà in stretta relazione con il gruppo di progetto di ATS Sardegna, con il quale concorderà l’agenda degli sia per l’implementazione ed avvio dei sistemi offerti, che per la successiva attività di monitoraggio dell’andamento del progetto e dei collaudi.

▪ Application Specialists: sono i responsabili della formazione sul sistema e della sua configurazione lato utente. Sono formatori certificati, con preparazione differenziata in ambito applicativo, sulle varie metodiche.

Le figure individuate per le attività descritte sono le seguenti: Project Manager:

▪ Xxxxxx Xxxxx

Application Specialist:

▪ Xxxxxx Xx XXX

▪ Igor Campus Picasso ESB

▪ Xxxxxxxx Xxxxx XXX

▪ Xxxxx Xxxxxx Xxxx XXX

▪ Xxxxxxx Xxxxxxx XXX, Xxxxxxx

▪ Xxxxx Xxxxxx Xxxxxxx ESB, QlikView

▪ Xxxxxx Xxxxxxxx XXX

▪ Xxxxxx Xxxxxx Xxxxxxx

14. Criticità

Le criticità del progetto sono rintracciabili su diversi fronti, tutti riconducibili al fattore tempo:

▪ Immediatezza dell’azione: il progetto dovrà essere concluso all’inizio dell’autunno, in quanto alcuni virologi ed epidemiologi prevedono per questo periodo un ulteriore impennata dei contagi;

▪ Configurazioni delle reti geografiche: per l’attuazione del progetto, è necessario accelerare in modo significativo le configurazioni delle reti che abilitano le connessioni necessarie per l’attivazione dei canali d’integrazione. In alcuni casi le configurazioni sono particolarmente complesse, in quanto necessitano dell’interazione di più soggetti (gestori delle reti dell’ATS, delle Aziende Ospedaliere, Gestori esterni). Per queste ragioni sarà necessario muoversi per priorità, in modo tale da garantire le interconnessioni necessarie man mano che il progetto si dispiega sul territorio regionale.

▪ Disponibilità dell’infrastruttura per il DWH centrale: per garantire la disponibilità dell’hardware sul quale dovrà essere attivato il DWH centrale, il RUP della Stazione Appaltante ha attivato un’opzione a disposizione di tutte le Aziende Sanitarie della Sardegna relativa al contratto ULA (Unlimited License Agreement) con Oracle, ottenendo le risorse sul Cloud Oracle. Il sistema è attualmente in fase di completamento.

▪ Disponibilità del canale di integrazione Galileo-DNLab: come evidenziato in precedenza, i trasferimenti delle informazioni cliniche sul DWH Centrale, avverranno mediante intercettazione dei messaggi di pubblicazione dei risultati da DNLab a Galileo. La situazione, già riportata nel precedente par. 14.2, è la seguente:

− per quanto riguarda ATS, il porting dell’integrazione DNLab-Galileo su Xxxxxxx è previsto nel progetto ESB dell’ATS, in quanto funzionale al presente progetto;

− per quanto riguarda AOU Sassari, l’integrazione dovrà essere migrata su Xxxxxxx;

− per quanto riguarda AOU Cagliari, l’integrazione dovrà essere migrata su Xxxxxxx;

− per quanto riguarda AO Brotzu, l’integrazione dovrà essere migrata su Xxxxxxx.