ATS Sardegna
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Indra Italia S.p.A/Pwc Public Sector S.r.l | Sistema Pubblico di Connettività LOTTO 3 |
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
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Indra Italia S.p.A/Pwc Public Sector S.r.l | Sistema Pubblico di Connettività LOTTO 3 |
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
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Indra Italia S.p.A/Pwc Public Sector S.r.l | Sistema Pubblico di Connettività LOTTO 3 |
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:
◼ programmazione aziendale e gestione complessiva dell'erogazione dei servizi sanitari e socio-sanitari;
◼ omogeneizzazione e armonizzazione dei processi gestionali nel territorio regionale in coordinamento con l'attività delle altre aziende sanitarie;
◼ 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;
◼ 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;
◼ 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;
◼ 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);
◼ 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
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Indra Italia S.p.A/Pwc Public Sector S.r.l | Sistema Pubblico di Connettività LOTTO 3 |
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:
◼ Organizzazione del Contratto
◼ Progetto di Attuazione
◼ Modalità di presentazione e approvazione degli stati di avanzamento mensili
◼ Piano di Attuazione
◼ Data di Attivazione
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Indra Italia S.p.A/Pwc Public Sector S.r.l | Sistema Pubblico di Connettività LOTTO 3 |
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:
◼ Realizzazione interfacce web services
◼ Realizzazione client per la fruizione dei servizi
◼ 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 |
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Indra Italia S.p.A/Pwc Public Sector S.r.l | Sistema Pubblico di Connettività LOTTO 3 |
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:
◼ il Responsabile del Contratto Esecutivo: Xxxxxx Xxxxxxxx
◼ il Responsabile delle funzioni di Project e Risk Management e di Quality Management specifiche per il CE: Xxxxxxxx Xxxxxxxx
e
i
Centri Servizi
La figura seguente rappresenta l’organizzazione prevista per l’esecuzione del contratto.
e
e
Responsabile
C.Q.
Responsabile dei
Centri Servizi
Responsabil
Coop. App.
Responsabile
Big Data
Orchestrazione
Web services/Client
Supporto Analisi
Supporto Memorizzazione
Responsabil Open Data
Qualità
Project e Risk
Management
Responsabil Contratto Es.
Piattaforme «a-a-s»
BIG Data «a-a-s»
SPAQRL end point
Porta di dominio
Figura 1: Organizzazione del Contratto
La tabella seguente riporta i nominativi/ruoli dell’organizzazione previsti per i servizi contrattuali erogati.
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Indra Italia S.p.A/Pwc Public Sector S.r.l | Sistema Pubblico di Connettività LOTTO 3 |
Progetto dei Fabbisogni | SPCL3-ATS_XDS-ProgettoFabbisogni-1.1 |
Ruolo | Nome | Cognome | Riferimenti |
Responsabile Centro Servizi | Xxxxxxxx | Xxxxxx | |
Responsabile Cooperazione Applicativa | Xxxxx | Xxxxxx |
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Indra Italia S.p.A/Pwc Public Sector S.r.l | Sistema Pubblico di Connettività LOTTO 3 |
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]).
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Indra Italia S.p.A/Pwc Public Sector S.r.l | Sistema Pubblico di Connettività LOTTO 3 |
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 Xxxxxxx 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 |
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Indra Italia S.p.A/Pwc Public Sector S.r.l | Sistema Pubblico di Connettività LOTTO 3 |
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, Xxxxxxx 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).
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Indra Italia S.p.A/Pwc Public Sector S.r.l | Sistema Pubblico di Connettività LOTTO 3 |
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.
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Indra Italia S.p.A/Pwc Public Sector S.r.l | Sistema Pubblico di Connettività LOTTO 3 |
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 Xxxxxxx.
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.
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Indra Italia S.p.A/Pwc Public Sector S.r.l | Sistema Pubblico di Connettività LOTTO 3 |
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.
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Indra Italia S.p.A/Pwc Public Sector S.r.l | Sistema Pubblico di Connettività LOTTO 3 |
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 XDSFolder | Reppresenta gli oggetti ‘Submission Set’ e il meccanismo dei ‘Folder’ |
Association E’ il formalismo di ebXML per includere oggetti all’interno di un RegistryPackage | Definisce link bidirezionali e tipizzazione dei dati. Esempio: associazione tra l’oggetto ‘Document Entry’ 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:
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Indra Italia S.p.A/Pwc Public Sector S.r.l | Sistema Pubblico di Connettività LOTTO 3 |
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.
Impianto | Dim. DB (GB) | N° 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:
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Indra Italia S.p.A/Pwc Public Sector S.r.l
Sistema Pubblico di Connettività LOTTO 3
Progetto dei Fabbisogni
SPCL3-ATS_XDS-ProgettoFabbisogni-1.1
Lotto 3 | ATS - XDS | € | 945.680,00 | ||||||
Cod. Serv. | Nome Servizio | Modalità di consuntivazion e | Periodicità di consuntivazion e | Prezzo unitario offerto (€) | quantità necessarie | valore economico | |||
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 se | 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 Xxxxx che prevede la presenza del solo personale.
Sede | Azienda RTI | Data Center | Indirizzo | Mq totali |
Casal Boccone | Almaviva | √ | xxx xx Xxxxx Xxxxxxx 000/000 - Xxxx | 34.800 |
Scalo Prenestino | Almaviva | √ | xxx xxxxx Xxxxx Xxxxxxxxxx 00 - Xxxx | 11.200 |
Missaglia | Almaviva | √ | xxx Xxxxxxxxx 00 - Xxxxxx | 10.800 |
Xxxx | Xxxxx | xxx Xxxxxxx Xxxx 00 - Xxxx | 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:
◼ Sistema di Controllo dei livelli di Servizio (SLM);
◼ Portale di Governo della Fornitura (PGF);
◼ 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:
◼ 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
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Indra Italia S.p.A/Pwc Public Sector S.r.l | Sistema Pubblico di Connettività LOTTO 3 |
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.
◼ 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.
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Indra Italia S.p.A/Pwc Public Sector S.r.l | Sistema Pubblico di Connettività LOTTO 3 |
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:
◼ il project manager del RTI invia, mediante E-mail, il report SAL all’Amministrazione;
◼ 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.
◼ 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:
◼ Avanzamento/Rispetto dei tempi previsti nel piano di attivazione;
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Indra Italia S.p.A/Pwc Public Sector S.r.l | Sistema Pubblico di Connettività LOTTO 3 |
Progetto dei Fabbisogni | SPCL3-ATS_XDS-ProgettoFabbisogni-1.1 |
◼ Eventuali ripianificazioni;
◼ Esito Tracking sui rischi;
◼ Esito dei test interni;
◼ Esito collaudi effettuati (con DigtiPA e/o con l’amministrazione stessa);
◼ Change emersi nel periodo;
◼ Azioni correttive/preventive applicate;
◼ 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:
◼ Indicazioni su possibili problemi o anomalie eventualmente verificatisi;
◼ Proposte di modifiche/aggiornamenti da apportare;
◼ Proposte eventuali ottimizzazioni/migliorie da apportare all’organizzazione dei processi definiti;
◼ Varie ed eventuali.
Tali informazioni posso essere fornite utilizzando il template SPCL3-TMP-SALMensile-1.0.
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Indra Italia S.p.A/Pwc Public Sector S.r.l
Sistema Pubblico di Connettività LOTTO 3
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 | ||||||||||||||||||||||||
ID | Nome attività | Giugno | Luglio | Agosto | Settebre | Ottobre | Novembre | Dicembre | Gennaio | Febbraio | Marzo | Aprile | Maggio | Giugno | Luglio | Agosto | Settebre | Ottobre | Novembre | Dicembre | Gennaio | Febbraio | Marzo | Aprile | Maggio | Giugno |
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 | |
1 | Rendere i clinical data repository compatibili con la tecnologia XDS | |||||||||||||||||||||||||
2 | Attivare un sistema di gestione delle anagrafi dei pazienti | |||||||||||||||||||||||||
3 | Creazione di un registri xds che possa accedere a qualunque documento clinico contenuto nelle istanze di galileo | |||||||||||||||||||||||||
4 | Attivazione della sperimentazione del sistema fornendo 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.
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Indra Italia S.p.A/Pwc Public Sector S.r.l | Sistema Pubblico di Connettività LOTTO 3 |
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.