Diese Kolumne berichtet über aktuelle Entwicklungen innerhalb des GNU-Projekts und versucht, Einblicke in die zugrunde liegende Philosophie zu vermitteln. In dieser Ausgabe: Debian-Med, Gnumed, OIO, Res Medicinae, Romance, Java Risk, Emacs Chess.
Willkommen zu einer weiteren Ausgabe der Brave GNU World. Wir haben es schon immer geahnt, aber diese Ausgabe beweist es: Freie Software ist gut für die Gesundheit!
Debian-Med
Auch im Bereich medizinischer Anwendungen sind viele Projekte schon recht weit fortgeschritten. Da ein normaler Anwender meist überfordert ist, wenn es gilt, solche Lösungen zusammenzufassen, startete Andreas Tille Anfang 2002 das Debian-Med-Projekt[5].
Das Vorhaben will eine Debian-Distribution auf die Bedürfnisse von Anwendern aus dem medizinischen und mikrobiologischen Bereich zurechtschneiden und Softwareprojekte auf diesen Gebieten integrieren. Das Debian-Jr.-Projekt[6] – den Brave-GNU-World-Lesern aus dem Linux-Magazin 2/01[7] bekannt – hatte Andreas zu Debian-Med inspiriert. Die etwa 70 Beteiligten schaffen für die betroffenen Gebiete freie Softwarelösungen.
Sicherheit und Schutz der Daten gefordert
Privatsphäre, Schutz der Daten, Vertraulichkeit und Sicherheit sind die obersten Ziele. Gerade im ärztlichen Bereich, wo Software unmittelbar mit der Privat- und Intimsphäre von Menschen interagiert, muss sie hohen Anforderungen entsprechen, die ausschließlich Open-Source-Software erfüllt.
So gewährleistet nur die völlige Transparenz, dass Patientendaten vertraulich und vor fremdem Zugriff geschützt bleiben. Auch die Verlustsicherheit von Daten ist wichtig. Untersuchungen sind manchmal belastend, manchmal können sie gar nicht wiederholt werden. Gehen Daten verloren, beeinträchtigt das die ärztliche Leistung, es kann sogar das Vertrauen des Patienten in den behandelnden Arzt stören. Sichere, vertrauenswürdige und stabile Programme einsetzen – also freie Software – ist damit ein Muss für jeden verantwortungsvollen Mediziner.
Daneben besteht das Bedürfnis nach einfacher Bedienbarkeit, einfacher Installation und einfacher Administration. Sie verhindern Fehler und Frustration, die sich in diesem Bereich immer zu Lasten der Patienten auswirken, und erleichtern zudem den Umstieg von anderen Programmen.
Eine Live-CD für Vorführungen ist geplant. Das Projekt braucht Hilfe bei Dokumentation und Übersetzung. Auch ein Logo ist bisher noch nicht gefunden (Andreas schwebt aber bereits eine Kombination aus Debian-Logo und Schlange vor).
Die Lizenz muss sich bei einem derartigen Metaprojekt natürlich nach den Lizenzen der Einzelpakete richten, freie Software nach den Debian Free Software Guidelines (DFSG) ist aber bevorzugt. Bislang sieht sich das Projekt leider gezwungen, auch kostenlose proprietäre Software einzubinden. Die Entscheidung für eine solche Schwachstelle ist aber noch nicht endgültig und sollte, wenn sich genügend Gegenstimmen finden, abzuwehren sein.
Freie Software in den medizinischen Bereich einzubringen schien mir immer schon sehr wichtig. Wer in einem wirklich sinnvollen Projekt mitarbeiten möchte, ist bei Debian-Med am richtigen Platz, schließlich soll Debian-Med eine echte Alternative für Ärzte werden.
Gnumed
Zu den Programmen, die innerhalb von Debian-Med verwendet werden, gehört auch Gnumed[8], ein offizielles GNU-Projekt für die papierlose medizinische Praxis. Es nahm seinen Anfang in Australien, wo im März 2000 eine hitzige Diskussion über die Gefahren proprietärer Software im Gesundheitswesen stattfand. Die Ärzte wehrten sich dagegen, ihre Entscheidungen undurchsichtigen Algorithmen anzuvertrauen.
Bei dieser Diskussion sah sich Horst Herb dem Vorwurf ausgesetzt, unkonstruktive Kritik zu üben. Er nahm dies zum Anlass, sogleich mit der Arbeit an Gnumed zu beginnen. Die erste funktionierende Alphaversion wurde auf der Med Info 2001 in London vorgestellt. Wegen des internationalen Interesses muss die interne Struktur neu geordnet werden. Das ist die aktuelle Hauptaufgabe der Projektkoordinatoren Horst Herb und Karsten Hilbert, die gemeinsam mit 17 Entwicklern und vielen Freiwilligen an Gnumed arbeiten.
Sobald eine geplante Minimalversion für den täglichen Einsatz fertig ist, soll Gnumed zur vollständigen medizinischen Softwarelösung inklusive einer Entscheidungsbegleitung ausgebaut werden. Eine ergonomische, konfigurierbare Oberfläche, Unterstützung für verschiedene Sprachen, Gesundheitssysteme und Plattformen sind Ziele des unter der GPL stehenden Softwareprojekts.
Probleme, denen sich Gnumed auf dem Weg dorthin stellen muss, sind fehlende freie pharmazeutische Datenbanken, das Nebeneinander verschiedener Gesundheitssyteme mit ihren unterschiedlichen Regelungen, fehlende Standards bei Daten- und Protokollformaten und bei der Identifizierung einer Person.
Als Programmiersprachen nutzt Gnumed Python und C/C++ auf Seite des Clients sowie PgSQL, C und Python auf Server-Seite. Der Schwerpunkt liegt auch hier auf Stabilität und Sicherheit. Das Gnumed-Team besteht hauptsächlich aus Ärzten verschiedener Fachrichtungen, die zwar genau wissen, was sie wollen, aber manchmal nicht, wie es am besten umzusetzen ist. Ihnen wären deshalb erfahrene Entwickler als Verstärkung willkommen.
OIO

Abbildung 1: Mit OIO lassen sich verschiedene Formulare leicht verwalten, etwa zur Exploration von Patienten.
Open Infrastructure for Outcomes (OIO)[9] wird von Andrew Ho, ihrem Autor, als die “Suche nach dem heiligen Gral” der Datenportierbarkeit bezeichnet. Begleitet wird er auf dieser Suche unter anderen von Nandalal Gunaratne und Alexander Chelnokov.
OIO wurde bereits im März 2000 am Harbor-UCLA Medical Center als Produktionssystem eingesetzt, bevor es im August als freie Software unter der GNU General Public License herausgegeben wurde. Im September verwaltete es bereits die Daten von über 1000 Patienten und wird seit Februar 2002 als Krankenhaus-Informationssystem eingesetzt. OIO hat sich damit bereits im täglichen Einsatz behauptet.
Die beiden wesentlichen Komponenten des OIO-Systems sind der Server, auf den per Browser über HTML zugegriffen wird, sowie die OIO-Bibliothek. Der Server ist ein sehr flexibles Web-basiertes Datenmanagementsystem, mit dem Benutzer, Patienten und Informationen über Patienten verwaltet werden können. Es wäre natürlich ebenfalls möglich, Informationen über Kunden, Rechnungen, Lieferungen oder Konten mit OIO zu führen.
Die OIO-Bibliothek ist ein Metadaten-Repository, mit dem Metadaten etwa für Plug&Play-Webformulare oder Projektbeschreibungen zwischen Server und Benutzer ausgetauscht werden können. Ein OIO-Benutzer kann per Web-Browser Formulare erzeugen oder verändern, die unmittelbar als Eingabemasken zur Verfügung stehen. Sobald ein Formular definiert ist, ist es für die Datensammlung bereit (Abbildung 1).
Die Formulare können später als XML-Daten exportiert werden, um zum Beispiel in ein Metadaten-Repository wie die OIO-Bibliothek oder einen anderen OIO-Server übertragen zu werden. Natürlich besteht außerdem die Möglichkeit, aufgrund der Daten aus verschiedenen Formulare bestimmte Datensätze zu definieren, um diese anschließend logisch verknüpft zu selektieren.
Auch wenn OIO sich bereits längere Zeit im praktischen Einsatz befindet, steht die Entwicklung nicht still. Künftig sollen PDAs drahtlos unterstützt und Plug&Play-Fähigkeit eingebaut werden. Hilfreich wären dabei vor allem mehr Nutzer, mehr Feedback und bessere Pakete für einfachere Installation.
Res Medicinae

Abbildung 2: Statt der Krankengeschichte auf Karteikarte bietet Res Medicinae übersichtliche Krankenblätter.
Auch Res Medicinae[10] von Christian Heller ist im Debian-Med-Projekt vertreten. Gemeinsam mit Karsten Hilbert arbeitet er daran, Res Medicinae zur umfassenden Softwarelösung im medizinischen Bereich zu machen (siehe Abbildung 2). Um maximale Plattformunabhängigkeit zu erreichen, basiert Res Medicinae auf Java (API/Swing, Servlets/ JSP, JDBC) mit etwas CORBA/IDL und SOAP/XML. Das ist auch das größte Problem des unter GNU General Public License und GNU Free Documentation License stehenden Projekts: Dass es immer noch keine vollständige, freie Java-Implementation gibt, gefährdet die Freiheit des Projekts.
Diese Freiheit hatte Christian mit der Arbeit an Res Medicinae beginnen lassen, will er doch gerade den Benutzern in weniger privilegierten Ländern die teuren proprietären medizinischen Informationssysteme ersparen und ein freies, stabiles, sicheres und plattformunabhängiges System anbieten.
Das Projekt ist noch recht jung. Die Pläne sehen vor, bis Ende 2002 das ResMed-Lib-Framework zu konsolidieren und Prototypen für zwei Module fertig zu stellen. Im Jahr 2003 sollen das administrative Modul und der Formulardruck oder das Erstellen von Berichten funktionieren, später auch Bildverarbeitung, ein Management- sowie Abrechnungs- und Statistik-Module. Ein Trainingsmodul und möglicherweise eins zur Entscheidungsunterstützung sollen das Ganze abrunden. Der Praxiseinsatz ist noch nicht möglich.
Wer Lust hat, sich mit Fachkompetenz, Übersetzungen, Java-Programmierung oder als Webseiten-Designer einzubringen, der findet bei Res Medicinae sicherlich herzliche Aufnahme. Res Medicinae dürfte das einzige Java-basierte GPL-Programm im medizinischen Bereich sein. Die Entwickler wollen mit OpenEMed, einem ähnlichen Java-Projekt unter BSD-Lizenz, sowie dem erwähnten Gnumed-Projekt kooperieren.
Vom Arzt zur Romance
Damit genug Gesundheit für heute, sollte jemand noch weitere Projekte aus dem medizinischen Bereich kennen, stellen wir sie gerne in einer späteren Ausgabe vor. Eine E-Mail[1] ist zu diesem Zweck das geeignete Mittel.
Mit Romance[11] arbeiten Bertrand Lamy und Jean-Baptiste Lamy an einer freien Alternative zu Microsofts .NET. Bertrand vermutet, dass Ximian keine freie Implementation von .NET schreiben kann. Microsoft hatte bereits öffentlich angekündigt, derartige Entwicklungen unter Einsatz ihrer Softwarepatente zu bekämpfen.
Von Unternehmen kontrollierte Standards ohne freie Referenzimplementation bewirken immer wieder, dass die Unternehmen ein paar Schritte voraus sind, während freie Projekte nicht mitziehen können. Die Situation um Java krankt genau an diesem Effekt. Die Antwort ist klar: Wir brauchen einen freien Standard mit einer freien Implementation. Das soll Romance bieten.
Der erste Teil – und Anfang der Entwicklung – ist Rose, das Romance Object System. Rose stellt ein Protokoll zur Verfügung, mit dem von verschiedenen Programmiersprachen aus auf Objekte zugegriffen werden kann. Der nächste Schritt der Entwicklung wird Wise sein, der Romance Widget Server. Er wird als GUI-Toolkit-Bibliothek allen Romance-Applikationen über den Romance-Server zur Verfügung stehen.
Das Paradigma für Wise ist, dass alle Widgets aller Romance-Applikationen dem Wise-Prozess zugeordnet bleiben, nicht den verschiedenen Applikationen. So soll Romance Widgets sehr schnell und einfach verteilen können. Bertrand und Jean-Baptiste glauben, dass drei Viertel aller Desktop-Applikationen in Skriptsprachen geschrieben sein sollten. Rose konzentriert sich daher auf Python, Guile sowie C und soll künftig für Perl, Ruby, Lisp, Scheme und andere dynamische Sprachen erweitert werden.
Die Einsatzmöglichkeiten für Romance sind vielfältig: Für große Applikationen wird oft eine Erweiterungssprache definiert. Statt eine bestimmte Sprache zu wählen, können Objekte über Romance zur Verfügung gestellt werden, um dann die Applikation in jeder unterstützten Sprache zu skripten.
Vernetzte Applikationen brauchen ein gemeinsames Kommunikationsprotokoll. Weniger aufwändig als CORBA, mit mehr Sprachen als Java RMI und mit dynamischen Objekten bietet Romance hier einige Vorteile. Auch der Einsatz als Kitt zwischen den Komponenten eines Programms, die in verschiedenen Programmiersprachen verfasst wurden, ist denkbar. Damit wäre Romance eine Alternative zu SWIG.
Über Wise stellt Romance auch entsprechende Widgets für grafische Benutzeroberflächen bereit, die schnell und einfach von verschiedenen Prozessen benutzbar sind. Das erspart selbst das dynamische Linken eines Programms gegen ein grafisches Toolkit, der Nutzer kann ein einheitliches Look&Feel aller Applikationen wählen.
Bei diesen vielfältigen Möglichkeiten kommt Rose mit weniger als 500 Zeilen Programmcode in Python/Scheme aus. Das Projekt, das vollständig der GNU General Public License unterliegt, scheint zunächst eher für Programmierer interessant, deutet aber auch ganz allgemein künftige Entwicklungen an.
Emacs Chess

Abbildung 3: Eine Schachpartie für Emacs-Freunde: Das Spielbrett von Emacs Chess mit seiner X-Board- Grafik ist im Vordergrund zu sehen, der Hintergrund zeigt die laufende IRC-Sitzung. Über das IRC-Protokoll CTCP können die Spielzüge des Gegners übertragen werden.
In Reaktion auf die Brave GNU World in Heft 6/02 hat sich Mario Lang gemeldet, um mir das Emacs-Chess-Projekt[14] von John Wiegley zu empfehlen. Das GPL-Programm, offizieller Status: Beta, besteht im Wesentlichen aus drei Teilen. Der erste widmet sich der Anzeige verschiedener Typen von Schachbrettern im Emacs. Der zweite erlaubt die Kommunikation mit verschiedenen Schach-Engines wie GNU Chess und Crafty. Dritter Teil ist eine Bibliothek für Positionen und Spiele samt Validitätscheck für Züge und Spieldatenbank-Verwaltung.
Das herausragende Feature von Emacs Chess ist, dass es vom Emacs-IRC-Client (ERC)[15] unterstützt wird. Zwei Spieler, die beide Emacs Chess und ERC benutzen, können in der IRC-Sitzung miteinander spielen (Abbildung 3). Das IRC-Schach-Protokoll basiert auf CTCP – so können auch andere Clients damit ausgerüstet werden.
Man kann Emacs auch nur auf der Konsole benutzen, so ist die Steuerung über die Braille-Zeile oder die Sprachausgabe möglich. Wer sich dem Emacs bisher verweigern konnte, den wird vielleicht auch Emacs Chess nicht dazu bringen. Für Emacs-Freunde ist das Programm aber sehr interessant.
Java Risk
Ebenfalls als Nachtrag zur Brave GNU World in Heft 6/02[12], in der einige Risiko-Klone vorgestellt wurden, sei noch Java Risk[13] von Christian Domsch, Sebastian Kirsch und Andreas Habel erwähnt. Java Risk ist eine Implementation des bekannten Brettspiels “Risiko”. Das Spiel ist in Java programmiert und steht unter der GNU General Public License. Die Regeln basieren komplett auf der deutschen Version des Spiels. Eher unüblich für ein aktuelles Computerspiel ist, dass die Autoren auf Netzwerkunterstützung und künstliche Intelligenz verzichten. Die Grafik von Java Risk ist allerdings so gut gelungen, dass die Entwickler von J-TEG (ebenfalls in Heft 06/02 vorgestellt) sie als Theme implementiert haben.
Java Risk ist ein typisches Studentenprojekt: Die drei Autoren ließen selbst in Gegenwart ihres Professors nicht von der Arbeit ab. Der zeigte sich aber auf Anhieb begeistert und schlug vor, im fünften Semester als Studienprojekt eine künstliche Intelligenz für das Spiel schreiben zu lassen. Da er außerdem Asien-Fan ist, bat sie der Professor um kleine animierte Samurai-Kämpfer für den Fall, dass China oder Japan angegriffen werden.
Derzeit arbeiten Christian, Sebastian und Andreas an einer neuen Version von Java Risk, die mehr Ähnlichkeit mit einem strategischen Kriegsspiel wie “Empire” haben wird. Außerdem soll die Java-Risk-Version 2 von Anfang an Netzwerkunterstützung bieten.
Schluss
Damit wieder einmal genug Nachrichten aus der Brave GNU World, jedenfalls für diesen Monat. Ich hoffe, dass wieder für alle Freunde freier Software etwas Neues dabei war. Ideen, Anregungen, Kommentare und Meldungen über interessante neue Projekte und Fortschritte bei bereits bekannten sind wie immer per E-Mail an die übliche Adresse[1] sehr willkommen. (fan)
Der Autor |
|
Dipl.-Phys. Georg C. F. Greve beschäftigt sich seit etlichen Jahren mit freier Software und kam früh zu GNU/Linux. Nach Mitarbeit im GNU-Projekt und seiner Aktivität als dessen europäischer Sprecher hat er die Free Software Foundation Europe initiiert, deren Präsident er ist. Mehr Informationen finden sich unter [http://www.gnuhh.org]. |






