analisi ad alto livello - dipartimento salute, … rete dei medici di medicina generale rs...
TRANSCRIPT
Analisi ad alto livello Pagina 1 di 38
II..TT..BB.. IIssttiittuuttoo ddii TTeeccnnoollooggiiee BBiioommeeddiicchhee
UUnniittàà ddii SSaanniittàà EElleettttrroonniiccaa -- RRoommaa
Mariangela Contenti, Gregorio Mercurio, Gianfranco Misuriello,
Fabrizio L. Ricci, Angelo Rossi Mori, Luca D. Serbanati
Analisi ad alto livello
Sommario
Il Progetto LUMIR, coerentemente con gli obiettivi del Piano Sanitario Nazionale 2003 –
2005 persegue due obiettivi strategici:
Supportare l’efficienza delle cure primarie attraverso l’integrazione in rete dei
professionisti medici e pediatri in forma singola o associata al fine di agevolare i
processi di continuità della cura;
Supportare l’integrazione dei servizi sanitari e sociali nell’ambito del territorio al
fine di agevolare i processi di integrazione tra presidi, distretti e professionisti.
A tal fine, le soluzioni adottate nel Progetto LUMIR si ispirano ai risultati ottenuti
nell’ambito del progetto MobiDis. Tale progetto MobiDis mette al centro delle sue ricerche
lo studio di una nuova architettura di sistemi informativi per ambienti sanitari ed adotta una
prospettiva mirata al paziente (patient-centric paradigm); in particolare, è stata studiata la
gestione dei Fascicoli Sanitari Personali (FaSP) e dei relativi Libretti Sanitari Personali
(LSP) dei cittadini in maniera integrata e consistente.
Questo documento è così strutturato:
Il Capitolo Introduzione ed i successivi paragrafi 1, 2, 3 illustrano il tema trattato, lo scopo
ed il campo di applicazione, indicano la bibliografia di riferimento e gli acronomi e le
definizioni utilizzate.
Il Capitolo 2 riporta lo stato dell’arte ed dell’informatizzazione della Regione Basilicata,
ponendo il focus sui progetti da coinvolgere nell’ambito di LUMIR.
Il Capitolo 3 espone una valutazione del Capitolato Tecnico del Progetto LUMIR alla luce
dell’indagine svolta in Regione e delle evoluzioni avvenute dall’atto di redazione del
programma.
Il Capitolo 4, infine, descrive il disegno architetturale ad alto livello di un sistema
informatico in grado di supportare l’integrazione dei servizi sanitari e sociali nell’ambito
del territorio e in parallelo con una maggiore integrazione dei professionisti nello
svolgimento delle cure primarie.
Analisi ad alto livello Pagina 2 di 38
Indice dei Contenuti
1. Introduzione ...................................................................................................... 3
1.1 Scopo e vincoli 3
1.2 Riferimenti bibliografici 3
1.3 Acronimi e definizioni 4
2. Il sistema informativo sanitario attuale della Regione Basilicata ................ 6
2.1 Sintesi dello stato attuale del sistema informativo sanitario regionale (SISR) 6
2.1.1 Progetti realizzati nell’ambito dell’assistenza sanitaria di base 6
2.1.2 Progetti realizzati nell’ambito dell’assistenza ospedaliera 7
2.2 Progetti di informatizzazione del SISR 9
2.2.1 Progetto RUPAR della Regione Basilicata 9
2.2.2 Progetto BAS-REFER 9
2.2.3 Progetto ICAR 9
2.2.4 Progetto TELEMEDBAS 9
2.2.5 Progetto BASMED 10
2.2.6 Progetto MARNO 10
3. Rivisitazione del Capitolato Tecnico LUMIR .............................................. 11
3.1 Obiettivi di macro-livello 11
3.1.1 Potenziamento degli attuali sistemi tecnologici (OR1) 11
3.1.2 Adeguamento delle componenti software del SISR (OR2) 12
3.1.3 Avvio sperimentale software per i Punti Salute (OR3) 13
3.2 Vincoli applicativi: LUMIR, altri progetti e le applicazioni legacy 14
3.2.1 Applicazioni sanitarie 14
3.2.2 La situazione delle applicazioni sanitarie in Basilicata 14
3.2.3 Componenti software legacy da prendere in considerazione per LUMIR 16
3.2.4 Funzioni applicative legacy da prendere in considerazione per LUMIR 18
3.3 Eredità MobiDis 19
3.3.1 Principi MobiDis 19
3.3.2 Livelli di approfondimento in MobDis 20
3.3.3 Architettura MobiDis 21
4. Il nuovo sistema informativo sanitario della Regione Basilicata ................ 23
4.1 Fascicolo Sanitario Elettronico per la Regione Basilicata 23
4.1.1 Cos’è FSE in LUMIR 23
4.1.2 Infrastruttura FSE 23
4.1.3 Requisiti per l’infrastruttura di comunicazione che supporta FSE 23
4.1.4 Componenti dell’infrastruttura del FSE 24
4.2 Analisi dei requisiti utente per il FSE 25
4.2.1 Contesto del FSE 25
4.2.2 Requisiti per il FSE 26
4.2.3 Principi di progettazione del FSE per LUMIR 27
4.2.4 Separazione ontologica 27
4.2.5 Obiettivi ontologici di LUMIR 27
4.2.6 Documenti CDA 29
4.3 Separazione secondo i punti di vista (viewpoints) 32
4.4 Architettura LUMIR 33
4.5 Diagramma dei componenti del sistema LUMIR 37
Analisi ad alto livello Pagina 3 di 38
1. Introduzione
1.1 Scopo e vincoli
Il presente documento descrive i risultati dell’analisi di alto livello del sistema informativo
riguardante il Progetto LUMIR fornendo in finale una proposta di architettura del sistema
informatico in accordo con gli standard di cooperazione applicativa e con le direttive del
Tavolo della Sanità Elettronica (TSE).
Di conseguenza, il sistema LUMIR sarà facilmente integrabile con il futuro sistema
nazionale che prevede l’interoperabilità di tutti gli operatori sanitari, appunto su scala
nazionale. La progettazione esecutiva verrà presentata in dettaglio in un apposito
documento, successivo a questo.
1.2 Riferimenti bibliografici
1) [LUMIR] Convenzione CNR – Basilicata - “LUMIR” Lucania - Medici in Rete -
Allegato tecnico;
2) [MOBIDIS] Progetto MOBIDIS (http://www.irpps.cnr.it/mobidis/index.php);
3) [TSE] Il Tavolo di lavoro permanente per la Sanità Elettronica
(http://www.sanitaelettronica.gov.it);
4) [BASREFER] Progetto BAS-REFER “Invio delle refertazioni di laboratorio ai medici
di base per via informatica protetta”, P.O.R. Basilicata 2000/2006, Misura VI.2 – Reti
immateriali, ALLEGATO 1 (allegato_1_-_scheda_progetto_bas-refer.doc);
5) [BASREFERWEB] Portale BAS-REFER (http://bas-
refapp.basilicatanet.it/portale/servizio_strumenti.html);
6) [ICAR] Progetto interregionale ICAR “Interoperabilità e Cooperazione Applicativa tra
le Regioni” <Task AP-1> Piano di progetto Versione 1.4
(ICAR_Task_AP1_piano_progetto_V1 4.doc);
7) [ICARWEB] Portale ICAR (http://best.det.unifi.it:9090/icar);
8) [ICARC] Convegno “L’avvio del progetto ICAR. Interoperabilità e cooperazione
applicativa fra le Regioni e le Province autonome” Trento, 18-19 Maggio 2006;
9) [TELEMEDBAS] Progetto TeleMedBas “Servizi di Teleformazione e di telemedicina
Specializzata su rete a larga banda” PROGETTAZIONE ESECUTIVA (progetto
esecutivo TeleMedBas.doc);
10) [ERA] eHealth ERA “Towards the Establishment of a European Research AREA”
D2.3 “Report on Priority Topic Cluster One and recommendations”;
11) [Allegati W1ANR1AA] W1ANRALL;
12) [TSE] TSE-IBSE-Strategia_architetturale-v01.00-DEF.pdf
(http://www.sanitaelettronica.gov.it/xoops/modules/docmanager/index.php?curent_dir=
39).
Analisi ad alto livello Pagina 4 di 38
1.3 Acronimi e definizioni
ADI Assistenza Domiciliare Integrata
ADP Assistenza Domiciliare Protetta
AO Azienda Ospedaliera
ASL Azienda Sanitaria Locale
CA Medico di Continuità Assistenziale
CCV Cartella Clinica Virtuale
CDA HL7 Clinical Document Architecture
CEA Centri Esterni Accreditati
CNS Carta Nazionale Servizi
CTR Centro Tecnico Regionale
CUP Centro Unificato di Prenotazione
EA Enterprise Architecture
EBM Evidence Based Medicine
EHR Electronic Health Record
FaSP Fascicolo Sanitario Personale
FSE Fascicolo Sanitario Elettronico
HL7 Health Level 7
IBIS InfoBroker Individuale Sanitario
IBSE Infrastruttura di Base per la Sanità Elettronica
ICAR Infrastruttura per la Cooperazione Applicativa
Regionale
ICT Information Communication and Technology
IP Internet Protocol
ISDN Integrated Services Digital Network
IBSE Infrastruttura di Base per la Sanità Elettronica
LSP Libretto Sanitario Personale
LUMIR LUcania Medici In Rete
MdS Ministero della Salute
MMG Medici di Medicina Generale
MobiDis Telemedicina tramite telefonia mobile
Analisi ad alto livello Pagina 5 di 38
OMS Organizzazione Mondiale per la Sanità
PLS Pediatri di Libera Scelta
Programma Progetto LUMIR
Progetto Progetto LUMIR
PS Punto Salute
PSN Piano Nazionale Sanitario
P2P Peer to Peer
RIM HL7 Reference Information Model
RMMG Rete dei Medici di Medicina Generale
RS Responsabile Scientifico
RSA Residenza Sanitaria per Anziani
RP Responsabile del Programma
RQ Responsabile dell’Assicurazione di Qualità
RT Responsabile Tecnico del WorkPackage
RUPAR Rete Unitaria della Pubblica Amministrazione
Regionale
SOA Service Oriented Architecture
SPCoop Sistema Pubblico di Cooperazione applicativa
SSN Sistema Sanitario Nazionale
SSR Sistema Sanitario Regionale
SISR Sistema Informativo Sanitario Regionale
UTAP Unità Territoriale di Assistenza Primaria
Analisi ad alto livello Pagina 6 di 38
2. Il sistema informativo sanitario attuale della Regione Basilicata
2.1 Sintesi dello stato attuale del sistema informativo sanitario regionale (SISR)
La Regione Basilicata si estende su una superficie di 9.942 Kmq, è costituita da due
province e da 131 comuni. La popolazione residente è concentrata soprattutto nei centri
urbani (90%), il resto si distribuisce tra nuclei rurali e case sparse. Il 66% della
popolazione risiede nella provincia di Potenza (Fonti ISTAT, Censimento della
popolazione 2001).
Nei servizi territoriali operano 510 Medici di Medicina Generale, 90 Pediatri di Libera
Scelta, 453 Medici di Continuità Assistenziale. Si ha un carico medio di 100 assistiti per
MMG, di 582 assistiti per PLS e vi sono in media 3 CA per comune.
Vi sono 27 distretti sanitari di I livello ed 11 distretti sanitari di II livello.
Nella regione Basilicata tutte le strutture sanitarie sono interconnesse alla RUPAR ed il
posizionamento dei nodi primari e secondari è stato fatto nell’ottica di privilegiare la rete
sanitaria regionale.
La RUPAR nasce nel 1999, è costituita da 16 nodi di cui 11 posizionati in strutture
sanitarie regionali, garantendo in tal modo la connessione a larga banda delle stesse. La
gestione della rete è effettuata direttamente dalla Regione Basilicata per il tramite del
Centro Tecnico Regionale che ha la responsabilità del dominio della Rete.
Relativamente al Sistema Informativo Sanitario Regionale si può affermare che gli
obiettivi raggiunti sono correlati:
Alla realizzazione del Sistema Informativo Sanitario Regionale come insieme degli
applicativi, connessi in rete tra loro, che gestiscono le principali aree sanitarie
(prestazioni specialistiche e farmaceutiche, medicina di base, anagrafe assistiti e
medici, ricoveri ospedalieri,specialistica ambulatoriale, etc.);
Al collegamento telematico di tutte le strutture operanti nell’ambito del Servizio
Sanitario Regionale (ospedali, servizi specialistici, medici di base, etc.);
Alla realizzazione di un sistema di supporto alle decisioni per il governo della spesa
sanitaria, destinato ai dirigenti delle aziende sanitarie ed alla amministrazione
regionale;
Alla creazione di alcuni servizi reali all’utenza delle Aziende Sanitarie e Ospedaliere
fruibili sul portale Basilicatanet.
Si considerano di seguito gli interventi effettuati nell’area dell’assistenza sanitaria di base e
nell’area dell’assistenza ospedaliera. Tali interventi hanno prodotto un miglioramento dei
servizi offerti dalle strutture sanitarie pubbliche adeguando il sistema esistente alle nuove
tecnologie informatiche (basate sulla costituzione di Intranet aziendali) e costruendo nelle
ASL le infrastrutture necessarie per lo sviluppo di servizi telematici per la sanità su scala
Regionale.
2.1.1 Progetti realizzati nell’ambito dell’assistenza sanitaria di base
Attivazione dei Centri Unificati di Prenotazione delle aziende sanitarie locali ed
ospedaliere (CUP Aziendali) per rendere prenotabili, presso le diverse sedi delle
aziende sanitarie dislocate sul territorio regionale, tutte le prestazioni;
Analisi ad alto livello Pagina 7 di 38
Attivazione del Centro Unificato Regionale (CUP Regionale), per l’integrazione dei
CUP Aziendali.
Tale attivazione è finalizzata a garantire l’interoperabilità dei centri di prenotazione delle
ASL e delle aziende ospedaliere ed ancora l’interscambio informativo tra le aziende
sanitarie ed i centri esterni accreditati (CEA) relativamente alle prestazioni ambulatoriali
eseguite presso i medesimi centri e la gestione dell’esenzione dei ticket da parte degli
assistiti.
Attivazione di un Call Center CUP unico a livello regionale per la prenotazione
telefonica delle prestazioni specialistiche, in qualsiasi struttura sanitaria della Regione
erogante le prestazioni richieste dall’assistito.
Sviluppo di un prodotto per la gestione dello Studio Medico di base in grado di fornire
al medico di famiglia il necessario supporto informatico atto a consentirgli da un lato la
completa automazione dello studio e dall’altro l’interazione con le strutture delle
aziende sanitarie regionali in modo da offrire ai propri assistiti alcuni servizi
fondamentali (vedi prenotazioni di visite specialistiche, indagini strumentali, esami di
laboratorio).
Sistema di Controllo di Gestione in grado di supportare i funzionari del Dipartimento
Sicurezza Sociale della Regione e gli amministratori delle aziende sanitarie nelle
decisioni per il governo della spesa sanitaria, sia a livello aziendale che a livello
regionale, con particolare riferimento alla compensazione sanitaria interregionale.
Controllo e monitoraggio della Spesa Farmaceutica convenzionata che, partendo dalla
lettura ottica delle ricette, elabora alcuni indicatori quali-quantitativi a livello
territoriale con comunicazioni periodiche (semestrali) al MMG.
Adeguamento tecnologico e funzionale dei prodotti di gestione dell’Anagrafe Unica
della Popolazione Assistita.
Gestione dei Pagamenti delle Convenzioni di Medicina Generica e Pediatrica.
Gestione della assegnazione e collocazione della Guardia Medica.
2.1.2 Progetti realizzati nell’ambito dell’assistenza ospedaliera
Per l’assistenza ospedaliera nella regione Basilicata sono realizzati i seguenti sistemi:
Sviluppo di un prodotto di controllo della produttività ospedaliera (AIRO) finalizzato a
supportare il management delle aziende ospedaliere nelle attività di programmazione e
controllo degli interventi volti migliorare l’efficienza dell’intera struttura ospedaliera.
Tale sistema, partendo dalla gestione completa del ricovero, delle attività di reparto e delle
attività ambulatoriali, consente di stabilire, misurare controllare, l’efficienza e l’efficacia
complessiva di ciascuna unità operativa ospedaliera e, di conseguenza, dell’intero presidio
ospedaliero.
Attivazione di un sistema di storicizzazione ottica dei dati clinici dell’assistito
(memorizzazione ottica delle cartelle cliniche).
Sviluppo di un prodotto per la gestione delle Sale Chirurgiche (pianificazione degli
interventi, gestione delle attività della sala operatoria, gestione dei farmaci e dei
materiali utilizzati).
Analisi ad alto livello Pagina 8 di 38
Adeguamento funzionale e avvio in esercizio del prodotto di gestione delle Attività di
Reparto (prerequisito essenziale per l’avvio in esercizio del Controllo di Produttività
Ospedaliera).
Sviluppo di un prodotto per la gestione dei Pazienti Dializzati (GEPADIAL).
Sviluppo di un prodotto per la gestione dei Pazienti Cardiopatici (GEPACARD).
In particolare, gli applicativi GEPADIAL (Cartella clinica elettronica per la Divisione di
Nefrologia e Dialisi) e GEPACARD (Cartella clinica elettronica per la Divisione di
Cardiologia) sono stati realizzati utilizzando la tecnologia Microsoft COM e sono
strutturati in componenti ACTIVEX. I dati trattati dalle singole procedure sono
memorizzati su database relazionale Microsoft SQL Server.
GEPADIAL e GEPACARD possono scambiare dati e/o integrarsi con i seguenti software
del Sistema informativo ospedaliero:
Anagrafica unica assistiti;
CUP;
Laboratorio di analisi;
Radiologia;
Altri reparti.
Le integrazioni possono essere realizzate attraverso i seguenti standard e/o metodi:
Tracciato record;
Viste logiche;
HL7;
XML;
Web services.
Analisi ad alto livello Pagina 9 di 38
2.2 Progetti di informatizzazione del SISR
2.2.1 Progetto RUPAR della Regione Basilicata
Dal punto di vista dell’infrastruttura hardware, software e di rete, preposta all’erogazione
dei servizi informatici a livello regionale, il progetto RUPAR varato dalla Regione
Basilicata, assicura attualmente l’interconnessione a larga banda di tutte le ASL e di tutte
le strutture ospedaliere. Queste, infatti, rappresentano i nodi primari o secondari del
sistema.
Associato al sistema di rete, il sistema hardware gode di caratteristiche analoghe, in quanto
ciascun nodo regionale presenta dotazioni Server parzialmente adeguate a supportare le
funzionalità applicative, ma comunque esistenti e in evoluzione.
2.2.2 Progetto BAS-REFER
Il Progetto BAS-REFER gestisce i principali flussi operativi che permettono la creazione
dei referti firmati e i loro invio al sistema centrale, per essere messi a disposizione dei
MMG/PLS, dei cittadini e degli operatori autorizzati. Il medico potrà visualizzare la lista
degli eventi clinici riconducibili alla produzione di referti di un proprio assistito solo ed
esclusivamente previa autorizzazione dello stesso tramite delega da esplicitare in un
apposita sezione del portale Basilicata.Net (rif. [BASREFERWEB]).
2.2.3 Progetto ICAR
ICAR è un progetto interregionale a cui hanno aderito 16 Regioni e la Provincia Autonoma
di Trento. L’importo complessivo del progetto interregionale è di circa 30 milioni di euro
(fondi UMTS - DPCM 14.02.02) e la durata è di 36 mesi. L’obiettivo del progetto è quello
di definire e realizzare un’infrastruttura di base e alcuni relativi servizi infrastrutturali al
fine di permettere la cooperazione applicativa a livello interregionale.
Il progetto ICAR si articola in un insieme di interventi progettuali paralleli, tra loro
coordinati ed integrati che le Regioni intendono cooperativamente attuare. Vi sono due
tipologie di interventi: interventi infrastrutturali di base (INF) e interventi per lo sviluppo
di casi studio applicativi (AP) (rif. [ICARC]).
2.2.4 Progetto TELEMEDBAS
Il progetto ha l’obiettivo di potenziare la comunicazione tra i presidi sanitari regionali e
collegarli ai Centri di Eccellenza Clinica (IRCCS), realizzando una rete formativa e
informativa permanente di alto livello in medicina e sanità, basata sul teleconsulto
specialistico, che utilizzi servizi di e-learning e videoconferenza, e che sfrutti l’accesso ai
dati clinico-amministrativi del paziente (rif. [TELEMEDBAS]).
Dal punto di vista del trasferimento dei dati, l’intervento sfrutta il potenziamento
dell’infrastruttura di rete regionale, che verrà ottenuto dall’aggiudicazione dell’appalto
concorso per la continuazione, l’ampliamento e l’innovazione dei servizi di connettività
della RUPAR e dei relativi servizi di base.
Per la realizzazione dell’intervento progettuale si prevede, in accordo con quanto previsto
nella scheda di cui al primo integrativo all’APQ-SI Basilicata (Accordo Programma
Quadro – Società dell’Informazione), la progettazione, l’acquisizione, l’implementazione e
Analisi ad alto livello Pagina 10 di 38
configurazione, nonché la messa a regime dei seguenti servizi e sistemi di trasferimento in
relazione con gli obiettivi prefissati:
Estensione e potenziamento della larga banda per le strutture Ospedaliere e
collegamento alla rete GARR;
Realizzazione di formazione permanente di alto livello in medicina e sanità e di un
network per il teleconsulto specialistico.
2.2.5 Progetto BASMED
Il progetto ha l’obiettivo di supportare la cooperazione tra MMG e per la gestione dello
Studio Medico di base, ed è in grado di fornire al medico di famiglia il necessario supporto
informatico atto a consentirgli da un lato la completa automazione dello studio e dall’altro
l’interazione con gli altri MMG in base a determinati percorsi/protocolli clinici.
2.2.6 Progetto MARNO
Attraverso il sistema software MARNO, la Regione Basilicata svolge le attività di
informatizzazione delle ricette farmaceutiche per la gestione del servizio di raccolta dei
dati delle ricette a fini statistici e di controllo della spesa farmaceutica.
Il servizio di rilevazione e trattamento dei dati dalle ricette farmaceutiche ha due finalità
fondamentali:
Verificare la congruità di quanto corrisposto alle farmacie convenzionate e se queste
hanno rispettato le norme vigenti nella spedizione di ricette contenenti prescrizioni di
medicinali la cui spesa è a carico del Servizio Sanitario;
Elaborare statistiche sui consumi e sulla spesa farmaceutica, in riferimento alla
tipologia dei farmaci, agli ambiti territoriali, alle caratteristiche degli assistiti, ai
comportamenti prescrittivi dei medici, anche in relazione a livelli di spesa prefissati, ad
indici prescrittivi standardizzati, all’appropriatezza delle prescrizioni, alle interazioni,
alle possibili correlazioni epidemiologiche dei consumi farmaceutici.
Alla rilevazione e trattamento dei dati dalle ricette farmaceutiche sono connesse altre
funzioni, come il trasporto delle ricette, la loro obliterazione, il loro inscatolamento, la loro
archiviazione ottica (immagini digitali delle ricette), la loro custodia per cinque anni e lo
smaltimento finale.
Analisi ad alto livello Pagina 11 di 38
3. Rivisitazione del Capitolato Tecnico LUMIR
3.1 Obiettivi di macro-livello
Il Progetto LUMIR si innesta nel contesto del progetto nazionale RMMG “Rete dei Medici
di Medicina Generale” e persegue lo scopo del completamento e del potenziamento
dell’interconnessione logica esistente per consentire:
A. Un’effettiva comunicazione e condivisione delle informazioni tra vari utenti;
B. L’accesso ai dati trattati dal proprio sistema informativo, anche attraverso LUMIR;
C. L’integrazione dello stesso nell’ambito del Sistema Informativo Sanitario Regionale,
tra tutti i soggetti e le strutture sanitarie che operano nell’ambito dell’assistenza
sanitaria primaria della Regione;
D. L’avvio sperimentale dei modelli organizzativi Punti di Salute, sul territorio regionale.
Dal punto di vista prettamente implementativo, LUMIR prevede i seguenti interventi, con
componenti software preferibilmente open source, a supporto del nuovo modello
organizzativo in sperimentazione (i.e. Punto Salute), coerentemente alle politiche e linee
guida del Tavolo permanente per la Sanità Elettronica:
Ob. Descrizione Componenti software
OR1 Potenziamento degli attuali sistemi tecnologici ed
informativi dei MMG e degli altri operatori, per
consentire l’effettiva comunicazione e condivisione
delle informazioni
IBIS Regione Basilicata
Rete di Repository
FSE (Componente CCV-Mobidis)
Libretto Sanitario Personale (LSP)
OR2 Adeguamento delle componenti software del
Sistema Informativo Sanitario Regionale afferenti ai
livelli di assistenza territoriale ed ospedaliera, ai
sistemi di monitoraggio delle prescrizioni ed al
sistema di EHR Regionale, per consentire la loro
integrazione con i sistemi informativi del MMG
Componenti di Integrazione
(wrapper) allineati ai Template HL7
CDA
OR3 Avvio sperimentale di software progettato per i
Punti Salute in almeno 5 punti sul territorio
regionale
LSP per Pediatria e/o 1-2 malattie
croniche (e.g. Diabetologia e
Cardiologia)
3.1.1 Potenziamento degli attuali sistemi tecnologici (OR1)
Questo intervento da parte della Regione Basilicata ha lo scopo di effettuare di
perfezionare gli attuali sistemi tecnologici ed informativi dei MMG/PLS per consentire
l’interoperabilità tra vari attori coinvolti, con l’effettiva comunicazione e condivisione
delle informazioni e con l’integrazione dei servizi applicativi della rete MMG/PLS nel
contesto di un Sistema Informativo Sanitario Regionale integrato. In questo senso
l’intervento prevede:
La connessione dei MMG/PLS al sistema di videoconferenza ed al network per il
teleconsulto specialistico, al servizio degli operatori sanitari del territorio regionale
Analisi ad alto livello Pagina 12 di 38
previsto dal progetto di telemedicina TeleMedBas (già in corso su altri progetti, e
quindi non previsto in LUMIR);
L’accesso ai servizi di formazione specifica per MMG/PLS, per il tramite del portale di
e-learning regionale (già in corso su altri progetti, e quindi non previsto in LUMIR);
Il potenziamento dei servizi dedicati ai MMG/PLS sul portale Basilicata.Net, con
accesso tramite certificato digitale (già in corso su altri progetti, e quindi non previsto
in LUMIR);
L’automazione completa dei flussi informativi tra Regione, ASL, Ospedali e
MMG/PLS con utilizzo diffuso della firma digitale (già in corso su altri progetti, e
quindi non previsto in LUMIR);
La definizione di regole standard per la produzione dei dati a partire dagli sistemi
applicativi dei MMG/PLS (applicativi “ad hoc” o interoperabilità degli esistenti), al
fine di consentire la condivisione delle informazioni tra MMG/PLS rendendo
sostituibili tra loro i MMG/PLS nei confronti del cittadino assistito nello scopo di avere
una copertura maggiore di assistenza sanitaria (attività prevista in LUMIR);
La definizione ed implementazione delle componenti chiave della infrastruttura FSE,
ovvero l’IBIS regionale costituita da registri (i.e. Indice degli Eventi), repository ,
AccesGateway per il routing dei messaggi, e il middleware dei servizi comuni (attività
prevista in LUMIR);
La definizione ed implementazione della componente FSE (ovvero CCV in accezione
Mobidis) (attività prevista in LUMIR);
La definizione ed implementazione del front-end del FSE cioè delle componenti che
forniscono varie viste sul FSE (attività prevista in LUMIR).
3.1.2 Adeguamento delle componenti software del SISR (OR2)
Questo intervento prevede l’adeguamento dei sistemi applicativi attuali o in corso di
realizzazione del SISR per renderli interoperabili nel sistema integrato.
A partire dai progetti in corso di realizzazione nella Regione relativamente ai sistemi di
cooperazione applicativa ed all’integrazione della RUPAR Basilicata in linea con le regole
tecniche condivise a livello nazionale, vengono adeguati gli attuali componenti software
dei SISR per consentire l’integrazione con i sistemi informativi dei MMG/PLS.
Ciò consentirà l’integrazione dei MMG/PLS e dei Punti Salute con il territorio e con
l’ospedale/ASL consentendo la condivisione delle informazioni tra tutti i soggetti coinvolti
a vario titolo nell’erogazione dei servizi sanitari al cittadino assistito.
L’intervento prevede:
Implementazione delle funzioni applicative di CUP, Refertazione, ADI, etc. (già in
corso su altri progetti, e quindi non previsto in LUMIR);
Integrazione al livello applicativo di alcuni sistemi applicativi esistenti utilizzati dai
vari attori nel ambito del SISR con particolare riferimento all’applicativo per la
continuità assistenziale; l’attività verrà realizzato attraverso apposite componenti
software (wrapper) che da un lato integrano le funzionalità già disponibili di tipo
RMMG (e.g. prenotazione online, prescrizione, etc.) e ne fornisce altre specifiche per
Analisi ad alto livello Pagina 13 di 38
la nuova forma di assistenza (e.g. gestione integrata ADI, etc.) e dall’altro lato utilizza
come collante il middleware e FSE previste da OR1 (attività prevista in LUMIR);
La definizione di regole standard per la produzione dei dati, a partire dagli applicativi
SISR, al fine di consentire la condivisione delle informazioni tra operatori (attività
prevista in LUMIR).
3.1.3 Avvio sperimentale software per i Punti Salute (OR3)
L’intervento per il Punto Salute prevede:
Con riferimento alla sperimentazione del Punto Salute di S. Gervaso avviata nella ASL
N° 1 di Venosa, l’avvio, da parte della Regione, con gradualità di altri PS nelle ASL
del proprio territorio (attività non prevista in LUMIR);
La definizione del modello organizzativo funzionale del PS e l’eventuale attivazione di
uno specifico sistema informativo atto alle esigenze di tali strutture così progettate,
completamente integrato nella rete sanitaria regionale (attività prevista in LUMIR);
Gli aspetti sanitari riguarderanno in prima battuta il completamento del follow-up della
prima infanzia, e si analizzerà la possibilità di estendere i risultati ad altre patologie
come, ad esempio, lo scompenso cardiaco (attività prevista in LUMIR);
In particolare, si prevede la realizzazione del Libretto Sanitario Elettronico per la
gestione sanitaria condivisa (scegliendo tra Libretto Pediatrico, Libretto Geriatrico,
etc.), ossia l’estensione open source del progetto MOBIDIS (attività prevista in
LUMIR).
Analisi ad alto livello Pagina 14 di 38
3.2 Vincoli applicativi: LUMIR, altri progetti e le applicazioni legacy
3.2.1 Applicazioni sanitarie
Nella Figura 1 è rappresentato il quadro riepilogativo dei processi di interazione tra vari
sistemi applicativi che hanno un impatto diretto sul circuito di assistenza sanitaria
Assistito, Medico di Base, Struttura Sanitaria e Regione, e quindi che risultano d’interesse
per il Progetto LUMIR.
Servizi
Refertazione
Laboratorio
Reparto
Accesso
Utente
Pronto
Soccorso
CUP
ADT(Accettazione)
Gestore
Repository
Amministrativo
Gestore
Repository
Clinico
Fascicolo clinico
ADT(Dimissione /
Trasferimento)
Repository
Clinico
Cassa
Repository
Amministrativo
Sistema di
reporting
Figura 1: Quadro riepilogativo dei processi di interazione
Il circuito informativo dovrebbe essere completato con l’integrazione al sistema dei Centri
Esterni Accreditati, al sistema di gestione dell’Assistenza Domiciliare, al sistema
Vaccinale, al sistema di Gestione della Protesica e a quello di rilevazione delle Prescrizioni
Farmaceutiche (circuito MARNO).
Si sottolinea che il repository di raccolta dei dati clinico-amministrativi è l’elemento
centrale che raccoglie le informazioni provenienti dai sistemi verticali e le offre secondo
logiche differenziate in base al profilo d’uso e di accesso (controllo di gestione e
contabilità analitica/generale, epidemiologia e verifica dei livelli di cura e appropriatezza,
indagine epidemiologica, etc.).
3.2.2 La situazione delle applicazioni sanitarie in Basilicata
Oltre al Progetto LUMIR (RMMG in Basilicata), in Regione Basilicata sono attive e
previste altre iniziative nel settore dell’informatica medica (BAS-REFER, CUP,
Analisi ad alto livello Pagina 15 di 38
BASITEL, etc.). Con tali iniziative il Progetto LUMIR si confronterà per creare un unico
ambiente favorevole alla sanità elettronica in Basilicata.
Dal punto di vista dell’infrastruttura hardware, software e di rete, preposta all’erogazione
dei servizi informatici a livello regionale, il sistema RUPAR assicura attualmente
l’interconnessione a larga banda di tutte le ASL e le strutture ospedaliere. Associato al
sistema di rete, il sistema hardware è caratterizzato da nodi principali dislocati presso
ciascuna struttura sanitaria, inoltre ciascun nodo regionale presenta dotazioni Server
adeguate a supportare le funzionalità applicative verticali. Sono in corso inoltre attività di
ricognizione e di verifica dello stato di adeguatezza delle strutture che verranno potenziate,
in virtù di un piano di omogeneizzazione e di uniforme riorganizzazione dei Server sia dal
punto di vista architetturale che da quello dell’efficienza e delle risorse.
Le applicazioni che vengono utilizzate a livello centrale dipartimentale e periferico (cioè
presso le AO ed ASL) seguono anch’esse una logica territoriale e di rete. Ciò è reso
possibile grazie all’impianto contrattuale adottato nella maggior parte dei contesti di
fornitura, che prevede un rapporto convenzionato tra società produttrici e il dipartimento, il
quale a sua volta si fa carico di coprire le esigenze informative delle strutture sanitarie.
Ciò offre diversi vantaggi, tra cui principalmente una uniformità sinergica tra le funzioni
applicative ed un maggiore controllo della spesa (sia perché direttamente scalata su
economie pluri-ente, sia perchè gestita da una entità univoca).
Si elencano, di seguito, i principali sistemi applicativi (associati all’ambito funzionale
coperto) che rispondono attualmente a tale situazione contrattuale:
CUP (Centro Unico di Prenotazione delle prestazioni specialistiche);
AIRO (sistema di gestione dell’Accettazione e Dimissione Ospedaliera, Pronto
Soccorso, Ricoveri e Refertazione);
Anagrafe Sanitaria;
CEA (sistema di gestione dei Centri Esterni Accreditati);
Controllo di Gestione e di Produttività Ospedaliera;
Gestione degli Invalidi Civili;
Protesica;
BASMED (sistema per la gestione degli studi medici di MMG).
Altre applicazioni rientrano in una analoga gestione territoriale (per ragioni che le hanno
viste nascere contrattualmente in modo omogeneo rispetto alle varie aziende sanitarie),
come ad esempio l’ADI (sistema per la gestione dell’assistenza domiciliare in corso di
sperimentazione presso 3 ASL regionali), le applicazioni ospedaliere di Contabilità e
Magazzino Farmacia, ed altre.
Analisi ad alto livello Pagina 16 di 38
3.2.3 Componenti software legacy da prendere in considerazione per LUMIR
Grazie ai progetti in corso di seguito descritti, sono presenti i seguenti elementi
fondamentali per la progettazione del programma LUMIR:
Componente Collocazione Descrizione
C01 Anagrafica Unica
degli Assistiti
CTR Allineata giornalmente con le anagrafiche
dipartimentali; tale base dati anagrafica
centralizzata, è carente per quanto riguarda la
correttezza e completezza del dato; per questo
motivo, la Regione è impegnata a creare sul
portale Basilicata.Net una seziona di registrazione
per utenti BASREFER, nella quale presentare i
dati in possesso della Regione, ed eventualmente
dare la possibilità all’utente di inviare
comunicazione di variazioni o di completamento
dei propri dati
C02 Anagrafica dei
MMG/PLS
CTR Per la corretta identificazione ed autenticazione del
medico
C03 Repository dei
Referti firmati
CTR Memorizza i referti firmati, ottenuti principalmente
dai Laboratori e il Pronto Soccorso
C04 Indice Centrale CTR Contiene i metadata e i riferimenti ai referti
laddove sono memorizzati.
C05 CUP Regionale Regione
Basilicata
Il Centro Unico di Prenotazione fornisce all’Indice
Centrale BASREFER i dati di sintesi relativi ad
una prenotazione, senza la necessità di firmare
digitalmente alcun documento
C06 Basedati Deleghe CTR Il cittadino/medico può richiedere di ricevere via
email una notifica di “referto pronto”, presso la
propria casella di posta elettronica; i cittadini
eventualmente desiderano dare ai propri medici
tale opzione
C07 FirmaDocumentX Laboratori,
Pronto
Soccorso
Permette l’apposizione della firma digitale su un
qualsiasi documento elettronico
C08 InvioDocumentoX Laboratori,
Pronto
Soccorso
Permette l’inoltro del documento precedentemente
firmato con FirmaDocumentoX al sistema centrale
C09 Repository di
raccolta dei Dati
Clinico-
Amministrativi
CTR Elemento centrale che raccoglie le informazioni
provenienti dai sistemi verticali SISR e le offre
secondo logiche differenziate in base al profilo
d’uso e di accesso
Analisi ad alto livello Pagina 17 di 38
Componente Collocazione Descrizione
C10 ICAR
Identificazione
Assistito
CTR Utilizzo in rete di funzioni di cooperazione
applicativa per effettuare il riconoscimento
anagrafico degli utenti iscritti in una qualsiasi
Azienda Sanitaria del territorio nazionale
C11 ICAR Mobilità
Sanitaria
CTR Comunicazione, a livello interregionale, degli eventi
riguardanti prestazioni e ricoveri per gli assistiti delle
aziende sanitarie al fine di consentire il monitoraggio
costante dei livelli di mobilità sanitaria ed effettuare
tempestivamente le compensazioni sanitarie
interregionali di carattere finanziario
C12 ICAR
Informativa per
i Medici di Base
CTR Comunicazione, a livello interregionale, per
MMG/PLS, delle informazioni riguardanti i Ricoveri
e le Dimissioni dei propri assistiti
C13 ICAR Accesso
ai dati Clinico-
Amministrativi
CTR Possibilità di accesso, a livello interregionale, da
parte di personale medico autorizzato, ai dati
Clinico-Amministrativi di un utente ricoverato
appartenente ad altra azienda sanitaria
Nell’ambito della sperimentazione dei sistemi software sviluppati nel progetto LUMIR
alcuni componenti legacy descritti saranno coinvolti.
La scelta dei sistemi da coinvolgere sarà presa durante lo svolgimento del progetto in
accordo con la Regione e secondo gli interessi emersi.
Analisi ad alto livello Pagina 18 di 38
3.2.4 Funzioni applicative legacy da prendere in considerazione per LUMIR
Funzione Collocazione Descrizione
F01 CUP Centrale CTR Centro Unico di Prenotazione delle prestazioni
specialistiche
F02 CUP Periferico ASL, AO Centro Unico di Prenotazione delle prestazioni
specialistiche
F03 AIRO CTR Sistema di gestione dell’Accettazione e Dimissione
Ospedaliera
F04 AIRO CTR Sistema di gestione del Pronto Soccorso
F05 AIRO CTR Sistema di gestione dei Ricoveri
F06 AIRO CTR Sistema di gestione della Refertazione
F07 Anagrafiche CTR Anagrafe sanitaria
F08 CEA CTR Sistema di gestione dei Centri Esterni Accreditati
F09 IC CTR Gestione degli Invalidi Civili
F10 Protesica CTR Protesica
F11 BASMED CTR Sistema per la gestione degli studi medici di MMG
Nell’ambito della sperimentazione dei sistemi software sviluppati nel progetto LUMIR
alcune funzioni applicative legacy descritte saranno coinvolte.
La scelta dei sistemi da coinvolgere sarà presa durante lo svolgimento del progetto in
accordo con la Regione e secondo gli interessi emersi.
Analisi ad alto livello Pagina 19 di 38
3.3 Eredità MobiDis
3.3.1 Principi MobiDis
Il sistema MobiDis (rif. [MOBIDIS]) segue i seguenti principi derivati dalle particolarità
del settore che si vuole informatizzare e dai requisiti dei sistemi business in genere. Questi
principi sono pienamente condivisibili per il progetto LUMIR:
1. Centralità del paziente: il sistema viene sviluppato intorno al concetto di cartella
clinica virtuale associata a ciascun cittadino/paziente registrato nel sistema. Altri
sistemi informativi per la sanità enfatizzano altri aspetti come: l’organizzazione, l’area
territoriale o le malattie.
2. Molteplicità di viste sui dati memorizzati nel sistema: consumatori e fornitori di
servizi sanitarie possono accedere ai dati in modo personalizzato secondo il contesto di
cura in cui si trovano. Per ciascun utente, secondo le sue necessità e il suo scopo di
accesso, il sistema permette un accesso limitato ai dati offrendo all’utente:
a. i dati da lui richiesti,
b. in un formato da lui sollecitato,
c. secondo le possibilità di visualizzazione del suo display,
d. quando lui li vuole.
3. Valore aggiunto per i fornitori di cura: il sistema deve fornire ai fornitori di cura
informazioni aggiuntive e quanto possibile complete, conoscenze necessarie per tutte le
attività critiche svolte dal fornitore.
4. Informazioni accurate e appropriate: tutti gli agenti coinvolti in attività di cura
debbono avere dal sistema solo informazioni accurate, aggiornate e fornite al momento
giusto.
5. Interoperabilità e integrazione: il sistema coesisterà con sistemi legacy con cui deve
cooperare per sempre o magari per un periodo limitato di tempo; l’architettura del
sistema deve permettere facile integrazione con tali sistema.
6. Standardizzazione: il sistema MobiDis deve essere allineato con tutti gli standard
riconosciuti nei campi sanitario e informatico; questi standard sono importanti per gli
scambi di informazione tra i vari componenti del sistema, ma soprattutto per gli scambi
tra il sistema ed altri sistemi.
7. Riutilizzabilità: l’architettura del sistema MobiDis deve contenere componenti
facilmente riutilizzabili a tutti i livelli: dai pattern di supporto alla cura fino ai pattern
nella tecnologia informatica.
8. Adattabilità: il sistema deve permettere l’adattamento a vari situazioni e a vari
contesti. La variabilità delle situazioni riguarda strategie di pianificazione, prestazioni
obbligatori e quelle opzionali, risorse, obiettivi del business etc.; la variabilità dei
contesti riguarda contesti in cui opererà il sistema (locali, regionali etc.), numero di
nodi nell’infrastruttura informatica, numero di utenti, numero di transazioni concorrenti
etc..
9. Estendibilità per sviluppi futuri: il sistema MobiDis deve essere progettato per
affrontare le esigenze esistente oggi nel mondo della sanità, ma dovrebbe essere aperto
per integrare esigenze future in un dominio cosi dinamico come è la sanità.
Analisi ad alto livello Pagina 20 di 38
10. Sicurezza e privacy: un sistema come MobiDis crea per individui comuni un nuovo
tipo di accesso alla sanità; questo accesso impone un approccio speciale per le politiche
di sicurezza e privacy delle informazioni. L’operatività del sistema è basata sul
consento dei consumatori e dei fornitori di cura.
11. Apertura a nuove tecnologie: una caratteristica importante nel progetto MobiDis è la
varietà dei dispositivi di accesso al sistema. Questi dispositivi sono sottoposti ad un
continuo rinnovamento tecnologico, potendo diventare realtà nuovi paradigmi; il
sistema deve affrontare questa sfida ed essere pronto al connettersi con nuovi
dispositivi sempre più sofisticati e miniaturizzati.
3.3.2 Livelli di approfondimento in MobDis
Il progetto MOBIDIS ha analizzato, progettato e sperimentato un sistema per garantire agli
attori di una cosiddetta Struttura Sanitaria Virtuale (gli operatori sanitari autorizzati e il
paziente) l’accesso ad una quantità “appropriata” di dati clinici sul paziente, tenuti
costantemente aggiornati.
L’utente, una volta autorizzato, ha difatti a disposizione tre livelli di approfondimento:
A) una sintesi dello stato clinico del paziente, costantemente aggiornata, sotto il
controllo del medico di fiducia del paziente
Questo livello è estremamente utile ed efficace, e copre la maggior parte dei bisogni
ordinari di accesso all’informazione clinica.
Si ritiene, infatti, che un operatore sanitario remoto, sia alla prima visita che in caso di
cooperazione con altri operatori, debba poter disporre di una sintesi controllata dello stato
del paziente, facilmente e rapidamente consultabile, anche tramite terminale mobile, in
modo da poter affrontare le emergenze (si pensi al Pronto Soccorso) e comunque avere
immediatamente un quadro complessivo del paziente stesso.
In tale ambito, dovrebbero essere forniti anche tutti i dati relativi ai trattamenti
farmacologici seguiti e tutte le informazioni riguardanti le incompatibilità e le allergie del
paziente rispetto ai principi attivi.
B) un insieme di pagine riassuntive di tutti gli ultimi incontri del paziente con le
strutture sanitarie
Quando lo ritiene necessario, l’operatore può successivamente accedere in modo mirato ad
informazioni più dettagliate, guidato sia dal quadro generale ricevuto che dalla visita in
corso.
C) i dati originali esportati dalle cartelle cliniche delle varie strutture sanitarie
coinvolte
A questo scopo viene prevista una “cartella clinica virtuale”, che mette in “linea” tutte le
informazioni cliniche fornite dalle cartelle cliniche disponibili in formato elettronico in
diversi sistemi locali, con opportune trasformazioni per ovviare alla diversità di formati e
contenuti che non permettono una facile integrazione.
La configurazione del sistema permette alla Struttura Sanitaria Virtuale di evolvere verso
forme più complesse, ad esempio con l’uso di messaggistica standard tra sistemi
informativi clinici strutturati, basate su un ampio dizionario dati condiviso.
La semplicità d’uso e il basso grado di accoppiamento tra i sistemi locali esistenti sono un
fattore che faciliterà la penetrazione di questo sistema e la sua evoluzione graduale.
Analisi ad alto livello Pagina 21 di 38
Nella Figura 2 sono evidenziati i tre modi suddetti con cui l’utente accede alle
informazioni cliniche personali dell’assistibile:
Figura 2: Accesso alle informazioni cliniche personali
Tramite le pagine Web residenti nel Server Primario, passate attraverso il vaglio del
MMG (informazioni approvate, importate e amalgamate nella propria cartella, e quindi
estratte secondo criteri uniformi);
Tramite pagine Web estratte in modo uniforme dalle cartelle cliniche originali, e
predisposte in un Server di Appoggio;
Tramite accesso diretto alle pagine Web ottenute per trasformazione delle cartella
cliniche originali, attraverso la Cartella Clinica Virtuale, residenti nei sistemi
informativi locali.
3.3.3 Architettura MobiDis
Il sistema MobiDis è inserito nel suo ambiente costituito dal Sistema Sanitario Nazionale o
una parte del SSN, cosi come viene presentato nella Figura 3. Questo diagramma introduce
il modello architetturale del sistema da realizzare. Il modello descrive il sistema MobiDis
con una vista del più alto livello, identificando le componenti principali che partecipano
alla creazione e gestione della cartella clinica virtuale (CCV).
Pagine XML stand-by
Esami diagnostici e altri documenti
Estratto sull’incontro in XML
Cartella clinica MMG
Catalogazione, notifica
Estrazione
Sintesi stato corrente paziente in XML
Pagine web
Data sets per MMG
Data sets essenziali
secondo problema e contesto
MMG
legge pagina
marca pagina con “ignora”
importa
dati
allega pagina
Cartelle cliniche ospedaliere
Cartelle cliniche specialistiche
Maschere ad hoc tramite web
Estrazione
SERVER DI APPOGGIOSERVER DI APPOGGIO
SERVER PRIMARIOSERVER PRIMARIO
Adattamento
Stili XSL parametrici
Profilo utenteContesto della richiesta
Adattamento
Stili XSL parametrici
Contesto della richiesta
Profilo utente
Catalogazione
Pagine XML attive
ACCESSOACCESSO
DIRETTODIRETTO
Pagine web
Adattamento Stili XSL parametrici
Contesto della richiesta
Profilo utente
Esporta in XML
Pagine XML
DATI ORIGINALIDATI ORIGINALI
Dizionario dati esteso
Analisi ad alto livello Pagina 22 di 38
Figura 3: Architettura MobiDis
Il modello è organizzato in strati di componenti. La localizzazione geografica e il criterio
funzionale hanno contribuito alle decisioni di collocare i componenti in uno o l’altro degli
strati. In questo modello di integrazione del sistema MobiDis con sistemi già esistenti, tutte
le applicazioni accedono al sistema utilizzando il bus di comunicazione e attraverso
messaggi HL7. Il bus di comunicazione diventa l’unico punto di accesso nel sistema. Con i
suoi servizi comuni, il sistema MobiDis intercetta i messaggi scambiati con le applicazioni
e provvede l’inserimento di tutti i servizi necessari (conversioni di formato, verifica di
autorizzazioni, normalizzazione etc.). I registri e i repository di dominio utilizzano lo
stesso canale di comunicazione e gli stessi servizi, cioè la stessa infrastruttura software.
Servizi di registri
Cartella Clinica Virtuale
Registri Repository di dominio
Applicazioni legacy
Servizi comuni
Bus di comunicazione
Applicazioni ad hoc
MobiDis
Servizi della CCV Servizi di repository
Servizi di integrazione
Analisi ad alto livello Pagina 23 di 38
4. Il nuovo sistema informativo sanitario della Regione Basilicata
4.1 Fascicolo Sanitario Elettronico per la Regione Basilicata
4.1.1 Cos’è FSE in LUMIR
Il cuore dell’architettura della Rete di Medici di Medicina Generale della Regione
Basilicata è il Fascicolo Sanitario Elettronico (FSE) dove vengono raccolti informazioni
sugli eventi sanitari del cittadino/paziente dalla sua nascita, mano a mano che vengono
generati. Il FSE non è un semplice raccoglitore di dati ma è un’entità virtuale fornitrice di
un insieme di servizi accessibili a tutti quelli interessati e che hanno diritti di accesso a
questi servizi. I servizi servono non solo per visualizzare i dati gestiti dall’entità virtuale,
ma anche di alimentare la stessa entità con informazioni aggiornate attraverso flussi di dati
provenienti dalle applicazioni locali o regionali abilitate per comunicare con FSE. In
questa accezione FSE si allinea ad un concetto largamente utilizzato, quello di “Electronic
Health Record” (EHR).
Nell’accezione LUMIR, FSE non è la memoria dei dati operativi e non sarà mai una fonte
di nuovi dati. FSE fornisce ad ogni cittadino una registrazione storica dei principali eventi
sanitari verificati nell’ambito del sistema sanitario. La registrazione è disponibile in
formato elettronico ovunque ed in qualsiasi momento a tutti coloro che hanno diritto di
accesso al fine di garantire un’integrazione socio-sanitaria nell’assistenza del cittadino.
Il FSE di un cittadino sarà acceduto in vari contesti di cura da vari attori. FSE deve essere
in grado di fornire viste personalizzate sui dati del cittadino secondo le necessità e gli
obiettivi di ciascun utente. In una vista, la personalizzazione deve fornire i dati desiderati,
nel formato desiderato, al momento desiderato, con informazioni sul contesto dello
scenario di cura corrente e informazioni riguardanti le eventuale scelte da prendere da parte
dell’utente. Alcune volte la vista personalizzata può essere “incarnata” in un libretto
sanitario specializzato per i pazienti stessi. In questi casi il libretto può usufruire
dall’appoggio di una base di conoscenze specifiche per la tipologia del libretto.
4.1.2 Infrastruttura FSE
Nella rete RMMG, FSE non è l’unica applicazione, ma deve convivere con altre
applicazioni che sono produttori o consumatori di informazioni interscambiate con FSE. In
una tale rete FSE deve essere indipendente da altre applicazioni per lasciarle evolvere
liberamente una da altra e dall’architettura stessa.
La soluzione del problema è il disaccoppiamento tra le applicazioni, FSE incluso. Questo
disaccoppiamento può essere realizzato attraverso una infrastruttura di comunicazioni tra
vari applicazioni che implementa un meccanismo di routing tra produttori e consumatori di
informazioni, entità paritetiche in una architettura orientata ai servizi. Il Tavolo per la
Sanità Elettronica ha chiamato questa infrastruttura IBSE (Infrastruttura di Base della
Sanità Elettronica).
L’infrastruttura del FSE contiene componenti altamente riutilizzabili che fungono da
supporto alle applicazioni di gestione dei dati sanitari. Essa consiste da soluzioni software,
definizioni di dati e standard di messaggistica necessarie al FSE.
4.1.3 Requisiti per l’infrastruttura di comunicazione che supporta FSE
I principali requisiti adottati per l’infrastruttura IBSE in vista della progettazione del FSE
sono i seguenti (rif. [TSE]):
Analisi ad alto livello Pagina 24 di 38
L’infrastruttura deve rendere disponibili le informazioni cliniche dell’assistito (la sua
storia clinica) dove e quando queste informazioni sono clinicamente utili;
L’architettura complessiva dell’infrastruttura deve essere federata e in linea con le
moderne architetture tecnologiche e con la cooperazione applicativa prevista dal
Sistema Pubblico di Connettività e Cooperazione (SPCoop) e recentemente dal
protocollo ICAR (Interoperabilità e Cooperazione Applicativa tra le Regioni);
L’infrastruttura deve avere un grado di prestazioni elevato in termini di sicurezza e
rispetto della privacy e basarsi su un profilo condiviso di sicurezza sia tecnologica che
organizzativa;
L’infrastruttura deve essere intrinsecamente affidabile e deve avere una disponibilità
24x7 (ossia 24 ore al giorno, ogni giorno della settimana);
L’infrastruttura deve essere pensata in maniera modulare per evitare una rapida
obsolescenza del sistema;
L’infrastruttura deve avere la minima invasività possibile rispetto ai sistemi esistenti e
massima disponibilità di integrarli;
L’infrastruttura deve utilizzare degli standard aperti sia per i protocolli di trasporto che
per gli aspetti sintattici e semantici (documenti e dati scambiati tra i sistemi).
4.1.4 Componenti dell’infrastruttura del FSE
L’infrastruttura del FSE contiene le seguenti tipologie di sistemi:
1. Sistemi registry (registri) che forniscono e gestiscono informazioni necessarie per
l’identificazione univoca degli attori nel sistema FSE; questi attori sono sia i
pazienti/cittadini che gli operatori sanitari o le varie strutture di cura: ASL, ospedali
etc. sono numerose tipologie di registri utili per il FSE1.
Nell’infrastruttura del FSE, i registri della stessa tipologia possono essere molteplici
secondo l’area geografica coperta.
Esempi di registri utili sono:
a. Registri anagrafe cittadini, registri anagrafe operatori sanitari, registri di
localizzazione, etc..
b. Registri contenenti consensi informati dei pazienti fanno parte anche loro
dell’infrastruttura FSE.
c. Registri di metadati che rendono pubbliche informazioni sulla semantica e sui
componenti di un dato per ottenere l’interoperabilità semantica dei metadati in
1 Registry di elementi e tipi di dati: forniscono un dizionario comune di dati che contengono definizioni di tipi e elementi di dato. Registry di schemi XML: forniscono un repository di versioni di schemi XML che descrivono messaggi, formati di file, e componenti di dato. Registry di XML Stylesheet: forniscono un repository di versioni di XML stylesheet per conversioni tra schemi di dati. Registry di namespace o dominio: forniscono un registry che controlla un domnio o namespace gerarchico. Registry di servizi: fornisce un registry dinamico per servizi web. Registri di modelli: forniscono un repository di modelli di informazioni, relazioni tra dati, e altri informazioni di tipo ontologico.
Analisi ad alto livello Pagina 25 di 38
vari domini e in vari contesti culturali. Questi registri di solito memorizzano la
semantica degli elementi di metadati e mantengono informazioni su qualsiasi
estensione locale di essi, fornendo anche mappings ad altri schemi di metadati.
d. Registri che forniscono servizi che permettano ad applicazioni fornitrici di
servizi di incontrare i consumatori degli stessi servizi.
2. Repository di dominio che gestiscono insiemi di dati clinici appartenenti al dominio del
FSE (repository per farmaci, immagini di diagnostico e di analisi di laboratorio).
3. Servizi comuni in particolare di comunicazione per sostenere l’interoperabilità tra i vari
componenti nell’infrastruttura, tra altre infrastrutture e tra l’infrastruttura stessa e le
applicazioni legaci.
4. Strutture standardizzate di dati e messaggi in grado di abilitare transazioni necessarie
alla memorizzazione e allo scambio di informazioni tra FSE e il suo ambiente.
Questa infrastruttura permette l’implementazione del sistema FSE, un’altra componente
software che gestisce e memorizza informazioni cliniche mirate al cittadino. Il progetto
LUMIR deve identificare i requisiti, l’architettura e le soluzioni tecnologiche per
l’implementazione del Fascicolo Sanitario Personale regionale in conformità con le norme,
le leggi e gli standard internazionali e con il progresso registrato nel campo dell’ICT
(Figura 4).
Figura 4. Progetto FSE per LUMIR
In questo ambito è sbagliato concepire il FSE come una base di dati (virtuale o meno);
invece esso deve essere visto e progettato come un sistema di routing sofisticato.
L’architettura FSE (architettura logica in Figura 4) viene specificata attraverso il modello
di dominio (Reference Model in termini HL7), i servizi forniti e i meta-modelli utilizzati,
così come evidenziato nella Figura 4. Questo documento si conclude con la prima bozza di
architettura cosi come essa risulta dall’analisi del ambiente in cui FSE verrà utilizzato.
4.2 Analisi dei requisiti utente per il FSE
4.2.1 Contesto del FSE
La Figura 5presenta il contesto applicativo del FSE, formato dagli attori (persone e altri
sistemi applicativi) che interagiscono con FSE, dagli elementi base (Registry/Repository),
dai Libretti Sanitari del Paziente.
Requisiti
Standard, norme, leggi
Architettura logica
Modello del
dominio
Modello dei
servizi
Meta-
modelli
Architettura
tecnologica
vincoli
vincoli vincoli
Casa anziani
Assistente sociale
ASL
Cartella
Registry/ repository
Libretto paziente/ Summary
Analisi ad alto livello Pagina 26 di 38
Figura 5.Contesto del FSE
L’architettura FSE deve consentire l’interazione con altri sistemi che utilizzano la stessa
infrastruttura.
I servizi FSE devono essere aggiunti ad un’infrastruttura esistente che deve fornire la
condivisione e la sicurezza degli accessi ai fascicoli sanitari dei diversi pazienti. Questi
servizi devono essere accessibili per la comunità degli utenti che compongono il contesto
del FSE (Figura 5) per essere utilizzati dalle applicazioni installate presso i fornitori di cura
(la cartella elettronica del medico di famiglia, la cartella clinica del ospedale, etc.), presso i
pazienti (accesso web ai vari libretti della salute) oppure presso altri enti interessate
nell’informarsi sulla salute dei cittadini (Ministero della Salute, Comuni, etc.). In questo
senso il FSE è lui stesso un’infrastruttura di tipo middleware che consente lo sviluppo di
sistemi applicativi.
4.2.2 Requisiti per il FSE
I requisiti rispettati dal FSE e dalle applicazioni supportate da esso includono:
copertura per l’intero ciclo di vita dei cittadini,
facilitare l’interazioni tra paziente e gli operatori sanitari,
assicurare la tracciabilità delle decisioni, potenziare la responsabilità dei fornitori di
cura, etc.,
indipendenza di qualsiasi formato o scelta tecnologica,
condivisione dei dati e delle conoscenze attraverso l’interoperabilità,
utilizzo sia per cure primarie che per quelle acute,
integrazione tra vari linguaggi o gerghi utilizzati nel ambito sanitario,
Analisi ad alto livello Pagina 27 di 38
supporto per la privacy dei cittadini,
supporto per dati medico-sanitari: liste tabelle, serie temporali, eventi sanitari, domini
di valori, sistemi alternativi di misurazione, etc.,
supporto per workflow automatici o semi-automatici,
supporto per usi secondari quali l’educazione, la ricerca, la medicina popolare,
compatibilità con sistemi di messaggistica esistenti.
4.2.3 Principi di progettazione del FSE per LUMIR
La progettazione del FSE include la modellizzazione dell’informazione, dei servizi e delle
regole del business.
La modelizzazione si basa sul principio cardine della progettazione, cioè la separazione
delle competenze (separation of concerns) che permette la scomposizione di un sistema in
parti, ognuna delle quali responsabile di una particolare area di interesse, chiamata
“concern”. Questo principio permette di creare più modelli dello stesso sistema, ognuno di
essi organizzato gerarchicamente. Un tale approccio fornisce mantenibilità, estendibilità e
flessibilità al sistema.
4.2.4 Separazione ontologica
La separazione ontologica si basa sulla dimensione semantica dell’universo da
rappresentare. Una separazione fondamentale è tra l’Universo dell’Informazione e quello
Reale in cui il primo è uno specchio parziale, mediato del secondo.
Nell’Universo dell’Informazione si deve distinguere tra i modelli informativi contenenti
delle strutture di informazione e i modelli dei vincoli imposti ai primi. Tali vincoli sono
derivati dalle regole del “business” al fine di poter “mappare” meglio i modelli informativi
nel mondo reale. Concetti come “Archetype” e “Templates” nello strato dei modelli delle
regole del business mappano i modelli informativi in terminologie, classifiche e linee
guida. Tenere separati i due livelli permette di distinguere tra i modelli più stabili, quelli di
riferimento, e quelli più volatili, delle regole del business. Di conseguenza, nello sviluppo
del software di supporto per le attività business si possono separare le attività che
progettano ed implementano i database e i meccanismi di supporto infrastrutturale delle
attività automatizzate da quelle che sviluppano archetypes, patterns e impostano vincoli
(cioè conoscenze).
In seguito si presenta l’ontologia dei concetti le cui istanze sono gestite dal FSE.
4.2.5 Obiettivi ontologici di LUMIR
Un sistema informativo sanitario territoriale di ampie dimensioni, come uno di natura
regionale, deve essere in grado di relazionare un unico sistema di metadati al fine di
garantire l’integrità semantica del contenuto di ciascuna informazione elementare. Nel caso
del progetto LUMIR, i metadati individuati corrispondono in gran parte all’HEADER dello
standard HL7 CDA.
Tale scelta potrebbe non essere analoga a quella fatta in altre regioni oppure in altre
nazioni; in tale ambito, si possono immaginare “ponti semantici” tra questi sistemi
eterogenei di metadati, attraverso ontologie condivise e sistemi di registri interoperabili tra
i modelli più consolidati. Nasce quindi la necessità di associare una ontologia al sistema di
metadati presente nei registri dell’infrastruttura LUMIR. Tale necessità, peraltro, deriva nel
Analisi ad alto livello Pagina 28 di 38
conferire una interpretazione semantica alle informazioni presenti nei registri, che non sia
quella implicitamente sottesa dal sistema di metadati scelto.
Ad esempio, HL7 ha “categorizzato” gli eventi del domino sanitario, così come evidenziati
nella Figura 7, considerando le principali funzionalità coinvolte; tale classificazione può
essere impiegata per individuare una ontologia d’alto livello per gli eventi di LUMIR.
Ciò è stato fatto in parte considerando i metadati dell’HEADER di HL7 CDA:
Figura 6. Eventi HL7
Allo stesso modo, il CEN, nello standard EN 13606, ha disegnato un modello, una parte
sintetizzato nella Figura 7, per i concetti espressi negli statement (concetti); tale
classificazione può essere impiegata per individuare una ontologia d’alto livello per i
servizi legati ai documenti sanitari.
An Example Service Functionality
Ontology
HealthCareServices
PatientAdministration PatientCare PatientReferral Scheduling ObservationReporting
PatientInfoRequest CancelPatientReferralPatientReferralRequest
InsuranceInformation ClinicalInformation DemographicData
GetClinicalInformation
serviceQuality location Properties of the
Generic Service
Class
Properties of the
Generic Service
Class
Analisi ad alto livello Pagina 29 di 38
Figura 7. Statement CEN Eventi HL7
In generale, quindi, nella visione LUMIR diversi sistemi FSE possono sviluppare i propri
metadati, nomenclatori e ontologie. Talune di queste possono essere conformi a standard
sviluppati dagli enti di normalizzazione (CEN TC251, ISO TC215, GEHR, HL7, etc.),
altre possono essere proprietarie e rese aperte da descrizione semantiche (ISO 111179,
Dublin Core). Il mapping tra queste ontologie può avvenire attraverso delle “mediazioni
semantiche” opportune.
4.2.6 Documenti CDA
Per la rappresentazione elettronica delle Unità Documentali sarà utilizzato lo standard HL7
CDA. L’iniziativa Clinical Document Architecture (CDA) è stata introdotta in HL7
versione 3 come un modello standard, derivato dal RIM HL7, di scambio di documenti
elettronici in ambito clinico con vari livelli di complessità. Il CDA, quindi, rappresenta un
file elettronico che specifica la struttura e la semantica di un “documento clinico” ed ha le
seguenti caratteristiche:
Persistenza: un documento clinico elettronico HL7 CDA continua ad esistere in uno
stato inalterato, per un periodo di tempo definito.
Amministrabilità: un documento clinico elettronico HL7 CDA è mantenuto da un
organizzazione affidabile.
Autenticazione: un documento clinico elettronico HL7 CDA è un insieme di
informazioni che possono essere legalmente autenticate.
Contesto: un documento elettronico HL7 CDA stabilisce il contesto del suo contenuto.
Interezza: l’autenticazione di un documento clinico elettronico HL7 CDA è applicata
all’intero documento e non a porzioni dello stesso.
Leggibilità umana: un documento clinico elettronico HL7 CDA è leggibile da un
essere umano.
Come indicato, il modello CDA è derivato dal RIM HL7 mediante il processo classico di
specializzazione della metodologia versione 3, che pone dei vincoli sulle classi del RIM.
An example Service Message
Ontology
Concept
Property
Concept
Property
DD02: Problem
DTC12: CarePlan
DF03: AllergyState
DTH03: Ongoing Problems
DTH08: Present Interpretations
DD01: Diagnosis
DTC08: Diagnostic Test Results
DS00: Patient
Analisi ad alto livello Pagina 30 di 38
Un documento CDA è codificato in XML, ed è costituito da due grosse componenti:
l’HEADER e il BODY.
L’HEADER è compreso fra i tag “ClinicalDocument” e il tag “structuredBody”, ed
identifica e classifica il documento fornendo informazioni sull’autenticazione, gli attori
sanitari, il paziente e i fornitori di prestazioni sanitarie.
Il BODY contiene le informazioni cliniche e può essere costruito sia in formato de-
strutturato che in formato strutturato mediante sezioni ricorsive.
Il BODY del CDA in formato strutturato contiene le “entry” che si richiamano agli eventi
sanitari che caratterizzano i dati clinici del documento. Tali eventi sono descritti mediante
degli atti sanitari. I principali atti sono:
Act: registra l’informazione sanitaria relativa a cosa è stato fatto, cosa può essere fatto
o è intenzione o richiesto che venga fatto. E’ derivata dalla classe Act del RIM e viene
usata quando le altre classi più specifiche non sono appropriate.
Observation: rappresenta l’informazione sulla natura di una osservazione ed
eventualmente il risultato o gli accertamenti correlati. E’ derivata dalla classe
Observation del RIM.
Encounter: è un interazione tra un paziente e una struttura sanitaria con il fine di
fornire dei servizi sanitari fra i quali una valutazione diagnostica. L’Encounter è usato
per l’ammissione, la dimissione e il trasferimento come per ogni singola visita presso
un ufficio sanitario; inoltre, tratta il piano per visite regolari quali cure preventive
durante la gravidanza o il controllo di pazienti con malattie croniche. L’Encounter è
derivato dalla classe PatientEncounter del RIM, usata per rappresentare
incontri/contatti correlati o un effettivo singolo incontro.
Supply: è usata per rappresentare la fornitura di un materiale da una entità ad un’altra.
E’ derivata dalla classe Supply del RIM.
Procedure: è usata per rappresentare gli interventi; è derivata dalla classe Procedure
del RIM.
SubstanceAdministration: è usata per rappresentare eventi relativi a medicazioni,
quali la storia delle medicazioni, la pianificazione di medicazioni. Include la richiesta,
le istruzioni per il paziente, le raccomandazioni, le promesse, i divieti o i rifiuti di
somministrazione di una sostanza e gli effettivi atti si somministrazione di una
sostanza. E’ derivata dalla classe SubstanceAdministration del RIM.
Organizer: è usata per creare un arbitrario raggruppamento di altre classi
rappresentanti eventi clinici che condividono un contesto. Un Organizer può contenere
un altro Organizer ed altre classi rappresentanti eventi clinici attraverso la relazione
Component. E’ derivata dalla classe Act del RIM.
L’infrastruttura FSE evidenziata in precedenza per LUMIR assicura un meccanismo per
conservare i documenti clinici elettronici, per avvertire un eventuale destinatario
predefinito della disponibilità di una particolare Unità Documentale, per cercare
nell’elenco i documenti clinici elettronici relativi ad un paziente e per estrarli dall’archivio.
I dati clinici contenuti nelle Unità Documentali pervenuti al destinatario non sono
necessariamente elaborabili; l’infrastruttura FSE di LUMIR assicura, infatti, solo la
distribuzione delle Unità Documentali, non la possibilità di interpretare il contenuto; per
questo scopo, è necessario utilizzare degli ulteriori standard, come ad esempio HL7 CDA
che sarà la specifica di riferimento per le Unità Documentali in LUMIR.
Analisi ad alto livello Pagina 31 di 38
Con ciò si realizzano le diverse finalità previste, fra cui quelle di utilizzo a fini
comunicativi, utilizzo statistico-epidemiologico, utilizzo clinico, realizzazione di un
sistema evoluto di Fascicolo Sanitario Elettronico.
L’infrastruttura FSE di LUMIR prevede l’introduzione nella rete enterprise
(Internet/intranet) di un Repository logico per l’archivio delle Unità Documentali, ed un
Registro degli indici dei documenti. Il sistema LUMIR incapsulerà ogni Unità
Documentale che si scatena a valle di un evento clinico in un formato coerente allo
standard HL7 CDA.
Pertanto i dati trattati dal sistema LUMIR (dati di supporto, quali dati inerenti medicinali,
prestazioni erogabili, fornitori di prestazioni, e dati clinici, relativi al percorso sanitario
delle persone e all’assistenza fornita alle persone stesse), verranno quindi “incapsulati” in
file XML conformi allo standard HL7 CDA (dai Proxy Applicativi) e in tale formato
verranno dati in “pasto” all’infrastruttura FSE di LUMIR.
Esempi di dati del sistema LUMIR sono:
referti di laboratorio,
visite specialistiche ambulatoriali,
dati della diagnostica,
dati delle cartelle sanitarie disponibili presso i MMG e i PLS,
dati dei ricoveri, lettere di dimissione, SDO,
prescrizioni farmaceutiche, specialistiche e di ricovero,
vaccinazioni e certificati di malattia,
Il vantaggio notevole è l’adeguamento semantico dei dati degli eventi clinici, perché questi
ultimi avranno sempre l’HEADER codificato: ad esempio, se l’evento di refertazione
produce un PDF firmato destrutturato, questo sarà inserito, così com’è (codifica base64)
nel documento XML HL7 CDA (nella sezione BODY) ma comunque erediterà un serie di
metadati (la sezione HEADER) che, in qualche maniera, lo “strutturano” (e.g. si riporta il
tipo di documento, l’autore, il soggetto, etc.); se l’evento di refertazione, viceversa,
produce già una qualche forma di strutturazione (e.g. un file XML) sarà più semplice il
passaggio nel formato HL7 CDA, e quindi l’estrazione dei dati componenti il documento.
Il risultato è avere due Unità Documentali perfettamente confrontabili sotto l’aspetto
semantico, anche se originariamente completamente diversi (un PDF narrativo e
destrutturato, ed un file XML strutturato), grazie ai metadati dell’HEADER.
Analisi ad alto livello Pagina 32 di 38
4.3 Separazione secondo i punti di vista (viewpoints)
Quando le responsabilità nel sistema si dividono tra più componenti è necessario separare
tra le informazioni che i processi elaborano e come questi processi comunicano tra loro.
Più precisamente questa separazione si può dettagliare in più punti di vista:
Funzionale: riguarda le attività business, obiettivi, politiche, contesto del sistema da
specificare;
Strutturale: riguarda la semantica dell’informazione che deve essere memorizzata ed
elaborata nel sistema;
Comportamentale: riguarda la interazione tra oggetti che comunicano al livello delle
loro interfacce;
Infrastrutturale: riguarda i meccanismi che supportano la distribuzione geografica del
sistema;
Tecnologica: riguarda gli aspetti tecnologici dei componenti che compongono il
sistema distribuito.
Tale suddivisione sarà ripresa nel documento della progettazione di dettaglio del Progetto
LUMIR.
Di seguito, si riporta il punto di vista d’alto livello funzionale, strutturale e
comportamentale.
Analisi ad alto livello Pagina 33 di 38
4.4 Architettura LUMIR
La progettazione esecutiva del sistema LUMIR verrà presentata in un apposito documento.
Gli aspetti fondamentali di questa architettura sono:
orientamento ai servizi
federazione dei dati
federazione degli aspetti di sicurezza
robustezza e tolleranza ai difetti.
L’architettura riutilizza il pattern dei sistemi business basati sui servizi adattandolo agli
aspetti specifici della sanità elettronica, in particolare ai processi di creazione, gestione e
utilizzo dei fascicoli sanitari dei cittadini. In seguito la stessa architettura potrà essere
utilizzata per implementare applicazioni verticali come i vari libretti sanitari o i processi di
cura per le varie malattie.
L’architettura del sistema business prevede in linee di massima la definizione/adattamento
delle seguenti componenti logiche strutturate in più strati di servizi (Figura 8):
A. Strato dell’infrastruttura di comunicazione
1. Servizio di comunicazione in una rete composta da nodi corrispondenti a tutti gli
operatori sanitari (i MMG/PLS, gli specialisti, i Laboratori, le Aziende Ospedaliere,
etc.) basato su vari servizi di basso livello necessari nella comunicazione: servizi di
integrazione dati, scambio di documenti (file), messaggistica sincrona ed asincrona
(gestione code), orchestrazione di servizi etc. La comunicazione avviene utilizzando
un protocollo standard:
2. Servizio di protocollo nazionale per l’interoperabilità (ICAR sopra SPCoop).
B. Strato dell’infrastruttura di servizi condivisi:
3. Servizi per l’indicizzazione, routing e persistenza delle informazioni, relative agli
eventi sanitari individuali su scala regionale, composto da:
3.1. Un gruppo di Repository (quelli del Centro Tecnico Regionale e delle sedi
periferiche) per la conservazione e l’accesso alle informazioni relative agli eventi
sanitari conformemente agli standard sintattici/semantici internazionali (es. lo
standard HL7 CDA release 2.x);
3.2. Un gruppo di Registri (quello del Centro Tecnico Regionale e delle sedi
periferiche) per la pubblicazione e l’indicizzazione delle informazioni relative
agli eventi sanitari.
3.3. Un Broker di oggetti business per la localizzazione/routing e trasporto di entità
business del sistema informativo.
4. Servizi di sicurezza, privacy e di policy di accesso sicuro attraverso firma digitale ed
autenticazione forte (standard CNS).
5. Servizi di notifica per la realizzazione di pattern diversificati di comunicazione
compresa quella asincrona.
6. Servizi di dati per la realizzazione delle conversioni tra vari data-set e per la
strutturazione/destrutturazione dei dati compositi.
Analisi ad alto livello Pagina 34 di 38
7. Servizi di transazioni e auditing per la gestione delle transazioni (commit/rollback)
distribuite.
C. Strato dei servizi business (applicativi)
8. Servizi normalizzati e integrati, quali la prescrizione, refertazione, etc., provenienti da
applicazioni legacy o non legacy. Questi servizi sono possibili componenti di
complessi processi sanitari online.
Figura 8: Architettura business del sistema LUMIR
La Figura 9 mostra schematicamente gli strati di servizi che compongono il Sistema di
Sanità della Regione Basilicata derivati dall’architettura di riferimento.
L’accesso degli utenti al FSE si realizza utilizzando applicazioni web eseguite dal browser
oppure applicazioni web realizzate ad hoc per il sistema sanitario regionale integrato. Nel
caso del browser l’accesso avviene tramite un portale della regione Basilicata. Il sistema
FSE può comunicare con applicazioni legacy in quale caso tra il sistema e le applicazioni
si interpongono dei componenti software (integratore legacy o wrapper) in grado di
armonizzare i servizi dell’applicazione con i servizi richiesti dal sistema. Il FSE è costituito
da un software distribuito (Cartella clinica virtuale) che realizza i suoi compiti utilizzando
un’infrastruttura di servizi.
Questi servizi sono servizi condivisi che assicurano prestazioni specifiche come: notifiche,
rispetto della privacy, sicurezza dei dati e delle operazioni, transazioni, auditing etc. Questi
servizi si inseriscono automaticamente nello scambio di informazioni che avviene tra le
varie applicazioni. Questo scambio si basa su dei servizi di messaggistica che sfruttano
Applic . legacy Applic. legacy
Applic . legacy Applic. legacy
Applic . legacy Applic. legacy
Applic . legacy Applic. legacy
Componenti Business
Integratore di servizi
Strato dei componenti software (sistemi legacy )
Integratore di servizi
Applic . legacy Applic. legacy
InfoBroker
Strato d’ interconnetività (SOA)
Strato dei servizi del business
Hub di servizi medico - sanitari
Infrastruttura di comunicazione (ICAR/SPCoop)
Strato di normalizzazione dei servizi
Strato del business
Servizi di supporto per l’ interoperabilità sintattica e semantica
Servizi di pubblicazione e localizzazione
Processo business
Strato applicativo
Servizi di sicurezza e privacy
Servizi di collaborazione
Processi utente
Repository / Registry
Modelli/ Ontologie
Basi dati
LIVELLI
Analisi ad alto livello Pagina 35 di 38
protocolli standard per comunicare in rete. In fine, il contenuto di dati dei messaggi viene
prelevato attraverso servizi specifici per l’accesso ai repository e/o database.
Persistenza
Servizio di
notifica
Servizio di
identità
(privacy)
Servizio
demografico
Servizio di
sicurezzaServizi di
auditing
Servizi di comunicazione locale (servizi di messaggistica)
Servizi di comunicazione sicura a larga scala
1. persistenza
2. servizi di back-up
3. clienti virtuali
4. logica
dell’applicazione
5. presentazione
Cartella
clinica
virtuale
Integratore
legacy
Cartella
clinica
virtuale
Motore
di query
Cartella
clinica
virtuale
Logica dell’
applicazione
Cartella
clinica
virtuale
Applicazione
sanità
Strato di
presentazione
DB
legacy
Portal web
Browser
web
Persistenza
Servizio di
notifica
Servizio di
identità
(privacy)
Servizio
demografico
Servizio di
sicurezzaServizi di
auditing
Servizi di comunicazione locale (servizi di messaggistica)
Servizi di comunicazione sicura a larga scala
1. persistenza
2. servizi di back-up
3. clienti virtuali
4. logica
dell’applicazione
5. presentazione
Cartella
clinica
virtuale
Integratore
legacy
Cartella
clinica
virtuale
Motore
di query
Cartella
clinica
virtuale
Logica dell’
applicazione
Cartella
clinica
virtuale
Applicazione
sanità
Strato di
presentazione
DB
legacy
Portal web
Browser
web
Figura 9. Architettura a servizi del sistema LUMIR
Analisi ad alto livello Pagina 36 di 38
Figura 10: Mapping dell’architettura a servizi nell’architettura business
La Figura 10 presenta come si mappa l’architettura a servizi nell’architettura di
riferimento.
La Figura 11 invece introduce un’altra vista ancora sul sistema sanitario regionale,
integrato fornendo una strutturazione geografica dei componenti del software. Sono stati
individuati tre ambienti: locale, aziendale e regionale in cui vengono installati i
componenti software del sistema.
Analisi ad alto livello Pagina 37 di 38
Figura 11. Strutturazione territoriale del sistema LUMIR
Nel diagramma si presentano simbolicamente gli utenti del sistema, sono stati inseriti i vari
wrapper necessari per i componenti esistenti e evidenziate le interfacce di accesso ai
componenti.
4.5 Diagramma dei componenti del sistema LUMIR
La Figura 12 presenta il diagramma di componenti del sistema LUMIR. Una descrizione
completa dei componenti e delle loro dipendenze si può trovare nel documento di
progettazione.
IBIS
Clinical
Application
Wrapper
Gateway
Wrapper
Registry
Repository
notify
locate
Wra
pp
er
retrieve
Livello locale
Livello regionale
store
Data Source
Clinical/Mgm.
Application
Wrapper
Livello aziendale
register
Regione
ASL
MMG/
Ospedale/
Cittadino
Web Server
Browser
Browser
Browser
…..
Repository
Regional
HIS
Wra
pp
er
IBISIBIS
Clinical
Application
Wrapper
Gateway
Wrapper
Registry
Repository
notify
locate
Wra
pp
er
retrieve
Livello locale
Livello regionale
store
Data Source
Clinical/Mgm.
Application
Wrapper
Livello aziendale
register
Regione
ASL
MMG/
Ospedale/
Cittadino
Web Server
Browser
Browser
Browser
…..
Repository
Regional
HIS
Wra
pp
er
Analisi ad alto livello Pagina 38 di 38
Figura 12. Diagramma di componenti LUMIR