Servizio Sistemi Informativi Standard Tecnologici

Transcript

1 Servizio Sistemi Informativi Standard Tecnologici Redatto: Nucleo Gestione Innovazione e fornitori IT Versione: Data emissione: 13/01/2012 1

2 Indice Sommario Deroghe Sistemi Server Hardware Software Software di base Application Server Sistemi di autenticazione: Single Sign-On Servizi RDBMS Situazione attuale Configurazione Standard Standard internazionali Standard di sicurezza Meccanismi di sicurezza standardizzati da ISO/IEC/JTC1/SC Standard nazionali Posta Elettronica Certificata (PEC) La normativa di riferimento Le regole tecniche Carta Nazionale dei Servizi La normativa di riferimento Le regole tecniche Firma digitale e conservazione sostitutiva La normativa di riferimento e le regole tecniche Standard internazionali di Informatica medica TC HL DICOM IHE UNI CORBAMED GEHR Codifiche Altri standard per l identificazione del paziente Altri standard per la comunicazione Standard per la definizione di indicatori di qualità e linee guida Realizzazione ed acquisizione di applicazioni Metodologia per lo studio e la realizzazione del software Requisiti non-funzionali Interoperabilità Portabilità Aderenza a Standards I.T Look and feel Manutenibilità Scalabilità e Performance Affidabilità, Disponibilità e Sicurezza

3 5.1.2 UP Metodologia per lo studio e la realizzazione del database Progettazione del database UML Architettura applicativa Architettura del sistema Partizionamento dell applicazione Presentation Tier Middle Tier Enterprise Information System Tier Architetture dei sistemi settoriali e di servizio Integrazione dati: protocolli per il trasporto dati Web Services WSDL SOAP Registry Service Integrazione con altri sistemi Erogazione di applicazioni in modalità Application Service Provider (ASP)...35 Browser standard...35 AJAX...36 HTML Flash Sicurezza e privacy Conservazione sostitutiva Qualità dei beni e dei servizi ICT

4 Sommario Obiettivo del presente documento è definire le linee guida sugli standard tecnologici informatici della Azienda Provinciale per i Servizi Sanitari di Trento. Essendo il contesto tecnologico in continua evoluzione questo documento è da considerarsi valido fino all emissione di una versione successiva. 4

5 1 Deroghe Eventuali deroghe agli standard enunciati devono essere richieste per iscritto al Servizio Sistemi Informativi che si riserva la possibilità di accettare o respingere la proposta. 5

6 2 Sistemi Server 2.1 Hardware I sistemi Server attualmente in uso sono riportati in seguito. Tale lista potrebbe non essere aggiornata data l'alta dinamicità del nostro contesto. I server in produzione al 31/12/2011 sono delle seguenti tipologie: Sun Microsystems Sun Fire V490, E6900, 4800, V880, V245; Sun Ultra 25 Workstation; Sun Enterprise 3500; IBM xseries 255, 365, 350, 365, 366, 346; IBM MTM 8488; BladeCenter LS41; BladeCenter LS42; CISCO MCS 7800; HP ML570, ML370; Siemens/Fujitsu Primergy; ElettroData Samara; SI Productiva; DELL PowerEdge2550; 2850; VmWare ESX. Gli storage in produzione al 31/12/2011 son delle seguenti tipologie: EMC2 Clariion IBM DS4000 IBM DS4500 IBM DS4700 IBM TOTALSTORAGESAN32M-2 6

7 2.2 Software Software di base Sist. Operativo Unix-Solaris HW Sparc Sun Vers. S.O. 10.0/9.0/8.0/6.0 Intel mono-proc e bi-proc Windows 2000 Service Pack: 2, 3e 4 Internet Explorer: 5.5/6.0/7.0/8.0 Windows 2003 Windows 2008 Standard/ Enterprise aggiornamento alla release/sp più recente disponibile Internet Explorer: 6.0/7.0/8.0 Standard/ Enterprise aggiornamento alla release/sp più recente disponibile Internet Explorer: 6.0/7.0/8.0 Linux Versione S.O. Kernel 2.4 RedHat Ent. 5.5/Mandrake Tabella 1: Software di base in uso Unix-Solaris Windows 2008 Windows 2003 Windows 2000 Linux Tabella 2: Software di base per nuove installazioni S.O. Unix Solaris 10.0 o successivi Kernel 2.4 o successivi Application Server L application server da utilizzare per il deploymet delle applicazioni è JBoss versione o successiva. La configurazione e l architettura degli applicativi deve consentire il loro funzionamento in ambiente clusterizzato e devono poter essere messi in produzioni su server preesistenti sui quali JBoss e altre applicazioni potrebbero essere già state installate Sistemi di autenticazione: Single Sign-On L'utilizzo di sistemi di autenticazione basati su password, benchè estremamente utili ai fini della sicurezza informatica interna, comporta spesso problemi organizzativi e gestionali non indifferenti. Infatti, dato l'elevato numero di servizi informatici differenti (protetti dalla rispettive password) ai 7

8 quali un utente medio deve accedere nel corso della sua attività lavorativa, spesso si instaurano comportamenti di gestione delle credenziali di accesso ai sistemi rivolti alla semplificazione della propria attività a scapito della sicurezza globale, ad es.: utilizzo della medesima password per servizi differenti utilizzo di password deboli riutilizzo di un ristretto insieme di password nel corso del tempo A ciò deve essere inoltre addizionato il costo del lavoro aggiuntivo richiesto ai sistemi di IT Help Desk per la gestione del reset delle password (ad es. in caso di smarrimento delle stesse). Per affrontare questo tipo di problematiche l'azienda ha deciso di dotarsi di un sistema di Single Sign-On (traducibile come autenticazione unica o identificazione unica) di livello enterprise. Tali sistemi permettono ad un utente di autenticarsi una sola volta e di accedere a tutte le risorse informatiche alle quali egli è abilitato. Gli obiettivi sono multipli: semplificare la gestione delle password: riducendo drasticamente il numero delle password da gestire, maggiore è la possibilità che queste aderiscano a criteri di sicurezza elevati; semplificare la gestione degli accessi ai vari servizi; semplificare la definizione e la gestione delle politiche di sicurezza. Al termine di un processo di valutazione dei sistemi presenti sul mercato (considerando, tra gli altri, elementi quali: supporto dei sistemi pre-esistenti (ambienti desktop, integrazione con i sistemi di autenticazione, piattaforme ed applicazioni), apertura verso possibili evoluzioni future, semplicità d'uso ed overhead di gestione, sperimentazioni interne, valutazioni di mercato indipendenti, referenze) è stato adottato quale standard aziendale il prodotto OneSign Single Sign-On di Imprivata ( Nel dettaglio esso è composto da: una coppia di apparati in configurazione failover (Dimensioni 1 RU, equipaggiati con Suse Linux e MySQL) versione 3.0 di OneSign, comprensivo di componenti Agent da installare sui sistemi Server (Citrix, Terminal Server) e dei componenti Agent destinati a sistemi Client (nella versione per utenti locali e remoti) 8

9 3 Servizi 3.1 RDBMS Situazione attuale Il DBMS standard è Oracle: Le release di Oracle installate sono dalla 8i alla 11g Sono in uso anche altri DBMS ed in particolare: MS SQL Metaframe Access DB MySql PostgreSQL Configurazione Vengono individuate le seguenti regole di gestione di un Database Oracle: In fase di creazione dei campi : I campi contenenti data devono essere di tipo date I campi contenenti dati alfanumerici devono essere di tipo varchar2 I campi contenenti numeri devono essere di tipo numerico Per quanto riguarda gli indici: Le tabelle dati devono trovarsi su un tablespace diverso da quello delle tabelle indici; Gli indici su un campo sono di tipo b-tree se il campo ha una cardinalità maggiore del 15%, altrimenti sono di tipo bitmap; Gli indici vanno definiti in base alle esigenze delle istruzioni select definite La connessione al Database deve essere di tipo shared; Va in ogni caso utilizzata l utility di sicurezza inclusa nel DBMS per l invio crittografato di dati. Servizi Server/SW di base Server Unix/Solaris Windows NT Windows 2000 Windows Server 2003 Windows Server 2008 Linux RDBMS ORACLE MS SQL MS SQL MS SQL ORACLE, Postgresql, MySQL File Service - Nativo Nativo Nativo - Print Service - Nativo Nativo Nativo - Proxy MS Proxy/ISA MS Proxy/ISA Datawarehouse /ETL Antivirus Antispam Agente locale Symantec - Business Object Web Intelligence ETL Business Object Norton Antivirus Symantec MS Proxy/ISA - Norton Antivirus Symantec McAfee Secure Internet Gateway Agente locale Symantec 9

10 Servizi Server/SW di base Server Unix/Solaris Windows NT Windows 2000 Windows Server 2003 Windows Server 2008 Linux Backup Symantec Veritas ver.10.1 Symantec Veritas ver.10.1 Middleware HL7 integrated composite application network (JCAPS) Middelware Mirth Mirth_Connect (Windows Server 2003 R2) Mirth_Con nect (Windows Server 2008 R2) Application Server JBOSS 4.x e successive Tomcat versione 4.X Tomcat versione 4.X e successive JBOSS 4.X e successive tomcat HTTP server Apache 2.x Tabella 3: Schema di sintesi dei Servizi installati 10

11 4 Standard I sistemi in produzione presso l azienda sanitaria devono rispondere, per le rispettive aree di rilevanza sia agli standard internazionali e nazionali generici sia a precisi standard di informatica medica. 4.1 Standard internazionali SQL - Structured Query Language ANSI 92. XML 1.1, W3C Recommendations Feb 2004, Namespaces in XML 1.1 recommendations. IEEE POSIX Std , ISO/IEC : 1996 System API. IEEE POSIX Std /2a-1992, ISO/IEC Shell and Utilities. ISO/ IEC : Open Systems Interconnection--Basic Reference Model. ITU X.400: Message Handling System and Service Overview, 06/99. ITU X.500: Information technology - Open Systems Interconnection - The Directory: Overview of concepts, models and services, 02/01. ITU X.509 Information technology - Open Systems Interconnection - The Directory: Publickey and attribute certificate frameworks, 3/00. IEEE : OSI X-400 Based Electronic Messaging API. IEEE : Information Technology: Directory Services API. ISO :1999 Codes for the representation of names of countries and their subdivisions. ISO 7816 Chip cards. ISO 8601 Representation of dates and times. ISO :1998 Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1. ISO 8879:1996 Standard Generalized Markup Language (SGML). ISO/IEC 26300:2006 Open Document Format for Office Applications (OpenDocument) v1.0 ISO 9660 Draughting instruments with or without graduation. ISO Still image data compression standard (JPEG). ISO Digital video/audio compression and encoding (MPEG). NCSC Trusted Computer System Evaluation Criteria (Orange Book) DOD STD-83, CSC-STD-001, IETF SSL protocol version 3.1 RFC /99. IETF RFC : MD2, MD4, MD5. RSA Inc. Public Key Criptography Standard (PKCS #1, #6, #7, #9, #11). TCP/IP - Transmission Control Protocol/Internet Protocol :IETF RFC 971 (IP) e IETF RFC 703 (TCP). SMTP/SNMP - Simple Mail Transfer Protocol/ Simple Network Management Protocol Ethernet (IEEE 802.3, ISO/IEC :1993) ISDN (ITU-TI Series 100 through 600) ATM(ANSI T1.630, ANSI T1.635, UNI Specification V3.1) ISO/DIS Document management -- Portable document format -- PDF Standard di sicurezza ISO/IEC IS Information security management - Part 1: Code of practice for information security management Standard. BS Information security management systems - Specification with guidance for use. 11

12 ISO/IEC TR , Information technology Security techniques Guidelines for the management of IT security (GMITS) Part 1: Concepts and models of IT security ISO/IEC TR , Information technology Security techniques Guidelines for the management of IT security (GMITS) Part 2: Managing and planning IT security ISO/IEC TR , Information technology Security techniques Guidelines for the management of IT security (GMITS) Part 3: Techniques for the management of IT security ISO/IEC TR , Information technology Security techniques Guidelines for the management of IT security (GMITS) Part 4: Selection of safeguards ISO/IEC TR , Information technology Security techniques Guidelines for the management of IT security (GMITS) Part 5: Management guidance on network security ISO/IEC IS Evaluation Criteria for Information Technology Security - Part 1: Introduction and general model. ISO/IEC IS Evaluation Criteria for Information Technology Security - Part 2: Security functional requirements. ISO/IEC IS Evaluation Criteria for Information Technology Security - Part 3: Security assurance requirements Meccanismi di sicurezza standardizzati da ISO/IEC/JTC1/SC27 ISO/IEC FDIS 7064: (2002), Data processing - Check character systems (2nd edition, revision of ISO 7064: 1983) ISO 8372: 1987, Modes of operation for a 64- bit block cipher algorithm ISO/IEC : (2002), Digital signature schemes giving message recovery - Part 2: Integer factorization based mechanisms ISO/IEC : 1999, Digital signatures schemes giving message recovery - Part 3: Discrete logarithm based mechanisms ISO/IEC : 1999, Message authentication codes (MACs) - Part 1: Mechanisms using a block cipher ISO/IEC : (2002), Message authentication codes (MACs) - Part 2: Mechanisms using a dedicated hash-function ISO/IEC : 1997, Entity authentication - Part 1: General (2nd edition) ISO/IEC : 1999, Entity authentication - Part 2: Mechanisms using symmetric encipherment algorithms (2nd edition) ISO/IEC : 1998, Entity authentication - Part 3: Mechanisms using digital segnature techniques (2nd edition) ISO/IEC : 1999, Entity authentication - Part 4: Mechanisms using a cryptographic check function (2nd edition) ISO/IEC : 1999, Entity authentication - Part 5: Mechanisms using zero knowledge techniques ISO/IEC 9979: 1999, Procedures for the registration of cryptographic algorithms (2nd edition) ISO/IEC 10116: 1997, Modes of operation for an n-bit block cipher algorithm (2nd edition, in fase di revisione) ISO/IEC : 2000, Hash-functions - Part 1: General (2nd edition) ISO/IEC : 2000, Hash-functions - Part 2: Hash-functions using an n-bit block cipher algorithm (2nd edition) ISO/IEC : 1998, Hash-functions - Part 3: Dedicated hash-functions ISO/IEC : 1998, Hash-functions - Part 4: Hash-functions using modular arithmetic ISO/IEC : 1996, Key management - Part 1: Framework ISO/IEC : 1996, Key management - Part 2: Mechanisms using symmetric 12

13 techniques ISO/IEC : 1999, Key management - Part 3: Mechanisms using asymmetric techniques ISO/IEC : 1997, Non-repudiation - Part 1: General (in fase di revisione) ISO/IEC : 1998, Non-repudiation - Part 2: Using symmetric techniques ISO/IEC : 1997, Non-repudiation - Part 3: Using asymmetric techniques ISO/IEC TR 14516: 2002 ( ITU-T X.842), Guidelines on the use and management of Trusted Third Party services (in attesa di pubblicazione) ISO/IEC : 1999, Digital signatures with appendix - Part 1: General ISO/IEC : 1999, Digital signatures with appendix - Part 2: Identity-based mechanisms ISO/IEC : 1999, Digital signatures with appendix - Part 3: Certificate-based mechanisms ISO/IEC 15816: 2002 ( ITU-T X.841), Security information objects for access control ISO/IEC 15945: 2002 ( ITU-T X.843), Specification of TTP services to support the application of digital signatures ISO/IEC : (2002), Cryptographic techniques based on elliptic curves - Part 1: General (in attesa di pubblicazione) ISO/IEC : (2002), Cryptographic techniques based on elliptic curves - Part 2: Digital signatures (in attesa di pubblicazione) ISO/IEC : (2002), Cryptographic techniques based on elliptic curves - Part 3: Key establishment (in attesa di pubblicazione) ISO/IEC FCD : 2002, Cryptographic techniques based on elliptic curves - Part 4: Digital signatures giving message recovery ISO/IEC TR 15947: (2002), IT intrusion detection framework (in attesa di pubblicazione) ISO/IEC 17799: 2000, Code of practice for information security management (in fase di revisione) ISO/IEC : (2002), Time stamping services - Part 1: Framework (in attesa di pubblicazione); ISO/IEC FDIS : 2002, Time stamping services - Part 2: Mechanisms producine independent tokens ISO/IEC CD : 2002, Time stamping services - Part 3: Mechanisms producine linked tokens ISO/IEC WD 18028: 2001, Information technology - Security techniques - IT network security ISO/IEC CD 18031: 2002, Random bit generation ISO/IEC CD 18032: 2002, Prime number generation ISO/IEC CD : 2002, Encryption algorithms - Part 1: General ISO/IEC WD : 2002, Encryption algorithms - Part 2: Asymmetric ciphers ISO/IEC CD : 2002, Encryption algorithms - Part 3: Block ciphers ISO/IEC WD : 2002, Encryption algorithms - Part 4: Stream ciphers ISO/IEC WD 18043: 2002, Guidelines for the implementation, operation and management of Intrusion Detection Systems (IDS) ISO/IEC WD 18044: 2002, Information security incident management ISO/IEC WD 18045: 2002, Methodology for IT security evaluation 13

14 4.2 Standard nazionali Posta Elettronica Certificata (PEC) La Posta Elettronica Certificata (PEC) è un sistema di comunicazione simile alla posta elettronica standard a cui si aggiungono delle caratteristiche di sicurezza e di certificazione della trasmissione tali da rendere i messaggi opponibili a terzi. L impiego della posta elettronica consente e facilita il cambiamento culturale ed organizzativo dell'azienda sanitaria: bisogna accelerare questo processo di cambiamento e darne concreta percezione anche all esterno, abbandonando inutili ed onerosi formalismi, considerati, anche, i consistenti risparmi di risorse che potranno derivare dall uso intensivo della posta elettronica Il servizio di posta elettronica certificata deve comprendere le seguenti funzionalità: la confidenzialità, l integrità, il non ripudio, la tracciabilità, la storicizzazione del flusso dei messaggi PEC Di seguito si descrive lo schema funzionale per il servizio di posta elettronica certificata come configurato dal CNIPA. Il servizio di posta elettronica certificata può essere acceduto dall utente sia utilizzando un client di posta che tramite un comune browser Internet. Nel caso si utilizzi un client di posta è necessaria, per garantire l'interoperabilità, la possibilità di utilizzare qualunque client aderente agli standard (Lotus Notes, Ms. Outlook, Mozilla Thunderbird Eudora, ecc.). Nel caso si utilizzi un browser Internet è necessaria, per garantire l'interoperabilità, la possibilità di utilizzare qualunque browser aderente agli standard (Ms. Internet Explorer, Netscape Navigator, Mozilla, Firefox, ecc.) Per garantire la protezione crittografica sarà necessario accedere al servizio con protocollo https. 14

15 Schema Funzionale PEC La normativa di riferimento Il DPR 11 febbraio 2005, n. 68 (G.U. 28 aprile 2005, n. 97) disciplina le modalità di utilizzo della Posta Elettronica Certificata (PEC) non solo nei rapporti con la PA, ma anche tra privati cittadini. In sintesi le novità contenute nel provvedimento: nella catena di trasmissione potranno scambiarsi le certificate sia i privati, sia le PA. Saranno i gestori del servizio (art. 14), iscritti in apposito elenco tenuto dal Cnipa (che verificherà i requisiti soggettivi ed oggettivi inerenti ad esempio alla capacità ed esperienza tecnico-organizzativa, alla dimestichezza con procedure e metodi per la gestione della sicurezza, alla certificazione ISO9000 del processo), a fare da garanti dell'avvenuta consegna; per iscriversi nell'elenco dovranno possedere un capitale sociale minimo non inferiore a un milione di euro e presentare una polizza assicurativa contro i rischi derivanti dall'attività di gestore; i messaggi verranno sottoscritti con la firma digitale avanzata che dovrà essere apposta sia sulla busta, sia sulle ricevute rilasciate dai gestori per assicurare l'integrità e l'autenticità del messaggio; i tempi di conservazione: i gestori dovranno conservare traccia delle operazioni per 30 mesi; i virus: i gestori sono tenuti a verificare l'eventuale presenza di virus nelle ed informare in caso positivo il mittente, bloccandone la trasmissione (art. 12); le imprese, nei rapporti intercorrenti, potranno dichiarare l'esplicita volontà di accettare l'invio di PEC mediante indicazione nell'atto di iscrizione delle imprese. 15

16 L articolo 16 comma VI del Decreto Legge 185/2008 Misure urgenti per il sostegno a famiglie, lavoro, occupazione e impresa e per ridisegnare in funzione anti-crisi il quadro strategico nazionale ha infatti introdotto importanti novità in tema di Posta Elettronica Certificata. L'art. 16 del D.L. 185 obbliga tute le società, esistenti e di nuova costituzione, i professionisti e le Pubbliche Amministrazioni, che già avevano tale dovere, a dotarsi di almeno una casella di Posta Elettronica Certificata. Gli indirizzi di P.E.C. saranno pubblicati, rispettivamente, dal Registro delle Imprese, dagli albi e dal CNIPA in elenchi consultabili gratuitamente in modalità telematica. Si tratta di un forte impulso alla digitalizzazione ed alla diffusione di uno strumento, la P.E.C., che conferisce alla comunicazione elettronica lo stesso valore legale della raccomandata cartacea con ricevuta di ritorno. Ogni interessato potrà così notificare, se in possesso di Pec, atti legali, contratti, diffide, richieste sottoscrivendo i documenti con firma digitale e trasmettendo il tutto all indirizzo Pec della società pubblicato nel Registro Imprese Le regole tecniche Il Decreto Ministeriale contenente le Regole tecniche per la formazione, la trasmissione e la validazione, anche temporale, della posta elettronica certificata" (tutti i requisiti tecnico-funzionali che devono essere rispettati dalle piattaforme utilizzate per erogare il servizio) è stato pubblicato nella G.U. del 15 novembre 2005, n Il Cnipa effettua le attività di vigilanza e controllo assegnategli dalla norma e, con un apposito Centro di competenza, supporterà le PA ai fini dell'introduzione della PEC nei procedimenti amministrativi. Per quanto riguarda le novità introdotte dall'art. 16 del D.L. 185 si specifica quanto in seguito. Per acquisire la casella di posta elettronica è possibile consultare l elenco dei verificatori e raggiungerlo dal sito del Centro Nazionale per l Informatica nella Pubblica Amministrazione (CNIPA), Le istanze di iscrizione prodotte verranno conseguentemente protocollate e sospese, come da indicazioni del sistema. L azienda potrà avere più indirizzi di posta elettronica certificata, ma solo uno di questi potrà essere pubblicato nel Registro imprese e identificherà la vera e propria sede elettronica della società presso cui potranno essere recapitati tutti gli atti e documenti a valore legale a prescindere dal consenso della società. La consultazione per via telematica dei singoli indirizzi di posta elettronica certificata nel registro delle imprese o negli albi o elenchi avviene liberamente e senza oneri. Profilo di busta crittografica per la firma digitale in linguaggio XML Per maggiore chiarezza si riporta per intero il contenuto della deliberazione numero 34/06, Regole tecniche per la definizione del profilo di busta crittografica per la firma digitale in linguaggio XML del CNIPA di data 03/10/2006. Centro Nazionale per l'informatica nella Pubblica Amministrazione Deliberazione numero 34/06 Regole tecniche per la definizione del profilo di busta crittografica per la firma digitale in linguaggio XML (G.U. 3 ottobre 2006 n. 230) IL COLLEGIO - Visto il decreto legislativo 12 febbraio 1993, n. 39, cosi' come modificato dall'art. 176, comma 3, del decreto legislativo 30 giugno 2003, n. 196; -Visto il decreto legislativo 7 marzo 2005, n. 82, recante il «Codice dell'amministrazione digitale»; - Visto il decreto del Presidente del Consiglio dei Ministri 13 gennaio 2004, recante «Regole tecniche per la formazione, la trasmissione, la conservazione, la duplicazione, la riproduzione e la validazione, anche 16

17 temporale, dei documenti informatici» e, in particolare, l'art. 10 e l'art. 40, comma 4; - Vista la direttiva 98/34/CE del Parlamento europeo e del Consiglio del 22 giugno 1998, modificata dalla direttiva 98/48/CE del Parlamento europeo e del Consiglio del 28 luglio 1998, entrambe recepite nell'ordinamento italiano dalla legge 21 giugno 1986, n. 317, cosi' come modificata dal decreto legislativo 23 novembre 2000, n. 427; - Vista la deliberazione CNIPA n. 4 del 17 febbraio 2005, recante «Regole per il riconoscimento e la verifica del documento informatico» e, in particolare, l'art. 12, comma 8, che prevede che le regole tecniche per la definizione dei formati standard di busta crittografica per la firma digitale in linguaggio XML sono fissate dal CNIPA stesso; - Espletata la procedura di notifica alla Commissione europea prevista dalla direttiva 98/34/CE del Parlamento europeo e del Consiglio del 22 giugno 1998, modificata dalla direttiva 98/48/CE del Parlamento europeo e del Consiglio del 28 luglio 1998, sopra richiamate; - Considerato che la sottoscrizione digitale in linguaggio XML e' di fondamentale interesse ai fini dello sviluppo del Sistema pubblico di connettivita' (SPC); - Considerato, inoltre, che detta sottoscrizione digitale in linguaggio XML richiede delle specifiche regole tecniche allo scopo di garantire l'interoperabilita' nel riconoscimento e nella verifica del documento informatico; Delibera di emanare le seguenti regole tecniche: Articolo 1 Oggetto 1. Con la presente deliberazione sono stabilite - ai sensi dell'art. 12, comma 8, della deliberazione CNIPA n. 4 del 17 febbraio 2005, citata nelle premesse - le regole tecniche per la definizione dei formati standard di busta crittografica per la firma digitale in linguaggio XML. 2. Dette regole tecniche sono riportate nel documento allegato, che costituisce parte integrante della presente deliberazione. Articolo 2 Criteri di interoperabilità 1. Salvo diversa specificazione, la presente deliberazione fa riferimento al profilo, al formato e alla struttura dei certificati definiti nella citata deliberazione CNIPA n. 4 del 17 febbraio Articolo 3 Strumenti di verifica 1. I certificatori accreditati ai sensi dell'art. 29, comma 1, del decreto legislativo 7 marzo 2005, n. 82, che rilasciano strumenti per la sottoscrizione nei formati previsti dalla presente deliberazione, devono fornire, ovvero indicare - ai sensi dell'art. 10, comma 1, del decreto del Presidente del Consiglio dei Ministri 13 gennaio almeno un sistema che consenta di effettuare la verifica della sottoscrizione stessa. Articolo 4 Disposizioni finali 1. La presente deliberazione trova applicazione a decorrere da sei mesi dalla data di pubblicazione nella Gazzetta Ufficiale della Repubblica italiana Carta Nazionale dei Servizi Roma, 18 maggio 2006 Il presidente: Zoffoli La carta nazionale dei servizi e' un dispositivo che ha come obiettivo l'identificazione del cittadino. Ogni cittadino ha disposizione una smart card per poter accedere a servizi quali firma digitale, accesso sicuro alle reti informatiche, pagamenti on-line, servizi sanitari e servizi anagrafici La normativa di riferimento Il DPR n. 177 del 2 Marzo 2004 regolamenta la diffusione della carta nazionale dei servizi. Questa normativa riguarda il rilascio, le caratteristiche i dati contenuti e la validità temporale della CNS: 17

18 La carta nazionale dei servizi, in attesa della carta d'identità elettronica, è emessa dalle pubbliche amministrazioni interessate al fine di anticiparne le funzioni di accesso ai servizi in rete delle pubbliche amministrazioni. La carta nazionale dei servizi contiene un certificato di autenticazione, consistente nell'attestato elettronico che assicura l'autenticità delle informazioni necessarie per l'identificazione in rete del titolare della carta nazionale dei servizi, rilasciato da un certificatore accreditato. La carta può contenere eventuali informazioni di carattere individuale generate, gestite e distribuite dalle pubbliche amministrazioni per attività amministrative e per l'erogazione dei servizi al cittadino, cui si può acc edere tramite la carta, salvo si tratti di dati sensibili La carta nazionale dei servizi ha la validità temporale determinata dall'amministrazione emittente, comunque non superiore a sei anni. Tutte le pubbliche amministrazioni che erogano servizi in rete devono consentire l'accesso ai servizi medesimi da parte dei titolari della carta nazionale dei servizi indipendentemente dall'ente di emissione, che è responsabile del suo rilascio Le regole tecniche Il Decreto Ministeriale n.9 di dicembre 2004 del Ministro dell'interno, del Ministro per l'innovazione e le tecnologie e del Ministro dell'economia e finanze definisce le regole tecniche e di sicurezza relative alle tecnologie e ai materiali utilizzati per la produzione della Carta nazionale dei servizi. Il Cnipa a riguardo ha espresso delle modalità basate su delle interfacce software per garantire l'interoperabilità tra dispositivi. Poiché una richiesta di interoperabilità basata su dispositivi conformi alla norma ISO 7816 non è molto percorribile in quanto questa è soggetta ad implementazioni parziali dei diversi produttori delle carte. Tali interfacce, rappresentate nella figura sottostante, consentono di utilizzare smart card di differenti fornitori senza vincoli restrittivi sul sistema operativo. Quest' architettura si presta a processi di Autenticazione e Firma Digitale. 18

19 Architettura Carta Nazionale dei Servizi Firma digitale e conservazione sostitutiva La soluzione adottata dalla Azienda Provinciale per i Servizi Sanitari in merito alle funzionalità di firma digitale e conservazione sostitutiva sono quelle fornite dalla ditta Infocert Spa che risulta inoltre nell'elenco dei certificatori di Firma Digitale pubblicato da DigitPA ( La normativa di riferimento e le regole tecniche Decreto Legislativo 235/2010 Nuovo Codice dell'amministrazione digitale; Decreto Presidente Consiglio dei Ministri 30 marzo 2009 Regole tecniche in materia di generazione, apposizione e verifica delle firme digitali e validazione temporale dei documenti informatici; Decreto legislativo 4 aprile 2006, n. 159 Disposizioni integrative e correttive al decreto legislativo 7 marzo 2005, n. 82, recante codice dell'amministrazione digitale; Direttiva del 18 novembre 2005 del Ministro per l Innovazione e le Tecnologie Definizione dei criteri e delle azioni che tutte le pubbliche amministrazioni dovranno attuare per realizzare concretamente i principi contenuti nel Codice dell'amministrazione digitale; Decreto Legislativo del 7 marzo 2005, n. 82 Codice dell'amministrazione digitale; CNIPA Deliberazione n.4/2005 del 17 febbraio 2005 Regole per il riconoscimento e la verifica del documento informatico; Deliberazione CNIPA del 19 febbraio 2004, n. 11 Regole tecniche per la riproduzione e conservazione di documenti su supporto ottico idoneo a garantire la conformità dei documenti agli 19

20 originali; Decreto del Presidente del Consiglio dei Ministri 13 gennaio 2004 Regole tecniche per la formazione, la trasmissione, la conservazione, la duplicazione, la riproduzione e la validazione, anche temporale, dei documenti informatici; Direttiva del 18 Dicembre 2003 Linee guida in materia di digitalizzazione dell'amministrazione per l'anno 2004; Decreto del Presidente della Repubblica 7 aprile 2003, n.137 Regolamento recante disposizioni di coordinamento in materia di firme elettroniche a norma dell'articolo 13 del decreto legislativo 23 gennaio 2002, n. 10; Direttiva del Ministro per l'innovazione e le tecnologie, 9 dicembre 2002 Trasparenza dell'azione amministrativa e gestione elettronica dei flussi documentali; Parlamento europeo direttiva 1999/93/CE del 13 dicembre 1999 Quadro comunitario per le firme elettroniche; Decreto del Presidente della Repubblica del 28 dicembre 2000, n. 445 Testo unico delle disposizioni legislative e regolamentari in materia di documentazione amministrativa. 20

21 4.3 Standard internazionali di Informatica medica Il sistema deve essere coerente con i metodi ed i prodotti dell informatica medica al fine di poter garantire l interoperabilità con altre applicazioni, lo scambio di informazioni cliniche e l integrazione in un ambiente multi-vendor. Gli standard esistenti si possono classificare nelle seguenti tipologie: Identificazione Comunicazione Contenuto e struttura Rappresentazione di dati clinici Sicurezza e riservatezza Indicatori di qualità e linee guida Nel seguito si indicano gli standard principali di riferimento e altri standard di carattere indicativo TC251 Gli standard predisposti dal TC251, nell ambito del Comitato Europeo di Normalizzazione, su vari argomenti tra cui i sistemi aperti, la sicurezza, i dispositivi nel campo medico, ed in particolare: CEN/TC251 ENV Healthcare Information Systems Architecture - Part 1: Healthcare Middleware Layer; CEN/TC251 ENV Medical Informatics - Security Categorisation and protection for healthcare Information Systems; CEN/TC251 ENV Medical Informatics - Intermittently Connected Devices; CEN/TC251 ENV Messages for exchange of laboratory information; CEN/TC251 ENV Messages for patient referral and discharge; CEN/TC251 ENV Request and report messages for diagnostic service department; Lo standard europeo CEN/TC 251 schematizza un generico sistema sanitario mediante tre livelli cooperanti: livello applicativo (application): consiste in una serie di componenti responsabili dell interazione con l utente e fornisce un supporto alle varie attività svolte nell ambito di una struttura sanitaria; livello intermedio (middelware): consiste in una serie di componenti che forniscono un insieme di servizi comuni di tipo Health-care related e di tipo Generic Common allo strato applicativo; livello delle strutture informatiche di base (bitways): fornisce l insieme di funzionalità informatiche di base (hardware e software) necessarie al funzionamento ed alla interazione dei vari moduli che costituiscono il sistema informativo HL7 Lo standard Usa HL7 relativo al settimo livello dello standard OSI per le applicazioni nel campo dei sistemi informativi medici descrive le modalità per lo scambio in forma elettronica di dati di ambiente sanitario, con particolare enfasi per gli aspetti riguardanti i pazienti degenti presso strutture ospedaliere. 21

22 4.3.3 DICOM La necessità di scambiare immagini mediche con le relative informazioni (annotazioni, referti del medico, ecc.) tra i diversi soggetti di un ospedale, o tra ospedali diversi, attraverso le reti telematiche, ha fatto sorgere l esigenza della definizione di uno standard che consentisse una comunicazione globale tra le diverse strutture. DICOM Versione 3.0 rappresenta lo standard defacto che consente ai vari dispositivi medici (TAC, risonanza, ecc.) l archiviazione e lo scambio delle immagini e delle informazioni associate in un formato digitale. Lo standard definito da ACR- NEMA: Digital Imaging and Communications in Medicine (DICOM) v IHE IHE (Integration of Healthcare Enterprises) promuove l utilizzo degli standard di informatica sanitaria esistenti definendo la grammatica, ovvero come una serie di regole con cui due procedure dialogano utilizzando i vocaboli DICOM e HL7. La grammatica si compone di profili ed attori; i primi definiscono le regole di interoperabili tra tutte le diverse procedure che gestiscono il workflow dei dati anagrafici del paziente dalla accettazione del ricovero all esecuzione di un esame radiologico mentre i secondi sono sistemi informativi che raggruppano delle specifiche funzionalità. I profili principali sono: Scheduled workflow Patient information reconcilition Consistent presentation of images Presentation of grouped procedures Access to radiology information Key image note Simple image and numeric report Basic security Charge posting Evidence documents Gli attori principali sono: ADT - patient registration Order placer Order filler - dpt system scheduler Image manager Acquisition modality Evidence creator Image display Print composer Print server Report creator Report manager Report reader Report repository Audit record repository Secure node Time server Change processor Display 22

23 Information source Patient identity consumer Patient identity cross reference manager Patient identity source Time client Automation manager Order result tracker UNI Le norme UNI sulla integrazione di sistemi software per la sanità CORBAMED Lo standard CORBAmed per l interoperabilità delle applicazioni sanitarie in tecnologia CORBA ed in particolare: Person Identification Service (PIDS) specification (1999); Lexicon Query Service Specification (1999); Clinical Image Access Service (CIAS); Clinical Observations Access Service (COAS); Healthcare Resource Access Control GEHR Il progetto GEHR (Good Electronic Healthcare Record) per la definizione dei dati sanitari in ambienti object-oriented Codifiche Lo standard per la rappresentazione di dati clinici (Codici) ed in particolare: International Classification of Diseases (ICD-9); Systematized Nomenclature of Human and Veterinary Medicine (SNOMED); Laboratory Observation Identifier Names and Codes (LOINC); Diagnostic Related Groups (DRGs): Questi codici sono mantenuti da HCFA; Unified Medical Language System (UMLS); ATC (Anatomical and Therapeutic Chemicals) Altri standard per l identificazione del paziente Identificazione del paziente: Universal Healthcare Identifier (ASTM), Patient Identifier Project Team (CPRI); Identificazione del medico: Universal Physician Identifier Number- UPIN (HCFA); Identificazione della struttura: Health Industry Number (HIN); Identificazione dei prodotti: UPC, NDC; Lo standard ASTM per il record sanitario: ASTM: E1384 Standard description for content and structure of the Computer-based Patient Record. 23

24 Altri standard per la comunicazione Messaggi tra strutture e paganti ASCX12N 148, 270, 271, 276, 277, 278, 834, 835, 837 ; Messaggi in formato ASTM (E1394 per strumenti clinici, E1238 informazioni cliniche, E1460 basi di conoscenza/arden Syntax.); Messaggi e standard per apparecchiature radiologiche e terapeutiche: DICOM, MEDICOM Standard per la definizione di indicatori di qualità e linee guida Indicator Measurement System (IMSystem) della Joint Commission on Accreditation of Health Care Organizations (JCAHO); The Health Plan Employer Data and Information Set (HEDIS) version 2.0 and 2.5 (sviluppato col supporto della the National Committee for Quality Assurance NCQA). 24

25 5 Realizzazione ed acquisizione di applicazioni 5.1 Metodologia per lo studio e la realizzazione del software Requisiti non-funzionali I requisiti non-funzionali sono una serie di requisiti del sistema che non sono direttamente collegati a quello che il sistema deve fare. Nel seguito vengono definiti i principali requisiti non-funzionali. Molti di essi incidono direttamente sulla qualità del prodotto finale. Nei paragrafi successivi viene inoltre illustrata l architettura di riferimento APSS, rispondente ai requisiti non funzionali Interoperabilità Il grado di interoperabilità di un sistema software si riferisce allo sforzo richiesto per far interagire il sistema con altri programmi. Si raggiunge con la progettazione di sistemi dove sono adottati standard aperti e non proprietari. Ciò permette di ottenere la interoperabilità tra sistemi progettati in modo indipendente, ma che condividono i protocolli. L interoperabilità è fondamentale per l integrazione nei sistemi informativi sanitari e nelle reti sanitarie. I sistemi software devono essere in grado di produrre ed operare con formati di documento standard ed aperto Portabilità Portare un programma o un sistema software significa produrne una versione eseguibile in un nuovo ambiente basata su una versione esistente. Il termine ambiente si riferisce alla gamma completa di elementi in una installazione che interagiscono con il software che deve essere portato. Un sistema software è portabile se il costo di portare il programma in un nuovo ambiente è significativamente inferiore al costo di un nuovo sviluppo. I tipi principali di portabilità che di solito si considerano sono la portabilità binaria (viene portato l eseguibile) e la portabilità del sorgente (viene portata la rappresentazione in linguaggio sorgente). La portabilità di un sistema si può raggiungere come pre-requisito - con l utilizzo di standards (si faccia riferimento alla sezione relativa). In un sistema complesso su n livelli, come quello presente, le componenti possono essere distribuite potenzialmente su diversi sistemi di elaborazione e su architetture diverse; il sistema deve quindi rispondere ai requisiti di: portabilità lato client portabilità lato server (almeno sui Sistemi Operativi Windows e UNIX) indipendenza dal Web Server La portabilità è un requisito importante per sistemi destinati ad un utilizzo enterprise e che nel corso del tempo saranno impiegati su sistemi diversi Aderenza a Standards I.T. L aderenza agli standard riconosciuti è un pre-requisito per la costruzione di sistemi aperti, portabili ed interoperabili; per l organizzazione che li adotta i vantaggi sono i seguenti: Possibilità di scegliere tra più fornitori, i quali a loro volta con l utilizzo di standard possono diminuire i costi di produzione; Possibilità di integrare più facilmente componenti prodotti da fornitori diversi; I sistemi possono essere sviluppati più rapidamente, con migliori prestazioni e funzionalità; 25

26 I sistemi che seguono lo stato dell arte evolvono più rapidamente e con una strategia ben definita; Possono essere sviluppate applicazioni tecnologicamente avanzate e che includono un più vasto spettro di tecnologie; Gli standard per i sistemi aperti supportano l interoperabilità tra le applicazioni eterogenee che li seguono Look and feel La progettazione dell interfaccia utente che deve essere caratterizzata da: facilità di apprendimento; facilità di memorizzazione; efficienza; capacità di limitare gli errori Manutenibilità Nell analisi del ciclo di vita di un sistema software, le statistiche indicano che il costo della manutenzione incide per una percentuale consistente, mediamente più del 50% dei costi complessivi. Per risolvere questi problemi si adottano oggi nuovi metodi di analisi e paradigmi di sviluppo software. Si tratta dei paradigmi ad oggetti che consentono di produrre software in modo meno costoso e più affidabile del passato. I concetti di riusabilità ed ereditarietà permettono di progettare il software come una serie di componenti standardizzati usabili anche in altre applicazioni. Tali paradigmi sono indicati come requisiti architetturali da adottare nei paragrafi successivi Scalabilità e Performance In considerazione del numero d utenti potenziali del sistema (Personale sanitario interno, Medici di Medicina Generale, Cittadini) si deve porre particolare enfasi sulla scalabilità del sistema. Dovrà essere possibile gestire a regime un numero di stazioni di lavoro dell ordine di qualche migliaio con tempi di risposta accettabili. Il sistema deve poter dimostrare scalabilità orizzontale (aggiunta di client senza grossi impatti sulle prestazioni) e verticale (migrazione a server più capaci e veloci). Si dovranno poter aggiungere, per esempio, più Web server in parallelo per gestire le connessioni http o più Application Server per suddividere il carico elaborativo. La progettazione dei componenti software deve tener conto di questi vincoli Affidabilità, Disponibilità e Sicurezza Il sistema per la gestione dei dati sanitari da realizzare dovrà essere utilizzato in modo continuativo su ospedali e territorio, riveste quindi il carattere di sistema mission-critical ad alta affidabilità (24x7). La progettazione del sistema dovrà tenere presente i requisiti di: Affidabilità: le funzioni offerte dal sistema corrispondono ai requisiti funzionali. I risultati forniti dal sistema corrispondono a quelli attesi o se ne discostano per un margine tollerabile. Robustezza: Il sistema si comporta in modo accettabile anche in condizioni non specificate nei requisiti; gli errori che si possono generare non si propagano a tutto il sistema (soft failing). 26

27 Disponibilità: Il sistema deve essere disponibile in continuazione per gli utenti; l architettura del sistema non prevede quindi interruzioni del servizio per backup (la modalità di salvataggio dati sarà il warm-backup), inizializzazioni periodiche, etc. Sicurezza: Il sistema deve gestire gli accessi alle informazioni in modo da impedire accessi non autorizzati, sia di natura involontaria che dolosa. Dal punto di vista dell implementazione si adotteranno architetture ridondanti per i sistemi server ed i sistemi di rete, con gli opportuni sistemi di management che consentano la gestione proattiva dei problemi [LIR1997] UP La metodologia standard adottata per l'analisi e lo sviluppo del sistema software deve basarsi su Unified Process.La progettazione del sistema deve produrre una adeguata documentazione che deve comprendere: Specifiche progettuali e requisiti, sono essenzialmente costituiti dalla descrizione del problema (problem statement), dall'insieme dei casi d'uso (use case) e da tutti i documenti trasmessi dall'utenza relativamente ai processi in atto. Modello di analisi, utilizzato per descrivere l'organizzazione interna del sistema con un elevato grado di astrazione, e con modalità indipendente dalle scelte tecnologiche. Il modello di analisi contiene sia descrizioni statiche che dinamiche: gli aspetti statici sono descritti sotto forma di uno o più diagrammi delle classi, gli aspetti dinamici sotto forma di un insieme di diagrammi di interazione e di stato. Il modello di analisi rappresenta, sotto forma di classi, le componenti fondamentali, le loro specifiche responsabilità, le loro associazioni e le loro interazioni. L'input principale è costituito dal modello dei casi d'uso, che viene analizzato per scoprire quali parti del sistema servono per implementare le singole funzionalità, e quale ruolo devono svolgere in tale ambito. Modello di disegno, descrive l'organizzazione interna del sistema, con un livello di dettaglio che tiene conto delle tecnologie software e hardware utilizzate sia per l'implementazione delle componenti che della loro interazione. La differenza sostanziale tra il modello di analisi e quello di disegno sta nel fatto che quest'ultimo è legato ad una specifica tecnologia di implementazione (ad esempio il linguaggio di programmazione), mentre il primo è indipendente dalle caratteristiche implementative. Da questa prima differenza consegue che il modello di disegno è più vincolato rispetto al modello di analisi (maggiore conformità alle caratteristiche specifiche della tecnologia selezionata), inoltre è molto più complesso e dettagliato del modello di analisi perchè rappresenta nel dettaglio il sistema sotto un profilo maggiormente tecnico: il numero delle classi è superiore ed è superiore la complessità dei diagrammi di interazione. Modello di implementazione, descrive la configurazione delle risorse hardware necessarie per l'esecuzione del software e l'organizzazione interna del sistema a livello di componenti implementativi (eseguibili, file, ecc.), evidenziando le dipendenze che esistono tra le componenti stesse. Il processo unificato è un processo guidato dai casi d'uso (use case): i requisiti degli utenti sono raccolti in casi d'uso, sotto forma di sequenze eseguibili dal sistema e in grado di fornire valori per gli utenti. Gli use case sono impiegati come base per il successivo lavoro degli analisti e degli sviluppatori, al fine di realizzare i modelli del progetto e dell'implementazione. Di seguito viene definito l'insieme minimo dei diagrammi da realizzare per ciascun modello 27

28 prodotto: Diagramma dei casi d'uso (use case diagram), obbligatorio; Diagramma delle classi (class diagram), obbligatorio sia nel modello di analisi che in quello relativo al design; Diagramma di sequenza (sequence diagram), obbligatorio per le interazioni particolarmente significative in termini di complessità e criticità; Diagramma di attività (activity diagram), obbligatorio unitamente alla descrizione dei casi d'uso e per i processi con elevata complessità e numero di interazioni; Diagramma di collaborazione (collaboration diagram), facoltativo; Diagramma di stato (state transition diagram), facoltativo, consigliato per illustrare i metodi particolarmente complessi; Diagramma di distribuzione (deployment diagram), obbligatorio a livello di sotto-sistema e di sistema; 5.2 Metodologia per lo studio e la realizzazione del database A livello di analisi e disegno è necessario definire un modello separato relativo ai dati persistenti che il sistema dovrà gestire in un DBMS relazionale. Il modello dei dati deve essere rappresentato: con un diagramma delle classi ben distinto da quello che rappresenta le classi vere e proprie (in termini di notazione UML); tramite un diagramma Entità Relazioni (ER diagram); Gli oggetti così definiti possono essere resi persistenti con modalità automatica oppure personalizzata (Container Managed Persistence oppure attraverso l adozione di un pattern DAO) come dettagliato in seguito. La base dati deve essere centralizzata e deve utilizzare il motore relazionale Oracle nella versione 8i o superiore Progettazione del database Nell'ambito delle basi di dati, si è consolidata negli anni una metodologia di progetto che ha dato prova di soddisfare pienamente le proprietà di generalizzazione, di qualità del prodotto e facilità d'uso. Tale metodologia è articolata in tre fasi principali da effettuare in cascata e si fonda su un principio molto semplice ma efficace: quello di separare in maniera netta le decisioni relative a ''cosa'' rappresentare in una base di dati (prima fase), da quelle relative a ''come'' farlo (fasi successive). Le fasi si possono distinguere nelle seguenti tipologie di progettazione: Progettazione concettuale, il cui scopo è quello di rappresentare le specifiche informali della realtà di interesse in termini di una descrizione formale e completa, ma indipendente dai criteri di rappresentazione utilizzati nei sistemi di gestione di basi di dati. Il prodotto di questa fase viene chiamato schema concettuale e fa riferimento a un modello concettuale dei dati. Il modelli concettuale consente di descrivere l'organizzazione dei dati a un alto livello di astrazione, senza tener conto degli aspetti implementativi. In questa fase infatti, il progettista deve cercare di rappresentare il contenuto informativo della base di dati, senza preoccuparsi nè delle modalità con le quali queste informazioni verranno definite in un sistema reale, nè dell'efficienza dei programmi che devono interagire con queste informazioni. Progettazione logica, consiste nella traduzione dello schema concettuale definito nella fase precedente, in termini delle strutture di rappresentazione proprie del tipo di sistema di gestione di base di dati a disposizione. Il prodotto di questa fase viene denominato schema 28

29 logico della base di dati e fa riferimento a un modello logico dei dati. Il modello logico consente di descrivere i dati secondo una rappresentazione ancora indipendente da dettagli fisici, ma può essere realizzata direttamente con un sistema di gestione di base di dati che adotta il modello logico scelto. In questa fase, le scelte progettuali tengono conto anche di criteri di ottimizzazione delle rappresentazioni, in base alle operazioni da effettuare sui dati. Progettazione fisica, dove lo schema logico viene completato con le specifiche dei parametri fisici relative alla base di dati. Il prodotto di questa fase viene denominato schema fisico UML Il linguaggio simbolico utilizzato per la rappresentazione dei modelli e dei diagrammi prodotti con l'applicazione della metodologia è l' UML (Unified Modelling Language). UML è un linguaggio che può essere utilizzato per definire un sistema in modo formale ma non stabilisce una metodologia per l'analisi, la progettazione e l'implementazione di quel sistema Architettura applicativa Le applicazioni devono prevedere una architettura scomposta su tre livelli secondo gli standard CEN ENV e UNI 10533, indipendentemente dagli strumenti e dalle tecnologie utilizzate: Application: insieme di componenti responsabili dell interazione con gli utenti; Middleware: componenti software che forniscono alle applicazioni servizi comuni di tipo sanitario e generico; Bitways: fornisce le strutture tecnologiche di base (hardware e software). Architettura secondo lo standard CEN ENV e UNI Architettura del sistema I sistemi devono prevedere un architettura che risolva tutte le problematiche d affidabilità, scalabilità, portabilità, interoperabilità ed integrazione caratterizzanti il software di livello Enterprise. Nella progettazione di nuovo software o nella reingegnerizzazione di quello esistente devono essere seguiti i principi relativi all architettura distribuita multi-livello (multi tier distributed 29

30 application model). Questo scenario fa del middleware l elemento centrale. L obiettivo del middleware è di centralizzare l infrastruttura software e il suo deployment. Nella struttura dell organizzazione attuale, l integrazione viene estesa anche al di fuori dei suoi confini. Tramite Internet viene creata una rete globale dove l organizzazione e i suoi partners possono interagire velocemente ed efficientemente. Java fornisce una lingua franca per interconnettere facilmente dati e applicazioni fra l organizzazione e al di fuori di essa. In un ambiente globale distribuito dove non si può avere il controllo sulle scelte tecnologiche dei partners, si deve cercare di dirigersi verso delle piattaforme standard neutrali, Java 2 Enterprise Edition è la risposta a questo tipo di esigenze. La logica di business può essere implementata attraverso componenti riusabili posti nel middleware che permettono a differenti tipi di client di accedere ai tipi di dati eterogenei posti nel back end. Il front-end può essere costituito da varie tipologie di client quali desktop/browser, PDA, Web phones, thin client e da differenti piattaforme. Nel back end possono risedere diversi tipi di repository (RDBMS, ODBMS, Mainframe) su piattaforme altrettanto distinte Partizionamento dell applicazione Il partizionamento dell applicazione avviene in tre modi. Questi partizionamenti sono però concettuali e non vengono mappati necessariamente nei dettagli implementativi come schema del database o gerarchia delle classi. La prima partizione corrisponde all architettura Model-View-Controller (MVC), che separa la presentazione dei dati dalla rappresentazione e dal comportamento dell applicazione. La seconda partizione divide l applicazione in livelli multipli (multiple tier), individuando le applicazioni client, le funzionalità Web, le funzionalità Enterprise JavaBeans e il back-end persistente. La terza via di partizionamento riguarda la decomposizione modulare delle funzionalità. Ogni partizionamento d alto livello fornisce uno specifico beneficio al design. L architettura MVC apporta flessibilità, riusabilità, estendibilità e dei ruoli di design chiari per i componenti dell applicazione. Il design multiple tier permette una facile scelta delle tecnologie per l implementazione, scalabilità e possibilità di evolversi. Il design modulare decompone le funzionalità dell applicazione in sottosistemi intuitivi che premettono di essere analizzati, testati e compresi individualmente. Il tipo di partizionamenti presentati devono essere implementati attraverso la divisione dell applicazione in moduli funzionali e livelli multipli. Vengono riconosciuti i seguenti livelli: Presentation Tier, il cui scopo è presentare all'utente i contenuti informativi, si suddivide in: Il client tier, il quale è responsabile della presentazione dei dati all utente e comunica con gli altri tiers dell applicazione. Ad esempio client tier consiste nella visualizzazione sul browser di pagine web generate nel web tier. Il web tier, il quale è responsabile di tutte l elaborazioni relazionate con il cliente tier come servire pagine HTML, istanziare i template per le pagine web e formattare le pagine JSP per essere visualizzate sul browser. Il client che si va a costruire è di tipo thin e si occupa della gestione della logica di presentazione e d interazione con i livelli adiacenti. Business Tier, è il livello dove deve essere implementata la logica di business applicativa, in J2EE questo livello viene denominato Enterprise JavaBeans tier. L Enterprise JavaBeans tier è responsabile per ogni elaborazione riguardante la logica di business e viene implementato attraverso la tecnologia Enterprise Java Bean (EJB). Essenzialmente questo livello fornisce un modello a componenti per l accesso a servizi di sistemi distribuiti e ai dati persistenti (es. interazione con 30

31 sistemi diversi presenti sia all interno della rete aziendale sia esterni). Data tier consiste nel livello di gestione delle basi di dati. Enterprise Information System Tier, che comprende tutti i sistemi aziendali attualmente in funzione o in procinto di essere realizzati Presentation Tier L applicazione deve applicare il design pattern Model View Controller (MVC) non solo a macrolivello architetturale ma anche nell ambito specializzato del presentation tier. MVC separa tre forme di funzionalità all interno dell applicazione. Il Model rappresenta la struttura dei dati nell applicazione e le operazioni su questi. La View (possono essere più d una) presenta i dati in una certa forma all utente. Il Controller traduce le azioni dell utente (movimenti del mouse, tasti) e gli input in chiamate al model e seleziona la View appropriata. Essenzialmente il model descrive lo stato e le funzionalità dell applicazione, la view si occupa della presentazione e il controller del comportamento dell applicazione. Raffigurazione in dettaglio dei componenti MVC Nel caso del presentation tier implementato attraverso un browser, l architettura MVC trae vantaggio da entrambe le tecnologie servlet e JSP. Usa JSP per generare il presentation layer e le servlets per processare i task più intensivi. La servlet agisce come controller ed è incaricata di gestire l elaborazione delle request e la creazione di ogni bean od oggetto che venga usato dalle pagine JSP. Inoltre decide sulla base delle azioni dell utente a quale pagina JSP reindirizzare la request. Non vi è nessuna logica d elaborazione all interno della pagina JSP, essa deve solo ottenere l oggetto o i beans che sono stati creati in precedenza dalla servlet. Quest approccio permette una chiara separazione fra presentazione e contenuto. Con l aumentare della complessità dell applicazione aumentano anche i benefici derivanti dall utilizzo di quest architettura. Il presentation tier può essere implementato con tecnologie diverse purché rispetti i principi MVC. Si consiglia l utilizzo del browser come client ma evitando la tecnologia applet per problemi riguardanti il traffico di rete (questo principio può essere ignorato in particolari circostante previa autorizzazione da parte del Servizi Sistemi Informativi). Sono considerate accettabili per la realizzazione del lato client e delle interfacce utente le seguenti tecnologie: HTML oppure XHTML; XML/XSL, da utilizzare nella produzione di documenti dinamici. Ogni documento deve essere prodotto in formato XML e deve avere una DTD oppure un Xml-Schema di riferimento. Il rendering deve essere effettuato tramite fogli di stile XSL; PDF, da utilizzare nella produzione di stampe e documenti da firmare elettronicamente ed archiviare; 31

32 L applicazione deve essere installabile tramite la tecnologia Java Web Start ( ) Middle Tier Il livello intermedio si occupa dell'implementazione delle logiche di business (business tier). La logica di business viene gestita all interno dell application nell EJB Container. Le tipologie di enterprise bean che vivono nell EJB Container sono le seguenti: Session Bean, questa tipologia di oggetti gestisce le elaborazioni e l interazioni con altri oggetti al fine di eseguire la logica di applicativa. Nel farlo l utilizzo dei session bean deve essere fatto seguendo le indicazioni di pattern architetturali noti che risolvono in maniera ottimale le diverse tipologie di problematiche che si vanno ad incontrare al fine di portare a termine un processo. E' richiesto l'utilizzo delle transazioni di tipo CMT (Container Managed Transaction), completamente gestite tramite l'ejb server. Entity Bean, è preferibile l utilizzo di entity bean CMP per una questione di performance, qualora le richieste verso il database non siano possibili da effettuare attraverso entità bean (anche qui si vedano i pattern architetturali) è necessario utilizzare JDBC attraverso l utilizzo del pattern DAO. Message Driven Bean, sono utilizzabili per interfacciare sistemi di messaging e per la realizzazione di servizi eseguibili in modalità asincrona; Enterprise Information System Tier La strategia aziendale di sistema informativo vuole rendere possibile la cooperazione applicativa tra tutti i sistemi informatici, sia quelli di nuova concezione che quelli esistenti. Tutti i sistemi, anche se diversi per concezione e funzionamento, devono esporre un'interfaccia normalizzata costruita secondo lo standard WSDL. Tale condizione comporta la possibilità di utilizzare i sistemi aziendali attraverso una rete capace di assicurare buone performance e contemporaneamente garantire l'affidabilità del servizio Architetture dei sistemi settoriali e di servizio Per quanto riguarda lo sviluppo di applicazioni per sistemi settoriali e di servizio è possibile ricorre ad architetture "leggere", purchè rispettino il principio di essere web Based; una possibile architettura che si può adottare in questi casi è la cosiddetta LAMP (Linux, Apache, MySQL, PHP) come piattaforma per lo sviluppo di pagine e applicazioni in ambiente Web. LAMP è una soluzione completamente Open Source, che integra le potenzialità di un sistema operativo stabile ampiamente diffuso nel mondo Web (Linux), il Web Server più utilizzato in ambiente di rete (Apache), un database potente e versatile (MySQL) e un linguaggio di programmazione e scripting lato server completo. 5.3 Integrazione dati: protocolli per il trasporto dati Una volta realizzata la connessione, devono essere definite le modalità di scambio dei dati (marshaling) tra le componenti del sistema (protocollo di comunicazione applicativa). Il livello dati è responsabile dell'incapsulamento delle informazioni negli opportuni messaggi. La problematica deve essere risolta tramite l'adozione estensiva ed intensiva di XML e dei protocolli di scambio da 32

33 esso derivati Web Services Elemento chiave per lo sviluppo di applicazioni interoperanti in rete, essi possono essere considerati come il nuovo modo di utilizzo delle risorse del web secondo un paradigma computazionale distribuito. L'idea di web service si basa su diverse tecnologie complementari quali WSDL, SOAP e necessita di un opportuno Registry Service WSDL Web Services Description Language (WSDL) fornisce un metodo standard per definire quali funzioni renda disponibili uno specifico servizio Web XML, e quali argomenti si debba fornire per poterle utilizzare. Occorre definire un oggetto WSDL per ciascun servizio in modo da consentire al client di fruire di un livello di indirezione (o disaccoppiamento) evitando un accesso diretto al servizio. Anche la parte client deve considerare questo protocollo disaccoppiando la chiamata ai Web Services SOAP SOAP (Simple Object Access Protocol) è il protocollo di messaggi basato su XML che viene utilizzato per sviluppare una grande varietà di sistemi distribuiti. Questo protocollo definisce il formato dei messaggi da utilizzare per implementare funzionalità di tipo Remote Procedure Call, per la notifica di eventi asincroni, per il reindirizzamento attraverso intermediari, ed altro ancora. Si prevede di utilizzare SOAP unitamente al protocolli HTTP e HTTPS che hanno spiccate caratteristiche di scalabilità: HTTP è infatti uno dei protocolli di rete più scalabili. In alcuni casi è consentito l'utilizzo di SOAP unitamente ai protocolli FTP e SMTP ecc. E' comunque necessario che il processore XML sia accuratamente selezionato per garantire prestazioni e scalabilità adeguate Registry Service Il Registry Service consente la costruzione di un repository contenente le specifiche relative ai Web Services disponibili e fornisce gli strumenti per catalogare servizi basati su SOAP e WSDL. 5.4 Integrazione con altri sistemi Qualora fosse necessario interfacciare sistemi legacy (i cui servizi non fossero disponibili sotto forma di web service) si porrebbe un problema di System Integration. Relativamente alla piattaforma selezionata sono accettabili due diverse architetture: JCA, Java Connector Architecture: che realizza un modello di connessione punto-punto. La JCA definisce un'architettura standard utilizzabile per connettere la piattaforma J2EE a sistemi EIS eterogenei. L'event model JCA supporta un protocollo sincrono di tipo request/reply; 33

34 JMS, Java Message Service dove un Message-Oriented Middleware (MOM) può essere utilizzato a supporto della comunicazione asincrone punto-punto e peer-to-peer tra applicazioni diverse. Le API JMS permettono ad un'applicazione Java di creare, inviare, ricevere e leggere messaggi tramite l'utilizzo di prodotti di mercato (Tibco, Vitria, Ibus ecc...). 34