Standard Tecnologici

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "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 (http://www.imprivata.com/onesign_sso). 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 (http://www.digitpa.gov.it/certificatori_firma_digitale). 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 (http://www.medas-solutions.it/soluzioni.asp) 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 (http://java.sun.com/products/javawebstart/ ) 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

Il Sistema Informativo Sanitario Territoriale della Puglia

Il Sistema Informativo Sanitario Territoriale della Puglia Il Sistema Informativo Sanitario Territoriale della Puglia Assessorato al Welfare e alle Politiche della Salute Bari, 16 luglio 2014 Il Fascicolo Sanitario Elettronico L'art. 12 del D.L. 179 del 18 ottobre

Dettagli

La Posta Elettronica Certificata - Pec

La Posta Elettronica Certificata - Pec Ministero della Pubblica Istruzione Ufficio Scolastico Regionale per il Veneto Ufficio Scolastico Provinciale di Padova Area della comunicazione e web La Posta Elettronica Certificata - Pec Piccola guida

Dettagli

La Posta Elettronica Certificata

La Posta Elettronica Certificata Contenuti PA digitale La Posta Elettronica Certificata Paola Cantamessa Direzione Enti Locali Cos è la PEC: E un sistema di comunicazione simile alla posta elettronica standard a cui si aggiungono delle

Dettagli

La PEC e la valenza legale: come eliminare la Raccomandata cartacea

La PEC e la valenza legale: come eliminare la Raccomandata cartacea La PEC e la valenza legale: come eliminare la Raccomandata cartacea Codice Amministrazione i i Digitaleit D.P.R. 11/02/2005 n. 68 Decreto MIT 2/11/2005 16/07/2009 dott. Flavio Perico 1 Decreto del Presidente

Dettagli

Prot. n 169 Salerno, lì 24 Febbraio 2016

Prot. n 169 Salerno, lì 24 Febbraio 2016 Prot. n 169 Salerno, lì 24 Febbraio 2016 A tutti gli iscritti all Albo e nell Elenco Speciale LORO SEDI OGGETTO: Circolare n 38/2016. Libera professione. Nuove Tecnologie. La P.E.C. (Posta Elettronica

Dettagli

Servizio Sistemi Informativi Standard Tecnologici

Servizio Sistemi Informativi Standard Tecnologici Servizio Sistemi Informativi Standard Tecnologici Redatto: Nucleo Gestione Innovazione e fornitori IT Versione: 1.4.12 Data emissione: 13/01/2012 1 Indice Sommario...4 1 Deroghe...5 2 Sistemi Server...6

Dettagli

Disposizioni in materia di rilascio e di uso della casella di posta elettronica certificata assegnata ai cittadini.

Disposizioni in materia di rilascio e di uso della casella di posta elettronica certificata assegnata ai cittadini. D.P.C.M. 6 maggio 2009 1 e 2 Disposizioni in materia di rilascio e di uso della casella di posta elettronica certificata assegnata ai cittadini. IL PRESIDENTE DEL CONSIGLIO DEI MINISTRI Visto il decreto

Dettagli

DOCUMENTI INFORMATICI E ARCHIVI DIGITALI

DOCUMENTI INFORMATICI E ARCHIVI DIGITALI Prof. Stefano Pigliapoco DOCUMENTI INFORMATICI E ARCHIVI DIGITALI s.pigliapoco@unimc.it Il nuovo codice dell amministrazione digitale (CAD) Il decreto legislativo 30 dicembre 2010, n. 235, adottato a norma

Dettagli

Firma Digitale per il il Consiglio Nazionale degli Ingegneri

Firma Digitale per il il Consiglio Nazionale degli Ingegneri Firma Digitale per il il Consiglio Nazionale degli Ingegneri :: Firma Digitale :: La Firma Digitale è il risultato di una procedura informatica che garantisce l autenticità e l integrità di messaggi e

Dettagli

Servizio Sistemi Informativi Standard Tecnologici

Servizio Sistemi Informativi Standard Tecnologici Servizio Sistemi Informativi Standard Tecnologici Redatto: Nucleo Gestione Innovazione e fornitori IT Versione: 1.4.11 Data emissione: 21/6/2010 1 Indice Sommario...4 1 Deroghe...5 2 Sistemi Server...6

Dettagli

K-Archive. Conservazione Sostitutiva

K-Archive. Conservazione Sostitutiva K-Archive per la Conservazione Sostitutiva Descrizione Prodotto Per informazioni: MKT Srl Corso Sempione 33-20145 Milano Tel: 02-33104666 FAX: 20-70039081 Sito: www.mkt.it Email: ufficio@mkt.it Copyright

Dettagli

Firma Digitale per l Ordine degli Ingegneri di Napoli

Firma Digitale per l Ordine degli Ingegneri di Napoli Firma Digitale per l Ordine degli Ingegneri di Napoli :: Firma Digitale :: La Firma Digitale è il risultato di una procedura informatica che garantisce l autenticità e l integrità di messaggi e documenti

Dettagli

IL PRESIDENTE DEL CONSIGLIO DEI MINISTRI

IL PRESIDENTE DEL CONSIGLIO DEI MINISTRI 1 DECRETO DEL PRESIDENTE DEL CONSIGLIO DEI MINISTRI 27 settembre 2012 Regole tecniche per l'identificazione, anche in via telematica, del titolare della casella di posta elettronica certificata, ai sensi

Dettagli

OpenPEC: La soluzione open source per la Posta Elettronica Certificata

OpenPEC: La soluzione open source per la Posta Elettronica Certificata OpenPEC: La soluzione open source per la Posta Elettronica Certificata Descrizione della soluzione White paper Autore EXEntrica srl Versione 1.5 Data 17/10/2008 Copyright 2007 EXEntrica srl Pag 1 di 7

Dettagli

Conservazione del documento informatico ed i conservatori accreditati. Agenzia per l Italia Digitale

Conservazione del documento informatico ed i conservatori accreditati. Agenzia per l Italia Digitale Conservazione del documento informatico ed i conservatori accreditati Agenzia per l Italia Digitale 21-11-2014 L «ecosistema» della gestione dei documenti informatici PROTOCOLLO INFORMATICO FIRME ELETTRONICHE

Dettagli

Quali azioni per l implementazione del FSE: l esperienza della Regione Puglia

Quali azioni per l implementazione del FSE: l esperienza della Regione Puglia Quali azioni per l implementazione del FSE: l esperienza della Regione Puglia ing. Vito Bavaro email: v.bavaro@regione.puglia.it Ufficio Sistemi Informativi e Flussi Informativi Servizio Accreditamento

Dettagli

Posta Elettronica Certificata e Firma Digitale. CST Monterraneo, 9 Febbraio 2011

Posta Elettronica Certificata e Firma Digitale. CST Monterraneo, 9 Febbraio 2011 Posta Elettronica Certificata e Firma Digitale CST Monterraneo, 9 Febbraio 2011 Agenda Posta Elettronica Certificata Cos è Riferimenti normativi Soggetti Flusso dei messaggi Vantaggi PEC nella Pubblica

Dettagli

Caso di studio nazionale sul Taccuino e PHR : Toscana

Caso di studio nazionale sul Taccuino e PHR : Toscana Caso di studio nazionale sul Taccuino e PHR : Toscana Alessandra Morelli Regione Toscana Trento, 21 marzo 2014 AGENDA Il Sistema Sanitario della Toscana (SST) Obiettivi e strumenti Sistema ICT Il progetto

Dettagli

Ministero del Lavoro e delle Politiche Sociali

Ministero del Lavoro e delle Politiche Sociali Ministero del Lavoro e delle Politiche Sociali Prospetto Informativo on-line Standard tecnici del sistema informativo per l invio telematico del Prospetto Informativo Documento: UNIPI.StandardTecnici Revisione

Dettagli

IL RAGIONIERE GENERALE DELLO STATO

IL RAGIONIERE GENERALE DELLO STATO Determina del Ragioniere generale dello Stato concernente le modalità di trasmissione e gestione di dati e comunicazioni ai Registri di cui al decreto legislativo 27 gennaio 2010, n. 39, concernente la

Dettagli

White Paper. Per informazioni puoi rivolgerti presso l Agenzia:

White Paper. Per informazioni puoi rivolgerti presso l Agenzia: White Paper Per informazioni puoi rivolgerti presso l Agenzia: Pagina 2 di 12 Versione 2.0 Sommario Per informazioni puoi rivolgerti presso l Agenzia:... 1... 1 White Paper... 1 1. Introduzione... 3 2.

Dettagli

Il Codice dell Amministrazione Digitale LA POSTA ELETTRONICA CERTIFICATA. Prefettura di Reggio Calabria 23-25 novembre 2010 www.vincenzocalabro.

Il Codice dell Amministrazione Digitale LA POSTA ELETTRONICA CERTIFICATA. Prefettura di Reggio Calabria 23-25 novembre 2010 www.vincenzocalabro. Il Codice dell Amministrazione Digitale LA POSTA ELETTRONICA CERTIFICATA Prefettura di Reggio Calabria 23-25 novembre 2010 www.vincenzocalabro.it 1 Il Codice dell Amministrazione Digitale Capo IV - Trasmissione

Dettagli

Decreto 2 novembre 2005 Regole tecniche per la formazione, la trasmissione e la validazione, anche temporale, della posta elettronica certificata

Decreto 2 novembre 2005 Regole tecniche per la formazione, la trasmissione e la validazione, anche temporale, della posta elettronica certificata Decreto 2 novembre 2005 Regole tecniche per la formazione, la trasmissione e la validazione, anche temporale, della posta elettronica IL MINISTRO PER L'INNOVAZIONE E LE TECNOLOGIE - Visto l articolo 17

Dettagli

La generazione del documento informatico firmato online:

La generazione del documento informatico firmato online: La generazione del documento informatico firmato online: Formazione, sottoscrizione e trasmissione dei documenti informatici. L esperienza con il Comune di Parma Stefano Conforto Sertorelli Business Development

Dettagli

L AMMINISTRAZIONE PUBBLICA DIGITALE: OPPORTUNITÀ E OBBLIGHI PER GLI ENTI ERP

L AMMINISTRAZIONE PUBBLICA DIGITALE: OPPORTUNITÀ E OBBLIGHI PER GLI ENTI ERP Prof. Stefano Pigliapoco L AMMINISTRAZIONE PUBBLICA DIGITALE: OPPORTUNITÀ E OBBLIGHI PER GLI ENTI ERP s.pigliapoco@unimc.it La società dell informazione e della conoscenza La digitalizzazione delle comunicazioni,

Dettagli

PER IL RILASCIO E L UTILIZZO DEL SERVIZIO DI POSTA ELETTRONICA CERTIFICATA DELL AZIENDA OSPEDALIERA UNIVERSITARIA FEDERICO II PER FINI ISTITUZIONALI

PER IL RILASCIO E L UTILIZZO DEL SERVIZIO DI POSTA ELETTRONICA CERTIFICATA DELL AZIENDA OSPEDALIERA UNIVERSITARIA FEDERICO II PER FINI ISTITUZIONALI REGOLAMENTO PER IL RILASCIO E L UTILIZZO DEL SERVIZIO DI POSTA ELETTRONICA CERTIFICATA DELL AZIENDA OSPEDALIERA UNIVERSITARIA FEDERICO II PER FINI ISTITUZIONALI Approvato con deliberazione n. 463 del 10.08.2015

Dettagli

DECRETO DEL PRESIDENTE DEL CONSIGLIO DEI MINISTRI

DECRETO DEL PRESIDENTE DEL CONSIGLIO DEI MINISTRI DECRETO DEL PRESIDENTE DEL CONSIGLIO DEI MINISTRI 6 maggio 2009 Disposizioni in materia di rilascio e di uso della casella di posta elettronica certificata assegnata ai cittadini. (09A05855) IL PRESIDENTE

Dettagli

IL PRESIDENTE DEL CONSIGLIO DEI MINISTRI

IL PRESIDENTE DEL CONSIGLIO DEI MINISTRI dalla G.U. n. 59 del 12 marzo 2014 (s.o. n. 20) DECRETO DEL PRESIDENTE DEL CONSIGLIO DEI MINISTRI 3 dicembre 2013 Regole tecniche in materia di sistema di conservazione ai sensi degli articoli 20, commi

Dettagli

ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO

ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO Standard tecnici Gli standard tecnici di riferimento adottati sono conformi alle specifiche e alle raccomandazioni emanate dai principali

Dettagli

Appendice 2 POSTA ELETTRONICA CERTIFICATA

Appendice 2 POSTA ELETTRONICA CERTIFICATA Versione 1.0 Aggiornato al 29 Luglio 2009 www.to.camcom.it/guideregistroimprese Appendice 2 POSTA ELETTRONICA CERTIFICATA ANAGRAFE ECONOMICA - REGISTRO IMPRESE REGISTRO IMPRESE CAMERA DI COMMERCIO DI TORINO

Dettagli

Normativa di riferimento

Normativa di riferimento Normativa di riferimento 1 Evoluzione della normativa Nel Art. CP 491-bis doc. informatico del C.P. =supporto L. contenente 547 una «res» come 23/12/1993 il documento L 547 23/12/1993 Legge semplificazione

Dettagli

Il Fascicolo Sanitario Elettronico. in TRENTINO

Il Fascicolo Sanitario Elettronico. in TRENTINO Trieste, 20 giugno 2014 Il Fascicolo Sanitario Elettronico in TRENTINO luciano.flor@apss.tn.it 1 e-health in P.A. di Trento anno 2014 al 3 giugno SIO APSS e ACCREDITATE Fascicolo sanitario elettronico

Dettagli

CONFERENZA SULLA SANITA ELETTRONICA

CONFERENZA SULLA SANITA ELETTRONICA CONFERENZA SULLA SANITA ELETTRONICA CONFERENZA SULLA SANITA ELETTRONICA Il percorso di adozione del Fascicolo Sanitario Elettronico in Italia Lidia Di Minco Direttore Ufficio Nuovo Sistema Informativo

Dettagli

Il Portale Continuità della Cura è un applicativo web già in uso da vari anni da parte dei MMG/PLS FVG che accorpa funzioni di:

Il Portale Continuità della Cura è un applicativo web già in uso da vari anni da parte dei MMG/PLS FVG che accorpa funzioni di: Affidamento servizi IT di progettazione e realizzazione sw per l estensione funzionale del portale web regionale Continuità della Cura () : Patient Summary/FSE, estensione della cartella clinica del paziente,

Dettagli

DIREZIONE CENTRALE. Attività Produttive, Politiche del Lavoro e dell'occupazione ----------------------------------------------

DIREZIONE CENTRALE. Attività Produttive, Politiche del Lavoro e dell'occupazione ---------------------------------------------- DIREZIONE CENTRALE Attività Produttive, Politiche del Lavoro e dell'occupazione ---------------------------------------------- Protocollo d Intesa tra Il Comune di Milano e l Ordine dei Consulenti del

Dettagli

L informatizzazione in ambiente sanitario: prospettive attuali e future

L informatizzazione in ambiente sanitario: prospettive attuali e future L informatizzazione in ambiente sanitario: prospettive attuali e future Dott. Pietro Paolo Faronato Direttore Generale Azienda ULSS 1 Belluno Padova, 27 settembre 2013 1 Verso la Sanità Digitale Sanità

Dettagli

L EMAIL: ISTRUZIONI PER L USO Strumenti, metodi e criticità per creare, gestire e conservare la posta elettronica

L EMAIL: ISTRUZIONI PER L USO Strumenti, metodi e criticità per creare, gestire e conservare la posta elettronica Prof. Stefano Pigliapoco L EMAIL: ISTRUZIONI PER L USO Strumenti, metodi e criticità per creare, gestire e conservare la posta elettronica s.pigliapoco@unimc.it Posta Elettronica (PE) [DPCM 31/10/2000]:

Dettagli

Firma Digitale, Posta Elettronica Certificata, Conservazione Sostitutiva: gli strumenti per la dematerializzazione

Firma Digitale, Posta Elettronica Certificata, Conservazione Sostitutiva: gli strumenti per la dematerializzazione 1 Firma Digitale, Posta Elettronica Certificata, Conservazione Sostitutiva: gli strumenti per la dematerializzazione Pisa, 25 ottobre 2010 2 Visione d insieme FIRMA DIGITALE POSTA ELETTRONICA CERTIFICATA

Dettagli

Domande frequenti sulla Posta Elettronica Certificata

Domande frequenti sulla Posta Elettronica Certificata Domande frequenti sulla Posta Elettronica Certificata 1. Cosa è la Posta Elettronica Certificata? La Posta Elettronica Certificata (denominata anche Posta Certificata o PEC) è una tipologia di posta elettronica,

Dettagli

Documento di presentazione. Posta Elettronica Certificata Firma digitale

Documento di presentazione. Posta Elettronica Certificata Firma digitale Posta Elettronica Certificata Firma digitale LUGLIO 2007 INDICE Introduzione... 3 1 La Posta Elettronica Certificata... 4 1.1 Funzionalità...4 1.2 Benefici...5 1.3 Quando usare la PEC...6 1.4 Requisiti

Dettagli

La Firma Digitale e la Posta Elettronica Certificata. Centro Tecnico RUPAR Puglia - Tecnopolis Csata Chiara Valerio Bari, 14 dicembre 2006

La Firma Digitale e la Posta Elettronica Certificata. Centro Tecnico RUPAR Puglia - Tecnopolis Csata Chiara Valerio Bari, 14 dicembre 2006 La Firma Digitale e la Posta Elettronica Certificata Centro Tecnico RUPAR Puglia - Tecnopolis Csata Chiara Valerio Bari, 14 dicembre 2006 INNOVAZIONE DELLA P.A. Quadro normativo Il Codice dell Amministrazione

Dettagli

LA FATTURAZIONE ELETTRONICA P.A.

LA FATTURAZIONE ELETTRONICA P.A. LA FATTURAZIONE ELETTRONICA P.A. CONVEGNO O.D.C.E.C. BARI Bari 6 giugno 2014 Relatore Dr. Vito SARACINO ARGOMENTI DA TRATTARE RIFERIMENTI NORMATIVI; DEFINIZIONE DELLA FATTURAZIONE ELETTRONICA; LA FATTURAZIONE

Dettagli

Firma Digitale per il il Consiglio Nazionale degli Ingegneri. Roma 15 ottobre 2009

Firma Digitale per il il Consiglio Nazionale degli Ingegneri. Roma 15 ottobre 2009 Firma Digitale per il il Consiglio Nazionale degli Ingegneri Roma 15 ottobre 2009 :: Firma Digitale :: La Firma Digitale è il risultato di una procedura informatica che garantisce l autenticità e l integrità

Dettagli

OpenPEC: La soluzione open source per la Posta Elettronica Certificata

OpenPEC: La soluzione open source per la Posta Elettronica Certificata OpenPEC: La soluzione open source per la Posta Elettronica Descrizione della soluzione Autore EXEntrica srl Versione 1.0 Data 25. Sep. 2006 Pagina 1 di 10 Indice Glossario... 3 La posta elettronica certificata

Dettagli

Il glossario della Posta Elettronica Certificata (PEC) Diamo una definizione ai termini tecnici relativi al mondo della PEC.

Il glossario della Posta Elettronica Certificata (PEC) Diamo una definizione ai termini tecnici relativi al mondo della PEC. Il glossario della Posta Elettronica Certificata (PEC) Diamo una definizione ai termini tecnici relativi al mondo della PEC. Avviso di mancata consegna L avviso, emesso dal sistema, per indicare l anomalia

Dettagli

DigitPA. VISTI gli articoli 16 e 16 bis del decreto Legge 29 novembre 2008, n. 185 convertito con modificazioni dalla Legge 28 gennaio 2009 n.

DigitPA. VISTI gli articoli 16 e 16 bis del decreto Legge 29 novembre 2008, n. 185 convertito con modificazioni dalla Legge 28 gennaio 2009 n. DigitPA VISTO l art. 6, comma 1 bis, del decreto legislativo 7 marzo 2005 n. 82 (indicato in seguito con l acronimo CAD), come modificato dal decreto legislativo 30 dicembre 2010 n. 235; VISTI gli articoli

Dettagli

Regolamento recante disposizioni per l'utilizzo della posta elettronica certificata, a norma dell'articolo 27 della legge 16 gennaio 2003, n. 3.

Regolamento recante disposizioni per l'utilizzo della posta elettronica certificata, a norma dell'articolo 27 della legge 16 gennaio 2003, n. 3. DPR 11 febbraio 2005, n. 68 1, 2 e 3 Regolamento recante disposizioni per l'utilizzo della posta elettronica certificata, a norma dell'articolo 27 della legge 16 gennaio 2003, n. 3. Art. 1 - Oggetto e

Dettagli

Seminario Formativo. La Posta Elettronica Certificata (PEC)

Seminario Formativo. La Posta Elettronica Certificata (PEC) Comune di Viterbo Prefettura di Viterbo Provincia di Viterbo Coordinamento territoriale per l Amministrazione Digitale della provincia di Viterbo Seminario Formativo La Posta Elettronica Certificata: aspetti

Dettagli

SCHEMA DI DECRETO DEL PRESIDENTE DELLA REPUBBLICA RECANTE REGOLAMENTO CONCERNENTE DISPOSIZIONI PER L UTILIZZO DELLA POSTA ELETTRONICA CERTIFICATA.

SCHEMA DI DECRETO DEL PRESIDENTE DELLA REPUBBLICA RECANTE REGOLAMENTO CONCERNENTE DISPOSIZIONI PER L UTILIZZO DELLA POSTA ELETTRONICA CERTIFICATA. SCHEMA DI DECRETO DEL PRESIDENTE DELLA REPUBBLICA RECANTE REGOLAMENTO CONCERNENTE DISPOSIZIONI PER L UTILIZZO DELLA POSTA ELETTRONICA CERTIFICATA. IL PRESIDENTE DELLA REPUBBLICA Visto l articolo 87, quinto

Dettagli

Determina Ufficio Segreteria n 1 del 13.02.2015

Determina Ufficio Segreteria n 1 del 13.02.2015 Determina Ufficio Segreteria n 1 del 13.02.2015 Adozione del Piano di informatizzazione delle procedure per la presentazione di istanze, dichiarazioni e segnalazioni on line. IL SEGRETARIO COMUNALE Visto

Dettagli

La PEC e interoperabilità di protocollo

La PEC e interoperabilità di protocollo La PEC e interoperabilità di protocollo Contenuti (1) La Pec La PEC nella normativa Gli attori coinvolti Utenti Gestori La rete di comunicazione Il documento informatico Il punto di vista dell utente Il

Dettagli

La posta elettronica certificata e la conservazione elettronica dei documenti

La posta elettronica certificata e la conservazione elettronica dei documenti La posta elettronica certificata e la conservazione elettronica dei documenti Francesco Maria Schinaia Milano, 9 febbraio 2005 www.infocamere.it Argomenti La Posta Elettronica Certificata La Conservazione

Dettagli

OpenPEC: La soluzione open source per la Posta Elettronica

OpenPEC: La soluzione open source per la Posta Elettronica OpenPEC: La soluzione open source per la Posta Elettronica Descrizione della soluzione Autore EXEntrica srl Versione 1.3 Data 27. Jun. 2007 Pagina 1 di 11 Glossario Open Source MTA LDAP SMTP SMTP/S POP

Dettagli

Il Nuovo Codice dell Amministrazione Digitale: opportunità per i cittadini, adempimenti per le amministrazioni Napoli, 28 aprile 2011

Il Nuovo Codice dell Amministrazione Digitale: opportunità per i cittadini, adempimenti per le amministrazioni Napoli, 28 aprile 2011 Il Nuovo Codice dell Amministrazione Digitale: opportunità per i cittadini, adempimenti per le amministrazioni Napoli, 28 aprile 2011 IL DOCUMENTO INFORMATICO E LA SUA GESTIONE Enrica Massella Ducci Teri

Dettagli

Ministero dell Ambiente e della Tutela del Territorio e del Mare

Ministero dell Ambiente e della Tutela del Territorio e del Mare Prot. n. 02/ALBO/CN 11 SETTEMBRE 2013 Ministero dell Ambiente e della Tutela del Territorio e del Mare ALBO NAZIONALE GESTORI AMBIENTALI Deliberazione 11 settembre 2013 Regolamento per la gestione telematica

Dettagli

I Modulo: Generale 11 12 13 giugno 2013 orario: 9.00 13.00 e 14.00 17.30

I Modulo: Generale 11 12 13 giugno 2013 orario: 9.00 13.00 e 14.00 17.30 I Modulo: Generale 11 12 13 giugno 2013 orario: 9.00 13.00 e 14.00 17.30 Martedì, 11 giugno Avv. Luigi Foglia Ing. Andrea Caccia Il documento informatico e la sua conservazione Il Documento informatico:

Dettagli

DOCUMENTI INFORMATICI CONSERVAZIONE e RIPRODUZIONE ai FINI degli OBBLIGHI FISCALI

DOCUMENTI INFORMATICI CONSERVAZIONE e RIPRODUZIONE ai FINI degli OBBLIGHI FISCALI Circolare informativa per la clientela Settembre Nr. 2 DOCUMENTI INFORMATICI CONSERVAZIONE e RIPRODUZIONE ai FINI degli OBBLIGHI FISCALI In questa Circolare 1. Codice dell amministrazione digitale 2. Modifiche

Dettagli

I NUOVI FORMATI DELLA FIRMA DIGITALE

I NUOVI FORMATI DELLA FIRMA DIGITALE I NUOVI FORMATI DELLA FIRMA DIGITALE Giovanni Manca Ufficio Standard e tecnologie d identificazione AGENDA Il quadro normativo di riferimento. I principi base dell interoperabilità. La verifica del documento

Dettagli

La firma digitale Del PTB

La firma digitale Del PTB La firma digitale Del PTB :: Firma Digitale :: La Firma Digitale è il risultato di una procedura informatica che garantisce l autenticità e l integrità di messaggi e documenti scambiati e archiviati con

Dettagli

Modello dell Infrastruttura per il Fascicolo Sanitario Elettronico (InfFSE) Progetto: Infrastruttura tecnologica del Fascicolo Sanitario Elettronico

Modello dell Infrastruttura per il Fascicolo Sanitario Elettronico (InfFSE) Progetto: Infrastruttura tecnologica del Fascicolo Sanitario Elettronico Dipartimento per la digitalizzazione della PA e l innovazione Consiglio Nazionale delle Ricerche Dipartimento delle Tecnologie dell Informazione e delle Comunicazioni Modello dell Infrastruttura per il

Dettagli

Presidenza del Consiglio dei Ministri

Presidenza del Consiglio dei Ministri Presidenza del Consiglio dei Ministri DIPARTIMENTO PER LA DIGITALIZZAZIONE DELLA PUBBLICA AMMINISTRAZIONE E L INNOVAZIONE TECNOLOGICA Alle amministrazioni pubbliche di cui all art. 1, comma 2, del d.lgs.

Dettagli

Scheda prodotto LegalmailPA

Scheda prodotto LegalmailPA Scheda prodotto LegalmailPA Settembre 2006 1 di 6 LegalmailPA La Posta Elettronica Certificata per le Pubbliche Amministrazioni Che cosa è la Posta Elettronica Certificata Il DPR 11 febbraio 2005, n.68

Dettagli

IfinConsulting News - FOCUS FATTURA ELETTRONICA

IfinConsulting News - FOCUS FATTURA ELETTRONICA GIUGNO 2014 IfinConsulting News - FOCUS FATTURA ELETTRONICA Stop alle fatture su carta! A decorrere dal 6 giugno scatta l obbligo per i fornitori della PA Centrale di fatturare con modalità elettroniche.

Dettagli

TELEMEDICINA. SALUTE IN RETE O BUONI PROPOSITI

TELEMEDICINA. SALUTE IN RETE O BUONI PROPOSITI TELEMEDICINA. SALUTE IN RETE O BUONI PROPOSITI MILANO, 2 MARZO 2015 DOTT. LUCIANO FLOR DIRETTORE GENERALE AZIENDA SANITARIA TRENTO Provincia Autonoma di Trento Superficie Kmq 6.200 eurochirurgia e troke

Dettagli

Esperienze di utilizzo dello standard HL7 Regione Emilia Romagna

Esperienze di utilizzo dello standard HL7 Regione Emilia Romagna Esperienze di utilizzo dello standard HL7 Regione Emilia Romagna Il Progetto SOLE - Sanità On LinE e gli standard Stefano Micocci e Marco Devanna CUP 2000 15 settembre 2010 SOLE-100206 Di cosa parleremo

Dettagli

Sanità digitale !62 STRATEGIA PER LA CRESCITA DIGITALE 2014-2020

Sanità digitale !62 STRATEGIA PER LA CRESCITA DIGITALE 2014-2020 Sanità digitale Cosa e perchè L innovazione digitale dei processi sanitari è un passaggio fondamentale per migliorare il rapporto costo-qualità dei servizi sanitari, limitare sprechi e inefficienze, ridurre

Dettagli

Carta Sanitaria Elettronica IL FASCICOLO SANITARIO ELETTRONICO IN REGIONE TOSCANA

Carta Sanitaria Elettronica IL FASCICOLO SANITARIO ELETTRONICO IN REGIONE TOSCANA Carta Sanitaria Elettronica IL FASCICOLO SANITARIO ELETTRONICO IN REGIONE TOSCANA 1 INDICE ARCHITETTURA CONTENUTI ORGANIZZAZIONE SOGGETTI COINVOLTI RIFERIMENTI NORMATIVI RIFERIMENTI TECNOLOGICI 2 ARCHITETTURA

Dettagli

Appl. di emissione PKCS#11. API (Metacomandi) Resource Manager Windows. Drivers PC/SC dei lettori

Appl. di emissione PKCS#11. API (Metacomandi) Resource Manager Windows. Drivers PC/SC dei lettori Roma, 30 gennaio 2003 La realtà della carta di identità elettronica (nel seguito CIE) e della carta nazionale dei servizi (nel seguito CNS) rende ineluttabile l individuazione di servizi da erogare in

Dettagli

DIRETTIVE CONCERNENTI L UTILIZZO DELLA POSTA ELETTRONICA E DELLA POSTA ELETTRONICA CERTIFICATA DA PARTE DELL AMMINISTRAZIONE PROVINCIALE.

DIRETTIVE CONCERNENTI L UTILIZZO DELLA POSTA ELETTRONICA E DELLA POSTA ELETTRONICA CERTIFICATA DA PARTE DELL AMMINISTRAZIONE PROVINCIALE. Allegato A) DIRETTIVE CONCERNENTI L UTILIZZO DELLA POSTA ELETTRONICA E DELLA POSTA ELETTRONICA CERTIFICATA DA PARTE DELL AMMINISTRAZIONE PROVINCIALE. 1. LA POSTA ELETTRONICA TRADIZIONALE E LA POSTA ELETTRONICA

Dettagli

La Fatturazione Elettronica verso la PA

La Fatturazione Elettronica verso la PA N.B.: i collegamenti agli indirizzi web riportati nel testo e alla Presentazione Fatturazione Elettronica Armando Giudici Dylog - Buffetti sono richiamabili cliccandoli col pulsante sinistro del mouse.

Dettagli

SISTEMI E APPLICAZIONI PER L AMMINISTRAZIONE DIGITALE

SISTEMI E APPLICAZIONI PER L AMMINISTRAZIONE DIGITALE Università degli Studi di Macerata Dipartimento di Giurisprudenza Scienze dell amministrazione pubblica e privata (Classe LM-63) SISTEMI E APPLICAZIONI PER L AMMINISTRAZIONE DIGITALE LA POSTA ELETTRONICA

Dettagli

POSTA ELETTRONICA CERTIFICATA

POSTA ELETTRONICA CERTIFICATA POSTA ELETTRONICA CERTIFICATA Questo vademecum ha lo scopo di riassumere i concetti relativi alla PEC. Per approfondimenti e verifiche, si rimanda alla legislazione vigente. 1 COS E ED A COSA SERVE PEC

Dettagli

PEC. La posta elettronica certificata

PEC. La posta elettronica certificata Servizi Applicativi su Internet PEC La posta elettronica certificata Parzialmente tratte da Regole tecniche del servizio di trasmissione di documentiinformatici mediante posta elettronica certificata Normativa

Dettagli

Il Fascicolo Sanitario Elettronico della Regione Autonoma della Sardegna: stato dell arte ed evoluzione

Il Fascicolo Sanitario Elettronico della Regione Autonoma della Sardegna: stato dell arte ed evoluzione Verso la cartella clinica elettronica: standard internazionali e piattaforme aperte in informatica sanitaria Il Fascicolo Sanitario Elettronico della Regione Autonoma della Sardegna: stato dell arte ed

Dettagli

Allegato Tecnico al Contratto di Servizio

Allegato Tecnico al Contratto di Servizio FatturaPA Fatturazione elettronica verso la Pubblica Amministrazione Allegato Tecnico al Contratto di Servizio Allegato Tecnico al Contratto di Servizio fattura PA Versione gennaio 20145 Pagina 1 di 7

Dettagli

Nulla si crea Nulla si distrugge Ma tutto si conserva

Nulla si crea Nulla si distrugge Ma tutto si conserva Nulla si crea Nulla si distrugge Ma tutto si conserva Dockeeper è la suite di conservazione sostitutiva che gestisce l intero processo di generazione, emissione ed archiviazione dei documenti, dalla semplice

Dettagli

Direttive concernenti le comunicazioni con le pubbliche amministrazioni e lo scambio di documenti per via telematica.

Direttive concernenti le comunicazioni con le pubbliche amministrazioni e lo scambio di documenti per via telematica. ALLEGATO A) Direttive concernenti le comunicazioni con le pubbliche amministrazioni e lo scambio di documenti per via telematica. 1. Premessa Le presenti direttive disciplinano le comunicazioni telematiche

Dettagli

Il CAD e il Dlgs. 33. Brescia I.I.S. Tartaglia Olivieri 21 gennaio 2014

Il CAD e il Dlgs. 33. Brescia I.I.S. Tartaglia Olivieri 21 gennaio 2014 Il CAD e il Dlgs. 33 gli obblighi delle scuole: trasparenza, dematerializzazione, archiviazione sostitutiva Brescia I.I.S. Tartaglia Olivieri 21 gennaio 2014 Il CAD e le Istituzioni scolastiche: dal documento

Dettagli

ALLEGATO AL CONTRATTO DI FORNITURA DEL SERVIZIO LEGALMAIL

ALLEGATO AL CONTRATTO DI FORNITURA DEL SERVIZIO LEGALMAIL ALLEGATO AL CONTRATTO DI FORNITURA DEL SERVIZIO LEGALMAIL.1. Introduzione Legalmail è il servizio di posta elettronica con valore legale realizzato da InfoCamere. Esso consente al Cliente di disporre di

Dettagli

COMUNE DI CARPEGNA. Montefeltro Provincia di Pesaro e Urbino. Piano di informatizzazione ai sensi del D.L. 90/2014, art. 24 c.

COMUNE DI CARPEGNA. Montefeltro Provincia di Pesaro e Urbino. Piano di informatizzazione ai sensi del D.L. 90/2014, art. 24 c. COMUNE DI CARPEGNA Montefeltro Provincia di Pesaro e Urbino Piano di informatizzazione ai sensi del D.L. 90/2014, art. 24 c. 3bis Approvato con delibera di Giunta Comunale n. 13 del 16/02/2015 Pag. 2 2.

Dettagli

Guida alla FATTURAZIONE ELETTRONICA

Guida alla FATTURAZIONE ELETTRONICA Guida alla FATTURAZIONE ELETTRONICA 1) Normativa Le disposizioni della Legge finanziaria 2008 prevedono che l emissione, la trasmissione, la conservazione e l archiviazione delle fatture emesse nei rapporti

Dettagli

Progetto SIRPE De-materializzazione delle prescrizioni nella Regione Piemonte. Farmacie. Versione 1.0

Progetto SIRPE De-materializzazione delle prescrizioni nella Regione Piemonte. Farmacie. Versione 1.0 Pag. 1 di 13 Progetto SIRPE De-materializzazione nella Regione Piemonte Farmacie Versione 1.0 INDICE Pag. 2 di 13 1 Introduzione 3 1.1 Scopo del documento 3 1.2 Riferimenti 3 2 Inquadramento e obiettivo

Dettagli

M. Ciampi. Consiglio Nazionale delle Ricerche Dipartimento delle Tecnologie dell Informazione e delle Comunicazioni

M. Ciampi. Consiglio Nazionale delle Ricerche Dipartimento delle Tecnologie dell Informazione e delle Comunicazioni Presidenza del Consiglio dei Ministri Dipartimento per la digitalizzazione della PA e l innovazione tecnologica Consiglio Nazionale delle Ricerche Dipartimento delle Tecnologie dell Informazione e delle

Dettagli

REGOLAMENTO PER LA PRESENTAZIONE DI ISTANZE E DICHIARAZIONI PER VIA TELEMATICA

REGOLAMENTO PER LA PRESENTAZIONE DI ISTANZE E DICHIARAZIONI PER VIA TELEMATICA COMMUNE DE GRESSAN REGOLAMENTO PER LA PRESENTAZIONE DI ISTANZE E DICHIARAZIONI PER VIA TELEMATICA Approvazione deliberazione del Consiglio comunale n. 10 del 13/01/2012 del Consiglio comunale n. del Art.

Dettagli

DECRETO DEL PRESIDENTE DEL CONSIGLIO DEI MINISTRI 8 agosto 2013

DECRETO DEL PRESIDENTE DEL CONSIGLIO DEI MINISTRI 8 agosto 2013 DECRETO DEL PRESIDENTE DEL CONSIGLIO DEI MINISTRI 8 agosto 2013 Modalita' di consegna, da parte delle Aziende sanitarie, dei referti medici tramite web, posta elettronica certificata e altre modalita'

Dettagli

Posta Elettronica Certificata per l Ordine dei Medici Veterinari della Provincia di Verona. Verona 11 marzo 2010

Posta Elettronica Certificata per l Ordine dei Medici Veterinari della Provincia di Verona. Verona 11 marzo 2010 Posta Elettronica Certificata per l Ordine dei Medici Veterinari della Provincia di Verona Verona 11 marzo 2010 :: Indice della presentazione :: La Posta Elettronica Certificata: normativa e caratteristiche

Dettagli

Certificatore Accreditato Postecom S.p.A. Servizio Postecert Firma Digitale

Certificatore Accreditato Postecom S.p.A. Servizio Postecert Firma Digitale Certificatore Accreditato Servizio Postecert Firma Digitale Guida alla comprensione degli OID presenti nei certificati rilasciati da ver.: 3.1 del:26/04/2013 Guida Comprensione OID Documento pubblico Pagina

Dettagli

Ministero dell Economia e delle Finanze

Ministero dell Economia e delle Finanze Prot. 8962/2015/DF/DGT Ministero dell Economia e delle Finanze DIPARTIMENTO DELLE FINANZE IL DIRETTORE GENERALE DELLE FINANZE VISTO il decreto del Ministro dell Economia e delle Finanze in data 23 dicembre

Dettagli

Il documento informatico: sottoscrizione e conservazione

Il documento informatico: sottoscrizione e conservazione Il documento informatico: sottoscrizione e conservazione Prof. Avv. Giusella Finocchiaro Studio legale Finocchiaro www. studiolegalefinocchiaro.it 1 Il quadro normativo Percorso lungo e complesso: normativa

Dettagli

Dematerializzazione dei documenti amministrativi, utilizzo della PEC e delle firme digitali nell'informatizzazione e automazione dei procedimenti

Dematerializzazione dei documenti amministrativi, utilizzo della PEC e delle firme digitali nell'informatizzazione e automazione dei procedimenti Dematerializzazione dei documenti amministrativi, utilizzo della PEC e delle firme digitali nell'informatizzazione e automazione dei procedimenti Il ciclo di vita del documento informatico e le comunicazioni

Dettagli

La Posta Elettronica Certificata (P.E.C.)

La Posta Elettronica Certificata (P.E.C.) La Posta Elettronica Certificata () Definizione La Posta Elettronica Certificata è un sistema di posta elettronica con la quale si fornisce al mittente documentazione elettronica, con valore legale, attestante

Dettagli

La Fatturazione Elettronica verso la PA

La Fatturazione Elettronica verso la PA La Fatturazione Elettronica verso la PA Il 6 giugno 2014 sarà una data importante in quanto entra in vigore il D.M. 55/2013 che ha stabilito le modalità attuative per fatturazione elettronica nei confronti

Dettagli

Pina Civitella pina.civitella@comune.bologna.it

Pina Civitella pina.civitella@comune.bologna.it Pina Civitella pina.civitella@comune.bologna.it La timeline del quadro normativo (1) 1998 2000 2004 2005 Protocollo informatico Regole tecniche per il protocollo informatico di cui al decreto del Presidente

Dettagli

Posta Elettronica Certificata obbligo e opportunità per le Imprese e la PA

Posta Elettronica Certificata obbligo e opportunità per le Imprese e la PA Posta Elettronica Certificata obbligo e opportunità per le Imprese e la PA Belluno 28 gennaio 2014 www.feinar.it PEC: Posta Elettronica Certificata Che cos'è e come funziona la PEC 3 PEC: Posta Elettronica

Dettagli

In vigore anche per i professionisti l obbligo di emissione di sole fatture elettroniche per servizi resi verso le pubbliche amministrazioni

In vigore anche per i professionisti l obbligo di emissione di sole fatture elettroniche per servizi resi verso le pubbliche amministrazioni In vigore anche per i professionisti l obbligo di emissione di sole fatture elettroniche per servizi resi verso le pubbliche amministrazioni La Legge Finanziaria 2008 (Legge 244/2007, articolo 1, commi

Dettagli

che, diversamente dalla raccomandata, nella ricevuta di avvenuta consegna sono presenti anche i contenuti del messaggio originale.

che, diversamente dalla raccomandata, nella ricevuta di avvenuta consegna sono presenti anche i contenuti del messaggio originale. Di seguito sono riportate le risposte relative a quesiti pervenuti circa i seguenti aspetti del servizio: caratteristiche generali; funzionamento; attivazione; gestori; Indice PA. 1. Introduzione Che cos'è?

Dettagli

Posta Elettronica Certificata: introduzione

Posta Elettronica Certificata: introduzione Posta Elettronica Certificata: introduzione Umberto Ferrara [ferrara@exentrica.it] Seminario PEC e cooperazione applicativa TossLab Dip Informatica, Università di Pisa 2 aprile 2009 ::www.exentrica.it

Dettagli

PRODUZIONE E CONSERVAZIONE DEL REGISTRO GIORNALIERO DI PROTOCOLLO

PRODUZIONE E CONSERVAZIONE DEL REGISTRO GIORNALIERO DI PROTOCOLLO PRODUZIONE E CONSERVAZIONE DEL REGISTRO GIORNALIERO DI PROTOCOLLO Sommario 1. Introduzione e breve inquadramento normativo... 2 2. Contenuti del registro giornaliero di protocollo... 4 3. Formazione del

Dettagli

SISTEMI RIS/PACS: AGGIORNAMENTI SUL TEMA

SISTEMI RIS/PACS: AGGIORNAMENTI SUL TEMA SISTEMI RIS/PACS: AGGIORNAMENTI SUL TEMA Firma digitale e conservazione sostitutiva Gabriele Faggioli MIP Politecnico Milano Milano, 18 gennaio 2007 Aspetti introduttivi L evoluzione e la diffusione delle

Dettagli