PROGETTO DEI FABBISOGNI - ATS Sardegna Azienda Tutela della Salute - Dipartimento ICT
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
ATS
Data: 30/03/2020 10:57:36 PG/2020/0081006
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Sistema Pubblico di Connettività LOTTO 3
Indra Italia S.p.A/Pwc Public Sector S.r.l
Progetto dei Fabbisogni SPCL3-ATS_XDS-ProgettoFabbisogni-1.1
ATS Sardegna
Azienda Tutela della Salute – Dipartimento ICT
PROGETTO DEI FABBISOGNI
Implementazione CDR-XDS per il SICP
Versione 1.1 R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Pagina
Indra Italia S.p.A/Pwc Public Sector S.r.l.
Data di emissione 27/03/2020 1 di 21
Uso pubblico
ATS
Data: 30/03/2020 10:57:36 PG/2020/0081006
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Sistema Pubblico di Connettività LOTTO 3
Indra Italia S.p.A/Pwc Public Sector S.r.l
Progetto dei Fabbisogni SPCL3-ATS_XDS-ProgettoFabbisogni-1.1
SOMMARIO.
1 INTRODUZIONE .............................................................................................................................. 3
1.1 Premessa .......................................................................................................................................3
1.2 Scopo.............................................................................................................................................4
1.3 Campo di applicazione ..................................................................................................................5
1.4 Assunzioni .....................................................................................................................................5
1.5 Riferimenti ....................................................................................................................................5
1.6 Acronimi e glossario ......................................................................................................................5
2 ORGANIZZAZIONE DEL CONTRATTO ESECUTIVO .............................................................................. 6
3 PROGETTO DI ATTUAZIONE ............................................................................................................ 8
3.1 Prima esigenza: Realizzare una struttura di Registry XDS per ATS Sardegna ..............................8
3.1.1 Database .................................................................................................................................... 11
3.1.2 IHE Patient Identifier Cross-referencing (PIX)............................................................................ 11
3.1.3 XDS Registry: modello dei dati ................................................................................................... 12
3.1.4 Cenni su ebXML ......................................................................................................................... 13
3.1.5 Persistenza dei metadati NoSql ................................................................................................. 14
3.2 Seconda esigenza: Indicizzazione documenti ............................................................................ 14
3.3 Terza esigenza: Sperimentazione .............................................................................................. 15
3.4 Quadro riassuntivo dei servizi.................................................................................................... 15
3.5 Impegno delle risorse professionali ........................................................................................... 16
3.6 Indirizzo di dispiegamento dei servizi ........................................................................................ 16
3.7 Modalità di esecuzione del collaudo dei servizi ........................................................................ 17
4 MODALITÀ DI PRESENTAZIONE E APPROVAZIONE DEGLI STATI DI AVANZAMENTO MENSILI ........... 18
4.1 Gestione dei SAL Mensili............................................................................................................ 18
4.2 Report di Stato di Avanzamento Mensile .................................................................................. 18
5 PIANO DI ATTUAZIONE ................................................................................................................. 20
5.1 Piano di Lavoro .......................................................................................................................... 20
5.2 Gestione della Sicurezza ............................................................................................................ 20
5.3 Piano di Qualità .......................................................................................................................... 20
6 DATA DI ATTIVAZIONE.................................................................................................................. 21
Versione 1.1 R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Pagina
Indra Italia S.p.A/Pwc Public Sector S.r.l.
Data di emissione 27/03/2020 2 di 21
Uso pubblicoATS
Data: 30/03/2020 10:57:36 PG/2020/0081006
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Sistema Pubblico di Connettività LOTTO 3
Indra Italia S.p.A/Pwc Public Sector S.r.l
Progetto dei Fabbisogni SPCL3-ATS_XDS-ProgettoFabbisogni-1.1
1 INTRODUZIONE
1.1 PREMESSA
La Legge Regionale 27 luglio 2016, n. 17 ha modificato l'assetto istituzionale del Servizio sanitario regionale della
Sardegna, istituendo l'Azienda per la Tutela della Salute.
L'ATS nasce dalla fusione per incorporazione delle sette ASL nell'azienda incorporante di Sassari.
Ci sono una Azienda e otto aree socio-sanitarie, corrispondenti ai territori delle vecchie ASL. Ci sarà anche l’Area
Metropolitana di Cagliari, contestualmente all'attuazione della riforma degli Enti Locali. Con ATS e ASSL, avremo
i Distretti, che verranno definiti per numero e ambiti territoriali.
L'ATS, sulla base degli atti di indirizzo deliberati dalla Giunta regionale e delle direttive dell'Assessorato
competente in materia di sanità, svolge le funzioni di:
n programmazione aziendale e gestione complessiva dell'erogazione dei servizi sanitari e socio-sanitari;
n omogeneizzazione e armonizzazione dei processi gestionali nel territorio regionale in coordinamento
con l'attività delle altre aziende sanitarie;
n accentramento, per quanto di competenza di tutte le aziende sanitarie della Sardegna, dei processi di
aggregazione della domanda di beni e servizi e di approvvigionamento degli stessi;
n gestione accentrata, secondo gli indirizzi della Giunta regionale e nel rispetto delle disposizioni di cui
all'articolo 18, comma 1, della legge regionale n. 10 del 2006 per quanto attiene le aziende
ospedaliero-universitarie, per tutte le aziende sanitarie della Sardegna, delle procedure concorsuali e
selettive, del trattamento economico del personale, dei magazzini e della relativa logistica, delle reti
informatiche e delle tecnologie dell'informazione e della comunicazione, delle tecnologie sanitarie e
della valutazione dell'impatto delle stesse;
n gestione accentrata, secondo gli indirizzi della Giunta regionale, per tutte le aziende sanitarie della
Sardegna, delle procedure di gara per la progettazione, realizzazione, manutenzione, alienazione,
concessione e locazione degli immobili costituenti patrimonio delle stesse;
n definizione degli accordi con le strutture pubbliche ed equiparate e stipula dei contratti con quelle
private e con i professionisti accreditati, ai sensi dell'articolo 8 della legge regionale n. 10 del 2006, in
coerenza con la programmazione territoriale di cui all'articolo 4, comma 5, lettera a);
n accentramento delle procedure di organizzazione dei percorsi di formazione ECM.
La Ats è impegnata in un profondo processo di riorganizzazione, razionalizzazione e centralizzazione: sono
infatti in corso dei percorsi di riorganizzazione complessiva della Sanità regionale, di riorganizzazione e
razionalizzazione dei presidi ospedalieri, di revisione dei processi di presa in carico dei pazienti, centralizzazione
dei processi amministrativi e di acquisti e di quelli clinico-sanitari. Il tutto per raggiungere un importate
Versione 1.1 R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Pagina
Indra Italia S.p.A/Pwc Public Sector S.r.l.
Data di emissione 27/03/2020 3 di 21
Uso pubblicoATS
Data: 30/03/2020 10:57:36 PG/2020/0081006
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Sistema Pubblico di Connettività LOTTO 3
Indra Italia S.p.A/Pwc Public Sector S.r.l
Progetto dei Fabbisogni SPCL3-ATS_XDS-ProgettoFabbisogni-1.1
obiettivo: rimettere il Paziente al centro dei processi assistenziali, di cura e prevenzione, con la certezza della
sostenibilità finanziaria del sistema.
In questa quadro ATS Sardegna intende valorizzare l’insieme dei Sistemi di Interoperabilità realizzati (e in fase
di realizzazione) nel dominio della sanità regionale e quindi sul territorio della Regione Autonoma della
Sardegna, intervenendo sull’orchestrazione e sulla cooperazione applicativa nell’ambito delle Cure Primarie e
nella revisione e riorganizzazione del modello ospedale centrico, a favore dei servizi territoriali.
Il progetto si propone di realizzare un sistema di interoperabilità documentale – basato sul ESB della ATS
Sardegna – con l’obiettivo di rendere disponibili ed indicizzati i documenti clinici che alimenteranno il CDR
(Clinical Data Repository).
Più in dettaglio il presente progetto si pone l’obiettivo di attuare e realizzare un sistema che renda disponibili
tutti i documenti clinici accessibili dei Pazienti al sistema Cure Primarie, ossia la struttura di XDS Registry per
ATS Sardegna che gestisce le funzionalità di indicizzazione dei documenti clinici e ricerca degli stessi;
l’orchestratore del Sistema Cure Primarie interrogherà il XDS Registry di ATS affinché possa disporre dei
documenti clinici; attraverso i Gateway XCA (non oggetto del presente intervento) che potranno essere
realizzati successivamente, le ricerche di documenti clinici dei pazienti potranno essere estese anche alle
AO/AOU e/o agli altri soggetti privati accreditati del SSR. Il Registry potrà essere integrato con la futura
eventuale piattaforma regionale di gestione dei Consensi dei Cittadini; quest’ultima sarà a sua volta integrata
con gli ulteriori applicativi che hanno necessità di interagire per la registrazione o il recupero dei documenti di
consenso. In sostanza, il Registry, ogni qualvolta venga richiamato dall’Orchestratore o da altra applicazione,
dovrà verificare la presenza del consenso riferito alla possibilità di fruizione del documento richiesto.
Il presente documento costituisce il Progetto dei Fabbisogni per i servizi richiesti dall’Amministrazione ATS
Sardegna, esso riporta la proposta tecnico ed economica da implementare presso l’Amministrazione sulla base
delle richieste contenute nel Piano dei Fabbisogni secondo le modalità tecniche ed i listini previsti nel Contratto
Quadro.
Il presente progetto, versione 1.1, costituisce un aggiornamento della precedente versione per quanto il
piano temporale di erogazione dei servizi. Rimane immutata la descrizione delle attività e l’impegno
economico.
1.2 SCOPO
Scopo del documento è documentare e quantificare i servizi richiesti dall’Amministrazione. Si compone di:
n Organizzazione del Contratto
n Progetto di Attuazione
n Modalità di presentazione e approvazione degli stati di avanzamento mensili
n Piano di Attuazione
n Data di Attivazione
Versione 1.1 R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Pagina
Indra Italia S.p.A/Pwc Public Sector S.r.l.
Data di emissione 27/03/2020 4 di 21
Uso pubblicoATS
Data: 30/03/2020 10:57:36 PG/2020/0081006
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Sistema Pubblico di Connettività LOTTO 3
Indra Italia S.p.A/Pwc Public Sector S.r.l
Progetto dei Fabbisogni SPCL3-ATS_XDS-ProgettoFabbisogni-1.1
1.3 CAMPO DI APPLICAZIONE
Il documento si applica al progetto SPC lotto 3. In particolare, ai seguenti servizi:
n Realizzazione interfacce web services
n Realizzazione client per la fruizione dei servizi
n Orchestrazione
1.4 ASSUNZIONI
La ATS renderà disponibili la piattaforma hardware necessaria ad ospitare la soluzione, le eventuali licenze di
sistemi operativi, middleware e RDBMS, e la connettività correlata.
1.5 RIFERIMENTI
Identificativo Titolo/Descrizione
Contratto Quadro del 31/03/2017 e relativi Allegati Contratto Quadro del 31/03/2017 relativo all’Appalto dei
servizi di interoperabilità per i dati e di cooperazione
applicativa (lotto 3) in favore delle PA.
Allegato 5A alla lettera d’invito Capitolato Tecnico Parte Generale
Allegato 5B alla lettera d’invito Capitolato Tecnico Lotto 3
SPCL3-ATS-ESB-PianoFabbisogni v 3_6 Piano dei Fabbisogni
SPLC-ATS-XDS-ProgettoFabbisogni-1.0 del 8.01.2019 Progetto dei Fabbisogni
1.6 ACRONIMI E GLOSSARIO
Definizione / Acronimo Descrizione
Consip Consip S.p.a.
RTI Raggruppamento Temporaneo d’Impresa
SPC Sistema Pubblico di Connettività
ATS Azienda Tutela della Salute
ASSL Azienda Socio Sanitaria Locale
ESB Enterprise Service Bus
Versione 1.1 R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Pagina
Indra Italia S.p.A/Pwc Public Sector S.r.l.
Data di emissione 27/03/2020 5 di 21
Uso pubblicoATS
Data: 30/03/2020 10:57:36 PG/2020/0081006
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Sistema Pubblico di Connettività LOTTO 3
Indra Italia S.p.A/Pwc Public Sector S.r.l
Progetto dei Fabbisogni SPCL3-ATS_XDS-ProgettoFabbisogni-1.1
2 ORGANIZZAZIONE DEL CONTRATTO ESECUTIVO
Il RTI si avvale di un modello organizzativo di Cooperazione, che ha come obiettivo quello di soddisfare le
richieste di Cooperazione delle Amministrazioni in maniera coordinata e integrata sia a livello di singolo
Contratto Esecutivo sia a livello di Contratto Quadro.
Per il Contratto Esecutivo si identificano:
n il Responsabile del Contratto Esecutivo: Sergio Nicodemo
n il Responsabile delle funzioni di Project e Risk Management e di Quality Management specifiche per il
CE: Graziano Trasarti
La figura seguente rappresenta l’organizzazione prevista per l’esecuzione del contratto.
Responsabile
Re
C.Q.
Responsabile
le
Responsabile dei Contratto Es.
Centri Servizi
Project e Risk
Qualità
Centri Servizi
Management
Responsabile
le Responsabile
le Responsabile
le
Coop. App. Open Data Big Data
Web Supporto
services/Client Memorizzazione
Orchestrazione Supporto Analisi
Porta di dominio SPAQRL end point BIG Data «a-a-s»
Piattaforme «a-a-s»
Figura 1: Organizzazione del Contratto
La tabella seguente riporta i nominativi/ruoli dell’organizzazione previsti per i servizi contrattuali erogati.
Versione 1.1 R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Pagina
Indra Italia S.p.A/Pwc Public Sector S.r.l.
Data di emissione 27/03/2020 6 di 21
Uso pubblicoATS
Data: 30/03/2020 10:57:36 PG/2020/0081006
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Sistema Pubblico di Connettività LOTTO 3
Indra Italia S.p.A/Pwc Public Sector S.r.l
Progetto dei Fabbisogni SPCL3-ATS_XDS-ProgettoFabbisogni-1.1
Ruolo Nome Cognome Riferimenti
Responsabile Centro Emiliano Muroni e.muroni@almaviva.it
Servizi
Responsabile Marco Clivio m.clivio@almaviva.it
Cooperazione
Applicativa
Versione 1.1 R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Pagina
Indra Italia S.p.A/Pwc Public Sector S.r.l.
Data di emissione 27/03/2020 7 di 21
Uso pubblicoATS
Data: 30/03/2020 10:57:36 PG/2020/0081006
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Sistema Pubblico di Connettività LOTTO 3
Indra Italia S.p.A/Pwc Public Sector S.r.l
Progetto dei Fabbisogni SPCL3-ATS_XDS-ProgettoFabbisogni-1.1
3 PROGETTO DI ATTUAZIONE
Dalle esigenze espresse nel Piano dei Fabbisogni “Servizi di interoperabilità per i dati e di cooperazione
applicativa” è stato possibile identificare il progetto finalizzato allo sviluppo di una Piattaforma di
interoperabilità documentale basata sull’Enterprise Service Bus dell’ATS Sardegna, finalizzata alla indicizzazione
ed alla disponibilità dei documenti clinici per l’orchestratore delle Cure Primarie, di prossima acquisizione.
3.1 PRIMA ESIGENZA: REALIZZARE UNA STRUTTURA DI REGISTRY XDS PER ATS SARDEGNA
L’esigenza rappresentata è la seguente:
Realizzare una struttura di Cinical Document repository a livello ATS mediante un Registry XDS, integrato con
la piattaforma di gestione dei consensi e riferito ai Clinical Data Repository presenti in tutte le Aree Socio
Sanitarie che compongono l’ATS.
I Clinical Data Repository Galileo sono presenti presso ogni singola ASSL come Repository di alcune tipologie di
documenti clinici.
Il profilo IHE XDS (cross-enterprise document sharing) è preposto alla registrazione e alla distribuzione di
documenti clinici elettronici tra diversi attori coinvolti nei processi sanitari. XDS definisce specifiche standard
per la condivisione dei documenti, permettendo di gestire un insieme centralizzato di informazioni cliniche
relative ad un paziente all’interno di un singolo Affinity Domain.
Il concetto di Affinity Domain XDS può essere descritto come un gruppo di attori che cooperano sulla base di
un set comune di regole e che condividono una comune infrastruttura. Gli elementi caratteristici di un sistema
XDS, ciascuno con le rispettive caratteristiche, sono i seguenti:
· un Document Repository preposto all’archiviazione dei documenti in modo trasparente, sicuro e affidabile,
in grado di rispondere alle richieste di recupero di documenti;
· un Document Registry preposto alla conservazione ed indicizzazione di informazioni relative ai suddetti
documenti, affinché i documenti di interesse durante un processo clinico possano facilmente essere
selezionati e recuperati (vedi successivo punto AZIONE 2);
· i Document Source, che rappresentano gli attori in grado di produrre e archiviare documenti clinici (quali
ad esempio laboratori, reparti ospedalieri, sistemi radiologici, Pronto Soccorso);
· i Document Consumers, che costituiscono gli attori interessati al consumo dei documenti (nel caso
specifico, la piattaforma di Cure Primarie di prossima acquisizione nella Fase 2 del progetto).
Il profilo XDS non prevede vincoli alle tipologie di documenti, pertanto possono essere gestite svariate tipologie
e formati di documenti rispetto agli standard più diffusi.
L’ XDS Repository, conformemente allo standard IHE, dovrà gestire le seguenti funzionalità:
· pubblicazione documenti (Provide And Register Document Set-b [ITI-41])
· recupero documenti (Retrieve Document Set-b [ITI-43]).
Versione 1.1 R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Pagina
Indra Italia S.p.A/Pwc Public Sector S.r.l.
Data di emissione 27/03/2020 8 di 21
Uso pubblicoATS
Data: 30/03/2020 10:57:36 PG/2020/0081006
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Sistema Pubblico di Connettività LOTTO 3
Indra Italia S.p.A/Pwc Public Sector S.r.l
Progetto dei Fabbisogni SPCL3-ATS_XDS-ProgettoFabbisogni-1.1
XDS Registry dovrà gestire le seguenti funzionalità, che rispecchiano le transazioni definite dallo standard IHE:
· indicizzazione documento (Register Document Set-b [ITI-42])
· ricerca documenti (Registry Stored Query [ITI-18]).
Di seguito uno schema dell’architettura funzionale:
L’esigenza si sostanzia nelle seguenti azioni:
1) AZIONE 1: rendere i Clinical Data Repository compatibili con la tecnologia XDS.
Per realizzare l’obiettivo sarà necessario l’adeguamento dei CDR Galileo esistenti, già dotati delle licenze
necessarie, da migrare all’ultima versione disponibile per poi procedere alla installazione e configurazione dei
moduli software necessari per renderli compliant alla tecnologia XDS.
L’adeguamento si sostanzierà nell’upgrade di Galileo all’ultima versione. Quest’ultima, contiene le strutture
tabellari che permettono la gestione dei metadati e l’innesco delle transazioni XDS.
Le operazioni di upgrade verranno realizzate, ASSL per ASSL, fino a completamento. La durata è variabile a
seconda dell’obsolescenza della versione attualmente in uso.
Di seguito un prospetto delle versioni attualmente in produzione:
ASSL Versione in uso
Sassari 1.4
Olbia 1.5
Versione 1.1 R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Pagina
Indra Italia S.p.A/Pwc Public Sector S.r.l.
Data di emissione 27/03/2020 9 di 21
Uso pubblicoATS
Data: 30/03/2020 10:57:36 PG/2020/0081006
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Sistema Pubblico di Connettività LOTTO 3
Indra Italia S.p.A/Pwc Public Sector S.r.l
Progetto dei Fabbisogni SPCL3-ATS_XDS-ProgettoFabbisogni-1.1
Nuoro 1.4
Lanusei 1.4
Oristano 1.5
Sanluri 1.2
Carbonia 1.4
Cagliari 1.2
Come si vede, la situazione è variegata: alcune ASSL già utilizzano l’ultima versione, e necessitano pertanto solo
di un Upgrade di release, mentre altre (su tutte Cagliari), utilizzano versioni estremamente obsolete, addirittura
risalenti alla prima installazione del sistema SILUS (2008-2009).
Visto che si tratta di sistemi in produzione, per ridurre al minimo i disagi ed assicurare la buona riuscita delle
operazioni, le attività tecniche di upgrade verranno realizzate e testate in ambiente di test, per poi, una volta
accertata la buona riuscita delle operazioni, essere ripetute in produzione. Quest’ultimo passo prevede un
periodo di fermo macchina dipendente dal numero di versioni e release che dovranno essere applicate. In fase
esecutiva sarà prodotto un cronoprogramma ed una stima dei periodi di fermo macchine ASSL per ASSL, che
potranno essere comunicati agli utenti nell’ottica di ridurre al minimo i disagi.
2) AZIONE 2: Attivare un sistema di gestione delle anagrafiche dei pazienti
Si tratta di attivare un modulo software Anagrafico che permetta di gestire i codici identificativi regionali dei
pazienti, con gli alias con i quali gli stessi pazienti sono riconosciuti nel resto dell’ATS. Attualmente, infatti,
Galileo non gestisce i codici identificativi regionali dei pazienti (XMPI Centrale di SiSaR): ciò significa che ogni
singolo Repository Galileo contiene dati riferibili solo ai pazienti locali (XMPI SiSaR locale); dovendosi riferire ad
un’area più estesa (tutta l’ATS), è necessario che i pazienti siano identificabili in prima istanza attraverso il codice
identificativo regionale, ed in seconda istanza attraverso i codici identificativi locali.
La soluzione proposta prevede l’attivazione del modulo Galileo PEOPLE, in unica istanza per tutta l’ATS.
Galileo PEOPLE è un sistema realizzato in tecnologia web e scritto interamente in Java. Il sistema è realizzato
secondo l’architettura n-tier (multi livello) ed è costituito da un insieme di componenti indipendenti, ciascuno
dedicato a svolgere specifiche funzioni. L’adozione di un’architettura modulare, con netta separazione
funzionale dei moduli, ha come vantaggio il fatto che generalmente non si introducono vincoli o dipendenze
nella collocazione fisica dei componenti stessi; questo consente la massima flessibilità nella costruzione delle
configurazioni hardware. Il software è stato progettato e realizzato utilizzando tecniche di modellazione UML
sia per le strutture statiche che per quelle dinamiche e successivamente implementando le specifiche SUN JSR-
220 (Java Persistence API) per definire le entità (classi java che gestiscono l'accesso al database) che mappano
il modello demografico stabilito.
Le componenti principali del sistema sono il database (PSN schema), l’applicazione che espone i servizi web
(Web Service application), l’applicazione di consultazione/manutenzione (Client application) e l’applicazione di
integrazione HL7 (Integration application).
Versione 1.1 R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Pagina
Indra Italia S.p.A/Pwc Public Sector S.r.l.
Data di emissione 27/03/2020 10 di 21
Uso pubblicoATS
Data: 30/03/2020 10:57:36 PG/2020/0081006
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Sistema Pubblico di Connettività LOTTO 3
Indra Italia S.p.A/Pwc Public Sector S.r.l
Progetto dei Fabbisogni SPCL3-ATS_XDS-ProgettoFabbisogni-1.1
3.1.1 Database
Il database contiene tutti i dati demografici aggiornati, la relativa storicizzazione e le tabelle di dizionario del
sistema. È richiesto Oracle RDBMS versione 9 o superiore. L’occupazione stimata per ogni milione di posizioni
anagrafiche gestite è tre gigabyte.
È sconsigliato l’accesso diretto al database da parte di applicazioni terze. In caso di necessità è possibile usare
uno schema alternativo che espone alcune viste e procedure specifiche per la lettura/scrittura dei dati
demografici. In ogni caso la scrittura attraverso questo accesso al database non è mai sincrona in quanto i dati
sono storicizzati su una coda e successivamente processati da un agente asincrono che opera all’interno della
web-application e che rimanda gli stessi ai manager di processo (gestori della business-logic) dei servizi web.
3.1.2 IHE Patient Identifier Cross-referencing (PIX)
L’architettura proposta realizza il profilo IHE PIX, ossia l’integrazione dei vari domini di identificazione anagrafica
usando un approccio di correlazione tra tutti gli identificatori associati allo stesso paziente. Questa sezione
presenta come questo approccio sia compatibile con organizzazioni che desiderano realizzare sistemi
centralizzati di archiviazione dei dati demografici, a livello aziendale o geografico (eMPI – Enterprice Master
Patient Identifier).
Il concetto di eMPI è spesso associato alla creazione di un nuovo dominio di identificazione anagrafico. Tale
dominio viene quindi considerato principale, più importante o più attendibile rispetto ad altri domini anagrafici
già esistenti ed operativi all’interno dell’organizzazione sanitaria, aziendale o territoriale. Questa
rappresentazione gerarchica può essere considerata un particolare caso di correlazione, dove gli identificatori
dei vari domini sono messi in relazione con gli identificatori del dominio principale. Due possibili configurazioni
possono essere descritte dalla figura sottostante.
Versione 1.1 R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Pagina
Indra Italia S.p.A/Pwc Public Sector S.r.l.
Data di emissione 27/03/2020 11 di 21
Uso pubblicoATS
Data: 30/03/2020 10:57:36 PG/2020/0081006
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Sistema Pubblico di Connettività LOTTO 3
Indra Italia S.p.A/Pwc Public Sector S.r.l
Progetto dei Fabbisogni SPCL3-ATS_XDS-ProgettoFabbisogni-1.1
PIX riceve i messaggi HL7 relativamente alle richieste di alimentazione (feed), riceve i messaggi HL7 di richiesta
delle chiavi di identificazione (PIX query).
Flusso degli eventi:
· L'operatore di accettazione registra un paziente
· L'attore PIX esegue la verifica di esistenza del nominativo nel dominio master
· PIX associa la relazione ID-A con ID-Master
3) AZIONE 3: Creare un Registry XDS che contenga le chiavi per poter accedere a qualunque documento
clinico contenuto nelle istanze di Galileo.
Il processo di sottomissione di un nuovo documento prevede l’avvio, da parte dell’applicativo sorgente, di una
transazione IHE ITI-41 verso un XDS Repository. La componente XDS Registry centrale verrà attivata dal modulo
Repository tramite l’invio sincrono via web service di un messaggio contenente tutte le informazioni relative al
documento ai fini dell’indicizzazione (transazione ITI-42).
Le informazioni inviate dal XDS Repository verranno salvate sull’indice centrale dei documenti mantenuto dal
registry, diventando così disponibili per successive ricerche da parte di XDS Consumer.
3.1.3 XDS Registry: modello dei dati
Il modello dati del Registry, secondo le indicazioni dello standard XDS, è basato sulle entità principali descritte
di seguito.
· XDS Document Entry: raccoglie il set di metadati descrittivi delle caratteristiche di un documento XDS,
unitamente al link ad una posizione (uniqueId) su uno specifico XDS Repository (RepositoryUniqueId) in cui
il documento è stato archiviato e può essere recuperato;
· XDS Document: include il bytestream del documento clinico, archiviato in un Repository e referenziato da
una entità di XDS Document Entry;
· XDS Folder: si tratta di un contenitore “logico” che raggruppa una o più XDS Document Entries secondo un
determinato criterio (ad esempio, per episodio clinico, autore, specialità clinica, …). Questo tipo di struttura
è usata opzionalmente e in modo personalizzabile, allo scopo di fornire diversi modi in cui organizzare i
documenti. Uno stesso documento XDS può appartenere a zero o più Folders;
· XDS Submission Set: quando un documento XDS viene registrato da un attore Document Source, esso deve
essere incluso in uno e un solo Submission Set. Un XDS Submission Set raggruppa zero o più nuovi
documenti XDS e referenzia eventuali documenti XDS già esistenti;
· XDS Submission Request: una Submission Requests include uno e un solo Submission Set, zero or più nuovi
XDS Folders e/o eventuale assegnamento di documenti XDS Documents a Folder nuovi o esistenti. La
Submission Request viene processata in maniera atomica da Repository/Registry, in modo che il
Submission Set, i documenti e gli eventuali Folder inclusi nella sottomissione siano registrati tutti, o tutti
rifiutati. Questa caratteristica di atomicità della Submission garantisce che le entità risultino gestite e
disponibili per un Document Consumer tutte nello stesso momento.
Versione 1.1 R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Pagina
Indra Italia S.p.A/Pwc Public Sector S.r.l.
Data di emissione 27/03/2020 12 di 21
Uso pubblicoATS
Data: 30/03/2020 10:57:36 PG/2020/0081006
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Sistema Pubblico di Connettività LOTTO 3
Indra Italia S.p.A/Pwc Public Sector S.r.l
Progetto dei Fabbisogni SPCL3-ATS_XDS-ProgettoFabbisogni-1.1
Figura 2: modello dati XDS
3.1.4 Cenni su ebXML
La specifica ebXML (Electronic Business using eXtensible Markup Language) descrive l’implementazione di
client e server di registry/repository XDS tramite interfacce, protocolli e modelli informativi standard per la
pubblicazione, la gestione, la ricerca e il recupero di documenti e metadati associati. La specifica ebXML
RegRep è composta di due parti:
· ebRIM (Registry Info Model): definisce le tipologie di metadati e contenuti che possono essere gestiti
da un Registry bXML. E’ usato linguaggio XML, espresso tramite oggetti ed attributi;
· ebRS (Registry Services - protocolli): definisce i servizi gestiti da Registry e i protocolli per l’integrazione
dei client.
Il modello ebRIM include le seguenti classi per esplicitare i principali elementi del modello dati XDS descritti
precedentemente.
Versione 1.1 R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Pagina
Indra Italia S.p.A/Pwc Public Sector S.r.l.
Data di emissione 27/03/2020 13 di 21
Uso pubblicoATS
Data: 30/03/2020 10:57:36 PG/2020/0081006
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Sistema Pubblico di Connettività LOTTO 3
Indra Italia S.p.A/Pwc Public Sector S.r.l
Progetto dei Fabbisogni SPCL3-ATS_XDS-ProgettoFabbisogni-1.1
ebRIM Class XDS Class Description
ExtrinsicObject XDSDocumentEntry Raggruppa il contenuto informativo del documento
salvato nel Registry (metadati). Il documento in sè
viene considerato come un ‘external object' (e posto
nel Repository)
RegistryPackage XDSSubmissionSet Reppresenta gli oggetti ‘Submission Set’ e il
meccanismo dei ‘Folder’
XDSFolder
Association Definisce link bidirezionali e tipizzazione dei dati.
E’ il formalismo di ebXML per includere oggetti Esempio: associazione tra l’oggetto ‘Document Entry’
all’interno di un RegistryPackage e l’oggetto ‘Submission Set’ (o ‘Folder’)
3.1.5 Persistenza dei metadati NoSql
La componente XDS Registry, in quanto componente applicativa deputata alla persistenza di indici e metadati
documentali, è basata sul database NoSQL di nuova generazione MongoDB. L’insieme costituito da una voce
nell’indice dei documenti sommata ai metadati del documento stesso, infatti, costituisce un elemento logico
unitario le cui singole componenti sono in relazione gerarchica, e vengono spesso usate insieme come criteri
di selezione da parte del motore che gestisce le ricerche documentali. Questo particolare scenario rende i
classici database relazionali strumenti non ottimali per la persistenza ed indicizzazione di queste informazioni.
Esse infatti sono un tutt’uno, elementi di un’unica “collezione”, piuttosto che un insieme di record disgregati
posti in relazione tra loro secondo la logica canonica dei database relazionali. MongoDB consente di superare
questi limiti gestendo nativamente basi dati non più nella logica entità-relazione bensì nella logica “a
collezione”, persistendo gli elementi delle collezioni in modo compatto e unificato. Questo consente di
indicizzare ciascuna collezione in modo estremamente efficiente così come di effettuare al loro interno
ricerche usando informazioni che sono già tra loro vicine e logicamente collegate, eliminando la necessità di
operazioni di JOIN complesse e costose dal punto di vista computazionale.
Il risultato in termini di performance è di altissimo livello se comparato con le performance ottenibili, a parità
di funzionalità, con un database relazionale.
3.2 SECONDA ESIGENZA: INDICIZZAZIONE DOCUMENTI
L’esigenza è così formulata:
Versione 1.1 R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Pagina
Indra Italia S.p.A/Pwc Public Sector S.r.l.
Data di emissione 27/03/2020 14 di 21
Uso pubblicoATS
Data: 30/03/2020 10:57:36 PG/2020/0081006
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Sistema Pubblico di Connettività LOTTO 3
Indra Italia S.p.A/Pwc Public Sector S.r.l
Progetto dei Fabbisogni SPCL3-ATS_XDS-ProgettoFabbisogni-1.1
Indicizzare i documenti presenti e futuri sui singoli Repository Galileo, in modo tale da renderli fruibili
dall’esterno secondo i profili standard IHE XDS.
Attraverso opportune procedure batch verranno indicizzati sul Registry centrale. Di seguito una tabella che
evidenzia i documenti presenti nei CDR ad oggi.
Dim. DB N°
Impianto
(GB) Documenti
ASSL Cagliari 192 1.365.487,00
ASSL Carbonia 114 900.613,00
ASSL Sanluri 120 793.039,00
ASSL Oristano 146 1.596.565,00
ASSL Lanusei 136 1.292.069,00
ASSL Nuoro 251 2.946.920,00
ASSL Olbia 120 1.719.691,00
ASSL Sassari 391 8.382.529,00
TOTALE 1470 18.996.913,00
3.3 TERZA ESIGENZA: SPERIMENTAZIONE
L’esigenza è così formulata:
Attivare la sperimentazione del sistema fornendo supporto al Servizio 116117.
Nel contesto della sperimentazione prevista territorialmente in relazione all’applicazione dell’intervento della
Scheda Progetto N: 1 relativa al Servizio 116117 – Numero Unico della Non Emergenza, dovrà essere fornito il
supporto applicativo – con eventuale sviluppo di interfacce programmatiche di selezione e accesso alla
documentazione clinica verso le specifiche applicazioni - per consentire la disponibilità delle informazioni agli
operatori autorizzati che necessitano di visualizzare informazioni dei pazienti richiedenti il servizio di
Continuità Assistenziale. In tale contesto sarà necessario disporre di una piattaforma di gestione del consenso
che renda possibile la sperimentazione descritta. La sperimentazione sarà limitata ai referti di Laboratorio di
Analisi. Per consentire la sperimentazione verrà attivata una piattaforma di Content Management integrata
con il LIS DNLab per poter raccogliere il consenso dei pazienti alla fruizione dei documenti.
3.4 Quadro riassuntivo dei servizi
Si riporta di seguito la tabella con il dettaglio degli importi per servizio. I costi indicati, si intendono IVA
esclusa:
Versione 1.1 R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Pagina
Indra Italia S.p.A/Pwc Public Sector S.r.l.
Data di emissione 27/03/2020 15 di 21
Uso pubblicoATS
Data: 30/03/2020 10:57:36 PG/2020/0081006
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Sistema Pubblico di Connettività LOTTO 3
Indra Italia S.p.A/Pwc Public Sector S.r.l
Progetto dei Fabbisogni SPCL3-ATS_XDS-ProgettoFabbisogni-1.1
Lotto 3 ATS - XDS € 945.680,00
Modalità di Periodicità di
Cod. Prezzo unitario offerto quantità
Nome Servizio consuntivazion consuntivazion valore economico
Serv. (€) necessarie
e e
L3.S2 Realizzazione interfacce web services € 330.000,0
L3.S2.1 Sviluppo singola operation comprensivo di 12 mesi di garanzia A corpo na € 3.000,00 110 € 330.000,0
L3.S3 Realizzazione client per la fruizione dei servizi € 278.180,0
L3.S3.1 Sviluppo singolo FP comprensivo di 12 mesi di garanzia A corpo na € 140,00 1.987 € 278.180,0
L3.S4 Orchestrazione € 337.500,0
L3.S4.1 Orchestrazione singolo servizio (orchestrazione di meno di 10 servizi)A corpo na € 2.500,00 135 € 337.500,0
3.5 Impegno delle risorse professionali
Su richiesta dell’Amministrazione e in relazione alle attività da svolgere, il mix professionale impegnato nella
attività potrà variare rispetto a quanto previsto nel contratto quadro.
3.6 Indirizzo di dispiegamento dei servizi
Il Centro Servizi del RTI può essere considerato a tutti gli effetti un Data Center “virtuale” ed è costituito dalle
sedi che le aziende del RTI hanno attivato per la erogazione di tutti i servizi previsti dall’Accordo quadro SPC.
Il Centro Servizi è organizzato su 4 sedi (cfr. tabella seguente) dislocate sul territorio italiano: tre della
mandataria Almaviva che ospitano sia il personale sia l’infrastruttura dedicata alle Amministrazioni contraenti,
una di Indra che prevede la presenza del solo personale.
Sede Azienda RTI Data Center Indirizzo Mq totali
Casal Boccone Almaviva √ via di Casal Boccone 188/190 - Roma 34.800
Scalo Prenestino Almaviva √ via dello Scalo Prenestino 15 - Roma 11.200
Missaglia Almaviva √ via Missaglia 98 - Milano 10.800
Saba Indra via Umberto Saba 11 - Roma 2.600
I servizi oggetto del presente Progetto saranno erogati secondo le modalità previste dal Contratto Quadro,
mentre saranno erogati dal Centro Servizi i Servizi Trasversali a supporto, qui di seguito elencati:
n Sistema di Controllo dei livelli di Servizio (SLM);
n Portale di Governo della Fornitura (PGF);
n Help Desk (HD).
In particolare l’infrastruttura di Help Desk sarà ospitata nel Centro Servizi, mentre il personale di I livello
opererà da postazioni presenti presso una sede del Gruppo AlmavivA e il personale di II livello opererà da
postazioni presenti presso le sedi del RTI.
Vanno inoltre ricordati i Servizi di gestione necessari al buon funzionamento del Centro Servizi:
n Gestione della sicurezza dei Data Center, consiste messa in opera delle misure di tipo fisico, logico ed
organizzativo atte ad assicurare in corso d’opera il mantenimento dei livelli di sicurezza coerenti con
Versione 1.1 R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Pagina
Indra Italia S.p.A/Pwc Public Sector S.r.l.
Data di emissione 27/03/2020 16 di 21
Uso pubblicoATS
Data: 30/03/2020 10:57:36 PG/2020/0081006
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Sistema Pubblico di Connettività LOTTO 3
Indra Italia S.p.A/Pwc Public Sector S.r.l
Progetto dei Fabbisogni SPCL3-ATS_XDS-ProgettoFabbisogni-1.1
le politiche e con gli impegni assunti nei contratti e formalizzati nelle specifiche di
servizio/configurazioni di servizio.
n Monitoraggio e controllo dei sistemi e della rete, consiste nell’utilizzo dell’infrastruttura hardware e
software di base a supporto delle verifiche sulla disponibilità delle risorse dell’ambiente elaborativi e
della rete e successivi controlli sui Log.
Gestione dei Backup dei sistemi del Centro Servizi, consiste nell’utilizzo della infrastruttura a supporto della
applicazione delle politiche di backup e nel salvataggio in ambienti sicuri dei supporti utilizzati.
3.7 Modalità di esecuzione del collaudo dei servizi
I servizi oggetto del presente Contratto Esecutivo saranno sottoposti ad un collaudo “sul campo” da parte
dell’Amministrazione.
Tale attività coinciderà con l’esecuzione del collaudo del primo progetto previsto nel Piano di Attuazione per
ciascun servizio.
Versione 1.1 R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Pagina
Indra Italia S.p.A/Pwc Public Sector S.r.l.
Data di emissione 27/03/2020 17 di 21
Uso pubblicoATS
Data: 30/03/2020 10:57:36 PG/2020/0081006
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Sistema Pubblico di Connettività LOTTO 3
Indra Italia S.p.A/Pwc Public Sector S.r.l
Progetto dei Fabbisogni SPCL3-ATS_XDS-ProgettoFabbisogni-1.1
4 MODALITÀ DI PRESENTAZIONE E APPROVAZIONE DEGLI
STATI DI AVANZAMENTO MENSILI
4.1 GESTIONE DEI SAL MENSILI
Gli Stati di avanzamento, sul modello di quelli mensili, verranno prodotti con cadenza concordata con il DEC.
Gli stati di avanzamento mensili costituiscono lo strumento mediante il quale il RTI tiene informata
l’Amministrazione su tutte le attività che costituiscono il provisioning dei servizi da erogare (dal sopralluogo
fino al collaudo finale e la relativa migrazione) e, successivamente, sullo stato di funzionamento e la qualità
dei servizi stessi.
A tale scopo il Fornitore ed il RTI attivano un servizio di project management consistente nella pianificazione,
gestione e verifica delle attività mirate al completamento del progetto.
Il project manager del Fornitore si confronterà con il responsabile di progetto nominato dall’Amministrazione
per la definizione ed esecuzione delle attività.
I report saranno prodotti con cadenza mensile e consegnati all’Amministrazione secondo una modalità di
comunicazione definita tra RTI ed Amministrazione.
4.2 REPORT DI STATO DI AVANZAMENTO MENSILE
Gli Stati di avanzamento, sul modello di quelli mensili, verranno prodotti con cadenza concordata con il DEC.
Per quanto concerne le attività legate all'implementazione dei servizi, il flusso comunicativo può essere
sintetizzato come segue:
n il project manager del RTI invia, mediante E-mail, il report SAL all’Amministrazione;
n l’Amministrazione, nella persona del suo responsabile di progetto, analizza, congiuntamente con il
project manager del fornitore, la situazione di avanzamento, le eventuali modifiche rispetto al piano
operativo previsto e le contromisure che il fornitore intende mettere in atto per recuperare gli
eventuali ritardi verificatisi.
n Il responsabile dell’Amministrazione approva il report mediante comunicazione e-mail verso il
fornitore.
Il report di Stato di Avanzamento Mensile contiene le seguenti informazioni:
n Avanzamento/Rispetto dei tempi previsti nel piano di attivazione;
Versione 1.1 R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Pagina
Indra Italia S.p.A/Pwc Public Sector S.r.l.
Data di emissione 27/03/2020 18 di 21
Uso pubblicoATS
Data: 30/03/2020 10:57:36 PG/2020/0081006
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Sistema Pubblico di Connettività LOTTO 3
Indra Italia S.p.A/Pwc Public Sector S.r.l
Progetto dei Fabbisogni SPCL3-ATS_XDS-ProgettoFabbisogni-1.1
n Eventuali ripianificazioni;
n Esito Tracking sui rischi;
n Esito dei test interni;
n Esito collaudi effettuati (con DigtiPA e/o con l’amministrazione stessa);
n Change emersi nel periodo;
n Azioni correttive/preventive applicate;
n Varie ed eventuali.
Tutti gli stati di avanzamento sono soggetti ad approvazione da parte dell’Amministrazione.
Nella fase di erogazione dei servizi il RTI manterrà la produzione mensile del SAL, orientati più a definire
l’andamento della erogazione, in termini di:
n Indicazioni su possibili problemi o anomalie eventualmente verificatisi;
n Proposte di modifiche/aggiornamenti da apportare;
n Proposte eventuali ottimizzazioni/migliorie da apportare all’organizzazione dei processi definiti;
n Varie ed eventuali.
Tali informazioni posso essere fornite utilizzando il template SPCL3-TMP-SALMensile-1.0.
Versione 1.1 R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Pagina
Indra Italia S.p.A/Pwc Public Sector S.r.l.
Data di emissione 27/03/2020 19 di 21
Uso pubblicoATS
Data: 30/03/2020 10:57:36 PG/2020/0081006
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Sistema Pubblico di Connettività LOTTO 3
Indra Italia S.p.A/Pwc Public Sector S.r.l
Progetto dei Fabbisogni SPCL3-ATS_XDS-ProgettoFabbisogni-1.1
5 PIANO DI ATTUAZIONE
5.1 PIANO DI LAVORO
Il piano di lavoro si sviluppa secondo quanto riportato nello schema seguente:
distribuzione dell'impegno nel tempo 2020 2021
Novembre
Novembre
Dicembre
Dicembre
Febbraio
Febbraio
Settebre
Settebre
Gennaio
Gennaio
Ottobre
Ottobre
Maggio
Maggio
Giugno
Giugno
Giugno
Agosto
Agosto
Marzo
Marzo
Aprile
Aprile
Luglio
Luglio
ID Nome attività
ATS XDS X X X X X X X X X X X X X X X X X X X X X X X X X
Rendere i clinical data repository compatibili con la tecnologia
1 XDS
2 Attivare un sistema di gestione delle anagrafi dei pazienti
Creazione di un registri xds che possa accedere a qualunque
3 documento clinico contenuto nelle istanze di galileo
Attivazione della sperimentazione del sistema fornendo
4 supporto al servizio 116/117
5.2 GESTIONE DELLA SICUREZZA
Il documento SPCL3-SEC-Documento Programmatico sulla Sicurezza (DPS)-2.1.docx è il riferimento alle
politiche di sicurezza implementate dal RTI per SPC lotto 3.
Relativamente agli specifici progetti sviluppati nell’ambito dei servizi richiesti dall’ANPAL, sarà implementato
nel progetto il profilo di sicurezza per la riservatezza dei dati nonché le misure per soddisfarlo.
5.3 PIANO DI QUALITÀ
Il documento SPCL3-GEN-PianoQualitaGenerale-2.2.docx è il piano di qualità di riferimento per il presente
progetto.
Versione 1.1 R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Pagina
Indra Italia S.p.A/Pwc Public Sector S.r.l.
Data di emissione 27/03/2020 20 di 21
Uso pubblicoATS
Data: 30/03/2020 10:57:36 PG/2020/0081006
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Sistema Pubblico di Connettività LOTTO 3
Indra Italia S.p.A/Pwc Public Sector S.r.l
Progetto dei Fabbisogni SPCL3-ATS_XDS-ProgettoFabbisogni-1.1
6 DATA DI ATTIVAZIONE
La data di attivazione dei servizi contrattualizzati è il 01 giugno 2019, come da verbale sottoscritto dalle parti.
Versione 1.1 R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Pagina
Indra Italia S.p.A/Pwc Public Sector S.r.l.
Data di emissione 27/03/2020 21 di 21
Uso pubblicoPuoi anche leggere
