Framework di architettura di servizi per la sanita'
              




Specifications
Design
Prototyping
Integration
Pilot
       Pilot

 

 

 Il Pilot  ha l’obiettivo di definire, allestire, configurare e mettere in opera una dimostrazione che possa verificare la correttezza sintattica e semantica, l’efficacia e l’efficienza dei servizi HSSP realizzati nel corso del progetto. Il dimostratore affronterà una problematica reale nel settore clinico sanitario. In particolare, i partner pensano di definire una serie di processi e scenari d’uso nell’ambito dei percorsi diagnostico-terapeutici dei pazienti affetti da Cefalea. Tali processi saranno creati sfruttando sistemi di Business Process Management e sfruttando, ovviamente, la natura SOA dei sistemi realizzati dai partner del progetto HealthSOAF.

Componenti specifiche da integrare nell’infrastruttura del Pilot dovranno essere realizzate per poter implementare i processi clinico sanitari che si intende sperimentare. In particolare, sarà realizzata una componente di Services Registry sulla base dei servizi utilizzati nel dimostratore e dovranno essere realizzati dei prototipi di DSS focalizzati sul dominio dei percorsi diagnostico-terapeutici in ambito cefalee.

Dovrà, inoltre, essere realizzata anche una componente Client, che faccia da collante ai processi che si intende supportare. In particolare, si sperimenterà in questo caso l’implementazione di soluzioni RIA (Rich Internet Application) in ambito sanitario. La sperimentazione dei servizi realizzati sfrutterà ovviamente alcuni sistemi legacy dei partner di progetto, come per esempio la piattaforma di interoperabilità X1.V1 Dedalus.

Tenendo in considerazione anche i risultati della sperimentazione, gli outcome dell’attività sono:

Ø  dimostrare come mediante l’uso di questi nuovi servizi si riesca a supportare processi clinico sanitari complessi, che prevedono l’interazione di attori eterogenei e distribuiti;

Ø  proporre le condizioni e le modalità per un futuro sfruttamento industriale dei risultati ottenuti nell’ambito del progetto.

 

Le singole attività prevista per l’Obiettivo Realizzativo sono :

A5.1 Requisiti funzionali del Pilot. L’obiettivo di questa attività è quella di identificare nell’ambito dei percorsi diagnostico terapeutici per pazienti affetti da cefalea, una serie di scenari d’uso e l’insieme di processi clinico-sanitari che li caratterizzano, che possano risultare utili per sperimentare e valutare la correttezza, l’efficacia e l’efficienza dei servizi realizzati nell’ambito del progetto HealthSOAF. Pur individuando un insieme limitato di scenari d’uso e dei relativi processi clinico-sanitari l’obiettivo è quello di creare i presupposti per una sperimentazione in un ambiente operativo reale e con situazioni a contorno realistiche. Obiettivo di questa attività è anche quello di identificare una serie di parametri ed indicatori clinico-sanitari, su cui si possa valutare, anche se ovviamente in modo molto circoscritto, l’efficacia e l’efficienza di una soluzione come quella proposta dal progetto HealthSOAF. L’attività A5.1, infine, dovrà fornire, da un punto di visto tecnico-funzionale, anche una modellazione dei processi clinico-sanitari che si intende realizzare, utilizzando strumenti formali di Business Process Management.

A5.2 Specifiche tecniche e Confezionamento del Pilot. Obiettivo di questa attività è definire le specifiche tecniche del dimostratore da realizzare nell’ambito dei percorsi diagnostico-terapeutici per pazienti affetti da emicrania e sulla base dei requisiti funzionali definiti nell’attività A5.1. L’attività ha anche l’obiettivo di andare a confezionare l’infrastruttura base del dimostratore, sulla base dei servizi realizzati nell’ambito del progetto HealthSOAF. Il dimostratore si dovrà basare anche su componenti specifici, come un service registry e su Clinical Decision Support System specifici del dominio encefalico. Il dimostratore, inoltre, dovrà permettere agli utenti l’accesso alla gestione dei processi clinico sanitari implementati tramite interfacce RIA. L’attività A5.2 si occupa di definire le specifiche tecniche anche di questi componenti aggiuntivi, che saranno realizzati rispettivamente nelle attività A5.3 e A5.4. Per quanto riguarda l’infrastruttura del dimostratore, l’attività A5.2 ha il compito di configurare il Pilot come un'architettura distribuita composta dai principali servizi realizzati nell’ambito del progetto. In particolare, saranno utilizzati servizi del tipo Health Record Services, per accedere ai documenti clinico-sanitari dei pazienti. L’infrastruttura prevedrà anche l’utilizzo del relativo broker, che permetterà la ricerca, l'accesso in lettura e scrittura e la sincronizzazione (tra più occorrenze del broker) a dati e documenti del paziente. Servizi di tipo Health Identity Services, sfrutteranno il loro broker per permettere l'accesso a più sistemi d'identificazione. Tali servizi saranno utilizzati sia come base per l'autenticazione del paziente in quanto utente del dimostratore, sia per l'identificazione del paziente da parte dei sistemi e degli operatori. Per i servizi Health Terminology Services, invece, il Broker permetterà la ricerca, la selezione e l'accesso di percorsi sanitari di riferimento. Per i servizi Health Directory Services, il Broker permetterà la ricerca la selezione e l'accesso agli operatori in coerenza con le prescrizioni sia diagnostiche che terapeutiche, sia da parte del paziente direttamente, sia da parte degli operatori stessi. Per i servizi Health Privacy Services, il server permetterà la manipolazione dei diritto di accesso ai propri dati terapeutici, e l'accesso controllato a tali dati e la possibilità di consultare le tracce degli accessi da parte del paziente.

A5.3 Componente specifici Pilot (HSR e DSS). Nell’ambito del dimostratore dovranno essere realizzati componenti specifici, per soddisfare completamente i requisiti funzionali definiti nell’attività A5.1. L’attività A5.3, pertanto,  si occupa di realizzare i componenti:

Ø  Un modulo Health Service Registry Services, con l’obiettivo di offrire funzioni di pubblicazione, individuazione identificazione, amministrazione di servizi applicativi  infrastrutturali del dimostratore, sulla base dello standard UDDI. Tale modulo prevede la realizzazione di:

 

·         un HSRS Consumer Adapter, componente J2EE di implementazione della HSRS Consumer Interface, la cui integrazione in una applicazione J2EE facilita la fruizione di servizi Discovery, Publish su piattaforma WS*. L'architettura del componente è una specializzazione dell'API standard di publish/discovery UDDI V3.

·         Health Service Registry Server, registro UDDI per i servizi applicativi e infrastrutturali.

 

Ø  Un modulo messo a disposizione del server dei Health Decision Support Services che implementi un Clinical Decision System (CDS) sui protocolli diagnostici e terapeutici in ambito cefalee, sulla base delle specifiche funzionali definite nell’A5.1.

A5.4 Componente Health Rich Web Client per il Pilot. Il dimostratore, affinché la sperimentazione sia affidata a veri operatori del sistema sanitario, deve dotarsi anche di una serie di interfacce utente per gestire i processi clinico sanitari definiti per il Pilot. Questa componente riguarda una serie di moduli software di tipo Rich client Web 2.0, per l’accesso ai servizi di back office, in tecnologia W3C. Saranno inoltre utilizzate tecnologie associate come Web Storage, Web Workers e Web Socket. L'insieme di componenti permette la realizzazione di un Rich Web Client 2.0 che :

Ø  configuri e permetta l'accesso interattivo all'utente secondo il profilo - paziente, operatore clinico, operatore amministrativo - ai servizi di back office Health SX;

Ø  implementi una logica applicativa client sofisticata, permettendo la composizione dei servizi di back-office eseguibile nel browser e le cui regole siano caricabili on the fly;

Ø  implementi la comunicazione bi-direzionale con i server - per esempio con i provider degli Health SX, e che, quindi, soddisfi l'implementazione del consumer in conformità con gli standard HSSP;

Ø  implementi la persistenza locale dei dati e della possibilità di lavorare offline. Il modulo sarà implementato utilizzando le tecnologie allo stato dell’arte (come per esempio HTML5).

A5.5 Deployment e configurazione Pilot. Obiettivo dell’attività è quello di dispiegare nell’ambiente selezionato per la sperimentazione l’infrastruttura software del dimostratore, confezionata nelle attività precedenti e di configurarla sulla base dei requisiti funzionali definiti in A5.1.

A5.6 Sperimentazione. Questa attività si occupa della sperimentazione vera e propria del dimostratore in un contesto reale e con scenari d’uso realistici.

5.7 Validazione. Questa attività si occupa della valutazione della sperimentazione, con un’attenta analisi sia degli aspetti e delle criticità sorte da un punto di vista tecnologico, sia degli aspetti e delle criticità funzionali. La valutazione sarà condotta sulla base dei requisiti funzionali definiti in A5.1 e sulla base delle specifiche tecniche definite in A5.2.

A5.8 Exploitation e Dissemination del progetto. Il progetto HealthSOAF intende realizzare una infrastruttura di servizi software, basati sugli standard HSSP, a vantaggio di una nuova generazione di sistemi informativi clinico-sanitari, che, seguendo un approccio SOA, possano garantire effettivamente una completa interoperabilità applicativa. In particolare, il progetto HealthSOAF con tale obiettivo intende promuovere un’innovazione tecnologica e culturale dei sistemi informativi clinico sanitari, passando definitivamente da una visione per prodotti, ad una visione per processi, in cui, grazie ad una sempre più nativa interoperabilità applicativa, si possa affrontare tematiche quali continuità di cura, assistenza integrata ospedale territorio e, al tempo stesso, applicare politiche che governance clinica in grado di ottimizzare l’uso delle risorse ed incidere positivamente sulla spesa sanitaria. L’attività A5.8, che di fatto chiude il progetto HealthSOAF ha l’obiettivo di capire come questi obiettivi tecnologici, funzionali ed organizzativi possono essere tradotti anche in nuove opportunità di business per le aziende partner del progetto ed, in generale, per i player del settore informatico in sanità. Opportunità di business che da una parte devono valutare, a fronte di un investimento per l’industrializzazione dei prototipi realizzati nell’ambito del progetto, quale modalità di fornitura e/o erogazione di servizi innovativi possono essere più idonei per conquistare importanti posizioni nel mercato nazionale ed internazionale dell’informatica clinico-sanitaria. Il piano di exploitation dei risultati deve però tenere in considerazione anche l’impatto che sistemi informativi di nuova generazione come quello proposto da HealthSOAF possono avere sulla governance clinico sanitaria ed, in generale, sulle politiche di gestione della sanità in termini di:

Ø  efficacia dei percorsi di cura;

Ø  realizzazione di percorsi integrati ospedale-territorio, a vantaggio soprattutto di pazienti con patologie croniche;

Ø  maggiore assistenza alle categorie più deboli

Ø  maggiore attenzione alla qualità del servizio fornito al cittadino (liste d’attesa, accesso a centri di eccellenza ecc)

e al tempo stesso consentire al sistema sanitario una maggiore ottimizzazione delle risorse ed un contenimento della spesa, affinché tutto il sistema sia sostenibile.