Sanità elettronica: sperimentazione della ricetta on-line in Campania e Piemonte

Articolo tratto da ICT4Health

In Piemonte e in Campania, con l’arrivo del 2010, parte in via sperimentale per sei mesi un progetto che prevede la possibilità per i farmacisti di prendere carico on line delle ricette dei Medici di Medicina Generale e dei Pediatri di Libera Scelta.

Sarà sufficiente che il medico compili la ricetta sul suo computer e la invii alla rete al ministero della salute: a questo punto sarà pronta per essere letta dal farmacista, che quando il paziente si presenterà con la propria tessera sanitaria si collegherà al sito del ministero e, previa verifica della prescrizione, consegnerà le medicine.

In questo modo i pazienti potranno evitare di recarsi negli studi dei medici e di fare estenuanti code; qualora fossero presenti per una visita, potranno comunque avere copia cartacea della prescrizione. Il progetto è stato realizzato da Sogei, la società di information technology del ministero dell’economia e delle finanze che ha sviluppato il software necessario ad avviare la nuova rivoluzione da consegnare ai professionisti. Oltre al servizio reso al paziente, l’obiettivo del ministero è ovviamente il controllo della spesa farmaceutica e il risparmio della carta.

Articoli Correlati

Sanità elettronica: sempre più presente nell'agenda della Comunità Europea

Articolo tratto da ICT4Health.

La sanità elettronica riceve sempre più impulso da parte degli Organismi dell’Unione Europea, mentre si moltiplicano i progetti che puntano ad accelerare la crescita del mercato, a promuovere l’interoperabilità e ad abbattere le barriere legali ed amministrative ancora presenti.

All’interno degli organismi UE, il nostro Paese sta contribuendo alla definizione dei meccanismi e delle logiche alla base dello sviluppo e dell’integrazione dei vari servizi sanitari nazionali. Secondo quanto dichiarato il 2 dicembre a Bruxelles – in occasione del Consiglio dei Ministri della salute dell’Unione Europea – dal viceministro per la salute, Ferruccio Fazio, «la Sanità elettronica è uno dei punti cruciali intesi a garantire il controllo delle prestazioni sul territorio, sia dei medici di medicina generale, sia delle strutture ospedaliere».

Proprio in riferimento a quanto fino adesso è stato fatto a livello europeo in tema di e-Health, all’inizio di ottobre è stata presentata dalla Commissione Europea una relazione aggiornata sulle iniziative comunitarie nel settore. In prima battuta, è emerso che la maggior parte delle iniziative programmate è stata avviata e che le scadenze e gli step sono stati rispettati. I progetti che rientrano negli interventi comunitari di e-Health hanno come obiettivo primario l’interoperabilità dei dati tra le 27 nazioni che compongono l’Unione Europea. La Commissione Europea continua a porre particolare enfasi sulla necessità di creare una maggiore disponibilità economica, nonostante la crisi, in misura tale da consentire un maggiore sviluppo dell’e-Health e, di conseguenza, anche un’apprezzabile crescita del mercato, che è stato incluso tra i settori chiave della crescita comunitaria (insieme a tessile protettivo, edilizia sostenibile, riciclaggio dei rifiuti, produzione biologica ed energie rinnovabili).

Tra le principali iniziative spiccano la definizione di linee guida sull’interoperabilità transnazionale, in vista dell’adozione del Fascicolo Sanitario Elettronico, a cui è legato a doppio giro il Progetto EPSOS (Smart Open Service for European Patients), che punta a sviluppare l’interoperabilità delle cartelle e delle prestazioni cliniche elettroniche; lo sviluppo della Rete Calliope (Call for Interoperable eHealth services in Europe), che consentirà di mettere a disposizione dell’intero settore sanitario europeo i risultati del progetto pilota SOS (Smart Open Service) che punta a garantire la compatibilità delle informazioni mediche in formato elettronico indipendentemente dalla lingua o dalla tecnologia utilizzata; il progetto “Good Health for All”, che ha l’obiettivo di rendere l’Europa più sana e più competitiva attraverso la condivisione delle responsabilità per la salute tra cittadini, Governi ed istituzioni UE.

Articoli Correlati

Amministratori di sistema: un sistema di log open source

Domani entra in vigore il famigerato decreto sugli amministratori di sistema.

Questa è una soluzione che abbiamo sviluppato e che proponiamo ai nostri clienti per quanto riguarda la parte tecnica, gestione dei log degli accessi degli amministratori di sistema.

Nel pieno rispetto dell’open source presentiamo una soluzione a basso costo utilizzando sistemi liberamente scaricabili da internet.

Sistemi per la gestione dei log ne esistono di tutti i tipi e per tutte le tasche ma, leggendo le caratteristiche di molti a pagamento… abbiamo subdorato che molto spesso sono dei pc embedded con programmi open source venduti a svariati migliaia (se non decine di migliaia) di euro. Vediamo come fare utilizzando la rete.

Prendimao un pc con una buona dotazione di spazio disco (e poi vedremo perchè) e installiamoci una distribuzione open source linux (noi lavoriamo con ubuntu… ma il discorso si puo’ fare con qualsiasi altra distribuzione avendo l’accortezza di utilizzare i comandi adeguati).

A questo punto montiamoci un server MySql e quindi utilizziamo come log server centralizzato il sistema Syslog-ng per salvare tutti i dati sul database menzionato.

Seguendo le direttive trovate sul seguente link:  http://www.openskill.info/infobox.php?ID=1466

Innanzitutto e’ necessario  connettendosi a mysql con il comando mysql -u username -p passwhord -h 127.0.0.1 e creare il database che conterra’ i log con il comando create database db_log;.
Si presuppone che mysql sia in esecuzione sullo stesso sistema del syslog server ed in ascolto sull’indirizzo di loopback.
Una voltra create il database si suggerisce di creare un utente apposito che abbia i privilegi sullo stesso, in modo di evitare di utilizzare l’utenza di root. Anche in questo caso e’ necessario loggarsi al dbms con un mysql -u username -p password -h 127.0.0.1 ed eseguir eil seguente comando:
GRANT ALL PRIVILEGES ON db_syslog.* TO syslog_user@127.0.0.1 IDENTIFIED BY 'syslog_password'.
L’ultima operazione da eseguire sul database e’ la creazione della tabella che conterra’ i messaggi syslog salvati da syslog-ng. Tale operazione puo’ essere portata a termine con il comando mysql -u syslog_user -p syslog_password -h 127.0.0.1 < syslog_table.sql .
syslog_table.sql sara’ un file di testo contenente le istruzione per creare la tabella, e dovra’ contenere le seguenti linee:

#
# Table structure for table `logs`
#

CREATE TABLE logs (

host varchar(32) default NULL,
facility varchar(10) default NULL,
priority varchar(10) default NULL,
level varchar(10) default NULL,
tag varchar(10) default NULL,
date date default NULL,
time time default NULL,
program varchar(15) default NULL,
msg text,
seq int(10) unsigned NOT NULL auto_increment,

PRIMARY KEY (seq),

KEY host (host),
KEY seq (seq),
KEY program (program),
KEY time (time),
KEY date (date),
KEY priority (priority),
KEY facility (facility)

) TYPE=MyISAM;

Ovviamente nel caso il file syslog_table non sia nella stessa directory dalla quale viene lanciato il client mysql sara’ necessario specificare il percorso del file in questione.
Una volta predisposta la parte relativa al database, e’ stata aggiunta la seguente destinazione al file di configurazione di syslog-ng /etc/syslog-ng/syslog-ng.conf:

#file di destinazione con query sql che saranno processate dal feeder
destination file_sql {
file(“/var/log/sqllog/log_sql_$HOUR.$MIN”
template(“INSERT INTO logs (host, facility, priority, level, tag, date, time, program, msg) VALUES ( ‘$HOST’, ‘$FACILITY’, ‘$PRIORITY’, ‘$LEVEL’, ‘$TAG’, ‘$YEAR-$MONTH-$DAY’, ‘$HOUR:$MIN:$SEC’,’$PROGRAM’, ‘$MSG’ );n”)
template_escape(yes));
};

Questa direttiva fa in modo che all’interno del file /var/log/sqllog/log_sql_ORA.MINUTO vengano inserite una serie di istruzioni INSERT SQL che una volta eseguite dal client mysql andranno ad inserire i dati nella tabella logs del database db_syslog.
A meno che nel file di configurazione di syslog-ng non sia posta a yes l’opzione create_dirs sara’ necessario creare la directory /var/log/sqllog ed impostare dei permessi coerenti con le opzioni owner, group, perm, dir_owner, dir_group e dir_perm se definite nel file di configurazione di syslog-ng.
Inoltre, come si puo’ notare dall’opzione file della direttiva destination, non verra’ creato un singolo file ma diversi a seconda dell’ora e del minuto in cui verranno generati. Tale scelta si e’ resa necessaria per semplificare la creazione e l’esecuzione dello shellscript che eseguira effettivamente gli inserimenti nek database e che verra’ successivamente illustrato.

Infine, la nuova destinazione creata dovra’ essere utilizzata all’interno di una direttiva log del file /etc/syslog-ng/syslog-ng.conf perche’ qualcosa possa essere scritto all’interno del file /var/log/sqllog/log_sql_ORA.MINUTO:

#log query per il feeder
log { source(s_all); destination(file_sql); };

Con questa configurazione, pero’, nessun dato viene ancora scritto all’interno del database ma vengono solo scritte delle istruzioni INSERT nei file /var/log/sqllog/log_sql_ORA.MINUTO.
E’ quindi necessario creare uno script che prenda questi file e inserisca effettivamente i log all’interno del database, ad esempio /opt/syslg-db/feeder.sh:

#!/bin/bash
# Script adattato da process_logs di  Casey Allen Shobe

dbhost=”localhost”
dbuser=”syslog_user”
dbpass=”syslog_password”
dbname=”db_log”
datadir=”/var/log/sqllog”

while true; do
logfiles=`find $datadir -name “log_sql_[0-2][0-9].[0-5][0-9]”`
sleep 70 # This is to ensure we don’t screw up a log currently being written.
for logfile in $logfiles; do
cat $logfile | mysql –user=$dbuser –password=$dbpass $dbname
if [ $? -ne 0 ]; then
echo “[ERRORE] Problema nel processare il file $logfile!!!” >> $datadir”/feeder_log.log”
#exit 1 #Comment out this line if you want the script to
else
echo “[OK] $logfile inserito nel db in data `date –rfc-3339=seconds`” >> $datadir”/feeder_log.log”
rm -f $logfile
fi
done
done

Nella parte iniziale dello script vengono definite alcune variabili d’ambiente che indicano i parametri da utilizzare per la connessione al database e la directory dove si trovano i files scritti da syslog-ng contenenti le istruzioni inserti da eseguire.
Un aspetto importante dello script e’ l’istruzione sleep 70 eseguita all’interno del ciclo while dopo avere settato la variabile contenente i nomi dei file da processare durante l’iterazione corrente. Quando eseguita essa sospende l’esecuzione dello script per 70 secondi, in modo da impedire che possa essere processato un file in corso di scrittura da parte di syslog-ng.
Poiche’ la destination definita nel file di configurazione di syslog-ng, prevede la creazione di un nuovo file di log ogni minuto (grazie all’utilizzo della macro $MIN), con una sleep di 70 secondi si avra’ la sicurezza che i files definiti nella variabile logfiles non siano piu’ oggetto di scrittura, essendo trascorsi almeno 60 secondi dalla loro creazione.
Per ognuno di questi file, infine, vengono eseguite le istruzioni INSERT in essi contenute passandole in input al client mysql tramite la linea cat $logfile | mysql --user=$dbuser --password=$dbpass $dbname.
Una volta processato, il file viene rimosso tramite il comando rm -f. Lo script verifica inoltre l’exit code del comando mysql ed in base ad esso scrive l’esito del processing del file in /var/log/sqllog. Questa operazione puo’ anche essere considerata superflua ed evitata semplicemente commentando le due istruzioni echo all’interno del ciclo for.
Infine, per automatizzare l’utilizzo dello script feeder.sh e’ possibile modificare lo script /etc/syslog-ng/syslog-ng in modo da avviare e terminare automaticamente feeder.sh insieme al syslog server:

#!/bin/sh
#
[…]

start() {
echo -n $”Starting $prog: ”
daemon $exec $SYSLOGNG_OPTIONS
retval=$?
echo
[ $retval -eq 0 ] && touch $lockfile
echo “Starting Feeder”
/opt/syslg-db/feeder.sh &
return $retval
}

stop() {
echo “Stopping Feeder”
killall feeder.sh
echo -n $”Stopping $prog: ”
killproc $prog
retval=$?
echo
[ $retval -eq 0 ] && rm -f $lockfile
return $retval
}

[…]

Bene a questo punto il server è a posto, ricordandosi di abilitare la ricezione dei log remoti modificando una riga su /etc/syslog-ng/syslog-ng.conf . La riga in questione comincia con #udp(). Cancellate il carattere #, salvate riavviate il server syslog- Bene il sistema è quasi pronto.

Passiamo ai clients.

Se i client sono linux, nessun problema, installate su tutti il demone syslog-ng e modificatene il contenuto aggiungendo le seguenti righe:

destination d_loghost  { udp(“ip_server_log”);  };

log { source (s_all); destination (d_loghost);};

Riavviate sui client il demone syslog-ng e il server comincerà a ricevere i log.

Passiamo ai clienti Windows (per client, intendo server windows che manderanno i log sul server di log centralizzato)

Per windows ho testato  Snare Agent per windows, un pacchetto open source che installa un servizio per il log degli eventi su windows ed è amministrabile tramite una pagina web. L’installazione si limita al solito doppio click sull’eseguibile, all’impostazione della password ed alla scelta se permettere o meno l’accesso remoto alla pagina di configurazione del servizio. Per effettuare la configurazione è sufficiente puntare il browser su localhost:6161. Utente e password di default sono snare/snare, da cambiare immediatamente.

La configurazione da impostare per avere il log remoto è sulla pagina network. Basta impostare  Destination Snare Server address con l’indirizzo ip del server di log e come  destination  port  514. Attivare Enable Syslog  Header e selezionare come syslog facility auth, con livello notice.

Stanchi? un attimo di pazienza tra un po’ è finito.

A questo punto abbiamo tutti i nostri log su un server mysql. La normativa ci impone di salvarli su supporti non modificabili (cd o dvd in pratica).

Lo risolviamo in questo modo:

Scriviamo un piccolo script che ad una certa ora (impostata con cron) viene eseguito per estrarre i dati dal database e scriverli in un file che poi recupereremo per trasferirlo in un cd  e/o DVD.

lo script è il seguente:

#!/bin/bash
dbhost=”localhost”
dbuser=”syslog_user”
dbpass=”syslog_password”
dbname=”db_log”
filebackup=backup-log-$(date +%d-%m-%Y –date=”yesterday”)
/usr/bin/mysql –user=$dbuser –password=$dbpass $dbname < /opt/syslg-db/query.sql > /home/log/$filebackup.txt
gzip /home/log/$filebackup.txt

il contenuto del file sql query.sql è questo:

select * from logs where date=(select curdate() – interval 1 day);

Per recuperare il tutto abbiamo utilizzato il servizio ftp (il server  non ha monitor e/o tastiera). Installiamo il demone proftpd, lo configuriamo e creiamo un utente log. A questo punto, a tempi prefissati, ci recuperiamo i files da scrivere sui CD e/o DVD

Alcune note di prestazione: da un nostro cliente con una decina di server e con circa 100 client con tale sistema in meno di cinque giorni abbiamo un db con oltre 2 milioni di righe!!!!  Diventa importante quindi eseguire ogni tanto un task per cancellare dal db i record vecchi di n giorni ( a questo punto è banale l’implementazione).

Altra nota: il garante ci dice che dobbiamo loggare anche tutti gli accessi degli amministratori sui pc che trattano dati pernonali e/o sensibili.. i log diventeranno ancora di più.

Abbiamo finito, questa è una soluzione che abbiamo ritenuto soddisfacente i requisiti minimi del garante (a seguito anche di incontri con esponenti del Garante stesso). Non saraà perfetta, sarà migliorabile, ma funziona.

Attendiamo commenti

Articoli Correlati

Amministratori di sistema: precisazione del Garante

Notizia tratta da www.garanteprivacy.it

 

Amministratori di sistema: precisazioni del Garante

In vista della scadenza del 15 dicembre, termine entro il quale imprese e altri soggetti interessati devono adeguarsi alle prescrizioni impartite a suo tempo in materia di amministratori di sistema, l’Autorità per la protezione dei dati personali ritiene opportuno precisare alcuni aspetti, anche allo scopo di evitare ingiustificati oneri per le aziende.

L’Autorità, nel rilevare il generale impegno da parte delle imprese ad adempiere alle prescrizioni impartite con il provvedimento del 27 novembre 2008, ha infatti constatato che informazioni imprecise o anche talune azioni promozionali da parte di consulenti rischiano di disorientare alcune aziende, soprattutto quelle di piccole dimensioni, esponendole a immotivati aggravi economici.

L’Autorità intende dunque ribadire quanto segue:

  • le prescrizioni riguardano solo quei soggetti che, nel trattare i dati personali con strumenti informatici, devono ricorrere o abbiano fatto ricorso alla figura professionale dell’amministratore di sistema o a una figura equivalente.
  • le prescrizioni non si applicano, invece, a quei soggetti anche di natura associativa che, generalmente dotati di sistemi informatici di modesta e limitata entità e comunque non particolarmente complessi, possano fare a meno di una figura professionale specificamente dedicata alla amministrazione dei sistemi o comunque abbiano ritenuto di non farvi ricorso.

Per quanto concerne, infine, gli aspetti tecnici del provvedimento (in particolare, la conservazione dei log degli accessi effettuati dagli amministratori di sistema), il Garante ricorda come l’adeguamento possa avvenire anche con soluzioni a basso costo, validamente proposte e disponibili in rete (per esempio basate su software gratuito, anche con licenze di tipo open source), che possono costituire valide alternative all’impiego di prodotti commerciali o di apparati più sofisticati.

Roma, 10 dicembre 2009

Articoli Correlati