SlideShare une entreprise Scribd logo
1  sur  18
Télécharger pour lire hors ligne
Personal Health Record: a che punto siamo?
Il "caso Trentino" e l'esperienza del Gruppo GPI

      L'architettura tecnologica di TreC
                                         Davide Piazza
      Project Manager Web Group Argentea Spa – Gruppo GPI
Il Portale TreC (acronimo di Cartella Clinica del Cittadino) si
propone di fornire ai cittadini della Provincia Autonoma di
Trento una piattaforma PHR di servizi online per accedere,
consultare, condividere e aggiornare i propri documenti sanitari
tramite l’uso di un portale internet. Questo nuovo sistema, ad
adesione volontaria, sarà utilizzato dal cittadino sia per
supportarlo nella gestione della propria salute e di quella dei
propri familiari, sia per entrare in rete con le strutture e gli
operatori sanitari provinciali.
Il progetto è realizzato in sinergia tra Assessorato alla Salute e
Politiche Sociali, Fondazione Bruno Kessler, Azienda Provinciale
per i Servizi Sanitaria e imprese IT operanti nel settore della
sanità elettronica.
Architettura generale del sistema
Ambiente tecnologico
   Sistema operativo CentOS (open source)


   Portal server: Liferay portal (open source)


   Framework portlet: icefaces (open source)


   Protocolli di comunicazione standard (Web Services e REST)


   Single Sign-On: Sun OpenSSO Express (open source)


   Framework javasign (open source)
Architettura applicativa

   GPI - Liferay Portal: portal server per il portale TreC e il
    gestionale utenti


   FBK - Middleware: middleware di gestione del dato della cartella


   GPI - Gestione Autenicazione Single Sign-On e policy di
    autorizzazione


   GPI - Single Sing-On con Strong Authentication
Liferay portal

   “Un portale è un ambiente web-based in cui le applicazioni degli
    utenti vengono eseguite e integrate tra loro, in maniera
    consistente e sistematica”


   Le applicazioni eseguite dal portale si denifiscono “Portlet” (JSR-
    168)


   Liferay Portal è un container per applicazioni integrate già
    pronte all'uso senza necessità di sviluppi.
Liferay portal

   Aggregazione di applicazioni
        –     RSS feed aggregator
        –     Calendar
        –     Calculator
   Content management
   Collaboration tool
        –     Blog
        –     Wiki
        –     Forum
        –     Document management
   Interfaccia personalizzabile
TreC: home page pubblica
TreC: pagina di login
TreC: home page utente
TreC: wizard
Punti di forza Liferay in TreC
   Widget = Portlet
   TreC utente = liferay community
   API Liferay per personalizzazione pagine e schede da parte
    dell'utente




   Supporto a opensso
ICEFaces

   Implementazione Java Server Faces
   Implementazione modello Model View Controller (MVC)
   Supporto avanzato AJAX per una user experience di alto
    livello (partial submit nella compilazione dei form)
   Ajax Push per interportlet communication: assistente
    contestuale TreC aggiorna il contenuto (preso da CMS)
    senza reload di pagina
   www.icefaces.org
Autenticazione CNS

 Autenticazione forte a 2 vie


 Funzionamento (aderente linee guida CNIPA)


 Supporto a diversi formati di smart card
Autenticazione OTP

 Autenticazione forte a 2 vie
 Funzionamento
    → Identificazione utente
    → Il cittadino compone un numero verde con il
      proprio cellulare
    → Il cittadino compone sul tastierino del proprio
      cellulare il codice come indicato dal portale
Single Sign On

   Un'unica autenticazione
    permette l'accesso a ulteriori
    risorse del sistema senza altre
    autenticazioni fastidiose per
    l'utente




   Il Single Sign-On è sfruttato dal
    middleware che riceve ad ogni
    chiamata da parte del portale
    il token di sessione e demanda
    al sistema SSO la verifica della
    sua validità
Policy management
   Estensione del modello OpenSSO di entitlement
   Funzionamento
     →     Il portale richiede al middleware una risorsa (un dato sanitario)
     →     Middleware verifica se l'utente del portale ha accesso al dato in base alla policy
           del proprietario del dato
     →     Middleware se autorizzato restituisce il dato
   Criteri di policy decision: proprietario del dato, utente abilitato, identificazione del dato
    (url risorsa), azione (permetti/nega accesso), data inizio validità, data fine validità
   Esempi url risorsa:
     →     http://server:porta/applicazione/resources/1/clinicalDocument/23 DENY
     →     http://server:porta/applicazione/resources/1/observableParameters/* ALLOW
     →     http://server:porta/applicazione/resources/1/observableParameters/5 DENY

Contenu connexe

Similaire à Architettura tecnologica di TreC

Sviluppo di servizi REST per Android - Luca Masini
Sviluppo di servizi REST per Android - Luca Masini Sviluppo di servizi REST per Android - Luca Masini
Sviluppo di servizi REST per Android - Luca Masini
Whymca
 
Anonimato nell'era digitale (rfree)
Anonimato nell'era digitale (rfree)Anonimato nell'era digitale (rfree)
Anonimato nell'era digitale (rfree)
Elisa Brivio
 
SVILUPPO DI UNA SOLUZIONE SINGLE SIGN ON PER L’ENTE VENETO LAVORO
SVILUPPO DI UNA SOLUZIONE  SINGLE SIGN ON  PER L’ENTE VENETO LAVOROSVILUPPO DI UNA SOLUZIONE  SINGLE SIGN ON  PER L’ENTE VENETO LAVORO
SVILUPPO DI UNA SOLUZIONE SINGLE SIGN ON PER L’ENTE VENETO LAVORO
Zanatta Davide
 
Single Sign On sul web
Single Sign On sul webSingle Sign On sul web
Single Sign On sul web
Vincenzo Calabrò
 

Similaire à Architettura tecnologica di TreC (20)

Linux Day 2014 - Napoli - Programma Il Futuro: una scelta open source
Linux Day 2014 - Napoli - Programma Il Futuro: una scelta open sourceLinux Day 2014 - Napoli - Programma Il Futuro: una scelta open source
Linux Day 2014 - Napoli - Programma Il Futuro: una scelta open source
 
Programma il futuro: una scelta open source
Programma il futuro: una scelta open sourceProgramma il futuro: una scelta open source
Programma il futuro: una scelta open source
 
OpenStack: leggero, aperto e basato sul web.
OpenStack: leggero, aperto e basato sul web.OpenStack: leggero, aperto e basato sul web.
OpenStack: leggero, aperto e basato sul web.
 
Sviluppo di servizi REST per Android - Luca Masini
Sviluppo di servizi REST per Android - Luca Masini Sviluppo di servizi REST per Android - Luca Masini
Sviluppo di servizi REST per Android - Luca Masini
 
SVILUPPO DI SERVIZI REST PER ANDROID
SVILUPPO DI SERVIZI REST PER ANDROIDSVILUPPO DI SERVIZI REST PER ANDROID
SVILUPPO DI SERVIZI REST PER ANDROID
 
Anonimato nell'era digitale (rfree)
Anonimato nell'era digitale (rfree)Anonimato nell'era digitale (rfree)
Anonimato nell'era digitale (rfree)
 
Un Web-GIS per i comuni della Valle della Cupa Realizzato in Ambiente Open So...
Un Web-GIS per i comuni della Valle della Cupa Realizzato in Ambiente Open So...Un Web-GIS per i comuni della Valle della Cupa Realizzato in Ambiente Open So...
Un Web-GIS per i comuni della Valle della Cupa Realizzato in Ambiente Open So...
 
SVILUPPO DI UNA SOLUZIONE SINGLE SIGN ON PER L’ENTE VENETO LAVORO
SVILUPPO DI UNA SOLUZIONE  SINGLE SIGN ON  PER L’ENTE VENETO LAVOROSVILUPPO DI UNA SOLUZIONE  SINGLE SIGN ON  PER L’ENTE VENETO LAVORO
SVILUPPO DI UNA SOLUZIONE SINGLE SIGN ON PER L’ENTE VENETO LAVORO
 
BGD - Doc premio_forumpa2017
BGD - Doc premio_forumpa2017BGD - Doc premio_forumpa2017
BGD - Doc premio_forumpa2017
 
September 2010 - Gatein
September 2010 - GateinSeptember 2010 - Gatein
September 2010 - Gatein
 
Meetup Progressive Web App
Meetup Progressive Web AppMeetup Progressive Web App
Meetup Progressive Web App
 
Conf stampa 2010 v1.4
Conf stampa 2010 v1.4Conf stampa 2010 v1.4
Conf stampa 2010 v1.4
 
Conf Stampa 2010 V1.4
Conf Stampa 2010 V1.4Conf Stampa 2010 V1.4
Conf Stampa 2010 V1.4
 
Cv 2014 richard_gennaro_ eur_it
Cv 2014 richard_gennaro_ eur_itCv 2014 richard_gennaro_ eur_it
Cv 2014 richard_gennaro_ eur_it
 
Sviluppo di un'applicazione ibrida su dispositivo mobile per l'interfacciamen...
Sviluppo di un'applicazione ibrida su dispositivo mobile per l'interfacciamen...Sviluppo di un'applicazione ibrida su dispositivo mobile per l'interfacciamen...
Sviluppo di un'applicazione ibrida su dispositivo mobile per l'interfacciamen...
 
Moving from Monolithic to Microservice Architecture: an OSS based stack deplo...
Moving from Monolithic to Microservice Architecture: an OSS based stack deplo...Moving from Monolithic to Microservice Architecture: an OSS based stack deplo...
Moving from Monolithic to Microservice Architecture: an OSS based stack deplo...
 
Istituzioni, aziende, società: il valore della fiducia digitale - presentazio...
Istituzioni, aziende, società: il valore della fiducia digitale - presentazio...Istituzioni, aziende, società: il valore della fiducia digitale - presentazio...
Istituzioni, aziende, società: il valore della fiducia digitale - presentazio...
 
Meetup Fluent Design e Progressive Web App
Meetup Fluent Design e Progressive Web AppMeetup Fluent Design e Progressive Web App
Meetup Fluent Design e Progressive Web App
 
Fun with Machine Translation APIs
Fun with Machine Translation APIsFun with Machine Translation APIs
Fun with Machine Translation APIs
 
Single Sign On sul web
Single Sign On sul webSingle Sign On sul web
Single Sign On sul web
 

Architettura tecnologica di TreC

  • 1. Personal Health Record: a che punto siamo? Il "caso Trentino" e l'esperienza del Gruppo GPI L'architettura tecnologica di TreC Davide Piazza Project Manager Web Group Argentea Spa – Gruppo GPI
  • 2. Il Portale TreC (acronimo di Cartella Clinica del Cittadino) si propone di fornire ai cittadini della Provincia Autonoma di Trento una piattaforma PHR di servizi online per accedere, consultare, condividere e aggiornare i propri documenti sanitari tramite l’uso di un portale internet. Questo nuovo sistema, ad adesione volontaria, sarà utilizzato dal cittadino sia per supportarlo nella gestione della propria salute e di quella dei propri familiari, sia per entrare in rete con le strutture e gli operatori sanitari provinciali.
  • 3. Il progetto è realizzato in sinergia tra Assessorato alla Salute e Politiche Sociali, Fondazione Bruno Kessler, Azienda Provinciale per i Servizi Sanitaria e imprese IT operanti nel settore della sanità elettronica.
  • 5. Ambiente tecnologico  Sistema operativo CentOS (open source)  Portal server: Liferay portal (open source)  Framework portlet: icefaces (open source)  Protocolli di comunicazione standard (Web Services e REST)  Single Sign-On: Sun OpenSSO Express (open source)  Framework javasign (open source)
  • 6. Architettura applicativa  GPI - Liferay Portal: portal server per il portale TreC e il gestionale utenti  FBK - Middleware: middleware di gestione del dato della cartella  GPI - Gestione Autenicazione Single Sign-On e policy di autorizzazione  GPI - Single Sing-On con Strong Authentication
  • 7. Liferay portal  “Un portale è un ambiente web-based in cui le applicazioni degli utenti vengono eseguite e integrate tra loro, in maniera consistente e sistematica”  Le applicazioni eseguite dal portale si denifiscono “Portlet” (JSR- 168)  Liferay Portal è un container per applicazioni integrate già pronte all'uso senza necessità di sviluppi.
  • 8. Liferay portal  Aggregazione di applicazioni – RSS feed aggregator – Calendar – Calculator  Content management  Collaboration tool – Blog – Wiki – Forum – Document management  Interfaccia personalizzabile
  • 9. TreC: home page pubblica
  • 11. TreC: home page utente
  • 13. Punti di forza Liferay in TreC  Widget = Portlet  TreC utente = liferay community  API Liferay per personalizzazione pagine e schede da parte dell'utente  Supporto a opensso
  • 14. ICEFaces  Implementazione Java Server Faces  Implementazione modello Model View Controller (MVC)  Supporto avanzato AJAX per una user experience di alto livello (partial submit nella compilazione dei form)  Ajax Push per interportlet communication: assistente contestuale TreC aggiorna il contenuto (preso da CMS) senza reload di pagina  www.icefaces.org
  • 15. Autenticazione CNS  Autenticazione forte a 2 vie  Funzionamento (aderente linee guida CNIPA)  Supporto a diversi formati di smart card
  • 16. Autenticazione OTP  Autenticazione forte a 2 vie  Funzionamento → Identificazione utente → Il cittadino compone un numero verde con il proprio cellulare → Il cittadino compone sul tastierino del proprio cellulare il codice come indicato dal portale
  • 17. Single Sign On  Un'unica autenticazione permette l'accesso a ulteriori risorse del sistema senza altre autenticazioni fastidiose per l'utente  Il Single Sign-On è sfruttato dal middleware che riceve ad ogni chiamata da parte del portale il token di sessione e demanda al sistema SSO la verifica della sua validità
  • 18. Policy management  Estensione del modello OpenSSO di entitlement  Funzionamento → Il portale richiede al middleware una risorsa (un dato sanitario) → Middleware verifica se l'utente del portale ha accesso al dato in base alla policy del proprietario del dato → Middleware se autorizzato restituisce il dato  Criteri di policy decision: proprietario del dato, utente abilitato, identificazione del dato (url risorsa), azione (permetti/nega accesso), data inizio validità, data fine validità  Esempi url risorsa: → http://server:porta/applicazione/resources/1/clinicalDocument/23 DENY → http://server:porta/applicazione/resources/1/observableParameters/* ALLOW → http://server:porta/applicazione/resources/1/observableParameters/5 DENY