[DE | EN | FR | IT | JA | KO |

Benvenuti ad un altro numero di Brave GNU World. Lo sospettavamo, ma questo numero ne ha le prove: il Software Libero fa bene alla salute!

Debian-Med

Come in diversi altri campi, nel settore delle applicazioni mediche c'è una gran quantità di progetti che sono talvolta piuttosto avanzati, ma metterli assieme o integrarli in un'unica soluzione è fuori dalla portata di qualsiasi utente "normale". Per trovare una soluzione a questa situazione, Andreas Tille diede inizio al progetto Debian-Med [5] agli inizi del 2002, con lo scopo di personalizzare la distribuzione Debian per gli utenti in campo medico e microbiologico, e di integrare i progetti software in questo settore.

I lettori abituali di Brave GNU World potrebbero vedere un richiamo al il progetto Debian-Jr. [7] presentato nel numero 23 [6], ed in effetti l'idea di Debian-Med è stata ispirata da quel progetto.

Specialmente il software che interagisce con la sfera privata e profondamente intima della vita umana - come nel caso dei medici - deve soddisfare determinati criteri che attualmente solo il Software Libero può soddisfare pienamente.

Deve per esempio assicurare che siano mantenute la confidenzialità e la sicurezza dei dati del paziente. Ciò richiede una certa trasparenza, che è assicurata al meglio attraverso il processo di sviluppo Libero.

Inoltre la salvaguardia nei confronti della perdita di dati può essere molto importante, poiché alcuni esami sono rischiosi per la salute e talvolta non possono essere ripetuti. Se i dati venissero persi, sarebbe indubbiamente ridotta la qualità del servizio sanitario; causando allo stesso tempo una perdita di fiducia di un paziente verso il medico.

Per quanto detto, questo settore necessita di un fondamento (il sistema operativo) sicuro, affidabile e stabile per applicazioni di questo tipo. Utilizzare Software Libero sta diventando sempre più una necessità per ogni medico consapevole.

Ovviamente, la riservatezza, la protezione dei dati, la fidatezza e la sicurezza sono al primo posto nell'elenco degli obiettivi di Debian-Med.

Altre questioni centrali sono - come dovrebbe essere - la facilità d'uso, di installazione e di amministrazione.

La facilità d'uso previene gli errori e le frustrazioni, entrambi giocherebbero a sfavore del paziente in questo campo. Inoltre, l'installazione e l'amministrazione semplici assicurano che i medici consapevoli abbiano minori problemi migrando al Software Libero, dando loro un aiuto pratico.

Attualmente il progetto, del quale fanno parte Andreas e circa altre 70 persone interessate, si focalizza nel trovare le soluzioni ad ogni problema comune e nel renderlo pronto all'installazione.

La prospettiva a medio termine è quella di presentare ai medici Debian-Med come reale alternativa e di creare un CD dimostrativo.

Le aree nelle quali c'è maggiormente bisogno di aiuto sono la documentazione e la traduzione, inoltre manca ancora un logo. Per questo, Andreas ha in mente una combinazione del logo Debian con un serpente.

La situazione della licenza dell'intero progetto è determinata dalle singole licenze software, naturalmente. Viene privilegiato Software Libero la cui licenza sia approvata secondo le linee guida Debian per il Software libero ("Debian Free Software Guidelines (DFSG)").

Sfortunatamente il progetto prevede anche di includere software proprietario che sia distribuibile gratuitamente, costituendo un punto debole per le prospettive a medio e lungo termine. Ma se un numero sufficiente di persone esprimessero il loro desiderio di prestare attenzione al lungo termine, sono sicuro che la cosa non sia scolpita nella pietra.

Portare il Software Libero in campo medico è qualcosa che ho sempre considerato piuttosto importante e se se state cercando un progetto utile nel quale cimentarvi, Debian-Med è con molta probabilità una buona scelta.

Gnumed

Tra i programmi inclusi in Debian-Med c'è Gnumed [8], un progetto ufficiale di GNU per l'esercizio medico senza l'utilizzo di carta.

Il progetto nacque in Australia, dove ebbe luogo nel Marzo del 2000 una accesa discussione sui pericoli del software proprietario nella sanità. I medici si rifiutavano di basare le proprie decisioni su algoritmi non trasparenti. Nella discussione Hors Herb venne accusato di criticare in maniera non costruttiva, che fu la molla che lo spinse ad iniziare a lavorare su Gnumed.

Dopo che una primo rilascio in versione alpha funzionante venne presentato al MedInfo2001 di Londra, l'interesse internazionale per Gnumed rese necessaria una totale riprogettazione della struttura interna necessaria. Implementare questa nuova struttura è attualmente il compito principale dei coordinatori del progetto Horst Herb e Karsten Hilbert, che lavorano a questo con circa 17 sviluppatori e diversi volontari.

Dopo aver completato una versione minimale, che sperano sia già utile, è in programma di rendere Gnumed una soluzione completa che includa il supporto decisionale.

I problemi che Gnumed trova sulla sua strada sono la mancanza di un database farmacologico libero, differenti sistemi sanitari con differenti leggi, mancanza di formati di dati, standard di trasmissione e protocolli di comunicazione standardizzati e la mancanza di un sistema per creare un identificativo del paziente univoco in tutto il mondo.

Il linguaggi di programmazione utilizzati in questo progetto sono il Python ed il C/C++ lato client, PgSql, C e Python lato server, con affidabilità e sicurezza come paradigmi più importanti; entrambi i quali non sono trattati adeguatamente secondo l'opinione del gruppo Gnumed.

In ogni caso: il gruppo di Gnumed è composto principalmente da medici di differenti settori, che sanno molto bene ciò che vogliono, ma spesso non altrettanto bene come implementarlo. Perciò sarebbe molto gradito se programmatori con più; esperienza si unissero al gruppo di lavoro.

Gnumed, che mira ad avere una GUI semplice, ergonomica ed altamente configurabile, supporto per diverse lingue e sistemi sanitari così come una relativa indipendenza dalla piattaforma, è pubblicato come Software Libero secondo la Licenza Pubblica Generica GNU (GNU GPL).

Se desiderate attivarvi in questo settore, Gnumed è sicuramente un progetto dove vale la pena farlo.

OIO

Il programma "Open Infrastructure for Outcomes" (OIO) [9] (Infrastruttura aperta per gli esiti, N.d.T) è chiamato dal suo autore, Andrew Ho, "La ricerca del Sacro Graal" della portabilità dei dati. Nandalal Gunaratne, Alesander Chelnokov ed altri lo accompagnano in questa ricerca.

OIO è stato utilizzato in produzione al centro medico Harbor-UCLA nel Marzo del 2000, prima ancora di essere pubblicato come Software Libero sotto la Licenza Pubblica Generica (GNU GPL) in Agosto. In Settembre gestiva già i dati di 1000 pazienti e fin dal Febbraio 2002 viene utilizzato come sistema informativo di tutto l'ospedale. Quindi è corretto dire che OIO ha già dato prova di se nell'utilizzo quotidiano.

I principali componenti di OIO sono il server, al quale si accede attraverso un browser web e la libreria OIO. Il server è un sistema di gestione dati via web flessibile, che gestisce utenti, pazienti e loro informazioni; sebbene sarebbe anche possibile utilizzarlo per clienti, fatture, spedizioni o contabilità.

La libreria OIO è un "metadata repository", che consente lo scambio di "metadata" come form web plug-and-play o di descrizioni di progetti tra il server e l'utente.

Un utente di OIO può creare o modificare le forms attraverso un browser web, le quali sono poi immediatamente disponibili per essere utilizzate per la raccolta dati attraverso il web.

Successivamente le forms possono essere esportate come dati XML per essere trasferite in un "metadata repository" come la libreria OIO o caricate su un altro server OIO.

Naturalmente è anche possibile mettere i dati di diverse forms in un unico dataset sul quale fare successivamente ricerche attraverso il web con l'aiuto di operazioni logiche.

Sebbene OIO sia già stato utilizzato per qualche tempo, il suo sviluppo non è terminato. Tra le funzionalità pianificate in futuro c'è il supporto per i PDA wireless e saranno anche supportati i protocolli plug-and-play. Avere più utenti, più informazioni di ritorno e miglior impacchettamento sarebbe al momento di maggior aiuto.

Debian-Med dovrebbe aiutare almeno per l'ultimo punto.

Res Medicinae

Anche Res Medicinae [10] di Christian Heller è utilizzato dal progetto Debian-Med. Assieme a Karsten Hilbert stà lavorando per rendere Res Medicinae la soluzione software completa nel settore medico.

Per ottenere la massima portabilità, Res Medicinae è basato su Java (API/Swing, Servlets/JSP, JDBC) con un po' di CORBA/IDL e SOAP/XML. Questo già mostra il più grosso problema di questo progetto di Software Libero sotto la Licenza Pubblica Generica GNU (GNU GPL) e Licenza per Documentazione Libera (GNU FDL), poichè, mancando una completa implementazione libera di Java, la libertà del progetto è in pericolo.

Ma la libertà è stato il fattore motivazionale più importante affichè Christian cominciasse a lavorare a Res Medicinae. Sembra surclassare i sistemi informativi medici estremamente costosi e proprietari e fornisce agli utenti dei paesi meno privilegiati l'accesso a un sistema libero, stabile, sicuro, indipendente dalla piattaforma e vasto.

Il progetto è ancora piuttosto acerbo. Stando a quanto pianificato, per la fine del 2002 l'ambiente di lavoro ResMedLib dovrebbe essere consolidato e dovrebbero essere disponibili due moduli completi. Nel 2003, il modulo amministrativo, i moduli di stampa e i report dovrebbero funzionare.

Alla fine dovrebbero essere aggiunti un modulo per la manipolazione e gestione delle immagini ed un modulo per la fatturazione e le statistiche. Un modulo per l'addestramento ed un modulo di supporto decisionale dovrebbero poi completare il progetto.

Non dovreste provare ad utilizzare il progetto per il lavoro quotidiano, ma coloro che sono interessati a portare la propria competenza medica, traduzioni, programmazione Java o progettazione di pagine web riceveranno una calorosa accoglienza in Res Medicinae.

Per quanto a conoscenza degli autori, Res Medicinae è attualmente l'unico progetto GPL basato su Java nel settore medicale ed essi hanno intenzione di lavorare con OpenEMed - un progetto simile sotto licenza BSD - ed il già citato progetto Gnumed per raggiungere l'interoperabilità

Per oggi dovrebbe bastare con la sanità, se ci sono altri progetti in questo settore, vorrei illustrarli in un prossimo numero. Una email [1] sarebbe il modo giusto per far si che questo avvenga.

Romance

Romance [11] è il tentativo di Bertrand Lamy e Jean-Baptiste Lamy, di dare al Software Libero una reale e libera alternativa a .NET di Microsoft.

Secondo Bertrand, la loro motivazione è che Ximian probabilmente non sarà in grado di rilasciare una implementazione libera di .NET. Il fatto che Microsoft abbia già promesso di combattere tutte le alternative libere utilizzando i brevetti software rende tutto ciò plausibile.

Inoltre, gli standard controllati da aziende senza una implementazione di riferimento libera hanno sempre il problema che l'azienda è diversi passi avanti, mentre i progetti liberi hanno diversi problemi a starvi dietro. La situazione relativa a Java risente proprio di questo effetto.

La risposta è chiara: abbiamo bisogno di standard liberi con una implementazione libera. Questo è ciò che Romance si prefigge di fare.

La prima parte - e l'inizio dello sviluppo - è Rose, il "Romance Object System rosE." Rose fornisce un protocollo, che consente la condivisione degli oggetti tra differenti linguaggi di programmazione.

Il passo successivo dello sviluppo sarà WiSe, il "Romance Widget Server." Sarà disponibile come una libreria GUI/toolkit a tutte le applicazioni Romance attraverso il server Romance. Il paradigma adottato in WiSe è che tutti i widgets restano di proprietà del processo WiSe, non delle diverse applicazioni. Questo dovrebbe consentire a Romance di rendere molto semplice e veloce la condivisione dei widgets.

Poichè Bertrand e Jean-Baptiste sono convinti che il 75% di tutte le applicazioni desktop dovrebbero essere scritte con linguaggi di scripting, si sono concentrati innanzitutto sul supporto per Python, Guile e C. Secondo i loro piani, in futuro Rose supporterà anche Perl, Ruby, Lisp, Scheme ed altri linguaggi dinamici.

Ci sono molti esempi di come potrebbe essere utilizzato Romance.

Per grosse applicazioni è spesso una buona idea definire un linguaggio di espansione. Invece di scegliere un linguaggio, un gruppo di oggetti potrebbero essere resi disponibili attraverso Romance, che consente di scrivere l'applicazione in qualsiasi linguaggio di scripting supportato da Romance.

Le applicazioni di rete spesso richiedono un protocollo di comunicazione, che può essere fornito da Romance. Poichè è più leggero di CORBA, supporta più linguaggi di Java RMI e funziona con oggetti dinamici, Romance offre diversi vantaggi per queste applicazioni.

Romance può anche fungere da "collante" tra diverse componenti di un programma scritte in diversi linguaggi di programmazione, rappresentando una alternativa a SWIG. Essendo dinamico, Romance assicura automaticamente che l'interfaccia sia disponibile in tutti i linguaggi "Romantici".

Attraverso WiSE, Romance fornisce anche i widgets per una interfaccia grafica, che può condividere in modo snello ed efficiente tra processi differenti. Ciò rende superfluo il linking ai toolkit grafici e consente agli utenti di scegliere il look&feel di tutte le applicazioni attraverso Romance.

Nonostante offra tutte queste possibilità, Rose è molto piccolo, ha meno di 500 linee di codice in Python/Scheme.

Sebbene questo progetto, che è stato rilasciato con Licenza Generica Pubblica GNU, sia di maggior interesse per i programmatori, dovrebbe fornire prospettive future interessanti anche ai non sviluppatori.

JavaRisk

Come aggiunta al numero 39, [12] nel quale vennero illustrati alcuni cloni di Risk, vorrei presentarvi JavaRisk [13] di Christian Domsch, Sebastian Kirsch e Andreas Habel.

JavaRisk è una implementazione del rinomato gioco in scatola Risk (simile a RisiKo!, N.d.T.) scritto in Java sotto Licenza Pubblica Generica GNU, con le regole basate interamente sulla versione tedesca del gioco. Nonostante JavaRisk sia un gioco per computer, gli autori non hanno implementato nessun supporto di rete o intelligenza artificiale.

Ha una grafica notevole, comunque, così bella che il gioco J-TEG presentato nel numero 39 la ha implementata come temi.

JavaRisk è un tipico progetto studentesco, che significa che i tre autori non smettevano di giocare nemmeno quando c'era in giro il loro professore.

Quando egli notò il programma, se ne innamorò immediatamente. Suggerì che avrebbero dovuto scrivere una intelligenza artificiale per il loro gioco durante il loro progetto di studio del quinto semestre. Inoltre, poichè è un fan di tutto ciò che è asiatico, chiese loro di implementare un piccolo guerriero Samurai animato da visualizzare ogni qual volta la Cina o il Giappone venissero attaccati.

Attualmente Christian, Sebastian ed Andreas sono impegnati nella scrittura di una nuova versione di JavaRisk, che avrà qualche richiamo in più al gioco di strategia di guerra Empire. Inoltre, JavaRisk versione 2 avrà il supporto per il gioco in rete sin dalla partenza.

EmacsChess

Anche in risposta al numero 39, Mario Lang mi ha scritto chiedendomi di scrivere del progetto Emacs Chess [14] di John Wiegley.

Emacs Chess è composto da tre componenti principali. La prima parte contiene le funzioni di visualizzazione/frontend per visualizzare differenti tipi di scacchiere in Emacs. La seconda parte consente la comunicazione con differenti motori di gioco come GNU Chess e Crafty. La terza parte è una libreria di posizioni e mosse, che include anche un controllo di validità delle mosse ed un gestore del database di gioco.

La cosa più bella tra le bellissime caratteristiche di Emacs Chess è che il client IRC di Emacs (ERC) [15] supporta Emacs Chess, così che è possibile iniziare una partita con qualcuno in IRC, se anche quella persona utilizza Emacs Chess e ERC.

Poichè il protocollo IRC per gli scacchi è basato su CTCP, è possibile anche implementare una funzionalità compatibile in altri client IRC.

Poichè Emacs funziona anche su console, Emacs Chess fornisce anche un bel frontend di scacchi per utenti non vedenti, che possono sentire le mosse annunciate come "cavallo in a4". Naturalmente anche coloro che sono vedenti possono usare questa funzione molto bella.

Le persone che non utilizzano Emacs molto probabilmente non inizieranno ad utilizzarlo per Emacs Chess, ma vale senz'altro la pena di provarlo per tutti gli amici di Emacs.

Emacs Chess è scritto in Emacs-Lisp e pubblicato sotto Licenza Pubblica Generica GNU come software in betatest, aspettatevi allora qualche piccolo problema.

Fine

Per il Brave GNU World di questo mese è abbastanza. Idee, suggerimenti, commenti e segnalazioni di progetti interessanti sono sempre benvenute al solito indirizzo. [1]