Verpasste Chancen. Nachdenken über Fehlentwicklungen der Medizinischen Informatik

mibe000247 10.3205/mibe000247 urn:nbn:de:0183-mibe0002478 Systematischer Rückblick und Perspektiven Verpasste Chancen. Nachdenken über Fehlentwicklungen der Medizinischen Informatik Missed opportunities. Reflections on misdevelopments in medical informatics Giere Giere Wolfgang W Prof. em. Dr. med.

Eddersbacher Berg 5, 65232 Taunusstein, DeutschlandKlinikum der J. W. Goethe-Universität, Frankfurt a. M., Deutschland

author German Medical Science GMS Publishing House

Düsseldorf

610 20230714 germ This is an Open Access article distributed under the terms of the Creative Commons Attribution 4.0 License. Dieser Artikel ist ein Open-Access-Artikel und steht unter den Lizenzbedingungen der Creative Commons Attribution 4.0 License (Namensnennung). 1860-9171 19 GMS Medizinische Informatik, Biometrie und Epidemiologie GMS Med Inform Biom Epidemiol 08 Vor fünfzig Jahren war Deutschland in der Datenverarbeitung in der Medizin „second to none“, zusammen mit Schweden und den USA weltweit führend. Heute rangiert die Praxis der Digitalisierung in der Medizin unter „ferner liefen“, hinkt weit hinter her. Woran hat es gelegen? Ein Pionier der Medizinischen Informatik versucht, darauf Antworten zu finden. Fifty years ago medical informatics in Germany was second to none, was world-leading along with Sweden and the USA. Today we are “also-rans” regarding the digitalisation in medicine, have a low ranking. What is the cause? A pioneer of medical informatics tries to find an answer. 1 EinleitungVor 50 Jahren, Ende der 1960er, Anfang der 1970er Jahre, führte in der Anwendung der Datenverarbeitung in der Medizin unsere Bundesrepublik zusammen mit den USA1 und Schweden2. 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 Zu</PlainText></TextGroup>sammenhänge mit Hintergrundwissen erhellen, einige Aspekte der offiziellen Geschichtsschreibung der Medizinischen Informatik ergänzen – ohne erhobenen Zeigefi<TextGroup><PlainText>n</PlainText></TextGroup>ger. Bewusst wage ich mich für diese Aufgabe auch an Spekulationen, an Was-wäre-wenn-Fragen.</Pgraph><Pgraph>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, I<TextGroup><PlainText>n</PlainText></TextGroup>stitutionen 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.</Pgraph><Pgraph>Wie gesagt: Dieses soll keine wissenschaftliche Arbei<TextGroup><PlainText>t w</PlainText></TextGroup>erden, 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 <Mark2>Handbuch der medizinischen Dokumentation und Datenverarbeitung</Mark2>, 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<Superscript>3</Superscript>.</Pgraph></TextBlock> <TextBlock linked="yes" name="2 Frühe Förderung"> <MainHeadline>2 Frühe Förderung</MainHeadline><Pgraph>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<Superscript>4</Superscript> des Förderkreises Industrie- und Technikgeschichte (FITG, <Hyperlink href="https://www.fitg.de">https://www.fitg.de</Hyperlink>) 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.</Pgraph></TextBlock> <TextBlock linked="yes" name="3 Sachverständigenkreis Datenverarbeitung in der Medizin (DVmed)"> <MainHeadline>3 Sachverständigenkreis Datenverarbeitung in der Medizin (DVmed)</MainHeadline><Pgraph>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).</Pgraph><Pgraph>Der Sachverständigenkreis hatte als Grundlage für ein vereinheitlichtes Berichtswesen über die Projektfortschri<TextGroup><PlainText>t</PlainText></TextGroup>te 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.</Pgraph><SubHeadline>3.1 Dietz-Debakel im Krankenhaus Bethanien in Moers</SubHeadline><Pgraph>Peter Dietz baute in Mülheim an der Ruhr erfolgreich Prozessrechner<Superscript>5</Superscript> 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 de<TextGroup><PlainText>m F</PlainText></TextGroup>ernseherbildschirm, wenn er den Patienten besucht. Alle eingehenden Befunde werden eingegebe<TextGroup><PlainText>n; die u</PlainText></TextGroup>nterschiedlichen 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.</Pgraph><Pgraph>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.</Pgraph><Pgraph>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ännche<TextGroup><PlainText>n i</PlainText></TextGroup>m Keller händisch aufbereitet werden. Die Ärzte waren begeistert. Aber die an sich simple EDV-Lösung hat es nie gegeben.</Pgraph><Pgraph>In meinen Augen war das eine verpasste Chance. Hätte man den Benutzeranspruch des Arztes (schnelle R<TextGroup><PlainText>e</PlainText></TextGroup>akti<TextGroup><PlainText>o</PlainText></TextGroup>nszeit) 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.</Pgraph><Pgraph>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!</Pgraph><SubHeadline>3.2 Philips Kommunikationssystem in Herford</SubHeadline><Pgraph>Im Kreiskrankenhaus Herford hatte die Firma Philips Röntgenmüller aus Hamburg ein komplettes Leis<TextGroup><PlainText>t</PlainText></TextGroup>ungsan<TextGroup><PlainText>f</PlainText></TextGroup>orderungs- 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 standardisier<TextGroup><PlainText>t, k</PlainText></TextGroup>annte 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<Superscript>6</Superscript>.</Pgraph><Pgraph>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.</Pgraph><SubHeadline>3.3 Einführung der Datenverarbeitung in die Ärztliche Praxis (EDAP)</SubHeadline><Pgraph>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 Diagno<TextGroup><PlainText>s</PlainText></TextGroup>tik 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.</Pgraph><Pgraph>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.</Pgraph><Pgraph>Beide Vorhaben wurden vom Sachverständigenkreis D<TextGroup><PlainText>V</PlainText></TextGroup>med 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.</Pgraph><SubHeadline>3.4 DOMINIG</SubHeadline><Pgraph>„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?</Pgraph><Pgraph>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-R<TextGroup><PlainText>e</PlainText></TextGroup>staurant 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.</Pgraph><Pgraph>Mehrere Teams bewarben sich:</Pgraph><Pgraph><UnorderedList><ListItem level="1">Für DOMINIG I, „Regionales medizinisches Organisati<TextGroup><PlainText>o</PlainText></TextGroup>ns- und Planungssystem für überbetriebliche Aufg<TextGroup><PlainText>a</PlainText></TextGroup>ben“, kurz: das öffentliche Gesundheitswesen, war eine Berliner Bewerbung erfolgreich.</ListItem><ListItem level="1">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.</ListItem><ListItem level="1">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.</ListItem></UnorderedList></Pgraph><Pgraph>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.</Pgraph><SubHeadline2>3.4.1 DOMINIG I, öffentliches Gesundheitswesen</SubHeadline2><Pgraph>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.</Pgraph><SubHeadline2>3.4.2 DOMINIG II, Krankenhausbereich</SubHeadline2><Pgraph>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-Sof<TextGroup><PlainText>t</PlainText></TextGroup>wa<TextGroup><PlainText>r</PlainText></TextGroup>e 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 17<TextGroup><PlainText>2 K</PlainText></TextGroup>rankenhä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.</Pgraph><SubHeadline2>3.4.3 DOMINIG III, niedergelassene Ärzte</SubHeadline2><Pgraph>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…</Pgraph><Pgraph>Mit der Projektdurchführung sollte neben der DKD als Partner das neu zu gründende „Zentralinstitut für di<TextGroup><PlainText>e k</PlainText></TextGroup>assenä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.<Superscript>7</Superscript> 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 <Hyperlink href="https://www.baik.de/akas">https://www.baik.de/akas</Hyperlink>). 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<Superscript>8</Superscript>. DIADEM wurde genehmigt – zusätzlich zu DOMINIG III (entgegen den ursprünglichen Intentionen des BMFT).</Pgraph><Pgraph>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; DOMINI<TextGroup><PlainText>G I</PlainText></TextGroup>II wurde von Friedrich Wilhelm Schwartz ohne den med<TextGroup><PlainText>iz</PlainText></TextGroup>inischen 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.</Pgraph><Pgraph>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!</Pgraph><Pgraph><Mark1>Fazit:</Mark1> 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.</Pgraph><SubHeadline>3.5 DIADEM</SubHeadline><Pgraph>„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.</Pgraph><SubHeadline>3.6 DEPAK</SubHeadline><Pgraph>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 Leistungsste<TextGroup><PlainText>l</PlainText></TextGroup>lenkommunikation und konnte mit Fug und Recht als bestens eingeführtes „Krankenhaus-Informations-System (KIS)“ angesehen werden.</Pgraph><Pgraph>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 kau<TextGroup><PlainText>m – I</PlainText></TextGroup>BM 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!</Pgraph></TextBlock> <TextBlock linked="yes" name="4 Bund-Länder-Programme"> <MainHeadline>4 Bund-Länder-Programme</MainHeadline><Pgraph>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.</Pgraph><SubHeadline>4.1 Verwaltung</SubHeadline><Pgraph>„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.</Pgraph><SubHeadline>4.2 Medizinische Dokumentation</SubHeadline><Pgraph>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:</Pgraph><Pgraph><UnorderedList><ListItem level="1">Nicht verwaltungs-, sondern arztorientiert</ListItem><ListItem level="1">Dezentraler Einsatz von Datenverarbeitung für das DOC-System</ListItem><ListItem level="1">Eigene Programmiersprache DUTAP für die Berichtsge<TextGroup><PlainText>n</PlainText></TextGroup>erierung</ListItem><ListItem level="1">Gesamtsystem BAIK programmiert in Mumps (nicht in Cobol, wie die übrigen Bund-Länder-Programme)<Superscript>9</Superscript></ListItem><ListItem level="1">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).</ListItem></UnorderedList></Pgraph><Pgraph>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.)</Pgraph></TextBlock> <TextBlock linked="yes" name="5 BAIK – verpasste Chance"> <MainHeadline>5 BAIK – verpasste Chance</MainHeadline><Pgraph>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:</Pgraph><Pgraph><UnorderedList><ListItem level="1"><Mark1>Aufwand:</Mark1> 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.)</ListItem><ListItem level="1"><Mark1>Fehlende Mittel: </Mark1>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!)</ListItem><ListItem level="1"><Mark1>Mangelhafte Kommerzialisierung:</Mark1> 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.</ListItem><ListItem level="1"><Mark1>Unzureichende Wartungskapazitäten:</Mark1> 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!</ListItem></UnorderedList></Pgraph><Pgraph>Und damit sind wir bei den schmerzlichen Überlegungen „Was wäre, wenn“ und landen bei Spekulationen.</Pgraph></TextBlock> <TextBlock linked="yes" name="6 Was wäre, wenn ...? Spekulationen"> <MainHeadline>6 Was wäre, wenn ...? Spekulationen</MainHeadline><Pgraph>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.</Pgraph><SubHeadline>6.1 DOMINIG</SubHeadline><Pgraph>Wenn DOMINIG ein Erfolg geworden wäre – und nach meiner festen Überzeugung wäre das möglich gewese<TextGroup><PlainText>n –</PlainText></TextGroup> 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.</Pgraph><Pgraph>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).</Pgraph><Pgraph>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!</Pgraph><Pgraph>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.</Pgraph><Pgraph>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“.</Pgraph><SubHeadline>6.2 Zentralinstitut für die kassenärztliche Versorgung in der Bundesrepublik Deutschland (ZI)</SubHeadline><Pgraph>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 DOM<TextGroup><PlainText>I</PlainText></TextGroup>NI<TextGroup><PlainText>G I</PlainText></TextGroup>II, 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.</Pgraph><SubHeadline>6.3 DKD-Krise</SubHeadline><Pgraph>In der Krise der DKD verhandelte ein Drei-Männer-Gr<TextGroup><PlainText>e</PlainText></TextGroup>m<TextGroup><PlainText>i</PlainText></TextGroup>um 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 s<TextGroup><PlainText>i</PlainText></TextGroup>cher keine Trennung von der DKD gegeben.</Pgraph></TextBlock> <TextBlock linked="yes" name="7 Trauriges Fazit"> <MainHeadline>7 Trauriges Fazit</MainHeadline><Pgraph>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.</Pgraph><Pgraph>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)<Superscript>10</Superscript>.</Pgraph><Pgraph>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äg<TextGroup><PlainText>e d</PlainText></TextGroup>es transatlantischen Gemeinschaftsprojektes MuC<TextGroup><PlainText>H</PlainText></TextGroup>MO<TextGroup><PlainText>R</PlainText></TextGroup>e an die NSF und die EU zu sehen.</Pgraph><Pgraph>Darüber gibt meine BAIK-Webseite (<Hyperlink href="https://www.baik.de">https://www.baik.de</Hyperlink>) 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.</Pgraph></TextBlock> <TextBlock linked="yes" name="8 Anmerkungen"> <MainHeadline>8 Anmerkungen</MainHeadline><Pgraph><Superscript>1</Superscript> Zum Beispiel Morris Collen mit EDV-gestütztem Automatic Multiphasic Health Testing (AMHT) (Kaiser Permanen<TextGroup><PlainText>t</PlainText></TextGroup>e) und Octo Barnett mit Computer Stored Ambulatory Record (COSTAR) (MGH).</Pgraph><Pgraph><Superscript>2</Superscript> Zum Beispiel Paul Hall mit der EDV-basierten Patientenakte J5 (Karolinska Sjukhuset).</Pgraph><Pgraph><Superscript>3</Superscript> 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.</Pgraph><Pgraph><Superscript>4</Superscript> 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 <Mark2>Der Baader Meinhof Komplex</Mark2> als Kulisse für den Leiter des Bundeskriminalamtes, Horst Herold (gespielt von Bruno Ganz), bei der Erfindung der „Rasterfahndung“.</Pgraph><Pgraph><Superscript>5</Superscript> 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).</Pgraph><Pgraph><Superscript>6</Superscript> 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 <Hyperlink href="https://de.wikipedia.org/wiki/Mumps">https://de.wikipedia.org/wiki/Mumps</Hyperlink>.</Pgraph><Pgraph><Superscript>7</Superscript> 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).</Pgraph><Pgraph><Superscript>8</Superscript> 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.</Pgraph><Pgraph><Superscript>9</Superscript> Eine Ausnahme bildete der zentrale Auswertungsteil IATROS, der einerseits im Mumps, andererseits für Bad Ems auch in Cobol programmiert wurde.</Pgraph><Pgraph><Superscript>10</Superscript> Auf meiner persönlichen Webseite <Hyperlink href="https://www.wgiere.de">https://www.wgiere.de</Hyperlink> 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.“</Pgraph></TextBlock> <TextBlock linked="yes" name="9 Appendix"> <MainHeadline>9 Appendix</MainHeadline><SubHeadline>9.1 Abkürzungen: Projekte und Institutionen</SubHeadline><Pgraph><UnorderedList><ListItem level="1">AEG: Allgemeine Elektrizitätsgesellschaft</ListItem><ListItem level="1">AGK: Arbeitsgruppe Klartextanalyse der GMDS</ListItem><ListItem level="1">AKAS: Arzt-Kommunikations- und Auskunfts-System</ListItem><ListItem level="1">BAIK: Befunddokumentation und Arztbriefschreibung im Krankenhaus, Bund-Länder-Vorhaben</ListItem><ListItem level="1">BMFT: Bundesministerium für Forschung und Technologie</ListItem><ListItem level="1">DEPAK: Demonstrations-DV-Projekt für das Allgemeine Krankenhaus</ListItem><ListItem level="1">DIADEM: Dokumentations- und Informationsverbesserung für den Arzt mit Dezentralem EDV-Modul</ListItem><ListItem level="1">Dietz: Dietz Computer-Systeme KG, Mülheim an der Ruhr</ListItem><ListItem level="1">DIMDI: Deutsches Institut für Medizinische Dokumentation und Information (dem Gesundheitsministerium unterstellt), 2020 in das Bundesinstitut für Arzneimittel und Medizinprodukte (BfArM) eingegliedert</ListItem><ListItem level="1">DIPAS: Dokumentations- und Informationsverbesserung in der Praxis des Niedergelassenen Arztes durch EDV-Service</ListItem><ListItem level="1">DKD: Deutsche Klinik für Diagnostik, Wiesbaden</ListItem><ListItem level="1">DMI: DMI GmbH & Co. KG, Münster (Krankenhaus-Software- und Archivierungs-Firma (ursprünglich „Deutsches Mikrofilm Institut“)</ListItem><ListItem level="1">DOC: Doctors Office Computer (Produkt von TA)</ListItem><ListItem level="1">DOMINIG: DV-Einsatz zur Lösung überbetrieblicher Organisations- und Managementaufgaben durch Integration des Normierten Informationsflusses zwischen verschiedenen Einrichtungen des Gesundheitswesens</ListItem><ListItem level="1">DUSP: Datenerfassungs- und Speicherungs-Programm</ListItem><ListItem level="1">DUTAP: Dekodierungs- und Text-Ausgabe-Programm</ListItem><ListItem level="1">DVmed: siehe SVK DVmed</ListItem><ListItem level="1">EDAP: Einführung der Datenverarbeitung in die Ärztliche Praxis</ListItem><ListItem level="1">EU: Europäische Union</ListItem><ListItem level="1">FITG: Förderkreis Industrie- und Technikgeschichte e.V., Frankfurt a.M.</ListItem><ListItem level="1">GFF: Gesellschaft zur Förderung der Forschung an der Deutschen Klinik für Diagnostik e.V., Wiesbaden</ListItem><ListItem level="1">GMDS: Gesellschaft für Medizinische Dokumentation und Statistik. Heute: Deutsche Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie e.V.</ListItem><ListItem level="1">HSK: Dr. Horst Schmidt Kliniken, Wiesbaden</ListItem><ListItem level="1">HZD: Hessische Zentrale für Datenverarbeitung, Wiesbaden</ListItem><ListItem level="1">IATROS: Informations-Aufbereitendes Text-Retrieval-Orientiertes System</ListItem><ListItem level="1">ID: Information und Dokumentation im Gesundheitswesen GmbH & Co. KGaA, Berlin</ListItem><ListItem level="1">IQWIG: Institut für Qualität und Wirtschaftlichkeit im Gesundheitswesen, Köln und Berlin</ListItem><ListItem level="1">ISAM: Index-Sequential Access Method</ListItem><ListItem level="1">Kaiser Permanente: Kaiser Permanente Medical Group, Oakland, CA</ListItem><ListItem level="1">Karolinska: Karolinska Sjukhuset, Stockholm</ListItem><ListItem level="1">KBV: Kassenärztliche Bundesvereinigung, Berlin (früher Köln)</ListItem><ListItem level="1">KiGSt: Kirchliche Gemeinschaftsstelle für elektronische Datenverarbeitung, Frankfurt a.M. (seit 2023 ECKD, Kassel)</ListItem><ListItem level="1">KIS: Krankenhaus-Informations-System</ListItem><ListItem level="1">MI: Medizinische Informatik (früher Datenverarbeitung in der Medizin)</ListItem><ListItem level="1">MCS: Medizinische Computersysteme GmbH, Eltville</ListItem><ListItem level="1">MGH: Massachusetts General Hospital, Boston, MS</ListItem><ListItem level="1">MuCHMORe: Multilingual Concept Hierarchies for Medical Information, Organisation and Retrieval (Transatlantisches Kooperationsprojekt der EU und NSF/USA)</ListItem><ListItem level="1">Mumps: Massachusetts General Hospital Utility Multi-Programming System, 1966 von Octo Barnett entwickelt. 1993 Namensänderung auf M.</ListItem><ListItem level="1">NIH: National Institutes of Health, Bethesda, MD</ListItem><ListItem level="1">NLG: Natural Language Generation</ListItem><ListItem level="1">NSF: US National Science Foundation, Arlington, VA</ListItem><ListItem level="1">Philips Röntgenmüller: Unternehmensbereich Medizin der Firma Philips, Hamburg</ListItem><ListItem level="1">Siemens UBmed: Siemens-Unternehmensbereich Medizin, Erlangen</ListItem><ListItem level="1">SVK DVmed: Sachverständigenkreis Datenverarbeitung in der Medizin</ListItem><ListItem level="1">TA: Triumph-Adler, Bürogeräte- und Computerfirma, Nürnberg (seit 2011 TA Triumph-Adler GmbH)</ListItem><ListItem level="1">ZI: Zentralinstitut für die kassenärztliche Versorgung in der Bundesrepublik Deutschland, Köln (später Berlin)</ListItem><ListItem level="1">ZInfo: Zentrum der Medizinischen Informatik am Klinikum der J. W. Goethe-Universität, Frankfurt a.M.</ListItem></UnorderedList></Pgraph><SubHeadline>9.2 Personenindex</SubHeadline><Pgraph>Barnett, Octo (MGH)<LineBreak></LineBreak>Bertuleit, Helmuth (BMFT)<LineBreak></LineBreak>Brauer, Wilfried</Pgraph><Pgraph>Collen, Morris F. (Kaiser)</Pgraph><Pgraph>Diekmann, Fritz<LineBreak></LineBreak>Dietz, Peter</Pgraph><Pgraph>Freybott, Armin</Pgraph><Pgraph>Ganz, Bruno<LineBreak></LineBreak>Geiss, Erhard</Pgraph><Pgraph>Hall, Paul (Karolinska)<LineBreak></LineBreak>Haux, Reinhold<LineBreak></LineBreak>Herold, Horst</Pgraph><Pgraph>Kampe, Dieter (KiGSt)<LineBreak></LineBreak>Koller, Siegfried</Pgraph><Pgraph>Moore, Henry<LineBreak></LineBreak>Muschallik, Hans Wolf</Pgraph><Pgraph>Pirtkien, Rudolf</Pgraph><Pgraph>Schaefer, Otfried P.<LineBreak></LineBreak>Schneider, Berthold<LineBreak></LineBreak>Schröpl, Friedrich<LineBreak></LineBreak>Schuster, R. Werner<LineBreak></LineBreak>Schwartz, Friedrich Wilhelm</Pgraph><Pgraph>Wagner, Gustav<LineBreak></LineBreak>Wilde, Eckehard</Pgraph><SubHeadline>9.3 Zeittafel ausgewählter eigener Projekte</SubHeadline><Pgraph>Manche Jahresangaben in der Zeittafel (s. Tabelle 1 <ImgLink imgNo="1" imgType="table"/>) 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 <Hyperlink href="https://www.baik.de">https://www.baik.de</Hyperlink>.</Pgraph></TextBlock> <TextBlock linked="yes" name="Danksagung"> <MainHeadline>Danksagung</MainHeadline><Pgraph>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.</Pgraph><Pgraph>* 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.</Pgraph></TextBlock> <TextBlock linked="yes" name="Interessenkonflikt"> <MainHeadline>Interessenkonflikt</MainHeadline><Pgraph>Der Autor erklärt, dass er keine Interessenkonflikte in Zusammenhang mit diesem Artikel hat.</Pgraph></TextBlock> <Media> <Tables> <Table format="png"> <MediaNo>1</MediaNo> <MediaID>1</MediaID> <Caption><Pgraph><Mark1>Tabelle 1: Zeittafel ausgewählter eigener Projekte</Mark1></Pgraph></Caption> </Table> <NoOfTables>1</NoOfTables> </Tables> <Figures> <NoOfPictures>0</NoOfPictures> </Figures> <InlineFigures> <NoOfPictures>0</NoOfPictures> </InlineFigures> <Attachments> <NoOfAttachments>0</NoOfAttachments> </Attachments> </Media> </OrigData> </GmsArticle>