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

Willkommen zu einer weiteren Ausgabe der Brave GNU World. Auch wenn wir es schon immer geahnt haben, will diese Ausgabe einige Beweise liefern: Freie Software ist gut für die Gesundheit!

Debian-Med

Wie in vielen Gebieten existiert auch bei medizinischen Anwendungen mittlerweile eine Vielzahl von Projekten, die zum Teil schon recht weit fortgeschritten sind, jedoch übersteigt es häufig die Möglichkeiten eines "normalen" Anwenders, diese zusammenzustellen und in eine Lösung zu integrieren. Daher startete Andreas Tille Anfang 2002 das Debian-Med [5] Projekt, das anstrebt, die Debian Distribution auf die Bedürftnisse von Anwendern aus dem medizinischen und mikrobilogischen Bereich zurechtzuschneiden und Softwareprojekte auf diesen Gebieten zu integrieren.

Regelmäßigen Leserinnen der Brave GNU World könnte dies an das in Ausgabe 23 [6] vorgestellte Debian-Jr. [7] Projekt erinnern und in der Tat wurde die Idee für Debian-Med von diesem inspiriert.

Gerade Software, die in so hohem Maße mit der Privat- und Intimsphäre von Menschen interagiert, wie dies bei Ärzten der Fall ist, muß gewissen Kriterien genügen, die momentan nur Freie Software vollständig erfüllen kann.

Es muß beispielsweise sichergestellt sein, daß die Vertraulichkeit und Sicherheit der Patientendaten gewährleistet ist. Dies macht jedoch eine entsprechende Transparenz erforderlich, die dauerhaft am besten durch einen Freien Entwicklungsprozeß gesichert werden kann.

Auch die Verlustsicherheit von Daten kann wichtig sein, denn manche Untersuchungen stellen eine Belastung der Gesundheit dar oder können nicht wiederholt werden. Gehen Daten verloren, stellt dies eindeutig eine Beeinträchtigung der ärztlichen Leistung dar. Von dem Verlust an Vertrauen des Patienten in seinen behandelnden Arzt ganz zu schweigen.

Daher wird in diesem Bereich ein sicheres, vertrauenswürdiges und stabiles Fundament (Betriebssystem) mit ebensolchen Applikationen benötigt. Der Einsatz Freier Software wird in zunehmendem Maße zum notwendigen Schritt für jeden verantwortungsvollen Mediziner.

Nicht überraschend stehen daher Privatsphäre, Schutz der Daten, Vertraulichkeit und Sicherheit ganz oben auf der Liste der durch Debian-Med angestrebten Ziele.

Doch auch einfache Bedienbarkeit sowie einfache Installation und Administration sind Kernpunkte und sollten dies auch sein.

Eine einfache Bedienbarkeit verhindert Fehler und Frustration, die sich in diesem Bereich immer zu Lasten der Patienten auswirken. Zudem sorgt eine einfache Installation und Administration dafür, daß verantwortungsbewußten Ärzten der Umstieg erleichtert wird, was praktisch große Bedeutung hat.

Im Augenblick konzentriert sich das Projekt, dem neben Andreas noch etwa 70 Interessierte angehören, noch darauf, für alle Gebiete eine entsprechende Freie Software Lösung zu finden und installationsfertig zu machen.

Mittelfristig soll dann den Ärzten Debian-Med als echte Alternative präsentiert und eine Live CD für Demonstrationen erstellt werden.

Benötigt wird vor allem Hilfe bei Dokumentation und Übersetzung, doch auch ein Logo ist bisher nicht gefunden, selbst wenn Andreas bereits die Idee von einer Kombination aus Debian-Logo und Schlange vorschwebt.

Der Lizenzstatus richtet sich bei einem derartigen Metaprojekt natürlich hauptsächlich nach den Lizenzen der Einzelpakete, wobei Freie Software nach den Debian Free Software Guidelines (DFSG) bevorzugt wird.

Leider plant das Projekt auch, kostenlose proprietäre Software einzubinden, was eine Schwachstelle für die mittel- bis langfristige Perspektive darstellt, aber wenn genügend Leute ihren Wunsch zum Ausdruck bringen, hier bevorzugt langfristig zu denken, dann ist dies wohl nicht unabänderlich.

Freie Software in den medizinischen Bereich zu bringen, ist etwas, was mir schon immer sehr wichtig erschien und wer nach einem wirklich sinnvollen Projekt zur Mitarbeit sucht, ist bei Debian-Med sicherlich nicht verkehrt.

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.

Das Projekt nahm seinen Anfang in Australien, wo im März 2000 eine hitzige Diskussion über die Gefahren proprietärer Software im Gesundheitswesen stattfand, denn die Ärzte wehrten sich dagegen, ihre Entscheidungen undurchsichtigen Algorithmen anzuvertrauen. Innerhalb dieser Diskussion wurde Horst Herb vorgeworfen, unkonstruktive Kritik zu üben, was dieser zum Anlaß nahm, mit der Arbeit an Gnumed zu beginnen.

Nachdem eine erste funktionierende Alpha-Version auf der MedInfo 2001 in London vorgestellt wurde, machte das internationale Interesse eine völlige Neuordnung der internen Struktur notwendig. Diese neue Struktur zu implementieren ist momentan die Hauptaufgabe für die Projektkoordinatoren Horst Herb und Karsten Hilbert, die gemeinsam mit 17 Entwicklern und vielen Freiwilligen an Gnumed arbeiten.

Nach der Fertigstellung einer minimalen Version, die jedoch bereits im täglichen Einsatz hilfreich sein soll, ist geplant, Gnumed zur vollständigen medizinischen Softwarelösung inklusive Entscheidungsbegleitung zu machen.

Die Probleme, denen sich Gnumed auf dem Weg dorthin stellen muß, sind der Mangel an Freien pharmazeutischen Datenbanken, die verschiedenen Gesundheitssyteme mit ihren unterschiedlichen Regelungen, der Mangel an Datenformaten, Transferstandards und standardisierten Messaging Protokollen, sowie das Fehlen eines global einheitlichen Systems zur Identifikation einer Person.

Als Programmiersprachen kommen für Gnumed Python und C/C++ auf Seite des Klienten, sowie PgSql, C und Python auf Serverseite zum Einsatz, wobei die Entwicklungsschwerpunkte immer auf Verläßlichkeit und Sicherheit liegen, zwei Punkte, die nach Meinung des Gnumed-Teams in proprietären Anwendungen zu kurz kommen.

Übrigens besteht das Gnumed-Team hauptsächlich aus Ärzten verschiedener Fachrichtungen, die sehr genau wissen, was sie wollen, aber teilweise nicht so genau, wie es implementiert werden sollte. Daher wären dem Projekt einige erfahrene Entwickler sehr willkommen.

Gnumed, das im Endresultat eine einfache, ergonomische und möglichst konfigurierbare Oberfläche, Unterstützung für verschiedene Sprachen und Gesundheitssysteme, sowie relative Plattformunabhängigkeit anstrebt, wird übrigens als Freie Software unter der GNU General Public License herausgegeben.

Wer sich in diesem Gebiet engagieren möchte, für den ist Gnumed sicherlich eine sehr geeignete Wahl.

OIO

Die "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 von Nandalal Gunaratne, Alexander Chelnokov und anderen.

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. Es darf also mit einigem Recht behauptet werden, daß sich OIO bereits im täglichen Einsatz behauptet hat.

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 Datenmanagement-System, mit dem Benutzer, Patienten und Informationen über Patienten verwaltet werden können; obwohl es natürlich gleichermaßen möglich wäre, Informationen über Kunden, Rechnungen, Lieferungen oder Konten mittels OIO zu führen.

Die OIO-Bibliothek ist ein Metadaten-Repository, mittels dessen Metadaten z.B. für Plug-and-Play Webformulare oder Projektbeschreibungen zwischen Server und Benutzer ausgetauscht werden können.

Ein Benutzer von OIO kann per Webbrowser Formulare erzeugen oder verändern, die unmittelbar zur Eingabe per Browser zur Verügung stehen. Sobald ein Formular definiert ist, steht es zur Datensammlung bereit.

Später können Formulare als XML-Daten exportiert werden, um z.B. in ein Metadaten-Repository wie die OIO Bibliothek oder einen anderen OIO Server übertragen zu werden.

Natürlich gibt es auch die Möglichkeit, aufgrund der Daten verschiedener Formulare bestimmte Datensätze zu definieren, die dann per Web über logische Operationen durchsucht/befragt werden können.

Auch wenn OIO sich bereits längere Zeit im praktischen Einsatz befindet, steht die Entwicklung nicht still. So ist beispielsweise die Unterstützung von drahtlosen PDAs geplant und es sollen plug-and-play Protokolle unterstützt werden. Hilfreich wären dabei vor allem mehr Nutzer, mehr Feedback und bessere Pakete für die einfachere Installation.

Zumindest beim letzten Punkt sollte Debian-Med in der Lage sein, dem Projekt weiter zu helfen.

Res Medicinae

Auch Res Medicinae [10] von Christian Heller ist im Debian-Med Projekt vertreten. Gemeinsam mit Karsten Hilbert arbeitet er daran, Res Medicinae zur umfassenden Software-Lösung im medizinischen Bereich zu machen.

Um die größtmögliche Plattformunabhängigkeit zu erreichen, basiert Res Medicinae auf Java (API/Swing, Servlets/JSP, JDBC) mit etwas CORBA/IDL und SOAP/XML. Damit ist auch gleich das größte Problem dieses unter GNU General Public License und GNU Free Documentation License stehenden Projekts erwähnt, denn mangels einer vollständigen, Freien Java-Implementation ist das Projekt in seiner Freiheit gefährdet.

Dabei ist gerade die Freiheit eine wesentliche Argumentation aus der heraus Christian mit der Arbeit an Res Medicinae begonnen hat. Seine Motivation ist es, die sehr teure und proprietäre Szene der medizinischen Informationssysteme zu überwinden und auch gerade den Benutzern in weniger privilegierten Ländern ein Freies, stabiles, sicheres, plattformunabhängiges und breit angelegtes System zur Verfügung zu stellen.

Das Projekt ist noch recht jung. Die Pläne sehen vor, bis Ende 2002 das ResMedLib Framework zu konsolidieren und Prototypen für zwei vollständige Module fertigzustellen. Im Jahr 2003 soll das administrative Modul sowie der Ausdruck von Formularen, bzw. die Erstellung von Berichten funktionieren.

In weiterer Zukunft soll dann auch die Bildverarbeitung und das Management-Modul sowie ein Abrechnungs- und ein Statistik-Modul hinzugefügt werden. Ein Trainings-Modul und möglicherweise ein entscheidungsunterützendes Modul sollen das Projekt abrunden.

Von der täglichen Anwendung muß im Moment wohl noch abgeraten werden, wer allerdings Lust hat, sich mit Fachkompetenz, Übersetzungen, Java-Programmierung oder als Webseiten-Designer einzubringen, der findet bei Res Medicinae sicherlich herzliche Aufnahme.

Nach Wissen der Autoren ist Res Medicinae übrigens die einzige javabasierte GPL-Software im medizinischen Bereich und sie planen, mit OpenEMed, einem ähnlichen Java-Projekt unter BSD-Lizenz, sowie dem bereits erwähnten Gnumed-Projekt zu kooperieren, um interoperabel zu sein.

Doch damit genug Gesundheit für heute, falls jedoch noch weitere Projekte aus diesem Bereich kennt, so sollen diese gerne in einer späteren Ausgabe vorgestellt werden. Eine Email [1] ist zu diesem Zweck das geeignete Mittel.

Romance

Mit Romance [11] arbeiten Bertrand Lamy und Jean-Baptiste Lamy daran, der Freien Software eine echte, Freie Alternative zu Microsofts .NET zu verschaffen.

Ihre Motivation hierzu ziehen sie laut Bertrand daraus, daß es Ximian vermutlich nicht möglich sein wird, eine Freie Implementation von .NET zu schreiben. Die Tatsache, daß Microsoft bereits öffentlich angekündigt hat, Freie Alternativen unter Einsatz ihrer Softwarepatente zu bekämpfen, spricht dafür, daß er Recht hat.

Außerdem haben unternehmenskontrollierte Standards ohne Freie Referenzimplementation in ihren Augen immer das Problem, daß das Unternehmen ein paar Schritte voraus ist, während Freie Projekte große Probleme haben, mitzuziehen. Die Situation um Java krankt genau an diesem Effekt.

Die Antwort ist klar: Wir brauchen einen Freien Standard mit einer Freien Implementation. Dies soll Romance bieten.

Der erste Teil - und Anfang der Entwicklung - ist Rose, das "Romance Object System rosE". Rose stellt ein Protokoll zur Verfügung, mit dessen Hilfe Objekte von verschiedenen Programmiersprachen benutzt werden können.

Der nächste Schritt der Entwicklung wird WiSe, der "Romance Widget Server" sein. Dieser wird als GUI/Toolkit Bibliothek allen Romance-Applikationen über den Romance-Server zur Verfügung stehen. Das Paradigma für WiSE ist, daß alle Widgets aller Romance-Applikationen dem WiSE-Prozess zugeordnet bleiben, nicht den verschiedenen Applikationen. Dies sollte es Romance erlauben, das Teilen von Widgets sehr schnell und einfach zu machen.

Da Bertrand und Jean-Baptiste glauben, daß 75% aller Desktop-Applikationen in Skriptsprachen geschrieben werden sollten, haben sie sich bei der Unterstützung der Programmiersprachen zunächst auf Python, Guile und C konzentriert. Rose wird jedoch nach ihren Plänen in Zukunft auch Perl, Ruby, Lisp, Scheme und andere dynamische Sprachen unterstützen.

Die Einsatzmöglichkeiten für Romance sind vielfältig.

Für große Applikationen bietet es sich oft an, eine Erweiterungssprache zu definieren. Anstatt eine bestimmte Sprache zu wählen, kann alternativ eine Gruppe von Objekten über Romance zur Verfügung gestellt werden, die es dann erlaubt, die Applikation in jeder von Romance unterstützten Sprache zu skripten.

Vernetzte Applikationen benötigen in vielen Fällen ein Kommunikationsprotokoll, welches durch Romance zur Verfügung gestellt werden kann. Da es weniger aufwändig als CORBA ist, mehr Sprachen als Java RMI unterstützt und mit dynamischen, nicht statischen Objekten arbeitet, bietet Romance hier einige Vorteile.

Auch als "Kleber" zwischen Komponenten eines Programms, die in verschiedenen Programmiersprachen verfasst wurden, ist der Einsatz von Romance als Alternative zu SWIG denkbar. Durch die Dynamizität von Romance ist sichergestellt, daß die Anbindung automatisch in allen durch Romance unterstützten Sprachen zur Verfügung steht.

Über WiSe stellt Romance auch entsprechende Widgets für eine grafische Benutzeroberfläche zur Verfügung, die alle schnell und einfach vonverschiedenen Prozessen benutzt werden können. Dies macht sogar das dynamische Linken eines Programms gegen ein grafisches Toolkit unnötig und es wäre denkbar, daß das entsprechende Look & Feel der Applikationen einheitlich über Romance durch den Nutzer gewählt wird.

Bei diesen vielfältigen Möglichkeiten kommt Rose mit weniger als 500 Zeilen Programmcode in Python/Scheme aus, es ist also sehr klein.

Auch wenn dieses Projekt, das übrigens komplett der GNU General Public License untersteht, eher für Entwickler relevant ist, so dürfte es doch auch Nicht-Entwicklern einige interessante Optionen für die Zukunft zeigen.

JavaRisk

Als Nachtrag zu Ausgabe 39, [12] in der einige Risiko-Klone vorgestellt wurden, soll hier auch JavaRisk [13] von Christian Domsch, Sebastian Kirsch und Andreas Habel Erwähnung finden.

JavaRisk ist eine Implementation des bekannten Brettspiels Risiko in Java unter der GNU General Public License, wobei die Regeln komplett auf der deutschen Version des Spiels basieren. Trotz der Tatsache, daß es sich hierbei um ein Computerspiel handelt, haben die Autoren trotzdem komplett auf eine Netzwerkunterstützung oder künstliche Intelligenz verzichtet.

Die Grafik von JavaRisk ist allerdings so gut, daß das bereits in Ausgabe 39 vorgestellte Spiel J-TEG diese als Theme implementiert hat.

JavaRisk ist ein typisches Studentenprojekt, was dazu führte, daß die drei Autoren auch in Gegenwart ihres Professors nicht davon ablassen wollten.

Dieser bemerkte das Spiel und war auf Anhieb begeistert. Er schlug vor, im 5ten Semester als Studienprojekt eine künstliche Intelligenz für das Spiel zu schreiben und da er außerdem ein Fan des Asiatischen ist, bat er sie um kleine animierte Samurai-Kämpfer für den Fall daß China oder Japan angegriffen werden.

Momentan arbeiten Christian, Sebastian und Andreas an einer neuen Version von JavaRisk, die mehr Ähnlichkeit mit einem strategischen Kriegsspiel wie Empire haben wird. Außerdem wird JavaRisk v2 von Anfang an über Netzwerkunterstützung verfügen.

Emacs Chess

Ebenfalls in Reaktion auf Ausgabe 39 hat sich Mario Lang gemeldet, um mir das Emacs Chess [14] Projekt von John Wiegley zu empfehlen.

Emacs Chess besteht im Wesentlichen aus drei Teilen. Der erste Teil beinhaltet die Anzeigefunktionalität, um verschiedene Typen von Schachbrettern im Emacs anzuzeigen. Der zweite Teil erlaubt die Kommunikation mit verschiedenen Schach-Engines wie GNUChess und Crafty. Und den dritten Teil bildet eine Bibliothek für Positionen und Spiele inklusive Validitätscheck für Züge und Spieldatenbank-Verwaltung.

Zu den wirklich bemerkenswerten Features von Emacs Chess gehört dabei u.A., daß der Emacs IRC Client (ERC) [15] Emacs Chess unterstützt, daher ist es möglich in der IRC-Sitzung ein Spiel mit jemand zu beginnen, der auch über Emacs Chess und ERC verfügt.

Da das IRC Schach-Protokoll auf CTCP basiert, ist es prinzipiell auch möglich, diese Funktionalität kompatibel in anderen Klienten zu implementieren.

Da Emacs auch auf der Konsole vollständig einsetzbar ist, bietet Emacs Chess beispielsweise auch ein Schach-Frontend für blinde Nutzerinnen, die sich Züge sogar im Stile von "Springer schlägt bei a4" verkünden lassen können. Doch natürlich dürfen auch Sehende gerne auf dieses nette Feature zurückgreifen.

Wer den Emacs nicht benutzt, den wird vermutlich auch Emacs Chess nicht dazu bringen, allerdings dürfte es für alle Emacs-Freunde sehr interessant sein.

Der Status dieses unter der GNU General Public License herausgegebenen Programms in Emacs-Lisp ist "Betatest", kleinere Probleme könnten also noch auftreten.

Schluss

Damit genug aus der Brave GNU World für diesen Monat. Ideen, Anregungen, Kommentare und Meldungen über interessante Projekte sind wie immer per Email an die übliche Adresse [1] willkommen.