Scheda descrittiva del programma ceduto in riuso UNI.SYS

(1)

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

(2)

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;

(3)

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 e.sacchi@asl2.liguria.it

 Referente/i di progetto

Nome e cognome:

Indirizzo:

Tel/Cel:

e-mail:

Simona Lanza

0196232206

s.lanza@asl2.liguria.it

 Referente/i amministrativo

Nome e cognome:

Indirizzo:

Tel/Cel:

e-mail:

Simona Lanza

0196232206

s.lanza@asl2.liguria.it

(4)

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;

(5)

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

(6)

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

(7)

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

(8)

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

(9)

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,00di 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.

(10)

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;

(11)

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 d

ell’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

(12)

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

(13)

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

Descrizione capitolo %

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

Classificazione dei requisiti non funzionali 100

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

100

Evidenza e descrizione delle modifiche in corso d’opera 100

Riferimenti a ulteriore documentazione di interesse prodotta o preesistente 80

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

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

Classificazione dei requisiti inversi 100

Eventi coinvolti nel requisito 100

Analisi dei dati che non devono essere trattati % 80

Evidenza e descrizione delle modifiche in corso d’opera 80

Riferimenti a ulteriore documentazione di interesse prodotta o preesistente 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

(14)

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

(15)

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:

(16)

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

(17)

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;

(18)

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

(19)

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

Glossario delle definizioni e acronimi utilizzati o riferimento al glossario del progetto 100 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

(20)

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

(21)

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

3.2 SISTEMI OPERATIVI E BASI DI DATI 3.3 STRUTTURA DEL DATABASE UTILIZZATO 4. CONFIGURAZIONE AMBIENTI DI SVILUPPO

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

6.2 INSERIMENTO PAZIENTE

6.3 INSERIMENTO ASSOCIAZIONI SPECIALITÀ – PRINCIPIO ATTIVO 6.4 INSERIMENTO CODIFICHE

6.5 INSERIMENTO STRUTTURE 6.6 SALVATAGGIO PT

Modulo Cartella di ricovero 1. INTRODUZIONE .

2. SCOPO DEL DOCUMENTO

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

3.2 SISTEMI OPERATIVI E BASI DI DATI 3.3 STRUTTURA DEL DATABASE UTILIZZATO 4. CONFIGURAZIONE AMBIENTI DI SVILUPPO

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.4 INSERIMENTO PAZIENTE

6.5 CONFIGURAZIONE TERAPIA

(22)

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 Modulo Cartella di ricovero

2. PROSPETTO DEGENTI

3. RICERCA PAZIENTI.

4. RICERCA RICOVERATI

4.1 Compilazione Cartella Paziente

(23)

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à

(24)

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

 Numero totale di funzioni: 37

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

(25)

 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

 Numero totale di funzioni: 37 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

(26)

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)

(27)

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