Allegato tecnico - inmi spallanzani

Progetto integrazione anagrafica e repository : allegato tecnico
Scenario attuale ed obiettivi
L’Istituto Nazionale per le Malattie Infettive “Lazzaro Spallanzani” nel corso degli anni ha dato vita ad un
processo di informatizzazione delle attività ospedaliere, implementato una serie di sistemi informatici
applicativi altamente specializzati nei doversi contesti clinici (RIS/PACS, LIS, ADT, ecc.), di frequente basati
su modelli e tecnologie diversi. Se da un lato tale approccio ha consentito di ottimizzare il supporto
informatico rispetto alle esigenze specifiche di ogni singolo settore, garantendo un buon livello di
automatizzazione dei processi, dall’altra parte ha creato un fattore di criticità legato alla cooperazione fra le
varie applicazioni, portando alla nascita di “isole di dati” distinte e, talvolta, incompatibili tra i diversi
contesti clinici.
L’obiettivo attuale dell’Istituto è integrare e rendere interoperabili le informazioni e i processi per
migliorare la gestione delle risorse dell’Ente e per limitare i fattori di rischio dovuti al passaggio quotidiano
di tali informazioni tra le diverse unità funzionali.
Lo snodo centrale di tali informazioni è rappresentato dall’anagrafe/repository sanitaria centrale (d’ora in
poi denominata Repository Centrale) : sui dati di carattere anagrafico-sanitario si appoggiano tutti i servizi
gestionali per il riconoscimento dell’assistito, l’assegnazione delle terapie, la diagnostica, ecc. Si rende,
quindi, necessario far convergere questi dati tra i vari sistemi e l’anagrafe sanitaria per fornire informazioni
utili a fini diagnostici e terapeutici e per ridurre il numero di errori dovuti all’errata identificazione del
paziente (o comunque a diverse identificazioni riconducibili al medesimo paziente ma incongruenti tra
loro).
Caratteristiche tecniche
L’Istituto intende acquisire una piattaforma di integrazione che implementi un Repository Centrale il cui
requisito fondamentale è la rispondenza del componente a tutti i dettami della norma internazionale UNI
EN ISO 12967 “Health Informatics - Service Architecture” (HISA). Il middelware di integrazione dovrà
consentire, attraverso una struttura architetturale idonea, l’integrazione e la cooperazione delle soluzioni
informatiche attuali e future, facendo confluire le informazioni all’interno di un patrimonio informativo
comune e facendo quindi in modo che gli applicativi non debbano basarsi su db locali ma attingere al
repository comune. Tale patrimonio anagrafico costituirà la base del Repository Centrale contenente la
storia sanitaria del paziente, rendendo disponibili risultati, immagini, documenti, prescrizioni e ogni altra
informazione sull'attività clinica svolta all’interno dell’Istituto, utile sia per la cura della persona che per la
gestione amministrativa.
Il sistema dovrà avere queste caratteristiche:


indipendente: il framework/middleware dovrà operare in maniera indipendente dalle logiche dei
singoli applicativi presenti in Istituto. La piattaforma dovrà operare indipendentemente su sistemi
Microsoft che su sistemi Unix/Linux e su macchine virtuali.;
accessibile: i dati dovranno essere accessibili da diversi ambienti, tra cui almeno uno tra il
linguaggio C/C++, MS .NET, Java e web services per consentire anche alle applicazioni in uso da
tempo di utilizzare i nuovi sistemi;










standard: il framework/middlware sarà conforme ai principali standard dell’informatica sanitaria
(es . HL7 CDA, DICOM, ecc.)
La struttura informativa del Repository, cioè il modello fisico della base dati, deve essere stabile e
pubblica. In altre parole deve essere ben documentata e aperta, in modo da consentire all’Istituto
l’accesso autonomo alle informazioni, mediante il linguaggio SQL, come da rispondenza del
repository allo standard HISA;
Sia il modello informativo che i servizi del middleware devono poter essere sviluppati ed estesi
anche autonomamente dall’Istituto, senza alcuna dipendenza dal fornitore originale;
La struttura informativa del Repository deve comprendere almeno gli oggetti informativi
specificati nello standard HISA e raggruppati in cluster o aree. Rappresenterà elemento
preferenziale un modello informativo che rappresenti un superinsieme di quello prescritto;
Per ogni oggetto informativo del modello dati, dovranno essere gestiti degli attributi “standard” di
sistema come prescritto da HISA. Tra questi:
 Identificatore unico del record, invariante
 Identificatore temporale (“timestamp”) dell’orario dell’ultimo aggiornamento del
record che permette di gestire la concorrenza d’accesso senza dover ricorrere a lock
inutili e pesanti per il sistema
 Data ed orario della creazione iniziale del record
 Identificatore dell’agente (utente) che ha creato inizialmente il record
 Identificatore dell’unità che ha inizialmente creato il record
 Data ed orario dell’ultimo aggiornamento del record
 Identificatore dell’agente (utente) che ha effettuato l’ultima modifica nel record
 Identificatore dell’unità dalla quale è stata effettuata l’ultima modifica nel record
Il repository deve essere in grado di operare con almeno uno tra i principali sistemi DBMS sul
mercato tra i seguenti: MySQL , MS SQL Server, Oracle, PostgreSQL. La possibilità d’operare con
un numero maggiore di DBMS così come con DBMS OpenSource rappresenterà elemento
preferenziale nella scelta del sistema;
flessibile e scalabile: il sistema consentirà sia di integrare facilmente moduli già esistenti, sia di
aggiungerne di nuovi senza stravolgere le integrazioni già realizzate fino a quel momento; il sistema
dovrà essere dotato di strumenti software (interfaccia amministrativa, ambiente di sviluppo,
wizard, ecc.) che consentano consentire una rapida progettazione delle architetture di
integrazione, la definizione di nuovi processi o la modifica dei canali di comunicazione esistenti
senza l’ausilio di personale esterno al servizio informatico aziendale.
interoperabile: dovrà essere in grado, in tutte le aree applicative, di interagire con sistemi di
terze parti: ad es. con dispositivi medici (medical devices) e con strumenti e sistemi di
Radiodiagnostica per immagini. Inoltre dovrà essere garantita l’interoperabilità con anagrafiche
esterne all’azienda, quali le anagrafiche sanitarie e quelle regionali. Sarà previsto anche lo scambio
sicuro dei dati certificati da enti ufficiali quali ad esempio il MEF
sicuro: sarà assicurata la storicizzazione delle informazioni per consentire la visione cronologica
delle modifiche e dovrà essere conforme alla normativa vigente in materia di trattamento di dati
personali e sensibili (Dlgs 196/2003 e Provvedimento del Garante della Privacy per gli
amministratori di sistema 28 novembre 2008).
Nella prima fase deve essere implementata l'integrazione tra le anagrafiche dei seguenti applicativi:
- applicativo ADT (SilsRad);
- applicativo LIS (Wlab);
- applicativo Erogazione Diretta dei Farmaci (EDF);
- Recup;
- Anagrafica Regionale ASUR/Prescrizioni on line.
Infine il middleware dovrà fornire a tutti gli altri applicativi servizi per la ricerca, l’inserimento,
l’aggiornamento dei dati; prevederà strumenti idonei ad evidenziare e correggere problemi legati ad
esempio alle duplicazioni e consentirà la riconciliazione di due posizioni anagrafiche.
Dovrà essere inoltre fornita una descrizione della architettura hardware necessaria ipotizzando sia una
soluzione minima che una ottimale.