Abbildungsverzeichnis
Tabellenverzeichnis
1. Einleitung
2. Open Source Software
2.1 Geschichte
2.2 Open Source Definition
2.2.1 Freie Weitergabe
2.2.2 Source Code
2.2.3 Abgeleitete Software
2.2.4 Unversehrtheit des Source Codes des Autors
2.2.5 Keine Diskriminierung von Personen oder Gruppen
2.2.6 Keine Einschränkung bezüglich des Einsatzfeldes
2.2.7 Weitergabe der Lizenz
2.2.8 Keine Lizenzbeschränkung auf ein bestimmtes Produktpaket
2.2.9 Keine Lizenzbeschränkung für die Weitergabe zusammen mit anderer Software.
2.2.10 Die Lizenz muss technologieneutral sein
2.3 Paradigma Open Source
3. Software im Health Care Bereich
3.1 Besonderheiten von Health Care IT
3.1.1 Qualität & Stabilität von Health Care IT
3.1.2 Datenschutz und Datensicherheit in Health Care IT
3.1.3 Ergonomie von Health Care IT
3.1.4 Interoperabilität von Health Care IT
3.2 Open Source Software in der Gesundheits IT
3.2.1 Dimension Qualität und Open Source
3.2.2 Dimension Sicherheit und Open Source
3.2.3 Dimension Ergonomie und Open Source
3.2.4 Dimension Interoperabilität und Open Source
3.2.5 Realisierbarkeit von OSS im Gesundheitsbereich
4. Die Marktanalyse aus theoretischer Sicht
4.1 Analyse der externen Umwelt
4.1.1 Politische und Rechtliche Faktoren
4.1.2 Ökonomische Faktoren
4.1.3 Soziale Faktoren
4.1.4 Technologische Faktoren
4.1.5 PEST-Analyse
4.2 Analyse der internen Umwelt
4.2.1 Identifikation von Stärken und Schwächen
4.2.2 Ressourcenanalyse
4.3 SWOT Analyse
5. Zusammenfassung und Ausblick
6. Marktanalyse anhand von Experteninterviews
6.1 Zielsetzung
6.2 Methodik
6.2.1 Auswahl der Experten
6.2.2 Erstellung des Interviewleitfadens
6.2.3 Interviewablauf
6.2.4 Interviewauswertung
6.3 Ergebnisse
6.3.1 Ergebnisse der Stärken Kategorie
6.3.2 Ergebnisse der Schwächen Kategorie
6.3.3 Ergebnisse der politisch / rechtlichen Kategorie
6.3.4 Ergebnisse der ökonomischen Kategorie
6.3.5 Ergebnisse der sozialen Kategorie
6.3.6 Ergebnisse der technologischen Kategorie
6.3.7 Zusammenführende Ergebnisanalyse
6.3.8 Gütekriterien
7. Diskussion und Ausblick
8. Literaturverzeichnis
Anhang A: Leitfaden für Experteninterview
Anhang B: Transkribierte Interviews
Abbildung 1: heterogenes IT-System im Krankenhaus
Abbildung 2: PEST-Analyse für Open Source Health Care IT
Abbildung 3: Stärken-Schwächen-Profil von Open Source Software im Gesundheitsbereich
Abbildung 4: schematische Darstellung der SWOT-Analyse
Abbildung 5: SWOT-Analyse von Open Source Health Care Software
Abbildung 6: Materialreduzierung durch die Zusammenfassung
Abbildung 7: SWOT-Analyse von Open Source Health Care Software nach Auswertung der Expertenbefragung
Tabelle 1: Reihung der Stärken und Schwächen von Open Source Health Care Software
Tabelle 2: Kategorien der Inhaltsanalyse
Tabelle 3: Prädeterminierter Leitfaden für Experteninterview
Das Phänomen Open Source hält weltweit Einzug in alle Branchen der Wirtschaft. Immer mehr Unternehmen beginnen quellfreie Software einzusetzen, zu fördern oder gar selbst zu entwickeln. Open Source Software befindet sich in der internationalen Wirtschaftswelt auf einem immensen Siegeszug und setzt sich immer mehr gegen die konventionellen proprietä- ren Softwarearchitekturen durch. Begründungen hierfür finden sich nicht nur in den geringe- ren Kosten (Renner et al., 2005), sondern vor allem in der Herstellerunabhängigkeit, Qualität, Sicherheit, Stabilität und sogar in der Ideologie (Stallmann, 2002), die dieser Softwarephilo- sophie zu Grunde liegt. Open Source beschreitet einfach einen anderen Weg, als jenen, den man von konventionellen klassischen Lizenzmodellen für Software gewohnt ist. Profitinteres- sen und Marketing müssen deshalb aber nicht im Hintergrund stehen. Viele neue Geschäfts- möglichkeiten bieten sich als Basis von Open Source Software für Distributoren und Syste- mintegratoren, aber auch für Software- und Hardwarehersteller an (Gläßer, 2004). RedHat, IBM oder Novell sind nur einige populäre Beispiele, dass sich mit Open Source Technologie erfolgreiche kommerzielle Modelle verwirklichen lassen (Sarrouh, 2007).
Auf dem Gebiet des österreichischen Gesundheitswesens, scheint sich der Trend zum Einsatz von Open Source Software jedoch noch nicht in diesem Ausmaß durchgesetzt zu haben. Im Bereich von Health Care IT - wie etwa Krankenhausinformationssystemen (KIS), Laborwert- dokumentationen oder digitaler Bilddiagnostik - ist die Verbreitung offener Architekturen in Österreich noch unterentwickelt. Dieser Markt zeigt sich von der Open Source Bewegung gänzlich unberührt. Sämtliche Gesundheitseinrichtungen setzen auf die altbewährten proprie- tären Softwarelizenzmodelle.
Passt die Open Source Idee nicht in das Umfeld von elektronischen Patientenakten und medizinischen Daten? Wodurch unterscheidet sich Gesundheits-IT von anderen Softwarearchitekturen? Was sind die Risiken, was die Chancen beim Einsatz von Offenen Technologien im Health Care Bereich? Ist Österreich bereit für die Einführung von Open Source Software Systemen im Gesundheitssektor?
Ziel dieser Arbeit ist es, genau diese Fragen aus Marketingsicht zu behandeln. Der erste Teil (Kapitel 2) versucht nun ein genaues Bild der Open Source Bewegung zu zeichnen und be- schäftigt sich mit der Geschichte und der zugrunde liegenden Philosophie quelloffener Syste- me. Im zweiten Teil (Kapitel 3) wird das Thema Health Care IT unter die Lupe genommen.
Hier werden die verschiedenen Arten von Software im Gesundheitswesen beleuchtet und auf die Besonderheiten im Umgang mit medizinischer Software eingegangen. Den Einsatz von Open Source Lizenz Modellen im Gesundheitsbereich beleuchtet dann Open Source Software in der Gesundheits IT in Kapitel 3.2. Hier wird der Versuch unternommen, die Open Source Idee an den in Kapitel 3.1 diskutierten Anforderungen von Health Care IT anzuwenden, um ein neuartiges Software-Produkt zu schaffen, das derzeit einzigartig im österreichischen Ge- sundheitswesen wäre.
Die Frage ob in Österreich der Bedarf für ein solch innovatives Produkt besteht, soll dann anhand einer Marktanalyse geklärt werden. In Kapitel 4 werden die für diesen Zweck einzusetzenden Marketinginstrumente theoretisch beleuchtet. Vor allem auf die Identifikation der externen und internen Faktoren der jeweiligen Organisationsumwelten wird großer Wert gelegt. Mit Hilfsmitteln wie etwa der PEST-Analyse, dem Ressourcen-Profil oder der SWOT Matrix wird hier aus theoretischer Sicht versucht festzustellen, ob und wie der österreichische Gesundheitsmarkt mit Open Source Software erobert werden kann.
Die praktische Anwendung dieser Marketingtools folgt dann in Kapitel 6 dieser Arbeit. An- hand von Experteninterviews wird hier versucht die Anforderungen des österreichischen Ge- sundheitsmarktes an die Open Source Idee empirisch zu untersuchen. Ausführlich wird die gewählte Methodik der Datenerhebung und der Datenanalyse beschrieben. Ebenso widmet sich dieses Kapitel der Aufbereitung der erarbeiteten Ergebnisse der Untersuchung, sowie deren Überführung auf die theoretisch erarbeiteten Konzepte und Erkenntnisse.
Das Abschlusskapitel diskutiert schließlich die aus Theorie und Empirie gewonnenen Ergeb- nisse und versucht einen Ausblick auf die Marktchancen und Marktrisiken von Open Source Softwarelizenzmodellen in der heimischen IT-Landschaft von Gesundheitsinstitutionen zu geben.
Um quelloffene Software im österreichischen Gesundheitsbereich im Kontext des modernen Marketings genau beleuchten zu können, muss zu allererst der Begriff Open Source Software genauer definiert werden. Das Schlagwort „Open Source“ ist inzwischen sehr weit verbreitet, wird quasi schon inflationär behandelt und lässt heute einen sehr breiten Interpretationsspiel- raum zu. Um diesen mächtigen Begriff etwas einzugrenzen bietet dieses Kapitel einen Ein- blick in die Entstehungsgeschichte von freier Software und Open Source, liefert eine genaue Definition des Open Source Software Begriffes, versucht das Paradigma von offenen Archi- tekturen zu beleuchten und ein klares Bild zu zeichnen worum es bei quelloffener Software eigentlich geht.
Das Konzept der Freien Software ist im ursprünglichen Sinn eigentlich kein neues. Als die Computer die Universitäten erreichten, waren diese reine Forschungsgeräte. Die entstandenen Programme wurden frei getauscht und Entwickler wurden für das Programmieren, und nicht für die eigentliche Software bezahlt (Perens, 1999).
Erst später, als die Computer die Wirtschaftswelt erreichten, begannen sich Programmierer gegenseitig zu unterstützen, in dem sie Gebühren für jede Kopie des Programms abverlang- ten. Man stellte Anfang der siebziger Jahre fest, dass man mit der Hilfe von Lizenzverträgen die freie Weitergabe von Software einschränken, beziehungsweise ganz verbieten könne. So entstanden neben Systemherstellern, die zunächst nur Programme für die eigenen Systeme lieferten, auch Firmen, die sich auf die Herstellung von Software spezialisierten (Gläßer, 2004). Es entstand jenes Lizenzmodell, welches heute als proprietäre Software bekannt ist. Der Quellcode des Programms wird vom Softwarehersteller als Intellectual Property gesehen und wird als Betriebsgeheimnis betrachtet und entsprechend genützt (Erber, 2008).
Die Idee quelloffene Software als politisches Statement zu nutzen ist allerdings noch nicht so alt (Perens, 1999). Richard Stallman - er gilt weithin als Begründer der Freien Software - formulierte das Konzept für quelloffenen Code erst im Jahre 1985 (Erber, 2008). Stallman störte, dass die Anwender durch Geheimhaltung des Codes vom Wissen um die Software ab- gehalten wurden. Ihm widerstrebte, dass die Softwarehersteller auf diesem Weg über den Umgang mit den Programmen bestimmten. Nach Gläßer (2004) ging es Stallman vor allem um die Idee der Informationsfreiheit beim Umgang mit der Software. Stallmann beschreibt in seinem Essay Free Software Definition, welches in seinem Buch Free Software, Free Society 2002 erschienen ist, folgende Freiheiten, die dem Benutzer freier Software garantiert werden:
- Freiheit 0: Die Freiheit die Software für jeden Zweck zu verwenden.
- Freiheit 1: Die Freiheit zu untersuchen, wie das Programm funktioniert und es an eigene Bedürfnisse anzupassen. Dafür ist die Verfügbarkeit des Quellcodes Voraussetzung.
- Freiheit 2: Die Freiheit Kopien weiterzuverteilen um seinem Nachbarn zu helfen.
- Freiheit 3: Die Freiheit ein Programm zu verbessern und seine Ände- rung zu publizieren, damit die gesamte Community profitiert. Auch hier ist Zugriff auf die Quellprogramme Voraussetzung. (Stallmann, 2002, S.43)
1985 gründete Stallmann die Free Software Foundation (FSF), welche später die Basis für das GNU Projekt - ein freies Softwarepaket - bilden sollte (Erber, 2008). Die GNU Software - das Akronym GNU steht für „GNU’s Not Unix“ (Stallmann, 2002, S.33) - wurde gemeinsam mit dem Kernel von Linus Torvalds, einem finnischen Informatikstudenten an der Universität Helsinki entwickelt. So entstand das Linux Betriebssystem mit umfassender Anwendersoftware und einer vollständigen Software-Entwicklungsumgebung, dessen Verbreitung und Nutzung durch die wohl bekannteste und wichtigste Lizenz für Freie Software, die GNU General Public License (GPL), geregelt wird (Gläßer, 2004).
Stallman lehnte die Idee vom Copyright, wie sie bei proprietärer Software zu finden ist strikt ab (Stallman, 2002). Das Copyright beinhaltet Urheberrechte wie Nutzungs-, Lizenz und Ver- vielfältigung und bezieht sich dabei auf den Urheber einer Arbeit, Leistung oder Idee. Die freie Weitergabe von Software wurde damit verboten. Bei Stallmans ursprünglichem Lizenz- modell, der GPL, war genau das Gegenteil der Fall: nämlich eine Verpflichtung zur Weiter- gabe (Gläßer, 2004). Als Gegenstück zum Copyright stellte Stallman hier das Prinzip von Copyleft vor.
Nicht zu verwechseln ist der Begriff Freie Software (engl. Free Software) mit dem Begriff Freeware. Während sich „free“ in Freeware auf den Preis der Applikation bezieht, bezeichnet es in Free Software die Freiheit für den Anwender. Stallman beschreibt dieses Thema folgendermaßen:
Free Software is a matter of liberty, not price. To understand the concept, you should think of “free” as in “free speech”, not as in “free beer”. Free Software is a matter of the user’s freedom to run, copy, distribute, study, change and improve the software. (Stallmann, 2002, S.43)
Stallmans einflussreiche Non-Profit Initiativen sorgten schließlich dafür, dass Freie Software selbst in den Erfolgszeiten von Microsoft Überlebensfähigkeit bewies (Freyermuth, 2007). 1990 wurde er dafür mit dem siebenstellig dotierten MacArthur Genius Grant belohnt.
Der Begriff Open Source ist deutlich jünger als die Idee von Freier Software. Erst im Jahr 1998 kam vom amerikanischen Softwareexperten Eric S. Raymond der Vorschlag, Software mit offenem Quellcode als Open Source Software zu bezeichnen (Gläßer, 2004). Dieser publizierte 1999 den vielzitierten Essay The Cathedral and the Bazaar, in dem gleichnamigen Buch, in welchem er die Linux Community mit einem wild durcheinander plappernden Basar mit unterschiedlichsten Zielsetzungen und Ansätzen vergleicht, die trotz aller Widrigkeiten zum einem bedeutenden Erfolg findet1.
Raymonds faszinierte mit seinem Essay das damalige Netscape Management, wo er in der Folge auch als Berater für den Open Source Internetbrowser Netscape Navigator™ tätig war. Seine Chronik über die erfolgreiche Freie Softwareentwicklung durch unbezahlte freiwillige Entwickler gilt heute als wichtigstes Werk der Literatur über Open Source Software Entwicklung überhaupt (z. B. Freyermuth, 2007; Perens, 1999). In der Folge sind, nicht zuletzt durch die weltweite Verbreitung des Internets, unzählige Open Source Software Projekte entstanden (Gläßer, 2004). Die vielen größtenteils namenlos gebliebenen Handwerker gelten heute als die wahren Architekten (Himanen, 2001) der New Economy.
Aus der Studie Open Source Software - Einsatzpotenziale und Wirtschaftlichkeit des Fraun- hofer Instituts (Renner et al., 2005) geht hervor, dass Open Source Software ursprünglich we- niger als Ersatz für kommerzielle Produkte geplant war. Vielmehr wollte man das weltweite Potenzial guter Entwickler nutzen. Vor allem durch die Idee des Reuse of Code wurde der Quellcode immer häufiger zugänglich (Erber, 2008) und konnte so immer weiter verbessert und erweitert werden, wobei hingegen bei proprietärer Software mit Closed Source der Sour- ce Code immer wieder neu entwickelt werden musste, welcher aber an einer anderen Stelle bereits bestand.
Um das immense Wissen und Innovationspotential der Open Source Community zu nutzen, gaben nun auch immer mehr kommerzielle Softwarehersteller den Quellcode ihrer Produkte frei. Die so entstandenen Open Source Versionen dienten den Herstellern dann als Basis für kommerzielle Produkte, welche die gewohnten Produktfreigabezyklen durchliefen (Gläßer, 2004). Die Open Source Bewegung war geboren.
Heute wird die Open Source Bewegung durch eine Vielzahl von weltweit tätigen Entwicklern in zahlreichen Projektgruppen getragen die ihre Softwareprodukte mit Open Source Lizenzen veröffentlichen. Parallel hat sich hier eine Reihe von gemeinnützigen Organisationen gebildet, die sich der Verbreitung von Open Source Software verschrieben haben. Gläßer (2004) er- wähnt hierzu die Open Source Initiative (OSI), die Free Standards Group und die in diesem Kapitel bereits erwähnte Free Software Foundation um Richard Stallman, aber auch projekt- spezifische Organisationen wie die Linux Standards Base oder das Linux Professional Institu- te. Zusätzlich zu den unzähligen Entwicklern und gemeinnützigen Institutionen sind schließ- lich noch sämtliche geschäftliche Dienstleistungsunternehmen und Distributoren zur Open Source Bewegung zu zählen, welche auf Basis der breiten Open Source Community kommer- zielle Zwecke verfolgen.
Nachdem das letzte Kapitel einen kurzen Einblick in die Entwicklungsgeschichte quelloffener Software gegeben hat, widmet sich dieser Abschnitt der Begriffsdefinition und Begriffsabgrenzung von Open Source.
Obwohl Stallmans Vision von Freier Software und Raymonds Open Source Konzept eng ver- flochten scheinen, verfolgen die Bewegungen dennoch unterschiedliche Ideologien (Stallman, 2002, S.57). Für die Vertreter Freier Software stehen gesellschaftliche Ideale im Vordergrund, hingegen entwickelt die Open Source Bewegung ein Modell für die Softwareentwicklung, welches eine Zusammenarbeit mit kommerziellen Unternehmen durchaus zulässt. Stallman (2002) behandelt dieses Thema eingehend in seinem Essay Why „Free Software“ is better than „Open Source“. Während die von der Free Software Foundation verwendete GNU GPL die Verwendung der Software für kommerziellen Gebrauch grundsätzlich einschränkt, ist dies bei Open Source Software nicht grundsätzlich verboten. Bei Open Source Software Projekten ist die Nutzung und die Verbreitung von Erweiterungen und Änderungen zwar nicht völlig frei, wird aber über Lizenzen geregelt (Gläßer, 2004). Grundsätzlich unterscheiden sich die Lizenzen vor allem durch diverse Abstufungen des Copyleft-Effekts, die Veränderung des zugrunde liegenden Quellcodes oder die Verwendung des quelloffenen Codes in eigener Software.
Für die exakte Definition von Open Source Software ist heute die bereits in Kapitel 2.1 er- wähnte Open Source Initiative (OSI) maßgeblich (Renner et al., 2005). Obwohl Stallman als Begründer der Freien Software gilt und sich inzwischen stark von der Open Source Bewegung distanziert (Stallmann, 2002), finden sich viele seiner Ideen in der Open Source Definition der OSI wieder (Perens, 1999), welche als Grundlage für alle bestehenden Open Source Lizenz- modelle gilt. Dieser Standpunkt ist selbst in dem Artikel Warum „Open Source“ das Wesent- liche von „Freier Software“ verdeckt von Richard Stallman (2008) nachzulesen.
Die nun folgenden Unterkapitel 2.2.1 bis 2.2.10 behandeln eine sinngemäße deutsche Übersetzung der Open Source Definition der OSI (Open Source Initiative, 1997). Zum besseren Verständnis werden die einzelnen Lizenzrichtlinien der OSI zusätzlich kommentiert.
Die Richtlinie Free Redistribution ist wohl die bedeutendste Regel der Open Source Definition. Sie besagt, dass Open Source Software nach Belieben an Dritte weitergegeben werden darf und dass Einschränkungen der Autoren bezüglich der Weitergabe unzulässig sind (Renner et. al., 2005). Die genaue Übersetzung dieser Richtlinie lautet wie folgt:
Die Lizenz darf niemanden in seinem Recht einschränken, die Software als Teil eines Software-Paketes, das Programme unterschiedlichen Ursprungs enthält, zu verschenken oder zu verkaufen. Die Lizenz darf für den Fall eines solchen Verkaufs keine Lizenz- oder sonstigen Gebühren festschreiben. (Open Source Initiative, 1997) Gläßer (2004) interpretiert, dass hier also nicht nur Kopien der Software angefertigt, sondern auch verkauft werden dürfen. Der Kaufpreis darf hier aber nur den Aufwand für das Kopieren und die Zusammenstellung der Programme enthalten. Für die Programme selbst dürfen ja keine Gebühren verlangt werden.
Die Richtlinie Source Code enthält ebenfalls eine der tragenden Kernaussagen der Open Source Bewegung. Die Forderung enthält die vollständige Offenlegung des Quellcodes in einer Form welche von jedem zugänglich ist. Die OSI formuliert dies folgendermaßen:
Das Programm muss den Quellcode beinhalten. Die Weitergabe muss sowohl für den Quellcode als auch für die kompilierte Form zulässig sein. Wenn das Programm in irgendeiner Form ohne Quellcode weiter- gegeben wird, so muss es eine allgemein bekannte Möglichkeit geben, den Quellcode zum Selbstkostenpreis zu bekommen, vorzugsweise als gebührenfreien Download aus dem Internet. Der Quellcode soll die Form eines Programms sein, die ein Programmierer vorzugsweise be- arbeitet. Absichtlich unverständlich geschriebener Quellcode ist daher nicht zulässig. Zwischenformen des Codes, wie sie etwa ein Präpro- zessor oder ein Konverter erzeugt, sind unzulässig (Open Source Initiati- ve, 1997).
Offener Quellcode ist eine notwendige Grundvoraussetzung für die Modifikation oder Reparatur eines Programms (Perens, 2002). Für eine möglichst einfache Weiterentwicklung muss der Code für jedermann zugänglich und in einer leicht nachvollziehbaren Form bereitgestellt werden (Gläßer, 2004).
Die OSI beschreibt in der Richtlinie Derived Works den Umgang für die Veränderung von Source Code und die damit geschaffenen neuen Software Produkte folgendermaßen:
Die Lizenz muss Veränderungen und Derivate zulassen. Außerdem muss sie es zulassen, dass die so entstandenen Programme unter denselben Lizenzbestimmungen weiter vertrieben werden können wie die Ausgangssoftware. (Open Source Initiative, 1997)
Gläßer (2004, S.23) kommentiert hier, dass die aus Open Source Software abgeleiteten Programme zwar unter der gleichen Lizenz weiterverbreitet werden, es darf aber zusätzlich auch eine andere Lizenz gewählt werden. Damit sei es grundsätzlich sogar möglich, dass ein auf Open Source Software basierendes Programm nicht frei sei. Ein ähnlicher Standpunkt ist auch bei Perens (1999) zu finden.
Um die Integrität des Autors zu schützen, erlässt das OSI in der Open Source Definition die Richtlinie Integrity of the Author’s Source Code. Diese Richtlinie schafft die Möglichkeit die Arbeit des Originalentwicklers unverändert weiterbestehen zu lassen:
Die Lizenz darf die Möglichkeit, den Quellcode in veränderter Form wei- terzugeben nur dann einschränken, wenn sie es vorsieht, dass zusam- men mit dem Quellcode so genannte „Patch Files“ weitergegeben wer- den dürfen, die den Programmcode bei der Kompilierung verändern. Die Lizenz muss die Weitergabe von Software, die aus verändertem Quellcode entstanden ist, ausdrücklich erlauben. Die Lizenz kann ver- langen, dass die abgeleiteten Programme einen anderen Namen oder eine andere Versionsnummer als die Ausgangssoftware tragen. (Open Source Initiative, 1997)
Viele Entwickler fürchteten dass etwaige fremde Veränderungen ihres originalen Source Codes eine schlechte Reputation liefern könnten (Perens, 1999). Durch diese Richtlinie wird die Möglichkeit geschaffen eine Trennung zwischen eigenem und fremdem Code zu schaffen ohne die Modifikationen einzuschränken. Perens (1999) erwähnt in diesem Kontext auch die Nutzung dieser Regel durch Netscape, die ihren Internetbrowser Netscape Navigator™ nennen, während die freien Versionen des Programms Mozilla oder anders lauten.
Ein politisches Statement findet sich in der Richtlinie No Discrimination Against Persons or Groups. Demnach darf keine Lizenz Personen oder Gruppen benachteiligen. Die OSI definiert dies folgendermaßen:
Die Lizenz darf weder Personen noch Gruppen benachteiligen. Das be- deutet dass durch die Lizenz niemand von der Mitarbeit in einem Open Source Projekt ausgeschlossen werden darf. (Open Source Initiative, 1997)
Diese Regel erscheint heutzutage seltsam und befremdend, geht aber laut Perens (1999) auf ein Verbot der University of California, Berkely zurück, die den Einsatz einer Software für elektronisches Design der südafrikanischen Polizei aus Gründen der Apartheidspolitik untersagte. Nach Meinung der OSI soll Software nicht auf bestimmte Personenkreise beschränkt werden, egal wie ehrenhaft die Gründe dafür auch sein mögen (Perens, 1999).
In eine ähnliche Richtung zielt auch die Richtlinie No Discrimination Against Fields of En- deavor. Sie behandelt einerseits eine sozialpolitische Forderung (Perens, 1999), andererseits beleuchtet sie auch den kommerziellen Aspekt von Open Source Software (Gläßer, 2004):
Die Lizenz darf niemanden daran hindern, das Programm in einem bestimmten Bereich einzusetzen. Zum Beispiel darf sie den Einsatz des Programms in einem Geschäft oder in der Genforschung nicht ausschließen. (Open Source Initiative, 1997)
Gläßer (2004) unterstreicht hier vor allem die geschäftliche Bedeutung indem er interpretiert, dass bei Open Source Software keine Anwendungsgebiete, vor allem nicht jener mit kommer- zieller Nutzung der Programme verboten werden können. Dieser Standpunkt ist auch in der Studie des Fraunhoferinstituts (Renner et al., 2005, S.13) nachzulesen. Gleichzeitig erwähnt die Studie aber auch die Komponente der Nutzungszwecke, welche bei Perens (1999) noch genauer beleuchtet und mit folgendem Statement kommentiert wird: „Your software must be equally usable in an abortion clinic, or by an anti-abortion organization. These political arguments belong on the floor of Congress, not in software licenses” (S. 179).
Natürlich regelt die OSI auch die Weitergabe von Lizenzen. Dies wird mit der Richtlinie Distribution of License geregelt, welche wie folgt lautet:
Die Rechte an einem Programm müssen auf alle Personen übergehen, die diese Software erhalten, ohne dass für diese die Notwendigkeit be- stünde, eine eigene, zusätzliche Lizenz zu erwerben. (Open Source Ini- tiative, 1997)
Diese Regel soll einen Statusverlust der Software auf indirektem Weg verhindern. Die Rechte des Nutzers müssen erhalten bleiben, ohne dass dieser eine besondere Einverständniserklärung unterfertigen muss (Gläßer, 2004). So darf zum Beispiel nicht verlangt werden, das Programm nicht offen weiterzugeben.
Die Richtlinie License Must Not Be Specific to a Product schließt aus, dass Software nur dann als frei anzusehen ist, wenn sie Bestandteil einer bestimmten Distribution ist (Gläser, 2004). In der Open Source Definition des OSI ist diese folgend beschrieben:
Die Rechte an dem Programm dürfen nicht davon abhängig sein, ob das Programm Teil eines bestimmten Software Paketes ist. Wenn das Programm aus dem Paket herausgenommen und im Rahmen der zu diesem Programm gehörenden Lizenz benutzt oder weitergegeben wird, so sollen alle Personen, die dieses Programm dann erhalten, alle Rechte daran haben, die auch in Verbindung mit dem ursprünglichen Software Paket gewährt wurden. (Open Source Initiative, 1997)
Das bedeutet, dass ein Produkt das z.B. Teil einer bestimmten Linux Distribution oder ähnlichem ist auch dann frei bleibt, wenn das Produkt von der Distribution getrennt wird, mit der es ausgeliefert wurde (Perens, 1999).
Die OSI regelt mit der Richtlinie License Must Not Contaminate Other Software die Verbreitung von Open Source Software gemeinsam mit proprietärer Software. Dies ist in der Open Source Definition folgend beschrieben:
Die Lizenz darf keine Einschränkungen enthalten bezüglich anderer Software, die zusammen mit der lizenzierten Software weitergegeben wird. So darf die Lizenz zum Beispiel nicht verlangen, dass alle anderen Programme, die auf dem gleichen Medium weitergegeben werden, auch quelloffen sein müssen. (Open Source Initiative, 1997)
Die Lizenz regelt also die Nutzung von Open Source Software in beliebiger Kombination, also auch in Verbindung mit kommerziellen Produkten (Gläßer, 2004).
Mit der OSI Richtlinie License Must Be Technology-Neutral regelt die Open Source Initiative schließlich auch noch den Umgang mit unterschiedlichen Technologien. Sie ist in der Open Source Definition folgend angeführt:
Keine Bestimmung der Lizenz darf sich auf eine einzelne Technologie oder Schnittstelle stützen. Das bedeutet, dass keine bestimmte Technologie oder Schnittstelle vorgeschrieben beziehungsweise ausgeschlossen werden darf. (Open Source Initiative, 1997)
Diese Regel sichert eine breite Akzeptanz für unterschiedliche Technologien und Schnittstellenstandards. Sie besagt, dass weder bestimmte Technologien noch bestimmte Schnittstellen ausgeschlossen oder gefordert werden dürfen (Gläßer, 2004)
Betrachtet man die in den Kapiteln 2.2.1 - 2.2.10 aufgelistete Open Source Definition der Open Source Initiative, so erhält man bereits ein relativ genaues Gesamtbild der Open Source Idee. Die OSI selbst beschreibt das grundlegende Ziel von Open Source Software so:
The basic idea behind open source is very simple: When programmers can read, redistribute, and modify the source code for a piece of soft- ware, the software evolves. People improve it, people adapt it, people fix bugs. And this can happen at a speed that, if one is used to the slow pace of conventional software development, seems astonishing. (Open Source Initiative, 2005)
Das Konzept von Open Source Software bietet eine Reihe von Vorteilen, die den Entwicklern, Dienstleistungsunternehmen, Institutionen und Benutzern zur Verfügung stehen. Weniger die Kostenersparnis durch Lizenzkosten proprietärer Software und die längere Nutzung der Hardware stehen hier im Vordergrund (Renner et al., 2005), sondern vielmehr die Idee vom Reuse of Code (Erber, 2008). Die Verwendung von Komponenten eines Open Source Produkts in den eigenen Architekturen kann nicht nur Entwicklungszeit einsparen, das Studieren des Quellcodes anderer Entwickler ermöglicht auch einen hohen Wissenstransfer innerhalb der Open Source Community (Renner et. al., 2005).
Befürworter von Open Source Software schreiben quelloffenen Applikationen eine tendenziell höhere Produktqualität zu, welche dem grundlegend anderen Entwicklungsprozess2 der für Open Source Produkte gilt zuzuschreiben ist (Renner et al., 2005). Während bei Open Source Software neue Entwicklungen und Änderungen schon von Anfang an durch Anwender und Tester begutachtet werden, wird bei der Qualitätssicherung kommerzieller Software nur das Einhalten der Spezifikation getestet. Der Freigabezeitpunkt hängt dann auch nicht zwangsläufig vom Erreichen einer bestimmten Qualität ab als vielmehr von strategischen Überlegungen von Marketing und Vertrieb (Gläßer, 2004).
Abschließend ist hierzu also zu bemerken, dass die Open Source Idee weit mehr als nur einen weiteren Konkurrenten zu den bereits existierenden Lizenzmodellen darstellt, sondern vielmehr eine „strukturbildende Leitidee“ (Freyermuth, 2007, S.20) ausgehend von arbeitsorgani- satorischen Motiven repräsentiert, welche die Denk- und Arbeitsweisen grundlegend geprägt hat. Das Paradigma Open Source steht also für die kooperative Herstellung und Verbreitung von Software (Tebe & Hepp, 2008), an der weltweit vernetzte Entwickler mit unterschiedli- chen Tagesabläufen und Ansätzen gleichzeitig und erfolgreich arbeiten (Raymond, 1997).
Während im letzten Kapitel die Geschichte, die Definition und das Paradigma von offenen Architekturen beschrieben wurden, widmet sich dieser Teil generell den Strukturen der In- formationstechnologie (IT) im Gesundheitsbereich. Der folgende Abschnitt (Kapitel 3.1) be- schäftigt sich mit den Besonderheiten von Health Care IT und identifiziert die Unterschiede zu IT-Systemen aus anderen Wirtschaftsbereichen. Im zweiten Abschnitt (Kapitel 3.2) wird versucht, die in Kapitel 2 definierten Eigenschaften von Open Source Software auf die Be- sonderheiten der Architekturen in Gesundheitsinstitutionen anzuwenden. Es gilt zu klären ob ein Open Source Produkt überhaupt die technischen Rahmenbedingungen von Health Care IT erfüllen kann.
Informationssysteme im Gesundheitswesen unterliegen anderen Grundvoraussetzungen als IT-Systeme wie sie zum Beispiel in der Industrie zu finden sind. Der markanteste Unterschied ist wohl jener, dass sich hinter den verarbeiteten Datensätzen zumeist keine Produktionsgüter, Materialien oder Konten befinden, sondern Patienten, die der Hilfe von Gesundheitseinrich- tungen bedürfen. Seit Beginn der 80er Jahre wird hier versucht den Menschen noch intensi- ver in die Datenstrukturen der Informationssysteme zu integrieren (Hägele & Köhler, 2002). Der Umgang mit so sensiblen Daten erfordert zwangsläufig andere Rahmenbedingung als beim Einsatz von IT-Systemen in der Industrie. Health Care IT erfordert eine hohe zeitliche Verfügbarkeit (Lechleitner, 2006). Die klinischen Applikationen müssen rund um die Uhr verfügbar sein, auch während Datensicherungen, Datenreorganisationen und Systemausbau- ten. Außerdem müssen diese ein gutes Antwortzeitverhalten aufweisen, um einen reibungslo- sen Ablauf im medizinischen Tagesgeschäft zu gewährleisten. Um die speziellen Anforderun- gen von Health Care IT genau zu beleuchten, werden die folgenden Dimensionen untersucht.
Medizinische Entscheidungen, die oftmals auf Datenbasis von Health Care IT Systemen ge- troffen werden, haben oft eine direkte Auswirkung auf Therapieerfolg, operative Eingriffe und über den weiteren Gesundheitsverlauf von menschlichem Leben. Nicht zuletzt aus diesem Grund stellt IT im Gesundheitswesen einen hohen Anspruch auf Qualität. Viele medizinische Softwareapplikationen obliegen hier dem Medizinproduktgesetz und müssen allein schon aus diesem Grund hohen Qualitätsansprüchen standhalten. Einerseits sind hier die gesetzlichen Vorgaben zu Qualitätsmanagement und Qualitätssicherung zu befolgen, andererseits auch die Fragen der Zertifizierung, der Patientensicherheit, der Transparenz und Qualitätsdarlegung nach außen zu beachten (Sens, 2009). Gesundheitsunternehmen verfügen über mindestens so hohe Ansprüche an stabile und hochverfügbare Systeme wie die Industrie, zumeist stehen diesen aber wesentlich geringere IT-Budgets (Walther & Becker, 2009) zur Maßnahmenreali- sierung gegenüber.
Da die Sensibilität der Daten in der medizinischen IT um ein Vielfaches höher ist, als in vielen anderen Bereichen, fällt dem Thema Datenschutz hier eine noch bedeutendere Rolle als bei anderen Informationssystemen zu. Zusätzlich zum Schutz und der Wahrung der Privatsphäre eines Menschen, eine Prämisse die sämtliche IT-Systeme betrifft, beschäftigen sich medizinische Informationssysteme zusätzlich noch mit dem Thema der ärztlichen Schweigepflicht. Das Verspeichern, Einsehen oder Verändern von Diagnosen, Anamnesen und Prognosen erfordert ein komplexes Berechtigungssystem. Hier gilt das Prinzip der minimalen Rechte (Seelos, 1991) bzw. das Need-to-Know-Prinzip (Pommerening, 1991), welches besagt, dass der berechtigte Personenkreis und deren Rechte zu minimieren sind.
Die Health Care IT Systeme müssen also einerseits die Möglichkeiten bereitstellen Berechti- gungsschemen für die Anwenderschaft einzurichten. Andererseits müssen auch Werkzeuge unterstützt werden, welche sicherstellen, dass sich hinter dem anmeldenden User auch tat- sächlich jene Person verbirgt, dem die benötigten Zugriffsrechte zugewiesen wurden. Haas (2005) nennt als Mittel zur Zugangskontrolle etwa die Verwendung von Passwörtern, Zu- gangscodes, Chipkarten und auch die Möglichkeit zur Überprüfung biometrischer Daten wie die Analyse und Erkennung der Pupille, eines Fingerabdrucks, des Gesichtes oder der Stim- me. Ebenfalls erfolgt hier aber auch eine Zugriffskontrolle. Dies wird durch eine automatische Protokollierung der Schreib- und Lesezugriffe gewährleistet (Historisierungsfunktion).
Eine weitere Besonderheit von Health Care IT bietet die spezielle Ergonomie der Eingabe- schirme. Für einen Großteil der Benutzer von medizinischen Applikationen versteht sich die elektronische Datenerfassung und Verarbeitung nicht als Teil des Kernaufgabengebietes der jeweiligen Berufsgruppe. Gut integrierte Gesundheits IT Systeme unterstützen also den Benutzer bei seinen Primäraufgaben und behindern ihn nicht dabei (Herbig, 2006). Dementsprechend berücksichtigt werden hier die Gesichtspunkte der einfachen und intuitiven Bedienung (Usability) für das Arbeiten mit den jeweiligen Applikationen. So ist auch bei Hegner (2003) nachzulesen, dass aus den vielen Gestaltungsmöglichkeiten, die moderne Technologien beinhalten, immer Applikationen entstehen müssen, die zu den spezifischen menschlichen Anforderungen passen. In weiterer Folge hält gute Verständlichkeit und Bedienbarkeit der Health Care IT Systeme auch den Schulungsaufwand gering (Lechleitner, 2006).
Eine wichtige Vorgehensweise der Sozialwissenschaften für die Bewertung von Systemen ist die Evaluation (Bortz & Döring, 2002). Nach Görner und Ilg (1993) bedeutet dies für die Softwareergonomie eine systematische Sammlung, Auswertung und Interpretation von Daten um eine aussagekräftige Bewertung von Benutzerschnittstellen zwischen medizinisch / pflegerischen Personal und Health Care IT Systemen zu erhalten.
Die Anzahl von unterschiedlichen heterogenen IT-Systemen innerhalb eines Krankenhauses ist immens hoch. Beispielsweise sind bis zu 80 verschiedene Applikationen (Walther & Becker, 2009) in einer Universitätsklinik keine Seltenheit. Jedes der Einzelsysteme verfügt über spezialisierte Fähigkeiten auf dem jeweiligen Aufgabengebiet (Best-of-Breed) in welchem es eingesetzt wird (Johner, 2009). Diese Menge an unterschiedlichen Systemen setzt unwillkürlich eine große Anzahl von Schnittstellen zwischen den einzelnen Applikationen und gemeinsame Standards der einzelnen Anwendungen voraus.
Ein wesentliches Leistungsmerkmal medizinischer IT ist also die Interoperabilität - die Fä- higkeit zur Zusammenarbeit verschiedener IT-Systeme (Haas, 2005). Nur so können Zeit und Kosten gespart und eine hohe Datenqualität gewährleistet werden. Das Zusammenspiel meh- rerer eigenständiger Systeme wird in der Regel durch lose Kupplungen implementiert, bei welchen der Informationsaustausch durch das Senden und Empfangen von Nachrichten er- möglicht wird (Haas et al., 2009). Die durch Systemschnittstellen und gemeinsame Standards erschaffene Struktur wird dann als verteiltes System bezeichnet. Solche Architekturen sind typisch für IT-Systeme, die in großen Gesundheitsinstitutionen wie Krankenhäusern einge- setzt werden.
Haas (2005) weist darauf hin, dass bei heterogenen Informationssystemen mit Software unter- schiedlicher Hersteller sämtliche Komponenten des logischen Architekturmodells mit indivi- duellen Datenmodellen, Datenhaltungen, Softwarearchitekturen sowie Funktionen und Benut- zeroberflächen arbeiten. Die einzelnen Systemteile sind nur über eine spezielle Kopplungs- software (z.B. Kommunikationsserver) miteinander verbunden, über welche dann der Daten- abgleich und die Kommunikation erfolgt (siehe Abbildung 1). Die abgeglichenen Informatio- nen werden dann aus den Subsystemen in das übergeordnete System rückübermittelt.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1: heterogenes IT-System im Krankenhaus
Die Abbildung zeigt eine (stark vereinfachte) schematische Darstellung eines heterogenen IT-Systems wie es in Krankenanstalten üblicherweise betrieben wird. Die Subsysteme arbeiten mit lokalen Datenbanken, die Kommunikation und der Datenabgleich wird mit der Hilfe spezifischer Standards über den Kommunikationsserver geregelt (Abbildung nach: Haas, 2005, S. 65).
Wie bereits zuvor erwähnt, sind für den Datenaustausch zwischen den einzelnen Subsystemen einheitliche Schnittstellenstandards eine wichtige Voraussetzung. Sowohl bei Haas (2005), wie auch bei Haas et al. (2009) und bei Thun (2009) werden hier unter anderem die Standards HL7 Version 2 und 3, sowie DICOM und xDT angeführt, welche die jeweiligen medizinischen Applikationen unterstützen sollten. Zusammenfassend ist also zu bemerken, dass die Standards eine herstellerunabhängige Plattform für die Übermittlung und den Abgleich gesundheitsspezifischer und demographischer Patientendaten zwischen den unterschiedlichen Systemen in einer heterogenen Struktur bieten.
Da im letzten Kapitel die Besonderheiten von Health Care IT eingehend diskutiert wurden, kann nun untersucht werden, ob die Open Source Idee auf diese Besonderheiten angewandt und ob der Weg quelloffener Software im Gesundheitsbereich einzusetzen überhaupt beschritten werden kann. Der folgende Abschnitt untersucht nun die Tauglichkeit der Open Source Technologie in Bezug auf die im letzten Kapitel identifizierten Dimensionen von Besonderheiten von Gesundheitssoftware.
Wie in Kapitel 3.1.1 beschrieben wird, ist Qualität eine bedeutende Grundvoraussetzung für medizinische Applikationen. Nach Gläßer (2004) liegt die Qualität bei Open Source Systemen höher als bei proprietärer Software. Begründet wird dies durch die hohe Anzahl von Anwen- dern und Testern welche die Neuentwicklungen und Änderungen schon von Beginn des Ent- wicklungsprozesses an begutachten. Auch Erber (2008) schreibt quelloffener Software eine höhere Qualität zu, da durch die Wiederverwendung von Code dieser immer wieder überprüft und verbessert wird. Außerdem entfällt hier oft der Termindruck und damit wird auch ein Sinken der Fehlerhäufigkeit argumentiert. Die höhere Produktqualität von Open Source Soft- ware gegenüber klassisch kommerziellen Lizenzmodellen bestätigt auch die Studie des Fraunhofer Instituts Open Source Software - Einsatzpotenziale und Wirtschaftlichkeit (Ren- ner et al., 2005). Folglich ist der Qualitätsstandard von Open Source Systemen mehr als aus- reichend für den Betrieb von Health Care IT Systemen.
Bedenklicher erscheint hier allerdings der rechtliche Qualitätsaspekt. Open Source Software wird in der Regel auf internationaler Ebene entwickelt und die rechtlichen Gegebenheiten eines einzelnen Landes werden hier kaum berücksichtigt. Einige der im Gesundheitsbereich eingesetzten Programme unterliegen dem jeweiligen nationalen Medizinproduktgesetz, welches ein kostspieliges Lizenzierungsverfahren voraussetzen. Bei quelloffenen Lösungen feh- len häufig die Investoren, die die Kosten für die teuren notwendigen Zertifizierungen über- nehmen (Schütz & Filler, 2005). Vom Medizinproduktgesetz sind vor allem Applikationen betroffen, die dafür bestimmt sind Verletzungen oder Krankheiten zu diagnostizieren oder zu behandeln, beziehungsweise die menschliche Anatomie oder Physiologie zu verändern (John & Geis, 2009). Applikationen wie Krankenhausinformationssysteme (KIS), Arztpraxisinfor- mationssysteme, Informationssysteme für Krankenkassen, Abrechnungsapplikationen, Kom- munikationssoftware, Workflow Software, Controllingsysteme, sowie sämtliche Applikatio- nen für administrative Tätigkeiten oder Textschreibung fallen nicht unter das Medizinpro- duktgesetz.
Eine weitere Dimension in der Betrachtung von Open Source Softwaresystemen im Gesundheitswesen stellt das in Kapitel 3.1.2 diskutierte Thema Datenschutz dar. Open Source Architekturen bieten aufgrund der Verfügbarkeit des Quellcodes eine höhere Sicherheit als konventionell geschlossene Systeme, da jeder Einsicht in den Quellcode nehmen und so Sicherheitslücken viel rascher entdeckt werden (Renner et al., 2005). Ebenso erfolgt die Bereitstellung von Servicepacks zur Fehlerbehebung viel rascher als bei proprietärer Software (Hunziker & Rihs, 2007). Vom Sicherheitsstandpunkt aus betrachtet, liefern Open Source Systeme also die beste Basis für den Betrieb medizinischer Applikationen.
Die Problematik der speziellen Ergonomie bei Software im Gesundheitsbereich (siehe Kapitel 3.1.3) kann bei Open Source Systemen durch die hohe Anpassbarkeit entschärft werden (Erber, 2008). Die quelloffenen Systeme können so an die individuellen Anforderungen der einzelnen Benutzer verschiedener Berufsgruppen innerhalb des Gesundheitswesens genau angepasst werden. Anders als bei proprietärer Software sind Veränderungen (siehe Kapitel 2.2.3) hier ja ausdrücklich gestattet. Die entstandenen Derivate der Software würden dann wiederum anderen Gesundheitseinrichtungen zur Verfügung stehen. Dies führt dann unwillkürlich zu einer steten Verbesserung der Ergonomie für die einzelnen Anwender.
[...]
1 Im Gegensatz zu den Kathedral-Architekten bei Proprietärer Software
2 Der Entwicklungsprozess von OSS unterliegt keinen Marktzwängen oder Veröffentlichungsterminen
