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

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

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

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

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

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

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

ASPETTI DI SICUREZZA NELLA

ASPETTI DI SICUREZZA NELLA ASPETTI DI SICUREZZA NELLA COOPERAZIONE TRA I SERVIZI Versione 1.0 INDICE 1. PREFAZIONE...3 1.1. Autori... 3 1.2. Modifiche Documento... 3 1.3. Riferimenti... 4 1.4. Acronimi e Definizioni... 4 2. OBIETTIVI

Dettagli

Esperienze di utilizzo dello standard HL7 Regione Emilia Romagna

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

Dettagli

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

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

SIRV-INTEROP Sicurezza basata sui ruoli

SIRV-INTEROP Sicurezza basata sui ruoli SIRV-INTEROP (UML-A8.2-0) 06 ottobre 2004 Approvazioni Il presente documento è stato approvato da: UML-A8.2-0 18/11/05 16.25 2 Storia delle Modifiche Versione Data Descrizione Riferimenti Numero Titolo

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Arsenàl.IT. Centro Veneto Ricerca e Innovazione per la Sanità Digitale. Documento Confidenziale pag. 1 di 18. Arsenàl.IT

Arsenàl.IT. Centro Veneto Ricerca e Innovazione per la Sanità Digitale. Documento Confidenziale pag. 1 di 18. Arsenàl.IT GDL-O Fornitori/Labelling Linee guida e specifiche tecniche per la gestione delle credenziali e dei profili degli utenti da parte dei fornitori di cartella dei medici prescrittori Centro Veneto Ricerca

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

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

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

Progetto Evoluzione e interoperabilità tecnologica del Fascicolo Sanitario Elettronico. InFSE:

Progetto Evoluzione e interoperabilità tecnologica del Fascicolo Sanitario Elettronico. InFSE: Presidenza del Consiglio dei Ministri Dipartimento per la Digitalizzazione della Pubblica Amministrazione e l Innovazione Tecnologica Consiglio Nazionale delle Ricerche Dipartimento di Ingegneria, ICT

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

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

AREA SERVIZI ICT. Servizi di hosting offerti dall'area Servizi ICT. Integrazione con l'anagrafica Unica di Ateneo. hosting.polimi.

AREA SERVIZI ICT. Servizi di hosting offerti dall'area Servizi ICT. Integrazione con l'anagrafica Unica di Ateneo. hosting.polimi. AREA SERVIZI ICT Servizi di hosting offerti dall'area Servizi ICT Integrazione con l'anagrafica Unica di Ateneo hosting.polimi.it Indice 1. Anagrafica unica di Ateneo... 4 1.1. Introduzione all anagrafica

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

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

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

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

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

La centralità del paziente tra MMG Distretto e Ospedale: il Fascicolo Sanitario Elettronico. Daniele Donato Azienda ULSS 16 - Padova

La centralità del paziente tra MMG Distretto e Ospedale: il Fascicolo Sanitario Elettronico. Daniele Donato Azienda ULSS 16 - Padova La centralità del paziente tra MMG Distretto e Ospedale: il Fascicolo Sanitario Elettronico Daniele Donato Azienda ULSS 16 - Padova Premesse 2010 Centralità del paziente Continuità delle cure Appropriatezza

Dettagli

SVI08-0003 Nuovo Sistema Revisioni

SVI08-0003 Nuovo Sistema Revisioni >> Nuovo Sistema Revisioni - Specifiche Web Services Officina SVI08-0003 Nuovo Sistema Revisioni Servizio di Sviluppo Software RTI Indice dei contenuti 1 GENERALITA... 8 1.1 Lista di distribuzione...8

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

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

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

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

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

Progettazione e realizzazione di servizi per l interoperabilità del Fascicolo Sanitario Elettronico mediante l infrastruttura InFSE

Progettazione e realizzazione di servizi per l interoperabilità del Fascicolo Sanitario Elettronico mediante l infrastruttura InFSE Consiglio Nazionale delle Ricerche Istituto di Calcolo e Reti ad Alte Prestazioni Progettazione e realizzazione di servizi per l interoperabilità del Fascicolo Sanitario Elettronico mediante l infrastruttura

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

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

Framework di sicurezza della piattaforma OCP (Identity & Access Management)

Framework di sicurezza della piattaforma OCP (Identity & Access Management) Smart Cities and Communities and Social Innovation Bando MIUR D.D. 91/Ric. del 5 luglio 2012 Framework di sicurezza della piattaforma OCP (Identity & Access Management) AAI: Il problema che OCP ha affrontato

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

[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

INVESTIMENTI ICT & PDTA REGIONE EMILIA ROMAGNA SERVIZIO SST GANDOLFO MISERENDINO 22-10-2015

INVESTIMENTI ICT & PDTA REGIONE EMILIA ROMAGNA SERVIZIO SST GANDOLFO MISERENDINO 22-10-2015 INVESTIMENTI ICT & PDTA REGIONE EMILIA ROMAGNA SERVIZIO SST GANDOLFO MISERENDINO 22-10-2015 DEFINIZIONE LA DEFINIZIONE REDATTA A PARTIRE DA QUELLA CONTENUTA NEL PIANO NAZIONALE PER IL GOVERNO DELLE LISTE

Dettagli

Centro Nazionale per l Informatica nella Pubblica Amministrazione

Centro Nazionale per l Informatica nella Pubblica Amministrazione Centro Nazionale per l Informatica nella Pubblica Amministrazione Procedura ristretta n. 2/2006 per l affidamento della progettazione, realizzazione e gestione di componenti di cooperazione applicativa,

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

SERVICE BROWSER. Versione 1.0

SERVICE BROWSER. Versione 1.0 SERVICE BROWSER Versione 1.0 25/09/2008 Indice dei Contenuti 1. Scopo del documento... 3 2. Introduzione... 3 3. Accordi di Servizio... 4 4. Servizi... 5 5. Servizio: Schede Erogatori... 8 6. Servizio:

Dettagli

SIST Sistema Informativo Sanitario Territoriale. Manuale utente. Medici Continuità Assistenziale

SIST Sistema Informativo Sanitario Territoriale. Manuale utente. Medici Continuità Assistenziale SIST Sistema Informativo Sanitario Territoriale Manuale utente Medici Continuità Assistenziale Versione 1.0 28 Aprile 2014 Indice dei Contenuti INDICE DEI CONTENUTI... 2 1. INTRODUZIONE... 3 2. IL SISTEMA

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

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

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

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

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

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

PROGETTO WEB SERVICES DOGANE SERVIZI PER RICEZIONE ED ELABORAZIONE MESSAGGI AMBIENTE REALE

PROGETTO WEB SERVICES DOGANE SERVIZI PER RICEZIONE ED ELABORAZIONE MESSAGGI AMBIENTE REALE Pag. 1 di 12 PROGETTO WEB SERVICES DOGANE SERVIZI PER RICEZIONE ED ELABORAZIONE MESSAGGI AMBIENTE REALE Pag. 1 di 12 Pag. 2 di 12 1 GENERALITÀ... 3 1.1 CANALI DI COMUNICAZIONE DEI SISTEMI... 3 2 SOA DOMINIO

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

Avvio AURA. Seminario sui web services. S. Dall'Olio P. Todoran CSI-Piemonte - Direzione Salute. Torino 5 agosto, 9 e 15 settembre

Avvio AURA. Seminario sui web services. S. Dall'Olio P. Todoran CSI-Piemonte - Direzione Salute. Torino 5 agosto, 9 e 15 settembre Avvio AURA Seminario sui web services S. Dall'Olio P. Todoran CSI-Piemonte - Direzione Salute Obiettivo dell'incontro AURA: Integrazione a servizi agevolare l'avvio di AURA per tutte le ASR entro i tempi

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

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

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

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

Interfacce applicative Servizi di gestione del consenso FSE

Interfacce applicative Servizi di gestione del consenso FSE Gara per l acquisizione di beni e servizi relativi al Sistema Informativo Sanitario e Socio-Sanitario della Regione Marche LOTTO 1 Anagrafe Sanitaria Regionale, infrastruttura Data Center,infrastruttura

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

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

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

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

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

Ulisse-SUAP sottosistema Registrazione e autenticazione Utenti

Ulisse-SUAP sottosistema Registrazione e autenticazione Utenti Pagina 1 di 13 Ulisse-SUAP sottosistema Registrazione e autenticazione Utenti Bozza Data: 17/5/2014 Numero pagine: 13 Pagina 2 di 13 INDICE GESTIONE DEL DOCUMENTO...3 GLOSSARIO...5 ACRONIMI...6 INTRODUZIONE...7

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

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

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

Integrazione del progetto CART regione Toscana nel software di CCE K2

Integrazione del progetto CART regione Toscana nel software di CCE K2 Integrazione del progetto CART regione Toscana nel software di CCE K2 Data Creazione 04/12/2012 Versione 1.0 Autore Alberto Bruno Stato documento Revisioni 1 Sommario 1 - Introduzione... 3 2 - Attivazione

Dettagli

JBoss ESB Un caso d'uso italiano: La Porta di Dominio per la Cooperazione Applicativa

JBoss ESB Un caso d'uso italiano: La Porta di Dominio per la Cooperazione Applicativa JBoss ESB Un caso d'uso italiano: La Porta di Dominio per la Cooperazione Applicativa Andrea Leoncini JBoss Stefano Linguerri - Pro-netics Agenda JBoss ESB le SOA e la Porta di Dominio Le specifiche CNIPA

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

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

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

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

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

DOCUMENTO DI ANALISI DEI MACROREQUISITI FUNZIONALI DEL SOFTWARE PER LA GESTIONE DELLO SCREENING DEL TUMORE DELLA CERVICE UTERINA

DOCUMENTO DI ANALISI DEI MACROREQUISITI FUNZIONALI DEL SOFTWARE PER LA GESTIONE DELLO SCREENING DEL TUMORE DELLA CERVICE UTERINA REGIONE MARCHE P.F. INFORMATICA Progetto: Consolidamento dello screening del tumore della cervice uterina Data: 31/12/2007 Stato: definitivo DOCUMENTO DI ANALISI DEI MACROREQUISITI FUNZIONALI DEL SOFTWARE

Dettagli

REGIONE TOSCANA GERTIC. Documentazione di progetto. Viale Montegrappa 278/E 59100 Prato (Italy) Telefono +39.0574.514180 Fax +39.0574.

REGIONE TOSCANA GERTIC. Documentazione di progetto. Viale Montegrappa 278/E 59100 Prato (Italy) Telefono +39.0574.514180 Fax +39.0574. REGIONE TOSCANA GERTIC Documentazione di progetto Viale Montegrappa 278/E 59100 Prato (Italy) Telefono +39.0574.514180 Fax +39.0574.551195 www.netstudio.it INFORMAZIONI DOCUMENTO PROGETTO GeRTIC Gestione

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

C.R.M. Custom Relationship Management

C.R.M. Custom Relationship Management Web Solution C.R.M. Custom Relationship Management Overview La soluzione CRM Portal Builder è una piattaforma innovativa per la gestione delle relazioni con i clienti, basata su una struttura modulare

Dettagli

l identità digitale federata nel progetto ICAR

l identità digitale federata nel progetto ICAR l identità digitale federata nel progetto ICAR Francesco Meschia Roma, 16 febbraio 2006 agenda generalità sul progetto ICAR e sul task INF-3 situazione e problemi dell identità digitale in Italia l approccio

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

DISCIPLINARE PER IL SERVIZIO DI CASSA ALLEGATO N. 2 ORDINATIVI INFORMATICI

DISCIPLINARE PER IL SERVIZIO DI CASSA ALLEGATO N. 2 ORDINATIVI INFORMATICI DISCIPLINARE PER IL SERVIZIO DI CASSA ALLEGATO N. 2 ORDINATIVI INFORMATICI A. Modalità di erogazione del servizio 1. Oggetto Gli ordinativi informatici dovranno essere sottoscritti con Firma Digitale dai

Dettagli