Servizio Sistemi Informativi Standard Tecnologici Redatto: Nucleo Gestione Innovazione e fornitori IT Versione: 02.00.00 Data emissione: 13/02/2014 Cronologia del documento (a partire dal 2014) Versione Data Autore 02.00.00 13/02/14 Annalisa Tomasi Commento/Sintesi aggiornamenti principali Introduzione del capitolo relativo all'eprescription e del capitolo relativo al FSE. 1 Indice 1.Sommario.........................................................................................................................................4 1 Deroghe............................................................................................................................................5 2 Sistemi Server...................................................................................................................................6 2.1 Hardware...................................................................................................................................6 2.2 Software....................................................................................................................................7 2.2.1 Software di base................................................................................................................7 2.2.2 Posta Elettronica...............................................................................................................7 2.2.3 Application Server.............................................................................................................7 2.2.4 Sistemi di autenticazione: Single Sign-On........................................................................8 3 Servizi...............................................................................................................................................9 3.1 RDBMS....................................................................................................................................9 3.1.1 Situazione attuale..............................................................................................................9 3.1.2 Configurazione..................................................................................................................9 3.2 Piattaforma di Content Management System (CMS).............................................................10 4 Standard..........................................................................................................................................11 4.1 Standard internazionali...........................................................................................................11 4.1.1 Standard di sicurezza.......................................................................................................11 4.1.2 Meccanismi di sicurezza standardizzati da ISO/IEC/JTC1/SC27..................................12 4.2 Standard nazionali...................................................................................................................14 4.2.1 Posta Elettronica Certificata (PEC).................................................................................14 4.2.1.1 La normativa di riferimento....................................................................................15 4.2.1.2 Le regole tecniche...................................................................................................16 4.2.2 Carta Nazionale dei Servizi.............................................................................................17 4.2.2.1 La normativa di riferimento....................................................................................17 4.2.2.2 Le regole tecniche...................................................................................................18 4.2.2.3 La soluzione implementata in APSS.......................................................................19 4.2.3 Firma digitale e conservazione sostitutiva......................................................................19 4.2.3.1 La normativa di riferimento e le regole tecniche....................................................20 4.2.3.2 La soluzione implementata in APSS.......................................................................21 4.2.4 ePrescription – Ricetta medica elettronica......................................................................22 4.2.5 FSE, Fascicolo Sanitario Elettronico..............................................................................24 4.2.6 La normativa di riferimento............................................................................................24 4.2.6.1 La soluzione implementata in APSS.......................................................................25 1.Ampere........................................................................................................................25 2.TREC...........................................................................................................................25 4.2.6.2 Attività di adeguamento alla nuova normativa........................................................26 4.3 Standard internazionali di Informatica medica.......................................................................27 4.3.1 TC251..............................................................................................................................27 4.3.2 HL7.................................................................................................................................27 4.3.3 DICOM...........................................................................................................................27 4.3.4 IHE..................................................................................................................................28 4.3.5 UNI..................................................................................................................................29 4.3.5.1 CORBAMED..........................................................................................................29 4.3.5.2 GEHR......................................................................................................................29 4.3.5.3 Codifiche.................................................................................................................29 4.3.5.4 Altri standard per l’identificazione del paziente......................................................29 4.3.5.5 Altri standard per la comunicazione........................................................................29 2 4.3.5.6 Standard per la definizione di indicatori di qualità e linee guida............................29 4.4 Partecipazione al progetto IPSE da parte di APSS................................................................30 5 Realizzazione ed acquisizione di applicazioni...............................................................................31 5.1 Metodologia per lo studio e la realizzazione del software......................................................31 5.1.1 Requisiti non-funzionali..................................................................................................31 5.1.1.1 Interoperabilità .......................................................................................................31 5.1.1.2 Portabilità................................................................................................................31 5.1.1.3 Aderenza a Standard I.T..........................................................................................31 5.1.1.4 Look and feel...........................................................................................................32 5.1.1.5 Manutenibilità.........................................................................................................32 5.1.1.6 Scalabilità e Performance........................................................................................32 5.1.1.7 Affidabilità, Disponibilità e Sicurezza....................................................................32 5.1.2 UP....................................................................................................................................33 5.2 Metodologia per lo studio e la realizzazione del database......................................................34 5.2.1 Progettazione del database..............................................................................................34 5.2.2 UML................................................................................................................................34 5.2.3 Architettura applicativa...................................................................................................35 5.2.4 Architettura del sistema...................................................................................................35 5.2.4.1 Partizionamento dell’applicazione..........................................................................36 5.2.4.2 Presentation Tier......................................................................................................36 5.2.4.3 Middle Tier..............................................................................................................37 5.2.4.4 Enterprise Information System Tier........................................................................38 5.2.4.5 Architetture dei sistemi settoriali e di servizio........................................................38 5.3 Integrazione dati: protocolli per il trasporto dati....................................................................38 5.3.1 Web Services...................................................................................................................38 5.3.2 WSDL.............................................................................................................................38 5.3.3 SOAP..............................................................................................................................38 5.3.4 Registry Service..............................................................................................................39 5.4 Integrazione con altri sistemi..................................................................................................39 6 Erogazione di applicazioni in modalità Application Service Provider (ASP)................................41 1.Browser standard.......................................................................................................................41 1.AJAX....................................................................................................................................42 2.HTML5.................................................................................................................................42 3.Flash......................................................................................................................................43 7 Sicurezza e privacy.........................................................................................................................43 8 Qualità dei beni e dei servizi ICT...................................................................................................45 9 Specifiche Funzionali di Integrazione con il Sistema Informativo dell’APSS..............................46 1.Premessa......................................................................................................................46 2.Anagrafe.....................................................................................................................................46 3.ADT...........................................................................................................................................47 4.Pronto Soccorso.........................................................................................................................47 5.CUP............................................................................................................................................48 6.Clinical Data Repository / Order Management / Minimum Data Set........................................48 7.Sistemi Diagnostici ...................................................................................................................48 8.Radiology Information System, RIS..........................................................................................48 9.Picture archiving and communication system, PACS................................................................48 10.Interoperabilità con LDAP o sistema GRU.............................................................................49 3 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 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 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 2.2 Software 2.2.1 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 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 Windows 2008 Internet Explorer: 6.0/7.0/8.0 Versione S.O. Kernel 2.4 RedHat Ent. 5.5/Mandrake Linux Tabella 1: Software di base in uso Unix-Solaris S.O. Unix Solaris 10.0 /9.0 Windows 2008 Windows 2003 Windows 2000 Linux Kernel 2.4 o successivi Tabella 2: Software di base per nuove installazioni 2.2.2 Posta Elettronica 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. 2.2.3 Application Server L’application server da utilizzare per il deploymet delle applicazioni è JBoss versione 3.2.3 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 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 3 Servizi 3.1 RDBMS 3.1.1 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 3.1.2 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 RDBMS Unix/Solaris Windows Server 2003 Windows Server 2008 Linux ORACLE MS SQL ORACLE, Postgresql, MySQL File Service - Nativo - Print Service - Nativo - MS Proxy/ISA - Proxy Datawarehouse/E TL Antivirus Antispam Backup Middleware HL7 Middelware Mirth Business Object Web Intelligence ETL Business Object Agente locale Symantec Norton Antivirus Symantec Agente locale Symantec McAfee Secure Internet Gateway Symantec Net backup 7.5 Integrated composite application network (JCAPS) Mirth_Connect (Windows Server 2003 R2) Mirth_Connect (Windows Server 9 Servizi Server/SW di base Server Unix/Solaris Windows Server 2003 Windows Server 2008 Linux 2008 R2) Application Server 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 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 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 1003.1-2008). ISO/ IEC 7498-1994: Open Systems Interconnection--Basic Reference Model. ITU X.400. Serie ITU X.500. IEEE 1224.1-1993: OSI X-400 Based Electronic Messaging API. IEEE 1224.2-1993: 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 8859-1: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 10918 Still image data compression standard (JPEG). ISO 11172 Digital video/audio compression and encoding (MPEG). NCSC Trusted Computer System Evaluation Criteria (Orange Book) DOD5200.28-STD-83, CSC-STD-001, 1985. IETF SSL protocol version 3.1 RFC 2246 01/99. IETF RFC 1319-1321 : 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 8802-3:1993). ISDN (ITU-TI Series 100 through 600). ATM(ANSI T1.630, ANSI T1.635, UNI Specification V3.1). ISO/DIS 32000 Document management -- Portable document format -- PDF 1.7 4.1.1 Standard di sicurezza ● ● ● ● ● ISO/IEC IS 17799-1 - Information security management - Part 1: Code of practice for information security management – Standard. BS7799-2 - Information security management systems - Specification with guidance for use. ISO/IEC TR 13335-1, Information technology – Security techniques – Guidelines for the management of IT security (GMITS) – Part 1: Concepts and models of IT security. ISO/IEC TR 13335-2, Information technology – Security techniques – Guidelines for the management of IT security (GMITS) – Part 2: Managing and planning IT security. ISO/IEC TR 13335-3, Information technology – Security techniques – Guidelines for the 11 ● ● ● ● ● ● management of IT security (GMITS) – Part 3: Techniques for the management of IT security. ISO/IEC TR 13335-4, Information technology – Security techniques – Guidelines for the management of IT security (GMITS) – Part 4: Selection of safeguards. ISO/IEC TR 13335-5, Information technology – Security techniques – Guidelines for the management of IT security (GMITS) – Part 5: Management guidance on network security. ISO/IEC IS 15408-1 Evaluation Criteria for Information Technology Security - Part 1: Introduction and general model. ISO/IEC IS 15408-2 Evaluation Criteria for Information Technology Security - Part 2: Security functional requirements. ISO/IEC IS 15408-3 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 45000 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. 4.1.2 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 9796-2: (2002), Digital signature schemes giving message recovery - Part 2: Integer factorization based mechanisms ISO/IEC 9796-3: 1999, Digital signatures schemes giving message recovery - Part 3: Discrete logarithm based mechanisms ISO/IEC 9797-1: 1999, Message authentication codes (MACs) - Part 1: Mechanisms using a block cipher ISO/IEC 9797-2: (2002), Message authentication codes (MACs) - Part 2: Mechanisms using a dedicated hash-function ISO/IEC 9798-1: 1997, Entity authentication - Part 1: General (2nd edition) ISO/IEC 9798-2: 1999, Entity authentication - Part 2: Mechanisms using symmetric encipherment algorithms (2nd edition) ISO/IEC 9798-3: 1998, Entity authentication - Part 3: Mechanisms using digital segnature techniques (2nd edition) ISO/IEC 9798-4: 1999, Entity authentication - Part 4: Mechanisms using a cryptographic check function (2nd edition) ISO/IEC 9798-5: 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 10118-1: 2000, Hash-functions - Part 1: General (2nd edition) ISO/IEC 10118-2: 2000, Hash-functions - Part 2: Hash-functions using an n-bit block cipher algorithm (2nd edition) ISO/IEC 10118-3: 1998, Hash-functions - Part 3: Dedicated hash-functions 12 ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ISO/IEC 10118-4: 1998, Hash-functions - Part 4: Hash-functions using modular arithmetic ISO/IEC 11770-1: 1996, Key management - Part 1: Framework ISO/IEC 11770-2: 1996, Key management - Part 2: Mechanisms using symmetric techniques ISO/IEC 11770-3: 1999, Key management - Part 3: Mechanisms using asymmetric techniques ISO/IEC 13888-1: 1997, Non-repudiation - Part 1: General (in fase di revisione) ISO/IEC 13888-2: 1998, Non-repudiation - Part 2: Using symmetric techniques ISO/IEC 13888-3: 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 14888-1: 1999, Digital signatures with appendix - Part 1: General ISO/IEC 14888-2: 1999, Digital signatures with appendix - Part 2: Identity-based mechanisms ISO/IEC 14888-3: 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 15946-1: (2002), Cryptographic techniques based on elliptic curves - Part 1: General (in attesa di pubblicazione) ISO/IEC 15946-2: (2002), Cryptographic techniques based on elliptic curves - Part 2: Digital signatures (in attesa di pubblicazione) ISO/IEC 15946-3: (2002), Cryptographic techniques based on elliptic curves - Part 3: Key establishment (in attesa di pubblicazione) ISO/IEC FCD 15946-4: 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 18014-1: (2002), Time stamping services - Part 1: Framework (in attesa di pubblicazione); ISO/IEC FDIS 18014-2: 2002, Time stamping services - Part 2: Mechanisms producine independent tokens ISO/IEC CD 18014-3: 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 18033-1: 2002, Encryption algorithms - Part 1: General ISO/IEC WD 18033-2: 2002, Encryption algorithms - Part 2: Asymmetric ciphers ISO/IEC CD 18033-3: 2002, Encryption algorithms - Part 3: Block ciphers ISO/IEC WD 18033-4: 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 4.2 Standard nazionali 4.2.1 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 Schema Funzionale PEC 4.2.1.1 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 e-mail 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 e-mail 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 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. 4.2.1.2 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. 266. 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 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 2005. 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 2004 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. Roma, 18 maggio 2006 Il presidente: Zoffoli 4.2.2 Carta Nazionale dei Servizi 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. 4.2.2.1 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 · 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. 4.2.2.2 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 4.2.2.3 La soluzione implementata in APSS La soluzione di CNS implementata da APSS è quella fornita da Actalis sulla base della contratto quadro sottoscritto da CNIPA1. 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. 4.2.3 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 continuano a valere quelle a suo tempo emanate dal CNIPA 2 (Deliberazione n. 11/20043) 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). 4.2.3.1 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. 57 4 DPR 28 dicembre 2000, n. 445, e successive modifiche. 20 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. 4.2.3.2 La soluzione implementata in APSS La soluzione di firma digitale oggi adottata è descritta al paragrafo ”La soluzione implementata in APSS“, numero 4.2.2.3 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 • 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 11-2004. 4.2.4 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 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 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 SAC 1: Inserimento dati Prescrizione 2: Richiesta stampa 3: Invio dati Prescrizione 4: Verifica correttezza dati 5: Assegnazione NRE 6: Invio Prescrizione 8: Calcolo tipo stampa 7: Ritorno Cod. Autent. 9: Memorizzazione dati 11: Stampa Prescrizione 10: NRE+Cod. Autent.+Tipo stampa 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. 4.2.5 FSE, Fascicolo Sanitario Elettronico 4.2.6 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 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/2012. 4.2.6.1 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 2011-2013”. 2. TREC TREC è il Fascicolo Sanitario Elettronico della Provincia Autonoma di Trento, è in produzione dal giugno 2012 ed oggi conta quasi 25.000 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 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). 4.2.6.2 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. 2. 26 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. 4.3.1 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 12967-1 1998 Healthcare Information Systems Architecture - Part 1: Healthcare Middleware Layer; ● CEN/TC251 ENV 12924 Medical Informatics - Security Categorisation and protection for healthcare Information Systems; ● CEN/TC251 ENV 12018 Medical Informatics - Intermittently Connected Devices; ● CEN/TC251 ENV 1613 1995 Messages for exchange of laboratory information; ● CEN/TC251 ENV 12538 1997 Messages for patient referral and discharge; ● CEN/TC251 ENV 12539 1997 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. 4.3.2 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. 4.3.3 DICOM La necessità di scambiare immagini mediche con le relative informazioni (annotazioni, referti del medico, ecc.) tra i diversi soggetti di un ospedale, o tra ospedali diversi, attraverso le reti 27 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 ACRNEMA: Digital Imaging and Communications in Medicine (DICOM) v.3. 4.3.4 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 · · · Time client Automation manager Order result tracker 4.3.5 UNI Le norme UNI sulla integrazione di sistemi software per la sanità. 4.3.5.1 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. 4.3.5.2 GEHR Il progetto GEHR (Good Electronic Healthcare Record) per la definizione dei dati sanitari in ambienti object-oriented. 4.3.5.3 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). 4.3.5.4 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. 4.3.5.5 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. 4.3.5.6 Standard per la definizione di indicatori di qualità e linee guida ● Indicator Measurement System (IMSystem) della Joint Commission on Accreditation of 29 ● 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: • 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. 2. 30 5 Realizzazione ed acquisizione di applicazioni 5.1 Metodologia per lo studio e la realizzazione del software 5.1.1 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. 5.1.1.1 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. 5.1.1.2 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. 5.1.1.3 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 ● ● 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. 5.1.1.4 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. 5.1.1.5 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. 5.1.1.6 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. 5.1.1.7 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 ed i sistemi di rete, con gli opportuni sistemi di management che consentano la gestione proattiva dei problemi [LIR1997]. 5.1.2 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 ● ● 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. 5.2.1 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. 5.2.2 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 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. 5.2.3 Architettura applicativa Le applicazioni devono prevedere una architettura scomposta su tre livelli secondo gli standard CEN ENV 12967-1 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 12967-1 e UNI 10533 5.2.4 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 5.2.4.1 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. 5.2.4.2 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 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/ ). 5.2.4.3 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 ● 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. 5.2.4.4 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. 5.2.4.5 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. 5.3.1 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. 5.3.2 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. 5.3.3 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 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. 5.3.4 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 6 Erogazione di applicazioni in modalità Application Service Provider (ASP) Il modello architetturale prevede che la tecnologia di elaborazione (hardware) e quella applicativa (software) vengono gestite centralmente presso un Service Provider lasciando all'utente finale la scelta dei tempi e dei modi di fruizione del servizio. Tipicamente, lo strumento software lato cliente che funge da interfaccia con il servizio applicativo è il web browser. 3. Browser standard HTML • L'ultima specifica HTML pubblicata da W3C è HTML 4.01 del 1999. Esiste un aggiornamento pubblicato nel 2001. La versione HTML 5 è stata pubblicata come Working Draft da W3C e non è ancora supportata da tutti i browser. • CSS I fogli di stile a cascata, meglio noti con l'acronimo CSS (dall'inglese Cascading Style Sheet) e detti anche semplicemente fogli di stile, vengono usati per definire la rappresentazione di documenti HTML, XHTML e XML. Le regole per comporre i fogli di stile sono contenute in un insieme di direttive (Recommendations) emanate a partire dal 1996 dal W3C. L'introduzione dei fogli di stile si è resa necessaria per separare i contenuti dalla formattazione e permettere una programmazione più chiara e facile da utilizzare, sia per gli autori delle pagine HTML che per gli utenti. • ECMAScript JavaScript è un linguaggio di scripting orientato agli oggetti comunemente usato nei siti web. JavaScript è stato standardizzato per la prima volta tra il 1997 e il 1999 dalla ECMA con il nome ECMAScript. L'ultimo standard, del dicembre 1999, è ECMA-262 Edition 3, e corrisponde a JavaScript 1.5. Javascript ha diversi generi di oggetti predefiniti, in particolare Array (vettori), Boolean (booleani), Date (oggetti contenenti una data e un'ora), Function (funzioni), Math (oggetto contente funzioni di uso nel calcolo matematico), Number (numeri), Object (oggetti), RegExp (espressioni regolari) e String (stringhe). Altri oggetti sono gli "oggetti ospiti", definiti non dal linguaggio ma dall'ambiente di esecuzione. In un browser, i tipici oggetti ospite appartengono al DOM: window (finestra) , form (maschera), link (collegamento) etc. 41 figura: struttura del Document Object Model In particolare per una applicazione web, si faccia riferimento alla tecnologia AJAX. 1. AJAX Il termine AJAX (Asynchronous JavaScript and XML) è venuto a rappresentare un ampio gruppo di tecnologie web che possono essere utilizzate per implementare una applicazione web che comunica con un server in background, senza interferire con l'attuale stato della pagina. Di seguito sono elencati gli elementi distintivi di una applicazione AJAX: • Il Document Object Model di javascript per la visualizzazione dinamica e l'interazione con i dati • XML per lo scambio di dati e XSLT per la sua manipolazione • L'oggetto di javascript XMLHttpRequest per gestire la comunicazione asincrona • JavaScript per portare queste tecnologie insieme. Per applicazioni critiche, è necessaria la continuità di erogazione di servizio in caso di off-line. Questo può essere realizzato ad esempio con l'utilizzo di tecnologie tipo Google Gears. Google ha recentemente dichiarato che non svilupperà ulteriormente questa tecnologia perchè intende implementare HTML5, che fornirà ad esempio la funzionalità di web storage (vedi di seguito) all'interno di uno standard. 2. HTML5 Di seguito vengono elencate le caratteristiche principali: • Markup - HTML5 introduce una serie di nuovi elementi e attributi che rispecchiano l'uso tipico su siti web moderni. Le principali introduzioni sono gli elementi <audio> e <video> • Nuove API - HTML5 specifica un insieme di nuove Application programming interfaces (APIs) disponibile alla programmazione della pagina web per mezzo di javascript. • La funzione canvas for per disegno 2D • Timed media playback – per la gestione ed esecuzione di contenuti multimediali • Offline storage database (web storage) • Document editing • Drag-and-drop • Cross-document messaging. - questa API permette ai documenti DOM di comunicare tra di loro, indipendentemente dal loro dominio di origine, in un modo progettato per non consentire attacchi cross-site scripting. • Gestione della Browser history • registrazione MIME type and protocol handler – consente la gestione dei diversi tipi MIME all'interno delle pagine html • Microdata – possibilità di inserire nella pagina html delle coppie nome-valore 42 3. Flash Adobe Flash (in precedenza Macromedia Flash) è un software per uso prevalentemente grafico che consente di creare animazioni vettoriali principalmente per il web. Viene utilizzato inoltre per creare giochi o interi siti web e grazie all'evoluzione delle ultime versioni è divenuto un potente strumento per la creazione di Rich Internet Application e piattaforme di streaming audio/video. I nuovi standard aperti come HTML5 creati nel periodo attuale, in cui sono sempre più diffusi i dispositivi mobili, sono probabilmente destinati a rendere legacy questa tecnologia, che quindi riteniamo meno preferibile rispetto a quelle precedentemente citate. Si configura comunque come un plug-in del browser, un nuovo componente che può creare problemi di performance e sicurezza. 7 Sicurezza e privacy Secondo la definizione ISO è possibile affermare che la sicurezza, vista dal punto di vista del sistema informativo, è l'insieme degli accorgimenti necessari a: ● garantire la disponibilità delle informazioni; ● garantire l'integrità delle informazioni; ● garantire la riservatezza delle informazioni. Il problema della privacy è collegato a quello più generale della sicurezza ed è relativo a tutti i sistemi informativi. La connessione fra le due problematiche avviene in particolare nel nodo utente, o per meglio dire utente autorizzato all'uso del sistema informativo. La tutela della privacy è un problema quotidiano nella gestione dei dati da parte di qualsiasi ente pubblico, tanto più delicato e sentito in campo sanitario, dove i dati raccolti arrivano a "toccare nella sfera più intima" delle persone che vengono in contatto con le strutture preposte. E' fondamentale tenere presente il più ampio spettro di possibilità tecniche in modo da salvaguardare in ogni dove la privacy della persona. Nel contempo, comunque, è necessario ridurre al minimo gli sforzi ed i costi relativi alla modifica delle strutture informative adibite alla gestione dei dati. Le politiche di sicurezza da adottare devono tenere in considerazione e risolvere le problematiche elencate in tabella 4. Oltre alle segnalazioni specifiche su programmi e soluzioni, è di fondamentale importanza definire non solo un metodo di security complessivo, ma soprattutto gestire a livello architetturale tutto il problema. E' necessario definire un livello di vaglio e controllo, che sia in grado di difendere la "rete di lavoro e gestione dati". 43 Azione Descrizione Livello di soluzione Identificazione utente L'utente si identifica presso il sistema informativo fornendo le proprie generalità. Interno all'applicazione. Certificati X.500. Certificati digitali X.509. Autenticazione utente Il trattamento di dati personali con strumenti Interno alla applicazione. elettronici è consentito agli incaricati dotati di Certificati X.500. credenziali di autenticazione, codice per Certificati digitali X.509. l’identificazione dell’incaricato associato a una parola chiave riservata conosciuta solamente dal medesimo, che consentano il superamento di una procedura di autenticazione relativa ad uno specifico trattamento o ad un insieme di trattamenti. La parola chiave è composta da almeno otto caratteri oppure, nel caso in cui lo strumento elettronico non lo permetta, da un numero di caratteri pari al massimo consentito; essa non contiene riferimenti agevolmente riconducibili all’incaricato ed è modificata da quest’ultimo al primo utilizzo e, successivamente, almeno ogni tre mesi, in caso di trattamento di dati sensibili. Il codice per l’identificazione, laddove utilizzato, non può essere assegnato ad altri incaricati, neppure in tempi diversi. Le credenziali di autenticazione non utilizzate da almeno sei mesi sono disattivate, salvo quelle preventivamente autorizzate per soli scopi di gestione tecnica. Autorizzazione utente (Profilo di abilitazione) L'utente è dotato di differenti diritti di accesso a Interno all'applicazione. secondo del proprio ruolo. Profili LDAP/SSON Periodicamente, e comunque almeno annualmente, è Smart-card verificata la sussistenza delle condizioni per la conservazione dei profili di autorizzazione. Responsabilità dell'utente Ogni accesso e/o modifica ai dati deve poter essere ricollegata all'utente che ha effettuato l'azione. File di log interni all'applicazione Protezione del sistema e Il sistema informatico deve essere protetto dagli sistemi anti-intrusione accessi indesiderati. Sicurezza dei Locali. Sistemi firewall e di sicurezza delle reti in genere Protezione delle trasmissioni dati I dati non devono essere trasmessi "in chiaro" sulla rete informatica. Sistemi di crittografia SSL VPN Cifrature dei dati sensibili e giudiziari DLGS 196/2003, Art. 22 comma 6: i dati sensibili e giudiziari contenuti in elenchi, registri o banche dati, tenuti con l’ausilio di strumenti elettronici, sono trattati con tecniche di cifratura. Utilizzo di strumenti di cifratura dei dati Conservazione separata DLGS 196/2003, Art 22 comma 7: i dati idonei a dei dati rivelare lo stato di salute e la vita sessuale sono conservati separatamente da altri dati personali trattati per finalità che non richiedono il loro utilizzo. Interno alle applicazioni Tabella 4Politiche di sicurezza 44 8 Qualità dei beni e dei servizi ICT APSS considera come riferimento per le strategie di controllo della qualità dei beni e dei servizi ICT, le linee guida per la definizione ed il governo dei contratti della Pubblica Amministrazione elaborate dal CNIPA5. Le Linee guida hanno lo scopo di definire: ● un quadro di riferimento complessivo per l’appalto di servizi ICT da parte delle amministrazioni; ● metodi quantitativi da applicarsi per definire misure di qualità ed identificare processi di misura, allo scopo di fornire indicazioni concrete, pragmatiche, immediatamente applicabili, sia alle amministrazioni appaltanti che ai fornitori offerenti; ● adeguate clausole, da utilizzarsi in fase di negoziazione, per la definizione di capitolati e contratti pubblici per la fornitura di beni e servizi nel settore ICT, relative alla descrizione delle attività da prevedersi contrattualmente, ai prodotti che dette attività realizzano (deliverables contrattuali), agli indicatori e misure di qualità da riferirsi sia alle attività che ai prodotti; ● clausole successivamente utili nella fase di attuazione dei contratti ICT, per la necessaria azione di governo del contratto e lo svolgimento del monitoraggio per la verifica del rispetto dei requisiti contrattuali in termini di tempi, costi e stato avanzamento lavori, quantità e qualità attese dei servizi ICT richiesti. 5 - Centro Nazionale per l'Informatica nella Pubblica Amministrazione (www.cnipa.gov.it ) 45 9 Specifiche Funzionali di Integrazione con il Sistema Informativo dell’APSS Il presente capitolo definisce le specifiche funzionali che devono essere soddisfatte da un qualsiasi sistema dipartimentale e/o verticale che si debba integrare con il Sistema Informativo per la gestione “amministrativa” e “clinica” di APSS, diffuso in tutti gli ospedali dell’Azienda Sanitaria. Tutti i flussi di integrazione sono realizzati mediante lo scambio di messaggistica standard HL7 V. 2.5 e DICOM. 1. Premessa Un generico sistema applicativo/informatico (di seguito “Sistema Satellite”), oggetto di acquisizione, deve integrarsi con le seguenti procedure, distribuite uniformemente a livello aziendale, che nel loro insieme costituiscono il Sistema Informativo di APSS: · Anagrafica · Gestione Amministrativa Ricoveri (ADT) · Pronto Soccorso (PS) · Centro Unico Prenotazioni (CUP) (Prenotazione prestazioni specialistiche ambulatoriali per pazienti esterni sul territorio provinciale) · Clinical Data Repository del Sistema Informativo Ospedaliero, SIO · Order Management · Minimum Data Set multidisciplinare · Principali Sistemi diagnostici (LIS, RIS) · PACS · Sistema di gestione delle CASSE · Sistema Informativo Territoriale, SIT · Sistema Informatico Gestione Richieste Utente Tali funzionalità sono in parte fornite da soluzioni sviluppate internamente all’azienda e in parte acquisite da fornitori esterni ad APSS. Nelle prossime pagine sono descritti i flussi d’integrazione da implementare. 4. Anagrafe L’anagrafe pazienti del Sistema Satellite (indicata nel seguito come “Anagrafe Satellite”) deve essere integrata con l’Anagrafe di APSS, realizzata secondo il profilo PIX di IHE, attraverso le modalità di seguito descritte. Essa deve inoltre contenere tutti i dati anagrafici utili per la corretta identificazione del paziente, ereditati dalla gestione anagrafica aziendale, compreso l'Identificativo Anagrafico Aziendale che identifica univocamente il paziente in tutti i sistemi. Operazioni che possono essere effettuate sull’Anagrafe: · inserimento di una nuova anagrafica (ADT A28); · aggiornamento di una anagrafica presente (ADT A31); · fusione (merge) di due anagrafiche (ADT A40) In merito a questa modalità di integrazione si precisa inoltre quanto segue, relativamente all'Anagrafe Satellite: · L’anagrafe satellite, a fronte di modifiche anagrafiche, deve notificare eventuali inserimenti/aggiornamenti all’anagrafe centrale; si deve tener presente che alcuni campi, non potranno essere modificati da parte dell'Anagrafe Satellite, che deve pertanto essere in grado di inibirne la modificabilità. 46 · Qualora sia necessario inserire nuove posizioni anagrafiche direttamente nel sistema satellite, queste dovranno essere notificate all’Anagrafe. Interrogazione dell’Anagrafe dal Sistema Satellite tramite web service, seguito dall’importazione puntuale dei dati anagrafici nell’anagrafe locale. Eventualmente, se si modificano i dati anagrafici letti, è possibile inviare un messaggio di notifica con standard HL7 (ADT A29) all’Anagrafe. I servizi messi a disposizione dal web service sono i seguenti: · ricerca anagrafica; · richiesta dati anagrafici (sintetici o dettagliati). Ogni servizio ritorna una stringa contenente un documento XML. 5. ADT Il sistema di ADT in uso presso APSS è stato realizzato internamente all'azienda e prende il nome di SIO (Sistema Informativo Ospedaliero). Si occupa sostanzialmente della movimentazione dei pazienti e della gestione amministrativa. Al Sistema Satellite se previsto, è richiesto di integrarsi con il sistema di ADT al fine di ricevere le informazioni relative movimentazione dei pazienti (accettazioni, trasferimenti,dimissioni). La modalità di integrazione verrà realizzata tramite messaggi standard HL7 V 2.5. Ogni evento clinico è contraddistinto da: · dati anagrafici · numero nosografico · reparto di cura codificato · regime di ricovero · data accettazione/trasferimento/dimissione I dati anagrafici degli eventi clinici sono gestiti centralmente attraverso il servizio di Anagrafica . Il sistema locale, dovrà essere in grado di ricevere gli eventi clinici relativi a: · pre-accettazioni (ADT^A05) · annullamento pre-accettazione (ADT^A38) · accettazioni (ADT^A01) · annullamento accettazioni (ADT^A11) · dimissioni (ADT^A03) · annullamento dimissioni (ADT^A13) · trasferimenti (ADT^A02) · annullamento trasferimenti (ADT^A12) · modifica dati paziente (ADT^A08) · spostamento visita (ADT^A45) Non è consentito al sistema satellite di effettuare direttamente le operazioni sopra elencate, in quanto queste continueranno ad essere eseguite sul SIO e la relativa movimentazione sarà trasmessa tramite i messaggi di ADT. 6. Pronto Soccorso La gestione del pronto soccorso in APSS è realizzata attraverso il SIO che gestisce anche l'ADT. La richiesta di esami/prestazioni da parte del Pronto Soccorso verso il Sistema Satellite deve essere gestita come segue: · La richiesta viene redatta nell'applicativo di PS e inviata direttamente al Sistema Satellite. Insieme alla richiesta viene inviato il nosografico di Pronto Soccorso che deve essere memorizzato dal Sistema Satellite. · I referti e/o i risultati relativi alle richieste di Pronto Soccorso devono essere inviati dal Sistema Satellite al repository (ITACA), da cui verranno poi consultati e 47 stampati, che provvederà ad associarli al rispettivo ricovero di PS utilizzando il nosografico. Anche in questo caso la comunicazione deve avvenire nel rispetto dello standard HL7 V 2.5. 7. CUP La prenotazione di prestazioni specialistiche ambulatoriali per pazienti esterni sul territorio provinciale viene effettuata utilizzando il sistema di prenotazione aziendale CUPIDO (Argentea). La prenotazione deve avvenire con le seguenti modalità: o La prenotazione degli esami deve essere effettuata mediante la procedura aziendale di CUP in uso. A questa è delegata l’identificazione del paziente e la registrazione delle richieste. o La richiesta viene trasferita dal CUP al Sistema Satellite per l’esecuzione utilizzando messaggistica HL7. o Il Sistema Satellite deve essere in grado di gestire correttamente anche l’eventuale cancellazione o modifica di una prenotazione inserita a CUP, e già ricevuta dallo stesso Sistema Satellite. o Il Sistema Satellite deve effettuare la rendicontazione delle prestazioni erogate al sistema CUP. In linea con l’infrastruttura di integrazione di APSS, l’integrazione del sistema satellite con il CUP deve avvenire tramite messaggi HL7. I messaggi utilizzati saranno quelli previsti dallo standard HL7 V 2.5 a seconda della tipologia di sistema satellite (ORM, OMG, etc.) 8. Clinical Data Repository / Order Management / Minimum Data Set Sia le richieste, che i referti, che qualsiasi altro dato clinico dovranno essere trasmessi dal Sistema Satellite e verranno inviati allo stesso attraverso messaggi conformi allo standard HL7 V 2.5 (o DICOM nel caso di immagini) e saranno veicolati dal middleware di integrazione. 9. Sistemi Diagnostici Il Sistema satellite, nel caso sia richiesto dalla specialità che gestisce, deve essere in grado di ricevere dal Sistema di Laboratorio o da altri sistemi diagnostici dipartimentali, dati analitici e/o risultati e/o referti, relativi alle richieste del reparto che gestisce. Il trasferimento dovrà riguardare i dati degli esami refertati e dovrà essere in grado di gestire eventuali ri trasmissioni per annullamento del referto. I dati ricevuti dovranno essere collegati al rispettivo paziente nel Sistema Satellite. 10. Radiology Information System, RIS Per quanto riguarda l'integrazione con il RIS-Fuji adottato da APSS, si richiede l'aderenza allo standard HL7 e interoperabilità dell'attività di refertazione. 11. Picture archiving and communication system, PACS Il sistema satellite, nel caso sia richiesto dalla specialità che gestisce, deve essere in grado sia di richiedere che di importare dal sistema PACS-FUJI adottato in APSS le immagini diagnostiche in formato DICOM presenti nel PACS aziendale o nelle singole modality. Tali immagini dovranno, a seconda della configurazione prescelta dall'APSS, poter essere immagazzinate nel sistema stesso oppure richiamate all'occorrenza via DICOM query dal PACS o direttamente dalla modality. Il sistema dovrà interagire con il PACS conformemente ai profili di integrazione IHE. 48 12. Interoperabilità con LDAP o sistema GRU Il sistema satellite dovrà essere integrato con Active Directory via protocollo LDAP per le operazioni di autenticazione. L' integrazione deve essere tale da: - consentire il passaggio delle credenziali digitate dall'utente al sistema LDAP per la loro verifica e la gestione coerente della risposta da questo fornita; - gestire il cambio password qualora le credenziali siano scadute sul sistema LDAP o siano nei termini di avviso di scadenza; - gestire il reset della password su iniziativa dell'utente e gestire l'informazione di supporto sullo scope dell'operazione. In alternativa dovrà interoperare via Web Services con il sistema aziendale di Gestione Richieste Utente per la operazione di rilascio di nuova password per un utente del sistema. 49
© Copyright 2024 Paperzz
