Standard Tecnologici

Transcript

1 Servizio Sistemi Informativi Standard Tecnologici Redatto: Versione: Data emissione: 13/02/2014 Nucleo Gestione Innovazione e fornitori IT Cronologia del documento (a partire dal 2014) Versione Data Autore Commento/Sintesi aggiornamenti principali /02/14 Annalisa Tomasi Introduzione del capitolo relativo all'eprescription e del capitolo relativo al FSE. 1

2 Indice 1.Sommario Deroghe Sistemi Server Hardware Software Software di base Posta Elettronica Application Server Sistemi di autenticazione: Single Sign-On Servizi RDBMS Situazione attuale Configurazione Piattaforma di Content Management System (CMS) 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 La soluzione implementata in APSS Firma digitale e conservazione sostitutiva La normativa di riferimento e le regole tecniche La soluzione implementata in APSS eprescription Ricetta medica elettronica FSE, Fascicolo Sanitario Elettronico La normativa di riferimento La soluzione implementata in APSS Ampere TREC Attività di adeguamento alla nuova normativa 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

3 Standard per la definizione di indicatori di qualità e linee guida Partecipazione al progetto IPSE da parte di APSS Realizzazione ed acquisizione di applicazioni Metodologia per lo studio e la realizzazione del software Requisiti non-funzionali Interoperabilità Portabilità Aderenza a Standard I.T Look and feel Manutenibilità Scalabilità e Performance Affidabilità, Disponibilità e Sicurezza 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) Browser standard AJAX HTML Flash Sicurezza e privacy Qualità dei beni e dei servizi ICT Specifiche Funzionali di Integrazione con il Sistema Informativo dell APSS Premessa Anagrafe ADT Pronto Soccorso CUP Clinical Data Repository / Order Management / Minimum Data Set Sistemi Diagnostici Radiology Information System, RIS Picture archiving and communication system, PACS Interoperabilità con LDAP o sistema GRU

4 1. 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/2013 sono delle seguenti tipologie: Sun Microsystems Sun Fire V490, E6900, V240; 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; Cisco UCS B-Series Blade; HP ML370, ML570, DL360, DL385, DL140, DL580 Gli storage in produzione al 31/12/2012 sono delle seguenti tipologie: EMC2 Clariion IBM DS4000 IBM DS4500 IBM DS4700 IBM TOTALSTORAGESAN32M-2 EMC VNX5300 Storageteck 3510, 2540, 6540, S1 6

7 2.2 Software Software di base HW Sistema Operativo Sparc Sun Unix-Solaris Vers. S.O. 10.0/9.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 S.O. Unix Solaris 10.0 /9.0 Windows 2008 Windows 2003 Windows 2000 Linux Tabella 2: Software di base per nuove installazioni Posta Elettronica Kernel 2.4 o successivi Il servizio di posta elettronica è fornito da una architettura MS Exchange 2003 con client MS Outlook e protocollo IMAP e POP3. La autenticazione avviene con protezione di accesso Kerberos/NTLM 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. 7

8 2.2.4 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 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. In APSS è stato adottato quale standard aziendale il prodotto OneSign Single Sign-On di Imprivata ( Nel dettaglio esso è composto da: una coppia di application server in configurazione loadbalancing equipaggiati con database ORACLE; versione 4.5 di Imprivata 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 Server 2003 Windows Server 2008 RDBMS ORACLE MS SQL ORACLE, Postgresql, MySQL File Service - Nativo - Print Service - Nativo - Proxy MS Proxy/ISA - Datawarehouse/E TL Business Object Web Intelligence ETL Business Object Antivirus Agente locale Symantec Norton Antivirus Symantec Antispam McAfee Secure Internet Gateway Backup Symantec Net backup 7.5 Middleware HL7 Middelware Mirth Integrated composite application network (JCAPS) Mirth_Connect (Windows Server 2003 R2) Mirth_Connect (Windows Server Linux Agente locale Symantec 9

10 Servizi Server/SW di base Server Application Server Unix/Solaris Windows Server 2003 JBOSS 4.x e successive Tomcat versione 4.X HTTP server Apache 2.x Tomcat versione 4.X e successive JBOSS 4.X e successive Windows Server R2) Linux tomcat Tabella 3: Schema di sintesi dei Servizi installati 3.2 Piattaforma di Content Management System (CMS) Lo standard aziendale per il CMS è Liferay Portal. Il sistema è attualmente utilizzato in versione Enterprise per la soluzione TREC, cartella clinica del cittadino della Provincia Autonoma di Trento e per il portale aziendale. 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 2006, Namespaces in XML 1.1 recommendations. POSIX:2008 (IEEE Std ). ISO/ IEC : Open Systems Interconnection--Basic Reference Model. ITU X.400. Serie ITU X.500. IEEE : OSI X-400 Based Electronic Messaging API. IEEE : Information Technology: Directory Services API. ISO 3166 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. 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 11

12 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. Come ribadito nelle Norme di Partecipazione, ai sensi e per gli effetti dell art. 113 e dell art. 75, comma 7 del D.Lgs. 163/2006 l importo della garanzia, e del suo eventuale rinnovo, è ridotto del 50% (cinquanta per cento) per gli operatori economici ai quali venga rilasciata, da organismi accreditati, ai sensi delle norme europee della serie UNI CEI EN e della serie UNI CEI EN ISO/IEC 17000, ISO/IEC 12207, la certificazione del sistema di qualità conforme alle norme europee della serie UNI CEI ISO 9000 e la certificazione per la sicurezza (ISO 27002:2007) riferita alla classe di fornitura 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 12

13 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 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. 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. 15

16 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 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, 16

17 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 a 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: 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. 17

18 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. Architettura Carta Nazionale dei Servizi 18

19 La soluzione implementata in APSS La soluzione di CNS implementata da APSS è quella fornita da Actalis sulla base della contratto quadro sottoscritto da CNIPA 1. La CNS è attualmente utilizzata a regime da oltre 1000 dirigenti prevalentemente medici per la firma nell'ambito dei Sistemi Informativi: Protocollo Informatico Laboratorio di analisi Anatomia Patologica Firma digitale e conservazione sostitutiva Le normative vigenti impongono alle aziende la conservazione di grandi quantità di documenti che devono essere opportunamente archiviati. Ciò determina un enorme spreco di risorse: da una parte di carta, dall'altra di spazi che potrebbero essere utilizzati per attività più proficue. Particolare attenzione viene quindi rivolta alle attività di 'dematerializzazione' dei documenti (e di conseguenza alla loro conservazione sostitutiva) al fine di: ridurre il numero dei documenti cartacei contenuti negli archivi (sostituendoli con opportune registrazioni informatiche) ridurre la creazione di nuovi documenti in formato carteceo preferendo il formato digitale sin dall'origine Il Codice dell amministrazione digitale, all articolo 1, definisce Documenti originali non unici quelli per i quali è possibile risalire al loro contenuto attraverso altre scritture o documenti di cui sia obbligatoria la conservazione, anche se in possesso di terzi : si tratta di un concetto innovativo e fondamentale che ha consentito lo sblocco della maggior parte delle difficoltà che impedivano l avvio della dematerializzazione. La suddetta normativa relativamente alla copia di documenti cartacei su supporto informatico, distingue l ambiente pubblico da quello privato. Per la Pubblica Amministrazione il regime giuridico è disciplinato dall articolo 22, comma 3, il quale stabilisce che Le copie su supporto informatico di documenti formati in origine su altro tipo di supporto sostituiscono, ad ogni effetto di legge, gli originali da cui sono tratti se la loro conformità all originale è assicurata dal funzionario a ciò delegato nell ambito dell ordinamento proprio dell amministrazione di provenienza, mediante l utilizzo della firma digitale e nel rispetto delle regole tecniche stabilite ai sensi dell articolo 71. Tale articolo stabilisce che le regole tecniche saranno emanate con Decreti del Presidente del Consiglio dei Ministri o del Ministro delegato per l innovazione e le tecnologie e che, nel frattempo, si applichino le regole tecniche in vigore. Pertanto, in questo specifico campo, 1 Oggi Agenzia Italia Digitale al posto di DigitPA 19

20 continuano a valere quelle a suo tempo emanate dal CNIPA 2 (Deliberazione n. 11/ ) in base al Testo Unico sulla documentazione amministrativa 4. Particolarmente importante è l articolo 4 di questa Deliberazione, che descrive il processo di conservazione sostitutiva di documenti cartacei: in sintesi, esso avviene mediante memorizzazione dell immagine dei documenti su supporti ottici, o su altra tecnologia equivalente (non vi sono vincoli né di formato né relativi al tipo di tecnologia usata), e termina con l apposizione del riferimento temporale (definisce la data dell'operazione) e della firma digitale (certifica la conformità al documento originale) da parte del responsabile della conservazione RCS o di un suo delegato, attestando in tal modo il corretto svolgimento del processo. Nel caso in cui l'operazione sia relativa a documenti originali unici è richiesta anche la firma digitale di un pubblico ufficiale. Terminate le procedure descritte, la registrazione informatica potrà essere esibita, ad ogni effetto di legge, in sostituzione del documento cartaceo da cui trae origine. Quindi per conservazione sostitutiva si intende quel processo che permette di conservare documenti in maniera che non si deteriorino e che, di conseguenza, risultino disponibili nel tempo nella loro integrità e autenticità conservando piena validità legale e fiscale. L'articolo 5 delle deliberazione in oggetto stabilisce i compiti del Responsabile del procedimento di Conservazione Sostitutiva (RCS) La normativa di riferimento e le regole tecniche DPCM 3/12/2013 recante nuove norme in materia di conservazione sostitutiva; 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 originali, sostituita nei termini previsti dai commi 2 (36 mesi di tempo) e 3(gestione del pregresso) del DPCM 3/12/13; 2 Il Centro Nazionale per l Informatica nella Pubblica Amministrazione (CNIPA) opera presso la Presidenza del Consiglio per l attuazione delle politiche del Ministro per le riforme e le innovazioni nella PA. 3 Deliberazione del 19 febbraio 2004, pubblicata in G.U. Il 9 marzo 2004, n DPR 28 dicembre 2000, n. 445, e successive modifiche. 20

21 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 La soluzione implementata in APSS La soluzione di firma digitale oggi adottata è descritta al paragrafo La soluzione implementata in APSS, numero ed è in fase di avvio il sistema che fornisce la funzionalità di firma digitale remota (HSM) proposto dalla ditta Infocert di Padova in outsourcing. Il prodotto utilizzato è LegalCert Remote Sign Enterprise. La soluzione adottata dalla Azienda Provinciale per i Servizi Sanitari in merito alle funzionalità di firma digitale remota e conservazione sostitutiva sono quelle fornite dalla ditta Infocert Spa che risulta nell'elenco dei certificatori di Firma Digitale pubblicato da DigitPA ( I documenti destinati alla conservazione sostitutiva sono in formato pdf-a, sono firmati digitalmente e sono prodotti da parte dei sistemi informativi Protocollo documentale, Laboratorio, Radiologia, Anatomia e Sistema Informativo Ospedaliero La conservazione sostitutiva dei documenti si compone delle seguenti procedure: Memorizzazione del lotto dei documenti su storage ad alta affidabilità 1. acquisizione, composizione del messaggio HL7 ed invio del lotto dei documenti e dei relativi attributi attraverso interrogazione al Repository aziendale dei referti al broker L-Care per l archiviazione e indicizzazione dei documenti sulla base degli attributi: cognome, nome, sesso, data di nascita, codice fiscale, data esame, id documento, Centro di Responsabilità, data firma del documento; 2. composizione ed invio da parte di L-Care al servizio LegalDoc di Infocert con firam del lotto da parte del Responsabile della Conservazione Sostitutiva; 3. aggiornamento del Repository aziendale dei referti con i dati relativi all esito delle procedure di conservazione comprensivo del token LegalDoc. Attribuzione del riferimento temporale Il sistema utilizza, per soddisfare il requisito di apposizione del riferimento temporale richiesto per la procedura di conservazione prevista dalla deliberazione CNIPA [2] (art. 5 comma 1 lett. g), le Marche Temporali fornite dal servizio di Time Stamping di InfoCert. Le marche temporali prodotte sono firmate da un certificato emesso mensilmente dalla TSA di InfoCert accreditata presso il CNIPA, sono di tipo detached ed hanno una validità di 20 anni. 21

22 Esibizione dei documenti conservati L esibizione dei documenti conservati avviene da parte di personale autorizzato di Apss mediante l interfaccia dell'esibitore LegalDoc di Infocert. L interfaccia permette ad un utente abilitato di ricercare ed eventualmente visualizzare i documenti di una determinata tipologia sottoposti al processo di Conservazione Sostitutiva presenti all interno dell archivio. A seguito dell accesso a tale funzionalità è possibile visualizzare la lista di tutte le classi documentali per le quali l utente può effettuare le ricerche. Successivamente, selezionando la tipologia di interesse, viene visualizzata una form, costruita dinamicamente in base alle caratteristiche della classe documentale, per l inserimento di tutti i parametri del documento in base ai quali effettuare la ricerca. Alla conferma dell utente l applicazione esegue la ricerca visualizzando la lista di documenti che rispondono ai parametri selezionati. Per ciascun documento della lista viene mostrato: un link che consente la visualizzazione di tutte le informazioni disponibili per il documento; un link che recupera il documento dall archivio. Visualizzando tutte le informazioni disponibili per il documento è possibile, tramite apposito link, recuperare l intero Lotto di Documenti sottoposto a Conservazione Sostitutiva e successivamente verificarne la Firma Digitale e la Marca Temporale. L Azienda ha acquisito il Sistema Informatico Scryba (versione 3.1.0) di Medas ( per l espletamento delle attività di Conservazione Sostitutiva delle immagini digitali prodotte dal Dipartimento di Radiologia tramite il sistema PACS Synapse. Gli applicativi informatici che producono o contengono i documenti da conservare interagiscono con Scryba grazie ad un apposito modulo sw, denominato Scryba Adapter. Ogni Scryba Adapter è sviluppato in accordo tra il produttore di Scryba ed il produttore dell applicativo esterno. Fa eccezione l Adapter per i sistemi PACS in quanto il dialogo tra Scryba e tali sistemi avviene tramite il protocollo standard DICOM. Il flusso informativo in Scryba si articola nelle fasi consecutive di ricezione, consolidamento probatorio, conservazione sostitutiva e gestione copie di sicurezza e consente la realizzazione di una struttura organizzativa idonea alla gestione del procedimento di conservazione sostitutiva della documentazione clinica digitale in modo da adempiere a quanto prescritto dalla deliberazione CNIPA eprescription Ricetta medica elettronica L'ePrescription è la versione elettronica della prescrizione cartacea per farmaci o visite specialistiche o ricoveri, la cui definizione deriva dai presupposti contemplati nell'articolo 50, del decreto legge 30/09/2009 n. 269 convertito con modificazione dalla legge 24/11/2003 n. 326 e successive modificazione, recante disposizioni in materia di monitoraggio della spesa nel settore sanitario e di appropriatezza delle prescrizioni sanitarie. Con il DPCM del 26 marzo 2008 sono state disciplinate le modalità di trasmissione telematica dei dati delle ricette da parte dei medici del SSN. In attuazione del DPCM, il Ministero della salute ha partecipato alle attività per la definizione dei Piani Regionali attuativi. Il programma di avvio a regime della trasmissione per via telematica delle ricette da parte dei medici prescrittori, è stato definito dai decreti ministeriali indicati di seguito: il decreto ministeriale 21 luglio 2011, ha definito il programma di avvio a regime della trasmissione per via telematica delle ricette da parte dei medici prescrittori nelle seguenti 22

23 Regioni: Provincia Autonoma di Trento (1 ottobre 2011), Toscana e Sardegna (31 dicembre 2011) e Puglia (31 gennaio 2012). Di rilevante importanza, in questo ambito applicativo, è il decreto legge n.78/2010 recante Misure urgenti in materia di stabilizzazione finanziaria e di competitività economica, convertito, con modificazioni, nella legge 30 luglio 2010, n. 122 il quale stabilisce, all articolo 11, comma 16, quanto segue: ai fini della trasmissione telematica delle ricette mediche di cui all articolo 50, commi 4, 5 e 5-bis del decreto-legge n. 269/03 convertito, con modificazioni, dalla legge n. 326/03, viene previsto l utilizzo della stessa piattaforma messa a disposizione per la trasmissione telematica dei certificati di malattia; l invio telematico dei dati relativi alle ricette mediche sostituisce a tutti gli effetti la prescrizione medica in formato cartaceo. In attuazione dell'articolo 11, comma 16, del decreto legge n. 78/2010 convertito, con modificazioni, dalla legge 30 luglio 2010, n. 122, il Ministero della salute ed il Ministero dell'economia e delle finanze hanno adottato il decreto 2 novembre 2011 (G.U. n. 264 del 12 novembre 2011), con cui sono state definite le modalità tecniche per la dematerializzazione della ricetta medica cartacea per le prescrizioni a carico del SSN e dei SASN. L attuazione delle disposizioni contenute nel decreto ministeriale è rimessa a piani di diffusione da sottoscrivere con le singole Regioni. La PAT si è attivata tramite APSS come SAR (Servizio di Accoglienza Regionale) nei confronti del SAC (Servizio di Accoglienza Regionale) per l'invio delle prescrizioni elettroniche prodotte dai medici convenzionati e dai medici dipendenti della APSS e per la dematerializzazione dei documenti cartacei di prescrizione nella fase di erogazione per quanto riguarda il farmaco. Il progetto è stato concordato con il Ministero dell'economia e della finanza e Sogei, Società Generale d'informatica SpA - società di Information Technology 100% del Ministero dell'economia e delle Finanze preposta al settore IT del Ministero medesimo. Per quanto riguarda l'invio delle prescrizioni, all interno della architettura adottata sono individuati due percorsi, che fanno riferimento il primo alle modalità di interfacciamento del SAR con il SAC per la gestione dei lotti di Numero Ricetta Elettronica NRE, il secondo alle modalità di generazione, numerazione ed invio al SAC delle Prescrizioni elettroniche. Secondo questa impostazione, l elemento che costituisce il legame fra i vari ambiti del percorso diagnostico/terapeutico del paziente è costituito dall identificativo della prescrizione che ne rappresenta il punto iniziale (NRE, Numero di Ricetta Elettronica). Ci si basa quindi sulla assegnazione da parte di SOGEI di un range di numeri (protocolli) associati a lotti, gestiti centralmente da APSS in qualità di SAR. Tali numeri di ricetta vengono assegnati ai prescrittori con modalità diverse ma garantendo in ogni caso l associazione tra NRE, medico prescrittore e conseguente prescrizione prodotta. Le comunicazioni tra i vari attori del sistema di Gestione della Prescrizione Elettronica all interno del SAR si basa sullo scambio di messaggistica XML su protocollo http (web services) definiti nel seguito del presente documento. La comunicazione tra SAR e SAC avverrà secondo lo standard definito da SOGEI. Per quanto riguarda la erogazione del farmaco che vede il progressivo coinvolgimento di tutte le farmacie del territorio, sono ora introdotte le funzionalità di stampa dei promemoria al posto della c.d. ricetta rossa o dell'invio informatizzato alle farmacie della prescrizione a fronte della autorizzazione rilasciata dal paziente; sulla base di tale flusso informativo viene consegnato il farmaco al paziente e contestualmente aggiornato il dato relativo all'erogato sul sistema centrale (SAC). 23

24 Il contenuto della eprescription è basato sempre sulle indicazioni di SOGEI e non su quanto definito dal TSE nel documento Standard tecnici per la creazione del Documento di Prescrizione da inviare al SAC secondo lo standard HL7-CDA Rel. 2. Diagramma Sequenza Prescrizione elettronica Prescrittore On -Line (Dati corretti ) Prescrittore SAR 2: Richiesta stampa 11: Stampa Prescrizione 1: Inserimento dati Prescrizione 3: Invio dati Prescrizione 5: Assegnazione NRE 8: Calcolo tipo stampa 10: NRE+Cod. Autent.+Tipo stampa 4: Verifica correttezza dati 6: Invio Prescrizione 7: Ritorno Cod. Autent. 9: Memorizzazione dati SAC La Direttiva di riconoscimento delle ricette mediche tra stati membri, la n. 2012/52/UE dovrà essere recepita entro ottobre 2013 sul territorio dell'ue con la messa in atto delle disposizioni legislative, regolamentari e amministrative necessarie FSE, Fascicolo Sanitario Elettronico La normativa di riferimento Il Decreto del Fare dell'estate del 2013 e la Legge 221/2012 che istituisce il FSE. Il Fascicolo Sanitario Elettronico, inteso come l'insieme dei dati e documenti digitali di tipo sanitario e sociosanitario generati da eventi clinici presenti e trascorsi, riguardanti l'assistito, è previsto dall articolo 12 della Legge 221 del 2012, istituito dalla Regioni e dalle province autonome ai fini di prevenzione, diagnosi, cura e riabilitazione, studio e ricerca scientifica in campo medico, biomedico ed epidemiologico, programmazione sanitaria, verifica delle qualità delle cure e valutazione dell assistenza sanitaria. Tale legge converte con modificazioni in D.L. 179/2012. Sulla base di quanto indicato dall'articolo 12 della L.221/2012 e di quanto previsto dall'articolo 15 della L.135/2012 si possono evidenziare, tra le altre, le seguenti caratteristiche del FSE: è istituito dalle regioni e province autonome; è obbligatorio (sulla base della modifica apportata dal c.d. Decreto del FARE ); deve consentire anche l'accesso da parte dei cittadini ai servizi sanitari online; con decreto del Ministro della salute e del Ministro delegato per l'innovazione tecnologica, di concerto con il Ministro per la pubblica amministrazione e la semplificazione e il Ministro dell'economia e delle finanze, sentita la Conferenza permanente per i rapporti tra lo Stato, le regioni e le province autonome di Trento e di Bolzano, acquisito il parere del Garante per la protezione dei dati personali, ai 24

25 sensi dell'articolo 154, comma 4, del decreto legislativo 30 giugno 2003, n. 196, dovranno essere definiti i contenuti del FSE e i limiti di responsabilità e i compiti dei soggetti che concorrono alla sua implementazione. il decreto c.d. del FARE L. 69/2013 che modifica l'art. 12 della L. 221 del 2012, prevede che il FSE sia obbligatorio per le Regioni e le Province Autonome ed che entro il 30/06/2014 debbano essere presentati i piani di progetto per la realizzazione dei FSE alla Agenzia per l'italia Digitale; il DPCM del 17/10/2013 definisce i contenuti del FSE, i limiti di responsabilità e i compiti dei soggetti che concorrono alla implementazione, i sistemi di codifica dei dati, le garanzie e le misure di sicurezza da adottare nel trattamento dei dati personali nel rispetto dei diritti dell'assistito, le modalità e i livelli diversificati di accesso al FSE da parte dei diversi soggetti individuati dai commi 4,5 e 6 del D.L. 179/2012 e ss.mm., la definizione e le relativi modalità di attribuzione di un codice identificativo univoco dell'assistito che non consenta l'identificazione diretta dell'assistito, i criteri per l'interoperabilità del FSE a livello regionale, nazionale ed europee, nel rispetto delle regole tecniche del sistema pubblici di connettività, nonché le modalità di accesso ai servizi sanitari on line da parte del cittadini, ai sensi del secondo periodo del secondo comma dell'articolo 12 del D.L. 179/ La soluzione implementata in APSS In PAT i Sistemi Informativi che realizzano il FSE sono il progetto Ampere, realizzato nell'ottica della condivisione di dati tra le strutture che svolgono servizi sanitari della Provincia Autonoma di Trento e più recentemente il Sistema TREC che consente inoltre l'accesso del cittadino ai servizi sanitari online. 1. Ampere Ampere è il servizio aziendale di interconnessione telematica tra l'azienda Provinciale per i Servizi Sanitari della Provincia Autonoma di Trento, i Medici di Medicina Generale - MMG ed i Pediatri di Libera Scelta - PLS per lo scambio in Rete di dati sanitari ed anagrafici tra i soggetti coinvolti nel processo di cura del cittadino nell'ottica di fornire un sistema di offerta dei servizi sanitari integrato, attraverso sicure modalità di trasferimento delle informazioni, con fruibilità tempestiva da parte di tutti i soggetti opportunamente abilitati. I riferimenti normativi sono i seguenti: o DPCM 26/03/2008 Attuazione del comma 810 dell'articolo 1 della L.296/2006 in materia di regole tecniche e trasmissione dati di natura sanitaria nel sistema pubblico di connettività ; decreto 21/07/2011 Avvio a regime del sistema di trasmissione dei dati delle ricette del SSN da parte dei medici prescrittori, per la PAT ; deliberazione di Giunta Provinciale n. 548 del 25/3/2011 Atto di indirizzo in materia di sanità elettronica TREC TREC è il Fascicolo Sanitario Elettronico della Provincia Autonoma di Trento, è in produzione dal giugno 2012 ed oggi conta quasi utenti, il 4,6% della popolazione trentina. Di seguito si riporta una sintesi dei documenti presenti nell'ambito del progetto Ampere e quindi nell'ambito del TREC. Referto di Laboratorio di analisi referto di Radiologia 25

26 referto di Anatomia Patologica referto di TAO referto di ECG referto di Alta Specialità referto di Gastroenterologia Referto di Continuità Assistenziale con piani terapeutici Referto di Assistenza domiciliare Certificati di Vaccinazioni Referto Ambulatoriale Altri referti? Verbali di PS Lettere di dimissione Profilo sanitario sintetico Prescrizioni specialistiche Erogazione farmaci (prescrizioni) Cartelle cliniche di ricovero Bilanci di salute Assistenza residenziale e semi-residenziale: scheda UVM Certificati di malattia Certificati di infortunio Le modalità di identificazione del cittadino al Sistema TreC che sono rese disponibili sono in elenco: mediante l'utilizzo della TS-CNS (Tessera Sanitaria Carta Nazionale dei Servizi) come previsto dalla normativa di accesso ai servizi online da parte del cittadino (vedere nel paragrafo relativo all'identificazione in rete del cittadino per i servizi online); mediante servizio di One Time Password OTP fornito da Telecom Italia; mediante servizio di accesso con scambio di SMS tramite applet per iphone; servizio di accesso con scambio di SMS tramite cellulari standard (in fase di definizione) Attività di adeguamento alla nuova normativa La APSS partecipa su incarico della PAT al gruppo di lavoro tecnico istituito presso l'agenzia per l'italia Digitale con determinazione commissariale, con finalità di predisporre entro il 30/03/14 le linee guida relative alla presentazione dei piani di progetto per la realizzazione del FSE, a cura delle Regioni e Province Autonome, e di svolgere inoltre un ruolo attivo al fine della valutazione dei progetti stessi. Il sistema TreC è attualmente pubblicato nel catalogo del riuso gestito dalla Agenzia per l'italia Digitale

27 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 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 27

28 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 Information source Patient identity consumer Patient identity cross reference manager Patient identity source 28

29 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 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 29

30 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). 4.4 Partecipazione al progetto IPSE da parte di APSS La Azienda Provinciale per i Servizi Sanitari ha contribuito alla realizzazione del progetto concluso nel giugno 2012 di Sperimentazione di un sistema per l'interoperabilità europea e nazionale delle soluzioni regionali di FSE, IPSE, co-promosso dal Dipartimento per la Digitalizzazione della Pubblica Amministrazione e l'innovazione Tecnologica e da una decina di regioni italiane tra le quali la Provincia Autonoma di Trento. I risultati del progetto resi pubblici da parte del Dipartimento per la Digitalizzazione della Pubblica Amministrazione e l'innovazione Tecnologica, hanno in particolare visto la adozione in via sperimentale dei seguenti elementi di informatica medica: 2. lo standard per il Patient Summary così come definito dal Tavolo della Sanità Elettronica; l'architettura InFSE di Fascicolo sanitario elettronico federato realizzata dal CNR; il Sistema Pubblico di Connettività SPC lo standard SAML 2.0 (Security Assertion Markup Language) per la gestione degli accessi a informazioni e servizi anche da parte di utenti non registrati nel dominio erogatore. 30

31 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 Standard 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à; I sistemi che seguono lo stato dell arte evolvono più rapidamente e con una strategia ben definita; 31

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

33 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 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; 33

34 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 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 34

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

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

37 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; 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 37

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

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

40 40