1 Oggetto del documento Definizioni, Acronimi ed Abbreviazioni Riferimenti Architettura generale Anagrafe operatori...

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "1 Oggetto del documento... 2 2 Definizioni, Acronimi ed Abbreviazioni... 2 3 Riferimenti... 2 4 Architettura generale... 2 4.1 Anagrafe operatori..."

Transcript

1 1 Oggetto del documento Definizioni, Acronimi ed Abbreviazioni Riferimenti Architettura generale Anagrafe operatori Anagrafe assistiti Fascicolo Sanitario Elettronico (FSE) Il Registry (indice documenti) L Access Gateway Il Repository dei documenti Funzionalità Flussi disponibili Flusso di autenticazione web services Flusso di sottomissione Flusso di interrogazione Flusso di retrieve Flusso di integrazione anagrafica Flusso gestione delle notifiche Flusso di integrazione CUP Flusso di integrazione Specifiche messaggistica Messaggio di richiesta token Saml Messaggio di risposta al messaggio di richiesta token Messaggio chiamata Proxy-ws con token Saml firmato Messaggio risposta proxy-ws Client Legacy... 19

2 1 Oggetto del documento L obiettivo del presente documento è la descrizione tecnico-funzionale delle tecnologie di sicurezza utilizzate per la protezione e la tutela dell accesso ai dati e ai servizi del progetto reti MMG della Regione Abruzzo e la modalità di integrazione con gli stessi. Sarà fornita la descrizione delle interfacce esposte per l accesso al sistema di archiviazione e di consultazione del FSE attraverso il modulo di Access Gateway, Anagrafe operatori e Anagrafe Assistiti. 2 Definizioni, Acronimi ed Abbreviazioni Acronimi Sigla Esteso SSO Single sign on WS Web services MMG Medici di Medicina Generale DN Distinguished name OU Organizational Unit CN Common Name FSE Fascicolo Sanitario Elettronico MMG Medici di Medicina Generale PLS Pediatri di Libera Scelta aka Also Known As HL7 Health Level 7 D-MIM Domain Message Information Model IHE Integrating HealthCare Enterprise SOA Service Oriented Architecture FSE Fascicolo Sanitario Elettronico 3 Riferimenti Client_legacy_integration.pdf IHE_ITI_TF_5.0_Vol2_FT_ doc Specifiche Tecniche Anagrafe Assistiti.doc Piano di test modulo Anagrafica Assititi.doc Specifiche Tecniche Modulo CUP.pdf Affinity Domain ReteMMG.pdf 4 Architettura generale Di seguito il Component Diagram relativo all infrastruttura del progetto reti MMG della Regione Abruzzo:

3 Dedalus FSE Mobile Client SSO Viewer Pronto Soccorso Service Provider ESB SAML, WS-Sec, WS-Trust, WS-Rest. POP3 Figura 1 - Architettura generale 4.1 Anagrafe operatori Il modulo Anagrafe Operatori è un insieme di software che permettono la creazione di un SSO utilizzabile sia in contesti di architetture SOA che in architetture rivolte ai Moduli Web. La gestione dell accesso ai servizi costituisce un punto nevralgico di ogni architettura, il modulo Anagrafe Operatori rappresenta un supporto che permette agli applicativi di svincolarsi dalle logiche di autenticazione e profilazione degli utenti. Il modulo Anagrafe Operatori come accennato in precedenza può essere utilizzato in architetture Web Oriented in cui l utente è una persona fisica. In questo caso le applicazioni che sono costituite da un front-end web e l utente fruisce della risorsa protetta dal SSO attraverso l uso di un comune browser web. Il modulo Anagrafe Operatori può essere anche utilizzato in un architettura SOA, l utente fruisce dei servizi attraverso un applicativo chiamante. I servizi sono esposti attraverso l uso di Web Services protetti dal SSO che sono invocati dall applicativo chiamante. 4.2 Anagrafe assistiti Per assicurare l univocità di identificazione degli assistiti all interno del domino operativo (i.e. la rete MMG/PLS), quindi garantire la corretta attribuzione delle informazioni anagrafiche e di posizione assistenziale (informazioni su medico curante, esenzioni, ) viene proposto un modello di collaborazione fra sistemi anagrafici di tipo gerarchico, in cui il modulo MAC (Modulo Anagrafe Centrale) svolga il ruolo di Anagrafe Sanitaria Master per l intero sistema informativo della Rete dei Medici a livello Regionale. L ownership delle informazioni identificative ed anagrafiche sarà comunque detenuta dall Anagrafe Regionale: il modulo fornito (MAC) - oggetto di questo progetto sarà quindi mantenuto in

4 sincrono con l Anagrafe Regionale attraverso il servizio SIAR fungendone da cache ed operando come interfaccia di collaborazione verso la rete MMG. Il modello di collaborazione fra anagrafiche adottato (modello gerarchico) prevede tutti i sistemi periferici (Cartelle Ambulatoriali MMG/PLS,etc) si comportino in termini di identificazione anagrafica come slave : tutte le informazioni anagrafiche ed identificative sono quindi derivate dal sistema MAC. Data la peculiarità del processo assistenziale territoriale gestito dai Medici di Medicina Generale e delle caratteristiche della infrastruttura informativa e di comunicazione utilizzata a supporto di quest ultimo, è stato scelto deciso di utilizzare un modello di interazione fra MAC e sistemi periferici così strutturato: per le comunicazioni da MAC verso i sistemi periferici si prevede una interazione di tipo asincrono attraverso un meccanismo di polling (gestione di code) - per le notifiche di variazioni anagrafiche o di riconduzione di posizioni duplicate; i meccanismi di collaborazione fra sistemi periferici e MAC (consultazione anagrafe, notifica aggiornamenti dati) saranno invece realizzati attraverso servizi sincroni. Ogni servizio è realizzato tramite servizi conformi allo standard HL7 V3, dove necessario, localizzato nel Realm Italiano. Dal punto di vista funzionale, il medesimo database del sistema MAC è utilizzato oltre che dall interfaccia applicativa di cooperazione descritta nei paragrafi seguenti, anche un front-end web per la consultazione delle informazioni gestite dal sistema 4.3 Fascicolo Sanitario Elettronico (FSE) All interno del progetto rete MMG il Fascicolo Sanitario Elettronico viene definito come un indice di oggetti informativi sanitari firmati digitalmente e creati nella storia dei suoi contatti dell assistito con i diversi attori del Sistema Sanitario Nazionale. Esso è accessibile dal cittadino e dagli operatori sanitari giuridicamente autorizzati in qualunque luogo ed in qualunque momento nel rispetto della regolamentazione nazionale e regionale e della tutela della privacy. Il Fascicolo Sanitario Elettronico deve permettere la gestione dei dati clinici sia da un punto di vista tecnico/informatico, sia dal punto di vista logico sanitario. Esso è uno strumento informativo condiviso e accessibile da tutti coloro che ne hanno il diritto, strutturato come una raccolta cronologica di eventi e informazioni longitudinale alla storia clinica del paziente. In base a questa definizione il tavolo di progettazione condivisa individua quindi nel Fascicolo Sanitario Elettronico un entità concettuale costituita dall'aggregazione logico-funzionale dei tre componenti rappresentati dall Access Gateway, dal Registry e dal Repository Il Registry (indice documenti) Il componente Registry è l indice del Fascicolo Sanitario Elettronico. Contiene l insieme dei metadati dei documenti memorizzati sui Repository e permette di recuperare questi ultimi, conformemente ai diritti di accesso dell utente richiedente, è centralizzato a livello regionale. Il Registry presenta le seguenti principali funzionalità: 1. recupero delle informazioni sui documenti (metadati) 2. creazione e modifica dello stato di un documento (modifica dei metadati) a fronte di una notifica dell Access Gateway"

5 4.3.2 L Access Gateway Il componente AccessGateway nella architettura IBSE è stato inizialmente concepito per realizzare le funzionalità necessarie a supportare comunicazioni sicure tra sistemi clinici e componenti interne del FSE, e tra queste ultime (in particolare, tra registry e repository). Può essere implementato sia a livello di ASL/AO sia a livello regionale. L Access gateway presenta le seguenti principali funzionalità: gestione delle comunicazioni tra le componenti interne al FSE gestione della criptazione a livello di messaggio. gestione degli aspetti di sicurezza e controllo degli accessi, mediante verifica e autorizzazione degli utenti (con il supporto dei sistemi anagrafici sanitari e delle Certification Authority) all accesso alle risorse del sistema. Pertanto, implementa primariamente le fasi di autenticazione forte (basata sull uso di CIE/CNS) identificazione forte (basata sull uso di CIE/CNS) autorizzazione gestione del tracciamento degli accessi Ulteriori componenti che non fanno parte del FSE, ma che sono di supporto alle funzionalità dell Access Gateway nel controllo degli accessi sono: Database a supporto alla sicurezza per la gestione di politiche e diritti di accesso 1, correlazioni tra medici e assistiti. Essi possono essere realizzati centralmente a livello regionale, distribuiti a livello di ASL/AO, oppure a livello di entrambi. Anagrafi operatori ed assistiti per la gestione degli utenti del sistema (operatori ed assistiti). Ciascuna tipologia di anagrafe può essere realizzata centralmente o a livello di ASL/AO. In tale contesto (i.e. in IBSE) l Access Gateway funge da facilitatore nell accesso ai componenti Registry e Repository, rendendo l infrastruttura trasparente dalle specifiche di implementazione del repository (qualora il sistema sia già presente sul territorio) Il Repository dei documenti Contiene documenti informatici[1] firmati digitalmente[2], la cui memorizzazione avviene secondo le modalità previste dal d.lgs.196/2003 (in particolare art. 22, comma 6). E normalmente distribuito a livello aziendale (ASL/AO), che ne è responsabile ai fini del trattamento, poiché i documenti risiedono nelle strutture sanitarie in cui sono stati creati. Il Repository presenta le seguenti principali funzionalità: 1. recupero di un documento a partire da un suo riferimento 2. memorizzazione di un documento [1] Tali documenti sono strutturati secondo lo standard internazionale HL7/CDA2, esplicitamente progettato per la rappresentazione di documenti clinici. 1 Si veda il documento DIT Matrice degli accessi (IBSE-RMMG-matrice-accessi-v01.00-BOZZA01.pdf)

6 [2] In base agli artt 20 comma 2 e 21 comma 2 del d.lgs n. 82 del 7/03/2005 Codice dell amministrazione digitale. Inoltre, in questo modo, per questi documenti si garantisce integrità e non ripudio. 5 Funzionalità Nell architettura prevista dal progetto tutti i servizi esposti verso gli attori attraverso l uso di architetture SOA dovranno essere protetti con l uso di WS-Security e SAML Assertion. Lo scambio di messaggi tra i componenti del sistema, cioè gli attori che partecipano al processo interattivo, identificabili dai componenti fisici come i client (Applicativi di Cartella, ADT, etc.) o dai componenti logici come quelli che espongono i servizi applicativi (Registry, Repository, CUP, Anagrafe regionale, etc), sarà filtrato da un componente proxy che realizza le funzionalità dei componenti logici definiti Access Gateway(AG) e Anagrafe Operatori. Tale proxy espone i servizi erogati dagli attori del progetto rete MMG in modo configurabile effettuando le funzionalità di filtro e controllo descritte in precedenza. 5.1 Flussi disponibili Il modulo proxy espone le interfacce per la gestione e mette a disposizione una serie di funzioni classificabili nelle seguenti categorie : Flusso di autenticazione Flusso di sottomissione Flusso di interrogazione Flusso di retrieve Flusso di integrazione anagrafica Flusso gestione delle notifiche Flusso di integrazione CUP Flusso di autenticazione web services Un applicativo che intende fruire di un servizio esposto deve necessariamente effettuare una chiamata verso il modulo di autenticazione. Il modulo valida le credenziali fornite dall applicativo chiamante sull anagrafe operatori verificando se l utente che intende fruire del servizio sia effettivamente censito ed autorizzato ad effettuare l operazione richiesta. Di seguito un schema riassuntivo di questa architettura:

7 Figura 2: Schema Architettura Modulo Autenticazione Web Services L applicativo di cartella prima di effettuare la chiamata SOAP verso il Web Service che vuole invocare, richiede l autenticazione dell operatore al modulo di autenticazione. Il componente Identity Provider del modulo di autenticazione, verifica sul Server OpenLDAP la validità delle credenziali inserite nel messaggio di richiesta(username e password). In caso di successo restituisce una asserzione SAML firmata con chiave privata. Tale asserzione viene quindi veicolata tramite il SOAP header ed usata dal Proxy Web Services per verificare l abilitazione dell operatore ad accedere al servizio invocato. L operazione di verifica avviene utilizzando i seguenti passi: prima viene verificata la firma della SAML Assertion,con la chiave pubblica per controllare l autenticità delle identità e del profilo (ruoli) trasmessi; quindi verifica che almeno uno dei ruoli associati all utente sia abilitato all invocazione del servizio. Se tutti i controlli sopraelencati vanno a buon fine il modulo instrada la chiamata verso il WS che eroga il servizio. Nel caso in cui i controlli non abbiano esito positivo, ossia l utente non risulta validato sull anagrafe operatori o il suo ruolo non permette di invocare il servizio e/ dell operazione richiesta, viene restituito all applicativo chiamante un messaggio di errore. L applicativo chiamante utilizza nelle successive chiamate il token Saml firmato fino alla scadenza dello stesso. Le policy di accesso relative alle singole operazioni (sottomissioni di documenti, interrogazioni, etc.) è oggetto di altri documenti descriventi il sistema nel suo complesso. Le funzioni di autenticazione sono le seguenti : RequestSecurityToken Tale metodo viene esposto dal modulo Identity provider che effettua il controllo delle credenziali sull Anagrafe Operatori. Le funzionalità esposte sono conformi ai seguenti standard: WS-Security

8 SAML Flusso di sottomissione Le funzioni di sottomissione sono le seguenti : DocumentRepository_ProvideAndRegisterDocumentSetB Per questa funzionalità fare riferimento alla documentazione IHE relativa al profilo XDS-B Rif.: IHE_ITI_TF_5.0_Vol2_FT_ doc Rif.: Affinity Domain ReteMMG.pdf Flusso di interrogazione Le funzioni di interrogazione sono le seguenti : RegistryStoredQuery Per questa funzionalità fare riferimento alla documentazione IHE relativa al profilo XDS-B Rif.: IHE_ITI_TF_5.0_Vol2_FT_ doc Rif.: Affinity Domain ReteMMG.pdf Flusso di retrieve Le funzioni di retrieve sono le seguenti: DocumentRepository_RetrieveDocumentSet Per questa funzionalità fare riferimento alla documentazione IHE relativa al profilo XDS-B Rif.: IHE_ITI_TF_5.0_Vol2_FT_ doc Rif.: Affinity Domain ReteMMG.pdf Flusso di integrazione anagrafica Le funzionalità di integrazione sono le seguenti per maggiori dettagli fare riferimento al documento di specifiche tecniche: SIA Servizio Identificazione Assistiti; STAA Servizio Trasmissione Aggiornamenti; SRDPR - Servizio Riconduzione Paziente; SNVA - Servizio notifica variazione anagrafica. Rif.: Specifiche Tecniche Anagrafe Assistiti.doc Rif.: Piano di test modulo Anagrafica Assititi.doc Flusso gestione delle notifiche Un applicativo client pubblica un referto, il Registry utilizzando il profilo IHE-NAV inoltra una mail al medico dell assistito per il quale è stato prodotto il referto. L applicativo di cartella può così procedere con lo scaricamento del documento dal Repository e l acquisizione in cartella. Rif.: IHE_ITI_TF_5.0_Vol2_FT_ doc

9 5.1.7 Flusso di integrazione CUP E prevista dalle specifiche di progetto l integrazione degli applicativi di cartella con il sistema regionale di SovraCup. Per questo scopo è stato realizzato un componente che espone le seguenti funzionalità: SRPECUP - Servizio Ricerca Prestazioni Erogabili CUP; SIPCUP - Servizio Inserimento Prenotazione CUP; SRLPA - Servizio Recupero Lista Prenotazioni per Assistito; SAPCUP - Servizio Annullamento Prenotazione CUP. Rif.: Specifiche Tecniche Modulo CUP.pdf 5.2 Flusso di integrazione L applicativo che si integra con l architettura deve eseguire le seguenti operazioni per effettuare l inserimento di un referto CDA2 nel Fascicolo Sanitario Elettronico: I. Autenticazione sul sistema e ricezione del token SAML. (RequestSecurityToken 2 ) II. Utilizzare il Token SAML ricevuto per effettuare le successive chiamate al proxy dei servizi, tali chiamate possono devono essere effettuate verso: a. Il modulo di anagrafe assistiti (invocazione del servizio SIA 3 )Dal messaggio HL7 tornato viene recuperato l identificativo dell assistito che sarà utilizzato nei flussi successivi. b. Il Repository per effettuare la sottomissione di un referto CDA2 e dei relativi metadati previsti dal framework IHE (DocumentRepository_ProvideAndRegisterDocumentSetB).Per la sottomissione è del referto è necessario utilizzare l identificativo regionale ottenuto con l interrogazione anagrafica. Il referto deve essere trasmesso in formato CDA2 come previsto dalle specifiche del TSE Per la firma digitale e la gestione dei fogli di trasformazione dei documenti CDA da inviare si faccia riferimento a quanto definito da CNIPA. c. Il Registry per effettuare la ricerca dei documenti che soddisfano una specifici criteri di ricerca. 5.3 Specifiche messaggistica Messaggio di richiesta token Saml Il messaggio comprende oltre alle intestazioni di WS-Security un tag UsernameToken contenente le credenziali dell operatore che vuole autenticarsi ed ottenere il Token firmato. Il Body contiene la richiesta di un token SAML, RequestSecurityToken. <?xml version='1.0' encoding='utf-8'?> <soapenv:envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsa="http://www.w3.org/2005/08/addressing"> <soapenv:header> <wsse:security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis wss- 2 Integrazione_AnagrafeOperatori_AG.doc 3 D Specifiche Tecniche Anagrafe Assistiti Completo_ _vdef.doc

10 wssecurity-secext-1.0.xsd" soapenv:mustunderstand="1"> <wsu:timestamp xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis wsswssecurity-utility-1.0.xsd" wsu:id="timestamp "> <wsu:created> t15:16:06.938z</wsu:created> <wsu:expires> t15:21:06.938z</wsu:expires> </wsu:timestamp> <wsse:usernametoken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis wsswssecurity-utility-1.0.xsd" wsu:id="usernametoken "> <wsse:username>ccrttl55m08d472i</wsse:username> <wsse:password Type="http://docs.oasis-open.org/wss/2004/01/oasis wss-usernametoken-profile-1.0#PasswordText" > </wsse:Password> </wsse:usernametoken> </wsse:security> <wsa:to>http://localhost:8082/idp-ws/services/basicsamlissuer</wsa:to> <wsa:messageid>urn:uuid:8a2238b7aa83b35dca </wsa:messageid> <wsa:action>http://schemas.xmlsoap.org/ws/2005/02/trust/rst/issue</wsa:action> </soapenv:header> <soapenv:body> <wst:requestsecuritytoken xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust"> <wst:requesttype>http://schemas.xmlsoap.org/ws/2005/02/trust/issue</wst:requesttype > <wst:tokentype>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile- 1.1#SAMLV1.1</wst:TokenType> <wsp:appliesto xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"> <wsa:endpointreference> <wsa:address/> </wsa:endpointreference> </wsp:appliesto> <wst:keytype>http://schemas.xmlsoap.org/ws/2005/02/trust/publickey</wst:keytype> <wst:keysize>256</wst:keysize> </wst:requestsecuritytoken> </soapenv:body> </soapenv:envelope> Messaggio di risposta al messaggio di richiesta token Il messaggio contiene nel SOAP body l asserzione SAML firmata dal modulo server IDP che il client utilizza per effettuare le chiamate verso i servizi.

11 <?xml version='1.0' encoding='utf-8'?> <soapenv:envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:wsa="http://www.w3.org/2005/08/addressing"> <soapenv:header> <wsse:security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis wss-wssecurity-secext-1.0.xsd" soapenv:mustunderstand="1"> <wsu:timestamp xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis wss-wssecurity-utility-1.0.xsd" wsu:id="timestamp "> <wsu:created> t15:16:03.067z</wsu:created> <wsu:expires> t15:21:03.067z</wsu:expires> </wsu:timestamp> </wsse:security> <wsa:action>http://schemas.xmlsoap.org/ws/2005/02/trust/rstr/issue</wsa:action> <wsa:relatesto>urn:uuid:8a2238b7aa83b35dca </wsa:relatesto> </soapenv:header> <soapenv:body> <wst:requestsecuritytokenresponse xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust"> <wst:tokentype>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile- 1.1#SAMLV1.1</wst:TokenType> <wst:requestedattachedreference> <wsse:securitytokenreference xmlns:wsse="http://docs.oasisopen.org/wss/2004/01/oasis wss-wssecurity-secext-1.0.xsd"> <wsse:reference URI="#_a4f71af ec164694edef4361d4" ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1" /> </wsse:securitytokenreference> </wst:requestedattachedreference> <wst:requestedunattachedreference> <wsse:securitytokenreference xmlns:wsse="http://docs.oasisopen.org/wss/2004/01/oasis wss-wssecurity-secext-1.0.xsd"> <wsse:reference URI="_a4f71af ec164694edef4361d4" ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1" /> </wsse:securitytokenreference> </wst:requestedunattachedreference> <wst:lifetime> <wsu:created xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis wss-wssecurity-utility-1.0.xsd"> T15:16:03.046Z</wsu:Created> <wsu:expires xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis wss-wssecurity-utility-1.0.xsd"> T15:21:03.046Z</wsu:Expires> </wst:lifetime> <wst:requestedsecuritytoken> <Assertion xmlns="urn:oasis:names:tc:saml:1.0:assertion" xmlns:samlp="urn:oasis:names:tc:saml:1.0:protocol" xmlns:saml="urn:oasis:names:tc:saml:1.0:assertion" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xmlns:xsd="http://www.w3.org/2001/xmlschema"

12 AssertionID="_a4f71af ec164694edef4361d4" IssueInstant=" T15:16:03.058Z" CN=DedalusCA, OU=Sviluppo, O=Dedalus S.p.A., L=Firenze, ST=Firenze, C=IT" MajorVersion="1" MinorVersion="1"> <Conditions NotBefore=" T15:16:03.058Z" NotOnOrAfter=" T16:16:03.058Z" /> <AuthenticationStatement AuthenticationInstant=" T15:16:03.048Z" AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:unspecified"> <Subject> <NameIdentifier>VVRTTL55M07D472I</NameIdentifier> <SubjectConfirmation> <ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:holder-ofkey</ConfirmationMethod> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"> <xenc:encryptedkey xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="EncKeyIdurn:uuid:2FE4F707E339CD75D "> <xenc:encryptionmethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" /> <ds:keyinfo> <wsse:securitytokenreference xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis wss-wssecuritysecext-1.0.xsd"> <wsse:keyidentifier EncodingType="http://docs.oasisopen.org/wss/2004/01/oasis wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-security- 1.1#ThumbprintSHA1">pfF7kNK/csb7tO/sRH4ZVqkHThE=</wsse:KeyIdentifier> </wsse:securitytokenreference> </ds:keyinfo> <xenc:cipherdata> <xenc:ciphervalue>ljwgs2spo7feagn+mwamvacsn916pfbvkvyfm7nwqgjbedn7yky fcuqvgtqiybialliumh1calik4doymf90bxiq8srl5mr4e9k+afosdfteaq/i1gfpjeood2leax oo5yrbbzxbixj3+9ncdvsuzmjulay5umretmwk4htf6ds=</xenc:ciphervalue> </xenc:cipherdata> </xenc:encryptedkey> </KeyInfo> </SubjectConfirmation> </Subject> </AuthenticationStatement> <AttributeStatement> <Subject> <NameIdentifier>VVRTTL55M07D472I</NameIdentifier> <SubjectConfirmation> <ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:holder-ofkey</ConfirmationMethod> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"> <xenc:encryptedkey xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="EncKeyIdurn:uuid:2FE4F707E339CD75D "> <xenc:encryptionmethod

13 Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" /> <ds:keyinfo> <wsse:securitytokenreference xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis wss-wssecuritysecext-1.0.xsd"> <wsse:keyidentifier EncodingType="http://docs.oasisopen.org/wss/2004/01/oasis wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-security- 1.1#ThumbprintSHA1">pfF7kNK/csb7tO/sRH4ZVqkHThE=</wsse:KeyIdentifier> </wsse:securitytokenreference> </ds:keyinfo> <xenc:cipherdata> <xenc:ciphervalue>ljwgs2spo7feagn+mwamvacsn916pfbvkvyfm7nwqgjbedn7yky fcuqvgtqiybialliumh1calik4doymf90bxiq8srl5mr4e9k+afosdfteaq/i1gfpjeood2leax oo5yrbbzxbixj3+9ncdvsuzmjulay5umretmwk4htf6ds=</xenc:ciphervalue> </xenc:cipherdata> </xenc:encryptedkey> </KeyInfo> </SubjectConfirmation> </Subject> <Attribute AttributeName="role" AttributeNamespace="urn:dedasso:attribute"> <AttributeValue>ME</AttributeValue> </Attribute> </AttributeStatement> <ds:signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:signedinfo> <ds:canonicalizationmethod Algorithm="http://www.w3.org/2001/10/xmlexc-c14n#" /> <ds:signaturemethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> <ds:reference URI="#_a4f71af ec164694edef4361d4"> <ds:transforms> <ds:transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /> <ds:transform Algorithm="http://www.w3.org/2001/10/xml-excc14n#"> <ec:inclusivenamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="code ds kind rw saml samlp typens #default xsd xsi" /> </ds:transform> </ds:transforms> <ds:digestmethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> <ds:digestvalue>oood1x8j7v2wb4zo3uqcb94vt2y=</ds:digestvalue> </ds:reference> </ds:signedinfo> <ds:signaturevalue>dawfelfslucp1qozzax3/54mnjhifmucwulyx8fglfrrbhdahpledl

14 YCa8c3iHKzY/RbMbhIty/ziFPwdv6KCXLY2EVYg4a1v1PiVqrpQxKd0XmyCr6H1KAZOSD 6KGREAbIFR94J2u5ygTRiF3kEHoA3j3ZTja+61DiqEhA9RXA=</ds:SignatureValue> <ds:keyinfo> <ds:x509data> <ds:x509certificate>miidjzccavigawibagideaahma0gcsqgsib3dqebbauamigum QswCQYDVQQGEwJJVDEQMA4GA1UECBMHRmlyZW56ZTEQMA4GA1UEBxMHRmly ZW56ZTEXMBUGA1UEChMORGVkYWx1cyBTLnAuQS4xETAPBgNVBAsTCFN2aWx1c HBvMRIwEAYDVQQDEwlEZWRhbHVzQ0ExITAfBgkqhkiG9w0BCQEWEmRlZGFsdXND QUBkZWRhLmNvbTAeFw0wODA4MDQxNDQzMTRaFw0wOTA4MDQxNDQzMTRaMGA xczajbgnvbaytaklumrawdgydvqqiewdgaxjlbnplmrcwfqydvqqkew5ezwrhbh VzIFMucC5BLjERMA8GA1UECxMIU3ZpbHVwcG8xEzARBgNVBAMTClRlc3RTZXJ2ZXIw gz8wdqyjkozihvcnaqebbqadgy0amigjaogbajbylbhcb/if54pwarr1rx/p30sd51 PeWu9SsY/Z/96HdnJFOYBl7Na/4VZ6404zBuMSl/el+GbWLcodJZMEcSF9c7bu+fhc7OW UbdEEoLlnuEbYmYy3Y2XE935e1/CJu+OJovX3fHzdbEtwJ8piF2HkBIgH6wYYM7AsCMp/ 76A1AgMBAAGjggEgMIIBHDAJBgNVHRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1P cgvuu1nmiedlbmvyyxrlzcbdzxj0awzpy2f0ztadbgnvhq4efgquvyvywdkvmpst Z9lZRFzAXFQH LckwgcEGA1UdIwSBuTCBtoAU2QbXrQbbTpVrMswHI4MUq8KHPJyhgZqkgZcwgZQxCz AJBgNVBAYT AklUMRAwDgYDVQQIEwdGaXJlbnplMRAwDgYDVQQHEwdGaXJlbnplMRcwFQYDVQQ KEw5EZWRhbHVz IFMucC5BLjERMA8GA1UECxMIU3ZpbHVwcG8xEjAQBgNVBAMTCURlZGFsdXNDQTEh MB8GCSqGSIb3 DQEJARYSZGVkYWx1c0NBQGRlZGEuY29tggEAMA0GCSqGSIb3DQEBBAUAA4GBAC PB5DlNlCaQB5h3 Smscyg4boO4MiQANMK5H6S+zWh72B8Ly/iYy1Rtg8VqKkbR44y2shYoD1Oooax4qFg1L uo1gsla8 o1j+uf8urb2ca5p8jsteqi4jqab7vxailgjgtv3x6dykvhwcvvegtc4mjcvu1xfzzs04zt p7xkqf +odh </ds:x509certificate> </ds:x509data> </ds:keyinfo> </ds:signature> </Assertion> </wst:requestedsecuritytoken> </wst:requestsecuritytokenresponse> </soapenv:body>

15 5.3.3 Messaggio chiamata Proxy-ws con token Saml firmato Il messaggio verso il modulo proxy è costituito nel body da una normale chiamata al servizio applicativo che si desidera invocare. Nell header deve essere inserito il token SAML ottenuto dalla chiamata effettuata all identity provider. Di seguito un esempio di header SOAP: <soapenv:header> <wsse:security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis wss-wssecurity-secext-1.0.xsd" soapenv:mustunderstand="true"> <Assertion xmlns="urn:oasis:names:tc:saml:1.0:assertion" xmlns:samlp="urn:oasis:names:tc:saml:1.0:protocol" xmlns:saml="urn:oasis:names:tc:saml:1.0:assertion" xmlns:axis2ns1="urn:oasis:names:tc:saml:1.0:assertion" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xmlns:xsd="http://www.w3.org/2001/xmlschema" AssertionID="_a4f71af ec164694edef4361d4" IssueInstant=" T15:16:03.058Z" CN=DedalusCA, OU=Sviluppo, O=Dedalus S.p.A., L=Firenze, ST=Firenze, C=IT" MajorVersion="1" MinorVersion="1"> <Conditions xmlns:axis2ns2="urn:oasis:names:tc:saml:1.0:assertion" NotBefore=" T15:16:03.058Z" NotOnOrAfter=" T16:16:03.058Z" /> <AuthenticationStatement xmlns:axis2ns3="urn:oasis:names:tc:saml:1.0:assertion" AuthenticationInstant=" T15:16:03.048Z" AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:unspecified"> <Subject xmlns:axis2ns4="urn:oasis:names:tc:saml:1.0:assertion"> <NameIdentifier xmlns:axis2ns5="urn:oasis:names:tc:saml:1.0:assertion">vvrttl55m07d472i</nameid entifier> <SubjectConfirmation xmlns:axis2ns6="urn:oasis:names:tc:saml:1.0:assertion"> <ConfirmationMethod xmlns:axis2ns7="urn:oasis:names:tc:saml:1.0:assertion">urn:oasis:names:tc:saml:1.0:c m:holder-of-key</confirmationmethod> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#" xmlns:axis2ns8="http://www.w3.org/2000/09/xmldsig#"> <xenc:encryptedkey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="EncKeyIdurn:uuid:2FE4F707E339CD75D "> <xenc:encryptionmethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" /> <ds:keyinfo> <wsse:securitytokenreference> <wsse:keyidentifier EncodingType="http://docs.oasisopen.org/wss/2004/01/oasis wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-security- 1.1#ThumbprintSHA1">pfF7kNK/csb7tO/sRH4ZVqkHThE=</wsse:KeyIdentifier> </wsse:securitytokenreference> </ds:keyinfo> <xenc:cipherdata>

16 <xenc:ciphervalue>ljwgs2spo7feagn+mwamvacsn916pfbvkvyfm7nwqgjbedn7yky fcuqvgtqiybialliumh1calik4doymf90bxiq8srl5mr4e9k+afosdfteaq/i1gfpjeood2leax oo5yrbbzxbixj3+9ncdvsuzmjulay5umretmwk4htf6ds=</xenc:ciphervalue> </xenc:cipherdata> </xenc:encryptedkey> </KeyInfo> </SubjectConfirmation> </Subject> </AuthenticationStatement> <AttributeStatement xmlns:axis2ns9="urn:oasis:names:tc:saml:1.0:assertion"> <Subject xmlns:axis2ns10="urn:oasis:names:tc:saml:1.0:assertion"> <NameIdentifier xmlns:axis2ns11="urn:oasis:names:tc:saml:1.0:assertion">vvrttl55m07d472i</namei dentifier> <SubjectConfirmation xmlns:axis2ns12="urn:oasis:names:tc:saml:1.0:assertion"> <ConfirmationMethod xmlns:axis2ns13="urn:oasis:names:tc:saml:1.0:assertion">urn:oasis:names:tc:saml:1.0: cm:holder-of-key</confirmationmethod> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#" xmlns:axis2ns14="http://www.w3.org/2000/09/xmldsig#"> <xenc:encryptedkey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="EncKeyIdurn:uuid:2FE4F707E339CD75D "> <xenc:encryptionmethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" /> <ds:keyinfo> <wsse:securitytokenreference> <wsse:keyidentifier EncodingType="http://docs.oasisopen.org/wss/2004/01/oasis wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-security- 1.1#ThumbprintSHA1">pfF7kNK/csb7tO/sRH4ZVqkHThE=</wsse:KeyIdentifier> </wsse:securitytokenreference> </ds:keyinfo> <xenc:cipherdata> <xenc:ciphervalue>ljwgs2spo7feagn+mwamvacsn916pfbvkvyfm7nwqgjbedn7yky fcuqvgtqiybialliumh1calik4doymf90bxiq8srl5mr4e9k+afosdfteaq/i1gfpjeood2leax oo5yrbbzxbixj3+9ncdvsuzmjulay5umretmwk4htf6ds=</xenc:ciphervalue> </xenc:cipherdata> </xenc:encryptedkey> </KeyInfo> </SubjectConfirmation> </Subject> <Attribute xmlns:axis2ns15="urn:oasis:names:tc:saml:1.0:assertion" AttributeName="role" AttributeNamespace="urn:deda-sso:attribute"> <AttributeValue xmlns:axis2ns16="urn:oasis:names:tc:saml:1.0:assertion">me</attributevalue> </Attribute> </AttributeStatement>

17 <ds:signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:signedinfo> <ds:canonicalizationmethod Algorithm="http://www.w3.org/2001/10/xml-excc14n#" /> <ds:signaturemethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsasha1" /> <ds:reference URI="#_a4f71af ec164694edef4361d4"> <ds:transforms> <ds:transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /> <ds:transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"> <ec:inclusivenamespaces xmlns:ec="http://www.w3.org/2001/10/xmlexc-c14n#" PrefixList="code ds kind rw saml samlp typens #default xsd xsi" /> </ds:transform> </ds:transforms> <ds:digestmethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> <ds:digestvalue>oood1x8j7v2wb4zo3uqcb94vt2y=</ds:digestvalue> </ds:reference> </ds:signedinfo> <ds:signaturevalue>dawfelfslucp1qozzax3/54mnjhifmucwulyx8fglfrrbhdahpledl YCa8c3iHKzY/RbMbhIty/ziFPwdv6KCXLY2EVYg4a1v1PiVqrpQxKd0XmyCr6H1KAZOSD 6KGREAbIFR94J2u5ygTRiF3kEHoA3j3ZTja+61DiqEhA9RXA=</ds:SignatureValue> <ds:keyinfo> <ds:x509data> <ds:x509certificate>miidjzccavigawibagideaahma0gcsqgsib3dqebbauamigum QswCQYDVQQGEwJJVDEQMA4GA1UECBMHRmlyZW56ZTEQMA4GA1UEBxMHRmly ZW56ZTEXMBUGA1UEChMORGVkYWx1cyBTLnAuQS4xETAPBgNVBAsTCFN2aWx1c HBvMRIwEAYDVQQDEwlEZWRhbHVzQ0ExITAfBgkqhkiG9w0BCQEWEmRlZGFsdXND QUBkZWRhLmNvbTAeFw0wODA4MDQxNDQzMTRaFw0wOTA4MDQxNDQzMTRaMGA xczajbgnvbaytaklumrawdgydvqqiewdgaxjlbnplmrcwfqydvqqkew5ezwrhbh VzIFMucC5BLjERMA8GA1UECxMIU3ZpbHVwcG8xEzARBgNVBAMTClRlc3RTZXJ2ZXIw gz8wdqyjkozihvcnaqebbqadgy0amigjaogbajbylbhcb/if54pwarr1rx/p30sd51 PeWu9SsY/Z/96HdnJFOYBl7Na/4VZ6404zBuMSl/el+GbWLcodJZMEcSF9c7bu+fhc7OW UbdEEoLlnuEbYmYy3Y2XE935e1/CJu+OJovX3fHzdbEtwJ8piF2HkBIgH6wYYM7AsCMp/ 76A1AgMBAAGjggEgMIIBHDAJBgNVHRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1PcG VuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUVYvYwDkvMPStZ9l ZRFzAXFQHLckwgcEGA1UdIwSBuTCBtoAU2QbXrQbbTpVrMswHI4MUq8KHPJyhgZqkg ZcwgZQxCzAJBgNVBAYTAklUMRAwDgYDVQQIEwdGaXJlbnplMRAwDgYDVQQHEwdG axjlbnplmrcwfqydvqqkew5ezwrhbhvzifmucc5bljerma8ga1uecxmiu3zpbhvw cg8xejaqbgnvbamtcurlzgfsdxndqtehmb8gcsqgsib3dqejaryszgvkywx1c0 NBQGRlZGEuY29tggEAMA0GCSqGSIb3DQEBBAUAA4GBACPB5DlNlCaQB5h3Smscyg 4boO4MiQANMK5H6S+zWh72B8Ly/iYy1Rtg8VqKkbR44y2shYoD1Oooax4qFg1LuO1GS La8o1J+UF8urb2cA5P8JsTeqi4JQAB7VXaiLgjGtv3x6dyKVhWcVvEgTC4MjCVU1xFZzS0 4ZTp7xKqf+odh</ds:X509Certificate> </ds:x509data> </ds:keyinfo> </ds:signature> </Assertion> </wsse:security>

18 <wsa:to>http://localhost:9999/soap/documentrepository_provideandregisterdocuments etb</wsa:to> <wsa:messageid>urn:uuid:8a2238b7aa83b35dca </wsa:messageid> <wsa:action>documentrepository_provideandregisterdocumentsetb</wsa:action> </soapenv:header> Messaggio risposta proxy-ws In caso di risposta con esito positivo il modulo proxy risponde con il messaggio proprio del servizio invocato così come nel caso di errori che potremmo definire nativi che sono tornati dagli applicativi dopo i controlli effettuati dal modulo Access Gateway. In caso di errori durante la fase di trattamento del messaggio da parte del modulo proxy questo ritorna il seguente formato di errore: <soapenv:fault xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <faultcode>axis2ns3:203</faultcode> <faultstring>org.apache.synapse.synapseexception: ruoli 'ME' non abilitati per operazione 'READ', documento 'registrystoredquery' e confidentiality code 'NA' (urn:ihe:iti:2007:registrystoredquery).</faultstring> <detail/> </soapenv:fault> Di seguito uno schema degli errori: Cod. Descrizione Errore 201 INVALID_DATE Data dell'asserzione SAML non valida 202 INCOMPATIBLE_ROLES Ruolo utente e/o operazione invocata non censito.(profile.xml) 203 ABILITAZIONE_MEDIATOR L operazione invocata non è consentita 204 REPOSITORY_RETRIEVE_MEDIATOR Repository non trovato N/A 205 OUT_FILTER Errore generico N/A filtraggio risultati 206 ROLE_MEDIATOR Errore generico AG N/A 101 DOCUMENT_TYPE_MEDIATOR Non è possibile stabilire N/A il tipo di documento 102 OPERATION_MEDIATOR Non è possibile stabile N/A il tipo di operazione 104 ROLE_RETRIEVER_COD_FISC_UTENTE Non è possibile estrarre N/A il CF dell utente 105 ROLE_RETRIEVER_COD_FISC_MMG Non è possibile estrarre N/A il CF del MMG 106 ARIT_SERVICES_NOT_STARTED Il client non è avviato correttamente 108 CUSTOM_CLASS_MEDIATOR Errore generico Access Gateway Comportamento Far effettuare nuovamente la login. N/A N/A Avviare nuovamente il Client Tentare nuovamente l invocazione

19 6 Client Legacy Sul fronte territoriale, l architettura proposta si apre all integrazione con il software applicativo installato sulla Postazione di Lavoro (PdL) dell attore MMG/PLS. Il flusso operativo, che chiameremo di pubblicazione, prevede che il MMG/PLS sia dotato di un software di cartella clinica provvisto dei componenti di Add-On e Plug-In, anch essi installati sulla PdL, che gli permettano, rispettivamente: la redazione dei documenti (PS, SSI, prescrizioni farmaceutiche e diagnostiche, ecc.) nel formato HL7 CDA2 e la trasmissione di questi al FSE (cfr. Figura 3). Il flusso operativo di consultazione consentirà la ricezione delle notifiche di disponibilità di documenti, il loro reperimento e l interrogazione del Registry. Client MMG/PLS PlugIn Back End Add-On Repository FSE: Prescrizioni Farmaceutiche e Diagnostiche Cartella clinica Informatizzata MMG/PLS Figura 3 Architettura della PdL

20

Piattaforma STS. Specifiche Tecniche. Versione 1.1

Piattaforma STS. Specifiche Tecniche. Versione 1.1 Piattaforma STS Specifiche Tecniche Versione 1.1 Questo documento contiene informazioni proprietarie e riservate di Dedalus SpA Nessuna parte di questa pubblicazione può essere riprodotta, trasmessa, trascritta,

Dettagli

Logo Cliente o Partner Un modello di sicurezza per servizi bancari!

Logo Cliente o Partner Un modello di sicurezza per servizi bancari! SECurity Logo Cliente o Partner Un modello di sicurezza per servizi bancari! Agenda La società SEC Servizi Presentazione generale Numeri chiave e Clienti Il modello di Sicurezza di SEC Servizi Access Control

Dettagli

Piattaforma. Guida all Integrazione. Descrizione Principali Funzionalità. Versione 1.2 BOZZA

Piattaforma. Guida all Integrazione. Descrizione Principali Funzionalità. Versione 1.2 BOZZA Piattaforma Guida all Integrazione Descrizione Principali Funzionalità Versione 1.2 BOZZA Questo documento contiene informazioni proprietarie e riservate di Dedalus SpA Nessuna parte di questa pubblicazione

Dettagli

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

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

Dettagli

I WorkShop del Tavolo Permanente di Sanità Elettronica

I WorkShop del Tavolo Permanente di Sanità Elettronica I WorkShop del Tavolo Permanente di Sanità Elettronica Infrastruttura nazionale del Fascicolo Sanitario Elettronico (InFSE) L infrastruttura regionale del progetto MEDIR Gianmaria Mancosu gimancosu@regione.sardegna.it

Dettagli

Gestione Richieste Patenti Web

Gestione Richieste Patenti Web >> Specifiche Integrazione Web Services RTI Gestione Richieste Patenti Web Servizio di Sviluppo SVI Versione 1.0-07 Dicembre 2009 Indice dei contenuti 1 GENERALITA... 6 1.1 Lista di distribuzione...6 1.2

Dettagli

INTEGRAZIONE ANAGRAFE DALL APPLICATIVO

INTEGRAZIONE ANAGRAFE DALL APPLICATIVO INTEGRAZIONE ANAGRAFE DALL APPLICATIVO DI CARTELLA MMG/PLS CICOM PROGETTO ESECUTIVO DEFINITIVO Accordo di Programma Quadro "Sviluppo della Società dell'informcazione nella Regione Abruzzo" Atto Integrativo

Dettagli

PROGETTI di E-government Area Sanità

PROGETTI di E-government Area Sanità PROGETTI di E-government Area Sanità Regione del Veneto Fabio Perina 15 dicembre 2004 Medici Di Base Cup IL ROGETTO Distretti Farmacie Repository Reparti Laboratori Sistema Accessi Gestore Eventi Comuni

Dettagli

Sicurezza nei Web Services: Migrazione dell autenticazone di Web Services da ticket di sessione a WS-Security con token SAML

Sicurezza nei Web Services: Migrazione dell autenticazone di Web Services da ticket di sessione a WS-Security con token SAML Master Universitario di II livello in Interoperabilità Per la Pubblica Amministrazione e Le Imprese Sicurezza nei Web Services: Migrazione dell autenticazone di Web Services da ticket di sessione a WS-Security

Dettagli

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

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

Dettagli

REGIONE AUTONOMA DELLA SARDEGNA. Regione Autonoma della Sardegna (MEDIR): la fase di avviamento del sistema

REGIONE AUTONOMA DELLA SARDEGNA. Regione Autonoma della Sardegna (MEDIR): la fase di avviamento del sistema Il Fascicolo Sanitario Elettronico della Il Fascicolo Sanitario Elettronico della Regione Autonoma della Sardegna (MEDIR): la fase di avviamento del sistema Gara Medir Pubblicazione del bando: Agosto Settembre

Dettagli

Mattone 9 Realizzazione del Patient File

Mattone 9 Realizzazione del Patient File Mattone 9 Realizzazione del Patient File Architettura di Cooperazione Roma 19 Giugno 2007 Nolan, Norton Italia Definizione del Fascicolo Sanitario Personale (FaSP) Non qualsiasi raccolta strutturata di

Dettagli

Manuale di Integrazione IdM-RAS

Manuale di Integrazione IdM-RAS IdM-RAS Data: 30/11/09 File: Manuale di integrazione IdM-RAS.doc Versione: Redazione: Sardegna IT IdM-RAS Sommario 1 Introduzione... 3 2 Architettura del sistema... 4 2.1 Service Provider... 4 2.2 Local

Dettagli

Visione Generale. Versione 1.0 del 25/08/2009

Visione Generale. Versione 1.0 del 25/08/2009 Visione Generale Versione 1.0 del 25/08/2009 Sommario 1 Premessa... 4 2 Le componenti applicative... 6 2.1 Porta di dominio... 7 2.2 Infrastrutture per la cooperazione... 9 2.2.1 Registro degli Accordi

Dettagli

REGIONE BASILICATA DIPARTIMENTO INFRASTRUTTURE, OO.PP. E MOBILITA

REGIONE BASILICATA DIPARTIMENTO INFRASTRUTTURE, OO.PP. E MOBILITA REGIONE BASILICATA DIPARTIMENTO INFRASTRUTTURE, OO.PP. E MOBILITA Ufficio Difesa del Suolo di Potenza SISTEMA FEDERATO DI AUTENTICAZIONE Informatizzazione dell iter procedurale e dei controlli relativi

Dettagli

I Servizi dell'architettura Web Services. Tito Flagella tito@link.it Lorenzo Nardi nardi80@gmail.com

I Servizi dell'architettura Web Services. Tito Flagella tito@link.it Lorenzo Nardi nardi80@gmail.com I Servizi dell'architettura Web Services Tito Flagella tito@link.it Lorenzo Nardi nardi80@gmail.com La struttura del messaggio SOAP Un messaggio SOAP consiste di: Envelope, identifica il contenuto del

Dettagli

1 Seminario Operativo Gruppi di Cure Primarie e Unità di Medicina Generale in Piemonte

1 Seminario Operativo Gruppi di Cure Primarie e Unità di Medicina Generale in Piemonte 1 Seminario Operativo Gruppi di Cure Primarie e Unità di Medicina Generale in Piemonte IL SISTEMA INFORMATIVO VISTO DALLA REGIONE PIEMONTE Dott. Domenico Nigro - Direzione regionale Sanità 24 Maggio 2008

Dettagli

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

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

Dettagli

POLITICHE DI SICUREZZA E GESTIONE

POLITICHE DI SICUREZZA E GESTIONE UNIVERSITA DEGLI STUDI DELLA BASILICATA FACOLTÀ DI SCIENZE MATEMATICHE, FISICHE E NATURALI CORSO DI LAUREA SPECIALISTICA IN INFORMATICA TESI DI LAUREA SPECIALISTICA POLITICHE DI SICUREZZA E GESTIONE DELL'IDENTITÀ

Dettagli

Strategie di system integration per l interoperabilità di sistemi eterogenei di Fascicolo Sanitario Elettronico

Strategie di system integration per l interoperabilità di sistemi eterogenei di Fascicolo Sanitario Elettronico Consiglio Nazionale delle Ricerche Istituto di Calcolo e Reti ad Alte Prestazioni Strategie di system integration per l interoperabilità di sistemi eterogenei di Fascicolo Sanitario Elettronico Mario Ciampi

Dettagli

guida: lo stato dell arte Stefano Micocci CUP 2000

guida: lo stato dell arte Stefano Micocci CUP 2000 Gli standard e le linee guida: lo stato dell arte Stefano Micocci CUP 2000 Di cosa parleremo Le reti in sanità: come stanno evolvendo in ambito regionale, nazionale ed europeo Il ruolo degli standard nel

Dettagli

Il Sistema Informativo Sanitario Territoriale della Puglia

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

Dettagli

Aspetti architetturali e tecnologici per l attuazione dell e-government a livello locale

Aspetti architetturali e tecnologici per l attuazione dell e-government a livello locale Aspetti architetturali e tecnologici per l attuazione dell e-government a livello locale Alessandro Osnaghi Università di Pavia E-government e Information Society L e-government è un capitolo della Società

Dettagli

Processi di business sovra-regionali relativi ai sistemi regionali di FSE. Versione 1.0 24 Giugno 2014

Processi di business sovra-regionali relativi ai sistemi regionali di FSE. Versione 1.0 24 Giugno 2014 Processi di business sovra-regionali relativi ai sistemi regionali di FSE Versione 1.0 24 Giugno 2014 1 Indice Indice... 2 Indice delle figure... 3 Indice delle tabelle... 4 Obiettivi del documento...

Dettagli

Gestione XML della Porta di Dominio OpenSPCoop

Gestione XML della Porta di Dominio OpenSPCoop i Gestione XML della Porta di Dominio ii Copyright 2005-2011 Link.it srl iii Indice 1 Introduzione 1 2 Hello World! 2 3 Configurazione XML della Porta di Dominio 5 3.1 Soggetto SPCoop...................................................

Dettagli

Guida Utente della PddConsole. Guida Utente della PddConsole

Guida Utente della PddConsole. Guida Utente della PddConsole Guida Utente della PddConsole i Guida Utente della PddConsole Guida Utente della PddConsole ii Copyright 2005-2014 Link.it srl Guida Utente della PddConsole iii Indice 1 Introduzione 1 2 I protocolli di

Dettagli

Guida Utente della PddConsole. Guida Utente della PddConsole

Guida Utente della PddConsole. Guida Utente della PddConsole Guida Utente della PddConsole i Guida Utente della PddConsole Guida Utente della PddConsole ii Copyright 2005-2015 Link.it srl Guida Utente della PddConsole iii Indice 1 Introduzione 1 2 I protocolli di

Dettagli

Ministero del Lavoro e delle Politiche Sociali

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

Dettagli

Il modello ICAR per la gestione dell Identit

Il modello ICAR per la gestione dell Identit Il modello ICAR per la gestione dell Identit Identità Digitale Federata Architettura, opportunità e prospettive di convergenza Forum PA 2008, Roma 15 maggio 2008 Massimiliano Pianciamore massimiliano.pianciamore@cefriel.it

Dettagli

Attori nella Federazione e Profili SAML. Massimiliano Pianciamore massimiliano.pianciamore@cefriel.it

Attori nella Federazione e Profili SAML. Massimiliano Pianciamore massimiliano.pianciamore@cefriel.it Attori nella Federazione e Profili SAML Massimiliano Pianciamore Agenda Ruoli e Attori in una infrastruttura federata Service Provider Identity Provider Attribute Authorities Lo standard SAML 2.0 Asserzioni

Dettagli

Il Fascicolo Sanitario Elettronico nel progetto Rete dei Medici

Il Fascicolo Sanitario Elettronico nel progetto Rete dei Medici Il Fascicolo Sanitario Elettronico nel progetto Rete dei Medici ForumPA 2007: Innovazione & Salute Roma, 21 maggio 2007 Katia Colantonio Responsabile Sanità Elettronica Innovazione Italia S.p.A. Agenda

Dettagli

Definizione delle interfacce di colloquio fra le componenti

Definizione delle interfacce di colloquio fra le componenti Definizione delle interfacce di colloquio fra le componenti (integrazione documento) 1 DOCUMENTO:. 1.2 Emesso da: EMISSIONE VERIFICA APPROVAZIONE Nome firma Verificato da: Approvato da: Area ISIC LISTA

Dettagli

Tecnopolis CSATA s.c.r.l. APQ in materia di e-government e Società dell Informazione nella Regione Puglia. Rete dei Medici di Medicina Generale

Tecnopolis CSATA s.c.r.l. APQ in materia di e-government e Società dell Informazione nella Regione Puglia. Rete dei Medici di Medicina Generale BANDO ACQUISIZIONI Servizi Informatici ALLEGATO 6 Capitolato Tecnico Allegato 6: Capitolato Tecnico Pag. 1 1 INTRODUZIONE... 5 2 DOCUMENTAZIONE DI RIFERIMENTO...6 3 OGGETTO DELLA FORNITURA... 7 4 LOTTO

Dettagli

La Gestione della Immagini all'interno dei Sistemi Informativi Sanitari

La Gestione della Immagini all'interno dei Sistemi Informativi Sanitari Appuntamenti a Fisica Gestione delle Immagini in Medicina La Gestione della Immagini all'interno dei Sistemi Informativi Sanitari Andrea Bo Sistemi Informativi A.O. Ordine Mauriziano Il Sistema Informativo

Dettagli

Manuale Gestione di OpenSPCoop 1.4 i. Manuale Gestione di OpenSPCoop 1.4

Manuale Gestione di OpenSPCoop 1.4 i. Manuale Gestione di OpenSPCoop 1.4 i Manuale Gestione di OpenSPCoop 1.4 ii Copyright 2005-2011 Link.it srl iii Indice 1 Introduzione 1 2 Prerequisiti per la Configurazione della Porta di Dominio 1 2.1 Verifica dell applicazione di gestione

Dettagli

CeBAS. Centrale Bandi e Avvisi Pubblici Regionali (DGR n. 1556 del 11.09.2009)

CeBAS. Centrale Bandi e Avvisi Pubblici Regionali (DGR n. 1556 del 11.09.2009) CeBAS Centrale Bandi e Avvisi Pubblici Regionali (DGR n. 1556 del 11.09.2009) Introduzione Il progetto CEBAS: la finalità è di migliorare l efficienza operativa interna dell Ente rispondere alle aspettative

Dettagli

Servizi di hosting offerti dall'area Servizi ICT Integrazione con l'anagrafica Unica di Ateneo. Area Servizi ICT

Servizi di hosting offerti dall'area Servizi ICT Integrazione con l'anagrafica Unica di Ateneo. Area Servizi ICT Area Servizi ICT Servizi hosting di Ateneo - Integrazione con l'anagrafica Unica di Ateneo Versione 1.1 http://hosting.polimi.it Servizi di hosting offerti dall'area Servizi ICT Integrazione con l'anagrafica

Dettagli

ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO

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

Dettagli

Il consenso nel progetto SOLE

Il consenso nel progetto SOLE Il consenso nel progetto Alessia Orsi Regione Emilia-Romagna Direzione Generale Sanità e Politiche Sociali Roma, 13 dicembre 2010 1 2 3 4 5 Circolare regionale 6/2009 Consenso e FSE Flusso base Architettura

Dettagli

Architettura Tecnica i. Architettura Tecnica

Architettura Tecnica i. Architettura Tecnica i Architettura Tecnica ii Copyright 2005-2011 Link.it s.r.l. iii Indice 1 Scopo del documento 1 1.1 Abbreviazioni..................................................... 1 2 Overview 1 2.1 La PdD........................................................

Dettagli

[TS-CNS-INFRA] Gestione del ciclo di vita della Tessera sanitaria e della Carta nazionale dei servizi (TS-CNS)

[TS-CNS-INFRA] Gestione del ciclo di vita della Tessera sanitaria e della Carta nazionale dei servizi (TS-CNS) Progetto cofinanziato dall Unione Europea Fondo Europeo di Sviluppo Regionale POR FESR Sardegna 2007-2013 [TS-CNS-INFRA] Gestione del ciclo di vita della Tessera sanitaria e della Carta nazionale dei servizi

Dettagli

ALLEGATO 1.1 CONTESTO DI RIFERIMENTO E PRINCIPALI EVOLUZIONI

ALLEGATO 1.1 CONTESTO DI RIFERIMENTO E PRINCIPALI EVOLUZIONI ALLEGATO 1.1 CONTESTO DI RIFERIMENTO E PRINCIPALI EVOLUZIONI Pagina 1 di 48 INDICE 1 SISTEMI INFORMATIVI PER LA SANITÀ... 3 1.1 Visione storica e principi di funzionamento... 3 1.2 I processi sanitari

Dettagli

ALLEGATO 1.1 CONTESTO DI RIFERIMENTO E PRINCIPALI EVOLUZIONI

ALLEGATO 1.1 CONTESTO DI RIFERIMENTO E PRINCIPALI EVOLUZIONI ALLEGATO 1.1 CONTESTO DI RIFERIMENTO E PRINCIPALI EVOLUZIONI Allegato 1.1 Contesto di riferimento e principali evoluzioni Pagina 1 di 138 INDICE 1 SISTEMI INFORMATIVI PER LA SANITÀ... 3 1.1 PRINCIPI E

Dettagli

La sicurezza nel Progetto CRS-SISS Fulvio Barbarito Milano, 20 ottobre 2005

La sicurezza nel Progetto CRS-SISS Fulvio Barbarito Milano, 20 ottobre 2005 Carta Regionale dei Servizi Sistema Informativo Socio Sanitario La sicurezza nel Progetto CRS-SISS Fulvio Barbarito Milano, 20 ottobre 2005 2 Agenda Le finalità del Progetto CRS-SISS I numeri del Progetto

Dettagli

Verso la Cartella Clinica Elettronica: standard internazionali e piattaforme aperte in Informatica Sanitaria

Verso la Cartella Clinica Elettronica: standard internazionali e piattaforme aperte in Informatica Sanitaria 2 Ottobre 2008 Verso la Cartella Clinica Elettronica: standard internazionali e piattaforme aperte in Informatica Sanitaria Ettore Simonelli Dir. Prodotti Area Sanità Engineering Agenda Sezione 1 Sezione

Dettagli

Web Service medra per la gestione DOI

Web Service medra per la gestione DOI Web Service medra per la gestione DOI Versione documento: 1.0 Data creazione: 23 dicembre 2010 Data ultima modifica: 14 maggio 2012 1. Introduzione...2 2. medra WS...2 2.1. Operation UPLOAD...2 2.2. Operation

Dettagli

Guida Utente della PddConsole. Guida Utente della PddConsole

Guida Utente della PddConsole. Guida Utente della PddConsole Guida Utente della PddConsole i Guida Utente della PddConsole Guida Utente della PddConsole ii Copyright 2005-2014 Link.it srl Guida Utente della PddConsole iii Indice 1 Introduzione 1 2 Prerequisiti per

Dettagli

QUALIFICAZIONE DELLA PORTA DI DOMINIO

QUALIFICAZIONE DELLA PORTA DI DOMINIO QUALIFICAZIONE DELLA PORTA DI DOMINIO IN MODALITÀ PROVVISORIA Versione 1.0 Qualificazione della Porta di INDICE 1. PROCESSO DI QUALIFICAZIONE DELLA PORTA DI DOMINIO IN MODALITÀ PROVVISORIA 3 2. DESCRIZIONE

Dettagli

Presentazione di Cedac Software

Presentazione di Cedac Software Agenda Presentazione di Cedac Software SOA ed ESB Analisi di un caso studio Esempi Q&A Presentazione di Cedac Software 1 2 Presentazione di Cedac Software S.r.l. Divisione Software Azienda nata nel 1994

Dettagli

FSE in Liguria: Conto Corrente Salute

FSE in Liguria: Conto Corrente Salute FSE in Liguria: Conto Corrente Salute Maria Franca Tomassi Regione Liguria - Settore Sistemi Informativi e Telematici Cristina Ulivi ASL4 Chiavarese - Settore Analisi e Progettazione Sistemi Informativi

Dettagli

FSE Fascicolo Sanitario Elettronico

FSE Fascicolo Sanitario Elettronico FSE Fascicolo Sanitario Elettronico Pagina 1 di 19 STATO DELLE VARIAZIONI VERSIONE PARAGRAFO O DESCRIZIONE DELLA VARIAZIONE PAGINA 1 Tutto il documento Versione iniziale del documento Pagina 2 di 19 Sommario

Dettagli

Allegato alla deliberazione n. 34/2006 Regole Tecniche per la definizione del profilo di busta crittografica per la firma digitale in linguaggio XML

Allegato alla deliberazione n. 34/2006 Regole Tecniche per la definizione del profilo di busta crittografica per la firma digitale in linguaggio XML Allegato alla deliberazione n. 34/2006 REGOLE TECNICHE PER LA DEFINIZIONE DEL PROFILO DI BUSTA CRITTOGRAFICA PER LA FIRMA DIGITALE IN LINGUAGGIO XML www.cnipa.gov.it DB/CNI/2006_034 Sommario 1 Definizioni...3

Dettagli

REGOLAMENTO. RECANTE LE REGOLE TECNICHE (articolo 4, comma 2, DPCM 24 ottobre 2014)

REGOLAMENTO. RECANTE LE REGOLE TECNICHE (articolo 4, comma 2, DPCM 24 ottobre 2014) REGOLAMENTO RECANTE LE REGOLE TECNICHE (articolo 4, comma 2, DPCM 24 ottobre 2014) Visto il decreto legislativo 7 marzo 2005, n. 82, e successive modificazioni, recante il Codice dell'amministrazione digitale,

Dettagli

CARTA REGIONALE DEI SERVIZI SISTEMA INFORMATIVO SOCIO- SANITARIO DELLA REGIONE LOMBARDIA

CARTA REGIONALE DEI SERVIZI SISTEMA INFORMATIVO SOCIO- SANITARIO DELLA REGIONE LOMBARDIA CARTA REGIONALE DEI SERVIZI SISTEMA INFORMATIVO SOCIO- SANITARIO DELLA REGIONE LOMBARDIA IL CLIENTE Regione Lombardia, attraverso la società Lombardia Informatica. IL PROGETTO Fin dal 1998 la Regione Lombardia

Dettagli

MODELLO DI GESTIONE FEDERATA DELLE IDENTITÀ DIGITALI (GFID)

MODELLO DI GESTIONE FEDERATA DELLE IDENTITÀ DIGITALI (GFID) MODELLO DI GESTIONE FEDERATA DELLE IDENTITÀ DIGITALI (GFID) Versione 1.5 INDICE 1. PREFAZIONE...5 1.1. Autori... 5 1.2. Modifiche Documento... 5 1.3. Riferimenti... 6 1.4. Acronimi e Definizioni... 6 2.

Dettagli

Soluzioni di cooperazione applicativa nell integrazione del sistema informativo dell Azienda Ospedaliero Universitaria di Careggi

Soluzioni di cooperazione applicativa nell integrazione del sistema informativo dell Azienda Ospedaliero Universitaria di Careggi 1/12 Libera il tuo computer con il software libero Linux day a Firenze 23 ottobre 2010 coordina Paolo Campigli - Consiglio Q4 - Firenze Soluzioni di cooperazione applicativa nell integrazione del sistema

Dettagli

Fascicolo Sanitario Elettronico

Fascicolo Sanitario Elettronico Consiglio Nazionale delle Ricerche Fascicolo Sanitario Elettronico «La roadmap e l accelerazione in atto» Ing. Stefano van der Byl Ing. Mario Ciampi Fascicolo Sanitario Elettronico 1/2 «Il FSE è l insieme

Dettagli

Progetto SIRPE De-materializzazione delle prescrizioni. Cartelle Cliniche MMG / PLS. Versione 3.0

Progetto SIRPE De-materializzazione delle prescrizioni. Cartelle Cliniche MMG / PLS. Versione 3.0 MMG / PLS Pag. 1 di 21 Progetto SIRPE De-materializzazione Cartelle Cliniche MMG / PLS Versione 3.0 MMG / PLS INDICE Pag. 2 di 21 1 Introduzione 5 1.1 Scopo del documento 5 1.2 Riferimenti 5 2 Inquadramento

Dettagli

Manuale gestione Porta di Dominio OpenSPCoop 1.1

Manuale gestione Porta di Dominio OpenSPCoop 1.1 i Manuale gestione Porta di Dominio ii Copyright 2005-2008 Link.it srl Questo documento contiene informazioni di proprietà riservata, protette da copyright. Tutti i diritti sono riservati. Non è permesso

Dettagli

Attuazione interventi per la dematerializzazione delle prescrizioni farmaceutiche e specialistiche

Attuazione interventi per la dematerializzazione delle prescrizioni farmaceutiche e specialistiche Progetto: Attuazione interventi per la dematerializzazione delle prescrizioni farmaceutiche e specialistiche Linea di attività: Interventi per lo sviluppo dei sistemi e per l erogazione dei servizi di

Dettagli

La rete SOLE ed il Fascicolo Sanitario Elettronico: realizzazione dell interoperabilità nella Regione E-R

La rete SOLE ed il Fascicolo Sanitario Elettronico: realizzazione dell interoperabilità nella Regione E-R La rete SOLE ed il Fascicolo Sanitario Elettronico: realizzazione dell interoperabilità nella Regione E-R ANTILOPE SUMMIT REGIONALE SULL INTEROPERABILITA Treviso 18 Giugno 2014 Stefano Micocci - Cup2000

Dettagli

DECRETO N. 152 DEL 24.12.2014

DECRETO N. 152 DEL 24.12.2014 Regione Campania Commissario ad acta per la prosecuzione del Piano di rientro del settore sanitario (Deliberazione Consiglio dei Ministri 23/4/2010) DECRETO N. 152 DEL 24.12.2014 OGGETTO : APPROVAZIONE

Dettagli

Elementi di Sicurezza e Privatezza Lezione 18 Autenticazione: Single Sign On

Elementi di Sicurezza e Privatezza Lezione 18 Autenticazione: Single Sign On Elementi di Sicurezza e Privatezza Lezione 18 Autenticazione: Single Sign On Chiara Braghin chiara.braghin@unimi.it Lab 8 Visti i problemi con la macchina virtuale e la rete, l assignment è sospeso 1 Autenticazione

Dettagli

Sistema pubblico di cooperazione: SERVIZI DI SICUREZZA

Sistema pubblico di cooperazione: SERVIZI DI SICUREZZA Sistema Pubblico di Connettività e Cooperazione Sistema pubblico di cooperazione: SERVIZI DI SICUREZZA Versione 1.0 INDICE 1. MODIFICHE DOCUMENTO... 4 2. OBIETTIVI E CONTESTO DI RIFERIMENTO...5 2.1. Scopi

Dettagli

Analisi ad alto livello

Analisi ad alto livello I.T.B. Istituto di Tecnologie Biomediche Unità di Sanità Elettronica - Roma Mariangela Contenti, Gregorio Mercurio, Gianfranco Misuriello, Fabrizio L. Ricci, Angelo Rossi Mori, Luca D. Serbanati Analisi

Dettagli

L esperienza di integrazione di Santer:

L esperienza di integrazione di Santer: gg.mm.aa L esperienza di integrazione di Santer: un caso concreto Massimo Caprino Santer Reply Contesto di integrazione SIO Esperienza di integrazione ospedaliera, sviluppata in Regione Lombardia nell

Dettagli

LBINT. http://www.liveboxcloud.com

LBINT. http://www.liveboxcloud.com 2014 LBINT http://www.liveboxcloud.com LiveBox Srl non rilascia dichiarazioni o garanzie in merito al contenuto o uso di questa documentazione e declina qualsiasi garanzia espressa o implicita di commerciabilità

Dettagli

REGIONE AUTONOMA DELLA SARDEGNA. Progetto SITR - IDT

REGIONE AUTONOMA DELLA SARDEGNA. Progetto SITR - IDT DELLA SARDEGNA Progetto SITR - IDT Obiettivi del progetto SITR Scopo dell iniziativa è: realizzare un ambiente nel quale gli attori possano cooperare tra loro ed interagire con la tecnologia alfine di

Dettagli

SISS IL SISTEMA AL SERVIZIO DELLA SANITÀ AO DESENZANO DEL GARDA

SISS IL SISTEMA AL SERVIZIO DELLA SANITÀ AO DESENZANO DEL GARDA SISS IL SISTEMA AL SERVIZIO DELLA SANITÀ AO DESENZANO DEL GARDA Sommario Introduzione Le finalità del progetto CRS-SISS e il ruolo di Regione Lombardia Aspetti tecnico-organizzativi del Progetto Servizi

Dettagli

Integrazione di Service Provider e Identity Provider SiRAC e INF3

Integrazione di Service Provider e Identity Provider SiRAC e INF3 Integrazione di Service Provider e Identity Provider SiRAC e INF3 SOMMARIO 1. Introduzione... 4 1.1. Contenuti del Documento... 4 1.2. Distribuzione... 5 1.3. Acronimi... 5 2. Integrazione di Service Provider...

Dettagli

POR Calabria FSE 2007/2013 Asse II Occupabilità Obiettivo operativo D1

POR Calabria FSE 2007/2013 Asse II Occupabilità Obiettivo operativo D1 Allegato n. 2 al Capitolato speciale d appalto. ENTE PUBBLICO ECONOMICO STRUMENTALE DELLA REGIONE CALABRIA POR Calabria FSE 2007/2013 Asse II Occupabilità Obiettivo operativo D1 Procedura aperta sotto

Dettagli

Servizi Anagrafe Assistiti per MMG/PLS

Servizi Anagrafe Assistiti per MMG/PLS Specifiche di Test Servizi Anagrafe Assistiti per MMG/PLS Il presente documento intende fornire le specifiche di test per il colloquio fra l Anagrafe Assistiti regionale e i sistemi software di cartella

Dettagli

Sistema pubblico di cooperazione: SERVIZI DI SICUREZZA. Versione 1.1

Sistema pubblico di cooperazione: SERVIZI DI SICUREZZA. Versione 1.1 Sistema pubblico di cooperazione: SERVIZI DI SICUREZZA Versione 1.1 INDICE 1. MODIFICHE DOCUMENTO... 4 2. OBIETTIVI E CONTESTO DI RIFERIMENTO... 5 2.1. Scopi del documento... 6 2.2. Note di lettura del

Dettagli

IL PROGETTO AMPERSA. Azienda Provinciale per i Servizi Sanitari di Trento APSS: ORGANIZZAZIONE E OBIETTIVI

IL PROGETTO AMPERSA. Azienda Provinciale per i Servizi Sanitari di Trento APSS: ORGANIZZAZIONE E OBIETTIVI IL PROGETTO AMPERSA Azienda Provinciale per i Servizi Sanitari di Trento Cristiana Armaroli,Andrea Vielmetti, Ettore Turra APSS - Trento Nell ambito delle Aziende Sanitarie Locali il progetto AMPERSA relativo

Dettagli

L informatizzazione in ambiente sanitario: prospettive attuali e future

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

Dettagli

CGM MEDIR Pagina 1 di 29

CGM MEDIR Pagina 1 di 29 GUIDA OPERATIVA CGM MEDIR Pagina 1 di 29 INDICE 1 INSTALLAZIONE E CONFIGURAZIONE... 3 1.1 Verifiche preliminari... 3 1.2 Requisiti Minimi... 4 1.3 Procedure di Installazione e Configurazione... 5 1.3.1

Dettagli

SPECIFICHE TECNICHE INTEGRAZIONE SERVIZI MUDE

SPECIFICHE TECNICHE INTEGRAZIONE SERVIZI MUDE Pag. 1 di 11 VERIFICHE E APPROVAZIONI VERSIONE REDAZIONE CONTROLLO AUTORIZZAZIONE APPROVAZIONE EMISSIONE NOME DATA NOME DATA NOME DATA V01 Mauro Pavese 17/05/12 Mauro Pavese 29/11/2012 STATO DELLE VARIAZIONI

Dettagli

Modelli di Triage, strumenti informatici e standardizzazione

Modelli di Triage, strumenti informatici e standardizzazione Modelli di Triage, strumenti informatici e standardizzazione Giorgio Moretti Stefano Ceccherini Roma 11 giugno 2010 Informatizzazione dei Pronto Soccorso in Italia La diffusione dell ICT in ambito di Pronto

Dettagli

Informatica e Database. Roma, 19 Aprile 2011 Feruglio Ruggero

Informatica e Database. Roma, 19 Aprile 2011 Feruglio Ruggero Informatica e Database Roma, 19 Aprile 2011 Feruglio Ruggero In che fase del progetto è opportuno designare l amministratore di sistema ed iniziare la collaborazione? Sistemi informativi Definizione e

Dettagli

INTERFACCIAMENTO CON GLI APPLICATIVI DELLA RETE MMG

INTERFACCIAMENTO CON GLI APPLICATIVI DELLA RETE MMG PIANO DI TEST DEL MODULO APPLICATIVO DI INTERFACCIAMENTO CON GLI APPLICATIVI DELLA RETE MMG PROGETTO ESECUTIVO DEFINITIVO Accordo di Programma Quadro "Sviluppo della Società dell'informazione nella Regione

Dettagli

PROCEDURA DI ACCREDITAMENTO

PROCEDURA DI ACCREDITAMENTO Procedura di accreditamento Solution Partner CRS PROCEDURA DI ACCREDITAMENTO per l iscrizione all Albo dei Solution Partner CRS in quanto produttori / distributori di prodotti CRS Ready in ambito Pubblica

Dettagli

Single Sign On sul web

Single Sign On sul web Single Sign On sul web Abstract Un Sigle Sign On (SSO) è un sistema di autenticazione centralizzata che consente a un utente di fornire le proprie credenziali una sola volta e di accedere a molteplici

Dettagli

Autenticazione con LDAP

Autenticazione con LDAP Autenticazione con LDAP Uso del protocollo LDAP per l autenticazione in rete ing. Walter Vendraminetto - vendra@sci.univr.it 07.06.2006 Directory Il concetto di Directory è essenzialmente quello di catalogo

Dettagli

Perchè utilizzare un'autorità di certificazione

Perchè utilizzare un'autorità di certificazione Una generica autorità di certificazione (Certification Authority o più brevemente CA) è costituita principalmente attorno ad un pacchetto software che memorizza i certificati, contenenti le chiavi pubbliche

Dettagli

System & Network Integrator. Rap 3 : suite di Identity & Access Management

System & Network Integrator. Rap 3 : suite di Identity & Access Management System & Network Integrator Rap 3 : suite di Identity & Access Management Agenda Contesto Legislativo per i progetti IAM Impatto di una soluzione IAM in azienda La soluzione di SysNet: Rap 3 I moduli l

Dettagli

SIST Sistema Informativo Sanitario Territoriale. Manuale utente. Medici Specialisti

SIST Sistema Informativo Sanitario Territoriale. Manuale utente. Medici Specialisti SIST Sistema Informativo Sanitario Territoriale Manuale utente Medici Specialisti Versione 1.1 21 Novembre 2014 Indice dei Contenuti INDICE DEI CONTENUTI... 2 1. INTRODUZIONE... 3 2. IL SISTEMA INFORMATIVO

Dettagli

DESCRIZIONE DELLE SPECIFICHE DI

DESCRIZIONE DELLE SPECIFICHE DI DESCRIZIONE DELLE SPECIFICHE DI SICUREZZA NEGLI ACCORDI DI SERVIZIO Versione 1.1 INDICE 1. PREFAZIONE...3 1.1. Autori... 3 1.2. Modifiche Documento... 3 1.3. Riferimenti... 4 1.4. Acronimi e Definizioni...

Dettagli

Introduzione ad Active Directory. Orazio Battaglia

Introduzione ad Active Directory. Orazio Battaglia Introduzione ad Active Directory Orazio Battaglia Introduzione al DNS Il DNS (Domain Name System) è un sistema utilizzato per la risoluzione dei nomi dei nodi della rete (host) in indirizzi IP e viceversa.

Dettagli

I Servizi dell'architettura Web Services. Tito Flagella tito@link.it Lorenzo Nardi nardi80@gmail.com

I Servizi dell'architettura Web Services. Tito Flagella tito@link.it Lorenzo Nardi nardi80@gmail.com I Servizi dell'architettura Web Services Tito Flagella tito@link.it Lorenzo Nardi nardi80@gmail.com La struttura del messaggio SOAP Un messaggio SOAP consiste di: Envelope, identifica il contenuto del

Dettagli

VENERE MEDIR (GUIDA OPERATIVA)

VENERE MEDIR (GUIDA OPERATIVA) VENERE MEDIR (GUIDA OPERATIVA) INDICE 1 INSTALLAZIONE E CONFIGURAZIONE... 3 1.1 Verifiche preliminari... 3 1.2 Requisiti Minimi... 4 1.3 Procedure di Installazione e Configurazione... 5 1.3.1 Installazione

Dettagli

MINISTERO DELLA GIUSTIZIA Notifiche telematiche degli atti per il settore penale presso gli uffici giudiziari

MINISTERO DELLA GIUSTIZIA Notifiche telematiche degli atti per il settore penale presso gli uffici giudiziari MINISTERO DELLA GIUSTIZIA Notifiche telematiche degli atti per il settore penale presso gli uffici giudiziari MANUALE UTENTE Versione SNT: 1.4.4 Versione 2.2 09 Febbraio 2015 Indice 1. Generalità... 4

Dettagli

Elementi di Sicurezza e Privatezza Lezione 18 Autenticazione: Single Sign On

Elementi di Sicurezza e Privatezza Lezione 18 Autenticazione: Single Sign On Elementi di Sicurezza e Privatezza Lezione 18 Autenticazione: Single Sign On Chiara Braghin chiara.braghin@unimi.it! Autenticazione cont d (1) Dalle lezioni precedenti: w L autenticazione è un prerequisito

Dettagli

PAGAMENTI TELEMATICI DELLA GIUSTIZIA

PAGAMENTI TELEMATICI DELLA GIUSTIZIA SISTEMI INFORMATIVI AUTOMATIZZATI PER LA GIUSTIZIA CIVILE E PROCESSO TELEMATICO PAGAMENTI TELEMATICI DELLA GIUSTIZIA SPECIFICHE VERSIONE 5.0 STATO:VERIFICATO [Pagina Vuota] PAGAMENTI TELEMATICI DELLA GIUSTIZIA

Dettagli

Versione 31 marzo 2014. Linee guida per la presentazione dei piani di progetto regionali per il FSE

Versione 31 marzo 2014. Linee guida per la presentazione dei piani di progetto regionali per il FSE Linee guida per la presentazione dei piani di progetto regionali per il FSE 1 Premessa L articolo 12 del D.L. 18 ottobre 2012, n. 179, recante Ulteriori misure urgenti per la crescita del Paese (convertito,

Dettagli

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

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

Dettagli

Progetto Conto Corrente Salute - Regione Liguria

Progetto Conto Corrente Salute - Regione Liguria 1 Argomenti 2 Descrizione Realizzare un fascicolo sanitario elettronico che renda disponibili immediatamente servizi: Gli obiettivi del progetto Per: Cittadini Operatori sanitari Istituzioni locali, regionali,

Dettagli

HealthSOAF Health Service Oriented Architecture Framework

HealthSOAF Health Service Oriented Architecture Framework HealthSOAF Health Service Oriented Architecture Framework Maria Carmela Groccia, de-health Lab, DIMEG Rosita Guido, Domenico Conforti Università della Calabria Maurizio Rizzo, Giampaolo Sammarco AlmavivA

Dettagli

Consolidamento e sviluppo CART

Consolidamento e sviluppo CART Nome del progetto Consolidamento e sviluppo CART Acronimo del progetto TOSCART Documento Manuale interfaccia monitoraggio Acronimo del documento TOSCART-TEC-INTWEB-PMC Stato del documento Definitivo Versione

Dettagli

4 Congresso nazionale Società Italiana Telemedicina e sanità elettronica

4 Congresso nazionale Società Italiana Telemedicina e sanità elettronica 4 Congresso nazionale Società Italiana Telemedicina e sanità elettronica Telemedicina: una sfida per la sostenibilità del sistema sanitario Integrazione dei servizi di Telemedicina con il Fascicolo Sanitario

Dettagli

! Evento organizzato con il supporto e la collaborazione del progetto Mattone Internazionale COMUNICATO STAMPA

! Evento organizzato con il supporto e la collaborazione del progetto Mattone Internazionale COMUNICATO STAMPA Evento organizzato con il supporto e la collaborazione del progetto Mattone Internazionale COMUNICATO STAMPA Nasce la rete della Medicina Generale per la condivisione dei dati assistenziali: Netmedica

Dettagli