Analisi ad alto livello - Dipartimento Salute, … Rete dei Medici di Medicina Generale RS...

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.


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


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).

http://www.irpps.cnr.it/mobidis/index.php

http://www.sanitaelettronica.gov.it/

http://bas-refapp.basilicatanet.it/portale/servizio_strumenti.html

http://bas-refapp.basilicatanet.it/portale/servizio_strumenti.html

http://best.det.unifi.it:9090/icar

http://www.sanitaelettronica.gov.it/xoops/modules/docmanager/index.php?curent_dir=39




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


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


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;


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).


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.


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


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.


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


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


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).


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,


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.


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


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.


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.


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à.


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.


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


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


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]):


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.


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


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,


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


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


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


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.


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.


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.


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.


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




Componenti Business

Integratore di servizi

Strato dei componenti software (sistemi legacy )

Integratore di servizi


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


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


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.


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


Figura 12. Diagramma di componenti LUMIR

Analisi ad alto livello - Dipartimento Salute, … Rete dei Medici di Medicina Generale RS...

Documents

Transcript of Analisi ad alto livello - Dipartimento Salute, … Rete dei Medici di Medicina Generale RS...