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

Welcome to another issue of the Brave GNU World. We may always have suspected it, but this issue presents some proof: Free Software is good for your health!

Debian-Med

Like many areas, the area of medical applications has a large quantity of projects which are sometimes quite advanced, but it is beyond the skills of any "normal" user to assemble them or integrate them into a solution. To solve this, Andreas Tille began the Debian-Med [5] project in early 2002, which aims at customizing the Debian distribution for users in the medical and microbiological fields and seeks to integrate software projects in these areas.

Frequent readers of the Brave GNU World might feel reminded of the Debian-Jr. [7] project introduced in issue #23, [6] and in fact the idea for Debian-Med was inspired by that project.

Especially software which interacts with the private and very intimate spheres of human life - as is the case for doctors - has to fulfil certain criteria which currently only Free Software can fully satisfy.

It must for instance be sure that the confidentiality and security of patient data is upheld. This requires a certain transparency, which is best secured through a Free development process.

Also safety from data-loss can be very important, because some tests are a hazard to health and also cannot be repeated sometimes. If data gets lost, this is clearly reducing the quality of the medical service. At the same time it will normally cause a loss of trust by a patient into the physician.

Therefore this area requires a secure, trustworthy and stable fundament (operating system) with similar applications. Using Free Software is more and more becoming necessary for every conscious physician.

Not surprisingly, privacy, protection of data, trustworthiness and security are on top of the list of Debian-Meds aims.

Other core issues are - as they should - ease of use and easy installation and administration.

Ease of use prevents errors and frustraton, both would work against the patient in these areas. Also easy installation and administration makes sure that conscious physicians have fewer problems moving to Free Software, which will help with practical considerations.

Currently the project, which consists of Andreas and about 70 more interested people, focuses to find a solution for every common problem and make it install-ready.

The mid-term perspective is to present Debian-Med as a real alternative to physicians and create a demonstration live CD.

Areas in most need of help are documentation and translation, but a logo is also still missing. Andreas has been thinking about a combination of Debian logo and snake for this.

The license status of the whole project is determined by the individual software licenses, of course. Free Software under a Debian Free Software Guidelines (DFSG) approved license is preferred.

Unfortunately the project also plans packaging proprietary software that is distributable at no cost, creating a weakness for the mid- and long-term perspectives. But if enough people express their wish to think in the long-term here, I'm sure this isn't carved in stone.

Bringing Free Software into the medical area is something that I always considered to be quite important and if you look for a useful project to engage yourself in, Debian-Med will most likely be a good choice.

Gnumed

Among the programs used within Debian-Med is Gnumed, [8] an official GNU project for paperless medical practice.

The project was born in Australia, where a heated discussion about the dangers of proprietary software in the health sector took place in March 2000. Physicians refused to base their decisions on intransparent algorithms. Within this discussion Hors Herb was accused of unconstructive criticism, which he took as a trigger to start working on Gnumed.

After a first working alpha-release was presented at the MedInfo2001 in London, the international interest in Gnumed made an total redesign of the internal structure necessary. Implementing this new structure is currently the main task for the project coordinations Horst Herb and Karsten Hilbert, who work on this together with about 17 developers and many volunteers.

After completing a minimal version, which they hope to be useful already, it is planned to make Gnumed a complete medical solution including decision support.

The problems that Gnumed faces on the way to this is a lack of free pharmaceutical databases, different health systems with different regulations, lack of data formats, transfer standards and standardised messaging protocols, as well as lack of a system to create a globally unique id for a patient.

Programming languages used in this project are Python and C/C++ on client side, PgSql, C and Python on the server side, with reliablitity and security being the most important paradigms; both of which are not adequately treated in proprietary solutions in the opinion of the Gnumed team.

By the way: The Gnumed team mainly consists of physicians of different fields, who very much know what they want, but often not as well, how to implement it. Therefore more experienced developers would be a very welcome addition to the team.

Gnumed, which seeks to have an easy, ergonomic and highly configurable GUI, support for different languages and health systems, as well as relative platform independence in the end, is published as Free Software under the GNU General Public License.

If you wish to get active in this sector, Gnumed is surely a project to do so.

OIO

The "Open Infrastructure for Outcomes" (OIO) [9] is called the "Search for the holy grail" of data portability by its author, Andrew Ho. Nandalal Gunaratne, Alesander Chelnokov and others accompany him on this quest.

OIO was used for production at the Harbor-UCLA Medical Center in March 200 already before being published as Free Software under the GNU General Public License in August. In September it already managed data of more than 1000 patients amd somce February 2002, it is being used as a hospital-wide information system. So it is safe to say that OIO has proven itself in daily use already.

The major components of OIO are the server, which is accessed via browser through HTML and the OIO library. The server is a flexible, web-based datamanagement-system, which manages users, patients and information about them; although it would of course also be possible to use it for customers, invoices, deliveries or accounts.

The OIO-library is a metadata repository, which allows exchanging metadata like plug-and-play web forms or project descriptions between server and user.

An OIO user can create or modify forms through a web browser, which then are immediately available to be used for data collection over the web.

Later forms can be exported as XML-data to be transferred into a metadata repository like the OIO library or uploaded to another OIO server.

Of course it is also possible to assemble data from different forms into a single dataset that can then be searched/queried over the web with help of logical operations.

Although OIO has already been used for some time, development is not over. Among the planned features for future releases is support for wireless PDAs and plug-and-play protocols will also be supported. Most helpful at the moment would be more users, more feedback and better packaging.

At least with the last point Debian-Med should be able to help.

Res Medicinae

Res Medicinae [10] by Christian Heller is also used by the Debian-Med project. Together with Karsten Hilbert he works on making Res Medicinae the extensive software solution in the medical area.

To achieve maximum portability, Res Medicinae is based on Java (API/Swing, Servlets/JSP, JDBC) with some CORBA/IDL and SOAP/XML. This already shows the largest problem of this Free Software project under GNU General Public License and GNU Free Documentation License, because lacking a full-featured Free Software Java implementation, the freedom of the project is in danger.

But freedom was a major motivational factor for Christian to begin working on Res Medicinae. He seems to overcome the very expensive and proprietary scene of medical information systems and give users in less priviledged countries access to a free, stable, secure, platform independent and extensive system.

The project is still rather young. According to the plans, at the end of 2002, the ResMedLib framework should be consolidated and prototypes for two complete modules should be available. In 2003, the administrative module, printing forms and generating reports should work.

Afterwards, an image processing and a management- as well as a billing and statics module should be added. A training module as well as a decision support module shall then finish the project.

So it should probably not be tried to use the project in daily life, but those who are interested to bring medical competence, translations, Java-programming or webpage-design into the project, will receive a warm welcome in Res Medicinae.

As far as the authors know, Res Medicinae is currently the only Java-based GPL project in the medical area and they plan to work together with OpenEMed, a similar Java project under a BSD license and the already mentioned Gnumed project to achieve interoperability.

That should be enough health for today, if there are other projects in this area, I would like to present them in a later issue. An email [1] would be the appropriate way to get this going.

Romance

Romance [11] is the attempt by Bertrand Lamy and Jean-Baptiste Lamy, to give Free Softare a real, Free alternative to Microsofts .NET.

According to Bertrand, their motivation is that Ximian will probably not be able to deliver a Free implementation of .NET. That Microsoft has already promised to fight all Free alternatives using software patents does indeed make this plausible.

Also standards controlled by companies without a Free reference implementation always have the problem that the company is several steps ahead, while the Free projects have many problems following. The situation around Java suffers from exactly this effect.

The answer is clear: We need a Free standard with a Free implementation. This is what Romance seeks to provide.

The first part - and beginning of development - is Rose, the "Romance Object System rosE." Rose provides a protocol, which allows sharing objects between different programming languages.

The next step of development will be WiSe, the "Romance Widget Server." It will be available as a GUI/toolkit library to all Romance applications through the Romance server. The paradigm employed in WiSE is that all widgets remain property of the WiSe process, not of the different applications. That should allow Romance to make sharing of widgets very fast and simple.

Since Bertrand and Jean-Baptiste believe that 75% of all desktop applications should be written in skript languages, they have concentrated on supporting Python, Guile and C first. According to their plans, Rose will also support Perl, Ruby, Lisp, Scheme and other dynamical languages in the future, though.

There are many examples how Romance can be used.

For large applications, it is often a good idea to define an expansion language. Instead of chosing one language, a group of objects could be made available through Romance, which allows skripting the application in any language supported by Romance.

Networked applications often require a communication protocol, which can be supplied by Romance. Since it is lighter than CORBA, supports more languages than Java RMI and works with dynamic, non-static objects, Romance offers several advantages in this regard.

Romance can also act as "glue" between different parts of a program written in different programming languages, providing an alternative to SWIG. Being dynamic, Romance automatically makes sure that the interface is available in all "Romantic" languages.

Through WiSE, Romance also provides widgets for a graphical user interface, which can shared in a lean and efficient manner between different processes. This makes linking against graphical toolkits unneccessary and allows the user to choose the look&feel of all applications through Romance.

While offering all these possibilities, Rose is very small, it has less than 500 lines of code in Python/Scheme.

Although this project, which is released under the GNU General Public License, most relevant to developers, it should also give non-developers some interesting perspectives for the future.

JavaRisk

As an add-on to issue #39, [12] in which some Risk-Clones were presented, I'd like to introduce JavaRisk [13] by Christian Domsch, Sebastian Kirsch and Andreas Habel.

JavaRisk is an implementation of the well-known board game Risk in Java under the GNU General Public with the rules based entirely on the German version of the game. Despite JavaRisk being a computer game, the authors did not implement any network support or artificial intelligence.

It has outstanding graphics, though, which are so good that the game J-TEG introduced in issue #39 implemented them as a theme.

JavaRisk is a typical student project, which means that the three authors also didn't stop playing while their professor was around.

When he noticed the game, he immediately loved it. He suggested that they should write an artificial intelligence for their game in their 5th semester student project. Also, since he is a fan of everything asian, he asked them to implement small animated Samurai-fighter to be displayed whenever China or Japan is being attacked.

Currently Christian, Sebastian and Andreas are busy working on a new version of JavaRisk, which will have more resemblance with a stategic war game like Empire. Also JavaRisk v2 will support networked play right from the start.

EmacsChess

Also in reaction to issue #39, Mario Lang wrote me and recommended writing about the Emacs Chess [14] project by John Wiegley.

Emacs Chess consists of three major parts. The first part contains the display/frontend capabilties in order to display different types of boards in Emacs. The second part allows communication with different chess engines like GNU Chess and Crafty. And the third part is a library for positions and games including a validity checker for moves and game-database management.

Among the very neat features of Emacs Chess is that the Emacs IRC Client (ERC) [15] supports Emacs Chess, so it is possible to start a game with somebody in IRC if that person also uses Emacs Chess and ERC.

Since the IRC chess protocol is based on CTCP, it is also possible to implement a compatible functionality in other clients.

Since Emacs also runs on console, Emacs Chess also provides a nice Chess front end for vision-impaired users, who can have moved announced in a "knight takes a4" form. But of course non-vision-impaired people may also use this very neat feature.

People not using the Emacs will probably not start doing so because of Emacs Chess, but it should truly be a worth a try for all Emacs-friends.

Emacs Chess is written in Emacs-Lisp and published under the GNU General Public License as betatest software, so you have to expect some minor difficulties.

End

Enough Brave GNU World for this month. Ideas, suggestions, comments and notificatios for interesting projects are as always welcome to the usual address. [1]