scheda descrittiva del programma - agid...azienda sanitaria n. 2 del savonese pagina 8 di 27 scheda...

Azienda Sanitaria n. 2 del Savonese Pagina 1 di 27

Scheda per la descrizione di

programmi informatici o parti di essi

ceduti in riuso

Scheda descrittiva del programma

ceduto in riuso

UNI.SYS

SISTEMA GESTIONALE SANITARIO UNIFICATO

PER LA RILEVAZIONE, IL TRATTAMENTO,

L’ARCHIVIAZIONE E LA RENDICONTAZIONE

DELLE PRESTAZIONI SANITARIE ASL2

ASL2 Savonese




ceduti in riuso

1 SEZIONE 1 – CONTESTO ORGANIZZATIVO

1.1 Generalità

1.1.1 Identificazione e classificazione dell’amministrazione cedente

Amministrazione cedente

Azienda Sanitaria Locale n. 2 Savonese – Regione Liguria

Amministrazione cedente – Sigla: Asl2 Savonese

Tipologia di Amministrazione cedente: Azienda

1.1.2 Identificazione e classificazione dell’Oggetto

Oggetto offerto in riuso

Sistema destinato ad integrare funzionalmente i reparti ospedalieri, le diagnostiche e le

strutture ambulatoriali - Sistema Gestionale Sanitario Unificato – UNI.SYS

Oggetto offerto in riuso - Sigla UNI.SYS

Tipologia di Oggetto offerto in riuso:

Altro: Servizi sanitari erogati in ambito ospedaliero e extra-ospedaliero

Note:

Il sistema informatizzato oggetto di riuso ha ad oggetto l’informatizzazione di tutti i dati

amministrativi e sanitari inerenti i pazienti che accedono ai servizi dell'Azienda,

relativamente a prestazioni erogate sia in regime di ricovero, sia in regime ambulatoriale

e presso i servizi sanitari territoriali

Collocazione funzionale dell’Oggetto.

L’Oggetto realizza funzioni a livello di: Servizio

Tipologia di licenza dell’Oggetto offerto: Proprietario

Modalità di implementazione dell’Oggetto ceduto in riuso:

Evoluzione di un Oggetto proprietario acquisito in licenza d’uso, eseguita sulla base di

specifici accordi stipulati dall’amministrazione con il titolare dell’Oggetto

Oggetto/i di cessione in riuso:

Oggetto o parte di esso

Altro: Le macro - componenti del sistema UNI.SYS già disponibili ai fini della

concessione in riuso sono le seguenti:

Sistema di autenticazione utenti mediante smart card;




ceduti in riuso

Cartella di ricovero (ordinario e DH) completata in tutte le sue componenti, sia

mediche sia infermieristiche, nonché della gestione della farmacoterapia

(prescrizione e somministrazione a bordo letto), integrata con il sistema di gestione

order entry unificato per la richiesta di prestazioni diagnostiche e consulenze

interne e la consultazione dei relativi referti;

Prescrizione ricetta rossa e relativo invio dati al SAC, tramite SAR;

Prescrizione piani terapeutici e relativo invio al sistema regionale di monitoraggio.

Il sistema UNISYS prevede inoltre le seguenti funzioni, attualmente in fase di sviluppo

SW / collaudo (a diversi livelli di approntamento) e quindi previste in cessione in riuso

in una fase successiva, che saranno completamente e nativamente integrate con i

suddetti moduli SW:

Cartella ambulatoriale

Gestione Liste di attesa

ADT (Accettazione, Dimissione e Trasferimento pazienti, con compilazione SDO)

Pronto Soccorso

Gestione dispensazione presidi protesici

Gestione PSAL, Igiene degli alimenti, Veterinaria, Vaccinazioni

Cartella Medici di Medicina Generale / Pediatri di Libera Scelta, integrata nel

sistema di dossier sanitario, con condivisione del patient summary del paziente.

1.1.3 Referenti dell’amministrazione cedente

Responsabile

dei sistemi

informativi

Nome e cognome:

Indirizzo:

Tel/Cel:

e-mail:

Ermanno Sacchi

Ospedale S. Corona - Via XXV Aprile 38 –

Pietra Ligure

0196232201 - 3482237249

[email protected]

Referente/i di

progetto

Nome e cognome:

Indirizzo:

Tel/Cel:

e-mail:

Simona Lanza


Pietra Ligure

0196232206

[email protected]

Referente/i

amministrativo

Nome e cognome:

Indirizzo:

Tel/Cel:

e-mail:

Simona Lanza


Pietra Ligure

0196232206

[email protected]




ceduti in riuso

1.2 Scenario di riuso

1.2.1 Ambito amministrativo interessato

Gestione dati per la pianificazione degli interventi finanziari, monitoraggio e

rendicontazione

Gestione di flussi documentali a supporto della cooperazione amministrativa

Servizi al cittadino

Servizi sanitari

1.2.2 Utenti fruitori dell’Oggetto

Numero totale di Utenti che utilizzano l’Oggetto: circa 2.150

Contesto organizzativo

UNISYS è un sistema informatizzato destinato ad essere utilizzato presso tutti i servizi

sanitari, ospedalieri e territoriali, di una Azienda Sanitaria. In particolare il sistema

integra funzionalmente i reparti ospedalieri (utilizzatori principalmente della cartella di

ricovero), le diagnostiche (mediante order entry unificato ed interscambio in tempo

reale di richieste di prestazioni, risultati strutturati e documenti firmati digitalmente), le

strutture ambulatoriali (ospedaliere e territoriali) e, in prospettiva prossima, i servizi

territoriali Asl ed i MMG/PLS).

Obiettivi perseguiti

Realizzazione e compiuta diffusione di un SISTEMA GESTIONALE SANITARIO

UNIFICATO il cui utilizzo, in relazione alle specifiche funzionalità di cui il sistema

stesso dispone attualmente e disporrà negli ulteriori sviluppi in corso, sia esteso a tutte

le strutture erogatrici di servizi sanitari e di servizi amministrativi a questi ultimi

connessi (sia in ambito ospedaliero che territoriale).

Il Sistema Gestionale Sanitario Unificato (UNI.SYS) si propone di costituire:

l’unica interfaccia per il caricamento, l’interrogazione, l’estrazione e la gestione

dei dati amministrativi e sanitari inerenti i pazienti che accedono ai servizi

dell'Azienda, relativamente a prestazioni erogate sia in regime di ricovero, sia in

regime ambulatoriale e presso servizi territoriali;

lo strumento comune di interscambio delle informazioni fra le differenti strutture

all’interno dell'Azienda, favorendo la consultazione informatizzata delle

informazioni nel rispetto della vigente normativa sulla privacy;

l’ambiente da cui accedere alla consultazione organizzata dei principali archivi

contenenti dati amministrativi / sanitari;

lo strumento per la generazione dei flussi di rendicontazione delle prestazioni

effettuate e per l’acquisizione dei dati necessari al corrette funzionamento dei

sistemi gestionali interni (controllo di gestione e supporto alla clinical governance).

L’esigenza di addivenire alla realizzazione di tale strumento unificato è derivata:

dall’accresciuta complessità delle prestazioni sanitarie erogate e dal crescente

ricorso alla diagnostica (clinica e per immagini) a supporto delle prestazioni

sanitarie medesime;




ceduti in riuso

dalla diffusione, non omogenea e spesso non coordinata, di sistemi informativi

autonomi, a servizio di singole aree / reparti, con significative problematiche in

termini di interscambio dei dati e di diffusione di una omogenea modalità operativa

all’interno di tutte le strutture aziendali;

dall’esigenza di costituire una piattaforma informatizzata unificata che semplifichi

l’operatività del personale sanitario dell’Azienda;

dalla crescente esigenza dell’Azienda di dotarsi di strumenti informativi efficaci a

fini di monitoraggio e controllo delle prestazioni erogate, nonché di gestione del

rischio clinico;

dall’opportunità di costituire una banca dati completa e condivisa, che sia

presupposto per la facile accessibilità del cittadino ai propri dati sanitari, anche

attraverso l’interfacciamento con gli strumenti all’uopo previsti dalla

programmazione regionale e nazionale (Fascicolo Sanitario Elettronico).

Sono pertanto attese ottimizzazioni:

in fase di acquisizione e gestione dei dati clinici ed amministrativi;

nella gestione del processo di somministrazione dei farmaci;

in ambito organizzativo, eliminando alcuni ostacoli all’intercambiabilità del

personale fra le strutture ed i servizi;

in termini di efficacia dell'assistenza al paziente, grazie alla pronta disponibilità dei

dati clinici e diagnostici, contestuali e storici, relativi all'assistito, in una logica di

dossier sanitario già orientato all'integrazione con sistemi regionali e nazionali di

FSE;

nell'adozione di nuovi modelli gestionali per la programmazione e l'esecuzione

delle attività infermieristiche, orientati ai bisogni del paziente;

nel governo dei processi, nel monitoraggio della spesa sanitaria, nella

programmazione dei servizi sanitari e socio-sanitari, nel controllo

dell'appropriatezza delle prestazioni erogate.

Aspetti dimensionali

Numero totale di Function Point dell’Oggetto: 37

Numero Classi java: 1.051

Numero di Moduli: 3

1.2.3 Descrizione delle funzionalità

Modulo Cartella di ricovero

Nome Descrizione Dati (*)

Input Output

Prospetto Degenti Funzionalità utilizzata per assegnare ad ogni

paziente il letto all’interno del reparto di degenza

Anamnesi Scheda in cui viene riportata la storia

anamnestica del paziente

Esame obiettivo Scheda su cui viene indicato l’esame obiettivo

attinente il ricovero

Dati generali Scheda su cui vengono memorizzate le

informazioni generali del paziente e quelle dei

parenti da contattare

Accertamento

infermieristico

Scheda che contiene i bisogni assistenziali del

paziente




ceduti in riuso

Scale e Score Schede per la gestione della valutazione del

paziente sia lato medico che infermieristico

Modulistica Gestione moduli consenso del paziente

Gestione allerte Gestione allergie, intolleranze, positività e

reazioni avverse

Diari Compilazione dei diari delle varie figure

professionali

Rilevazioni di

parametri vitali

Modulo per la compilazione dei parametri vitali

e gestione delle allerte in base al valore rilevato

Prescrizioni e

somministrazioni di

terapie

Modulo per la gestione delle prescrizione delle

terapie con la possibilità di utilizzare anche

prescrizioni salvate a livello di reparto e per la

gestione delle somministrazioni

Gestione dei presidi Modulo per la rilevazioni dei presidi (cvc, cvp,

ca, peg, sng) e delle medicazioni

Gestione delle lesioni Gestione delle lesioni da decubito, delle lesioni

chirurgiche e delle restanti con relative

medicazioni

Attività

infermieristiche

Gestione delle attività da pianificare ed eseguire

sul paziente

Lettere Possibilità di compilare e firmare digitalmente le

lettere di dimissione, di trasferimento e di

prosecuzione. Per il DH le lettere da compilare

possono essere quelle per il medico curante e per

la prescrizione di farmaci

Gestione dei problemi

sanitari

Possibilità di identificare i problemi sanitari del

paziente

(*)Data la complessità delle singole funzioni dei moduli SW in oggetto, non è possibile ricondurre alla

suddetta schematizzazione il dettaglio descrittivo dei dati elaborati dall’Oggetto, che peraltro sono

desumibili dalla relativa manualistica, disponibile presso Asl2.

Modulo Ricetta Rossa

Nome Descrizione Dati

Input Output

Ricerca Paziente Ricerca in anagrafica del paziente

Gestione Anagrafica Inserimento/Modifica dati anagrafici del

paziente

Ricetta Farmaci Compilazione ricetta farmaci

Ricetta Prestazioni Compilazione ricetta prestazioni

Worklist Ricette Visualizzazione ricette rosse prescritte al

paziente con funzioni di conferma / stampa /

annullamento / duplicazione

Gestione Profili Impostazione di profili farmaci / prestazioni

personali dell’utente

Invio Ricette Procedura di invio alla regione delle ricette

confermate / annullate




ceduti in riuso

Modulo Piani Terapeutici

Nome Descrizione Dati

Input Output

Ricerca paziente Ricerca di un paziente per cognome, nome, data

di nascita, codice fiscale

Inserimento paziente Inserimento di un paziente non presente

nell’anagrafica centrale

Modifica paziente Modifica dell’anagrafica locale di un paziente

Inserimento piano

terapeutico

Inserimento di un piano terapeutico per il

paziente selezionato

Inserimento piano

terapeutico extra

regione

Inserimento di un piano terapeutico extra regione

per il paziente selezionato

Visualizzazione piani

terapeutici del

paziente

Visualizzazione di una worklist con i dati

fondamentali dei piani terapeutici inseriti per un

paziente. Possibilità di filtrare per data

inserimento, stato (Attivo, chiuso, scaduto), piani

prescritti dal medico autenticato, piani prescritti

aziendalmente, piani presenti sul repository

regionale

Visualizzazione

singolo piano

terapeutico

Visualizzazione nel dettaglio di un singolo piano

inserito

Modifica piano Modifica di un singolo piano

Rinnova piano Rinnovo di un singolo piano

Duplica piano Duplica un singolo piano

Firma piano Firma un piano registrato in precedenza

Chiudi piano Chiude un piano inserito in precedenza

1.2.4 Servizi o procedure implementati/e

Nome servizio Descrizione sintetica Destinatari del servizio

(**)

Cartella di

Ricovero

Gestione dell’intero percorso clinico del

paziente dal suo ingresso presso la struttura di

ricovero (anche in fase di pre-spedalizzazione)

alla sua dimissione (comprensiva di gestione

degli accertamenti in prosecuzione di ricovero)

Differenziazione dei percorsi in funzione delle

tipologie di ricovero (ordinario, DH, etc.). La

gestione comprende sia l’informatizzazione

delle attività infermieristiche che di quelle

mediche, con separazione dei compiti e delle

responsabilità e stretta interconnessione fra le

differenti strutture sanitarie che interagiscono

con il paziente. Il modulo si avvale altresì

Personale della PA




ceduti in riuso

della funzione di order entry unificato, che

consente da un unico punto di accesso di

indirizzare richieste di prestazioni, consulenze

ed accertamenti diagnostici presso le principali

strutture aziendali erogatrici di tali servizi.

Sostituisce i molteplici sistemi di order entry

di ciascun verticale aziendale integrandoli in

un unico sistema di instradamento richieste ed

acquisizione dei relativi esiti.

Ricetta Rossa

Prescrizione delle prestazioni e dei farmaci in

modalità elettronica, con sistema automatico di

supporto alla corretta e completa compilazione

della ricetta e con utilizzo del NRE (numero

ricetta elettronico) in connessione con il SAR

di Regione Liguria per il successivo invio al

SAC ministeriale.

Personale della PA

Altre PA

Piani

Terapeutici

Compilazione informatizzata dei piani

terapeutici per i principi attivi a ciò soggetti,

con sistema informatizzato di supporto alla

corretta e completa compilazione e firma

digitale del documento; relativa trasmissione

ad apposito repository regionale mediante

servizi di tipo web services.

Personale della PA

Altre PA

1.2.5 Tipologia di contratto

La Azienda Sanitaria n. 2 Savonese ha commissionato lo sviluppo dei suddetti moduli SW, su

proprie specifiche e sotto il proprio coordinamento operativo sia in fase di sviluppo che di

deployment, alla società El.Co. S.r.l. di Cairo Montenotte (SV), già fornitore del proprio

sistema RIS (Polaris / Whale) e di ulteriori applicativi sanitari in uso presso molteplici

strutture aziendali.

Il contratto sottoscritto prevede la proprietà esclusiva del codice sorgente di tutti i moduli SW

commissionati da parte di Asl2 Savonese, la quale ha pertanto titolarità alla relativa cessione

in riuso.

Data la rilevante complessità del sistema, la cessione dello stesso potrà avvenire in una delle

forme di riuso normativamente previste, anche avvalendosi del supporto di Asl2 Savonese.

1.2.6 Tipologia di benefici economici ottenuti dall’amministrazione con l’uso

dell’Oggetto

Diretti :

Riduzione spese di attività sul territorio

Riduzione costi di pubblicazione e distribuzione di materiali stampati

Riduzione dei costi per incremento efficienza ed efficacia dell’azione amministrativa

Indiretti :

Riduzione di tempi di lavorazione delle pratiche

Riduzione del tasso di errori materiali e/o della quantità di reclami




ceduti in riuso

Riduzione della necessità di richiedere e/o raccogliere più volte gli stessi dati

Altro: Maggiore tempestività ed efficacia nel processi di diagnosi e cura del paziente

1.2.7 Amministrazioni che riutilizzano l’Oggetto

Hanno avviato in via sperimentale un parziale riuso del sistema UNI.SYS, nelle more del

perfezionamento del presente iter, le seguenti Aziende:

Azienda Sanitaria n. 3 Genovese, limitatamente al modulo Ricetta Rossa;

Azienda Sanitaria n. 1 Imperiese, limitatamente al modulo Piani Terapeutici..

1.2.8 Amministrazioni interessate al riuso dell’Oggetto

Hanno formalmente manifestato il proprio interesse al riuso del sistema UNI.SYS, per tutti o

parte dei moduli SW sopra descritti, le seguenti Aziende:

Azienda Sanitaria n. 3 Genovese, per i restanti moduli che compongono il sistema (ivi

inclusi quelli in fase di sviluppo SW / collaudo);

Azienda Sanitaria n. 5 Spezzina;

Ospedale Evangelico Internazionale di Genova.

1.2.9 - Amministrazioni idonee al riuso dell’Oggetto

Aziende Sanitarie

Altro: Strutture sanitarie e socio-sanitarie pubbliche o convenzionate, Aziende

Ospedaliere

1.2.10 Motivazioni che indussero l’amministrazione a implementare l’Oggetto

Norma primaria

Legge regionale

Integrazione con altro software/classe

Altro: esigenza di ottimizzazione dei processi aziendali, di diagnosi e cura, con

incremento dell’efficienza complessiva e contenimento dei costi di gestione

1.2.11 Costi sostenuti per l’implementazione e la manutenzione dell’Oggetto (IVA esclusa)

Costo totale dell’Oggetto, (analisi e specifica requisiti, progettazione tecnica, codifica,

test e integrazione, installazione, esercizio) € 1.051.500,00 di cui interni, 191.400,00 €

Costo esterno dell’Oggetto, (componenti proprietarie utilizzate dall’Oggetto ceduto in

riuso, quali, ad esempio, RDBMS, Middleware, Componenti specializzati, etc) € 36.000,00

Costo annuo della manutenzione correttiva: € 74.265,00 di cui:

costi interni, € 0

costi esterni, € 74.265,00

Nota:

Il sistema presuppone la disponibilità da parte dell’utilizzatore di licenza Oracle attiva

sui sistemi centrali presso i quali è installato, i cui costi risultano variabili in funzione

dell’architettura dei sistemi stessi.




ceduti in riuso

Il sistema di order entry unificato si basa sull’architettura del sistema di order entry RIS

denominato Whale, fornito dalla ditta El.Co. S.r.l., già acquisito da Asl2 Savonese nel

più ampio contesto della fornitura dei sistemi RIS /

1.2.12 Time line del progetto

Durata dell’intero progetto: 36 mesi

Data di primo rilascio: 05 / 2011

Data di rilascio ultima evolutiva: 12 / 2012

Data di rilascio ultima correttiva: 12 / 2012

1.2.13 Link al sito dove è descritto l’intero progetto che ha prodotto l’Oggetto

Il sistema non è attualmente linkabile dal sito internet aziendale.

1.2.14 Competenze sistemistiche e applicative richieste per l’installazione

dell’Oggetto.

Per procedere con l’installazione dell’oggetto bisogna disporre di nozioni relative alla

componentistica hardware e software dei computer e delle infrastrutture di rete, garantendone

il corretto funzionamento.

Deve essere garantita la sicurezza delle macchine e dei dati che contengono, oltre a definire le

procedure di autorizzazione agli accessi degli utenti e quelle di organizzazione dei dati

all’interno dell’ambiente software.

Per procedere con l’installazione dell’oggetto è necessario che il personale sistemistico abbia

competenze relative ai sistemi operativi che si vogliono implementare, competenze sul

database Oracle che si desidera installare sul sistema operativo, competenze sull’applicativo

server Apache Tomcat

1.2.15 Vincoli relativi all’installazione ed alla fruizione dell’Oggetto

L’oggetto è sviluppato in ambienti multi-piattaforma ed è in grado quindi di supportare tutti i

sistemi operativi sui quali sia possibile installare Oracle Java e Oracle Database nelle versioni

indicate.

Alcuni esempi di sistemi operativi supportati sono Windows Server 2008, Linux RedHat

Enterprise 5 e Sun Solaris 10.

1.2.16 Elementi di criticità

Il sistema, essendo sviluppato su piattaforma web, presuppone l’esistenze di adeguata e

capillare connessione di rete per l’accesso allo stesso, nonché la diffusione di impianti wi-fi in

caso di utilizzo dell’applicativo a bordo letto

1.2.17 Punti di forza

Il rilevante punto di forza del progetto UNISYS è costituito dall’unificazione, all’interno di un

unico ambiente, di tutte le informazioni sanitarie inerenti i contatti del paziente con l’Azienda,

consentendo:

l’implementazione di un sistema di single sign on, con identificazione del paziente

mediante smart card;




ceduti in riuso

la gestione unificata dei profili di abilitazione;

la possibilità di condivisione immediata delle informazioni fra diversi operatori e

strutture;

la miglior gestione dell’appropriatezza in fase prescrittiva, stante la consultabilità on line

di tutti i referti diagnostici prodotti;

la miglior gestione del rischio clinico, grazie alla ripartizione dei compiti e delle funzioni

fra differenti figure professionali e la registrazione on line in tempo reale degli eventi

clinici, con relativa firma digitale.

1.2.18 Livello di conoscenze/competenze ICT del personale

dell’amministrazione cedente Alto

1.2.19 Disponibilità dell’amministrazione cedente Fornire assistenza ICT all’amministrazione utilizzatrice

Erogare formazione al personale dell’amministrazione utilizzatrice

Eseguire la manutenzione correttiva

Eseguire la manutenzione correttiva ed evolutiva

1.2.20 Modalità di riuso consigliate Il presente sistema è ceduto in riuso, a discrezione del richiedente, in una delle modalità

normativamente previste.

La definizione puntuale e la quantificazione economica connessa agli eventuali servizi

richiesti ad Asl2 Savonese dall’Amministrazione utilizzatrice saranno definiti di caso in caso,

in funzione delle specifiche esigenze da quest’ultima manifestate




ceduti in riuso

2 SEZIONE 2 – CONTESTO APPLICATIVO

2.1 Qualità globale della documentazione di progetto

2.1.1 Documentazione disponibile

1. Specifiche dei requisiti funzionali

2. Specifiche dei requisiti non funzionali

3. Specifiche dei requisiti inversi

4. Specifiche dei casi d’uso

5. Architettura logico funzionale dell’Oggetto

6. Architettura hardware dell’Oggetto

7. Architettura TLC dell’Oggetto

8. Test e collaudo - Documento tecnico

9. Modulo Cartella di ricovero- Manuale di Gestione

10. Modulo Piani Terapeutici- Manuale di Gestione

11. Modulo Ricette Rosse- Manuale di Gestione

12. Modulo Cartella di ricovero- Manuale utente

13. Modulo Piani Terapeutici- Manuale utente

14. Modulo Ricette Rosse - Manuale utente

2.1.2 Livello di documentazione

Il livello qualitativo della documentazione disponibile è adeguato in funzione dei relativi

obiettivi. Data la complessità del sistema, sia dal punto di vista delle funzioni rese disponibili,

sia dell’architettura complessiva, si ritiene utile concedere la disponibilità di Asl2 Savonese

all’erogazione di servizi a supporto della riusabilità del sistema presso altre Amministrazioni,

in una delle forme normativamente previste, al fine di consentire all’Amministrazione

interessata al riuso la possibilità di acquisire un supporto operativo.

2.2 Requisiti

2.2.1 Specifica dei requisiti funzionali

La specifica dei requisiti funzionali: è disponibile e contiene i capitoli indicati nella tabella

seguente anche se ordinati in modo diverso;

Descrizione capitolo %

Glossario delle definizioni e acronimi utilizzati o riferimento al glossario del progetto 100

Attori coinvolti, con la specificazione del numero e della tipologia degli utenti coinvolti 100

Classificazione dei requisiti funzionali 100

Codifica (attributi) dei requisiti funzionali 100

Correlazione alle specifiche dei casi d’uso 80

Eventi coinvolti nel requisito 80

Componenti hardware e Oggetto dell’architettura complessiva del sistema che si intende

realizzare

80

Analisi dei dati - schema concettuale iniziale 50

Analisi dei dati - stima iniziale dei volumi 0




ceduti in riuso

Evidenza e descrizione delle modifiche in corso d’opera 100

Riferimenti a ulteriore documentazione di interesse prodotta o preesistente 80

2.2.2 Specifica dei requisiti non funzionali

La specifica dei requisiti non funzionali: è disponibile e contiene i capitoli indicati nella

tabella seguente anche se ordinati in modo diverso



Classificazione dei requisiti non funzionali 100

Vincoli sui componenti hardware e Oggetto dell’architettura complessiva del sistema che si

intende realizzare

100



2.2.3 Specifica dei requisiti “inversi”

La specifica dei requisiti inversi: è disponibile e contiene i capitoli indicati nella tabella

seguente anche se ordinati in modo diverso



Classificazione dei requisiti inversi 100

Eventi coinvolti nel requisito 100

Analisi dei dati che non devono essere trattati % 80



2.2.4 Casi d’uso

La specifica dei casi d’uso correlata ai requisiti funzionali: è disponibile e contiene i capitoli

indicati nella tabella seguente anche se ordinati in modo diverso


Breve descrizione del caso d’uso 100

Elenco degli attori con indicazione dell’attore principale 100

Precondizioni 100

Flusso base degli eventi 100

Eccezioni 80

Post-condizioni 80

Flussi alternativi 0

Sottoflussi 80

Informazioni aggiuntive 80

Scenari 0




ceduti in riuso

3 SEZIONE 3 – CONTESTO TECNOLOGICO

3.1 Progettazione

3.1.1 Studio di fattibilità

Lo studio di fattibilità: non è disponibile

3.1.2 Architettura logico funzionale dell’Oggetto

L’architettura logico funzionale dell’Oggetto: è disponibile, è descritta in modo discorsivo e

contiene i capitoli indicati nella tabella seguente anche se ordinati in modo diverso


Descrizione dei sottosistemi funzionali 100

Descrizione, per ciascun sottosistema, del modello logico-funzionale del Oggetto:

o Sottosistemi applicativi, 100

o Strutture di dati e relativi attributi 100

Descrizione, per ciascun sottosistema, del modello delle responsabilità funzionali

(comportamento statico del sw):

o Classi che lo compongono, con relativi metodi e attributi 100

o Casi d’uso dell’applicazione 100

Descrizione, per ciascun sottosistema, del modello dei processi eseguito dal

sistema/Oggetto (comportamento dinamico dell’Oggetto):

o Interfacce verso altri sistemi/programmi 80

o Esposizione di interfacce standard di interoperabilità 80

o Indipendenza delle componenti applicative utilizzate, ovvero presenza di criticità 80

o Impiego di interfacce utente aderenti agli standard di usabilità 80

o Indipendenza delle classi di interfaccia dal browser utilizzato 80

o Indipendenza delle classi di accesso dal RDBMS utilizzato 80

Descrizione, per ciascun sottosistema, del modello comportamentale (diagramma degli

stati) dove sono referenziati gli eventuali riferimenti normativi delle procedure

amministrative informatizzate

100

Descrizione dell’architettura software

Le versioni di Oracle compatibili con i moduli dell’Oggetto sono la 10.2.0.5 o la 11.2.0.3. Per

quanto riguarda le opzioni di installazione sono sicuramente da includere Oracle Text e

Xmldb.

Altre funzioni sicuramente potranno essere richieste in seguito a seconda delle specifiche

necessità dell’utilizzatore.

I parametri di inizializzazione sono quelli standard di Oracle.

La gestione della memoria viene fatta gestire in maniera automatica a Oracle, seguendo gli

advice dei report interni Awr. Si stima comunque che almeno 2 gb minimi siano necessari.

Nelle installazioni con personalizzazioni più complesse è possibile raggiungere quote di sga




ceduti in riuso

variabili tra 16-20gb e pga variabile da 1 gb a 5 gb. Presso Asl2, grazie all’ampia cache

(16gb) disponibile sullo storage, la sga attualmente in uso è 1,2gb.

MODULO RICETTE ROSSE: di seguito si propone lo schema logico delle tabelle

componenti il modulo:

MODULO PIANI TERAPEUTICI: di seguito si propone lo schema logico delle tabelle

componenti il modulo:




ceduti in riuso

MODULO CARTELLA DI RICOVERO: di seguito si propone lo schema logico delle

tabelle componenti il modulo:

3.1.3 Architettura hardware dell’Oggetto

L’architettura hardware dell’Oggetto: è disponibile, è descritta in modo discorsivo e contiene

i capitoli indicati nella tabella seguente anche se ordinati in modo diverso


Parametri dimensionali minimi:

o Potenza di calcolo 100

o RAM 100

Sistema operativo

o Deployment del sistema/Oggetto 100

o Middleware 100

Librerie esterne 100

RDBMS 100

Descrizione dell’architettura hardware

Database Server




ceduti in riuso

Si richiede l’uso di hardware classe server che possa supportare adeguatamente il carico

di I/O generato dall’applicazione, variabile in base al numero di utenti e funzionalità

utilizzate.

I requisiti per l’installazione del database dipendono dal sistema operativo scelto e dalla

versione di Oracle che si desidera implementare, in compatibilità con le certificazioni

ottenute dai Produttori del sistema operativo per il database Oracle.

Application Server

Memoria minima: 4GB di RAM

40gb hard disk

Le macchine possono essere sia fisiche sia virtuali, non ci sono requisiti specifici in

merito, sicuramente per la semplicità di deployment e versioning sono preferite le

ultime.

Oltre al S.O. di base è necessario un software di clustering con il quale viene gestito il

failover del servizio di bilanciamento e il relativo ip virtuale assegnato, tra le n

macchine che compongono il cluster di Application Servers.

Client

Memoria minima: 1GB di RAM

Connettività: scheda di rete 100Mb

Visulizzazione: scheda video e monitor per una risoluzione ottimale 1280x768

I rimanenti requisiti hardware sono quelli per l’installazione dei sistemi operativi

supportati (WindowsXP SP3,

Windows Vista, Windows Seven)

3.1.4 Architettura TLC dell’Oggetto

L’architettura di telecomunicazione dell’Oggetto: è disponibile, è descritta in modo discorsivo

e contiene i capitoli indicati nella tabella seguente anche se ordinati in modo diverso


Parametri dimensionali minimi 100

Protocolli di comunicazione 100

Descrizione dell’architettura di telecomunicazioni

La comunicazione si basa sull’utilizzo del protocollo TCP/IP; è quindi richiesta

un’infrastruttura in grado di gestire tale protocollo e di poter supportare in casi specifici

la mobilità dell’utente

3.2 Realizzazione

3.2.1 Manualistica disponibile

1) Modulo Cartella di Ricovero – Manuale di Gestione;

2) Modulo Ricette Rosse – Manuale di Gestione;




ceduti in riuso

3) Modulo Piani Terapeutici – Manuale di Gestione.

I manuali citati contengono le informazioni necessarie all’installazione dell’ambiente dedicato

all’Oggetto e alla configurazione di ciascuno dei suoi moduli.

3.2.2 Case – Computer aided software engineering

Non sono stati utilizzati strumenti di Case per lo sviluppo dell’oggetto

3.2.3 Ciclo di sviluppo

L’oggetto prevede un ciclo di vita, in linea con il modello a cascata (‘document based’),

composto dai seguenti step:

Analisi;

Progettazione;

Implementazione;

Test;

Collaudo;

Rilascio

3.2.4 Standard utilizzati

Non sono stati adottati standard, all’interno delle varie fasi del ciclo di vita dell’oggetto

3.2.5 Linguaggio di programmazione

I moduli sono stati sviluppato lato Server, utilizzando il linguaggio Java (nello specifico Java

servlet) e come "web server/motore Java servlet" Tomcat dalla versione 7 in avanti, mentre la

versione supportata dal "motore" è Java Jdk 1.6.x. Le pagine Web sono generate nel

linguaggio HTML con componenti "java script" versione 5.6.

Sugli applicativi sono inoltre integrate, mediante l’installazione di particolari ActiveX,

componenti quali firma digitale e stampe.

3.3 Test e collaudo

3.3.1 Specifiche dei test funzionali e non funzionali

Le specifiche dei test dell’Oggetto: sono disponibili, sono descritte in modo discorsivo e

contengono i capitoli indicati nella tabella seguente anche se ordinati in modo diverso


Integrazione del Piano di Test 100

Codifica e/o standard di descrizione delle informazioni e del livello dei contenuti adottata/i

nella specifica

100

Condizioni di test previste (descrizione di ogni condizione): 80

Precondizioni necessarie per:

o Rendere autoconsistente e rieseguibile il test 80

o Segnalare la sua relazione con altri test o funzionalità (regole di propedeuticità) 80

Obiettivi dei test per ogni componente, caratteristiche indagate e il tracciamento

dei test rispetto ai requisiti funzionali e non funzionali

100

Condizioni particolari da aggiungere alle basi dati di test 80




ceduti in riuso

Sequenza di azioni da svolgere 100

Eventuali ulteriori combinazioni di dati da utilizzare, sulla medesima sequenza di azioni

descritta, per verificare la stessa o altre condizioni di test

80

Verifica del test 100

3.3.2 Livello di copertura dei test rispetto ai requisiti da valutare

Al fine di valutare quantitativamente il livello di copertura dei test rispetto ai requisiti da

valutare, l’amministrazione cedente fornisce le seguenti coppie di valori in suo possesso:

Numero totale di requisiti funzionali: 37

Numero di requisiti funzionali sottoposti a test: 37

Numero totale di requisiti non funzionali: 4 (Usabilità, Affidabilità, Performance,

Supportabilità)

Numero di requisiti non funzionali sottoposti a test :3

3.3.3 Piano di test;

Il piano di test dell’Oggetto: è disponibile, è descritto in modo discorsivo e contiene i capitoli

indicati nella tabella seguente anche se ordinati in modo diverso



Tecniche utilizzate per la progettazione e l’esecuzione dei test 100

Tipologie di test cui sarà sottoposto ogni componente dell’Oggetto, con i criteri di ingresso

e uscita da ogni test

100

Il processo di testing adottato - Attività e Sottoattività previste 100

Componenti dell’Oggetto da sottoporre a verifica 100

Livello di copertura dei test 100

Metriche da utilizzare 80

Numero di cicli di test previsti 80

Livello di rischio (classe di rischio) associato a ogni test 80

Legame eventuale con altri processi presenti nell’Oggetto 80

Mappatura con requisiti (funzionali e non) e gli attributi definiti 80

Risorse professionali e strumentali che verranno impiegate per l’effettuazione di

ogni test (ruoli e responsabilità)

100

Modalità di esecuzione, di registrazione dei risultati dei test, dei difetti rilevati e di

rendicontazione dei test

80

Modalità di gestione delle anomalie 80

Pianificazione temporale dei test con indicazione del tempo stimato per l’esecuzione di

ogni singolo test

80

Riferimenti eventuali a ulteriore documentazione di interesse prodotta o preesistente 0




ceduti in riuso

3.3.4 Specifiche di collaudo

Le specifiche di collaudo dell’Oggetto: sono disponibili, descritte in modo discorsivo e

contengono i capitoli indicati nella tabella seguente anche se ordinati in modo diverso


Strategia, metodologia e obiettivi del collaudo 100

Specificazione dei requisiti dell’hardware e dell’Oggetto di base e dei vincoli dell’ambiente

di collaudo

100

Documentazione dei casi di test:

o Setup ( requisiti per avviare il test ) 80

o Sequenza delle azioni da svolgere utente/macchina 80

o Riesecuzione (eventuale) per condizioni diverse 80

o Altre verifiche per accertare l’esito dei test 80

Elenco dei test con evidenza della copertura rispetto ai requisiti e al rischio 100

Descrizione dei test formali, funzionali, non funzionali da eseguire, con particolare

attenzione ai test specifici per la validazione dei requisiti

100

Descrizione dei test automatici eventualmente realizzati e delle modalità di impiego 80

Le metriche ed indicatori di qualità e relative soglie 80

I criteri di accettazione da parte dell’Amministrazione 100

I contenuti previsti nei verbali di collaudo 100

3.4 Installazione, uso e manutenzione

3.4.1 Procedure di installazione e configurazione

Le procedure di installazione e configurazione dell’Oggetto: sono disponibili, descritte in

modo discorsivo e contengono i capitoli indicati nella tabella seguente anche se ordinati in

modo diverso


Verifiche preliminari e ex post 50 Livelli di automazioni necessari 50 Procedure di caricamento o porting della base informativa 20

3.4.2 Manuale di gestione

Il manuale di gestione dell’Oggetto: è disponibile ed è descritto in modo discorsivo

Indice del manuale di gestione

Modulo Ricette Rosse 1. INTRODUZIONE

2. SCOPO DEL DOCUMENTO 3

3. ARCHITETTURA DEL MODULO RICETTE ROSSE 3.1 AMBIENTE DI SVILUPPO

3.2 SISTEMI OPERATIVI E BASI DI DATI

3.3 STRUTTURA DEL DATABASE UTILIZZATO

4. CONFIGURAZIONE AMBIENTI DI SVILUPPO




ceduti in riuso

4.1 CONFIGURAZIONE DATABASE

4.2 CONFIGURAZIONE APPLICATION SERVER

5. CREDENZIALI DI AUTENTICAZIONE UNI.SYS

6. MODALITA D’INSTALLAZIONE E CONFIGURAZIONE 6.1 INSERIMENTO UTENTI

6.2 INSERIMENTO PAZIENTE

6.3 INSERIMENTO FARMACI

6.4 INSERIMENTO FARMACO PHT

6.5 INSERIMENTO PRESTAZIONE

6.6 INSERIMENTO BRANCA

6.7 INSERIMENTO ESENZIONE

6.8 INSERIMENTO CODIFICA ICD

7. INTEGRAZIONE CON IL SAL

Modulo Piani Terapeutici

1. INTRODUZIONE

2. SCOPO DEL DOCUMENTO

3. ARCHITETTURA DEL MODULO PIANI TERAPEUTICI 3.1 AMBIENTE DI SVILUPPO



4. CONFIGURAZIONE AMBIENTI DI SVILUPPO 4.1 CONFIGURAZIONE DATABASE



6. MODALITA’ D’INSTALLAZIONE E CONFIGURAZIONE0 6.1 INSERIMENTO UTENTI


6.3 INSERIMENTO ASSOCIAZIONI SPECIALITÀ – PRINCIPIO ATTIVO

6.4 INSERIMENTO CODIFICHE

6.5 INSERIMENTO STRUTTURE

6.6 SALVATAGGIO PT


1. INTRODUZIONE .

2. SCOPO DEL DOCUMENTO

3. ARCHITETTURA DEL MODULO CARTELLA DI RICOVERO3 3.1 AMBIENTE DI SVILUPPO



4. CONFIGURAZIONE AMBIENTI DI SVILUPPO 4.1 CONFIGURAZIONE DATABASE



6. MODALITA D’INSTALLAZIONE E CONFIGURAZIONE 6.1 INSERIMENTO E CONFIGURAZIONE REPARTO

6.2 INSERIMENTO E CONFIGURAZIONE UTENTI

6.3 INSERIMENTO E CONFIGURAZIONE STANZE E LETTI REPARTO


6.5 CONFIGURAZIONE TERAPIA




ceduti in riuso

3.4.3 Manuale utente

Il manuale utente fornisce una descrizione generale dell’applicazione e una guida operativa

all’utilizzo delle singole funzionalità dell’Oggetto utilizzabili dall’utente.

Il manuale utente dell’Oggetto: è disponibile ed è descritto in modo discorsivo

Indice del manuale utente

Modulo Ricette Rosse

1. ACCESSO ALL’APPLICATIVO

2. RICERCA PAZIENTE

2.1 Inserimento Nuovo Paziente..

3. INSERIMENTO RICETTA ROSSA FARMACI

4. INSERIMENTO RICETTA ROSSA PRESTAZIONI

5. VISUALIZZA WORKLIST RICETTE PAZIENTE

6. GESTIONE PROFILI

Modulo Piani terapeutici


2. RICERCA PAZIENTE

2.1 Inserimento Nuovo Paziente

3. INSERIMENTO PIANO TERAPEUTICO

4. VISUALIZZA PT PAZIENTE



2. PROSPETTO DEGENTI

3. RICERCA PAZIENTI.

4. RICERCA RICOVERATI

4.1 Compilazione Cartella Paziente




ceduti in riuso

4 SEZIONE 4 – QUALITÀ DELL’OGGETTO

4.1 Piano di qualità

4.1.1 Contenuti del piano

Il piano di qualità dell’Oggetto: non è disponibile

4.1.2 Descrizione della qualità

Il fornitore esterno incaricato dello sviluppo dell’applicativo è certificato UNI EN ISO

9001:2000 per i processi di sviluppo SW.

4.2 Profilo di qualità dell’Oggetto

Al fine di valutare quantitativamente gli attributi per la valutazione della qualità dell’Oggetto,

l’amministrazione cedente fornisce i seguenti valori in suo possesso:

4.2.1 Modularità

Numero di componenti auto consistenti dell’Oggetto: 3, in fase di successiva

implementazione

Numero totale di componenti dell’Oggetto: 3, in fase di successiva implementazione

4.2.2 Funzionalità

4.2.2.1 Interoperabilità - Protocolli di comunicazione

Numero dei protocolli di comunicazione dei sistemi/programmi con i quali

l’applicazione deve poter colloquiare: 7

Numero dei protocolli di comunicazione correttamente implementati (ovvero che hanno

superato i relativi test) all’interno dell’Oggetto: 6

4.2.3 Maturità

Il valore del requisito è determinato dalla concorrenza dei seguenti attributi elementari.

4.2.3.1 Densità dei guasti durante i test

Numero di guasti rilevati durante i test: 15

Numero di casi di test eseguiti: circa 500

4.2.3.2 Densità dei guasti

Numero di guasti rilevati durante il primo anno di esercizio dell’Oggetto: 10

Numero totale di FP dell’Oggetto: 37

4.2.4 Usabilità





ceduti in riuso

4.2.4.1 Comprensibilità – Completezza delle descrizioni

Numero di funzioni descritte nel manuale utente: 37

Numero totale di funzioni: 37

4.2.4.2 Apprendibilità - Esecuzione delle funzioni

Numero di funzioni che sono state eseguite correttamente dall’utente consultando la

documentazione: 37

Numero di funzioni provate: 37

4.2.4.3 Apprendibilità- Help on-line

Numero di funzioni per le quali l’help on-line è correttamente posizionato: 0

Numero di funzioni provate: 0

4.2.4.4 Configurabilità

Numero totale di parametri di configurazione: circa 60. Si evidenzia peraltro come, data

la complessità del progetto, risulti difficile stimare correttamente la totalità dei

parametri di configurazione, in quanto ogni sezione dell’Oggetto stesso è configurabile

totalmente ed in modo capillare


4.2.5 Manutenibilità


4.2.5.1 Conformità allo standard di Progettazione

Numero di deviazioni dagli standard di progettazione 0

Numero dei diagrammi progettuali realizzati 4

4.2.5.2 Conformità agli standard di codifica

Numero di deviazioni dallo standard di codifica 0

Numero di linee di codice esaminate: 230.000

4.2.5.3 Analizzabilità - Generale

Numero totale di commenti: 59.560

Numero totale di linee di codice: 300.000

4.2.5.4 Testabilità - Generale

Numero di funzioni con associato almeno un caso di test: 37

Numero totale di funzioni elementari: 37

4.2.5.5 Testabilità - Automatismi

Numero di casi di test automatizzati con opportune funzioni di test interne: 0




ceduti in riuso

Numero totale di casi di test: 500

4.2.6 Portabilità


4.2.6.1 Adattabilità– Strutture dei dati

Numero di strutture dati trasferibili tra DB commerciali senza modifiche 0

Numero totale strutture dati: 72

4.2.6.2 Adattabilità – Funzioni e organizzazione

Numero di funzioni indipendenti dalla organizzazione dell’amministrazione:32


4.2.6.3 Installabilità Generale

Numero di step di installazione descritti nel manuale di installazione 23

Numero totale di step di installazione 23

4.2.6.4 Installabilità - Automatizione delle procedure

Numero di step automatizzati descritti nel manuale di installazione:1

Numero totale di step di installazione 23

4.2.6.5 Installabilità - Multiambiente

Numero totale degli ambienti operativi nel quale l’Oggetto può essere installato per i

quali l’Oggetto dispone di funzioni di installazione: 3

Numero totale degli ambienti operativi su cui può essere installato: 3




ceduti in riuso

5 SEZIONE 5 – FORMAZIONE

5.1 Costi sostenuti per la formazione

Costo totale della formazione: € n.a.

Costi interni: € n.a. di cui:

Costi per i docenti, € n.a.

Costi per il materiale didattico, € n.a.

Costi esterni: € n.a.di cui:

Costi per i docenti, € n.a.

Costi per il materiale didattico, € n.a.

Nota:

I costi sostenuti da Asl2 Savonese per la formazione e deployment non risultano facilmente

quantificabili né significativi a fini di riuso in quanto all’esecuzione delle relative attività ha

concorso il fornitore esterno El.Co., nel più ampio contesto del contratto di partnership

instaurato con tale società. Ai fini della quantificazione dei possibili costi presso una

Amministrazione riutilizzatrice, si rinvia ai parametri quantitativi di cui al successivo

paragrafo 5.2

5.2 Dati quantitativi

Numero di giorni di formazione in aula per utente erogati: Formazione eseguita per

piccoli gruppi omogenei di utenti:

2 per la Cartella di ricovero

1 per Ricetta Rossa

1 per Piani Terapeutici

Numero di giorni di “training on the job” per utente erogati: Formazione eseguita per

piccoli gruppi omogenei di utenti:

da 15 a 20 giorni per Cartella di ricovero,

1 per Ricetta Rossa,

1 per Piani Terapeutici

Numero totale di utenti formati: 2.150

Numero totale di dipendenti di Asl2 Savonese utilizzatori dell’Oggetto descritto nella

presente scheda: circa 2.000

Numero totale di docenti interni impegnati nella formazione in aula: 2 (solo per quota

parte del loro impegno lavorativo)

Numero di docenti interni impegnati nella attività di training on the job: 2 (solo per

quota parte del loro impegno lavorativo)




ceduti in riuso

Numero di docenti esterni impegnati nella formazione in aula: 4

Numero di docenti esterni impegnati nella formazione training on the job: da 8 a 10

5.3 Descrizione dell’azione formativa

La formazione degli utenti è organizzata in funzione:

del profilo professionale degli operatori sanitari coinvolti (prevalentemente personale

medico ed infermieristico) e delle conseguenti funzionalità in uso a ciascuno di essi;

della necessaria compatibilità dell’attività formativa rispetto alla necessità di continuità

assistenziale ai pazienti, con conseguente esigenza di modulazione del numero di sessioni

formative, della relativa durata e degli orari di esecuzione.

La formazione in aula è pertanto programmata nelle giornate immediatamente antecedenti

all’avvio in utilizzo dell’applicativo SW, prevedendo un calendario concordato con i discenti

che tenga conto della necessaria compatibilità con le esigenze di copertura della turnistica.

I corsi di formazione sono differenziati fra personale medico e personale del comparto, al fine

di meglio finalizzare la stessa in relazione ai compiti attribuiti.

Entrambi i percorsi formativi hanno in comune l’inquadramento della logica funzionale del

sistema UNI.SYS e dei suoi obiettivi, al fine di condividerne il più possibile all’interno

dell’organizzazione le finalità ed i benefici complessivi indotti.

La formazione in aula è organizzata, in funzione delle esigenze specifiche dei destinatari,

presso aule informatizzate (di proprietà della Asl2 Savonese) ovvero mediante l’apposito

allestimento, con PC e proiettori da PC, di sale riunioni ubicate presso le singole strutture

sanitarie destinatarie della formazione (al fine di massimizzare la facilità di accesso ai

percorsi formativi da parte del personale in fase di smonto turno).

Sono resi disponibili manuali utente per ciascun modulo SW, anche scaricabili on line dal

sistema UNI.SYS.

Alla formazione in aula segue un affiancamento on the job di durata variabile in funzione

della complessità del modulo SW in fase di avviamento; la formazione è effettuata da parte di

personale dotato di adeguata professionalità ed esperienza, non solo rispetto all’utilizzo

dell’applicativo SW ma anche nell’applicazione delle logiche del sistema informatizzato

rispetto all’organizzazione dei servizi sanitari.

L’affiancamento on the job è garantito, per la cartella di ricovero (che costituisce il modulo

SW a maggiore complessità), mediante presenza on site di personale per circa n. 9 ore

giornaliere per un numero di giorni lavorativi compreso fra 15 e 20, con servizio di

reperibilità telefonica di operatori qualificati per le restanti ore (sino a copertura complessiva

7h/24)

5.4 Materiale didattico

Per la predisposizione del materiale didattico:

sono stati descritti i profili utente dell’applicativo;

sono stati definiti gli elementi per stimare il gap di competenze esistente

scheda descrittiva del programma - agid...azienda sanitaria n. 2 del savonese pagina 8 di 27 scheda...

Documents