PIATTAFORMA TECNOLOGICA
ED APPLICATIVA EPHIS
E-HEALTH PORTAL HOSPITAL INFORMATION SYSTEM
Sommario
Premessa............................................................................................................................. 5
Caratteristiche Tecniche della Piattaforma Applicativa ........................................................ 7
Requisiti di sistema ................................................................................................... 14
Architettura applicativa della piattaforma ................................................................... 15
Design Pattern........................................................................................................... 15
Motore di templating .................................................................................................. 17
Base dati ................................................................................................................... 17
Accessi e Sicurezza .................................................................................................. 19
Theming .................................................................................................................... 19
Motore API ................................................................................................................ 20
Middleware integrazione .................................................................................................... 21
MiddleWare: Scenario di riferimento ......................................................................... 21
MiddleWare: Protocolli di comunicazione .................................................................. 23
MiddleWare: Sicurezza ............................................................................................. 23
MiddleWare: Tracciamento delle operazioni effettuate .............................................. 24
MiddleWare: architettura applicativa ......................................................................... 25
MiddleWare: flussi di integrazione ............................................................................. 28
EPHIS – Sistema Informativo Ospedaliero ........................................................................ 30
EPHIS: lo scenario e gli obiettivi................................................................................ 30
EPHIS: le caratteristiche ed i punti di forza ............................................................... 34
EPHIS: funzionalità e moduli applicativi .................................................................... 40
Processi Implementati ............................................................................................... 40
EPHIS: cartelle cliniche specialistiche ....................................................................... 45
Indice delle immagini
Figura 1 - Schema architetturale piattaforma .................................................................. 13
Figura 2 - Schema flussi integrazioni.............................................................................. 22
Figura 3 - Schema architetturale middleware d'integrazione ............................................. 25
Figura 4 - Funzionalità Middleware ................................................................................. 27
Figura 5 - Integrazione dei servizi ospedalieri ................................................................. 29
Figura 6 - EPHIS: “gli attori” ........................................................................................ 36
Figura 7 - EPHIS: macro-funzioni .................................................................................. 39
Premessa
La piattaforma tecnologica ed applicativa per la sanità elettronica rappresenta il contenitore, il
veicolo e lo strumento per la gestione ed il trattamento di tutti i dati anagrafici e clinici dei pazienti nelle differenti strutture sanitarie, che siano ospedaliere, territoriali o domiciliari, e secondo i differenti processi lavorativi in esse espletati.
La piattaforma è un insieme di funzionalità e moduli applicativi fra di esse strettamente legate
in percorsi logici che rappresentano le attività lavorative quotidiane del personale sociosanitario, ponendo al centro sempre la salvaguardia della salute del paziente, centralizzando e
rendendo disponibili sempre ed ovunque tutte le informazioni ad esso inerenti ed ottimizzando
le attività e le risorse sia economiche che umane.
La piattaforma nasce e cresce in una forte e continua sinergia, quotidiana, dentro ogni turno
lavorativo, con il personale socio-sanitario che ha partecipato proattivamente e con un contributo di analisi dei processi e funzionale indispensabile.
Un tale approccio progettuale ha consentito e consente di avere un sistema applicativo completo, visto da molte e differenti prospettive lavorative, e soprattutto non “calato dall’alto” su
realtà sconosciute ma intrinsecamente coinvolto nella gestione e rappresentazione dei processi
lavorativi.
Tutto ciò porta ad avere non solo un prodotto, specializzato e customizzato, ma soprattutto una soluzione informatico-organizzativa completa ed integrata.
La base tecnologica centrale su cui poggia la piattaforma, e di cui è parte integrante ed attiva,
è un framework applicativo che rappresenta il “motore intelligente” di tutti i processi presenti
nelle varie applicazioni che ne derivano.
La natura completamente Open Source del framework consente alla piattaforma per la sanità
elettornica di essere integrata ed integrabile con ogni tipo di applicativo esterno ad essa, si
pensi ai servizi strasversali presenti nelle strutture ospedaliere (laboratori clinici, radiodiagnostici, etc.) e/o ad applicazioni specifiche per patologie.
5
Infatti tra le principali caratteristiche del framework applicativo è compreso l’utilizzo di layer
che assolve al compito di middleware di integrazione; di fatto funzionando da “interprete” da e
verso ogni tipo di informazione garantisce l’acquisizione di ogni informazione che riguardi il paziente e nel contempo il dialogo continuo tra le molteplici realtà applicative presenti all’interno
di strutture sanitarie complesse, senza modificare le modalità lavorative di ogni attore.
1. EPHIS – Sistema Informativo Ospedaliero
2. MiddleWare di Integrazione
6
Caratteristiche Tecniche della Piattaforma Applicativa
La piattaforma applicativa integrata per la gestione di processi e dati in sanità presente le seguenti caratteristiche principali:
1. WEB BASED nativa
2. OPEN SOURCE (sia a livello di codice sia a livello di base dati)
3. MODULARE e SCALABILE
4. Architettura CLOUD Computing
Le caratteristiche tecniche e tecnologiche della piattaforma, oltre a presentare tutti i vantaggi
del mondo WEB, la raggiungibilità e fruibilità dei servizi real time ovunque, e nel contempo
quelli del mondo del software OPEN, nessun costo di licenza e codice completamente aperto,
presentano notevoli vantaggi nell’infrastruttura necessaria al suo funzionamento, infrastruttura
assolutamente snella e di facile manutenzione.
La piattaforma tecnologica ed applicativa per la sanità elettronica è stata progettata e sviluppata implementando un’ infrastruttura a sistemi di CLOUD Computing, questo per cogliere
un'opportunità, che non riguarda soltanto la capacità di offrire servizi in un mercato differente,
ma anche quella, più nobile, di contribuire allo sviluppo del Paese realizzando, nel proprio ambito ed insieme alla pubblica amministrazione di riferimento, un modo di governare aperto,
trasparente e collaborativo.
Il CLOUD computing è uno strumento fondamentale per ottenere questo risultato.
Una piattaforma applicativa CLOUD nativa consente di ottenere notevoli vantaggi sia in termini economici che di utilizzo delle risorse:
•
avendo maggiori opportunità di diffuEPHISne dei propri servizi nel mercato di riferimento
•
modificando ed ampliando l'offerta delle soluzioni per un numero maggiore di clientela
7
•
evolvendo verso un nuovo modo di pensare e proporre servizi alla PA e quindi al cittadino
•
aumentando la propria competitività andando incontro alle nuove esigenze della pubblica amministrazione relative al risparmio e al miglior utilizzo delle risorse già acquisite
Di fatto si punta ad aumentare il fattore di risparmio da parte di chi acquista i servizi, risparmio dato dall'adozione di tecnologie cloud, in quanto esse abbattono i costi fissi per l'acquisizione di strumenti informatici (hardware e software), come anche i costi di manutenzione e di
aggiornamento, permettendo di convogliare la spesa soltanto sull'ottenimento del servizio desiderato e di farlo in maniera flessibile e solo quando ce n'è bisogno, in base alle reali esigenze
di approvvigionamento.
In questo modo, la PA potrà dedicarsi a “fare la PA” senza doversi orientare fra le complessità
dello sviluppo tecnologico. In questo modo potranno veder forma servizi più avanzati a beneficio di cittadini, pazienti, turisti, scuole, imprese, associazioni, comunità. In questo modo le piccole e medie imprese potranno rimanere sul mercato, diventando parte attiva nell'erogazione
di servizi al cittadino.
Altra caratteristica fondamentale della piattaforma è la sua architettura MODULARE.
È possibile decidere quali servizi occorrono per i propri processi lavorativi e acquistare solo quelli strettamente necessari, configurando i moduli applicativi opportuni.
In questa maniera si ottiene una notevole ottimizzazione delle risorse sia economiche che infrastrutturali, e non si appesantiscono i processi lavorativi in atto.
La base comune all’implementazione di tutti i processi sanitari rappresentati si fonda su un
CORE centrale (framework applicativo) che garantisce molteplici servizi trasversali all'intero
sistema:
l'autenticazione degli utenti e relative autorizzazioni
la sicurezza e crittografia dei dati e dei canali di trasmisEPHISne
la gestione delle sesEPHISni di connesEPHISne
la gestione del motore di templating
la gestione dei controller dei processi
la gestione dei servizi di theming relativi all’interfaccia
8
la gestione della persistenza delle transazioni e dei dati
la interoperabilità ed integrabilità con altre piattaforme applicative
In aggiunta ai moduli centrali del sistema sono stati progettati e sviluppati una serie di moduli
e funzionalità specifiche sulla base delle esigenze emerse dall'analisi funzionale e dati eseguita
direttamente on site con il personale sanitario ed amministrativo coinvolto nel processo di progettazione.
La progettazione e sviluppo di moduli specialistici ha consentito di ottenere un insieme completo di funzionalità per la gestione a 360° di strutture sanitarie complesse.
A livello applicativo ed architetturale la piattaforma tecnologica ed applicativa per la sanità
elettronica è composta da una serie di layers nativamente integrati fra loro ognuno dei quali
assolve a differenti compiti, ma tutti con un unico scopo finale: quello di mettere al centro dei
processi e relative informazioni la tutela della salute del paziente.
La piattaforma è stata studiata e progettata guardando alle nuove esigenze che stanno emergendo nel mondo della sanità: maggiore efficienza ed efficacia nell’erogazione dei servizi, il
tutto con modalità e strumenti estremamente sicuri, rispettosi della privacy del paziente e tali
da ridurre notevolmente il rischio clinico.
In tale direzione la progettazione della piattaforma ha posto particolare interesse ed importanza sulla sviluppo di moduli applicativi che assolvessero al compito di rendere la trattazione dei
dati, il loro trasferimento, la loro gestione nonché fruizione altamente sicuri.
L’obiettivo che ci si è posto è quello di garantire che la piattaforma applicativa risultasse uno
strumento sicuro ed utilizzabile nel rispetto dei principi guida che la Carta dei diritti del malato
sancisce come imprescindibili.
Si deve garantire al paziente:
1. il Diritto alla Sicurezza
2. il Diritto alla Protezione
3. il Diritto alla Qualità
9
Di fatto sono valori e principi che fondano le loro radice su di una forte interconnesEPHISne fra
loro e reciprocità di azione:
•
la sicurezza del paziente si propone in primis di evitare, controllare e ridurre gli eventi
avversi o i danni connessi all’assistenza
•
la sicurezza deriva dall’interazione di tutte le componenti del sistema e consiste
nell’evitare gli errori o i casi “prevenibili”
•
la sicurezza delle cure è correlata alla qualità delle cure e ne rappresenta un fondamentale sottoinsieme (US National Patient Safety Foundation)
In materia di Risk Management, complessa ed in continua evoluzione, garantire livelli di sicurezza, protezione e qualità richiede una grande sforzo progettuale ed una grande capacità organizzativa.
Caratteristiche peculiari che sono riscontrabili nella piattaforma applicativa che presenta un sistema completo ed alta affidabilità per la garanzia e gestione della sicurezza secondo le seguenti modalità e linee guida:
•
segretezza e confidenzialità: i dati devono poter essere consultati e/o modificati soltanto da parte di chi sia debitamente autorizzato;
•
integrità ed autenticità: i dati non devono poter essere manipolati dolosamente od accidentalmente e la loro provenienza deve essere verificabile;
•
accessibilità: i dati devono essere sempre disponibili eventualmente anche attraverso il
loro immediato ripristino
I moduli applicativi sviluppati per la gestione della sicurezza riguardano in particolare i
seguenti punti:
•
crittografia dei dati
•
autenticazione degli utenti e relative autorizzazioni
•
autorizzazione all'uso degli oggetti del database
•
amministrazione e l'aggiornamento delle policies
10
•
auditing
•
strategie di backup e di ripristino dei dati
Il modulo di autenticazione ed autorizzazione degli utenti rispetta le principali e più sicure regole di sicurezza con lo scopo di diminuire sensibilmente i rischi di intercettamento e riutilizzo
della password:
•
Tempo di durata delle credenziali minimo
•
Complessità della password elevata
•
Algoritmo di creazione delle password casuale e randomico
•
Meccanismi di lock dell’account
•
Determinazione del ciclo di vita dell’account
•
Livello di facilità di rintracciamento delle password secondo dizionari dati o metodi di attacco a forza bruta
•
Crittografia password
La sicurezza dell'intera infrastruttura applicativa inoltre viene implementata anche attraverso il
modulo dedicato alla gestione della crittografia.
Questo modulo, trasversale a tutto il sistema, consente ai dati in transito di essere automaticamente crittografati e decrittografati a seconda delle funzionalità attive. Tale processo è completamente trasparente all'utente che, se autenticato, vedrà sempre i dati in chiaro. I dati sono
crittografati successivamente con due diversi algoritmi a 256 bit scelti tra quelli oggi considerati “sicuri” dalle agenzie di intelligence dei paesi più industrializzati.
Una conseguenza molto importante dell'adozione di questo modulo è la totale inutilità dei dati
qualora il server fosse sottratto da malintenzionati: senza le chiavi di accesso il tempo stimato
per una forzatura (sia criptoanalitica che brute force) è stimabile in centinaia di anni anche con
l'utilizzo dei più potenti sistemi di calcolo oggi disponibili.
11
La piattaforma, inoltre, implementa un modulo dedicato alla gestione dei LOG del sistema.
Un sistema dettagliato e suddiviso in maniera precisa e puntuale che consente di sapere sempre ed in ogni circostanza chi ha fatto cosa quando e in che modalità.
Il sistema per la gestione dei LOG registra ogni azione (clic) che viene effettuata dall’utente
all’interno
della
piattaforma,
consentendo
di
ricostruire
sempre
la
storia
totale
dell’informazione.
In questa direzione la piattaforma tecnologica ed applicativa per la sanità elettronica eleva notevolmente i livelli di sicurezza nella gestione dei processi, tracciando tutto, identificando in
maniera univoca sia il paziente che l’utente utilizzatore, proteggendo le informazioni da rischi
di intruEPHISne ed acquisizione non autorizzati.
Lo schema logico della piattaforma applicativa prevede i seguenti livelli applicativi (visualizzazione TOP-DOWN):
Applicazioni specifiche (EPHIS-SIT)
Framework Applicativo
Middleware di integrazione
Base dati
12
Figura 1 - Schema architetturale piattaforma
13
Requisiti di sistema
Il sistema ha i seguenti requisiti base:
REQUISITI DELLA PIATTAFORMA APPLICATIVA
Unix
Windows
PIATTAFORMA OPERATIVA - OS
MacOS
Apache2
SERVER WEB
IIS
PHP5
LINGUAGGIO DI
PROGRAMMAZIONE
EstenEPHISni di base: XML, SOAP
Ajax/jQuery
MySQL v.5.x
DATABASE
14
Architettura applicativa della piattaforma
Design Pattern
Il prodotto è realizzato utilizzando il linguaggio di scripting PHP5.
Si basa su un framework che utilizza i più diffusi design pattern, in particolare l'MVC (modelview-controller), dove i flussi di informazione sono gestiti da differenti oggetti: il model gestisce l'interazione con il database e le altre sorgenti di input/output dei dati (XML, HTTP), il view
gestisce l'output, attraverso un sistema di templating che può basarsi direttamente su PHP,
oppure su altri linguaggi descrittivi della pagina (XML, XSLT), accompagnati da un sistema di
caching per velocizzare l'output.
Gerarchicamente l'applicazione consiste di moduli. Ogni modulo altro non è se non una collezione di elementi che abbiano caratteristiche comuni. Dato che la suddiviEPHISne dell'applicazione in moduli è puramente organizzativa e funzionale, si può avere un'applicazione composta
di un unico modulo.
Ogni modulo contiene al suo interno pagine, blocchi, templates, scripts. Le pages (pagine) sono dei contenitori di blocchi. Vengono definite insieme alla loro struttura (utilizzando di default
il grid system fornito da twitter bootstrap) in documenti XML creati all'uopo. Come detto, una
pagina può contenere da 1 a n blocchi. I blocks (blocchi) sono definiti all'interno dell'apposita
cartella. Ogni cartella col blocco contiene le views (viste) del blocco stesso, i controllers e gli
scripts associati (opzionali). Un blocco può avere più viste (ad esempio un blocco clienti può
avere una vista grid, per visualizzarne l'elenco, ed una edit, per modificare le informazioni);
nel caso non sia possibile utilizzare oggetti standard per le viste, se ne possono creare di custom, definendo, in questo caso, in un'apposita sezione dell'applicazione le informazioni di cui
ha bisogno l'oggetto per funzionare. Comunque queste informazioni verranno definite nei settings XML del blocco.
Il controller si occupa dell'interazione tra model e view. Un design pattern, anch'esso tra i più
diffusi, il singleton, gestisce la registrazione delle informazioni temporanee (sesEPHISni, variabili globali), in modo da garantire la sicurezza del sistema e da evitare sovrapposizioni e duplicazioni delle informazioni stesse durante l'esecuzione dell'applicazione.
L'applicazione è modulare, basata su un core predefinito e su moduli aggiuntivi. Partendo
quindi da una base condivisa, ad esempio, sulle varie views, è semplice realizzare views perso-
15
nalizzate o aggiungere comportamenti custom al core system, modulo per modulo. Ogni modulo, pertanto, a seconda delle funzionalità richieste, può ereditare le caratteristiche del core ed
implementare i propri comportamenti, secondo la prassi di sviluppo ormai consolidata della
programmazione ad oggetti.
Il sistema al fine di velocizzare le operazioni e garantire una visualizzazione grafica adeguata
agli standard Web 3.0, fa largo uso di librerie JavaScript, in particolare jQuery, che permette
anche un efficace gestione delle richieste Ajax (HTTP request), le quali garantiscono l'interazione in modo da evitare, ad ogni necessità di i/o, il caricamento dell'intera applicazione.
L'utilizzo della tecnologia Ajax/jQuery permette, inoltre, di applicare al prodotto sistemi di validazione dei dati misti (su client e su server), che impediscono l'inserimento nel database di informazioni non corrette o mal formattate, garantendo in tal modo l'integrità dei dati. Un sistema di cancellazione dei dati a cascata, infine, garantisce l'integrità referenziale delle informazioni contenute nel database.
Per la gestione dei settings, sia dell’intera piattaforma sia del singolo blocco o pagina, è stato
utilizzato gli standard del linguaggio XML al fine di garantire la maggior compatibilità e diffuEPHISne possibile con altre piattaforme applicative e con le diverse tecnologie presenti nel
mondo della sanità, come apparati elettromedicale e/o applicazioni verticali e specifiche.
A tal proposito è' stato creato un parser XML specializzato, per poter gestire tags ed attributi in
un formato che permetta di trasformarne correttamente i contenuti in array PHP.
Per quanto riguarda la gestione di tutte le viste che la piattaforma è in grado di elabora e presentare è stato progettato ed implementato un “view manager”. L'operazione è timeconsuming. E' stato creato un sistema più razionale di gestione dei settings provenienti dai vari
documenti XML.
Il view manager si comporta semplicemente da dispatcher, e chiama le varie classi specifiche
dell'oggetto. Tutte le funzionalità di gestione del view manager sono pertanto state affidate ai
manager dei singoli oggetti.
16
Motore di templating
Per la gestione del motore di templating si è scelto Twig, prodotto da SenEPHISLabs, ovvero
dalla stessa firm che ha creato Symfony. Prodotto robusto, affidabile e con una quantità notevole di opzioni, oltre ad una facilità d'uso che – in definitiva – è uno dei parametri principali
nella scelta di un template engine.
Nonostante si sia scelto Twig come template engine di base, la piattaforma applicativa può accettare anche altri template engines, a seconda dell'opportunità. All'interno della cartella render, per ogni template engine è presente una classe (Template) che si occupa da connettore
tra il framework e il motore. Riproducendo la classe in un altro motore, si può utilizzarlo in applicazioni custom. Ovviamente, in quel caso, occorrerà ridefinire i nuovi templates per adattarli
alla nuova sintassi.
La piattaforma può sostituire il template standard per applicativi specifici e verticali secondo le
seguenti linee:
•
Attraverso il tema. I templates (sia quelli generali, tipo page o block, che quelli di view,
tipo edit o grid) vengono ridefiniti all'interno del tema, rispettando le convenzioni (classi
e id framework-related).
•
Attraverso l'applicazione. Un blocco può avere: un template specializzato (come nella
verEPHISne attuale), ma anche un'implementazione specializzata dei templates standard (tipo edit o grid). Anche una singola pagina può avere un'implementazione specializzata del page template. In questo caso devono essere rispettate le convenzioni del
framework e quelle del tema (css).
Base dati
La piattafomra possiede un suo ORM, basato sul PDO di PHP. Di conseguenza è in grado di gestire database di vario tipo, non esclusivamente MySQL, ma qualunque database che sia riconosciuto da PHP e per il quale siano disponibili i connettori. Nell'eventualità di database non
gestibile direttamente da PHP, sarà comunque possibile collegarsi al database tramite ODBC.
E’ stato scelto l’utilizzo di MySql per implementare la base dati della piattaforma applicativa
sanitaria. Scelta effettuata in linea con in principi adottati nella progettazione e sviluppo
dell’intera piattaforma rispettando i canoni delle tecnologie open source e le esigenze legate
17
alla rappresentazione di processi riguardanti moli di dati elevate e di particolare sensibilità e
delicatezza.
Tale scelta, però, non preclude alcun tipo di utilizzo ed implementazione di differenti basi dati
anche in maniera contemporanea; uno dei punti più importanti, infatti, a cui si è prestata particolare attenzione nello sviluppo della piattaforma è l'accesso alle fonti esterne di informazioni,
in entrata ed in uscita, siano essi files di testo che xml oppure records di database. Nonostante
MySQL sia universalmente riconosciuto come il database più diffuso al mondo, si sono comunque ridisegnate le routines di accesso alle fonti esterne, in modo da poter gestire:
•
fonti differenti
•
database differenti
Lo strumento per la gestione dei dati e della base relativa progettato e sviluppato è un Database Manager all’interno del quale è stata realizzata la gestione del design pattern DAL (Database Astraction Layer), per permettere l'astrazione dei metodi del Database Manager dal tipo di
database.
Sono disponibili drivers per:
CUBRID (PDO)
MS SQL Server (PDO)
Firebird/Interbase (PDO)
IBM (PDO)
Informix (PDO)
MySQL (PDO)
MS SQL Server (PDO)
Oracle (PDO)
ODBC and DB2 (PDO)
PostgreSQL (PDO)
SQLite (PDO)
4D (PDO)
18
Accessi e Sicurezza
Il sistema è ad accesso riservato, con autenticazione dell'utente (login/password), accompagnato da meccanismi di sicurezza e criptazione che evitino attacchi ed intruEPHISni esterne,
oltre a meccanismi di sicurezza aggiuntivi (scadenza della password, numero massimo di tentativi di accesso, formattazione della password, etc.).
Il sistema di sicurezza e gestione utenti, infine, permette la creazione di ruoli e privilegi d'accesso personalizzati, in modo che ogni utente, a secondo dei privilegi concessigli dell'amministratore di sistema, possa accedere in lettura, scrittura (o non possa accedere per niente) a
qualsiasi modulo dell'applicazione.
Per quanto riguarda la gestione della sicurezza sono stati implementati le seguenti funzionalità:
Modifica l'attuale “ricorda password” al login (utilizzo cookies)
Integrazioni login: Captcha
Integrazioni login: Disattivazione account dopo n tentativi falliti
Integrazioni login: Scadenza password
Password criptate con MD5
Profilo utente: Password strength
Inoltre sono stati sviluppate integrazioni e metodi specifici per consentire l’utilizzo delle seguenti tecnologie/piattaforme:
CAS
LDAP
Sistemi di autenticazione FORTE
Theming
E' stato realizzato un sistema di temi, a partire dal tema di default, per permettere, tramite
opportune modifiche al CSS (e ad eventuali modifiche nei templates di default) lo switch da un
tema all'altro, con una semplice modifica alla config.xml.
La creazione di temi custom è stata facilitata dall'utilizzo di un framework tra i più diffusi, se
non il più diffuso al mondo, ovvero bootstrap, creato dagli autori di Twitter.
19
Il vantaggio di bootstrap è quello di riunire, in un unico documento CSS tutti i tags necessari
per la visualizzazione degli elementi grafici e dei campi. Bootstrap contiene inoltre gli script per
la gestione di tutti gli elementi di input delle informazioni e dell'interattività con l'utente.
E' completamente integrato con jQuery (set di routines javascript del quale il framework attuale fa largo uso, e che è a sua volta il framework js più diffuso al mondo).
La piattaforma applicativa, comunque, pur basandosi su bootstrap, ne fornisce una verEPHISne
modificata, per gestire al meglio le sue funzionalità.
In tal modo non solo lo sviluppatore può creare in modo semplice ed intuitivo i propri temi custom, ma può attingere – con un ridotto impegno extra – alla sterminata libreria di temi che
utilizzano bootstrap come base.
Di seguito le modalità configurabili ed utilizzabili nella piattaforma:
Tema di default
Css di default
Temi applicazione
Formati
Mobile compliance - HTML5 compliants e multibrowser
Motore API
E’ stato implementato un motore API (server e client), con le classi necessarie al fine di permettere ad utenti esterni di accedere alle funzionalità della piattaforma.
E' stato creato un sistema di chiavi (keys) che possono essere messe a disposizione (e ritirate
all'occorrenza) degli utenti, e di tagging; il risultato è fornito all'utenza sotto forma di documenti o files XML, customizzabili attraverso chiavi di ricerca al database:
SOAP
XML-RPC
RESTful
20
Middleware integrazione
MiddleWare: Scenario di riferimento
Nel campo dell'informatica sanitaria diventa sempre più centrale nella progettazione e realizzazione di soluzioni riferirsi a degli standard per facilitare l'interoperabilità tra sistemi sanitari informatici diversi.
L'obiettivo di questa viEPHISne è quello di svincolarsi da legami troppo stringenti a sistemi
proprietari chiavi in mano e monoblocco e agevolare lo scambio di dati e informazioni sanitarie
tra sistemi, applicativi e apparati diversi e forniti da partner commerciali distinti.
Ecco quindi l'ambito in cui si deve muovere un progetto di integrazione di sistemi e applicativi
di una struttura sanitaria ospedaliera.
I servizi e i componenti di un sistema ospedaliero possono essere:
•
•
•
•
•
•
•
•
•
•
ADT – Sistema Accettazione DimisEPHISne Trasferimento
CUP – Sistema Unico di Prenotazione
MPI – ANAGRAFICA CENTRALE PAZIENTI
PS – SISTEMA DI PRONTO SOCCORSO
HIS – SISTEMA INFORMATIVO OSPEDALIERO
EMR – dati sanitari del paziente
LIS – sistemi dei laboratori
RIS e PACS – sistemi radiologici
AMBULATORI SPECIALISTICI
PIATTAFORMA AMMINISTRATIVA
Il problema dell'interoperabilità tra le applicazioni informatiche sanitarie nasce dal fatto che
spesso alcune delle soluzioni tecnologiche già presenti ed utilizzate non è conforme agli standard di integrazione descritti in precedenza.
In questa situazione due sono le possibili strade da percorrere per ottenere l'obiettivo di integrare tutte le componenti del sistema ospedaliero:
•
richiedere a tutti i fornitori di applicativi informatici presenti nella struttura ospedaliera
di adeguarsi agli standard di interoperabilità. Sarebbe la strada per ottenere l'integra-
21
zione più omogenea dei sistemi ma comporta problemi tecnici e contrattuali: tecnici
perchè gli applicativi più obsoleti possono essere anche impossibilitati ad offrire la verEPHISne “standard compliant” o perlomeno a farlo in tempi medio-brevi; contrattuali
perchè i fornitori richiederanno l'acquisto di licenze aggiuntive e delle giornate di lavoro
necessarie per completare l'adeguamento.
•
Creare uno “strato intermedio” (MIDDLEWARE) in grado di far dialogare le applicazioni e
i servizi informatici componenti il sistema ospedaliero comprese quelle non “standard
compliant” attraverso la creazione di connettori ad hoc per ognuno dei servizi. In figura
lo schema descrittivo di questa soluzione, che evidenzia come è il MIDDLEWARE che si
occupa di consegnare e ricevere messaggi da tutti i diversi componenti del sistema.
Figura 2 - Schema flussi integrazioni
Questa seconda soluzione è la scelta che è stata presa ed implementata nella
piattaforma tecnologica applicativa per la sanità elettronica cioè è stato creato
un layer intermedio di integrazione in grado di far dialogare i nuovi servizi che si vanno
ad implementare con i diversi “pezzi” già installati del sistema informativo.
22
MiddleWare: Protocolli di comunicazione
Si è fatto in modo di garantire il maggiore spettro possibile di connettori in modo da poter integrare potenzialmente anche sistemi obsoleti o legacy. E' importante distinguere tra la sorgente, le fonti da cui il MIDDLEWARE deve estrarre o interpretare i dati, e la destinazione che
invece rappresenta il sistema in cui il MIDDLEWARE va a scrivere i dati. Elenchiamo i principali
connettori che la piattaforma deve essere in grado di integrare
•
Sorgente
codifiche accettate: xml, hl7, dicom, csv
connettori utilizzabili: tcp listener, database (attraverso obdc/jbdc), web service listener
(soap, xmlrpc, rest), lettore e parser di file di scambio, http listener, hl7 listener, DICOM listener. possibilità di creazione di API dedicate
protocolli di connesEPHISne: TCP/IP, FTP/SFTP, SMB, connessi ad API dedicate
•
Destinazione
codifiche accettate: le stesse viste per la sorgente
connettori utilizzabili: tcp, database writer(attraverso obdc/jbdc), web service sender
(soap, xmlrpc, rest), costruttore di file neutri di scambio, http sender, hl7 sender, DICOM sender, possibilità di creazione di API dedicate
protocolli di connesEPHISne: gli stessi visti per la sorgente
MiddleWare: Sicurezza
Il sistema MIDDLEWARE stesso e i canali di comunicazione da e verso di esso diventano un
nodo critico della rete riguardo alla protezione dei dati trattate e la relativa tutela conforme alla
normativa su privacy e sicurezza. Avendo scelto una piattaforma “Web Oriented” queste sono
le misure tecnologiche vincolanti che la piattaforma di integrazione deve supportare:
23
•
Https
•
Cifratura file system dei device contenenti dati sensibili
•
Sistema di autenticazione forte con crittografia forte sul canale di autenticazione
MiddleWare: Tracciamento delle operazioni effettuate
E' fondamentale che sia completamente tracciabile tutto il percorso di comunicazione tra sorgente e destinazione che porta l'informazione da un'applicazione del sistema ad un'altra distinta e tecnologicamente non omogenea alla prima.
La piattaforma di integrazione potrebbe, ad esempio, recuperare un file in formato .csv di un
referto prodotto da un sistema legacy, proprietario ed “esporla” tramite connesEPHISne diretta
HL7 ad un sistema ospedaliero “Standard Compliant”.
In questo processo i passaggi e le trasformazioni che l'informazione attraversa sono innumerevoli e complessi.
E' allora determinante per il monitoraggio del corretto andamento dei processi di integrazione
che vengano tracciati ed archiviati i seguenti log:
Log del bus: testimonia il corretto funzionamento del MIDDLEWARE durante il
processo o se si sono verificati errori interni, errori di sistema o altri eventi bloccanti
Log sorgente: server a documentare la corretta “entrata” dell'informazione nel sistema MIDDLEWARE attraverso i relativi connettori e protocolli utilizzati
Log destinazione: documenta la corretta “uscita” dell'informazione dal sistema
MIDDLEWARE e la “scrittura” della stessa nel sistema destinazione
24
Scrittura file di log specifici di processo: può essere necessario creare dei log specifici dedicati al particolare processo implementato e che vadano a monitorare
elementi particolarmente dedicati della transazione.
Tutto quanto espresso in precedenza viene evidenziato dallo schema in figura dove in alto abbiamo il “client” di connesEPHISne WEB per l'amministratore del sistema, a sinistra i sistemi
SORGENTE, a destra i sistemi DESTINAZIONE, in basso il REPOSITORY di interscambio dei dati
e al centro il “MOTORE” del sistema.
Figura 3 - Schema architetturale middleware d'integrazione
25
MiddleWare: architettura applicativa
Il middleware di integrazione è di fatto un collettore software che consente la gestione delle interconnesEPHISni per l’incapsulamento e la trasmisEPHISne dei dati fra i vari attori che partecipano ai processi sanitari in modalità operative complete e sicure:
o
web client (standard serve solo java virtual machine e su qualunque sistema operativo)
o
https per la connesEPHISne (sicurezza e cifratura dei dati)
o
possibilità di gestione pluriutente e profili separati
o
consolle in tempo reale di monitoraggio dei processi
o
sistema di alerting in caso di malfunzionamenti
o
log completi di ogni processo e ogni azione del sistema
o
interfaccia di “sorgente” con potenzialità di integrazione multiprocesso e multiprotocollo:
o
codifiche accettate: xml, hl7, dicom, csv, ecc.;
o
connettori utilizzabili: tcp listener, database (attraverso obdc/jbdc), web service
listener (soap, xmlrpc, rest), lettore e parser di file di scambio, http listener, HL7
listener, DICOM listener. possibilità di creazione di API dedicate;
o
protocolli di connesEPHISne: TCP/IP, FTP/SFTP, SMB, connessi ad API dedicate;
o
costruzione di integrazioni “dedicate” con sistemi legacy usando i linguaggi di
programmazione del sistema;
o
o
connettori tra sistema middleware e SOURCE sicuri e cifrati;
interfaccia “destinazione” con potenzialità di integrazione multiprocesso e multiprotocollo:
o
codifiche accettate: xml, hl7, dicom, csv, ecc.;
o
connettori utilizzabili: tcp, database writer (attraverso obdc/jbdc), web service
sender (soap, xmlrpc, rest), costruttore di file neutri di scambio, http sender,
HL7 sender, DICOM sender, possibilità di creazione di API dedicate;
o
protocolli di connesEPHISne: TCP/IP, FTP/SFTP, SMB, connessi ad API dedicate;
o
costruzione di integrazioni “dedicate” con sistemi legacy usando i linguaggi di
programmazione del sistema;
o
connettori tra sistema middleware e DESTINATION sicuri e cifrati.
o
motore interno di trasformazione/integrazione Java
o
sistema di auditing di ogni processo
26
o
possibilità di costruire “trasformazioni” di integrazione qualsivoglia complesse attraverso
wizard di configurazione o javascript puro
o
memorizzazione di tutti i messaggi ed i passaggi delle trasformazioni
o
report e statistiche sull'esito di tutti i processi di trasformazione e integrazione
o
possibilità di archiviare i dati di processo in un repository dedicato
Immediati i vantaggi:
Interfacciamento e integrazione tra sistemi obsoleti e sistemi di nuova concezione,
mantenendo attivi i primi e valorizzando i dati sui secondi (es. dati sistema legacy su
portale web)
Totalmente OPEN SOURCE e WEB oriented
Compliant con tutti gli standard, i protocolli, formati di file e linguaggi più utilizzati
possibilità di interfacciamento con quasi tutti i sistemi e applicativi esistenti
HL7 nativo per la facilitazione di tutte le integrazioni in ambito sanitario
Potenza del motore scalabile a seconda delle dimenEPHISni dei sistemi da integrare e
della mole di dati scambiati nei processi
ProfesEPHISnalità e formazione “su misura” e dedicata alle esigenze del cliente
→
PACS
PACS
Punti di ingresso
Punti di ingresso
nel sistema
nel sistema
RIS
RIS
LIS
LIS
GESTIONE
GESTIONE
AMBULATORI
AMBULATORI
MIDDLEWARE DI INTEGRAZIONE
PS
PS
GESTIONE
GESTIONE
REPARTI
REPARTI
Matrice
di interscambio
dei dati
CUP
CUP
HIS
HIS
Repository di dati clinici e anagrafici
Repository di dati clinici e anagrafici
MPI
MPI
ADT
ADT
CDR
CDR
Figura 4 - Funzionalità Middleware
27
MiddleWare: flussi di integrazione
Le integrazioni fra tutti i sistemi sanitari che afferiscono al EPHIS-SIT sono garantite dal
EPHIS-SIT stesso grazie all'implementazione nativa nella piattaforma degli standard internazionali (HL7, DICOM, XML-CDA) per la trasmisEPHISne e per il trattamento dei dati di tipo sanitario, ponendosi esso stesso come “traduttore” in-out per tutti quei sistemi che non hanno
caratteristiche di questo tipo e che non hanno implementati protocolli e standard internazionali
come quelli suddetti.
I flussi di integrazione già predisposti e sviluppati sono elencati di seguito:
Integrazione dei ricoveri del Pronto Soccorso verso i reparti ospedalieri
o
Pronto soccorso ------------------ EPHIS-SIT
Integrazione dei servizi di Radiodiagnostica
o
Pronto soccorso ------------------ Radiodiagnostica
o
EPHIS-SIT ------------------ Radiodiagnostica
Integrazione dei servizi di Laboratorio clinico-batteriologico
o
Pronto soccorso ------------------ LIS
o
EPHIS-SIT ------------------ LIS
Integrazione dei servizi CUP regionale
o
CUP ------------------ Radiodiagnostica
o
CUP ------------------ EPHIS-SIT
o
CUP ------------------ LIS
Integrazione dei servizi ADT esterni
o
ADT ------------------ Pronto soccorso
o
ADT ------------------ EPHIS-SIT
Integrazione Refertazione ON LINE
o
LIS ------------------ Portale Referti
28
Figura 5 - Integrazione dei servizi ospedalieri
29
EPHIS – Sistema Informativo Ospedaliero
EPHIS: lo scenario e gli obiettivi
“La medicina ha superato quella che può essere definita la “soglia digitale”, imponendosi come
uno dei settori trainanti del mercato ICT, oltre che come uno dei principali consumatori di tecnologia.” (Cagliari – 2009)
Le strutture ospedaliere sono dei macro-sistemi molto complessi all’interno dei quali differenti
profesEPHISnalità lavorano, si confrontano e collaborano con l’obiettivo comune di fornire le
cure adeguate al paziente. E’ fondamentale che in questi processi tutti gli attori partecipanti,
dalle risorse umane a quelle tecnologiche o cliniche, abbiano un accesso alle informazioni da
qualsiasi luogo e sempre e che tali informazioni siano quanto più possibile uniformi e confrontabili tra loro. Si pensi ad esempio allo scambio di informazioni tra i servizi diagnostici di un
ospedale: per esempio nella preparazione di un intervento chirurgico, il medico ha necessità di
consultare i dati relativi all’archivio storico delle immagini radiologiche relative agli esami precedenti del paziente.
Il più delle volte l’applicativo utilizzato all’interno delle differenti specialistiche e/o strutture risulta differente da quello usato per la gestione dei servizi (radiodiagnostici, chimici, etc.), ed è
possibile che si verifichino dei pericolosi casi di omonimia o di lettura errata delle informazioni,
con le conseguenze immaginabili.
Lo stato dell’arte nel nostro paese, ancora oggi, vede la struttura ospedaliera, di piccole-medie
dimenEPHISni, particolarmente frammentata e composta da molteplici “isole informatiche”
all’interno delle le attività sono, il più delle volte automatizzate grazie all’utilizzo di apparati
elettromedicali a cui afferiscono i software applicativi, si pensi ai sistemi RIS/PACS o i laboratori chimico-batteriologici.
Gli obiettivi principali che ci si pone di perseguire, attraverso l’utilizzo di un sistema informativo
ospedaliero come il EPHIS, riguardano proprio quelli di integrare le informazioni e i processi,
offrendo agli operatori sanitari delle strutture, ai medici di base agli specialisti e ai pazienti
stessi l’accesso a servizi altamente tecnologici e fruibili, riducendo notevolmente il rischio clinico.
30
Il sistema informativo ospedaliero EPHIS consente di ottenere e perseguire i seguenti
obiettivi:
Disponibilità in tempo reale di:
o
Dati anagrafici (utenti, operatori, pazienti)
o
Diagnosi
o
Risorse
o
Dati amministrativi e contabili legati alle prestazioni sanitarie
o
Dati statistici su occupazione letti, spese correnti sanitarie, prestazioni erogate, liste di attesa
o
Risultati aziendali nei vari settori
o
Situazione risorse ospedaliere (pronto soccorso, sale operatorie,
grandi diagnostiche)
L’integrazione, centralizzazione e digitalizzazione di tutto questo
patrimonio dati consentirà di elevare significativamente l’efficienza del
“sistema ospedale” migliorando il dettaglio, la completezza e la qualità
e nel contempo riducendo i costi, i tempi e le distanze necessari al
loro ottenimento.
Gestione integrata e unificata di:
o
Ospedali
o
Distretti
o
Dipartimenti
o
Ambulatori
o
URP
o
CUP
o
Servizi amministrativi
La gestione centralizzata ed unificata consentirà un controllo capillare
di tutti gli aspetti sanitari e amministrativi dell’attività aziendale.
Il
sistema
inoltre
consentirà
la
produzione
di
rendicontazioni in tempo reale di tutti i comparti gestiti.
Miglioramento prestazioni sanitarie:
31
statistiche
e
o
Gestione reparti e relative risorse
o
Gestione e controllo in tempo reale dei posti letto anche tra strutture diverse
o
Riduzione drastica del rischio clinico
o
Velocità ed efficienza nel trattamento sanitario del paziente presso
le strutture sanitarie
o
Riduzione tempi di redazione dei documenti sanitari da parte del
personale sanitario
o
Cartella clinica digitale e dematerializzazione
o
Conoscenza e focus immediato sui dati sanitari del paziente in ogni
suo passaggio clinico
o
Disponibilità dei dati sanitari in modo semplice ed efficiente per
tutta la storia clinica del paziente
o
Gestione automatizzata e tracciamento dei trattamenti farmacologici e delle terapie giornalieri
o
Refertazione on line
Questi strumenti consentono:
•
al medico di reparto o specialista di avere a disposizione
ogni informazione sul caso clinico attraverso qualunque
terminale del sistema;
•
al
personale
infermieristico
di
seguire
l’evoluzione
giornaliera e costante delle condizioni cliniche del paziente
agevolando le relative attività di assistenza sanitaria
•
alla
direzione
aziendale
di
controllare
dati,
risorse,
strutture, prestazioni e costi in tempo reale e/o tramite
aggregazioni di dati, report e statistiche
•
al paziente di usufruire di terapie, refertazioni e diagnosi in
tempi e modalità molto più efficienti
•
al medico curante di poter seguire e consultare i dati relativi
agli eventi clinici del paziente presso le varie strutture
aziendali
EstenEPHISne dei servizi informatici all’esterno della rete:
o
Consultazione referti (medico di base e paziente)
32
o
Prenotazione servizi e prestazioni sanitarie
o
ViEPHISne liste d’attesa
o
Funzioni specifiche di comunicazione verso le strutture sanitarie
aziendali per i medici di base
o
Comunicazione sulla cura del paziente tra medico di base e strutture ospedaliere o ambulatoriali
Grazie al sistema informativo unico il medico di base sarà in grado di
seguire anche l’eventuale iter ospedaliero del proprio assistito. Sarà in
grado, inoltre, di comunicare anche in modo attivo con l’equipe
specialistica per segnalazioni particolari riguardo ad anamnesi ed
eventuali incompatibilità terapeutiche del paziente.
Infine sarà possibile rendere disponibili al paziente referti, diagnosi e
terapie anche da casa.
33
EPHIS: le caratteristiche ed i punti di forza
EPHIS è una piattaforma WEB BASED nativa OPEN SOURCE.
Di fatto si configura come un vero e proprio “portale” di servizi sanitari integrati, raggiungibile
ed utilizzabile ovunque ed in qualsiasi momento, consentendo la consultazione dei dati clinicoanagrafici dei pazienti in real-time e la gestione delle attività e dei processi sanitari sia relativi
a strutture ospedaliere che territoriali (ambulatori, consultori, DSM, etc.).
È proprio la sua caratteristica di centralità, relativa alla capacità di erogare servizi sanitari ai
pazienti,
che
vincola
il
EPHIS
ad
essere
altamente
efficiente,
affidabile
e
garante
dell’accessibilità ed integrità dei dati da esso contenuti ed elaborati.
La particolarità e importanza dei dati trattati, dei numeri del sistema in termini di utenti connessi sia in trasmisEPHISne che in consultazione dei dati stessi, della delicatezza e tempestività degli interventi possibili, ci ha indotto a dirigere lo studio e la progettazione di
un’architettura solida, sicura e performante, capace di gestire una base dati sicura ed integra,
di offrire i servizi richiesti e soprattutto di essere scalabile e modulare, aperta a nuove soluzioni
ed implementazioni future.
Il sistema informativo ospedaliero e territoriale integrato si pone al centro di tutti i processi lavorativi, sanitari ed amministrativi, che vengono giornalmente espletati unificando in un'unica
base dati, anagrafica e sanitaria, tutti i servizi presenti nelle strutture sanitarie sia centrali che
territoriali.
Il EPHIS è stato, pensato prima, progettato e sviluppato di conseguenza come una piattaforma
in grado di riunificare tutti i servizi sanitari presenti nelle strutture, principalmente ospedaliere
ma anche territoriali, facendo parlare fra loro direttamente gli interlocutori, come ad esempio il
pronto soccorso con il laboratorio di analisi, i reparti con il laboratorio di analisi, il pronto soccorso con la radiodiagnostica, il pronto soccorso direttamente con i reparti dove vengono ricoverati i pazienti.
Il risultato di questo processo di unificazione dei servizi, dell’integrazione di altre piattaforme
applicative, dell’acquisizione dei dati da e verso la piattaforma in un’ unica grande e completa
base dati consente al EPHIS di partecipare attivamente al processo di formazione del FASCICOLO SANITARIO ELETTRONICO del paziente.
34
Uno degli aspetti fondamentali del EPHIS è la gestione integrata dei processi lavorativi che
giornalmente si espletano nei reparti, suddividendo le macro e micro funzionalità che afferiscono alle differenti profesEPHISnalità (primari, medici, capo sala, infermieri), attraverso lo sviluppo ed implementazione delle cartelle cliniche elettroniche relative alle molteplici specializzazioni.
Le integrazioni fra le varie strutture ospedaliere e territoriali e i servizi da esse forniti ed erogati mette in evidenza un'altra peculiarità del sistema, ovvero la possibilità da parte degli utenti esterni al sistema, medico di base o medici specialistici nonché il paziente stesso, di poter
accedere al sistema, previa profilazione utente appropriata che garantisca ai massimi livelli la
sicurezza dei dati trattati, e di poter consultare ogni informazione ad essi inerenti durante tutte
le prestazioni sanitarie ricevute all'interno delle strutture presenti nel EPHIS.
Le integrazioni fra tutti i sistemi sanitari che afferiscono al EPHIS sono garantite dal EPHIS
stesso grazie all'implementazione nativa nella piattaforma degli standard internazionali (HL7,
DICOM, XML-CDA) per la trasmisEPHISne e per il trattamento dei dati di tipo sanitario, ponendosi esso stesso come “traduttore” in-out per tutti quei sistemi che non hanno caratteristiche
di questo tipo e che non hanno implementati protocolli e standard internazionali come quelli
suddetti.
35
Figura 6 - EPHIS: “gli attori”
Attraverso il EPHIS è possibile reingegnerizzare i processi clinici e ospedalieri che sono
parte integrante dell’organizzazione a beneficio di tutte le attività che saranno quindi caratterizzate da una forte interazione tra le diverse unità operative, grazie soprattutto all'abbattimento dei tempi di scambio delle informazioni.
Questo approccio fa sì che l’eventuale riduzione del personale non vada ad inficiare la qualità
dei servizi sanitari erogati rilanciandoli verso livelli più alti. Non come in passato dove il processo di informatizzazione dell'area clinica non era mai stato affrontato in maniera omogenea e
standardizzata, ma a segmenti disconnessi tra loro, portando così all'utilizzazione di molti
strumenti, anche tecnologicamente avanzati, ma senza un approccio coordinato ed integrato a
livello di processo.
Con il EPHIS invece è possibile riprogettare i processi e gli scambi informativi tra i diversi
attori clinici, anche in ottica di controllo e reporting sul processo, puntando ad una integrazione
tra sistemi informativi presenti.
La flessibilità e la modularità della piattaforma EPHIS consente di ragionare sui processi che si
vogliono e/o devono rappresentare, assemblando le varie funzionalità e modellando i flussi delle informazioni necessarie.
36
Al centro, quindi, viene posto il processo come unità fondamentale da rappresentare attraverso l’utilizzo di strumenti e prodotti efficaci ed efficiente come EPHIS.
Attraverso i servizi proposti sarà possibile, con livelli di assoluta sicurezza nella gestione dei
dati, rendere disponibili verso medici e personale di reparto, specialisti, medici di base, personale amministrativo, direzione aziendale, tutte le informazioni di loro competenza e, con la
realizzazione del Fascicolo Sanitario Elettronico, anche ai pazienti i propri dati clinici.
I principali sottosistemi nei quali si articola il sistema informativo ospedaliero sono elencati di
seguito:
Ospedali
o
Reparti
o
Ambulatori
o
Laboratori clinici
o
Laboratori radio-diagnostici
o
Pronto-soccorso
o
ADT
Distretti
o
Ambulatori
o
Consultori
o
DSM
o
Laboratori
o
Strutture convenzionate
o
Medici e pediatri di base
Direzione aziendale
o
Generale
o
Sanitaria
37
o
Amministrativa
I punti di forza della del sistema informativo ospedaliero emergono direttamente dalle caratteristiche tecnologiche e funzionali della piattaforma:
Centralizzata ed integrata con servizi e sistemi sanitari
Architettura WEB-BASED nativa
Architettura Open Source
Centralizzazione dei dati e dei processi sanitari
Sicurezza e rispetto della privacy attraverso autenticazione forte
Elevata accessibilità e gestione user-friendly delle interfacce
On line every day – all day
Mobile compliance - HTML5 compliants e multibrowser (navigazione con IPAD, palmari,
Notebook, etc.)
38
Figura 7 - EPHIS: macro-funzioni
39
EPHIS: funzionalità e moduli applicativi
Processi Implementati
I processi socio-sanitari implementanti nel sistema informativo ospedaliero EPHIS vengono
elencati di seguito:
Accettazione del paziente
Gestione del ricovero del paziente
Gestione della cartella clinica medica specialistica elettronica
Gestione della cartella infermieristica
Gestione dei trasferimenti del paziente
Gestione delle dimisEPHISni del paziente
Gestione della struttura ospedaliera, dipartimenti, reparti
Gestione statistica delle informazioni
Integrazioni con i servizi ospedalieri (RIS/PACS, Pronto Soccorso, laboratori, tec.)
Di seguito vengono elencati tutte le macro funzionalità del sistema EPHIS:
•
Modulo per la gestione del “cruscotto” utente
Le sotto-funzioni di questo modulo sono elencate di seguito:
o
Gestione richieste trasferimenti ricevute
o
Gestione ricerca terapie e generazione report
o
Gestione referti consulti diagnostici
o
Gestione referti laboratorio chimico-batteriologico
o
Gestione referti radiodiagnostici
o
Gestioni richieste ricoveri da Pronto Soccorso
o
Gestione richieste consulti diagnostici da refertare
o
Gestione grafici e statistiche dati clinici
o
Gestione referti non arrivati
40
•
Modulo per la gestione dell’anagrafica paziente
Le sotto-funzioni di questo modulo sono elencate di seguito:
o
Gestione dati anagrafici
o
Gestione dati contatti d'emergenza
o
Gestione Farmaci
o
Gestione Anamnesi (remota, fiEPHISlogica, familiare)
o
Gestione ricoveri pregressi
o
Gestione indagini strumentali e di laboratorio pregressi
o
Gestione terapie domiciliari
o
Gestione allergie ed intolleranze
o
Gestione visite pregresse
o
Gestione stampe
o
Gestione ricerca
•
Modulo per la gestione dell’accettazione del paziente
•
Modulo per la gestione dei reparti e corsie della struttura ospedaliera
Le sotto-funzioni di questo modulo sono elencate di seguito:
•
o
Gestione Strutture Ospedaliere e Territoriali
o
Gestioni Dipartimenti
o
Gestioni reparti
o
Gestioni Ambulatori
o
Gestioni Stanze e Letti
Modulo per la gestione dei dati clinici del paziente
Le sotto-funzioni di questo modulo sono elencate di seguito:
o
Gestione dati anagrafici paziente
o
Gestione dati accettazione e ricovero
o
Gestione Anamnesi (patologica remota, fiEPHISlogica, familiare, patologica prossima)
41
o
Gestione esame obiettivo (generale, testa, torace, respiratorio, cuore, addome,
urogenitale, muscolo-scheletrico, sistema nervoso)
o
Gestione diagnosi
o
Gestione diaria clinica
o
Gestione cartella clinica medica
o
o
o
o
o
Gestione diario clinico medico
Gestione terapia anti-diabetica
Gestione Glasgow Coma Scale
Gestione richieste esami di laboratorio
Gestione richieste esami strumentali
Gestione richieste esami istologici
Gestione consulti diagnostici
Gestione cartella clinica infermieristica
DRG
Gestione esame obiettivo infermieristico
Gestione monitoraggio leEPHISni
Gestione diario clinico infermieristico
Gestione bilancio idrico
Gestione mobilizzazione
Gestione dimisEPHISni infermieristiche
Gestione terapie
Gestione trattamenti terapeutici
Gestione terapie giornaliere
Gestione allegati
Gestione referti
Gestione referti laboratorio clinico
Gestione referti radiologici
Gestione referti consulti diagnostici
Gestione ECG
Gestione consulti
•
Modulo per la gestione dell’assegnazione posti letto
•
Modulo per la gestione dei trasferimenti dei pazienti
•
Modulo per la gestione delle dimisEPHISni dei pazienti
Le sotto-funzioni di questo modulo sono elencate di seguito:
o
Gestione dimisEPHISni in codice 5
o
Gestione dimisEPHISni in codice 8
42
•
Modulo per la gestione epicrisi
•
Motore per la generazione di REPORT
Le sotto-funzioni di questo modulo sono elencate di seguito:
•
•
o
Gestione elaborazione report
o
Gestione memorizzazione report
Modulo per la gestione dei laboratori di analisi
Le sotto-funzioni di questo modulo sono elencate di seguito:
o
Gestione esami di laboratorio
o
Gestione set esami per reparto
o
Gestione multi-laboratorio
Modulo per la gestione dei gruppi
Le sotto-funzioni di questo modulo sono elencate di seguito:
o
Gestione diritti sulle aree
o
Gestione accessi ai campi
•
Modulo per la gestione degli utenti
•
Modulo per la gestione della stampa del braccialetto e del codice a barre identificativo del paziente
•
Modulo per la ricerca e consultazione dei ricoveri storici pregressi
•
Modulo per la gestione delle Stampe
Le sotto-funzioni di questo modulo sono elencate di seguito:
o
Scheda accettazione
o
Scheda Anamnesi
o
Scheda Esame obiettivo
43
•
o
Certificato di degenza
o
Dichiarazione dimisEPHISni volontarie
o
Scheda rifiuto della prestazione
o
Scheda Terapie
o
Cartella Clinica
o
Braccialetto
Modulo per la gestione delle ricerche
Le sotto-funzioni di questo modulo sono elencate di seguito:
o
Ricerca pazienti a testo libero
o
Ricerca pazienti secondo filtri
44
EPHIS: cartelle cliniche specialistiche
Di seguito vengono elencatele cartelle cliniche specialistiche del sistema EPHIS per alcune delle
quali vengono elencate le funzionalità specifiche-verticali sviluppate in aggiunta ai moduli applicativi sopra descritti:
•
Cartella clinica specialistica di geriatria
•
Cartella clinica specialistica di medicina interna
•
Cartella clinica specialistica di chirurgia generale
•
o
Gestione Anamnesi (fiEPHISlogica, familiare, patologica prossima)
o
Cartella Infermieristica ( Esame obiettivo chirurgico )
o
Interventi chirurgici
Cartella clinica specialistica di neonatologia
o
Dati genitori (genitori, gravidanze precedenti, gravidanza attuale, dati parto,dati
neonato)
o
Anamnesi fiEPHISlogica pediatrica
o
Esame obiettivo neonato
•
Cartella clinica specialistica di osservazione breve
•
Cartella clinica specialistica di pediatria
o
Dati genitori (genitori, gravidanze precedenti, gravidanza attuale, dati parto, dati
neonato )
•
o
Anamnesi fiEPHISlogica pediatrica
o
Esame obiettivo neonato
Cartella clinica specialistica di ginecologia
45
•
•
•
o
Anamnesi fiEPHISlogica ginecologica
o
Anamnesi ginecologica remota
o
Anamnesi ostetrica remota
o
Anamnesi patologica prossima ginecologica
o
Esame obiettivo ginecologico
o
Partogramma
o
Scheda parto
Cartella clinica specialistica di ostetricia
o
Anamnesi ostetrica remota
o
Anamnesi patologica prossima ostetrica
o
Esame obiettivo ostetrico
o
Partogramma
o
Scheda parto
Cartella clinica specialistica di otorinolaringoiatria
o
Anamnesi patologica prossima OTL
o
Esame obiettivo OTL
o
Intervento chirurgico OTL
Cartella clinica specialistica infermieristica
o
DRG
o
Gestione esame obiettivo infermieristico
o
Gestione monitoraggio leEPHISni
o
Gestione diario clinico infermieristico
o
Gestione bilancio idrico
o
Gestione mobilizzazione
o
Gestione dimisEPHISni infermieristiche
46
