Questo sito web utilizza cookie tecnici e, previo Suo consenso, cookie di profilazione, nostri e di terze parti. Chiudendo questo banner, scorrendo questa pagina o cliccando qualunque suo elemento acconsente all'uso dei cookie. Leggi la nostra Cookie Policy per esteso.OK

Ecco le architetture e gli standard per i servizi sanitari innovativi

Home PA Digitale Ecco le architetture e gli standard per i servizi sanitari innovativi

L’innovazione e la standardizzazione tecnologica possono trasformare rapidamente enti pubblici ed imprese private in organizzazioni digitali, contribuendo ad eliminare alcuni ostacoli sul percorso della creazione e dell’orchestrazione di servizi sanitari innovativi per il cittadino. Ecco come

28 Maggio 2016

S

Sergio Puggelli, Local Gov. & Healthcare Management, Hewlett Packard Enterprise

Durante il primo incontro del Cantiere Sanità Digitale, Hewlett Packard Enterprise, ha portato all’attenzione del tavolo di lavoro recenti aspetti di innovazione e di standardizzazione tecnologica in grado di trasformare rapidamente enti pubblici ed imprese private in organizzazioni digitali, contribuendo ad eliminare alcuni ostacoli sul percorso della creazione e dell’orchestrazione di servizi sanitari innovativi per il cittadino.

In estrema sintesi gli aspetti più interessanti di questa innovazione e standardizzazione tecnologica sono:

  • Architettura applicativa a microservizi;
  • API Standard REST per l’integrazione e l’orchestrazione delle risorse/oggetti (microservizi applicativi od oggetti infrastrutturali);
  • Architettura SOA (Service Oriented Architecture) basata sugli standard web (WOA – Web Oriented Architecture e ISB – Internet Service Bus);
  • Containers.

E’ interessante notare come gli stessi standard internazionali HL7 (Health Level 7) e CDA (Clinical Document Architecture) stiano evolvendo allo standard FHIR (Fast Health Interoperability Resources) che fa leva appunto sui primi 3 aspetti di innovazione tecnologica suddetti.

Vediamo piu’ nel dettaglio questi aspetti di innovazione tecnologica, che possono anche essere considerati raccomandazioni per i decisori politici.

L’architettura applicativa a microservizi obbliga innanzi tutto a scomporre la logica di business (business logic), ovvero l’intero servizio applicativo, in sottoinsiemi di servizi a granularità estremamente fine, dove ciascun sottoinsieme rappresenta appunto un microservizio applicativo.

In altre parole, se la logica di business raprresenta l’intera automazione di processo/flusso/funzione sanitaria, il suo microservizio rappresenta il più piccolo processo/flusso/funzione sanitaria rappresentabile all’interno della logica di business.

Immaginiamo questo singolo microservizio (processo/flusso/funzione) come una risorsa/oggetto o, meglio, come un componente applicativo, in grado di essere:

  • identificabile nel dominio applicativo grazie ad un suo specifico ed univoco indirizzo (URI – Unique Resource Identifier);
  • richiamabile da programmi via interfacce di programmazione (API) stnadard web (REST);
  • trasportato attraverso l’utilizzo di un protocollo stadard web (HTTPS);
  • indipendente dalla piattaforma hardware grazie al suo “incapsulamento” in un container open e standard (es. Docker).

In questo modo possiamo facilmente comprendere quanto possa diventare più semplice mettere in pratica le seguenti attività:

  • integrare tra loro microservizi appartenenti a diverse logiche di business prodotte da qualsiasi sviluppatore software (ISV o Home Made Application);
  • orchestrare “on-the-fly” nuovi servizi a seconda dell’esigenza dell’ente locale, dei cittadini tutti o di gruppi di specifici cittadini, dell’ente centrale o da parte di specifici organi di governo a livello locale o centrale;
  • usare il cloud (pubblico, privato e ibrido) per far scalare la potenza di erogazione del servizo a fronte di un improvviso aumento di richieste di servizio;
  • rendere il servizio virtualmente fault tolerant .

In questa logica, anche i dati sono pienamente fruibili tramite microservizi ed anch’essi, conseguentemente, assumono tutte le caratterizzazioni citate, aumentando ancora più la flessibilità del sistema nel suo complesso.

Considerando quanto sin qui esposto e prendendo come esempio gli ostacoli che ciascuna iniziativa locale ha – più o meno – riscontrato nel mettere a punto il Fascicolo Sanitario Elettronico (dalla sua standardizzazione per una piena interoperabilità su scala nazionale, all’inserimento in esso di informazioni a granularità fine anzichè interi documenti, etc.), riteniamo possa risultare evidente quanto una re-ingegnerizzazione delle varie iniziative di FSE, basata sugli standard e sulle innovazioni tecnologiche suddette, possa produrre evidenti risultati di efficenza, interoperabilità, flessibilità, semplificazione.

In un prossimo articolo ci proponiamo di approfondire ulteriormente questi temi ed introdurne altri riferiti ad elementi di sicurezza informatica, privacy ed infrastrutture Cloud abilitanti.

Su questo argomento

APP PA: l'elenco delle app ufficiali della Pubblica Amministrazione