gms | German Medical Science

Vor 50 Jahren, Ende der 1960er, Anfang der 1970er Jahre, führte in der Anwendung der Datenverarbeitung in der Medizin unsere Bundesrepublik zusammen mit den USA¹ und Schweden². Deutschland war „second to none“; kein anderes Land war besser. Vor allem bei elektronischer Patientenakte und Dokumentation waren wir mit ganz vorne. Das lag unter anderem an reichlich fließenden Forschungsgeldern des Bundesministerium für Forschung und Technologie (BMFT).

Heutzutage rangiert Deutschland in der Praxis der Medizinischen Informatik (MI) unter „ferner liefen“, ziemlich weit hinten. Das Digitalisierungsdefizit auch im Gesundheitswesen wird allgemein beklagt. Woher rührt dieser Verlust der führenden Rolle?

Einem alt gewordenen Pionier der Datenverarbeitung in der Medizin sei es erlaubt, etwa zwanzig Jahre nach der Emeritierung (2003) darüber nachzudenken, was er für die Ursachen hält!

Dieser Rückblick soll verpasste Chancen anhand persönlicher Erinnerungen aufdecken: traurig, aber nicht zornig, erinnernd, aber nicht klagend, pointiert, aber nicht akademisch.

Meine eigene Biografie steht nicht zur Diskussion; sie ist im Web dokumentiert (siehe https://www.wgiere.de). Auch meine berufliche Entwicklung lässt sich nachlesen (siehe https://www.baik.de). Diese Gedanken sollen Zusammenhänge mit Hintergrundwissen erhellen, einige Aspekte der offiziellen Geschichtsschreibung der Medizinischen Informatik ergänzen – ohne erhobenen Zeigefinger. Bewusst wage ich mich für diese Aufgabe auch an Spekulationen, an Was-wäre-wenn-Fragen.

Es geht also um den Versuch, Ursachen für den Verlust der Führung bei der Anwendung der Datenverarbeitung in der Medizin zu identifizieren und verpasste Chancen aus der Rück-Sicht zu beschreiben. Weil meine persönlichen Erinnerungen den Überlegungen zugrunde liegen, geht es auch um meine Fehler – aber nicht nur. Vor allem geht es um die Idiosynkrasien verschiedener Firmen, Institutionen und handelnder Personen. Klar ist somit: Es geht um meine persönlichen Ansichten, die Ansichten eines Pioniers an vorderster Front, der das alles miterlebt und teils schmerzlich miterlitten hat.

Wie gesagt: Dieses soll keine wissenschaftliche Arbeit werden, auch keine Geschichte der Medizinischen Informatik. Ich erzähle, was ich erinnere – und das ist natürlich im 87. Lebensjahr eingeschränkt. Literatur ziehe ich möglichst nicht heran. Zu den frühen angegebenen Projekten findet sich Information in dem großartigen Handbuch der medizinischen Dokumentation und Datenverarbeitung, herausgegeben 1975 von Siegfried Koller und Gustav Wagner. Meine subjektiven Beurteilungen sollen zum Nachdenken anregen und zum Nachfragen. Wenn sich aus diesem gebündelten Rückblick, aus meinem persönlichen Fazit, eine Diskussion ergeben sollte, wenn es begründeten Widerspruch gäbe, würde mich das freuen³.

Die Bundesregierung, konkret das BMFT, förderte die Datenverarbeitung seit Ende der 1960er Jahre großzügig. Verständlicherweise sollten deutsche Produkte bevorzugt werden. So kam es z.B. zur Ausstattung von Hochschulrechenzentren mit AEG-Telefunken-Rechnern. Die TR440⁴ des Förderkreises Industrie- und Technikgeschichte (FITG, https://www.fitg.de) stammt aus diesem Programm. Für das mir genehmigte Vorhaben DIPAS (DV 5.314) wurden Fernschreiber Siemens T200 für die zwölf angeschlossenen Praxen niedergelassener Ärzte und eine Siemens 4004/45 als Zentralrechner genehmigt. Dieser erste Einsatz von Datenverarbeitung in ärztlichen Praxen war erfolgreich. Beim nächsten Förderprogramm wurde eine eigenständige Förderung der Medizin vorgesehen und dazu, wohl 1972, ein Beirat berufen.

Den Vorsitz des Sachverständigenkreises Datenverarbeitung in der Medizin (SVK DVmed) hatte Berthold Schneider von der Medizinischen Hochschule Hannover (MHH), ein Biometriker. Stellvertretender Vorsitzender war ich, ein Arzt, damals Leiter des Rechenzentrums der Deutschen Klinik für Diagnostik (DKD) in Wiesbaden. Der SVK DVmed wurde hervorragend betreut vom Ministerialrat Dr. Bertuleit. Er hat viele erfolgreiche Projekte gefördert. Aber bei einigen kleineren frühen Vorhaben lassen sich schon verpasste Chancen feststellen (Dietz, Philips), gravierende bei den späteren Großvorhaben DOMINIG und DEPAK (Dokumentations-DV-Projekt für das Allgemeine Krankenhaus).

Der Sachverständigenkreis hatte als Grundlage für ein vereinheitlichtes Berichtswesen über die Projektfortschritte die „Dokumentations- und Verfahrensrichtlinien für medizinische DV-Projekte“ von R. Werner Schuster und mir erstellen lassen. Deren Einhaltung wurde zur Bedingung jeglicher Förderung. Von den Betroffenen wurden die detaillierten Vorschriften nicht geliebt, als „DoVmed“ (Doofmed) verächtlich gemacht, aber im Großen und Ganzen eingehalten. Die damals entstandenen Papiere sind großenteils durchaus auch heute noch lesenswert.

Peter Dietz baute in Mülheim an der Ruhr erfolgreich Prozessrechner⁵ für die Großindustrie. Er hatte Kontakt zum Krankenhaus Bethanien in Moers und war begeistert von den neuen Großplatten mit 80 MB (!) Kapazität, die Anfang der 1970er Jahre von Control Data auf den Markt gekommen waren. Und zusammen mit einem kreativen Oberarzt im Bethanien entwickelte er eine Idee, eine brillante, wie ich meine. Ziel: Der Arzt am Krankenbett hat alle Information zum Patienten übersichtlich auf dem Fernseherbildschirm, wenn er den Patienten besucht. Alle eingehenden Befunde werden eingegeben; die unterschiedlichen Ansichtsseiten der benötigten Auskunftsbildschirme werden während der Eingabe aufbereitet. Da es genügend Plattenkapazität gibt, werden die benötigten Bilder fix und fertig abgelegt. Damit ist gewährleistet, dass der Arzt sie auf Anforderung verzögerungsfrei, blitzschnell, erhält. Dietz argumentierte: Der Arzt kann und will nicht warten, aber bei der Eingabe hat der Rechner genügend Zeit, die gewünschte multiple Aufbereitung vorzunehmen. Die fertigen Bilder vom Rechner auf die Fernseher in den Krankenzimmern zu pusten, ist kein Problem. So hatte er sich das gedacht, und ich fand die Idee unterstützenswert.

Leider kam es anders. Vom Geldsegen des BMFT stellte Peter Dietz einen jungen Informatiker ein, frisch aus Hamburg, wo, wenn ich mich recht erinnere, von Wilfried Brauer damals über das neue Thema Datenbanken gelehrt wurde. Der Junginformatiker überzeugte Dietz, er müsse eine moderne und redundanzfreie Datenbank benutzen. Dafür gab es aber bei Dietz keinerlei Software. Außerdem reichte die Kapazität des Rechners nicht. Also müsse man einen zweiten hinzunehmen, einen Datenbankrechner. Und schließlich landete man mit einem weiteren zur Unterstützung der Kommunikation bei einem hochkomplexen Verbund aus drei Mini-Rechnern. Und das Team scheiterte kläglich, bekam die Probleme nicht in den Griff.

Damals war ich im „Vorhabenbegleitenden Ausschuss“ und veranlasste einen Trockentest ohne das Computernetzwerk. Das ursprüngliche Konzept von Peter Dietz, einfach und bestechend, wurde im Patientenzimmer erprobt. Dafür mussten die Daten von Heinzelmännchen im Keller händisch aufbereitet werden. Die Ärzte waren begeistert. Aber die an sich simple EDV-Lösung hat es nie gegeben.

In meinen Augen war das eine verpasste Chance. Hätte man den Benutzeranspruch des Arztes (schnelle Reaktionszeit) wichtiger genommen als das Dogma der Informatik (Redundanzfreiheit), wäre es meiner Meinung nach ein großer Erfolg geworden und vermutlich gäbe es das System in modernisierter Form heute noch: häufige Zusammenstellungen auf Knopfdruck blitzschnell abrufbar, seltenere Ad-hoc-Anfragen per Datenbank möglich, aber eventuell langsamer.

Merke: Es geht um die Zufriedenheit der Benutzer, verzögerungsfreie Auskunft für den Arzt, einheitlich, sodass er sich an das Bild gewöhnt und ganz einfach die gewünschte Information findet. Es geht um Praxis, nicht um die reine Lehre!

Im Kreiskrankenhaus Herford hatte die Firma Philips Röntgenmüller aus Hamburg ein komplettes Leistungsanforderungs- und Berichtssystem aufgebaut mit Fernschreiber-Terminals zwischen je zwei Stationen. Dazu hatten sie DEC-PDP-Rechner benutzt, programmiert in Mumps. Das war damals noch nicht standardisiert, kannte noch kein String-subscript (das hat die Hamburger Truppe, angeführt von Armin Freybott, einige Jahre später erfunden für ihren eigenen Rechner P800, den wir in Frankfurt a.M. benutzten). Es gab auch noch keine B*-Bäume zur Speicherorganisation⁶.

Der Sachverständigenkreis war nach einer Besichtigung des funktionierenden Systems beeindruckt. Aber leider wurde das System nicht weiterentwickelt. Die genauen Zusammenhänge weiß ich nicht mehr. Möglicherweise spielte eine Rolle, dass die Mumps-Rechner damals DEC-Rechner aus den USA waren. Die von Philips selbst entwickelten Minirechner mit eigenem Mumps standen damals noch nicht zur Verfügung. Vielleicht gab es auch schon damals irrationale Vorbehalte gegen Mumps, wie später noch oft. Jedenfalls starb das System und in meinen Augen starb damit das erste voll funktionierende Leistungsstellenkommunikationssystem in Deutschland – Anfang der siebziger Jahre, nota bene! Das System leitete die Befund-Dokumentation aus der Leistungsanforderung und Befundübermittlung ab, bewahrte also die Ärzte vor Mehrarbeit. Im Vordergrund stand die Praxis der Krankenhauskooperation. Dieses erfolgreiche System weiterzuentwickeln, wurde versäumt. Es war eine verpasste Chance.

Anfang der siebziger Jahre beantragte ich beim BMFT Förderung für das Vorhaben „Dokumentations- und Informationsverbesserung in der Praxis des Niedergelassenen Arztes durch EDV-Service (DIPAS)“. Zwölf Modellpraxen in ganz Deutschland sollten durch Datex-Anschluss an einen Zentralrechner in der Deutschen Klinik für Diagnostik vom DUSP/DUTAP-Verfahren profitieren. Der Antrag wurde noch im ersten DV-Förderprogramm genehmigt (DV 5.314). Die Fortsetzung wurde im DVmed-Programm beantragt.

Gleichzeitig hatte Otfried P. Schaefer in Kassel Förderung für die Konzeption eines „Informationssystems für den Niedergelassenen Arzt (INA)“ beantragt. Der Antragsteller war einflussreicher Standespolitiker, damals Vorsitzender des Marburger Bundes und der Kassenärztlichen Vereinigung Hessen.

Beide Vorhaben wurden vom Sachverständigenkreis DVmed empfohlen, vom BMFT genehmigt, aber aus verwaltungstechnischen Gründen zu einem Gesamtvorhaben unter meiner Gesamtleitung zusammengefasst: „Einführung der Datenverarbeitung in die Ärztliche Praxis (EDAP)“. EDAP bestand also aus den beiden Teilprojekten DIPAS und INA; Träger war die Gesellschaft zur Förderung der Forschung an der Deutschen Klinik für Diagnostik (GFF) in Wiesbaden. Beide Vorhaben waren erfolgreich. INA wurde vom Software-Unternehmen MCS in Eltville auf den Markt gebracht. DIPAS sollte seine Fortsetzung im geplanten Großvorhaben DOMINIG finden.

„DV-Einsatz zur Lösung überbetrieblicher Organisations- und Managementaufgaben durch Integration des Normierten Informationsflusses zwischen verschiedenen Einrichtungen des Gesundheitswesens (DOMINIG)“ hieß das mit reichlichen Fördermitteln ausgestattete Großvorhaben des Bundes, vertreten durch das BMFT, das helfen sollte, die Grenzen, besser gesagt die Kluft, zwischen den drei Säulen des deutschen Gesundheitswesens (Gesundheitsämter, Krankenhäuser, Niedergelassene Ärzte) zu überwinden. Wie kam es dazu?

Vom Sachverständigenkreis Datenverarbeitung in der Medizin waren erfolgreiche Projekte kleineren Umfanges gefördert worden. Nunmehr sollte ein großes Projekt alle Aktivitäten bündeln und positive Wirkung im Gesundheitswesen entfalten. Berthold Schneider, der Vorsitzende, ich als Vize und R. Werner Schuster als Gesundheitspolitiker wurden gebeten, ein Konzept zu entwickeln. Für mehrere Tage begaben wir uns in Klausur im Hotel-Restaurant Erbismühle im Weiltal. Dabei entstand das oben zitierte Konzept. Wenn ich mich richtig erinnere, passierte es den Sachverständigenkreis unverändert, wurde reichlich finanziert und ausgeschrieben.

Mehrere Teams bewarben sich:

• Für DOMINIG I, „Regionales medizinisches Organisations- und Planungssystem für überbetriebliche Aufgaben“, kurz: das öffentliche Gesundheitswesen, war eine Berliner Bewerbung erfolgreich.
• Für DOMINIG II, „Informationsverbund mehrerer Krankenhäuser unter Benutzung eines zentralisierten DV-Systems“, kurz: den Krankenhausbereich, hatte ich vorbereitend ein Treffen zwischen Schuster von der Hessischen Zentrale für Datenverarbeitung (HZD) und Kampe von der Kirchlichen Gemeinschaftsstelle für elektronische Datenverarbeitung (KiGSt) auf neutralem Grund in einer Raststätte an der A3 bei Hanau organisiert. Die beiden einigten sich tatsächlich auf eine gemeinsame Bewerbung für DOMINIG II. Die war erwartungsgemäß erfolgreich.
• Für DOMINIG III, „Informationsverbund für niedergelassene Ärzte und sonstige an der ambulanten Versorgung beteiligte Einrichtungen unter Benutzung eines zentralisierten DV-Systems“, kurz: den ambulanten Bereich, hatten die Kassenärztliche Bundesvereinigung (KBV) gemeinsam mit der DKD mit meinem erfolgreichen DIPAS-Projekt die besten Chancen. Der Vorsitzende der KBV, Hans Wolf Muschallik, bat mich, den Antrag als Fortsetzung von DIPAS für das zu gründende „Zentralinstitut für die kassenärztliche Versorgung in der Bundesrepublik Deutschland (ZI)“ im größeren Rahmen zu formulieren. Ich entwickelte dafür das Konzept „Arzt-Kommunikations- und Auskunfts-System (AKAS)“. Die Bewerbung war erfolgreich.

Den erfolgreichen Bewerbungen folgten leider keine erfolgreichen Durchführungen. Im Ergebnis konnte von einer „Lösung überbetrieblicher Organisations- und Managementaufgaben durch Integration des Normierten Informationsflusses im Gesundheitswesen“ nicht die Rede sein. Verpasste Chancen in allen drei Teilbereichen.

Soweit ich das sehen kann (und ich habe die Berliner Entwicklungen weniger genau verfolgt als die beiden anderen Teilprojekte), war der einzig greifbare Erfolg von DOMINIG I eine Stärkung der Firma ID von Fritz Diekmann und seiner Bemühungen um Dokumentation und Nomenklatur. Auch die enge Kooperation des Gründers von ID mit dem Bundesministerium für Gesundheit (BMG) ist wohl der Zusammenarbeit im Projekt DOMINIG I zu verdanken. Substantielles ist meines Wissens nicht von DOMINIG I übrig geblieben.

Das umfangreiche Gemeinschaftsprojekt lief mit großem Aufwand an. Die entstandenen Konzepte sind meines Erachtens noch heute lesenswert. Aber den Worten folgten jahrelang keine Taten, weil man sich bei der Schaffung eines eigenen Betriebssystems für die Klinik-Software verzettelte. Ich habe damals in einem ausführlichen Schreiben das zuständige Sozialministerium gewarnt und empfohlen, bewährte Software aus den USA zu übernehmen, z.B. die Datenbank- und Programmierumgebung „File-Manager“ und das Betriebssystem „Kernel“ von der Veterans Administration mit ihren 172 Krankenhäusern. Das hätte damals noch gelingen können. Dieser Brandbrief hätte mich fast die Freundschaft von R. Werner Schuster gekostet, der unbedingt das eigene Betriebssystem in Fortran entwickeln wollte. Leider hat der schmerzliche Abbruch des Vorhabens nach ergebnislosen Jahren mir Recht gegeben. Die Chance, in Kooperation mit den Ärzten (wie es die Veterans Administration damals erfolgreich vorgemacht hat) mit „rapid prototyping“ Bahnbrechendes im Krankenhausbereich zu entwickeln, wurde verpasst. Schuld waren aus meiner heutigen Sicht unbegründete Vorbehalte gegen Mumps und das NIH-Syndrom („Not Invented Here“), die verbreitete Scheu vor der Übernahme von Ergebnissen anderer. Eine transatlantische Kooperation der Veterans Administration mit DOMINIG II wäre grandios gewesen.

Die von mir im Auftrage der KBV verfasste Bewerbung „Arzt-Kommunikations- und Auskunftssystem (AKAS)“ basierte auf der Idee einer Weiterentwicklung der bewährten Technik von DIPAS und war erfolgreich. Aber…

Mit der Projektdurchführung sollte neben der DKD als Partner das neu zu gründende „Zentralinstitut für die kassenärztliche Versorgung in der Bundesrepublik Deutschland (ZI)“ betraut werden. Der KBV-Vorsitzende Hans Wolf Muschallik bat mich, die Leitung des zu gründenden ZI zu übernehmen. Das habe ich jedoch schweren Herzens abgelehnt, weil es einen erneuten Umzug bedeutet hätte, nach Tübingen, Duisburg, Stuttgart und Taunusstein dieses Mal nach Köln, und damit Schulwechsel für alle vier Kinder. Gründungsvorsitzender wurde nach meiner Ablehnung Friedrich Wilhelm Schwartz. Und der hatte für das ZI andere Ziele, lehnte eine Fortsetzung von DIPAS ab.⁷ Weil meine DIPAS-Mitarbeiter somit nicht wie geplant, beantragt und vom BMFT genehmigt in DOMINIG III übernommen wurden, war ich gezwungen, eine andere Fortsetzung zu beantragen. Einzelheiten hierzu finden sich in meiner ausführlichen Darlegung „DIPAS-Abschlussbericht=DIADEM-Ausgangsbasis“ (zu finden im Web unter https://www.baik.de/akas). Diesen Antrag „Dokumentations- und Informationsverbesserung für den Arzt mit Dezentralem EDV-Modul (DIADEM)“ schickte ich zusammen mit meiner Dokumentation des Hinauswurfs aus DOMINIG III durch Friedrich Wilhelm Schwartz gleichzeitig an das ZI, das BMFT und die Mitglieder des SVK⁸. DIADEM wurde genehmigt – zusätzlich zu DOMINIG III (entgegen den ursprünglichen Intentionen des BMFT).

Es ist ein Treppenwitz der Geschichte der Medizinischen Informatik: DOMINIG II ist an Fortran gescheitert, hätte vermutlich mit Mumps überlebt; DIADEM hat Mumps beantragt, musste aber in Fortran realisieren; DOMINIG III wurde von Friedrich Wilhelm Schwartz ohne den medizinischen Anteil von AKAS zu einem erfolgreichen Verwaltungs- und Abrechnungssystem gemacht – in Mumps. Das System wurde unter strengen Bedingungen kommerziellen Firmen zur Übernahme angeboten und hat viele Praxissysteme befruchtet.

Die medizinischen Teile von AKAS mit Dokumentation, Informationsunterstützung und Kommunikation, Basis für den von DOMINIG erwünschten „normierten Informationsfluss im Gesundheitswesen“, wurden ausgespart, Millionen an dafür bewilligten Fördermitteln zurückgegeben. AKAS hätte verwirklicht werden können. Das haben wir in den Folgejahren bewiesen. Damit hätte es schon damals das gegeben, was man heutzutage eine „aktive Elektronische Patientenakte“ nennt, eine, die dem Arzt mehr Information liefert, als er hineinsteckt. Das Modell für die aktive Elektronische Patientenakte, das spätere BAIK-Modell, wurde von mir für AKAS entwickelt. Verpasste Chance!

Fazit: DOMINIG war gescheitert. Die Chance, etwas wirklich Bahnbrechendes zu entwickeln, die es aus heutiger Sicht durchaus gegeben hätte, war vertan. Es kreißte der Berg und gebar eine Maus: Lediglich das unter Leitung von E. Geiss in Mumps entwickelte Praxisverwaltungs- und Abrechnungssystem des ZI in DOMINIG III überlebte.

„Dokumentations- und Informationsverbesserung für den Arzt mit Dezentralem EDV-Modul (DIADEM)“ hatte ich das neue Vorhaben in Anlehnung an das so erfolgreiche DIPAS getauft. Um dem ZI mit DOMINIG III nicht ins Gehege zu kommen, hatte ich mich auf das Berichtswesen in Krankenhäusern konzentriert. Als „dezentrale EDV-Module“ wurden beschafft Siemens 404-3, Dietz Mincal 621 und kleine Prozessrechner von Intertechnique. Auflage des BMFT war, das DUSP/DUTAP-System in Fortran (nicht, wie beantragt, in Mumps) zu realisieren. Das Programmieren von Textgenerierung und Stringverarbeitung in Fortran war eine Herausforderung besonderer Güte. Allerdings hatte ich darin schon viel Erfahrung als Assistent von Rudolf Pirtkien in Stuttgart sammeln können. Dort hatte ich 1969 (mit einer guten Assistentin) sein Vergiftungsauskunftssystem MEDIUC (in Fortran IV) völlig neu programmiert auf dem Boden einer veritablen Datenbank mit beliebig langen Texten. Auf dem winzigen Siemens 404-3 (maximaler Kernspeicherausbau 48 kB!), dem letzten von Zuse selbst entworfenen Rechner Z43, lief das System. Es wurde von Triumph-Adler (TA) auf einem eigenen Personal Computer als „Doctors Office Computer (DOC)“ auf den Markt gebracht. Leider starb DOC vor den ersten Verkäufen, weil TA Insolvenz anmeldete und aufgelöst wurde. Über die Inkompatibilitäten der verschiedenen Fortran-Installationen, die „Fortabilität“, haben wir damals publiziert. Um das ZI nicht zu reizen, haben wir im Sammelband über die vom BMFT geförderten Projekte „Datenverarbeitung im Gesundheitswesen“ nur über die formale Backus-Naur-Definition (Backus-Naur-Form) der DUSP/DUTAP-Systematik publiziert, was damals für Ärger sorgte. Aber wir wollten uns bewusst bedeckt halten.

Das Scheitern des Großprojektes DOMINIG, von dem man sich so viel versprochen hatte, war ein Schock. Es hat die Förderlandschaft nachhaltig geschädigt. Umso aufmerksamer beobachtete man das spätere „Demonstrations-DV-Projekt für das Allgemeine Krankenhaus (DEPAK)“ in Kulmbach unter der Leitung von Eckehard Wilde. Der Landrat wollte für sein Krankenhaus eigentlich eine IBM-Lösung, bekam jedoch gemäß den Förderrichtlinien eine etwa gleichwertige Siemens 4004/45-Anlage (die gleiche, die wir für DIPAS benutzten). Wohl deswegen wurde ich Vorsitzender des „Vorhaben-begleitenden Ausschusses“ und war somit eng vertraut mit dem Projekt. Es war ausgesprochen erfolgreich, verwirklichte echte Leistungsstellenkommunikation und konnte mit Fug und Recht als bestens eingeführtes „Krankenhaus-Informations-System (KIS)“ angesehen werden.

Allerdings änderte der federführende Siemens-Unternehmensbereich Medizin (UBmed) in Erlangen zwischenzeitlich seine Strategie und ließ die DV-Unterstützung der Medizin auf der Universalrechnerlinie 4004 zugunsten des Minirechners 404-3 (den wir auch in DIADEM aufs Auge gedrückt bekommen hatten) fallen. Das führte in Kulmbach einerseits dazu, dass sich die DEPAK-Mannschaft selbständig machte (Eckehard Wilde ging nach Augsburg), andererseits übernahm – man glaubt es kaum – IBM die Software und das funktionierende System im Kreiskrankenhaus Kulmbach. Mit anderen Worten: Siemens überließ das geballte Wissen aus dem Förderprogramm und ein gut funktionierendes KIS der Konkurrenz (von den 4004-Anwendungen in der DKD ganz zu schweigen). Es wurde nicht versucht, das System auf Nachfolgerechner der 4004 zu übertragen. Verpasste Chance!

Schon früh haben sich die Rechenzentren der Länder zusammengetan, um gemeinsam Programme für die Krankenhäuser zu entwickeln und sie so bei der Verwaltung zu unterstützen.

„Finanzbuchhaltung im Krankenhaus (FINK)“, „Kosten- und Leistungsrechnung im Krankenhaus (KOLK)“, „Maschinelle Anlagenbuchhaltung im Krankenhaus (MAIK)“ und „Materialwirtschaft im Krankenhaus (MARK)“ waren vielbenutzte Programmsysteme, die in den Gebietsrechenzentren entwickelt, gepflegt und für die angeschlossenen Krankenhäuser als Dienstleistung in Routine durchgeführt wurden (z.B. auch für das Uni-Klinikum Frankfurt a.M.). Im Rahmen von Bund-Länder-Abkommen hatte das Landesrechenzentrum von Rheinland-Pfalz in Bad Ems die Federführung. Der Vorteil der Bund-Länder-Programme war die bundeseinheitliche Regelung. Nachteilig war die Schwerfälligkeit des Entwicklungsprozesses.

Hinzu kam nach meinem Wechsel nach Frankfurt a.M. das in DIADEM weiterentwickelte Dokumentationssystem „Befunddokumentation und Arztbriefschreibung im Krankenhaus (BAIK)“ als Bund-Länder-Programm für die medizinische Dokumentation, ein Fremdkörper in mehrerlei Hinsicht:

• Nicht verwaltungs-, sondern arztorientiert
• Dezentraler Einsatz von Datenverarbeitung für das DOC-System
• Eigene Programmiersprache DUTAP für die Berichtsgenerierung
• Gesamtsystem BAIK programmiert in Mumps (nicht in Cobol, wie die übrigen Bund-Länder-Programme)⁹
• Nicht nur die „Zentrale Verfahrenspflege“, sondern auch die Betreuung der einzelnen Benutzer lag in den Händen des Zentrums der Medizinischen Informatik am Klinikum der J. W. Goethe-Universität, Frankfurt a.M. (ZInfo).

BAIK starb mit dem ZInfo, das mit meiner Emeritierung aufgelöst wurde. (Erst ab dem Jahre 2019 gab es wieder Initiativen der Medizinischen Informatik im Klinikum der J. W. Goethe-Universität.)

Natürlich habe ich darüber nachgedacht, was wohl die Gründe für den Untergang von BAIK waren. Wie so oft ist dafür nicht ein einziger Grund auszumachen; es ist wohl ein multifaktorielles Geschehen:

• Aufwand: Die BAIK-Einführung war personell aufwändig. Zwar erlaubte die präzise „BAIK-Einführungsstrategie“ eine gute Abschätzung des Aufwandes für die aufeinander folgenden Schritte, aber die initiale Hürde blieb hoch. (War sie überwunden, ernteten die Nutzer gerne die BAIK-Vorteile.)
• Fehlende Mittel: Die Beiträge aus der Bund-Länder-Vereinbarung waren sehr knapp, deckten kaum den Unterhalt, reichten nicht für Weiterentwicklungen. Die erfolgten zwar stetig, aber entsprechend langsam, im Wesentlichen durch Doktoranden. Erst mit der großzügigen Förderung des transatlantischen Projektes „Multilingual Concept Hierarchies for Medical Information, Organisation and Retrieval (MuCHMORe)“ gab es genügend Mittel zur Weiterentwicklung. Immerhin ist es gelungen, bis zu meiner Emeritierung alle Teile meines Modells der „aktiven Elektronischen Patientenakte“ zu verwirklichen. Die Machbarkeit konnte also bewiesen werden, wenn auch z.T. nur prototypisch. (Heute hätte sowieso niemand mehr Zweifel an der Machbarkeit!)
• Mangelhafte Kommerzialisierung: Heute ist mir klar: Wir hätten für BAIK dieselbe Strategie anwenden müssen wie das ZI, nämlich strikte Trennung von Entwicklung und Vertrieb. Verkauf und Einführung in der Praxis hätte erfahrenen Firmen überlassen werden müssen, nicht den Länderministerien. Das ZI hat die Verwendung der von ihm entwickelten DOMINIG-III-Software gratis ermöglicht, aber unter Einhaltung strikter Kautelen strikt zertifiziert und kontrolliert. Dasselbe hätte man bei BAIK auch anstreben müssen statt des „Vertriebs“ über Behörden. Die BAIK-Benutzung wurde den Krankenhäusern mehr oder weniger „auf’s Auge gedrückt“. Sie mussten zwar nicht bezahlen, hatten dadurch aber auch wenig Interesse.
• Unzureichende Wartungskapazitäten: Aus der mangelhaften Kommerzialisierung folgerte nicht nur mangelhafter Vertrieb, sondern auch unzureichende Wartung. Es ist nicht genuine Aufgabe eines Universitätsinstitutes, einzelne Installationen zu warten. Das wäre besser Aufgabe der Industrie gewesen. Hätten sich Firmen wie ID oder DMI darum gekümmert, würde BAIK wegen seiner unstreitig überlegenen Qualitäten vermutlich noch leben. Verpasste Chance!

Und damit sind wir bei den schmerzlichen Überlegungen „Was wäre, wenn“ und landen bei Spekulationen.

In diesem Abschnitt versuche ich, mir vorzustellen, wie es hätte weitergehen können, wenn verschiedene Chancen nicht verpasst worden wären. Und bei der kritischen Rückschau haben sich verschiedene Überzeugungen herausgebildet. Es lässt sich nicht beweisen, dass sie richtig sind, aber ich denke, sie sind plausibel.

Wenn DOMINIG ein Erfolg geworden wäre – und nach meiner festen Überzeugung wäre das möglich gewesen – hätte die Medizinische Informatik in Deutschland einen massiven Aufschwung genommen. Die Digitalisierung des Gesundheitswesens würde heute nicht hinter den meisten anderen Nationen hinterherhinken, sondern wäre beispielhaft und maßgebend.

Hätte sich R. Werner Schuster mit der HZD für Mumps statt Fortran entschieden (die KiGSt benutzte es sowieso), File-Manager und Kernel der Veterans Administration übernommen und sich auf die Anwendungsentwicklung und Erleichterung des Krankenhaus-Alltags konzentriert, wäre ein Erfolg nicht nur möglich, sondern sehr wahrscheinlich gewesen. Mit dem File-Manager hätte ein hervorragendes und bewährtes Instrument zum „rapid prototyping“ zur Verfügung gestanden und mit dem Kernel ein ausgebufftes Betriebssystem. Mumps hat seine Leistungsfähigkeit weltweit bewiesen und ist streng genormt (viel besser portabel als Fortran noch heute).

Hätte das ZI für DOMINIG III auch den medizinischen Teil des AKAS in Mumps realisiert wie beantragt und das in Absprache und Kooperation mit DOMINIG II, hätte das ziemlich sicher zu einem „normierten Informationsfluss im Gesundheitswesen“ geführt, zu dem, was wir immer noch schmerzlich vermissen!

Und wenn der Informationsfluss zwischen Krankenhaus und Praxis integriert worden wäre, hätte man sicher auch das öffentliche Gesundheitswesen mit einbeziehen können und auch DOMINIG I wäre erfolgreich geworden.

Schließlich: Wenn die in DIPAS bewährte DUSP/DUTAP-Systematik in allen drei Teilprojekten eingeführt worden wäre, hätte es kein Problem mit dem Informationsaustausch gegeben. Der vorhandene AGK-Thesaurus wäre nicht nur eine der Quellen für den heutzutage erfolgreichen ICD-10-Diagnosenthesaurus geworden, sondern schon in den siebziger Jahren eine für ein „integriertes Gesundheitswesen“.

Akzeptiert man diese Überlegungen, gibt es noch eine weitere Ursache für viele verpasste Chancen: Wäre ich damals der Bitte von Hans Wolf Muschallik gefolgt und hätte das ZI gegründet und geleitet, damit auch DOMINIG III, wäre es nicht zum Zerwürfnis von Friedrich Wilhelm Schwartz und mir gekommen, nicht zur Ablehnung meiner bewährten Methodik. Vermutlich wäre sie heute noch im gesamten Gesundheitswesen lebendig. Als Leiter des ZI hätte ich andere Chancen gehabt, vielleicht mehr bewirken können.

In der Krise der DKD verhandelte ein Drei-Männer-Gremium mit potenziellen Investoren. Als Prokurist der AG gehörte ich dazu. Damals gab es vonseiten der Kassen das Angebot, aus der DKD eine Qualitätssicherungsinstitution zu machen. Das wäre eine Chance gewesen. Sie wurde leider von den Kollegen abgelehnt. Hätte man mit etwas Weitblick weiter verhandelt, hätte die DKD damals schon die Rolle übernehmen können, die heute das IQWIG innehat. Und wäre ich Chef des ZI geworden, hätte es sicher keine Trennung von der DKD gegeben.

Versucht habe ich, aus meiner Erinnerung heraus verpasste Chancen aus der Pionierzeit zu identifizieren, die meiner Meinung nach die Entwicklung der Medizinischen Informatik in Deutschland beeinflusst haben, leider negativ. Sogar eigene Entscheidungen könnten wesentlich dazu beigetragen haben.

Was von mir bleibt, sind ausgerechnet Produkte, die ich für weniger wichtig halte: Der ICD-10-Diagnosenthesaurus und, schlimm genug, der Operationenschlüssel (OPS)¹⁰.

Für wichtig halte ich das BAIK-Modell mit dem Konzept der aktiven elektronischen Patientenakte mit allen Bausteinen: doppelte Sequenzbildung zur Identifikation (DUSP), Natural Language Generation (NLG, DUTAP), Klassifikation (IATROS) und Berücksichtigung des Arzt-Interessen-Profils bei der Informationsanreicherung (MedIAS). Besonders gefreut hat mich, das BAIK-Modell auf den Titelseiten der beiden gleichlautenden Anträge des transatlantischen Gemeinschaftsprojektes MuCHMORe an die NSF und die EU zu sehen.

Darüber gibt meine BAIK-Webseite (https://www.baik.de) mit dem BAIK-Buch Auskunft. Aber ich gebe mich keinen Illusionen hin: Wer studiert schon, was Altvordere gedacht, gemacht und darüber geschrieben haben! Trotzdem: Ich würde mich freuen, wenn diese Ausführungen eine Diskussion anstießen.

¹ Zum Beispiel Morris Collen mit EDV-gestütztem Automatic Multiphasic Health Testing (AMHT) (Kaiser Permanente) und Octo Barnett mit Computer Stored Ambulatory Record (COSTAR) (MGH).

² Zum Beispiel Paul Hall mit der EDV-basierten Patientenakte J5 (Karolinska Sjukhuset).

³ Leider spricht die Erfahrung dagegen. Ich kenne praktisch keine Diskussion gemachter Erfahrungen. Viele Appelle, auch meine im BAIK-Buch, sind ungehört verhallt. Vielmehr wird – leider – immer wieder von vorne angefangen, als ob es nicht auch früher schon gute Gedanken gegeben hätte.

⁴ Die TR440 stammt aus dem Hochschulrechenzentrum Kassel. Ich hatte mal ein Gutachten erstellt, ob sich eine unglaublich teure Arbeitsspeichererweiterung noch lohne, und habe mit dem FITG die Anlage vor dem Verschrotten gerettet. Sie diente 2008 im Film Der Baader Meinhof Komplex als Kulisse für den Leiter des Bundeskriminalamtes, Horst Herold (gespielt von Bruno Ganz), bei der Erfindung der „Rasterfahndung“.

⁵ Dietz Mincal 621: Zuverlässiger Minirechner mit sehr eigenwilliger Architektur. Der Arbeitsspeicher war nicht in Worte fester Wortlänge eingeteilt, sondern mit variablen Wortlängen organisiert. Wir benutzten später diese Rechner im Klinikum z.B. als sogenannte Remote Job Entry (RJE) Station für die Kommunikation mit dem Hochschulrechenzentrum, aber auch schon im Vorhaben DIADEM (siehe 3.5).

⁶ Philips hat für die P800 das so wichtige String-subscript für Mumps verwirklicht mit einer Art ISAM-Datenspeicherung mit alphabetisch adressierten Ketten für jede Hierarchiestufe. Die B*-Baum-Organisation der Datenspeicherung wurde später erstmals von DEC realisiert und machte Mumps unschlagbar für alphabetisch adressierte sparse arrays, non-sql-Datenbanken. Zu Mumps siehe https://de.wikipedia.org/wiki/Mumps.

⁷ Er verbündete sich mit dem neuen ärztlichen Direktor der DKD, Friedrich Schröpl. Auf dessen Initiative untersagte mir die GFF, im Namen der DKD Fortsetzungsanträge beim BMFT zu stellen. Ich musste dafür einen neuen Träger suchen und fand ihn bei den Städtischen Kliniken Wiesbaden, den Dr. Horst Schmidt Kliniken (HSK).

⁸ Es war klar, dass Friedrich Wilhelm Schwartz DIPAS nicht als Erfolg sehen wollte, aber ich musste mich verteidigen. Als der Leiter des ZI verlangte, meine Darstellung zurückzurufen, bot ich an, den Sachverständigen zu schreiben, er hätte von mir den Rückruf verlangt. Der Rückruf unterblieb.

⁹ Eine Ausnahme bildete der zentrale Auswertungsteil IATROS, der einerseits im Mumps, andererseits für Bad Ems auch in Cobol programmiert wurde.

¹⁰ Auf meiner persönlichen Webseite https://www.wgiere.de habe ich unter „Krisen, 3. OPS-Krise“ viele Einzelheiten zu diesem leidigen Thema ausgeführt. Sie schließen mit der lapidaren Feststellung: „Ich hielt und halte den OPS-Kompromiss für eine Missgeburt.“

• AEG: Allgemeine Elektrizitätsgesellschaft
• AGK: Arbeitsgruppe Klartextanalyse der GMDS
• AKAS: Arzt-Kommunikations- und Auskunfts-System
• BAIK: Befunddokumentation und Arztbriefschreibung im Krankenhaus, Bund-Länder-Vorhaben
• BMFT: Bundesministerium für Forschung und Technologie
• DEPAK: Demonstrations-DV-Projekt für das Allgemeine Krankenhaus
• DIADEM: Dokumentations- und Informationsverbesserung für den Arzt mit Dezentralem EDV-Modul
• Dietz: Dietz Computer-Systeme KG, Mülheim an der Ruhr
• DIMDI: Deutsches Institut für Medizinische Dokumentation und Information (dem Gesundheitsministerium unterstellt), 2020 in das Bundesinstitut für Arzneimittel und Medizinprodukte (BfArM) eingegliedert
• DIPAS: Dokumentations- und Informationsverbesserung in der Praxis des Niedergelassenen Arztes durch EDV-Service
• DKD: Deutsche Klinik für Diagnostik, Wiesbaden
• DMI: DMI GmbH & Co. KG, Münster (Krankenhaus-Software- und Archivierungs-Firma (ursprünglich „Deutsches Mikrofilm Institut“)
• DOC: Doctors Office Computer (Produkt von TA)
• DOMINIG: DV-Einsatz zur Lösung überbetrieblicher Organisations- und Managementaufgaben durch Integration des Normierten Informationsflusses zwischen verschiedenen Einrichtungen des Gesundheitswesens
• DUSP: Datenerfassungs- und Speicherungs-Programm
• DUTAP: Dekodierungs- und Text-Ausgabe-Programm
• DVmed: siehe SVK DVmed
• EDAP: Einführung der Datenverarbeitung in die Ärztliche Praxis
• EU: Europäische Union
• FITG: Förderkreis Industrie- und Technikgeschichte e.V., Frankfurt a.M.
• GFF: Gesellschaft zur Förderung der Forschung an der Deutschen Klinik für Diagnostik e.V., Wiesbaden
• GMDS: Gesellschaft für Medizinische Dokumentation und Statistik. Heute: Deutsche Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie e.V.
• HSK: Dr. Horst Schmidt Kliniken, Wiesbaden
• HZD: Hessische Zentrale für Datenverarbeitung, Wiesbaden
• IATROS: Informations-Aufbereitendes Text-Retrieval-Orientiertes System
• ID: Information und Dokumentation im Gesundheitswesen GmbH & Co. KGaA, Berlin
• IQWIG: Institut für Qualität und Wirtschaftlichkeit im Gesundheitswesen, Köln und Berlin
• ISAM: Index-Sequential Access Method
• Kaiser Permanente: Kaiser Permanente Medical Group, Oakland, CA
• Karolinska: Karolinska Sjukhuset, Stockholm
• KBV: Kassenärztliche Bundesvereinigung, Berlin (früher Köln)
• KiGSt: Kirchliche Gemeinschaftsstelle für elektronische Datenverarbeitung, Frankfurt a.M. (seit 2023 ECKD, Kassel)
• KIS: Krankenhaus-Informations-System
• MI: Medizinische Informatik (früher Datenverarbeitung in der Medizin)
• MCS: Medizinische Computersysteme GmbH, Eltville
• MGH: Massachusetts General Hospital, Boston, MS
• MuCHMORe: Multilingual Concept Hierarchies for Medical Information, Organisation and Retrieval (Transatlantisches Kooperationsprojekt der EU und NSF/USA)
• Mumps: Massachusetts General Hospital Utility Multi-Programming System, 1966 von Octo Barnett entwickelt. 1993 Namensänderung auf M.
• NIH: National Institutes of Health, Bethesda, MD
• NLG: Natural Language Generation
• NSF: US National Science Foundation, Arlington, VA
• Philips Röntgenmüller: Unternehmensbereich Medizin der Firma Philips, Hamburg
• Siemens UBmed: Siemens-Unternehmensbereich Medizin, Erlangen
• SVK DVmed: Sachverständigenkreis Datenverarbeitung in der Medizin
• TA: Triumph-Adler, Bürogeräte- und Computerfirma, Nürnberg (seit 2011 TA Triumph-Adler GmbH)
• ZI: Zentralinstitut für die kassenärztliche Versorgung in der Bundesrepublik Deutschland, Köln (später Berlin)
• ZInfo: Zentrum der Medizinischen Informatik am Klinikum der J. W. Goethe-Universität, Frankfurt a.M.

Barnett, Octo (MGH)
Bertuleit, Helmuth (BMFT)
Brauer, Wilfried

Collen, Morris F. (Kaiser)

Diekmann, Fritz
Dietz, Peter

Freybott, Armin

Ganz, Bruno
Geiss, Erhard

Hall, Paul (Karolinska)
Haux, Reinhold
Herold, Horst

Kampe, Dieter (KiGSt)
Koller, Siegfried

Moore, Henry
Muschallik, Hans Wolf

Pirtkien, Rudolf

Schaefer, Otfried P.
Schneider, Berthold
Schröpl, Friedrich
Schuster, R. Werner
Schwartz, Friedrich Wilhelm

Wagner, Gustav
Wilde, Eckehard

Manche Jahresangaben in der Zeittafel (s. Tabelle 1 [Tab. 1]) sind aus der Erinnerung geschätzt, aber die Reihenfolge dürfte stimmen und mag zur groben Orientierung genügen. Weiterführende Information zu den genannten Projekten finden sich unter https://www.baik.de.

Diese revidierte Fassung meines Entwurfs vom Ende letzten Jahres ist das Ergebnis ausgiebiger Beratungen mit dem Kollegen Reinhold Haux, dem ich für seine prompte Reaktion auf meinen Hilferuf*, eine ausführliche Videodiskussion und seine Korrekturvorschläge von Herzen danke. Dankbar bin ich besonders auch dem Kollegen Bernd Graubner für seine, wie seit jeher gewohnt, gründlichen und treffenden Korrekturvorschläge. Dem MIBE-Team und der GMS-Redaktion danke ich aufrichtig für die umsichtige, effektive und verständnisvolle Unterstützung bei der Fertigstellung des Beitrags.

* Die Skizze hatte ich nach einer schlaflosen Nacht erstellt und wusste nicht, was ich weiter damit tun sollte. Deswegen bat ich den geschätzten Kollegen um Rat und Hilfe.

Der Autor erklärt, dass er keine Interessenkonflikte in Zusammenhang mit diesem Artikel hat.