Scheda descrittiva del programma ceduto in riuso UNI.SYS

Transcript

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 Azienda Sanitaria n. 2 del Savonese Pagina 1 di 27

2 1 SEZIONE 1 CONTESTO ORGANIZZATIVO 1.1 Generalità 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 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; Azienda Sanitaria n. 2 del Savonese Pagina 2 di 27

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 Referenti dell amministrazione cedente Responsabile dei sistemi informativi Referente/i di progetto Referente/i amministrativo Nome e cognome: Indirizzo: Tel/Cel: Nome e cognome: Indirizzo: Tel/Cel: Nome e cognome: Indirizzo: Tel/Cel: Ermanno Sacchi Ospedale S. Corona - Via XXV Aprile 38 Pietra Ligure e.sacchi@asl2.liguria.it Simona Lanza Ospedale S. Corona - Via XXV Aprile 38 Pietra Ligure s.lanza@asl2.liguria.it Simona Lanza Ospedale S. Corona - Via XXV Aprile 38 Pietra Ligure s.lanza@asl2.liguria.it Azienda Sanitaria n. 2 del Savonese Pagina 3 di 27

4 1.2 Scenario di riuso 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 Utenti fruitori dell Oggetto Numero totale di Utenti che utilizzano l Oggetto: circa 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; Azienda Sanitaria n. 2 del Savonese Pagina 4 di 27

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: Numero di Moduli: Descrizione delle funzionalità Modulo Cartella di ricovero Nome Prospetto Degenti Anamnesi Esame obiettivo Dati generali Accertamento infermieristico Descrizione Funzionalità utilizzata per assegnare ad ogni paziente il letto all interno del reparto di degenza Scheda in cui viene riportata la storia anamnestica del paziente Scheda su cui viene indicato l esame obiettivo attinente il ricovero Scheda su cui vengono memorizzate le informazioni generali del paziente e quelle dei parenti da contattare Scheda che contiene i bisogni assistenziali del paziente Dati (*) Input Output Azienda Sanitaria n. 2 del Savonese Pagina 5 di 27

6 Scale e Score Modulistica Gestione allerte Diari Rilevazioni di parametri vitali Prescrizioni e somministrazioni di terapie Gestione dei presidi Gestione delle lesioni Attività infermieristiche Lettere Schede per la gestione della valutazione del paziente sia lato medico che infermieristico Gestione moduli consenso del paziente Gestione allergie, intolleranze, positività e reazioni avverse Compilazione dei diari delle varie figure professionali Modulo per la compilazione dei parametri vitali e gestione delle allerte in base al valore rilevato 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 Modulo per la rilevazioni dei presidi (cvc, cvp, ca, peg, sng) e delle medicazioni Gestione delle lesioni da decubito, delle lesioni chirurgiche e delle restanti con relative medicazioni Gestione delle attività da pianificare ed eseguire sul paziente 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 Possibilità di identificare i problemi sanitari del paziente Scheda per la descrizione di Gestione dei problemi sanitari (*)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. Nome Ricerca Paziente Gestione Anagrafica Ricetta Farmaci Ricetta Prestazioni Worklist Ricette Gestione Profili Invio Ricette Modulo Ricetta Rossa Descrizione Ricerca in anagrafica del paziente Inserimento/Modifica dati anagrafici del paziente Compilazione ricetta farmaci Compilazione ricetta prestazioni Visualizzazione ricette rosse prescritte al paziente con funzioni di conferma / stampa / annullamento / duplicazione Impostazione di profili farmaci / prestazioni personali dell utente Procedura di invio alla regione delle ricette confermate / annullate Dati Input Output Azienda Sanitaria n. 2 del Savonese Pagina 6 di 27

7 Nome Ricerca paziente Inserimento paziente Modifica paziente Inserimento piano terapeutico Inserimento piano terapeutico extra regione Visualizzazione piani terapeutici del paziente Visualizzazione singolo piano terapeutico Modifica piano Rinnova piano Duplica piano Firma piano Chiudi piano Modulo Piani Terapeutici Descrizione Ricerca di un paziente per cognome, nome, data di nascita, codice fiscale Inserimento di un paziente non presente nell anagrafica centrale Modifica dell anagrafica locale di un paziente Inserimento di un piano terapeutico per il paziente selezionato Inserimento di un piano terapeutico extra regione per il paziente selezionato 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 nel dettaglio di un singolo piano inserito Modifica di un singolo piano Rinnovo di un singolo piano Duplica un singolo piano Firma un piano registrato in precedenza Chiude un piano inserito in precedenza Dati Input Output Servizi o procedure implementati/e Nome servizio Cartella di Ricovero Descrizione sintetica 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ì Destinatari del servizio (**) Personale della PA Azienda Sanitaria n. 2 del Savonese Pagina 7 di 27

8 Ricetta Rossa Piani Terapeutici 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. 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. 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 Personale della PA Altre PA 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 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 Azienda Sanitaria n. 2 del Savonese Pagina 8 di 27

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 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 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 Amministrazioni idonee al riuso dell Oggetto Aziende Sanitarie Altro: Strutture sanitarie e socio-sanitarie pubbliche o convenzionate, Aziende Ospedaliere 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 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) ,00 di cui interni, ,00 Costo esterno dell Oggetto, (componenti proprietarie utilizzate dall Oggetto ceduto in riuso, quali, ad esempio, RDBMS, Middleware, Componenti specializzati, etc) ,00 Costo annuo della manutenzione correttiva: ,00 di cui: costi interni, 0 costi esterni, ,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. Azienda Sanitaria n. 2 del Savonese Pagina 9 di 27

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 / 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 / Link al sito dove è descritto l intero progetto che ha prodotto l Oggetto Il sistema non è attualmente linkabile dal sito internet aziendale 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 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 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 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; Azienda Sanitaria n. 2 del Savonese Pagina 10 di 27

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 Livello di conoscenze/competenze ICT del personale dell amministrazione cedente Alto 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 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 Azienda Sanitaria n. 2 del Savonese Pagina 11 di 27

12 2 SEZIONE 2 CONTESTO APPLICATIVO 2.1 Qualità globale della documentazione di progetto 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 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 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 80 realizzare Analisi dei dati - schema concettuale iniziale 50 Analisi dei dati - stima iniziale dei volumi 0 Azienda Sanitaria n. 2 del Savonese Pagina 12 di 27

13 Evidenza e descrizione delle modifiche in corso d opera 100 Riferimenti a ulteriore documentazione di interesse prodotta o preesistente 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 100 intende realizzare Evidenza e descrizione delle modifiche in corso d opera 100 Riferimenti a ulteriore documentazione di interesse prodotta o preesistente Specifica dei requisiti inversi La specifica dei requisiti inversi: è 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 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 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 Descrizione capitolo % 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 Azienda Sanitaria n. 2 del Savonese Pagina 13 di 27

14 3 SEZIONE 3 CONTESTO TECNOLOGICO 3.1 Progettazione Studio di fattibilità Lo studio di fattibilità: non è disponibile 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 capitolo % 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 100 stati) dove sono referenziati gli eventuali riferimenti normativi delle procedure amministrative informatizzate Descrizione dell architettura software Le versioni di Oracle compatibili con i moduli dell Oggetto sono la o la 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 Azienda Sanitaria n. 2 del Savonese Pagina 14 di 27

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: Azienda Sanitaria n. 2 del Savonese Pagina 15 di 27

16 MODULO CARTELLA DI RICOVERO: di seguito si propone lo schema logico delle tabelle componenti il modulo: 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 Descrizione capitolo % 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 Azienda Sanitaria n. 2 del Savonese Pagina 16 di 27

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) 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 Descrizione capitolo % 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 Manualistica disponibile 1) Modulo Cartella di Ricovero Manuale di Gestione; 2) Modulo Ricette Rosse Manuale di Gestione; Azienda Sanitaria n. 2 del Savonese Pagina 17 di 27

18 3) Modulo Piani Terapeutici Manuale di Gestione. Scheda per la descrizione di I manuali citati contengono le informazioni necessarie all installazione dell ambiente dedicato all Oggetto e alla configurazione di ciascuno dei suoi moduli Case Computer aided software engineering Non sono stati utilizzati strumenti di Case per lo sviluppo dell oggetto 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 Standard utilizzati Non sono stati adottati standard, all interno delle varie fasi del ciclo di vita dell oggetto 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 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 Descrizione capitolo % Integrazione del Piano di Test 100 Codifica e/o standard di descrizione delle informazioni e del livello dei contenuti adottata/i 100 nella specifica 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 100 dei test rispetto ai requisiti funzionali e non funzionali Condizioni particolari da aggiungere alle basi dati di test 80 Azienda Sanitaria n. 2 del Savonese Pagina 18 di 27

19 Sequenza di azioni da svolgere 100 Eventuali ulteriori combinazioni di dati da utilizzare, sulla medesima sequenza di azioni 80 descritta, per verificare la stessa o altre condizioni di test Verifica del test 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 : 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 Descrizione capitolo % 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 100 e uscita da ogni test 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 100 ogni test (ruoli e responsabilità) Modalità di esecuzione, di registrazione dei risultati dei test, dei difetti rilevati e di 80 rendicontazione dei test Modalità di gestione delle anomalie 80 Pianificazione temporale dei test con indicazione del tempo stimato per l esecuzione di 80 ogni singolo test Riferimenti eventuali a ulteriore documentazione di interesse prodotta o preesistente 0 Azienda Sanitaria n. 2 del Savonese Pagina 19 di 27

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 Descrizione capitolo % Strategia, metodologia e obiettivi del collaudo 100 Specificazione dei requisiti dell hardware e dell Oggetto di base e dei vincoli dell ambiente 100 di collaudo 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 100 attenzione ai test specifici per la validazione dei requisiti 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 Installazione, uso e manutenzione 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 Descrizione capitolo % Verifiche preliminari e ex post 50 Livelli di automazioni necessari 50 Procedure di caricamento o porting della base informativa 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 Azienda Sanitaria n. 2 del Savonese Pagina 20 di 27

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 Scheda per la descrizione di 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 4.1 CONFIGURAZIONE DATABASE 4.2 CONFIGURAZIONE APPLICATION SERVER 5. CREDENZIALI DI AUTENTICAZIONE UNI.SYS 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 4.1 CONFIGURAZIONE DATABASE 4.2 CONFIGURAZIONE APPLICATION SERVER 5. CREDENZIALI DI AUTENTICAZIONE UNI.SYS 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 Azienda Sanitaria n. 2 del Savonese Pagina 21 di 27

22 3.4.3 Manuale utente Scheda per la descrizione di 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 1. ACCESSO ALL APPLICATIVO 2. RICERCA PAZIENTE 2.1 Inserimento Nuovo Paziente 3. INSERIMENTO PIANO TERAPEUTICO 4. VISUALIZZA PT PAZIENTE Modulo Cartella di ricovero 1. ACCESSO ALL APPLICATIVO 2. PROSPETTO DEGENTI 3. RICERCA PAZIENTI. 4. RICERCA RICOVERATI 4.1 Compilazione Cartella Paziente Azienda Sanitaria n. 2 del Savonese Pagina 22 di 27

23 4 SEZIONE 4 QUALITÀ DELL OGGETTO 4.1 Piano di qualità Contenuti del piano Il piano di qualità dell Oggetto: non è disponibile 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: 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 Funzionalità 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: Maturità Il valore del requisito è determinato dalla concorrenza dei seguenti attributi elementari Densità dei guasti durante i test Numero di guasti rilevati durante i test: 15 Numero di casi di test eseguiti: circa Densità dei guasti Numero di guasti rilevati durante il primo anno di esercizio dell Oggetto: 10 Numero totale di FP dell Oggetto: Usabilità Il valore del requisito è determinato dalla concorrenza dei seguenti attributi elementari. Azienda Sanitaria n. 2 del Savonese Pagina 23 di 27

24 Comprensibilità Completezza delle descrizioni Numero di funzioni descritte nel manuale utente: 37 Numero totale di funzioni: Apprendibilità - Esecuzione delle funzioni Scheda per la descrizione di Numero di funzioni che sono state eseguite correttamente dall utente consultando la documentazione: 37 Numero di funzioni provate: Apprendibilità- Help on-line Numero di funzioni per le quali l help on-line è correttamente posizionato: 0 Numero di funzioni provate: 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: Manutenibilità Il valore del requisito è determinato dalla concorrenza dei seguenti attributi elementari Conformità allo standard di Progettazione Numero di deviazioni dagli standard di progettazione 0 Numero dei diagrammi progettuali realizzati Conformità agli standard di codifica Numero di deviazioni dallo standard di codifica 0 Numero di linee di codice esaminate: Analizzabilità - Generale Numero totale di commenti: Numero totale di linee di codice: Testabilità - Generale Numero di funzioni con associato almeno un caso di test: 37 Numero totale di funzioni elementari: Testabilità - Automatismi Numero di casi di test automatizzati con opportune funzioni di test interne: 0 Azienda Sanitaria n. 2 del Savonese Pagina 24 di 27

25 Numero totale di casi di test: Portabilità Il valore del requisito è determinato dalla concorrenza dei seguenti attributi elementari Adattabilità Strutture dei dati Numero di strutture dati trasferibili tra DB commerciali senza modifiche 0 Numero totale strutture dati: Adattabilità Funzioni e organizzazione Numero di funzioni indipendenti dalla organizzazione dell amministrazione:32 Numero totale di funzioni: Installabilità Generale Numero di step di installazione descritti nel manuale di installazione 23 Numero totale di step di installazione Installabilità - Automatizione delle procedure Numero di step automatizzati descritti nel manuale di installazione:1 Numero totale di step di installazione 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 Azienda Sanitaria n. 2 del Savonese Pagina 25 di 27

26 5 SEZIONE 5 FORMAZIONE 5.1 Costi sostenuti per la formazione Nota: 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. 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 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: Numero totale di dipendenti di Asl2 Savonese utilizzatori dell Oggetto descritto nella presente scheda: circa 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) Azienda Sanitaria n. 2 del Savonese Pagina 26 di 27

27 Numero di docenti esterni impegnati nella formazione in aula: 4 Scheda per la descrizione di Numero di docenti esterni impegnati nella formazione training on the job: da 8 a 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 Azienda Sanitaria n. 2 del Savonese Pagina 27 di 27