Die Rolle von eMed in der OP-Planung der Sanusklinik

Ametowobla, Dzifa

doi:10.1007/978-3-658-37256-9_4

Dzifa Ametowobla²

1723 Accesses

Zusammenfassung

Dieses Kapitel ist der Vorstellung der Fallstudie gewidmet. Die Ausführungen entsprechen den drei Phasen der Analyse, die im vorangegangenen Abschnitt 3.2 beschrieben worden sind: In der ersten Phase wurde das zentrale Handlungsproblem, das beim Umgang mit der Software bearbeitet wird, und die für diesen Umgang relevanten Elemente der Software genauer bestimmt. In der zweiten Phase wurden die Modelle, die sich um diese relevanten Softwareelemente aufspannen, rekonstruiert. In der dritten Phase wurden diese Analyseergebnisse genutzt, um die verketteten Spiele zu verstehen, die um den Einsatz von eMed bei der OP-Planung gespielt werden.

You have full access to this open access chapter, Download chapter PDF

Dieses Kapitel ist der Vorstellung der Fallstudie gewidmet. Die Ausführungen entsprechen den drei Phasen der Analyse, die im vorangegangenen Abschnitt 3.2 beschrieben worden sind: In der ersten Phase wurde das zentrale Handlungsproblem, das beim Umgang mit der Software bearbeitet wird, und die für diesen Umgang relevanten Elemente der Software genauer bestimmt. In der zweiten Phase wurden die Modelle, die sich um diese relevanten Softwareelemente aufspannen, rekonstruiert. Zu diesem Zweck wurde auf eine Kombination aus Analyse der Softwaredokumentation und Sekundärdaten über Entwicklungsprozesse und die sozialen Systeme, in denen diese Elemente entwickelt worden sind, zurückgegriffen. In der dritten Phase wurden diese Analyseergebnisse genutzt, um die verketteten Spiele zu verstehen, die um den Einsatz von eMed bei der OP-Planung gespielt werden. Der Aufbau des folgenden Kapitels spiegelt diese drei Phasen grob. Nach einer Einführung in den gesellschaftlichen Kontext, in dem die OP-Planung mit eMed in der Sanusklinik betrachtet werden muss, werden zuerst die untersuchten Planungsprozesse und die für die Nutzung relevanten Elemente der Software vorgestellt. Im zweiten Schritt werden die relevanten Modelle des Organisierens aus den sozialen Systemen rekonstruiert, die als Ursprünge dieser Modelle ausgemacht worden sind. Im Anschluss folgt die Analyse der Spiele, in denen sich die Modelle des Organisierens als performativ erwiesen haben. Dabei wird dargestellt, wo Akteur*innen eMed anders als vorgesehen nutzen und sich damit den Kontrollvorstellungen widersetzen, die in der Software angelegt sind. Die Spielanalyse zeigt auch, wie beim Umgang mit eMed Kontrolle im Handlungsfeld verteilt wird. Am Ende des Kapitels kehre ich zur Forschungsfrage zurück und diskutiere in der Gesamtschau auf die vier vorgestellten Spiele, welche Rolle die in eMed eingebetteten Modelle des Organisierens für den Umgang mit der Software bei der OP-Planung in den zwei untersuchten Abteilungen der Sanusklinik spielen.

4.1 Hintergrund: Die Sanusklinik und ihr Krankenhausinformationssystem

Wie in Kapiteln 2 und 3 ausgeführt, ist der Umgang mit Software abhängig von sozialen Bedingungen, die über den engen Rahmen der beobachteten Nutzungsprozesse hinausreichen. Vor der Darstellung der untersuchten Prozesse der OP-Planung werden daher zuerst grundlegende Entwicklungen im Gesundheitssystem und in der Sanusklinik skizziert, die für ein Verständnis des Falls notwendig sind.

4.1.1 Diagnosis Related Groups und die Ökonomisierung der Krankenhäuser

Krankenhäuser sind Organisationen, in denen medizinische und ökonomische Anforderungen und an diesen ausgerichtete Formen der Verhaltenskontrolle permanent ausbalanciert werden müssen (vgl. 3.3.1.). Diese für Krankenhäuser typische Balance hat sich in Deutschland in den letzten Jahrzehnten stark in Richtung Ökonomie verschoben: Bis in die 1970er Jahre war das Gesundheitssystem bedarfswirtschaftlich organisiert, was bedeutet, dass in den Krankenhäusern das Primat der Medizin galt und „Vergütungsregelungen […] dazu [dienten], den Kliniken versorgungsnotwendige Mittel zuzuführen“ (Iseringhausen und Staender 2012, S. 188). Seitdem ist die Steigerung der Kosteneffizienz des Krankenhausbetriebs in den Vordergrund gerückt. Dadurch haben sich sowohl die Beziehungen zwischen den medizinischen Bereichen des Krankenhauses als auch die zwischen Medizin und Administration neu geordnet (Bode 2010): Einerseits hat sich in vielen Krankenhäusern die interne Hierarchie zwischen den verschiedenen medizinischen Abteilungen verschärft, in der zentrale „Funktionsbereiche“, wie zum Beispiel die Chirurgie, die Abläufe vorgeben, denen andere, wie zum Beispiel die Anästhesie, als nachgeordnete Abteilungen folgen müssen (Iseringhausen und Staender 2012, S. 189). Andererseits wird die Autonomie der Mediziner*innen durch größere Macht der Geschäftsführung bzw. der Verwaltungseinheiten beschnitten (a.a.O., S. 191), weil die finanziellen Mittel, über die sie verfügen, durch geänderte Gesetze zur Krankenhausfinanzierung knapper geworden sind.

Die Krankenbehandlung ist ein Arbeitsfeld mit unbestimmter Technologie und gesellschaftlich umstrittener und damit in der Praxis abstrakter Zieldefinition (Klatetzki 2010): wann ein Mensch gesund ist, wann er oder sie behandelt werden sollte und wie ist hochgradig interpretationsbedürftig. Die Antwort auf diese Fragen unterscheidet sich von Mensch zu Mensch und von Situation zu Situation. Unter diesen Umständen ist die Verwaltung von Krankenhäusern nach einfachen Kosten-Nutzen-Betrachtungen in einem bedarfswirtschaftlich orientierten Gesundheitssystem schwierig, denn der Nutzen einer Behandlung lässt sich nicht ohne weiteres verallgemeinern oder eindeutig berechnen (Bode 2010, S. 69; Vogd 2016). In Deutschland wird seit dem Jahr 2003 das so genannte DRG-System genutzt, um dieses Problem zu lösen. Krankheitsbilder und dafür vorgesehene Behandlungen werden dabei in standardisierte Fallgruppen einsortiert, die Diagnosis Related Groups, kurz DRGs, genannt werden. Behandlungen werden nicht individuell nach Aufwand bezahlt, sondern nach einem festgelegten Satz, der pauschal anhand der Fallgruppe festgelegt ist (Feißt und Moltzberger 2016). Die sogenannten Fallpauschalen ersetzen den Anteil des Krankenhausbudgets^{Footnote 1}, der früher auf Basis der tatsächlich durch eine Behandlung entstandenen Kosten berechnet wurde, durch Entgelte, die auf Basis der Menge an bearbeiteten Fällen berechnet werden. Dadurch ist eine Dynamik entstanden, die das Primat der Medizin bei der Entscheidung über die Behandlung unter Druck durch die Logik der Ökonomie setzt:

„Indem an die ursprünglich von Ingenieuren erfundenen statistischen Mittel seitens der Politik über das Recht ein Preis angeheftet wurde, konnten jetzt unterschiedliche Akteure die DRGs als Waren in Hinblick auf Gewinn- und Verlustchancen kalkulieren. Auf dem Papier hat man jetzt ein Abrechnungskonstrukt mit dem sich nun rechnen und abschätzen ließ, welche Patientengruppe und welche Behandlungsprozeduren Profit versprechen.“ (Vogd 2016, S. 284)

Die DRGs ordnen den in den Krankenhäusern erbrachten medizinischen Leistungen einen eindeutigen ökonomischen Wert zu. Die Ergebnisse der Arbeit im Krankenhaus werden eindeutig berechenbar und können dadurch einfacher ökonomischen Kalkülen unterworfen werden. „[D]ie produktive und emanzipative Kraft der ökonomischen Kalküle [liegt darin][…], divergierende Zweck-Mittel-Perspektiven in ein sozial plausibles Arrangement zu überführen“ (Vogd 2016). Weil durch die DRG eine Möglichkeit besteht, die Arbeit im Krankenhaus mit Zahlen zu bewerten, ohne Bezug auf mehrdeutige und umstrittene Ziele nehmen zu müssen, lassen sich ökonomische Kalküle mit DRGs einfach in eindeutige Organisationsregeln übersetzen. Durch solche Regeln können Entscheidungssituationen innerhalb des Krankenhauses mit Bezug auf die Wirtschaftlichkeit (berechenbar anhand der DRGs) gelöst werden, ohne dass die Beteiligten die Widersprüche zwischen den konkurrierenden Anforderungen, denen Krankenhäuser immer ausgesetzt sind, bearbeiten müssten (Heimer 1999).

Wie Werner Vogd (2016) konstatiert, führt diese Entscheidungsstrategie in der Situation, in der sich das Gesundheitssystem seit den 1970er Jahren befindet, nicht nur zu einer Vielzahl an unterschiedlichen Auseinandersetzungen zwischen allen Akteur*innen des Gesundheitssystems um die DRGs (statt um adäquatere Krankenbehandlung zu insgesamt niedrigeren oder gleichen Kosten) und zu einer Entfremdung der Beteiligten von ihrer Arbeit, die formal der Gesundheit dienen soll (a.a.O. 299 f.). Sie führt auf Dauer auch systematisch zu einer Fehlverteilung der Mittel nach medizinischen, volkswirtschaftlichen und auch organisatorischen Kriterien, die durch immer weitere Arten der Formalisierung repariert werden soll (a.a.O., S. 291 ff.).

Ein Element dieser Dynamik der fortschreitenden Formalisierung sind immer umfassendere und stärker integrierte Krankenhausinformationssysteme (KIS). Die Menge und Komplexität der Dokumentation, die die Formalisierung mit sich bringt, lässt sich ohne Informationstechnik in Krankenhäusern kaum verwalten. In der Wissenschaft wird der Begriff Krankenhausinformationssystem als „Oberbegriff für die Gesamtheit aller an den administrativen und klinischen Prozessen der Krankenversorgung beteiligten Systemen eines Krankenhauses“ (Gocke 2011, S. 151) verwendet. Diesem Verständnis nach sind sowohl Menschen als auch Maschinen Teil des KIS. In der Praxis wird jedoch als das KIS eines Krankenhauses meist nur die Gesamtheit der Informationssysteme bezeichnet; weder die Nutzer*innen noch die angeschlossenen medizinischen Geräte, die z. B. Diagnosedaten ins KIS einspeisen, sind dabei mitgemeint. In der vorliegenden Arbeit verwende ich den Begriff des Krankenhausinformationssystems in der weniger umfassenden Bedeutung, so wie ihn auch die Akteur*innen in meiner Fallstudie verwendet haben. Wenn hier von Krankenhausinformationssystem oder KIS geschrieben wird, ist also nur die Software gemeint. Herstellerinnen integrierter Krankenhausinformationssysteme wie der in der Fallstudie untersuchten Software eMed versprechen, dass ihre Produkte die neue Eindeutigkeit in der Krankenbehandlung steuerbar machen, indem sie die Informationen zusammenführen, die in den einzelnen Bereichen des Krankenhauses gesammelt und produziert werden. Diese Form von Software ist auf das neue, stärker ökonomisch und administrativ orientierte Krankenhaus und die standardisierte Krankenbehandlung zugeschnitten. Solche KIS werden auch von etablierten Herstellerinnen von integrierter Standardsoftware für Organisationen angeboten. In der Sanusklinik, deren OP-Planung in dieser Arbeit untersucht wird, wird mit eMed ein KIS genutzt, das auf der standardisierten Organisationssoftware der Firma SAP beruht.

4.1.2 Die chirurgischen Abteilungen in der Sanusklinik

Die Sanusklinik ist ein großes deutsches Universitätsklinikum mit über 7000 Mitarbeiter*innen und über 1000 Betten. Als Uniklinik weist sie gleichzeitig die organisatorischen Eigenheiten einer Hochschule und die eines Krankenhauses der Vollversorgung auf. Dies bedeutet zum Beispiel, dass viele der leitenden Mitarbeiter*innen der Sanusklinik Professor*innen sind, dass die Verbindung von Forschung und Lehre zu den Zielen gehört, die in der Organisation offiziell verfolgt werden sollen, und dass im Arbeitsalltag die Kooperation einer Vielzahl von medizinischen Expert*innen organisiert werden muss.

In der Sanusklinik gibt es mehr als zehn chirurgische Fachabteilungen und über vierzig Operationssäle an mehreren Standorten auf dem weitläufigen Gelände. Jeder der Fachabteilungen sind einige Operationssäle zugeordnet, in denen im Regelfall die Operationen stattfinden, für die die jeweilige Abteilung verantwortlich ist. Neben dem zentralen OP-Bereich, in dem mehr als die Hälfte der Säle liegen und in dem die meisten Fachabteilungen ihre Patient*innen operieren, gibt es kleinere Cluster von Sälen, in denen eine oder zwei Abteilungen ihr Tagesprogramm abarbeiten, sowie einzelne „Außenstellen“. Diese Säle sind einzeln über den Campus verteilt. Sie werden nur im Ausnahmefall für sterile Operationen genutzt und dienen in der Regel der Durchführung kleinerer Eingriffe unter Lokalanästhesie.

Beschäftigte, die Tätigkeiten im OP-Bereich ausführen, gehören verschiedenen Berufsgruppen an: Chirurg*innen, Anästhesist*innen, OP- und Anästhesiepflegekräfte führen gemeinsam Operationen durch und sind damit für das Kerngeschäft verantwortlich, Angehörige weiterer Berufsgruppen übernehmen Unterstützungsaufgaben wie Transport oder Reinigung. Die formelle Aufsicht über den Bereich obliegt der Person, die die Stelle der OP-Koordination besetzt.

Alle Ärzt*innen und Pflegekräfte sind hochgradig spezialisiert und müssen nach der beruflichen Grundausbildung (Medizinstudium bzw. Pflegeausbildung) zusätzliche Qualifikationen erwerben, bevor sie sich als vollwertige Mitglieder eines OP-Teams selbstständig an Operationen beteiligen dürfen. Da die Sanusklinik ein Lehr- und Ausbildungskrankenhaus ist, finden sich hier neben voll ausgebildeten und erfahrenen Ärzt*innen und Pflegekräften auch viele, die formal für die Weiterbildung notwendige oder nicht formal vorgeschriebene, aber für den weiteren beruflichen Aufstieg nützliche Erfahrung mit komplexen Operationen sammeln müssen. Unter den Chirurg*innen herrscht eine relativ hohe Fluktuation: mit Berufserfahrung aus einer renommierten Klinik ist es oft einfacher, an anderen Krankenhäusern aufzusteigen und eine Stelle als Abteilungsleiter*in zu finden, als in die Leitungsebene der chirurgischen Abteilungen der Sanusklinik aufzurücken, in der viele Stellen von Habilitierten besetzt werden.

Chirurg*innen sind den Abteilungen nach Spezialisierung zugeordnet. Jede Abteilung wird von einer Chefärzt*in geleitet. Diese ist formal zwar dem Vorstand der Sanusklinik untergeordnet, faktisch jedoch keinerlei direkten Weisungen unterworfen, wenn es um interne Angelegenheiten ihrer Abteilung geht. Die Chefärzt*in trifft zwar grundlegende medizinische und organisatorische Entscheidungen über ihre Abteilung, überlässt aber die alltäglichen Aufgaben, die mit der Leitung der Abteilung einhergehen, in der Regel einer oder mehreren ausgewählten Oberärzt*innen, den sogenannten leitenden Oberärzt*innen. Jeder chirurgischen Abteilung ist eine Abteilung der OP-Pflege zugeordnet, an deren Spitze eine erfahrene Pflegekraft steht. Diese Position, die diese Pflegekraft besetzt, heißt in der Sanusklinik „OP-Leitung“, und diese Positionsbezeichnung wird im Alltag auch genutzt, um die Leiter*innen der Abteilungen der OP-Pflege zu bezeichnen. Pflegerische und chirurgische Abteilungen sind einander zwar zugeordnet, aber entsprechen sich nicht eindeutig: Einige Abteilungen der OP-Pflege versorgen mehr als eine chirurgische Abteilung, andere sind personell getrennt, arbeiten aber unter der gleichen Leitung. Außerdem wird zwischen den pflegerischen Abteilungen bei Engpässen Personal ausgetauscht, was zwischen den chirurgischen Abteilungen niemals geschieht. Die Anästhesie ist als übergreifende Dienstleistungsabteilung für die gesamte Klinik organisiert, Anästhesist*innen betreuen also nicht nur Operationen, sondern setzen z. B. auch Narkosen bei diagnostischen Untersuchungen oder Geburten. Jeder großen chirurgischen Abteilung ist eine eigene Einheit der Anästhesie zugeordnet. Die Leiter*in dieser anästhesistischen Einheit wird Blockleiter*in genannt (Abbildung 4.1).

4.1.3 Vorgeschichte: Einführung von eMed und Reorganisation

Im Jahr 2006 entscheidet der Vorstand der Sanusklinik, dass die IT vereinheitlicht werden soll. Eine Projektgruppe aus Mitgliedern verschiedener klinischer und administrativer Abteilungen und Mitarbeiter*innen des zentralen IT-Service wird beauftragt, ein Krankenhausinformationssystem auszuwählen, das möglichst viele der Anforderungen der administrativen und klinischen Bereiche erfüllen soll. Das Team entscheidet sich für das KIS eMed, einerseits, weil es standardisierte Module für die meisten Arbeitsprozesse anbietet, andererseits, weil es den IT-Expert*innen der Sanusklinik viele Möglichkeiten bietet, organisationsspezifische Anpassungen für die Software selbst zu programmieren. Die Einführung des KIS beginnt 2007 in den administrativen Abteilungen und wird im folgenden Jahr schrittweise auf die klinischen Abteilungen ausgeweitet.

Die Vereinheitlichung der IT stellt nur eines der Ziele der Softwareeinführung dar. Das KIS ist Teil einer größeren Reorganisation, die sowohl die Effizienz der Arbeitsprozesse als auch die Qualität der Dokumentation erhöhen soll. Die Dokumentation der Krankenbehandlung ist für die Klinik in zweierlei Hinsicht bedeutsam: juristisch, weil alle Aspekte der Krankenbehandlung strengen rechtlichen Regeln unterliegen und unvollständige oder falsche Dokumentation hohe Haftungsrisiken mit sich bringt. Finanziell, weil die Kliniken von den Kostenträger*innen (in der Regel Krankenkassen) nur die Teile der Behandlung abrechnen können, die formal dokumentiert sind. Die Reorganisation der chirurgischen Abteilungen ist in dieser Hinsicht besonders wichtig, denn Operationen gehören zu den kostspieligsten und gewinnträchtigsten Leistungen, die im Krankenhaus erbracht werden. Im Zuge der Reorganisation wird mit dem OP-Bereich eine neue organisatorische Einheit oberhalb der einzelnen chirurgischen Abteilungen geschaffen. Die chirurgischen Abteilungen sollen durch die Zusammenführung in einer eigenen organisatorischen Einheit zum Informationsaustausch, zur Zusammenarbeit und zum sparsamen Umgang mit den kostspieligen OP-Ressourcen bewegt werden.

Vor der Einführung arbeiten die Mitarbeiter*innen der einzelnen chirurgischen Abteilungen größtenteils unabhängig von denen aller anderen chirurgischen Abteilungen. Jede Abteilung verfügt über eigene Säle, eigene Pflegekräfte und ein eigenes Budget. Wenn das Tagesprogramm in einer Abteilung abgearbeitet ist, stehen ihre Säle leer. Wenn an einem Tag zu viele Operationen anfallen, werden die, die an diesem Tag nicht mehr erledigt werden können, auf einen anderen Tag verschoben. Ausschließlich die Verantwortlichen in den Abteilungen entscheiden darüber, wer Zugang zu „ihren“ Sälen hat. Die aktuellen OP-Pläne kennen außerhalb der Abteilung nur die Mitarbeiter*innen der Anästhesie, die übergreifend an Operationen in allen chirurgischen Abteilungen teilnehmen. Die für die Einführung des KIS verantwortliche Mitarbeiterin des IT-Service erinnert sich: „Das war damals unbedingt so gewünscht, weil man sollte sich nicht gegenseitig […] in die Karten kucken“. Der Betrieb von Operationssälen ist teuer, Operationen bringen oft hohe Erlöse und die Sanusklinik hat keinen Mangel an Patient*innen, die operiert werden müssen. Für Patient*innen, die lange auf Operationen warten müssen, für Mitarbeiter*innen einzelner Abteilungen, die ständig Überstunden machen, um den Rückstand abzuarbeiten, und für den Vorstand der Sanusklinik, aus deren Budget Säle und Personal finanziert werden, ob sie genutzt werden oder nicht, ist die Autonomie der Abteilungen ein Problem.

Über das OP-Modul des KIS wird eine einheitliche Plattform für die OP-Pläne geschaffen. Die Pläne werden zwar weiterhin innerhalb der Abteilungen erstellt, sind aber über eMed für alle Mitglieder des OP-Bereichs sichtbar. Die verschiedenen Programme, die in den Abteilungen für die OP-Planung eingesetzt werden, werden abgeschaltet, die Planung in eMed wird verpflichtend. Auch die Dokumentation der Operationen, bei der wichtige Arbeitsschritte und verwendete Materialien und Medizinprodukte festgehalten werden, muss nun in eMed erfolgen.

An der Spitze des gemeinsamen OP-Bereichs wird eine neue Stelle geschaffen, die der OP-Koordination. Die Inhaber*in dieser Position soll die Zusammenarbeit zwischen allen für Operationen relevanten Abteilungen koordinieren, soll dafür sorgen, dass die Ressourcen im neu geschaffenen OP-Bereich effizient genutzt und bedarfsgerecht zwischen den Abteilungen verteilt werden. Außerdem soll sie sicherstellen, dass alle Arbeiten vorschriftsmäßig dokumentiert werden. Sie besitzt dazu über eMed Zugriff auf die OP-Pläne und –Dokumentationen aller Abteilungen. Einsicht in alle Pläne haben durch die neue Software auch die übrigen Mitglieder der chirurgischen Abteilungen. Unter diesen gilt es jedoch als bekannt, dass die OP-Pläne in eMed nur eingeschränkt den tatsächlichen Stand der Planung wiedergeben. Kurzfristige Planänderungen, wie sie zum Beispiel bei Notoperationen geschehen, können in der allgemein verfügbaren Ansicht nicht abgebildet werden. Auch Verschiebungen in den Startzeiten, die entstehen, wenn Operationen länger dauern oder früher enden, als ursprünglich geplant, sind in der Übersicht nicht erkennbar. Zur Zeit der Erhebung besetzt Dr. Mosser^{Footnote 2}, ein Mediziner mit Leitungserfahrung, aber kein Chirurg, die Position der OP-Koordination. Er soll auf der einen Seite langfristig die Zusammenarbeit und den Informationsaustausch in und zwischen den chirurgischen Fachabteilungen so verbessern, dass Einnahmen steigen und Kosten gesenkt werden. Dazu berichtet er dem für die Krankenversorgung verantwortlichen Vorstandsmitglied über das Geschehen im OP-Bereich und berät es bei strategischen Entscheidungen. Auf der anderen Seite vermittelt er im Alltag zwischen den Abteilungen, die für Operationen notwendige Leistungen erbringen und wirkt darauf hin, dass die Mitglieder des OP-Bereichs eMed wie vorgesehen für Planung und Dokumentation nutzen. Er organisiert den Austausch von Personal und Sälen zwischen Abteilungen, die Engpässe und Überhänge haben, zum Beispiel weil eingeplantes Personal ausfällt oder an einem Tag weniger Operationen anfallen als üblich. Außerdem achtet er darauf, dass die formalen Regeln des Klinikvorstands eingehalten werden.

Die Mitglieder des Vorstands verlassen sich nicht allein auf den Einfluss des OP-Koordinators, sondern setzen auch auf finanzielle Anreize, um die Abteilungen zur effizienteren Nutzung von Ressourcen und zur Nutzung von eMed zu bewegen: Auch nach der Reorganisation bleibt die Budgethoheit bei den chirurgischen Abteilungen. Die Abteilungsleiter*innen handeln mit dem Vorstand der Sanusklinik das Jahresbudget ihrer Abteilung aus. Der Vorstand setzt die formalen Regeln fest, die für die Verteilung des Budgets gelten, und trifft die Entscheidung über die Budgetverteilung im Einklang mit diesen Regeln. Das Budget der Abteilungen wird an die Einnahmen geknüpft, die diese für das Krankenhaus generieren.^{Footnote 3} Auch die Kosten, die die Arbeit in einer Abteilung nachweislich verursacht, werden berücksichtigt.^{Footnote 4} Grundlage für die Berechnung der Einnahmen und Kosten sind die Daten aus eMed, die von der Controllingabteilung überprüft und (unter anderem) für die Verwendung in den Budgetverhandlungen aufbereitet werden.

4.2 OP-Planung und -Dokumentation mit eMed

Das Modul eMed OP für die Planung und Dokumentation der Prozesse im OP-Bereich wird 2009 in einer einzigen Abteilung, der allgemeinen Chirurgie, eingeführt. Diese fungiert als Pilotabteilung. In Vorbereitung auf die Pilotphase findet der größte Teil des Customizing des OP-Moduls in der allgemeinen Chirurgie statt. Chirurgie und Pflege werden im Customizingteam durch Mitglieder der allgemeinen Chirurgie und der ihr zugeordneten Abteilung der OP-Pflege repräsentiert. Bei den Anpassungen des Standardsystems in Bezug auf die OP-Planung und –Dokumentation orientieren sich die am Customizing beteiligten daher stark an den Arbeitsabläufen, die in der allgemeinen Chirurgie bereits vor der Einführung von eMed etabliert waren. Die Details dieser Abläufe werden in 4.2.2 beschrieben.

Die flächendeckende Einführung von eMed OP in der Chirurgie dauert bis 2013. Einzelne Einführungsprozesse beginnen damit, dass die Verantwortliche für eMed OP aus dem IT-Service Kontakt mit der Person aufnimmt, die für die operative Leitung der Abteilung zuständig ist. In der Regel ist dies die leitende Oberärzt*in. Diese entscheidet dann, wer sich auf Seiten der Abteilung wie an der Einführung beteiligt und ob die Abteilungsleiter*in in den Einführungsprozess einbezogen werden soll.

Fr. Senger (IT-Service): Die Chefs haben sich sehr unterschiedlich involviert. Es gibt sehr konservative Chefs, die das überhaupt nicht interessiert, die wollen nur, dass das funktioniert und machen, sprechen nur über ihren Oberarzt sozusagen und es gibt aber auch Chefärzte, die da sehr wohl dran Anteil nehmen. […] normalerweise reden die [Chefärzt*innen, DA] mit irgendwem im [IT-Service] nicht unmittelbar.

Bevor das Modul in einer neuen Abteilung eingeführt wird, können Repräsentant*innen der Abteilung eigene Anpassungen an die Software mit den für die Einführung Verantwortlichen im IT-Service aushandeln. Mögliche Anpassungen sind jedoch von vorneherein begrenzt, erstens durch die Standardsoftware selbst, zweitens durch die im Customizing unter den Beteiligten ausgehandelten allgemeinen Rahmenbedingungen des Softwareeinsatzes und drittens durch die Parameter, die durch formale Organisationsregeln als verbindlich für diesen Einsatz festgesetzt worden sind. Die Abteilungen machen unterschiedlich stark von dieser Möglichkeit Gebrauch; im Ergebnis unterscheiden sich die Varianten vor allem in Details der Benutzer*innenoberfläche sowie darin, welche Angaben zum Eingriff bei der Anmeldung von Operationen verpflichtend sind. Wer zum Beispiel eine Operation in der Augenchirurgie anmelden will, muss die zu operierende Körperseite zwingend mit angeben. In der Neurochirurgie hingegen sind Angaben zur Körperseite optional. Auch die Berechtigungen zum Umgang mit dem System sind sehr unterschiedlich verteilt. Die Rechtevergabe schwankt zwischen restriktiv (nur wenige ausgewählte Mitglieder der Abteilung und die Pflegeleitung können im System planen) und permissiv (alle Chirurg*innen und Sekretär*innen der Abteilung und die zugeordneten Pflegekräfte haben Planungsrechte).

4.2.1 Das allgemeine Handlungsproblem in der OP-Planung

Das allgemeine Handlungsproblem der OP-Planung ist die Zuordnung von Patient*innen mit Operationsbedarf zu Operationszeiten und Ressourcen, die für die Operation nötig sind. Zu den Ressourcen zählen qualifiziertes Personal, Operationssäle, für den Eingriff notwendige Arbeitsmittel wie Röntgengeräte, Spezialbesteck oder Lagerungsvorrichtungen sowie Verbrauchsmaterialien wie Blutkonserven, Medikamente, Implantate und ähnliches. Bei der OP-Planung handelt es sich also auf den ersten Blick vor allem um ein Koordinationsproblem: Der OP-Plan für einen Tag soll sicherstellen, dass einerseits alle Patient*innen, die operiert werden müssen, möglichst adäquat behandelt werden. Der korrekte Eingriff muss dazu von Mediziner*innen und Pflegekräften mit der passenden Qualifikation durchgeführt werden. Notwendige technische Geräte und Materialien müssen zum richtigen Zeitpunkt am richtigen Ort zur Verfügung stehen. Zur adäquaten Behandlung gehört auch die Vermeidung unnötiger Wartezeiten vor, während und nach der Operation sowie die den Bedürfnissen der Patient*in entsprechende Nachsorge, also zum Beispiel eine Unterbringung auf der Intensivstation im Anschluss, falls dies medizinisch geboten ist. Andererseits soll durch die OP-Planung auch sichergestellt werden, dass die Kapazitäten des Krankenhauses optimal ausgelastet werden. Dies bedeutet, dass der OP-Plan so gestaltet werden soll, dass alle Operationssäle während des Tages kontinuierlich gefüllt sind und alle Mitglieder des OP-Bereichs ihre Arbeitszeit produktiv im Sinne ihrer jeweiligen Aufgabenbeschreibung nutzen können.

In allen Krankenhäusern, in denen regelmäßig Operationen durchgeführt werden, findet irgendeine Art von OP-Planung statt. Wie diese Aufgabe konkret ausgestaltet ist, unterscheidet sich aber von Krankenhaus zu Krankenhaus. In der Sanusklinik variieren Arbeitsschritte, Verantwortliche, Vorgaben, zeitliche Zusammenhänge, Verbindlichkeit der Ergebnisse und andere Spezifika des Planungsprozesses bereits zwischen den Abteilungen stark. Dennoch lassen sich allgemeine Aussagen zur OP-Planung treffen, die unabhängig von den konkreten Praktiken überall dort gelten, wo Operationen zum Alltag gehören und zumindest einige der Ressourcen begrenzt sind, die zu ihrer Durchführung notwendig sind:

Damit eine Operation auf den OP-Plan gesetzt werden kann, muss zuerst bei einer Patient*in konkreter OP-Bedarf festgestellt werden. Dazu ist eine Untersuchung durch eine Chirurg*in nötig. Konkreter OP-Bedarf liegt vor, wenn feststeht, dass die Patient*in in einem definierten Zeitraum innerhalb der nächsten Tage operiert werden soll. Bei Patient*innen, deren Operationen Wochen oder Monate im Voraus geplant wurden, wird erst dann von konkretem OP-Bedarf gesprochen, wenn sie im Krankenhaus aufgenommen und von einer Chirurg*in untersucht worden sind. Jeden Tag wird eine Gruppe Patient*innen mit konkretem OP-Bedarf ausgewählt, die am Folgetag operiert werden soll.^{Footnote 5} Es wird festgelegt, in welcher Reihenfolge die Operationen stattfinden sollen, was im Detail zu tun und wer dafür verantwortlich ist. Der OP-Plan des Folgetags mit mindestens diesen Informationen (Reihenfolge, Patient*innen, genauer Eingriff, Verantwortliche) wird erstellt und auf irgendeine Art in der Gruppe der Beteiligten bekannt gemacht.

Die zentrale Unsicherheit des Handlungsproblems liegt in der Frage, welche Operationen anstehen werden. Aus den logistischen Anforderungen der OP-Planung ergeben sich weitere potentielle Unsicherheiten, die zu großen Teilen durch das Krankenhaus vorstrukturiert werden. Stellen- und Dienstpläne, Materiallager und Betriebszeiten für OP-Säle, Hierarchien und Sanktionen bilden den Rahmen, in dem sich die Unsicherheiten der OP-Planung entfalten.^{Footnote 6} Das Verhältnis zwischen dem Operationsaufkommen und den durch diese Rahmenbedingungen vorgegebenen grundsätzlichen Kapazitäten, mit der jede Planende arbeiten kann, macht die grundlegenden Unsicherheiten des Handlungsproblems zu organisatorischen Ungewissheitszonen, die in den konkreten Handlungssystemen jeweils leicht unterschiedlich aussehen können.

In der Sanusklinik bildet eine chirurgische Abteilung mit den ihr zugeordneten Pflege- und Anästhesieteams ein solches Handlungssystem, da die Spiele, die die Mitglieder dieser Teams und der Abteilung spielen, untereinander verkettet sind. Die Akteur*innen dieser drei Gruppen sind es, die die tägliche Planung direkt beeinflussen. Was in anderen Bereichen der Klinik geschieht (z. B. Transportdienst, Lager etc.) haben die Planenden bei der Planung nicht im Blick; diese Bereiche funktionieren nach eigenen Regeln – für die Planung ist nur wichtig, dass sie meistens so funktionieren wie erwartet.

Die dargestellten Grundelemente des Handlungsproblems der OP-Planung werden in den einzelnen Handlungssystemen der Sanusklinik in unterschiedlichen Praktiken und damit auf unterschiedliche Weise bearbeitet. In allen wird der OP-Plan des Folgetages jeden Morgen von (mindestens) den Oberärzt*innen im Dienst besprochen. Große Unterschiede zwischen den Abteilungen gibt es in drei Punkten: Erstens, welche Informationen der vorläufige Plan bereits enthält, zweitens, wie er genau zu Stande kommt und drittens, welche Funktion seine Besprechung hat, also ob sie allein der Information der Anwesenden dient oder Inhalte des Plans dort nur diskutiert oder auch (regelmäßig oder nur in Ausnahmefällen) verändert werden. Vor oder nach dieser Besprechung werden weitere Informationen in den Plan eingefügt, die für die Vorbereitung der Operationen wichtig sind. Dazu gehören zum Beispiel der zugeordnete OP-Saal, besondere Instrumente oder Materialien, die Art der Narkose, die Lagerung, also wie die Patient*in auf dem Operationstisch platziert werden soll, und die vorgesehene Nachsorge. Den fertigen Plan erhalten Anästhesie und OP-Pflege, in der Sanusklinik formell bis zum Mittag des Vortags. In beiden Abteilungen wird auf Basis der Informationen des Plans das Personal für den jeweiligen Tag eingeteilt. Eine Anästhesist*in besucht am Vortag die Patient*innen, um die Narkose zu besprechen, um festzulegen, welche Medikamente gegeben werden und um die schriftliche Einwilligung für den Eingriff einzuholen.^{Footnote 7} Die eingeteilten Pflegekräfte beschaffen direkt vor der OP die benötigten Materialien, bauen sie im Saal auf und informieren die Mediziner*innen, dass ihre Operation bald ansteht. Die Anästhesist*in bestellt die Patient*in beim Transportdienst, damit diese genau dann im OP ankommt, wenn es Zeit für die Vorbereitung ist. Im OP-Vorraum wird die Patient*in dann von Pflegekräften vorbereitet und von der Anästhesist*in in Narkose gelegt. Erst wenn sie schläft, wird sie in den OP-Saal gefahren. Aus Sicht der Chirurg*innen beginnt die Operation zu diesem Zeitpunkt (mit dem Schnitt) und endet, sobald die Wunde verschlossen ist (mit der Naht). Für die Planung müssen jedoch auch die Vor- und Nachbereitungszeiten (Ausleitung der Narkose, Überführung der Patient*in, Saalreinigung) mitbedacht werden.

Die in den Abteilungen der Sanusklinik eingesetzten Varianten von eMed unterscheiden sich in den zu Beginn von 4.2 dargestellten abteilungsspezifischen Details. Das Modell der OP-Planung in eMed bildet die allgemeinen Grundelemente des Handlungsproblems für alle einheitlich ab. Um bei der Analyse der Spiele die Modelle des Organisierens als technische Bedingungen berücksichtigen zu können, wird nun als erstes vorgestellt, wie der Prozess der OP-Planung in diesem Modell aussieht.

4.2.2 Modell der OP-Planung in eMed nach dem Customizing

Das Modell der OP-Planung, das beim Customizing für alle Abteilungen festgelegt worden ist, ist für diese Arbeit aus Interviews und dem Nutzerhandbuch der Klinik rekonstruiert worden. Der Prozess folgt in diesem Modell in weiten Teilen der Prozessvorlage aus der generischen Version von eMed und wird im Folgenden beschrieben (vgl. auch Abbildung 4.2).

Eine Nutzer*in (die Veranlasser*in) fordert eine Operation für eine Patient*in an, indem sie in eMed einen OP-Auftrag für die zuständige chirurgische Abteilung (zuständige Organisationseinheit) erstellt. In diesem Auftrag hält sie fest, welcher Eingriff aufgrund welcher Diagnose durchgeführt werden soll. Sie fügt alle Informationen hinzu, die sie über die Patient*in erhoben hat und die für die Operation relevant sein könnten, und speichert den Auftrag in der Software. Die Veranlasser*in kann zwar einen Termin für die Operation vorschlagen, die Entscheidung darüber, ob der Terminvorschlag angenommen wird, liegt jedoch bei der Planer*in. Die Software prüft, ob alle Pflichteingaben für einen OP-Auftrag vorhanden und alle Eingaben im richtigen Format sind. Ist dies der Fall, speichert die Software den Auftrag als bestätigt. Der Auftrag erscheint nun in der Auftragsübersicht der zuständigen Abteilung und kann dort von der Planer*in gesehen werden. Die Planer*in legt sowohl den Termin als auch die vermutliche OP-Dauer (die sogenannte Planzeit), den Saal und alle anderen Daten fest, die in der Abteilung als Pflichteingaben für den OP-Plan vorgegeben, im Auftrag aber noch nicht enthalten sind. Der so vervollständigte OP-Auftrag wird automatisch in den Plan eingefügt und repräsentiert die Operation nun im System.

Der OP-Plan kann in eMed auf unterschiedliche Arten dargestellt werden: Die Planer*in kann die aktuell geplante Belegung der OP-Säle und alle angeforderten Operationen des Tages gleichzeitig einsehen und OP-Aufträge der Reihe nach Sälen zuordnen. Diese Planungsansicht ist für die meisten Mitglieder der Chirurgie nicht einsehbar, sie dient allein der Erstellung und Bearbeitung des Plans (Abbildung 4.3).

In der Plantafel, einer Kalenderansicht des ausgewählten Tages, werden die OP-Säle als Spalten dargestellt, die geplanten Operationen als Blöcke. Die Ausdehnung der Blöcke korrespondiert mit der bei der Planung angegebenen Operationszeit (Abbildung 4.4). Die OP-Säle, die in den Gebäuden der Sanusklinik nebeneinander liegen (vgl. 4.1.2), werden auch auf der Plantafel gemeinsam dargestellt; das Team, das am Customizing beteiligt war, hat sich gegen eine Gesamtansicht entschieden, die alle 40 Säle der Klinik auf einmal zeigt, da auf einem regulären Bildschirm die Pläne für maximal acht Säle gleichzeitig repräsentiert werden können. Die Plantafel stellt die Auslastung aller OP-Säle im Tagesverlauf grafisch dar. Die Planer*in kann die Blöcke, die Operationen repräsentieren, auf der Zeitleiste oder zwischen den Spalten, die für Säle stehen, verschieben und die Plantafel somit direkt zur Planung nutzen. Laut der Dokumentation der Standardversion von eMed ist die Plantafel vor allem für die Nutzung durch die Person vorgesehen, die für die gleichmäßige Auslastung der OP-Ressourcen verantwortlich ist. In der Sanusklinik wäre dies die OP-Koordinator*in.

Die Farbe der Blöcke zeigt an, ob eine Operation noch aussteht, bereits begonnen wurde oder schon abgeschlossen ist. Wenn laufende Operationen die geplante Zeit überschreiten, kann das zwar aus der Farbe der Blöcke gefolgert werden, die Ausdehnung der Blöcke in der Kalenderansicht verändert sich jedoch nicht. Die Plantafel ist für alle Mitglieder des OP-Bereichs sichtbar; bearbeiten kann diese Ansicht jedoch nur, wem die Abteilung Planungsrechte in eMed eingeräumt hat.

Ähnliches gilt auch für das laufende OP-Programm, wie die Listenansicht des OP-Plans in eMed bezeichnet wird. Hier sind die Operationen entsprechend der geplanten Reihenfolge untereinander aufgelistet (Abbildung 4.5). Im laufenden OP-Programm zeigen zwei Spalten an, in welchem Stadium die Operation gerade ist. In allen drei Ansichten werden die Operationen durch eine kleine Auswahl der Daten aus dem OP-Auftrag symbolisiert, die jede Abteilung selbst festgelegt hat.

Das laufende OP-Programm soll Nutzer*innen ermöglichen, von der Übersicht über die anstehenden Operationen aus die Ansicht zu öffnen, in der sich die OP-begleitende Dokumentation einer Operation erstellen lässt. In der Sanusklinik wird das laufende OP-Programm so genutzt: Zu Beginn der OP-Vorbereitung öffnet die dafür verantwortliche Pflegekraft den Auftrag für die anstehende OP, indem sie in der Liste auf die Zeile klickt, in der diese Operation repräsentiert ist. Darüber ruft sie ein Protokollformular auf, in dem sie während der Operation alle vorgeschriebenen Zwischenschritte dokumentiert. Die Operation wird als begonnen markiert, was in allen Ansichten des Plans sichtbar ist. Nach Abschluss der Operation benutzen auch Chirurg*innen und Anästhesist*innen die Spalte mit dem OP-Auftrag als Einstieg, um die jeweiligen medizinischen Dokumentationen in dafür vorgesehene Formulare einzutragen. Alle Dokumente werden Teil der Krankenakte der Patient*in.

Das laufende OP-Programm ist laut der Dokumentation von eMed nicht für die Planung entwickelt worden, sondern soll eigentlich einen bestehenden Plan repräsentieren. Hier können jedoch auch Veränderungen am Plan vorgenommen werden, soweit sie die angezeigten Parameter betreffen (z. B. kann der zugeordnete OP-Saal nach dem Öffnen des OP-Auftrags verändert werden, solange die Operation noch nicht begonnen hat). Auch Daten der geplanten Operation, die nicht in der Ansicht angezeigt werden, können von der Ansicht des laufenden OP-Programms aus geändert werden. Um dies zu tun, müssen Nutzer*innen jedoch immer erst den OP-Auftrag öffnen, indem sie auf die Zeile in der Ansicht klicken, in der dieser Auftrag repräsentiert ist. Darüber hinaus brauchen Nutzer*innen für solche Änderungen die passenden Berechtigungen. In den meisten Abteilungen besitzen alle Mitarbeiter*innen die Berechtigung, das laufende OP-Programm zu sehen, aber nur wenige die Berechtigung, OP-Aufträge zu verändern.

Der OP-Plan ist kein eigenständiges Element von eMed, sondern nur eine Ansicht, in der eine Sammlung einzelner Elementen auf eine bestimmte Art und Weise angezeigt wird. Das, was im Umgang mit eMed als OP-Plan behandelt wird, besteht in der Software aus mehreren auf unterschiedliche Arten dargestellten Listen von OP-Aufträgen. Der OP-Auftrag erweist sich als das erste relevante Softwareelement, das in allen mit der OP-Planung verbundenen Praktiken bedeutsam wird. Von der Beauftragung bis zur Abrechnung der Operation ändert sich zwar der Status, den der OP-Auftrag in eMed hat, der Auftrag bleibt aber an sich als Element erhalten. Dieses Element OP-Auftrag ist die im Customizing erstellte Variante der Datenstruktur Klinischer Auftrag im OP-Modul der Sanusklinik. Die Datenstruktur Klinischer Auftrag wiederum ist in eMed definiert, also das Produkt des Softwareentwicklungsprozesses, der außerhalb der Sanusklinik (und ohne Beteiligung ihrer Mitglieder) stattgefunden hat. Über klinische Aufträge wird die Behandlung von Patient*innen im Krankenhaus angestoßen, geplant und dokumentiert. Insbesondere werden die Daten aus den Voruntersuchungen der Patient*innen, die Plandaten der Operation und die Daten ihrer Dokumentation zusammen im klinischen Auftrag gespeichert und sind über diesen für Nutzer*innen gemeinsam verfügbar. Der klinische Auftrag fungiert damit als Verbindungsglied zwischen den verschiedenen Arbeitsprozessen rund um Operationen.

Bei der Untersuchung des Umgangs mit eMed in der OP-Planung zeigt sich, dass die technische Verbindung zwischen OP-Planung und OP-Dokumentation die zentrale Ursache für Veränderungen der Praxis mit eMed im Vergleich zur Praxis vor der Einführung des KIS ist. Während OP-Planung und OP-Dokumentation vorher technisch und organisatorisch nur lose gekoppelt stattfanden, koppelt der OP-Auftrag aus Sicht der Nutzer*innen im OP-Bereich beide Aufgaben nun eng aneinander. Diese enge Kopplung ist eine Folge des Zwecks, für den der OP-Auftrag im KIS vorgesehen ist: Durch den OP-Auftrag wird dafür gesorgt, dass alle Daten, die für die Planung, Durchführung, Dokumentation und Abrechnung einer Operation im Krankenhaus als relevant erachtet werden, nach der ersten Eingabe im KIS gespeichert und an alle weitergereicht werden, die mit einem dieser Vorgänge zu tun haben.

Die Operation selbst wird in der Software als eine Menge medizinischer Leistungen modelliert, ebenso wie alle begleitenden medizinischen Maßnahmen, wie Voruntersuchungen, Narkose, Pflegetätigkeiten und andere. Leistungen repräsentieren einzelne Tätigkeiten der medizinischen Akteur*innen und stellen damit ein Modell der Aufgaben dar, die diese Akteur*innen erfüllen, wenn sie Patient*innen behandeln. Diese Aufgaben sind in eMed doppelt modelliert: Medizinische Tätigkeiten werden in eMed gleichzeitig als Prozeduren und Leistungen abgebildet. Während Prozeduren der Dokumentation dienen, sind Leistungen für die Abrechnung gedacht. Über zwei unterschiedliche Softwareelemente werden in diesem Fall zwei unterschiedliche Sichtweisen auf die gleiche Tätigkeit repräsentiert. Beide Elemente werden zusammen generiert, d. h. stößt eine Nutzer*in zum Beispiel bei der Beauftragung einer Operation die Erstellung einer neuen Leistung an, so erzeugt die Software automatisch die dazugehörige Prozedur. Im weiteren Verlauf der Arbeit werde ich auf diese Doppelstruktur nur über das Element der Leistungen Bezug nehmen, denn die Sichtweise, die in den Leistungen repräsentiert ist, erwies sich bei der Untersuchung als besonders relevant für das Verständnis des beobachteten Geschehens im Fall. Leistungen werden nicht nur in Verbindung mit Operationen, sondern bei der gesamten Behandlung der Patient*innen erbracht. Leistungen und Klinische Aufträge stellen also unterschiedliche Modelle dar, die aber in der Software verknüpft sind.

Der OP-Auftrag ist in eMed an ein Element gebunden, das als Fall bezeichnet wird. Der Fall verknüpft alle Daten, die im Laufe des Behandlungsprozesses entstehen, miteinander und mit den anderen Daten, die im Krankenhaus über die Patient*in gespeichert sind (z. B. Adresse, Versicherungsnummer etc.). Durch den Fall sollen alle Aspekte des Aufenthalts einer Patient*in im Krankenhaus von Beginn an für die Organisation nachvollziehbar werden. Leistung, Fall und OP-Auftrag sind die Softwareelemente, die zentral für die Praktiken in und um die OP-Planung in der Sanusklinik sind. Der OP-Auftrag ist eng an die eigentliche OP-Planung geknüpft. Durch Statuswechsel (von „beauftragt“ zu „geplant“, „laufend“, „abgeschlossen“) bildet er die unterschiedlichen Stadien der Operation im Krankenhaus ab. Der Fall integriert die OP-Planung in die Modelle der übrigen medizinischen und administrativen Arbeitsabläufe der Organisation: Er verbindet die verschiedenen klinischen Aufträge (z. B. einen OP-Auftrag, aber auch Aufträge für Voruntersuchungen, Röntgen etc.), die im Rahmen eines Krankenhausaufenthalts erfüllt werden, miteinander und mit Patient*innendaten, die für die Verwaltung des Aufenthalts gebraucht werden. Über die Leistung schließlich werden die finanziellen Aspekte der Behandlung im Krankenhaus mit den prozessualen und medizinischen Sichten verknüpft.

4.2.3 Die Praxis der OP-Planung in der Sanusklinik

Theoretisch entsprechen die Arbeitsschritte und Anforderungen der OP-Planung für die allermeisten Operationen^{Footnote 8} denen, die in 4.2.1 beschrieben werden: Auswahl einer Gruppe von Patient*innen mit konkretem OP-Bedarf, Festlegung der genauen Eingriffe, Zuordnung von Sälen und Personal, Festlegung der Reihenfolge der Operationen an einem Tag, Bekanntmachung des Plans. Dadurch erscheint die OP-Planung auf den ersten Blick als eine vorhersehbare Aufgabe. In der Praxis setzen jedoch die Patient*innen und ihre unberechenbaren Krankheitsverläufe der Vorhersehbarkeit Grenzen: Patient*innen erscheinen beispielsweise am Vortag der Operation nicht wie geplant zur Einweisung oder erscheinen unerwartet in kritischem Zustand. Der Zustand von Patient*innen verschlechtert sich über Nacht und sie können daher gar nicht oder aber müssen viel schneller als geplant operiert werden. Den Chirurg*innen bietet sich nach dem Schnitt ein anderes Bild des Körperinneren, als die Diagnostik vermuten ließ. Kurz: Ausfälle, Notfälle^{Footnote 9} und Terminverschiebungen aus verschiedensten Gründen sind Teil der Routine der OP-Planung. Der Umgang mit ihnen gehört ebenso zu diesem allgemeinen Handlungsproblem wie die logistischen Anforderungen, die sich aus dem „ungestörten“ Ablauf ergeben.

Solche kurzfristigen Veränderungen des OP-Plans werden von der Planer*in mit der zuständigen Leiter*in der zugeordneten Teams der Pflege und Anästhesie abgesprochen. Wenn die Veränderung beschlossen ist, werden alle telefonisch informiert, die an der Operation beteiligt sind. Anders als bei den am Vortag geplanten Operationen wird die Änderung den übrigen Chirurg*innen weder aktiv mitgeteilt, noch haben diese Einfluss auf die Entscheidung. Sie erfahren davon nur, wenn sie sich den OP-Plan des aktuellen Tages in eMed ansehen und ihnen die Veränderung auffällt. Kleinere Verschiebungen im Tagesverlauf können aufgefangen werden: Die Leiter*in der OP-Pflege behält das Geschehen in den Sälen im Tagesverlauf im Blick und sorgt dafür, dass die für eine Operation eingeteilten Pflegekräfte mit der Vorbereitung beginnen, sobald der OP-Saal bereit ist, und alle anderen Beteiligten telefonisch informiert werden, wenn ihr Einsatz ansteht. Kurzfristig neu in den Plan aufgenommene Operationen führen aber dazu, dass andere Operationen auf einen Folgetag verschoben werden oder vorerst ganz aus der Planung fallen. Ausfälle gehen jeweils in den Planungsprozess eines Folgetags ein, ein neuer Termin wird also nicht automatisch festgelegt.

Dass die OP-Planung grundsätzlich ein Prozess voller Unsicherheit ist, ist bei allen Beschäftigten im OP-Bereich akzeptiert, denn „wir sind eben nicht bei der Post und auch nicht im Büro“ (OP-Leitung allgemeine Chirurgie). Wie damit umgegangen werden sollte und welche Ursachen im Einzelfall verantwortlich sind, ist Gegenstand regelmäßig wiederkehrender Konflikte innerhalb der und zwischen den verschiedenen Berufsgruppen. Diese drehen sich vor allem um die Frage, wer für Verschiebungen im Plan und deren Folgen wie das verlängerte Leiden von Patient*innen, deren Operationen kurzfristig verschoben werden, oder unerwartete Überstunden, die den Mitarbeiter*innen abverlangt werden, verantwortlich ist und ob diese hätten vermieden werden können. Klar ist, dass nicht alle Unsicherheiten der Planung von Patient*innen ausgehen: eine Pflegekraft, die für den Weg zu einem entfernten Saal 60 statt wie erwartet 20 Minuten braucht, Anästhesist*innen, die Anfragen auf Unterstützung beim Schichtwechsel nicht weitergeben, Chirurg*innen, die erst kurz vor dem Schnitt bekannt geben, dass der gleich beginnende Eingriff deutlich komplexer wird als im Plan angegeben – wie sehr der Tagesablauf im OP-Bereich mit dem übereinstimmt, was im OP-Plan festgelegt worden ist, hängt davon ab, wie gut die Planenden solche Störungen verhindern oder ausgleichen können. Die Analyse der Spiele in Abschnitt 4.4 wird zeigen, dass der Umgang mit eMed darauf großen Einfluss hat.

Das medizinische Personal im OP-Bereich schätzt es, dass eMed einen direkten Zugriff auf Patient*innendaten ermöglicht, arbeitet aber insgesamt ungern mit der Software. Sie wird als langsam und umständlich wahrgenommen und ist nur in den Sekretariaten überwiegend beliebt. Chirurg*innen, Pfleger*innen und Anästhesist*innen empfinden die Benutzer*innenoberflächen als unübersichtlich und die Prozessvorlagen als unnötig komplex; viele der Informationen, die die Software ihnen präsentiert oder von ihnen verlangt, erscheinen ihnen überflüssig für die Erfüllung ihrer Aufgaben. Die Reaktionen der Software auf Eingaben finden sie oft nicht nachvollziehbar.

Dr. Schmidt (Oberarzt Anästhesie): Für mich ist das ein Programm, was ich als faschistoid empfinde. […] Das Hauptproblem ist ja, dass es so viele Informationen sind, die ich gar nicht brauche. Das ist gar nicht darauf beschränkt, was für mich nötig ist.

Die Verpflichtung, bei der Planung und Dokumentation eMed einzusetzen, wird vor allem als Zusatzbelastung empfunden, die die Beschäftigten von ihrer eigentlichen Arbeit an den Patient*innen ablenkt. Chirurg*innen und Pflegekräfte haben in der Sanusklinik jedoch keine alternativen Möglichkeiten, um Pläne und medizinische Dokumente im Alltag mit all den Akteur*innen zu teilen, die darüber informiert sein müssen, wenn die Behandlungsabläufe funktionieren sollen. Sie können die Regeln der Sanusklinik, die eine Nutzung von eMed vorschreiben, nicht umgehen, wenn sie ihr Handlungsproblem lösen wollen. Keine andere Software wird von allen Akteur*innen genutzt, die koordiniert werden müssen, damit Operationen durchgeführt werden können. Bei der Koordination ganz auf Software zu verzichten ist erst recht nicht vorstellbar, denn die Akteur*innen sind räumlich über den Campus der Sanusklinik verteilt und müssen eine Menge an Detailinformationen austauschen, um sich zu koordinieren. Der Umgang mit der ungeliebten Software stellt immer noch die beste Möglichkeit dar, um das Handlungsproblem zu lösen. Vor allem die Planungsdaten und Teile der operationsbegleitenden Dokumentation sind jedoch extrem unzuverlässig; jede Abteilung hat eigene informelle Regeln dafür entwickelt, wie die Interpretationsspielräume, die den Nutzer*innen bei der Dateneingabe bleiben, auszulegen sind und welche Regelverstöße (v. a. die Eingabe formal korrekter, aber inhaltlich fehlerhafter Daten) wie sanktioniert werden. Einige dieser informellen Regeln werden bei der Analyse der Spiele in Abschnitt 4.4 vorgestellt.

Die Stelle der OP-Koordinator*in ist im Rahmen der Reorganisation entstanden, in der die formale Stellenstruktur des OP-Bereichs an das Modell der Organisation in der Standardversion von eMed OP angepasst worden ist. Der aktuelle OP-Koordinator nutzt allerdings nur wenige der für seine Stelle vorgesehenen Funktionen der Software. Eines der Hauptargumente der Softwareherstellerin für eMed OP ist, dass dieses Produkt sich dazu eigne, einen OP-Bereich zentral zu überblicken und zu steuern. Diese Behauptung verweist er in den Bereich der Phantasie. Statt eMed OP nutzt der OP-Koordinator den Plan der Anästhesist*innen, den diese in einer eigenen Software erstellen und selbstständig pflegen, um sich einen Überblick über das zu verschaffen, was im OP-Bereich vor sich geht.

Die Abteilung Anästhesie hat die formale Erlaubnis, eine andere Software als eMed für ihre internen Planung einzusetzen, weil die Standardversion von eMed keine Möglichkeit vorsieht, die OP-Pläne, die nur Operationen abbilden, mit den geplanten diagnostischen Untersuchungen, die ebenfalls von der Anästhesie betreut werden, in einer Gesamtübersicht zu vereinen. Die Blockleiter*innen, also die Leiter*innen der anästhesistischen Einheiten, die den einzelnen chirurgischen Abteilungen zugeordnet sind, benutzen nur diese Software, um den Überblick über das Geschehen im OP-Bereich und die Auslastung ihrer Mitarbeiter*innen zu behalten. Die Daten aus den OP-Aufträgen in eMed und kurzfristige Änderungen, von denen sie auf andere Weise erfahren, übertragen sie per Hand in das eigene System. Diese Übertragung verursacht erheblichen Arbeitsaufwand. Die Anästhesist*innen nehmen diesen jedoch in Kauf; die Software, mit der die Anästhesist*innen ihre Pläne erstellen, bietet im Gegensatz zu eMed eine Gesamtübersicht aller OP-Säle an. Diese zeigt zwar weniger Details zu den laufenden Operationen an, stellt aber dafür aktuelle Veränderungen in der Planung grafisch dar. Da die Anästhesist*innen in ihrer Software selbst eintragen, wann Operationen begonnen und beendet werden, ist die Übersicht in der Planungssoftware der Anästhesist*innen unabhängig von den verschiedenen Planungs- und Dokumentationspraktiken der chirurgischen Abteilungen.

Die Ausführungen der Abschnitte 4.1 und 4.2 geben die Erkenntnisse aus der ersten Analysephase wieder (vgl. Abschnitt 3.2.1 zur Beschreibung des Vorgehens). Es zeigt sich, dass die OP-Dokumentation seit der Einführung von eMed eng mit dem Handlungsproblem der OP-Planung verbunden ist. Das Modell der OP-Planung aus der Standardversion von eMed OP ist zu großen Teilen übernommen worden, wobei sich OP-Auftrag, Leistung und Fall als zentrale Elemente herauskristallisieren. Widerstände zeichnen sich vor allem daran ab, dass Akteur*innen im OP-Bereich Daten, die die OP-Planung vereinfachen könnten oder für eine vollständige Planung sogar unabdingbar wären, falsch oder gar nicht eingegeben. Sie werden aber auch daran erkennbar, dass die Mitarbeiter*innen der Anästhesie großen Aufwand aufbringen, um nicht mit eMed planen zu müssen, und dass der OP-Koordinator es ablehnt, die Überblicksfunktion der Software zu nutzen. Die zentralen Elemente und beobachteten Widerstände bilden den Ausgangspunkt für die Rekonstruktion der Modelle des Organisierens.

4.3 Modelle des Organisierens im Krankenhausinformationssystem

Über Modelle des Organisierens wird versucht, die Arbeitsprozesse in Organisationen auf einen einheitlichen Zweck auszurichten. Die Widerstände im Umgang mit der Software, die diese Modelle enthält, zeigen an, wenn Akteur*innen ihre Praxis nicht auf diesen Zweck ausrichten wollen oder können. Letzteres kann eine Folge von Widersprüchen zwischen verschiedenen Modellen des Organisierens in der Software sein oder aus Widersprüchen zwischen diesen Modellen und formalen Regeln der Organisation entstehen, die ebenfalls Versuche darstellen, Kontrolle über den Umgang der Organisationsmitglieder mit der Software auszuüben.

Durch Analyse der Online-Softwaredokumentation von eMed lassen sich einige der grundlegenden Zusammenhänge zwischen den Datenstrukturen und Prozessvorlagen rund um die zentralen Elemente für die OP-Planung und OP-Dokumentation rekonstruieren. Die interne Struktur des Krankenhaussystems lässt sich auf drei technische Ebenen abstrahieren. Diese sind (s. auch Abbildung 4.6):

(1)
Der generische Softwarekern der Standardsoftware, die die Firma SAP für Organisationen produziert. Dieser wird als ERP-Kern bezeichnet. (ERP steht hier als Abkürzung für Enterprise Resource Planning, eine häufig genutzte Bezeichnung für standardisierte Organisationssoftware).
(2)
Die Erweiterungsmodule für den Gesundheitssektor, die ebenfalls von der Firma SAP entwickelt werden. Diese sind unter der Abkürzung IS-H bekannt.
(3)
Eine Reihe an Ergänzungsmodulen für den Einsatz im Krankenhaus, die zusammen i.s.h.med genannt werden. Diese krankenhausspezifische Ergänzung ist kein Produkt von SAP, sondern wird von einem anderen Unternehmen angeboten. Erst durch i.s.h. med wird die gesamte Software zum Krankenhausinformationssystem.

Es zeigt sich, dass die Art, wie Unsicherheiten in den Modellen der Elemente OP-Auftrag, Leistung und Fall reduziert wird, innerhalb jeder der drei technischen Ebenen von eMed einer konsistenten Logik folgt. Diese Logiken werden in den folgenden drei Abschnitten beschrieben. Die Beschreibung wird auch zeigen, dass die Logiken der drei technischen Ebenen nicht vollständig miteinander vereinbar sind. Viele der Datenstrukturen und Prozessvorlagen, die beim Umgang mit der Software genutzt werden, lassen sich nicht eindeutig einer Ebene zuordnen, sondern setzen sich aus Elementen zusammen, die ihren Ursprung auf verschiedenen Ebenen haben. Dadurch entstehen Abhängigkeiten zwischen den Elementen, die die Ebenen mit ihren in sich konsistenten Logiken überschreiten. Die Zusammenhänge zwischen den Elementen folgen daher in einigen Arbeitsprozessen mehr der einen, in einigen mehr der anderen Logik. Modelle des Organisierens lassen sich aus den Ausschnitten der Dokumentation nicht direkt rekonstruieren. Zu diesem Zweck wurden Informationen über die sozialen Bedingungen, unter denen die Software entwickelt worden ist, zur Analyse hinzugezogen. Die technischen Ebenen können aus dieser „biographischen“ Perspektive (vgl. 2.2.3.2) leicht als Produkt verschiedener sozialer Systeme identifiziert werden. Diese sozialen Systeme sind relativ stabil, d. h. es handelt sich um dauerhafte Beziehungs- und Interaktionszusammenhänge, nicht nur um isolierte Softwareentwicklungsprojekte in einzelnen Organisationen. Aus ihrer Historie und Entwicklung lässt sich in Umrissen erkennen, welche Art der Kontrolle mit ihren Produkten über Organisationen ausgeübt werden soll.

4.3.1 ERP-Kern: Die Ebene der generischen Organisationssoftware

Enterprise Resource Planning-Systeme (ERP-Systeme) sind darauf ausgelegt, Informationen über die unterschiedlichen Arbeitsprozesse in einem Unternehmen zu integrieren (Davenport 1998). Die Integration erfolgt einerseits darüber, dass die Software Daten über die Arbeitsprozesse in einheitlicher Form verwaltet und in einer gemeinsamen Datenbank oder einer vergleichbaren Struktur so ablegt, dass eine einheitliche Datenbasis entsteht, auf der beim Umgang mit der Software in den Arbeitsprozessen zurückgegriffen wird. Andererseits werden die Arbeitsprozesse über Prozessvorlagen integriert, die vorgeben, welche Arbeitsschritte aufeinander folgen sollen und welche Daten in jedem Schritt in die gemeinsame Datenbasis eingegeben werden müssen und können. Eine gemeinsame Benutzer*innenoberfläche sorgt für ein einheitliches Erscheinungsbild, wodurch Nutzer*innen bei allen Arbeitsprozessen, die durch die Software unterstützt sind, auf ähnliche Art und Weise mit der Software umgehen können.^{Footnote 10} Das Ergebnis jeder Aktion in der Software, bei der Daten verändert werden, wird unmittelbar gespeichert und ist über die gemeinsame Datenbasis für alle Elemente der Software verfügbar (Hohlmann 2007). Damit enthält die gemeinsame Datenbasis – so die Theorie – ein genaues Abbild aller von der Software abgebildeten Prozesse der Organisation in Echtzeit. Ausgehend davon wird ERP-Systemen eine zweite Funktion zugeschrieben: Sie sollen dieses vollständige Abbild der Informationen über die Organisation zentral verfügbar machen, um dadurch Manager*innen die Steuerung der Organisation zu ermöglichen. ERP-Systeme dienen also sowohl der Integration als auch der Darstellung der Geschehnisse, die an verschiedenen Stellen einer Organisation zu unterschiedlichen Zeitpunkten stattfinden, in einer zentralen Ansicht. Diese zentrale Darstellung soll durch die Zusammenführung aller prozessproduzierten Daten möglich werden.

Was heute als Kernfunktion von ERP-Systemen betrachtet wird, ist ein Ergebnis der in den 1960er Jahren begonnenen Automatisierung der industriellen Produktion mit Hilfe von Mikroelektronik (Pollock und Williams 2009). ERP-Systeme haben ihren Ursprung in Software zur Lagerverwaltung, die allmählich erweitert wurde, um immer weitere Teile des Produktionsprozesses zu integrieren. In den Anfangsjahren der Entwicklung standen Planung und Steuerung des Produktionsprozesses im Vordergrund. Arbeitsprozesse jenseits der Fertigung wurden erst später integriert, indem die Software nach und nach um entsprechende Funktionen erweitert wurde. Der Fokus des modellierten Anwendungsbereichs verschob sich von der Fertigung auf die Organisation als Ganzes.^{Footnote 11} Mit der Erweiterung des Anwendungsbereichs veränderten sich auch die technischen Charakteristika: Die Softwareunterstützung verschiedener Aufgabenbereiche der Organisation wurde in fachspezifische Module aufgeteilt, deren technische Integration (also aneinander anschließende Prozessvorlagen und gemeinsame Datenbasis) die fachliche Integration (also aneinander anschließende Arbeitsprozesse mit geteilten Informationen) sicherstellen sollte. Ein Kennzeichen von ERP-Systemen wurde ihre Multifunktionalität (Klaus et al. 2000). Auch der ERP-Kern des Krankenhausinformationssystems eMed ist ein Ergebnis dieser Entwicklung.

Gleichzeitig wurden die Systeme immer stärker als Werkzeug von Manager*innen dargestellt (und wahrgenommen). Zweck dieses Werkzeugs war es, dass Manager*innen alles, was in der Organisation geschieht, mit der Software überblicken, nach erprobten Vorlagen umgestalten und steuern können sollten. Diese Verschiebung – von einem Hilfsmittel für die Automatisierung der Produktion zum Werkzeug für Organisationsgestaltung – lässt darauf schließen, dass sich einige der Zwecke, für die die Software konstruiert worden ist, und einige der Unsicherheitsreduktionen in den Modellen, die im Entwicklungsprozess eingesetzt worden sind, über die Zeit verändert haben. Diese Veränderungen spiegeln sich aber nur partiell im Code wider, zumindest nicht bei den größten Anbietern: „[T]he ERP offerings of the top five ERP vendors still use the kernel of MRPII functionality [also den Code, der die Kernfunktionen des rein produktionsorientierten Vorgängersystems erzeugt, D.A.] for the manufacturing planning portion of their systems (Chung and Snyder 2000)“ (Pollock und Williams 2009, S. 25). Werden Modelle in frühen Phasen des Entwicklungsprozesses verändert, diese Veränderungen aber in den Phasen, in denen Code produziert wird, nicht nachvollzogen (z. B. weil Codeteile aus alten Versionen ohne Anpassung in neue Versionen übernommen werden), so bleibt das performative Modell des Organisierens von den Kontrollversuchen geprägt, für die Software ursprünglich entwickelt worden ist.

Das in der Fallstudie als Teil des Krankenhausinformationssystems untersuchte ERP-System der Firma SAP ist eines der Produkte dieser fünf erfolgreichsten Anbieter*innen. Grundlegend für das Modell des Organisierens in dieser Software ist die „ablaufgesteuerte Prozessorientierung“ (Rolf et al. 1998): Das Modell der Organisation besteht dabei aus einer statischen Grundstruktur, der sogenannten Aufbauorganisation, und einer dynamischen Ebene, der sogenannten Ablauforganisation.

Im Modell der Aufbauorganisation sind alle Organisationseinheiten (OE) inklusive der dort angesiedelten Planstellen abgebildet. Die Elemente der Aufbauorganisation sollen funktionalen Einheiten der Organisation entsprechen. Der genaue Zuschnitt solcher Einheiten hängt dabei von der konkreten Organisation ab. Organisationseinheiten in der Software können sowohl Werksstandorte repräsentieren als auch Abteilungen, Arbeitsgruppen oder ähnliches. Technisch gesehen enthält das Modell der Aufbauorganisation im ERP-System nicht nur die eine Abbildung der statischen Grundstruktur der Organisation, die hier beispielhaft genannt ist und in der Organisationseinheiten aufgabenspezifisch bestimmt werden. Sie besteht zusätzlich noch aus mehreren andere Modellen. In diesen anderen Modellen wird die statische Grundstruktur der Organisation zum Beispiel aus einer buchhalterischen Perspektive dargestellt. In diesem Fall bilden Kostenstellen die Organisationseinheiten im Modell und die gesamte Aufbauorganisation ist anders strukturiert als im ersten Fall. Unterschiede zwischen verschiedenen Perspektiven ergeben sich zum Beispiel, wenn die Ausgaben mehrerer Abteilungen über eine gemeinsame Kostenstelle abgerechnet werden oder Mitarbeiter*innen der gleichen Arbeitsgruppe ihre Kosten je nach Aufgabe über unterschiedliche Kostenstellen abrechnen. Beim Customizing werden die unterschiedlichen Modelle aufeinander abgebildet. Zur Laufzeit, also wenn Organisationsmitglieder die Software nutzen, wird dann jederzeit automatisch der richtige Bezug, z. B. zwischen der Abteilung, ihren Kostenstellen, Mitarbeiter*innen und zugeordneten Aufgaben, hergestellt (vgl. SAP AG 2001, D.8.16.2.1, S. 8–32).

Das Modell der Ablauforganisation setzt sich aus den Modellen der einzelnen Geschäftsprozesse zusammen. Die Software enthält Prozessvorlagen, also generische Kombinationen aus Elementen, die einzelne Prozessschritte (z. B. Wareneingang, Warenprüfung, Warenannahme) repräsentieren sollen. Im Modell jedes Prozessschritts sind notwendige und mögliche Eigenschaften definiert (z. B. beim Wareneingang Warentyp, Menge, Datum, Lieferant*in etc.), ebenso wie mögliche Verantwortlichkeiten (z. B. beim Wareneingang eine Person, die die Ware entgegennimmt) und eine Reihenfolge (z. B. beim Wareneingang immer vor der Warenprüfung). Auch die Prozessvorlagen müssen beim Customizing bearbeitet werden, zum Beispiel, indem entschieden wird, welche Geschäftsprozesse mit welchen Einzelschritten in der jeweiligen Organisation überhaupt zum Einsatz kommen (ob z. B. Wareneingang, Warenprüfung und Warenannahme einzeln unterschieden werden oder alles, was nach der Anlieferung von Waren geschieht, in einem Prozessschritt abgebildet werden soll), welche der Eigenschaften übernommen werden (z. B. welche Warentypen in der Organisation angenommen werden) und wer konkret für welche Schritte verantwortlich sein soll (ob es z. B. eine Lagerist*in gibt oder die Ware bei einer Pförtner*in abgegeben wird). Vor der Inbetriebnahme wird außerdem jeder Schritt in den Prozessen innerhalb der Ablauforganisation einem oder mehreren Elementen der Aufbauorganisation eindeutig zugeordnet und kann damit zur Laufzeit in der Organisation „lokalisiert“ werden (SAP AG 2001).

Der ERP-Kern von SAP soll durch diese Strukturen alle statischen und dynamischen Elemente der Organisation und alle Veränderungen der Beziehungen zwischen ihnen zu jeder Zeit vollständig abbilden. Um diesem Anspruch gerecht werden zu können, wird eine unüberschaubare Menge an Einzeldaten produziert und gespeichert. Während für die Integration der Arbeitsprozesse jeweils nur eine kleine Auswahl dieser Daten notwendig ist, ist die gewaltige Datenmenge, die von der Software produziert wird, immer dann ein Problem, wenn sich Nutzer*innen einen Überblick über einen Aspekt des Geschehens in der gesamten Organisation verschaffen wollen. Dies ist im ERP-Kern über Berichte möglich, die den Nutzer*innen eine vorstrukturierte Auswahl der Daten aus der von ihnen gewählten Perspektive zeigen (SAP AG 2001). Die Auswahl, Ausgestaltung und Neuanlage solcher Berichte ist ein wichtiger Teil der meisten Customizingprozesse.

Aufbau- und Ablauforganisation werden zusätzlich über sogenannte Module in betriebswirtschaftliche Funktionsbereiche eingeteilt, zum Beispiel Materialverwaltung, Personalverwaltung, Controlling o.ä. (mehr dazu bei Hohlmann 2007). Module bündeln Funktionalitäten und stellen funktionsspezifische Standardberichte bereit. Abbildung 4.7 zeigt die Architektur des ERP-Kerns mit den angegliederten Modulen.

Bei der Entwicklung der ersten Version ihrer ERP-Software setzte die Firma SAP ihr Produkt durch eine bis dahin ungewöhnliche zweite Sicht auf die Organisation von den Produkten der Konkurrenz ab, die auch in der später entwickelten Version R/3 (und der in der Fallstudie untersuchten Weiterentwicklung mit der Bezeichnung ERP) noch eine zentrale Position einnimmt: Alle Informationen in der gemeinsamen Datenbasis werden einerseits als Elemente der Arbeitsprozesse modelliert, die sie hervorbringen, andererseits als Elemente der Finanzflüsse innerhalb der Organisation (Hohlmann 2007). Durch die parallele Modellierung dieser beiden unterschiedlichen Sichten ist es möglich, das Abholen von Materialien aus dem Lager sowohl als Bewegung von Gütern aus einer Abteilung in die andere zu betrachten als auch als Verschiebung von finanziellen Werten zwischen internen Kostenstellen. In beiden Fällen kann konkret festgestellt werden, welche Mitarbeiter*in der Organisation die Aktion durchgeführt hat oder an ihr beteiligt war. Jeder Arbeitsschritt kann damit (je nach Modellierung) einem oder mehreren Mitarbeiter*innen zugerechnet werden. Jede Tätigkeit in der Organisation, die in irgendeiner Form in der Software abgebildet ist, wird dadurch automatisch finanziell bewertet. Theoretisch, d. h. entsprechend der Vorstellung vom Umgang mit der Software, die in dem Modell zum Ausdruck kommt, lässt sich über den ERP-Kern die gesamte Organisation in Echtzeit aus der Perspektive des Rechnungswesens darstellen.

Dieses finanzielle Modell der Organisation erlaubte es den Entwickler*innen der ersten Version von SAP, viele der unterschiedlichen Geschäftsprozesse nach einer einheitlichen Logik zu integrieren, nämlich der des Rechnungswesens (Mormann 2016). Bei der Entscheidung, die Daten, mit denen das Geschehen in der Organisation abgebildet werden sollte, in Echtzeit zu verarbeiten, orientierten sich die Entwickler*innen allerdings nicht an fachlichen Anforderungen von Vertreter*innen des Rechnungswesens, sondern nur an den vorhandenen technischen Möglichkeiten: „Die SAP-Entwickler boten […] eine technische Lösung für ein organisatorisches Problem an, das bislang überhaupt nicht als Problem identifiziert worden war“ (a.a.O., S. 59). Im Rechnungswesen wurden die finanziellen Werte, die im Unternehmen umgesetzt werden, traditionell im Nachhinein zu festen Zeitpunkten bilanziert. Eine ständige Betrachtung der Wertveränderungen als „Finanzströme“ war den Vertreter*innen des Rechnungswesens fremd (a.a.O.). Dieses für die Funktionalität von ERP-Systemen heute zentrale Merkmal lässt sich eher aus einer Dominanz der naturwissenschaftlich-technisch orientierten Entwickler*innen gegenüber den Repräsentant*innen der Anwender*innen in den frühen Auseinandersetzungen um die Modelle der ersten SAP-Version erklären als aus genuinen Anforderungen der intendierten Nutzer*innen (a.a.O.).

Insgesamt ist das ERP-Kernsystem das Ergebnis einer Vielzahl teilweise höchst kontroverser Aushandlungen zwischen Akteur*innen innerhalb und zwischen sozialen Systemen (Mormann 2016; Hohlmann 2007; Pollock und Williams 2009). Aus diesen Auseinandersetzungen ist eine Software hervorgegangen, in deren Modellen der Versuch zum Ausdruck kommt, „die“ Organisation „an sich“, also alle (in der Vorstellung der an der Entwicklung Beteiligten) relevanten Aspekte aller Arten von Organisationen aus mehreren Perspektiven mit Hilfe einer möglichst hohen Anzahl an Detailinformationen darzustellen. Die Funktionsbereiche des ERP-Kerns, die in jeder konkreten Variante der Software enthalten sind, die in irgendeiner konkreten Organisation genutzt wird, umfassen das Betriebsmodul, das Finanzmodul und das Personalmodul (Boeder und Groene 2014). Erweiterungen^{Footnote 12} gibt es sowohl für zusätzliche Aufgabenbereiche wie die Integration von Daten, die von Zuliefer*innen übermittelt werden, als auch für verschiedene Branchen, wie Gesundheitswesen oder Einzelhandel. Solche branchenspezifischen Erweiterungen fügen Vorlagen für die Aufbau- und Ablauforganisation sowie für typische Geschäftsprozesse hinzu, verändern aber die Strukturen des ERP-Kernsystems nicht, sondern nutzen sie für die als allgemein angesehenen Aufgaben. Das Modell des Organisierens im Kernsystem bleibt unabhängig von der konkreten Installation erhalten. In diesem Modell des Organisierens besteht eine Organisation aus wohldefinierten, hierarchisch geordneten statischen Einheiten wie zum Beispiel Abteilungen oder Kostenstellen. Diese nehmen veränderbare Einheiten aus der Umwelt, wie zum Beispiel Materialien und Vorprodukte, auf und reichen diese einander so lange in klar vorbestimmten Schritten weiter, bis sie wieder an die Umwelt abgegeben werden. Die Prozesse, in denen Mitglieder von Organisationseinheiten auf diese Art die Produkte der Organisation herstellen, sind vollständig transparent und können mit Hilfe der von der Software erhobenen und gesammelten Daten einfach von Manager*innen gesteuert werden. Der Zweck, auf den dieses Modell des Organisierens die Organisation ausrichten soll, ist die kosteneffiziente, fehlerfreie und zentral vom Leitungspersonal der Organisation beherrschbare Produktion standardisierter Güter. Das Modell des Organisierens im Kern entspricht damit einem kapitalistischen Ideal informationstechnisch integrierter Industrieproduktion.

4.3.2 IS-H: Die Ebene der Erweiterung der generischen Software für das Gesundheitswesen

Die Erweiterung von SAP ERP für das Gesundheitswesen basiert auf der von SAP entwickelten Komponente IS-H, die um zusätzliche, von anderen Firmen entwickelte Module (wie i.s.h.med) erweitert werden kann. Nach Peter Haas und Klaus Kuhn (2011) lässt sich ein KIS aus Anwender*innensicht in drei logische Teilsysteme zerlegen, die über ein Kommunikationssystem miteinander und mit einem elektronischen Zentralarchiv in Verbindung stehen: Das administrative Informationssystem beinhaltet alle Funktionen, die für die Verwaltung der Organisation und die Unterstützung der logistischen Prozesse notwendig sind. Das medizinische Informationssystem dient der Organisation und Dokumentation der Behandlung und der Pflege und das Patient*innenendatenverwaltungssystem führt die administrativen, medizinischen und organisatorischen Daten zusammen, die die Mitarbeiter*innen des Krankenhauses brauchen, um Behandlungen durchzuführen, abzurechnen und im Einklang mit bestehenden Gesetzen nachzuweisen. Im Krankenhausinformationssystem der Sanusklinik erfüllt IS-H die Funktionen des Patient*innendatenverwaltungssystems, des administrativen Systems und des Kommunikationssystems. Die in IS-H enthaltenen Modelle werden also beim Umgang mit der Software relevant, wenn durch das, was mit der Software getan wird, administrative Arbeitsprozesse berührt werden (also sehr häufig, wie sich noch zeigen wird). Die Elemente, über die diese administrativen Arbeitsprozesse im Modell des Organisierens von IS-H abgebildet sind, lassen sich auf zwei Quellen zurückführen: Erstens enthält IS-H Datenstrukturen und Prozessvorlagen, die eigens für Krankenhäuser entwickelt wurden. Diese krankenhausspezifischen Modelle repräsentieren zum Beispiel Elemente der Behandlung und sind im Zuge der Entwicklung von IS-H eigens für die Software modelliert worden. Zweitens finden sich in IS-H auch Datenstrukturen und Prozessvorlagen, die auf generischen Elementen aus dem ERP-Kern aufbauen. Diese Datenstrukturen und Prozessvorlagen sind das Ergebnis einer Spezifizierung der generischen Elemente, die ebenfalls im Zuge der Entwicklung von IS-H durchgeführt worden ist. Ein Beispiel ist die Organisationsstruktur: In IS-H ist das Grundmodell aus dem ERP-Kern konkretisiert, indem eine Hierarchie von Organisationseinheiten bereitgestellt wird, wie sie im Krankenhaus erwartbar sind: Im Modell der Klinik finden sich als Organisationseinheiten mehrere Fachabteilungen (wie z. B. die allgemeine Chirurgie) und deren Unterabteilungen (z. B. allgemeinchirurgischen Ambulanz, Station und Intensivstation). Diesen Organisationseinheiten sind, ebenso wie im ERP-Kern, dann bauliche Einheiten zugeordnet, Kostenstellen und Leistungen, die dort erbracht werden können. Durch solche Spezifizierungen nehmen die Entwickler*innen von IS-H einen Teil der Aufgaben vorweg, die in Krankenhäusern beim Customizing erledigt werden müssten, wenn dort das ERP-System von SAP ohne die Erweiterung für das Gesundheitswesen eingesetzt werden sollte. Die Mitarbeiter*innen eines Krankenhauses, in dem das ERP-System von SAP und IS-H gekauft worden ist, müssen beim Customizing zum Beispiel nicht mehr selbst definieren, dass jede ihrer chirurgischen Abteilungen eine eigene Ambulanz, eine Station und eine Intensivstation hat, sondern die chirurgischen Abteilungen nur noch konkret benennen und die auswählen, in denen es abweichend von der Regel keine eigene Ambulanz (o.ä.) gibt. Die Unterschiede zwischen den Organisationen des Gesundheitssektors und denen der Industrie, an denen der ERP-Kern sich orientiert, kommen vor allem im Modell der medizinischen Arbeitsprozesse und in dem Modell der Patient*in zum Ausdruck.

Die medizinischen Arbeitsprozesse werden in IS-H vor allem durch die Kombination von Behandlungselementen modelliert, die Prozeduren genannt werden (vgl. auch die Erläuterung dazu auf S. 172). Prozeduren werden im Modell eines medizinischen Arbeitsprozesses im Anschluss an eine Diagnose durchgeführt. Prozeduren werden in der Software gleichzeitig auch als Leistungen abgebildet, die von den Organisationseinheiten erbracht und später mit den Kostenträger*innen abgerechnet werden. Wie das ERP-Kernsystem enthält auch IS-H damit parallele Datenstrukturen, die es erlauben, die medizinischen Arbeitsprozesse im Krankenhaus sowohl (als Prozeduren) aus einer (bei der Softwareentwicklung als solche konstruierten) medizinischen als auch (als Leistungen) aus einer (ebenfalls bei der Softwareentwicklung so konstruierten) buchhalterischen Perspektive zu betrachten. Konkrete Diagnosen, Prozeduren und Leistungen sind den größtenteils gesetzlich vorgeschriebenen Katalogen entnommen, die von den Organisationen der gemeinsamen Selbstverwaltung des Gesundheitssystems und dem Gesundheitsministerium in Anlehnung an internationale medizinische Standards definiert werden. Diagnosen und Prozeduren entstammen dem ICD-10 bzw. dem OPS-Katalog, die beide in Anlehnung an die Klassifizierung der WHO im dem Bundesgesundheitsministerium untergeordneten „Deutschen Institut für medizinische Dokumentation und Information“ entwickelt werden (DIMDI 2019). Leistungskataloge sind je nach dem Behandlungsmodus (stationär/ambulant) und nach Art der Kostenträger (z. B. gesetzliche Versicherung, Privatversicherungen) unterschiedlich (SAP AG o. J.d, D3, S. 98–108) und werden zwischen verschiedenen korporativen Akteur*innen ausgehandelt.^{Footnote 13} Die Abrechnung selbst orientiert sich an dem System der Fallpauschalen (SAP AG o. J.d), das ebenfalls im Detail von den Kollektivakteur*innen des Gesundheitssystems definiert wird und gesetzlich vorgeschrieben ist (Feißt und Moltzberger 2016).

Während in der normativen gesellschaftlichen Vorstellung vom Krankenhaus die Patient*in als Empfänger*in der Behandlung im Mittelpunkt steht (Rohde 1974, S. 234 ff.), spielt sie im Modell des Organisierens in IS-H nur eine Nebenrolle. Im Modell, über das die Patient*in in IS-H abgebildet wird, werden zwar administrative und medizinische Daten über die jeweilige Patient*in zusammengeführt. Dieses Modell taucht beim Umgang mit der Software aber nur selten auf. Das zentrale Element in der Ablauforganisation von IS-H ist der Fall.

Über das Modell des Falls wird der Aufenthalt einer Patient*in im Krankenhaus repräsentiert. Dazu werden deren Bewegungen^{Footnote 14} innerhalb der Aufbauorganisation in einer Datenstruktur, eben dem Fall, zusammengefasst. Über den Fall werden Daten der Patient*in mit Daten über die Arbeitsprozesse verknüpft.^{Footnote 15} Anders als bei den Elementen der Behandlung (Prozeduren/Leistungen) und beim Modell der Patient*in (administrative/medizinische Daten) bildet der Fall in IS-H weder eindeutig eine medizinische noch eine buchhalterische Perspektive auf das Geschehen in der Organisation ab. Es findet sich in IS-H auch kein dem Fall entsprechendes paralleles Element, mit dem der Aufenthalt der Patient*in aus einer anderen Perspektive betrachtet werden könnte, die die des Falls in irgendeiner Weise spiegeln würde. Stattdessen werden die für das Krankenhaus gleichermaßen relevanten, aber unterschiedlichen Perspektiven, die medizinische und die buchhalterische, in einem Element zusammengeführt. Damit entspricht diese Struktur in IS-H den in 4.1.1 beschriebenen Standards der Finanzierung des Gesundheitssystems: Fallkategorien (DRGs) „gruppier[en] Fälle, die klinisch homogen sind und annähernd die gleichen Ressourcen verbrauchen“ (SAP AG o. J.d). Auch bei der medizinischen und pflegerischen Dokumentation sowie bei den Berichten, die das Krankenhausinformationssystem erzeugt, steht der Fall im Mittelpunkt (SAP AG o. J.d).

Obwohl diese Verbindung von Medizin und Rechnungswesen mit der Modellierung des Falls beabsichtigt ist, zeigt sich bei genauerer Betrachtung, dass im Modell des Falls primär die buchhalterische Perspektive auf die Behandlung abgebildet wird. Fälle dienen in IS-H explizit dem Zweck, die im Krankenhaus erbrachten Leistungen mit den Kostenträger*innen abzurechnen (SAP AG o.J.b). Im Modell des Falls werden die Unsicherheiten des Krankenhausaufenthalts der Patient*in, die beim Umgang mit der Software eine Rolle spielen, also so reduziert, dass die Kosten des Aufenthalts am Ende möglichst vollständig abgerechnet werden können. Andere Aspekte der Unsicherheit des Krankenhausaufenthalts sind im Modell des Falls kaum berücksichtigt. Ebenso sieht es in den anderen Modellen aus, die extra für IS-H entwickelt worden sind: Sie modellieren vor allem die Abrechnung und die Verwaltung von Patient*innen, nicht aber Spezifika der medizinischen Arbeitsprozesse. Die Funktionalitäten, die sich in IS-H für die Unterstützung der Arbeitsprozesse finden, entsprechen größtenteils generischen Funktionalitäten für die Produktionsplanung und – steuerung (z. B. Materialeingang, Transport, etc.), die im ERP-Kern bereits enthalten sind. Andere Funktionalitäten von IS-H dienen der Überführung der Prozessdaten in die Module für Controlling und Materialwirtschaft, die Teil des ERP-Kerns sind (SAP AG o. J.d). Die übrigen Aufgabenbereiche des Krankenhauses werden vollständig von den Standardmodulen des ERP-Kerns abgedeckt. Das Modell des Organisierens in IS-H entspricht somit größtenteils dem im ERP-Kern. Es unterscheidet sich vor allem dadurch, dass die Organisation im Modell des Organisierens in IS-H andere Produkte herstellt als die im Modell des Organisierens im ERP-Kern: Die Organisation, die im ERP-Kern repräsentiert ist, ist ein generisches Industrieunternehmen, in der Mitarbeiter*innen Materialien, die Kostenstellen zugeordnet sind, zu standardisierten Produkten zusammenfügen. Diese werden an Kund*innen verkauft, was dem Unternehmen Erlöse einbringt. Die Organisation, die in IS-H repräsentiert ist, gleicht diesem Industrieunternehmen in den Grundzügen. Die Mitarbeiter*innen der in IS-H modellierten Organisation nehmen allerdings nicht nur Materialien und ähnliche Gegenstände aus der Umwelt auf, sondern auch Patient*innen, die genauso wie die Materialien im Industrieunternehmen als Ressourcen für verschiedene Produktionsprozesse dienen. In diesen Produktionsprozessen, die denen des generischen Industrieunternehmens so sehr ähneln, werden keine physischen Gegenstände, sondern standardisierte Fälle hergestellt, wobei die Patient*innen als wichtigstes Vorprodukt von Prozessschritt zu Prozessschritt weitergereicht werden, bis die Fallproduktion abgeschlossen ist. Die fertigen Fälle werden dann für Fallpauschalen an Kostenträger*innen verkauft. IS-H, die Erweiterung des generischen ERP-Systems von SAP für den Gesundheitssektor, weicht fast ausschließlich durch Datenstrukturen und Prozessvorlagen von der generischen Grundform ab, die für das Rechnungswesen im Gesundheitssektor relevant sind. Die als medizinisch deklarierten Elemente gleichen strukturell den generischen Elementen und unterscheiden sich nur in ihren Bezeichnungen von diesen. Die Spezifika der Organisationen im Gesundheitswesen werden damit in IS-H auf Besonderheiten des Rechnungswesens reduziert. Die medizinischen Arbeitsprozesse, die in der Software modelliert sind, werden dadurch einer Kontrolle durch die Logik des Rechnungswesens unterworfen.

4.3.3 i.s.h.med: Die Ebene der Ergänzung für Krankenhäuser

i.s.h.med ist eine Erweiterung von IS-H, die vollständig in die SAP-Software für Krankenhäuser integriert ist, aber nicht von SAP selbst stammt, sondern von einer Reihe an wechselnden Unternehmenspartner*innen (weiter)entwickelt wird (Hoeksma 2009). In der Sanusklinik deckt i.s.h.med primär die Aufgaben eines medizinischen Informationssystems ab.^{Footnote 16} Anders als IS-H, bei dem ein Schwerpunkt auf die Neugestaltung der administrativen Arbeitsprozesse gelegt wurde, werden in i.s.h.med vor allem Arbeitsprozesse neu modelliert, die primär von medizinischem Personal im klinischen Alltag ausgeführt werden (SAP AG o. J.a). Dazu erweitert i.s.h.med Datenstrukturen und Prozessvorlagen, die in IS-H erstmalig definiert oder aus dem ERP-Kern übernommen und konkretisiert worden sind, um zusätzliche Parameter. Solche Parameter ermöglichen es zum Beispiel den Nutzer*innen, Daten nach den Kriterien einzelner Fachdisziplinen strukturiert einzugeben und anzuzeigen (z. B. Anzahl der Geburten bei Patientinnen in der Gynäkologie, aber nicht bei Patient*innen der Neurologie) oder die Leistungserbringung auf bestimmte Mitarbeiter*innen oder Organisationseinheiten zu beschränken (z. B. als Verantwortliche für Operationen keine Mitarbeiter*innen der Psychiatrie zuzulassen) (SAP AG o. J.a). Mit i.s.h.med sollen die medizinischen Prozesse im Krankenhaus aus medizinischer Perspektive abgebildet werden: Nicht Kosten oder Haftungsfragen, sondern das, was Ärzt*innen und Pfleger*innen wissen müssen, um den Patient*innen die richtige Behandlung zukommen zu lassen, soll in der Software modelliert werden. Dieser Anspruch wird an den detaillierten Vorlagen für die Arbeit in einzelnen Fachabteilungen ebenso erkennbar wie an der Modellierung der Zusammenarbeit zwischen diesen. Das zentrale Element dieser Modellierung sind Klinische Aufträge.

Mit einem Klinischen Auftrag werden medizinische Informationen zu einer Patient*in zwischen den Organisationseinheiten ausgetauscht, wenn Mitarbeiter*innen aus einer Organisationseinheit bei Mitarbeiter*innen der anderen Organisationseinheit eine Behandlung anfordern. Der Auftrag kann zu Beginn ohne Verknüpfung zu bestimmten Leistungen erstellt werden, die aus buchhalterischer Perspektive für den Arbeitsprozess relevant sind, aber nicht aus medizinischer (denn aus dieser stehen die Prozeduren im Vordergrund) (SAP AG o. J.a). Während der Behandlung werden die Daten, die das Personal bei der Erfüllung seiner Aufgaben in das auf die Logik ihrer Fachdisziplin zugeschnittene Teilmodul von i.s.h.med eingibt, mit Hilfe des Klinischen Auftrags miteinander verknüpft und von i.s.h.med automatisch um die administrativ notwendigen Elemente ergänzt. In der Online-Softwaredokumentation von i.s.h.med wird angegeben, dass das medizinische Personal den Arbeitsprozess rein aus der medizinischen Perspektive betrachten kann, wenn es klinische Aufträge nutzt, um die Zusammenarbeit mit Hilfe des Krankenhausinformationssystems zu koordinieren (a.a.O.). In dieser Angabe aus der Online-Softwaredokumentation, die hier beispielhaft genannt wird, um zu verdeutlichen, wie die Software in diesen Dokumenten beschrieben wird, zeigt sich der Zweck, dem i.s.h.med der offiziellen Darstellung zufolge dienen soll. In dieser Ergänzung der standardisierten Organisationssoftware für Krankenhäuser wird die Koordination der unterschiedlichen Teilaufgaben des Behandlungsprozesses mit ihren je speziellen Eigenlogiken in den Mittelpunkt gestellt. Auf dieser technischen Ebene des Krankenhausinformationssystems findet sich keine eigenständige Funktionalität für die administrativen Aspekte des Krankenhauses. Sie ist dezidiert dafür entwickelt worden, die beiden vorgelagerten technischen Ebenen (ERP-Kern und IS-H) zu ergänzen (Siemens AG 2009).

Die Modelle, in denen diese medizinische Perspektive auf die Arbeit im Krankenhaus zum Ausdruck kommen soll, haben nur wenig Auswirkung auf das Modell des Organisierens, das den Umgang mit dem KIS eMed in der Praxis beeinflusst. Der Grund dafür ist, dass das Modell des Organisierens in i.s.h.med nicht nur durch die Modelle bestimmt wird, die bei der Entwicklung dieser technischen Ebene neu geschaffen worden sind, sondern sehr stark durch die Modelle der vorgelagerten Ebenen vorstrukturiert wird. In i.s.h.med allein wird nur ein Teil einer Organisation repräsentiert; grundlegende Elemente, die Teil der Modelle der Arbeitsprozesse in i.s.h.med sind, werden mitsamt ihrer Funktionslogik aus dem ERP-Kern oder aus IS-H übernommen. Beispiele dafür sind die Prozeduren und Leistungen und die Unterteilung der Organisation in Untereinheiten, die in den Klinischen Aufträgen angefordert werden. Solche Elemente von anderen technischen Ebenen sind in den Modellierungsprozessen für i.s.h.med übernommen worden, haben sich im Code abgelagert und steuern zur Laufzeit von eMed viele der Funktionen der Software. Der Klinische Auftrag kann zwar als zentrales Element von i.s.h.med betrachtet werden. Er ist jedoch immer an einen Fall gekoppelt, welcher weiterhin in der Logik von IS-H verbleibt, in der das Krankenhaus als eine Art „Fabrik für Fälle“ vor allem aus buchhalterischer Perspektive dargestellt wird. Der Fall wird auch in i.s.h.med an vielen Stellen genutzt, um Daten zu sortieren, auszuwählen und darzustellen. Von der Anzeige der Patient*innendaten bis zu den medizinischen Berichten, die in i.s.h.med definiert sind, bleibt die Fallorientierung der Arbeitsprozesse dominant. Damit werden die Unsicherheiten der Krankenbehandlung auch über i.s.h.med immer wieder so reduziert, dass vor allem den Anforderungen an eine vollständige Abrechnung der Arbeit genüge getan wird. Die Orientierung an den Patient*inneninteressen auf medizinisch adäquate Behandlung kommt nur in einzelnen, speziell für i.s.h.med konstruierten Modellen, zum Ausdruck.

Hinzu kommt, dass i.s.h.med eine Ergänzung zu IS-H darstellt und kaum Elemente der anderen Software ersetzt. Wenn eMed in ein Krankenhaus eingeführt wird, müssen alle Aufgaben, die für die Einführung von i.s.h.med notwendig sind, zusätzlich zu den Aufgaben erfüllt werden, die bei der Einführung von IS-H anfallen. Das bedeutet vor allem, dass zusätzlicher Arbeitsaufwand beim Customizing entsteht, wodurch zusätzliche Kosten anfallen und zusätzlicher Bedarf an Aushandlungen (mit dem entsprechenden Konfliktpotential) entsteht. Das Customizing der Elemente aus IS-H bleibt notwendig, um die generischen Aspekte des Krankenhausinformationssystems so weit zu konkretisieren, dass es lauffähig wird. Viele dieser Konkretisierungen sind unabdingbar, wenn die Software genutzt werden soll: Organisationseinheiten unterschiedlicher Art (Abteilungen, Kostenstellen etc.) müssen bestimmt, benannt und einander zugeordnet werden, konkrete Mitarbeiter*innendaten müssen eingegeben, Nutzer*innenkonten müssen angelegt werden und so weiter, damit die Software irgendwelche Funktionen erzeugt. Im Gegensatz zu diesen unabdingbaren Aufgaben sind die Anpassung und Aktivierung der Funktionalitäten von i.s.h.med beim Customizing optional. Jede Entscheidung für eine Funktionalität von i.s.h.med erzeugt dadurch zusätzliche Komplexität beim Umgang mit der Software in einer Arbeitsumgebung, die auch ohne diese Funktionalität bereits hochkomplex ist: Fachspezifische Arbeitsprozesse müssen differenziert vordefiniert, von Nutzer*innen erlernt und regelmäßig so ausgeführt werden, dass die Software ihren Zweck im Arbeitsprozess erfüllen kann.

Beim Customizing in der Sanusklinik ist auf viele der möglichen Funktionalitäten verzichtet worden, wie Abschnitt 4.2.2 gezeigt hat. Die wenigen i.s.h.med-spezifischen Anpassungen sind in den meisten Fällen optional. Entweder haben sich abteilungsspezifische Regeln dafür herausgebildet, oder ihre Interpretation ist den Nutzer*innen freigestellt. Wie im folgenden Abschnitt sichtbar wird, sind solche optionalen zusätzlichen Anforderungen in den Aushandlungen um die Praxis des Umgangs mit dem KIS besonders einfach zu umgehen.

4.4 Das konkrete Handlungssystem der OP-Planung

Während die technischen Strukturen der drei generischen Ebenen des KIS unabhängig von den Gegebenheiten in der Sanusklinik beschrieben werden können, ist die Software, die in der alltäglichen Praxis genutzt wird, das Ergebnis des Customizings und der abteilungsspezifischen Anpassungen. Die Praktiken im Umgang mit eMed unterscheiden sich zwischen den Abteilungen, da zwar alle in die gleiche lokale Ordnung der Sanusklinik eingebunden sind, aber im Alltag relativ unabhängig voneinander arbeiten (vgl. 4.1.2 und 4.1.3). Die einzelnen Abteilungen müssen daher in einer strategischen Organisationsanalyse der OP-Planung als eigene Handlungssysteme betrachtet werden.

OP-Planung ist in allen Abteilungen eine relevante Aufgabenstellung; vor allem das Verhältnis von Routine- und Notfalloperationen und damit die Dynamik des OP-Plans und die generelle Auslastung der verfügbaren OP-Ressourcen variiert. In den Abteilungen für allgemeine und für spezielle Chirurgie,^{Footnote 17} die im Folgenden verglichen werden, sind mehrere Disziplinen organisatorisch zusammengefasst. Während in einigen Disziplinen dringende Eingriffe eher die Ausnahme darstellen (z. B. Urologie oder Orthopädie), kommen sie in anderen Abteilungen häufiger vor (z. B. Neuro-, Herz-, oder Unfallchirurgie). In einigen Abteilungen fallen regelmäßig mehr Operationen an, als mit den verfügbaren Kapazitäten an einem Tag erledigt werden können, in anderen ist das Verhältnis ausgeglichener. In der Allgemeinen und in der Speziellen Chirurgie gibt es eine ähnliche, relativ hohe Notfallquote. Notfälle sind in beiden Abteilungen häufig auch lebensbedrohlich. Die OP-Pläne sind dementsprechend in beiden Abteilungen sehr dynamisch. Zusätzlich übersteigt das Operationsaufkommen in beiden Abteilungen regelmäßig die Kapazitäten. In beiden Abteilungen darf regelhaft auch außerhalb der Kernzeiten, also vor allem nach dem Ende der Tagschicht um 16 Uhr, operiert werden, allerdings nur in einem gewissen, genau festgelegten Umfang.

Um das Thema Operationen herum bildet sich ein Ensemble von Unsicherheiten unterschiedlichen Ursprungs, unterschiedlicher Relevanz und unterschiedlicher Möglichkeiten, diese zu kontrollieren. Das Operationsaufkommen bildet auch in der Sanusklinik die größte Unsicherheit der OP-Planung. Die Kontrolle darüber, welche Operationen anstehen, liegt außerhalb des OP-Bereichs. Die Informationskanäle, über die Mitarbeiter*innen des OP-Bereichs von neuen Operationen erfahren können, bilden damit eine der zentralen organisatorischen Ungewissheitszonen der Handlungssysteme. Auch die Unsicherheiten der Logistik sind durch die Organisation vorstrukturiert: Wenn im Tagesverlauf mehr Operationen anfallen, als mit den verfügbaren Kapazitäten erledigt werden können, liegt es meist daran, dass mit Personal besetzte OP-Säle fehlen. Die Gründe dafür sind strukturell: Die Sanusklinik hat insgesamt ein hohes Operationsaufkommen, aber nur wenige räumliche Puffer und wenig zusätzliches Personal, das Krankheits- und Urlaubszeiten ausgleichen kann. Ungewissheitszonen liegen damit im Zugang zu Sälen und in der Verfügbarkeit von Personal.

Die Ungewissheitszone „Verfügbarkeit von chirurgischem Personal“ wird stark über die Profession mitstrukturiert: In der professionellen Identität von Chirurg*innen ist angelegt, dass sie jederzeit einsatzbereit sind und sich der Autorität der ranghöheren Chirurg*innen weitgehend unterwerfen.^{Footnote 18} Auch in der Sanusklinik ist diese professionelle Identität regelmäßig handlungsleitend; Chirurg*innen mögen unglücklich mit den Ergebnissen der Planung sein, folgen aber in der Regel dem OP-Plan und passen sich damit an die Vorgaben der Planer*innen an. Sie sind gleichzeitig auch die Hauptakteur*innen im Spiel um die Planung, denn die Erstellung des OP-Plans liegt in der Hand der Chirurgie und ist zentral mit allen anderen Spielen in den chirurgischen Abteilungen verbunden.

Anders sieht dies bei Pflegekräften und Anästhesist*innen aus. In der professionellen Hierarchie der Medizin stehen beide Gruppen unter den Chirurg*innen (mit deutlichen Unterschieden in der Distanz); in der Organisation bilden sie außerdem eigenständige Abteilungen mit anderen Spielen im Innen- und Außenverhältnis. Die Mitglieder beider Gruppen berufen sich in der Sanusklinik aktiv auf ihr Recht auf verlässliche Arbeitszeiten und versuchen diese weniger im Planungsspiel, sondern eher durch Spielzüge in anderen Handlungssystemen durchzusetzen, in denen das Machtgefälle zur Chirurgie weniger stark ins Gewicht fällt. Besonders umkämpft ist im Klinikum die Einhaltung der Betriebszeiten der OP-Säle. Weniger als zehn der über 50 Säle dürfen nach dem regulären Ende der Arbeitszeit am späten Nachmittag noch für Operationen genutzt werden. Die Betriebszeiten sollen eine verlässliche Personalplanung in den Servicebereichen, also unter anderem in Pflege und Anästhesie, ermöglichen. In beiden Bereichen gelten vorhersehbare Arbeitszeiten als hohes Gut und ungeplante Überstunden sollen die Ausnahme sein. Diese Ansicht widerspricht der Logik, die in den chirurgischen Abteilungen gefolgt wird. Hier wird mit der Planung eher das Ziel verfolgt, möglichst viele Operationen pro Tag zu absolvieren. Die Betriebszeiten der Sanusklinik sind das formale Ergebnis eines Kompromisses zwischen den Berufsgruppen in diesem dauerhaften Konflikt. An seiner Aushandlung war auch der Vorstand der Sanusklinik beteiligt, für den Arbeitszeitgesetze mehr Gewicht haben als innermedizinische Hierarchien.

Der Konflikt besteht jedoch weiter fort: Die OP-Planung wird ausschließlich von Chirurg*innen durchgeführt. Diese nehmen mögliche Überschreitungen der erlaubten Betriebszeiten bei der Planung deutlich eher in Kauf als Anästhesist*innen oder Pflegekräfte. Der OP-Koordinator greift daher täglich in die Planung in einzelnen Abteilungen ein und setzt geplante Operationen ab, wenn er überzeugt ist, dass sie nicht rechtzeitig beendet werden können. Die Betriebszeiten und seine formale Position, die ihm ein Vetorecht gegen die OP-Pläne der Abteilungen sichert, sind dabei seine Ressourcen. Aus dieser im Kern konfliktären Konstellation zwischen den Berufsgruppen folgt insgesamt, dass die Verfügbarkeit von Pflegekräften und Anästhesist*innen in den Spielen um die Planung eine dauerhafte Ungewissheitszone bildet.

Da die Studie erst mehrere Jahre nach Einführung des Systems in die beobachteten Abteilungen beginnt, können die früheren Abläufe bei der OP-Planung nur aus den geschilderten Erinnerungen der Akteur*innen rekonstruiert werden. Das allgemeine Handlungsproblem der OP-Planung bleibt durch die Softwareeinführung unverändert und ist in beiden Abteilungen gleich: Es muss entschieden werden, wer (aus Chirurgie, Anästhesie und Pflege) was (Patient*in und Eingriff) wann (Tag und Uhrzeit) und wo (in welchem Saal) operiert. In beiden untersuchten Abteilungen haben sich nach Ansicht der Befragten (Abteilungsmitglieder und Außenstehende) im Großen und Ganzen die Konturen dieser Abläufe durch die Einführung von eMed kaum verändert. Die Gründe sind allerdings höchst unterschiedlich.

Die allgemeine Chirurgie ist als Pilotabteilung eng in das Customizing von eMed eingebunden gewesen. Die Planer*in hat ihre bevorzugten Arbeitsabläufe so gut wie möglich in der Software abgebildet und umgekehrt die Software in die Planungspraktiken der Abteilung integriert. Die spezielle Chirurgie hat den entgegengesetzten Weg gewählt: Die Chefärzt*in versteht den Umgang mit Software als reine Verwaltungsaufgabe, vor der ihre ärztlichen Mitarbeiter*innen geschützt werden müssen. Nur im Sekretariat soll mit der neuen Software gearbeitet werden. Die Planung bleibt alleinige Aufgabe der Chirurg*innen, die Ergebnisse werden an das Sekretariat übergeben und dort in eMed übertragen. Die Planungspraktiken sind so weit wie möglich vom Umgang mit der Software entkoppelt. Auch nachdem die Chefärzt*in den „eMed-Bann“ für ihre Ärzt*innen zwei Jahre nach der Einführung aufhebt, ändert das wenig daran, dass die Planung größtenteils als Abstimmungsprozess zwischen Chirurg*innen betrachtet wird. Dass der fertige Plan nicht nur für die Verwaltung produziert wird, sondern auch für Pflegekräfte und Anästhesist*innen, also für den medizinischen Arbeitsprozess an sich, eine Rolle spielt, scheint weniger wichtig.

Die nun folgende Analyse der Spiele, in die die Modelle des Organisierens einbezogen werden, zeigt, dass viele der Widerstände, die in Abschnitt 4.2.3 angedeutet worden sind, sich nicht einfach als individuelles Fehlverhalten, Technikfeindlichkeit oder Gedankenlosigkeit deuten lassen. Stattdessen zeigen sich darin Reaktionen der Akteur*innen auf die verschiedenen Versuche, die Praktiken im OP-Bereich durch Modelle des Organisierens und organisatorische Regeln zum Umgang mit eMed zu kontrollieren.

4.4.1 Planungsspiele in der Allgemeinen Chirurgie

Die Allgemeine Chirurgie ist eine der größeren chirurgischen Abteilungen der Sanusklinik. Hier arbeiten über 30 Chirurg*innen, eingeteilt in feste Teams, die sich auf unterschiedliche Arten von Operationen spezialisiert haben. Neben einem Grundaufkommen an vorhersehbaren Routineeingriffen gibt es in der allgemeinen Chirurgie viele Notfälle, die entweder sofort oder spätestens am nächsten Tag operiert werden müssen. Dr. Natal, der leitende Oberarzt und Planer der Abteilung, schätzt, dass „die OP-Planung zu zwei Dritteln nicht so [ist], wie man sie am Vortag gemacht hat“.

Trotz dieser großen Unvorhersehbarkeit verläuft die OP-Planung sehr routiniert; sowohl die Aufgabenverteilung als auch die Abläufe sind klar geregelt und innerhalb der Abteilung kaum umstritten. Die Verantwortung für die Entscheidungen darüber, wer was wann und wo operiert, ist klar verteilt und folgt der formalen Hierarchie: Die Teamleiter*innen entscheiden, wer operiert, die OP-Leitung, also die leitende Pflegekraft, teilt die OP-Pflegekräfte für die Eingriffe ein, die Blockleiter*in aus der Anästhesie bestimmt, wer welche Narkosen betreut. Dr. Natal, der leitende Oberarzt der Chirurgie, bestimmt, welche Operationen wann und in welchem Saal durchgeführt werden.

Die Kontrolle über das chirurgische Personal liegt durch diese Aufteilung bei den Teamleiter*innen. Sie besetzen damit eine Machtposition im Spiel. Zwar legt eMed fest, dass bei der Planung Operateur*innen eingetragen werden müssen, sieht aber keine Funktionen für die Personalplanung vor. In das Feld, das die Daten über Operateur*innen in eMed speichert, können keine beliebigen Daten eingegeben werden, sondern es muss ein Eintrag aus einer Liste ausgewählt werden. Was in dieser Liste möglicher Einträge steht, gehört zu den abteilungsspezifischen Anpassungen im Customizing. In der allgemeinen Chirurgie enthält die Liste nur die Bezeichnungen der Teams, nicht etwa die Namen einzelner Chirurg*innen. Welche Mitglieder des Teams letztendlich am Operationstisch stehen sollen, wird innerhalb des Teams entschieden. Diese Entscheidung ist auch nach der Einführung von eMed für Außenstehende nicht transparent. So berührt die Software die Machtposition der Teamleiter*innen nicht.

Diese sorgen dafür, dass für jeden Eingriff die notwendige Zahl an Operateur*innen im OP-Saal erscheint, und entscheiden ohne Einmischung der Abteilungsleitung darüber, wie die Operationen innerhalb ihres Teams verteilt werden. Im Gegenzug akzeptieren sie, dass die restlichen Planungsentscheidungen von Dr. Natal getroffen werden. Im Planungsprozess mit eMed stellt das chirurgische Personal damit faktisch keine Ungewissheitszone dar.^{Footnote 19}

Dr. Natal (OP-Planer der Allgemeinen Chirurgie): Die Patienten suchen sich die Teams selber aus. Und das ist auch ganz alleine die Hoheit des Teamoberarztes. Punkt. Da mischen wir uns überhaupt nicht ein. […] Im Prinzip haben alle Oberärzte die gleichen Rechte am SAP, aber die werden natürlich nicht wahrgenommen. Das heißt, da gibt es aber auch gar keine Autoritätsprobleme. In anderen Abteilungen gibt es durchaus Querelen in dem Bereich, wo jeder versucht so ‘n bisschen seine Möglichkeiten auszuspielen. Das gibt es bei uns gar nicht. Das Programm wird von mir gemacht oder ich gebe es ab an jemanden, der es macht, und dann macht es der. Und zwar uneingeschränkt.

Dieses Arrangement entspricht laut der Aussagen von Dr. Natal den Vorstellungen der Chefärzt*in, die die Autorität der Verantwortlichen stützt, ohne ins Alltagsgeschäft einzugreifen.

Auch der Umgang mit Notfällen wird durch diese eindeutige Aufgabenverteilung zur Routinesache: Alle Notfälle werden telefonisch an den Planer Dr. Natal gemeldet. Er allein stimmt sich mit der Blockleiter*in und der OP-Leitung ab, um Personal für die neue Operation zu organisieren, und er allein entscheidet auch darüber, wo diese in den bestehenden Plan eingefügt wird.

Vor der Einführung von eMed kontrolliert Dr. Natal so durch seine Entscheidungshoheit in allen Fragen der Planung allein die Informationskanäle, über die alle für die Planung notwendigen Einzelinformationen zusammengeführt werden: die anstehenden Operationen der Abteilung, das Personal, die verfügbaren Säle.

Fr. Lewitscharoff (OP-Leitung der Allgemeinen Chirurgie): Die OP-Planung lief über ‘nen Zettel. [Lacht] Der leitende Oberarzt hat das immer schon gemacht. Da haben wir das eigentlich auch immer schon so … Der hatte Voranmeldungen, die bekam er … Also im Prinzip ähnlich wie jetzt. Der macht ja den OP-Plan aus den Voranmeldungen der einzelnen OP-Teams. Und so hat er das vorher auch gemacht. Bloß in Zetteln. Da bekam er für jede Operation, für jede Voranmeldung einer Operation ‘nen Zettel von dem OP-Team und daraus wurde dann der OP-Plan erstellt. Auf Papier. Und dann ging das Ganze zu einer Sekretärin von der Anästhesie, die dann den Gesamt-OP-Plan für alle geschrieben hat. So. Und dann hatte man im Prinzip so was [Sie holt einen Ausdruck des aktuellen OP-Plans heraus].

OP-Leitung und Blockleiter*in der Anästhesie kontrollieren jeweils das Personal ihrer Berufsgruppen und besetzen damit weitere Machtpositionen im Planungsspiel. Pflege und Anästhesie besitzen jeweils eigene Personalpläne, die für die Mitglieder dieser Abteilungen bindend sind. Solange die beiden die Informationskanäle zwischen den Berufsgruppen kontrollieren, besetzen sie auch in ihren internen Spielen Machtpositionen.

4.4.1.1 Widerstände

Die Allgemeine Chirurgie diente bei der Einführung von eMed in den OP-Bereich als Pilotabteilung (vgl. Abschnitt 4.1.3). Da Mitarbeiter*innen der Allgemeinen Chirurgie dadurch am Customizing beteiligt waren, ist die Erwartung naheliegend, dass der Umgang mit eMed den Vorgaben entspricht, die im Rahmen dieses Prozesses festgelegt worden sind. Dies ist jedoch nicht der Fall.

4.4.1.1.1 Das Spiel mit den OP-Aufträgen

Die Koordination zwischen den drei Berufsgruppen im OP ist nur möglich, wenn die OP-Leitung und die Blockleiter*in wissen, für welche Aufgaben sie ihre Mitarbeiter*innen einteilen sollen. Dazu müssen viele Detailinformationen zu anstehenden Operationen zwischen den behandelnden Chirurg*innen, Pflegekräften und Anästhesist*innen ausgetauscht werden, die bei der Operation zusammenarbeiten sollen. Nachdem die „Zettel“ durch eMed abgelöst worden sind, geschieht dies über die OP-Aufträge in der Software. Über diese ist es prinzipiell möglich, umfangreiche medizinische Daten zur Patient*in anzugeben. Erzwungen werden aber nur die Eingaben, die für die Abrechnung nötig sind, und die, die von den zentralen Akteur*innen im Rahmen des Customizing als Pflichteingaben festgelegt wurden, also zum Beispiel Angaben darüber, wie die Patient*in auf dem OP-Tisch gelagert werden soll, ob eine Infektion mit resistenten Keimen vorliegt o.ä. Insgesamt sind es nur sehr wenige Pflichteingaben, mit denen rein medizinische (und nicht gleichzeitig abrechnungsrelevante) Aspekte des Zustands der Patient*in in eMed beschrieben werden. Allein auf Basis der Pflichteingaben lässt sich nicht genau bestimmen, wie komplex und dringlich eine Operation ist.

Dr. Natal setzt durch, dass seine Chirurg*innen nicht zu viele zusätzliche Details in die OP-Aufträge einfügen, denn detaillierte Fallbeschreibungen in eMed sind für ihn Zeitverschwendung. Wenn in einem OP-Auftrag Informationen fehlen, die er für die Planungsentscheidung braucht, wird die Veranlasser*in angerufen. Er legitimiert dieses Vorgehen, indem er sich auf die medizinische Tradition der diskursiven Konstruktion eines Falls aus einer Menge an Einzelinformationen (Atkinson 1995) beruft und die Möglichkeit, medizinische Entscheidungen nach Aktenlage zu treffen, grundsätzlich bestreitet:

Dr. Natal (OP-Planer der Allgemeinen Chirurgie): Die wahre Planung findet natürlich individuell am Patienten statt, […] durch seine individuelle Dringlichkeit. Die Organisation, dass das stattfindet, und die Abwägung findet logischerweise nicht im SAP statt. Sondern das ist, ja, orale Koordination. Also dort wird miteinander gesprochen, der Fall dargestellt [...] Die Entscheidungen werden ja von Menschen getroffen. Das SAP ist das Kondensat, das heißt also, damit jeder hinterher drauf zugreifen kann auf einen fixen Punkt, dafür ist das SAP da. Aber […] man nutzt nicht das SAP, um die Entscheidung zu treffen. Weil man im SAP eben nicht lesen kann, sozusagen wie schwierig ein Patient ist oder so. Das kann man jemandem erzählen, aber man kann sich nicht ‘ne halbe Stunde hinsetzen und eingeben, was für Macken ein Patient hat.

Die medizinischen Daten in den OP-Aufträgen sind damit korrekt, aber ungenügend, um die Arbeit des Planers zu beurteilen oder gar in Frage zu stellen.

4.4.1.1.2 Das Spiel mit den Planzeiten

Auch die Daten, die der Planer selbst eingibt, sind nicht umfangreich und präzise genug, um sie ohne mündliche Absprachen zu verstehen. Besonders auffällig wird dies bei den Planzeiten: Im OP-Plan in eMed sind alle Operationen des Tages mit zwei Stunden Dauer angesetzt, egal, ob es sich um einfache Routineeingriffe oder um sehr aufwändige Kombinationseingriffe o.ä. handelt. Obwohl Operationen in der allgemeinen Chirurgie in der Praxis zwischen 30 Minuten und 16 Stunden dauern, wird ihr Zeitbedarf über den OP-Plan in eMed vereinheitlicht repräsentiert und damit auf eine Weise abgebildet, die für die Koordination bedeutungslos ist. Eine Zeitschätzung für das Tagesprogramm, bei der die real zu erwartende Varianz der Operationsdauer berücksichtigt wird, ist durchaus möglich. Der Planer Dr. Natal führt so eine Zeitschätzung auch täglich durch. Die Ergebnisse, also geschätzte Operationszeiten für die Eingriffe des Tages, werden nur nicht in eMed eingetragen. Dr. Natal gibt diese abseits von eMed weiter, zusammen mit allen anderen Informationen, die OP-Leitung und Blockleiter*in brauchen, um ihre eigenen Planungen durchzuführen. Dazu treffen sich die beiden Mediziner*innen täglich, um die geplanten Operationen zu besprechen. Die OP-Leitung holt fehlende Informationen meist im Anschluss an dieses Gespräch telefonisch beim OP-Planer ein.

Obwohl Dr. Natal erklären kann, wie er zu einer realistischen Zeitschätzung kommt und diese an die Verantwortlichen der Servicedisziplinen weitergibt, bestreitet die OP-Leitung, dass eine solche überhaupt möglich sei. Auch hier wird wieder auf die Logik der Profession verwiesen:

Fr. Lewitscharoff (OP-Leitung der Allgemeinen Chirurgie): Es werden auch keine Zeiten geplant. […] Aber die stimmen auch in anderen Abteilungen nicht […] Die wissen das vorher manchmal nicht. Man kann zwar manchmal im Laufe der Operation dann erkennen, wenn die erst mal angefangen haben und alles ist gut in Übersicht, dann können die vielleicht schon mal was sagen, so während der Operation. Aber vor der Operation nicht. Zu 99,9 Prozent stimmen diese Listen sowieso nicht. […] Auch die Fälle sind unterschiedlich. Man muss einfach erst mal vor Ort sein und wirklich einmal kucken. […] Es kann immer alles irgendwie Komplikationen geben und Schwierigkeiten […]. Und wie sich das zeigt, ist das auch fast überall so.

Die OP-Leitung begründet das Vorgehen des Planers hier als folgerichtiges Umgehen mit den allgemeinen Bedingungen, die angeblich für Operationen immer und überall gelten: Patient*innen sind unterschiedlich und Eingriffe verlaufen unvorhersehbar. Dies steht im Einklang mit der Logik des Einzelfalls, die typisch für die medizinische Profession ist. Eine OP-Planung, die eine realistische Einschätzung der OP-Dauer beinhaltet, wird aus Sicht der OP-Leitung nicht von Dr. Natals Planungspraxis verhindert, sondern ist grundsätzlich nicht möglich. Gegenbeispiele aus anderen Abteilungen verweist sie ins Reich der Phantasie.

4.4.1.1.3 Das Stornierungsspiel

Eine weitere Besonderheit des OP-Plans der allgemeinen Chirurgie lässt sich nicht durch Bezug auf die Profession erklären: Operationen, die im Tagesverlauf abgesetzt werden, sollen in eMed storniert werden. Dieses Vorgehen ist im Benutzer*innenhandbuch zum Umgang mit eMed in der Sanusklinik vorgeschrieben, eine Vorgabe, die der OP-Koordinator Dr. Mosser im Interview bestätigt. Werden Operationen in eMed storniert, verschwinden die OP-Aufträge vom Plan und erscheinen wieder in der Planungsübersicht. OP-Aufträge haben kein Ablaufdatum. Einmal eingeplant, wird in eMed nur ihre Startzeit nach hinten verschoben, solange sie nicht als erledigt markiert werden. Dadurch wechseln OP-Aufträge, die am Vortag eingeplant, aber weder als abgeschlossen markiert noch storniert worden sind, automatisch auf den Plan des nächsten Tags, wenn die in der Software hinterlegte Betriebszeit für den eingeplanten OP-Saal abgelaufen ist.

Dr. Natal storniert verschobene Operationen nicht, sondern fügt bei der täglichen Planung nur neue OP-Aufträge hinzu. Im Ergebnis enthält der OP-Plan der allgemeinen Chirurgie jeden Tag viel mehr Operationen, als bewältigt werden können. Dieses Unterlassen verhindert, dass irgendjemand außer den zentralen Akteur*innen eine Möglichkeit bekommt, den OP-Plan oder auch nur den Stand des Geschehens in den Sälen der allgemeinen Chirurgie zu beurteilen.

Fr. Lewitscharoff (OP-Leitung der Allgemeinen Chirurgie): Also für mich persönlich ist das kein Problem. Es ist natürlich für andere. Weil ich es jetzt weiß. Für andere, wie den [OP-Koordinator], für den wird’s ‘n Problem, weil der weiß das jetzt grad nicht. […] Es wär’ einfacher für alle Beteiligten, wenn sie das [d. h. die stornierten OP-Aufträge aus dem Plan] rausnehmen würden. […] Aber … ja.

Anders als im Fall der fehlenden Planzeiten, die die OP-Leitung ausführlich begründen konnte, indem sie auf die Logik der Profession Bezug nahm, fehlt ihr im Fall der fehlenden Stornierungen eine Erklärung. Der Verzicht auf Stornierungen stellt für die Koordination nach Aussage der OP-Leitung kein großes Problem dar, ist aber auch nicht förderlich. Die Stornierung eines OP-Auftrags ist weder zeitaufwändig noch kompliziert. Vor allem in der Allgemeinen Chirurgie, in der die planenden Akteur*innen sehr routiniert mit eMed umgehen, überrascht es daher, dass der Planer auf Stornierungen verzichtet. Dieses Vorgehen muss nicht ausführlich und explizit legitimiert werden, so wie es bei den anderen unvollständigen Eingaben der Fall war, denn der unübersichtliche Plan in eMed beeinträchtigt die Lösung des Handlungsproblems nicht. Über die Plantafel kann der Verlauf des Geschehens in den OP-Sälen nur verfolgt werden, wenn regelmäßige Abweichungen zwischen Plan und Wirklichkeit nicht vorkommen. Im Tagesverlauf neu angemeldete Notfälle werden auf der Kalenderansicht sogar überhaupt nicht angezeigt. In der allgemeinen Chirurgie sind Notfälle auch bei genauester Zeitschätzung nicht vermeidbar. Pflegekräfte verbringen den ganzen Tag im OP-Bereich und bekommen daher ohne Blick auf den Plan mit, wann die nächste Operation ansteht. Die Mediziner*innen werden telefonisch benachrichtigt, wenn ihre Operationen beginnen. Dass sie den wahren Plan nicht kennen, stört nicht bei der Lösung des Handlungsproblems.

4.4.1.2 Verteilung der Kontrolle in den Spielen mit eMed

Die Modelle des Organisierens in eMed und die Entscheidungen beim Customizing führen dazu, dass der OP-Plan für alle Spieler*innen des Planungsspiels sichtbar ist. Doch enthält der Plan neben den verpflichtenden Daten, die für die Abrechnung notwendig sind, nicht genug medizinische Daten, um ihn auch zu beurteilen. Die Akteur*innen in der allgemeinen Chirurgie koordinieren sich intern über einen Plan, der für Außenstehende unverständlich ist.

Der Wechsel vom „Zettel“ auf den OP-Auftrag schwächt Dr. Natals Kontrolle über die Informationskanäle zu anstehenden Operationen, denn durch eMed sehen alle Chirurg*innen der Abteilung auf einen Blick, welche Operationen für den Tag angemeldet sind: Die OP-Aufträge enthalten detaillierte Angaben zu jedem geplanten Eingriff. Die Plantafel in eMed OP zeigt den OP-Plan in Kalenderansicht, die geschätzte Operationsdauer und auch, welche Operationen schon begonnen haben und welche noch ausstehen. Diese Planungsentscheidungen basieren auf professionellem Fachwissen, das in eMed nicht enthalten ist. Die Chirurg*innen der Abteilung besitzen jedoch solches Fachwissen. Mit den Informationen aus eMed könnten sie die Entscheidungen des Planers Dr. Natal darüber, welche Operationen priorisiert und zu welchen Zeiten sie eingeplant werden, in Frage stellen. Da jedoch nur Pflichtfelder ausgefüllt werden, wird eine solche Kritik in der Praxis verhindert. Die Teamleiter*innen und der Planer können diesen Umgang mit eMed durchsetzen. Dabei können sie sich auf verschiedene Bedingungen stützen, die die Arbeit in der Allgemeinen Chirurgie charakterisieren: das Wohlwollen der Chefärzt*in, die ihren leitenden Mitarbeiter*innen bei der Gestaltung der Arbeitsprozesse innerhalb der Abteilung freie Hand lässt, die medizinische Tradition, der zu Folge Chirurg*innen nur mündlich kommunizierbares Expert*innenwissen haben, mit dem sie unvorhersehbare Einzelfälle behandeln, die professionelle Hierarchie der Medizin, in der erfahrene Chirurg*innen die Entscheidungen erfahrener Chirurg*innen nicht hinterfragen, und die notorische Arbeitsüberlastung der Chirurg*innen, die als offizielle Begründung gilt, warum „überflüssige“ Dateneingaben verhindert werden müssen.

Auch die OP-Leitung und die Blockleiter*in der Anästhesie tragen die Praxis des Umgangs mit eMed mit, durch die die unvollständigen OP-Pläne in der Allgemeinen Chirurgie entstehen. Würden sie nur den OP-Plan zur Koordination nutzen, wären alle Informationen, die dort eingegeben werden, für alle anderen Spieler*innen sichtbar. OP-Leitung, OP-Planer und Blockleiter*in berücksichtigen diese durch eMed neu eingeführte Bedingung beim Umgang mit der Software und tauschen kritische Informationen nur mündlich aus. Die Planung in der allgemeinen Chirurgie ist eingespielt, die Kontrolle der Ungewissheitszonen aufgeteilt zwischen Akteur*innen, die untereinander nicht konkurrieren: Über die professionelle Hierarchie der Medizin ist die Rangordnung zwischen den drei Akteur*innen klar definiert und über die organisatorische Hierarchie der Sanusklinik sind sie mit der Leitung klar getrennter Bereiche betraut. Die Planungspraxis, die in der Allgemeinen Chirurgie etabliert ist, sichert allen dreien einen Informationsvorsprung gegenüber den Mitgliedern ihrer eigenen Bereiche. Die Kooperation ist also für die OP-Leitung und die Blockleiter*in ebenso vorteilhaft wie für den OP-Planer. Alle drei nutzen die Funktionen der Software, die ihnen bei der Koordination helfen, ohne ihre Position zu gefährden, und verteidigen so die relevanten Ungewissheitszonen, die sie kontrollieren.

Auch Dr. Mosser, der OP-Koordinator, der jeden Tag entscheidet, welche Abteilung die raren zusätzlichen Plätze in OP-Sälen zugeteilt bekommt, kann sich durch eMed ein eigenes Bild vom OP-Plan der Allgemeinen Chirurgie machen. Der Verzicht auf die Stornierung von Aufträgen trifft vor allem ihn: Er kann dadurch nicht über eMed erkennen, welche Operationen tatsächlich noch anstehen und welche abgesetzt sind, ist aber auch nicht in die Kommunikation innerhalb der Abteilung eingebunden. Die Praxis, verschobene Operationen nicht zu stornieren, scheint nicht der Stabilisierung der Machtverteilung innerhalb des Spiels zu dienen. Eine Motivation dafür findet sich im Spiel um die Verteilung der abteilungsübergreifenden Ressourcen des OP-Bereichs.

Durch den Umgang mit eMed, der sich in der Allgemeinen Chirurgie etabliert hat, wird das Handlungsproblem zuverlässig gelöst; der etablierte Planungsprozess sorgt dafür, dass Menschen und Material täglich zur richtigen Zeit am richtigen Ort sind. Über das richtige was, wer, wo und wann entscheiden die medizinische Vernunft und die Umstände, beides interpretiert durch die zentralen Akteur*innen im Spiel.

Tatsächlich gibt es in der allgemeinen Chirurgie keine der Planungsfehler, über die sich Pflegekräfte und Chirurg*innen anderer Abteilungen in der Sanusklinik beschweren: Operateur*innen, die nicht erreichbar sind, wenn die schnittbereite Patient*in in Narkose liegt, leerstehende Säle, vor deren Tür mehrere OP-Teams diskutieren, wessen Operation nun Vorrang hat, oder diagnostische Untersuchungen kurz vor OP-Termin, deren Ergebnis den ganzen Tagesplan umwirft. Die Mitarbeiter*innen nutzen eMed routiniert. Trotz durchgängiger Kritik an der Langsamkeit und der überkomplexen Benutzer*innenoberfläche wird die Software als nützlich bewertet, weil sie Informationen bündelt und zentral bereitstellt: eMed ist „ein Fixpunkt, auf den alle zugreifen können“ (Dr. Natal). Die Transparenz, die in der Abteilung vorteilhaft ist, soll die Grenzen der Abteilung jedoch nicht überschreiten, wozu die Planungspraxis erheblich beiträgt. Die Informationen in eMed zeigen zwar an, welche Patient*innen noch warten und welche schon operiert wurden, lassen aber keine Rückschlüsse darauf zu, wie der Übergang vom ersten in den zweiten Zustand organisiert ist. Genau diese Frage ist Teil des Handlungsproblems, das alle Akteur*innen im OP-Bereich zusammenbringt.

4.4.2 Spiele um die Steuerung des OP-Bereichs

In den abteilungsübergreifenden Spielen im OP-Bereich wird um die Verteilung der Ressourcen, die von der Sanusklinik für Operationen bereitgestellt werden gespielt. Während es sich bei den Planungsspielen in der allgemeinen Chirurgie, die im vorangehenden Abschnitt analysiert worden sind, um Routinespiele handelt, werden in diesem Abschnitt Innovationsspiele rekonstruiert. Das Handlungsproblem dieser Innovationsspiele ist die Steuerung der abteilungsübergreifenden Spiele, über die die Verteilung der Ressourcen stattfindet.

Akteur*innen generieren relevante Ungewissheitszonen entlang der Grundkonflikte des Krankenhauses: Die Ressourcenverteilung soll einerseits medizinischen Anforderungen genügen, also sicherstellen, dass keine Patient*in ohne adäquate Behandlung bleibt. Andererseits sollen die Ressourcen auf eine Weise verteilt werden, die auch ökonomischen Anforderungen genügt. Dies bedeutet, dass im OP-Bereich sparsam mit Arbeitszeit und Sachmitteln umgegangen werden soll. Dieser Grundkonflikt bildet den Hintergrund, vor dem die Akteur*innen im OP-Bereich die relevanten Ungewissheitszonen des Innovationsspiels ausdefinieren. Die erste entsteht rund um die Frage, welche Ressourcen notwendig sind, um die in der Sanusklinik anfallenden Operationen adäquat zu erledigen. Die zweite liegt im Bereich der Verfügungsgewalt über die vorhandenen Ressourcen. Die Chirurg*innen können ihren Status als Repräsentant*innen der Profession einsetzen, um sich in Auseinandersetzungen um die Kontrolle über die erste Ungewissheitszone einen Vorteil zu sichern. Für die Verwaltung, die im Steuerungsspiel von Vorstand und OP-Koordinator*in repräsentiert wird, stellt die klassische Aufgabenteilung zwischen medizinischen und administrativen Abteilungen in Krankenhäusern eine Ressource in Auseinandersetzungen um die Kontrolle der zweiten Ungewissheitszone dar. Durch die Reorganisation und die Einführung von eMed eröffnet der Vorstand ein Innovationsspiel, das die frühere alleinige Kontrolle, die Abteilungsleiter*innen über „ihre“ Säle und „ihr“ Servicepersonal ausgeübt haben, in Frage stellt. Der Vorstand, der formal die Verfügungsgewalt über alle Ressourcen hat, definiert zwei Modi, in denen über Ressourcen verfügt werden soll: Das Jahresbudget der Abteilungen, die Stellenpläne und fest zugeordnete Säle sind mittel- und langfristig zwischen Abteilung und Vorstand auszuhandeln. Die kurzfristige Umverteilung von Sälen und Servicepersonal von einer Abteilung auf die andere obliegt der OP-Koordinator*in.^{Footnote 20} Das eröffnet neue Arenen und motiviert ein ganzes Ensemble neuer Spiele, in denen auch vorhergehende Konflikte neu ausgetragen werden können.

Zur Beantwortung beider Verteilungsfragen sind Informationen über das Geschehen in den Abteilungen notwendig. Die Abteilungsleiter*innen kontrollieren diese, und eMed soll das ändern. Einige der Spiele, die die Einführung von eMed innerhalb der Abteilungen nach sich zieht, wurden im vorigen Abschnitt 4.4.1 am Beispiel der Allgemeinen Chirurgie diskutiert. Andere werden hier nur angedeutet: Der Vorstand legt fest, dass alle Arbeitsprozesse und Ergebnisse in eMed dokumentiert werden müssen. Eines der Spiele um diese OP-Dokumentation wird weiter unten beschrieben. Mit Hilfe der OP-Pläne soll die OP-Koordinator*in die Übersicht über das Tagesgeschehen im OP-Bereich behalten und feststellen, welche ungenutzten Ressourcen kurzfristig wem zugeteilt werden können. Dieses Innovationsspiel ist zum Beispiel mit dem Stornierungsspiel in der Allgemeinen Chirurgie verkettet. Auch diese Verkettung wird im Folgenden genauer ausgeführt werden. Als Grundlage für Verhandlungen über das Jahresbudget und über langfristige Verschiebungen von Stellen und zugeordneten Sälen wird die OP-Dokumentation zwischen den Abteilungen genutzt. Eines der Spiele, das sich in den Abteilungen daraus ergibt, wird nun als erstes vorgestellt.

Die Abteilungsleiter*innen sind formal verantwortlich für alle Arbeitsabläufe innerhalb ihrer Abteilung. Sie delegieren die operative Leitung zwar größtenteils an die leitenden Oberärzt*innen, aber bleiben als oberste Entscheidungsinstanz auch im Arbeitsalltag präsent, indem sie die operativen Entscheidungen kommentieren oder auch spontan durch eigene Entscheidungen außer Kraft setzen, wann immer es ihnen gefällt. Die Chefärzt*innen setzen durch, dass eMed für die Planung genutzt wird. Widerstand gegen direkte Befehle der Chefärzt*in wird nicht geübt – die Chirurg*innen folgen ihren Anordnungen und beschweren sich höchstens unauffällig bei gleichrangigen Kolleg*innen, wenn sie mit der Entscheidung nicht einverstanden sind. Die Chefärzt*innen zeigen den Chirurg*innen in ihrer Abteilung außerdem, dass sie für das Budget mit verantwortlich sind.

Dr. Lessing (leitender Oberarzt): Wir kriegen Abzüge, wenn man ‘nen Patienten zu lange liegen lässt, oder zu früh entlässt. […] Das sind ja manchmal gar nicht medizinische Gründe, dass ‘n Patient jetzt sieben Tage liegt oder fünf, ja? Manchmal sind's administrative Gründe […] Und dann gibt’s auch die volle Summe und dann kriegt man keine Abzüge. […] Der Chef legt da Wert [drauf] und spricht das in den Besprechungen häufig an, dass man da jemanden nicht sofort entlassen kann. Oder geht donnerstags selber einmal Chefvisite und fragt halt, oh, die liegt seit vier Wochen hier, was kann man vielleicht optimieren. […] Das ist ja für beide Seiten gut. Für Patienten, aber auch für die wirtschaftliche Situation.

Auch die Mitglieder der zugeordneten pflegerischen Abteilungen werden von den Chefärzt*innen angehalten, bei ihrer Arbeit an das Abteilungsbudget zu denken. Die Pflegekräfte sind zwar formal eigenständig organisiert, sie sind der Chirurgie aber sowohl durch die professionelle Ordnung der Medizin als auch durch die Organisation des Arbeitsalltags untergeordnet: Chirurg*innen sind sowohl für die Planung von Operationen verantwortlich als auch für deren Durchführung und geben daher häufig Anweisungen, die die Pflegekräfte befolgen müssen. Einerseits unterstützen Pfleger*innen die Vorgabe, dass in eMed geplant werden soll, indem sie selbst eMed für die OP-begleitende Dokumentation einsetzen und dafür darauf bestehen, dass nur Operationen durchgeführt werden, für die in den Plan eingetragene OP-Aufträge vorliegen. „Inoffizielle“ Operationen, die nicht in eMed registriert werden, gibt es nicht. Spätestens die Pflegekräfte im Saal melden eine Operation an und sorgen so dafür, dass zumindest laufende und abgeschlossene Operationen in der Software angezeigt werden.^{Footnote 21} Andererseits ziehen sie nach Abschluss der Operationen einige der fehlenden oder falschen Daten im OP-Auftrag nach.

4.4.2.1 Widerstände

Die Abteilungsleiter*innen setzen die formalen Regeln zum Einsatz von eMed trotz des Widerwillens durch, den die meisten Mitarbeiter*innen der Software entgegenbringen. Allerdings befolgen die Mitarbeiter*innen die Regeln nicht in allen Details. Die Software wird zwar genutzt, um die Aufgaben zu erfüllen, die mit ihr erfüllt werden sollen. Die Daten, die eingegeben werden, sind jedoch regelmäßig unvollständig oder schlicht falsch.

Unvollständige oder falsche Planungsdaten werden nicht nur in der Allgemeinen Chirurgie sanktioniert, sondern auch in anderen chirurgischen Abteilungen (Beispiele aus einer zweiten Abteilung, der Speziellen Chirurgie, werden im nächsten Abschnitt vorgestellt). Auch in Abteilungen, in denen die OP-Säle nur gering ausgelastet sind, werden die OP-Aufträge für ausgefallene Operationen nicht immer unmittelbar storniert. Die Planer*innen verhindern so im täglichen Ablauf, dass „ihre“ Säle an andere Abteilungen weitergereicht werden.

Bei der OP-begleitenden Dokumentation mit eMed werden die Regeln etwas genauer befolgt als bei der OP-Planung. Pflegekräfte und Chirurg*innen können in eMed eintragen, welche Arbeitsschritte vor und während der Operation durchgeführt worden sind, dabei den konkreten Zeitpunkt festhalten und die Arbeitsschritte inhaltlich genau beschreiben. Über die Software können bei der Operation verwendete Geräte, Medikamente und Materialien gemeinsam gespeichert und verschiedene medizinische Parameter in der Krankenakte der Patient*in dokumentiert werden. Zu all diesen Zwecken dient die Verknüpfung der unterschiedlichen Daten zum Fall in eMed, die in den Abschnitten 4.2.2 und 4.3 detailliert beschrieben worden ist. Ein großer Teil der medizinischen Daten ist juristisch relevant^{Footnote 22} oder hat Auswirkungen auf den weiteren Behandlungsverlauf der Patient*in (z. B. bei Allergien). Solche Daten werden (größtenteils) vollständig dokumentiert. Das gleiche gilt für Verbrauchsmaterialien. In diesem Fall begründen Interviewpartner*innen in der Sanusklinik die Sorgfalt bei der Dokumentation mit einem Verweis auf das Budget. Die stellvertretende OP-Leitung der Speziellen Chirurgie erzählt:

„Der Materialverbrauch muss drin sein, weil die ganze Abrechnung über SAP läuft. Also wenn wir Materialien nicht eintragen, bekommen wir die auch nicht vergütet. So wurde mir das gesagt.“

Die budgetrelevanten Daten in eMed sind in der Regel korrekt, weil die Mitarbeiter*innen darauf achten, dass die Abteilung dafür korrekt vergütet wird. Anders sieht es bei den Daten aus, die genutzt werden könnten, um den Verlauf oder die Inhalte der Arbeitsprozesse aus der Dokumentation zu rekonstruieren. Diese sind oft ebenso falsch wie die Daten, die bei der Planung eingegeben werden.

Dr. Mosser (OP-Koordinator): Wir haben im Augenblick die Situation, dass zwar alle operativen Tätigkeiten in SAP dokumentiert werden, also die Anmeldung, die Erstellung des OP-Auftrags, die Planung als solche, und auch die Zeiten der jeweiligen operativen Bereiche, also OP-Pflege und Operateure – mit gewissen Einschränkungen, das darf man auch nicht verschweigen. Also die einzigen Zahlen, die ich wirklich glaube, sind Naht und Schnitt. Alles andere ist gelogen. Sag ich jetzt mal rundheraus. […] Da stimmt nichts von.

Wie bei der Planung in der allgemeinen Chirurgie beeinträchtigen falsche Angaben den Alltag der Mitglieder des OP-Bereichs nicht groß: die meisten von Ihnen müssen Daten für die Dokumentation nur eingeben, aber nicht damit weiterarbeiten. Die Arbeit des OP-Koordinators Dr. Mosser wird hingegen massiv gestört: Er weiß, dass die Daten aus eMed nicht verlässlich sind, und muss sich die Informationen, die er zur Steuerung braucht, durch freundschaftliche Beziehungen zum Personal und regelmäßige Rundgänge durch die einzelne Saalcluster erarbeiten. Auf diese Weise bekommt er genug Übersicht über die Abläufe im OP-Bereich, um täglich Kleinigkeiten zu verändern, gegen die Abteilungsleiter*innen nicht protestieren. Seine übergeordnete Position in der Hierarchie kann er jedoch nicht einsetzen, da er davon ausgeht, „dass diese Abteilungsleiter natürlich dann versuchen würden, meine Entscheidung zu konterkarieren“. Stattdessen setzt er darauf, dass sich „über irgendwelche Argumente, oder auch durch, sagen wir mal, zartes Schaffen von Fakten“ langfristig die Regeln zum Umgang mit eMed vollständig durchsetzen werden. Die hier beschriebenen Innovationsspiele werden über den Verlauf der Zeit, in der ich den Umgang mit eMed in der Sanusklinik untersucht habe, nicht zu Routinespielen. Die Frage, wie die Ressourcenverteilung gesteuert werden soll, bleibt umkämpft.

4.4.2.2 Verteilung der Kontrolle in den Spielen mit eMed

In den Spielen um die Steuerung des OP-Bereichs sind Strategien von Vorstand und Abteilungsleiter*innen erkennbar, die auf die Modelle des Organisierens von eMed und die dahinterliegenden Kontrollversuche treffen. Das Krankenhausinformationssystem eMed basiert auf der Annahme, dass das Geschehen in der Organisation mit Hilfe der Daten abgebildet werden kann, die während der Arbeitsprozesse von Nutzer*innen in die Software eingegeben oder in der Software automatisch generiert werden. Nutzer*innen, die Einsicht in die Daten haben, die in der zentralen Datenbank von eMed gespeichert sind, sollen dadurch in die Lage versetzt werden, Unsicherheiten im Krankenhaus zu kontrollieren. Durch Entscheidungen im Customizing werden über den Umgang mit eMed vor allem die Aspekte der Arbeitsprozesse im eben genannten Sinn transparent gemacht, die in den Modellen des Organisierens aus dem ERP-Kern und in denen von IS-H enthalten sind.

Alle Daten, die für die Berechnung der Fallpauschale nach gesetzlichen Vorgaben notwendig sind,^{Footnote 23} müssen beim Umgang mit eMed standardmäßig im frühestmöglichen Prozessschritt verpflichtend eingegeben werden, in dem sie den Nutzer*innen bekannt sind. Wenn Nutzer*innen die Pflichteingaben vermeiden, wird der OP-Auftrag vom System nicht angenommen; die Operation kann nicht in den OP-Plan eingetragen und damit auch nicht dokumentiert werden. Anders verhält es sich bei der Dauer der Operation, die bei der OP-Planung angegeben werden soll. Diese Angabe wird nicht in die Dokumentation übernommen. Wenn die Operation abgeschlossen ist, erscheint sie in keinem der Berichte, mit denen das Geschehen in der Sanusklinik für das Management abgebildet werden soll. Die einst eingeplante OP-Zeit bleibt zwar irgendwo als Eintrag in der zentralen Datenbank von eMed erhalten, wird jedoch beim Umgang mit der Software nicht erneut bedeutsam.

Auch bei der OP-begleitenden und der nachgelagerten Dokumentation ist über eMed vorgegeben, dass alle Daten, die für die Abrechnung einer Behandlung mit der Krankenkasse notwendig sind, in einem festgelegten Format eingegeben werden müssen, damit das Dokumentierte überhaupt im System gespeichert werden kann. Die Datenstrukturen und Prozesse, die die Sammlung abrechnungsrelevanter Daten sicherstellen, sind in IS-H implementiert. Hier wird festgelegt, dass der Fall das sogenannte „führende Objekt“ ist, also das Datenelement, an das alle anderen geknüpft werden. Die Modellierung der Prozesse um den Fall ist dort jedoch nicht neu angelegt, sondern orientiert sich an den Produktionsprozessen im ERP-Kern. Der zentrale Geschäftsprozess im ERP-Kern dient der Herstellung eines Produkts durch die Kombination von Materialien. Durch die Veränderungen, die bei der Entwicklung von IS-H mit diesem Geschäftsprozess und den Elementen der Software, die in ihm kombiniert wird, vorgenommen werden, dient er in IS-H der Bearbeitung eines Falls durch die Kombination von Leistungen. Die Richtlinien des deutschen DRG-Systems geben die Fallorientierung vor und legen auch fest, welche Daten notwendig sind, damit ein Fall eindeutig einer Diagnosis Related Group, also einer diagnoseabhängigen Fallgruppe, zugeordnet werden kann. Diese Zuordnung zu einer Fallgruppe ist Voraussetzung für die Abrechnung. Nur wenn die Abrechnung möglich ist, kann ein Fall nach den Kriterien in eMed erfolgreich bearbeitet werden. Die Richtlinien des deutschen DRG-Systems und die daraus abgeleiteten Anforderungen an die Dateneingabe sind so in die Arbeitsprozesse integriert, dass unvollständige oder fehlerhafte Eingaben, die sich auf die Abrechnung auswirken, spätestens in dem Arbeitsschritt korrigiert werden, in dem die Operation nach ihrer Beendigung dokumentiert wird. Die Eingabe von Daten, die nach diesen Richtlinien nicht relevant für die Abrechnung sind, ist nicht verpflichtend. Verschiedene Arten von Daten werden in der Software unterschiedlich behandelt: Einige, wie zum Beispiel die Leistungsdaten, sind einfach aufzufinden und werden in Berichten aufbereitet. Andere, wie zum Beispiel die geplanten OP-Zeiten, verschwinden nach kurzer Zeit in der Datenbank und verlieren bald nach der Eingabe ihre Bedeutung für die Prozesse in der Sanusklinik.

Die Verfolgung von Verbrauchsmaterialien vom Einkauf bis zur Rechnungsstellung durch spezielle Berichte wird in der Standardversion des ERP-Kerns unterstützt. Zusammen mit den abrechnungsrelevanten Daten bilden die Daten zu diesen Materialien die Grundlage der Verhandlungen zwischen Vorstand, OP-Koordinator und Abteilungsleiter*innen über die mittel- und langfristige Steuerung des OP-Bereichs. Die Entscheidung, Daten aus dem Krankenhausinformationssystem als Grundlage für diese Verhandlungen zu nutzen, lässt sich als eine Strategie des Vorstands in den Innovationsspielen des OP-Bereichs betrachten. Die Abteilungsleiter*innen sollen zur Preisgabe von Informationen über die Arbeitsprozesse bewegt werden, indem ihr Abteilungsbudget von den Erlösen der Abteilung und den Kosten abhängig gemacht wird, die der Abteilung eindeutig zugerechnet werden können. Die Daten aus eMed bilden die einzig legitime Grundlage der Budgetverhandlungen: Jede Abteilungsleiter*in, die die Richtigkeit dieser Daten in Zweifel zöge, würde sich damit dem Verdacht aussetzen, sie sorge in ihrer eigenen Abteilung nicht ausreichend dafür, dass eMed so genutzt wird, wie es die Organisationsregeln vorgeben.

Daten aus eMed können nicht nur Aufschluss über finanzielle Aspekte der Arbeit wie Erlöse und Kosten geben, sondern auch über Arbeitsabläufe und –inhalte. Wenn Mitarbeiter*innen aller Abteilungen vollständige, nicht gefälschte und auf die gleiche Weise interpretierbare Daten zu Planung und Dokumentation in eMed eingeben würden, ließen sich die zwölf chirurgischen Abteilungen in allen Aspekten vergleichen, die von diesen Daten abgedeckt werden. Die professionelle Deutungshoheit über medizinische Aspekte der Krankenbehandlung, die Abteilungsleiter*innen gegenüber den Vorstandsmitgliedern besitzen, bliebe zwar prinzipiell bestehen. Ihre Kontrolle über das Geschehen in ihren Abteilungen wäre aber dahin: Die Daten aus eMed würden es den Vorstandsmitgliedern (und anderen) ermöglichen, sich über dieses Geschehen zu informieren, ohne dass die Abteilungsleiter*innen dies beeinflussen könnten. Informationen über das Geschehen in den Abteilungen wären für Außenstehende nicht mehr unsicher, die Abteilungsleiter*innen könnten also diese relevante Ungewissheitszone in den Spielen um die Steuerung des OP-Bereichs nicht mehr kontrollieren. Wenn sich im Vergleich der Arbeitsprozesse einzelner Abteilungen auf Basis der Daten aus eMed Muster zeigen würden (was wahrscheinlich ist, da viele Eingriffe und Arbeitsschritte sich wiederholen), wäre es schwer für die Abteilungsleiter*innen, sich einheitlichen Regeln für die Arbeitsprozesse im gesamten OP-Bereich zu widersetzen. Ein Teil der Kontrolle über die Arbeitsprozesse innerhalb der Abteilung würde den Abteilungsleiter*innen entzogen und zum Gegenstand der Aushandlung in anderen Handlungssystemen werden, in denen sie weniger starke Machtpositionen einnehmen.

Die Strategie des Vorstands, über das Budget den Einsatz von eMed zu motivieren und damit verlässliche Informationen für die OP-Koordinator*in zu generieren, geht aber nicht auf, da es den Abteilungsleiter*innen gelingt, die Widersprüche zwischen den Modellen des Organisierens von IS-H und i.s.h.med auszunutzen. Diese Widersprüche entstehen vor allem dadurch, dass die Unsicherheiten der Krankenbehandlung in den Modellen von IS-H eher für die Zwecke des Rechnungswesens kontrolliert werden, in den Modellen von i.s.h.med aber vor allem die Koordination der Akteur*innen zum Zweck der medizinisch adäquaten Behandlung im Vordergrund stehen. Dass die Abteilungsleiter*innen diese Widersprüche nutzen, zeigt sich daran, welche formalen Regeln zum Umgang mit eMed von ihnen gestützt und welche ignoriert werden.

Die prinzipielle Annahme, auf der eMed basiert, bringt mit sich, dass DRG-relevante Daten für alle Nutzer*innen transparent werden, die Zugang zur Datenbasis der Software haben. Technisch wäre es möglich, Operationen auch ohne Angabe der Verbrauchsmaterialien zu dokumentieren: Im Gegensatz zu anderen Elementen der Dokumentation wie zum Beispiel den Leistungen handelt es sich bei den Verbrauchsmaterialien nicht um Pflichtangaben, deren Eingabe beim Umgang mit der Software automatisch überprüft wird. Der Verzicht auf die Eingabe der Verbrauchsmaterialien hätte für die Abteilung aber finanzielle Nachteile: Die Abteilungen als für die „Produktion“ verantwortliche Organisationseinheiten bestellen Verbrauchsmaterialien intern über eMed. Damit können Materialkosten automatisch Abteilungen zugerechnet werden – was für die Budgetberechnung auch genutzt wird. Abteilungsleiter*innen sorgen mit ihrem Einfluss dafür, dass ihre Mitarbeiter*innen jene Daten vollständig und korrekt eingeben, die für die Berechnung des Abteilungsbudgets relevant sind, und arbeiten in dieser Hinsicht dem Vorstand in die Hände. Diese Kooperationsbereitschaft mit den Zielen des Vorstands beschränkt sich aber auf Daten, die aus der eMed-Datenbank einfach zu extrahieren sind, weil Standardberichte dafür existieren. Solche Berichte gibt es nur für Daten, die entweder den für einen industriellen Produktionsprozess relevanten entsprechen oder relevant für die Zuordnung eines Falls zu einer Fallgruppe sind und daher bei der Entwicklung von IS-H neu für die Organisationen im Gesundheitswesen modelliert wurden.

Vorgeschrieben ist auch die Dokumentation der Prozesszeiten, also die Angabe, welche Mitarbeiter*innen wann welche Teilaufgaben erledigt haben. Diese Daten sind eigentlich für die Kostenrechnung relevant und müssten damit theoretisch auch eine Rolle für die Bestimmung von Abteilungsbudgets spielen, in welchen die in der Abteilung verursachten Kosten berücksichtigt werden. Sie können in eMed auch eingegeben werden. Mit eMed ist es aber schwierig, Prozesszeiten systematisch auszuwerten.

Dr. Mosser (OP-Koordinator): Hab‘ ich ja auch schon gesagt, dass das manchmal schwierig ist hier, fallbezogene Kostenrechnung […] und natürlich auch die zeitliche Bindung des Personals, das ist ja ein ganz wesentlicher Faktor. Wir sind hier aber nicht so weit. […] Und natürlich ist auch die Zuordnung von Prozesszeiten nicht möglich […] So dass [die Sanusklinik] sich quasi ‘ne Extra-Firma leistet, die die Daten aus SAP aufarbeitet, um sie dann ins [Drittsystem] zu stellen. Das ist so ‘n mehr oder weniger webbasiertes Tool, was sämtliche Zahlen, egal ob jetzt Verwaltung, Finanzen, Prozesse, in so ein WebTool packt, das man hier unterschiedlich […] benutzt, um zu sehen, welche Zahlen was machen.

Die Daten aus eMed werden von Mitarbeiter*innen der Controllingabteilung erhoben und unter anderem als Entscheidungsgrundlage für den Vorstand aufbereitet. Auch diese Mitarbeiter*innen sind (wie der OP-Koordinator Dr. Mosser) dem langfristigen Ziel verpflichtet, die Arbeitsprozesse im OP-Bereich effizienter steuerbar zu machen. Die Daten der Standardberichte aus eMed bilden diese Arbeitsprozesse zwar nur unvollständig ab, doch das IT-Projekt, das passendere Berichte (die z. B. Prozesszeiten beinhalten) und damit eine genauere Übersicht über die Kosten erlauben würde, wird erstmal auf die lange Bank geschoben.

Dr. Mosser (OP-Koordinator): Das Controlling will's auch nicht. Die wollen zwar vordergründig Zahlen wissen, wissen aber, dass das mit so viel Arbeit verbunden ist für die. Die sind auch nicht so ausgestattet, dass die das bei ihnen erledigen können, und sind da deswegen eher so: Ja, hm, hm, mal kucken.

Fehler oder Lücken in der OP-Dokumentation werden in den Spielen um die Ressourcenverteilung damit nur zum Problem, wenn es sich um Daten handelt, die von eMed verpflichtend abgefragt und in Standardberichten zusammengefasst und ausgegeben werden. Die relevante Ungewissheitszone „Informationen über das Geschehen in den Abteilungen“ wird dadurch entscheidend verändert: Erlöse und Kosten nach der Definition von eMed werden für alle sichtbar, die Zugang zu den Berichten von eMed haben. Sie sind damit nicht mehr ungewiss in den Spielen um die Steuerung des OP-Bereichs. Über den Rest weiß nur Bescheid, wer vor Ort ist und das Geschehen in der Abteilung unmittelbar beobachten kann – zum Beispiel Dr. Mosser, der OP-Koordinator. Das so erworbene Wissen bleibt aber ein anekdotisches, das jederzeit bestritten werden kann. Dies tun die Abteilungsleiter*innen auch, wenn der OP-Koordinator sie mit Regelverletzungen beim Umgang mit eMed, mit offensichtlichen Planungsfehlern oder anderen Praktiken konfrontiert, mit denen sie verhindern, dass im OP-Bereich sorgsamer mit den knappen Ressourcen umgegangen wird:

Dr. Mosser (OP-Koordinator): So was kann man nur aufbrechen, indem man möglichst exakt dokumentiert und auch wirklich klar zeigen kann: Letzten Dienstag, letzten Donnerstag und die drei Wochen vorher hast du bei 15 oder bei 25 oder bei 35 Fällen immer das und das und das und das gemacht. […] Wenn ich solche Dinge anspreche, […] dann heißt es: Das stimmt überhaupt nicht! Das war unvorhersehbar. […] Also es gibt tausend Gründe, warum das im Zweifelsfall nicht stimmt.

Der OP-Koordinator kann sein Wissen um das Geschehen im OP-Bereich anders als geplant in den Spielen um die Ressourcenverteilung nicht einsetzen, weil eMed ihm nicht die Daten liefert, mit denen er seine Beobachtungen belegen könnte.

Vorstand, Abteilungsleiter*innen und Mitarbeiter*innen im Controlling erreichen mit der beobachteten Nutzung (korrekte Dokumentation von Operationen in den leicht aus eMed extrahierbaren Datenfeldern), die von Abteilungsleiter*innen bei ihren Untergebenen durchgesetzt wird, einen temporären Kompromiss: Die Abteilungen erhalten ein möglichst hohes Budget und behalten einen großen Teil der Kontrolle über die abteilungsinternen Abläufe. Der Vorstand erhält eine vollständigere Dokumentation der Operationen und kann dadurch höhere Erlöse bei den Kostenträger*innen erzielen. Eines von zwei Zielen der Einführung ist damit vorerst erreicht. Die OP-Koordinator*in kann sich mit dem Wunsch nach besseren Prozessdaten zunächst nicht durchsetzen, gibt aber das Ziel nicht auf, langfristig doch noch zu den Mitarbeiter*innen durchzudringen und sie davon zu überzeugen, dass sie durch einen regelkonformen Umgang mit eMed (also insbesondere die Eingabe korrekter Daten bei OP-Planung und OP-Dokumentation) auch ihre eigenen Ziele (z. B. berechenbarere Arbeitszeiten) erreichen können.

Die Analyse der Spiele um die Steuerung der Ressourcenverteilung im OP-Bereich hilft dabei, auch die Planungspraktiken in der allgemeinen Chirurgie besser zu verstehen. Anders sieht es bei den Planungspraktiken in der Speziellen Chirurgie aus. Auch deren Planung ist für Außenstehende unvorhersehbar, doch dies kann nicht allein dadurch erklärt werden, dass die Akteur*innen in ihren Strategien für die Planungsspiele ihre Strategien für die verketteten Spiele im OP-Bereich berücksichtigen. Stattdessen wird der Umgang mit eMed bei der Planung in der Speziellen Chirurgie vor allem durch abteilungsinterne Spiele beeinflusst.

4.4.3 Planungsspiele in der Speziellen Chirurgie

Die Spezielle Chirurgie ist die größte chirurgische Abteilung der Sanusklinik. Etwa fünfzig Chirurg*innen mehrerer verwandter Fachgebiete sowie dreißig OP-Pflegekräfte arbeiten in sechs Operationssälen, die räumlich abgeschlossen einen eigenen Bereich bilden. Wie die Allgemeine Chirurgie hat auch die Spezielle Chirurgie eine sehr hohe Notfallquote. Während sich aber Mitarbeiter*innen aus der Allgemeinen Chirurgie bereitwillig am Customizing von eMed beteiligt und ihren Einfluss genutzt haben, um die Prozessmodelle in der Software so weit wie möglich an die in ihrer Abteilung etablierten Planungsprozesse anzupassen, wird der Umgang mit eMed in der speziellen Chirurgie vor allem als Verwaltungstätigkeit betrachtet (vgl. den Einstieg von 4.4). Die Mitarbeiter*innen der Speziellen Chirurgie erreichen bei der OP-Planung mit eMed nicht annähernd die gelassene Routine, die in der Allgemeinen Chirurgie vorherrscht. Nicht nur für den OP-Koordinator ist der OP-Plan der Speziellen Chirurgie unverständlich. Auch innerhalb der Abteilung können die Mitarbeiter*innen den Plan kaum zur Übersicht nutzen. Dabei scheint gerade die Planungspraxis dieser Abteilung auf den ersten Blick darauf ausgelegt, allen Mitarbeiter*innen möglichst viel Einblick zu ermöglichen.

In der speziellen Chirurgie erstellen Chirurg*innen die OP-Aufträge oder beauftragen eine Sekretär*in damit, sie anzulegen und die Pflichtfelder vorerst auf Basis der Daten aus der Patient*innenakte auszufüllen. Aus den anstehenden Aufträgen stellen die Dienst habenden Chirurg*innen den OP-Plan des Folgetages gemeinsam in der morgendlichen Konferenz zusammen. Nach der Konferenz wird dieser wieder einer Sekretär*in übergeben, welche ihn (und alle Änderungen und Ergänzungen der OP-Aufträge, die im Sekretariat erstellt worden sind) in eMed überträgt. Durch dieses Vorgehen wissen alle bereits am Vortag, welche Operationen wann und wo anstehen.

Anders als in der allgemeinen Chirurgie wird die relevante Ungewissheitszone „alle anstehenden Operationen“ nicht von einer zentralen Planer*in kontrolliert; die Planung wird kollegial ausgehandelt. Auch für die Entscheidung, wer bei welchem Eingriff als Operateur*in eingeteilt wird, gibt es keine klar definierten Verantwortlichkeiten. In eMed werden die Operateur*innen direkt benannt, nicht nur die Teams, in denen sie arbeiten. Da „Operateur“ ein Pflichtfeld ist, muss bei der Auftragserstellung eine konkrete Person zugeordnet sein. Ob diese Zuordnung bestehen bleibt, ist Teil der Entscheidungen über den OP-Plan, die in der Morgenbesprechung getroffen werden.

Die leitende Oberärzt*in ist zwar auch in der Speziellen Chirurgie formal für die Planung, die Absprachen mit den Leitungen von Pflege und Anästhesie und die Koordination der Notfälle verantwortlich. Anders als der Planer der Allgemeinen Chirurgie widmet sie sich dieser Aufgabe jedoch nicht systematisch. Bei Notfällen organisiert sie zwar Anästhesist*innen für ungeplante Operationen, doch mit den Pflegekräften wird nur sporadisch über solche Veränderungen im Plan gesprochen. Mit dem Einfügen des OP-Auftrags in den Tagesplan ist die Pflege ausreichend informiert, so ihre Haltung. Die stellvertretende OP-Leitung der zugeordneten pflegerischen Abteilung ist anderer Meinung.

Frau Petschel (stellv. OP-Leitung der Speziellen Chirurgie): Der organisierende Anästhesist informiert mich. Oder eine Kollegin aus dem Saal ruft mich an: Ob ich schon gesehen hätte, dass dieser Patient weg ist, dafür ein neuer. Und selten ruft der leitende Oberarzt an, so wie es sein soll. […] Die Anrufe kommen leider nicht zuverlässig und zeitnah. […] Dann hab‘ ich nur Stress und muss umorganisieren und dafür sorgen, dass das Personal auch diese OP kann.

In Fällen, in denen Patient*innen ohne OP-Auftrag im OP-Bereich eintreffen und spontan operiert werden sollen, erfüllen die Pflegekräfte ihre Verpflichtung, alle Operationen in eMed zu dokumentieren, indem sie sie über Notfallanmeldungen in der Software eintragen. Diese Funktion erlaubt es, Operationen ohne vorherigen OP-Auftrag in den Tagesplan einzufügen und sofort zu dokumentieren. Sie ist für die seltenen Fälle eingerichtet, in denen Patient*innen direkt nach der Einlieferung ins Krankenhaus operiert werden müssen und verlangt umfangreiche Nacharbeiten, bei denen die fehlenden administrativen und medizinischen Daten an den richtigen Stellen in der Software eingefügt werden müssen. In der Speziellen Chirurgie müssen die Pflegekräfte täglich mehrere Eingriffe als Notfälle in eMed anmelden, was entsprechend viel Arbeitsaufwand nach sich zieht und auch zu Fehlern in der Dokumentation führt: Die Pflegekräfte, die zu Beginn der Operation erst Anmeldungen erstellen müssen, vergessen häufig Einzelheiten, die sie dokumentieren müssten. Das regelmäßige Nacharbeiten bindet überdies Personal an den Bildschirm, das eigentlich im Operationssaal gebraucht würde.

4.4.3.1 Widerstände

Einerseits gilt der OP-Plan in eMed sowohl in der Pflege als auch in der Chirurgie als die gemeinsame Basis für den Informationsaustausch zwischen den Mitarbeiter*innen der beiden Berufsgruppen. Andererseits verhindern gerade die Chirurg*innen, dass der OP-Plan für einen erfolgreichen Informationsaustausch genutzt werden kann, weil sie systematisch fehlerhafte Eingaben machen. Unvollständige Leistungen und irreführende Angaben zu Operateur*innen sind selbst in den Aufträgen für regulär geplante Operationen alltäglich.

Die Abteilungsleiter*in setzt beispielsweise kurz vor geplantem Operationsstart noch diagnostische Untersuchungen an, entscheidet, dass Chirurg*innen andere als die geplanten Eingriffe durchführen sollen oder setzt kurzfristig eigene Operationen auf den Plan.

Ihre Mitarbeiter*innen tun es ihr gleich: oft entscheiden sie laut eigener Aussage erst kurz vor OP-Beginn, wie umfangreich der Eingriff werden wird. Die OP-Aufträge sind da schon lange erstellt und in den Plan eingetragen – unvollständig. Viele Chirurg*innen der Abteilung setzen auf die Koordination auf Zuruf:

Frau Petschel (stellv. OP-Leitung der Speziellen Chirurgie): Bei ganz vielen Patienten erfahre ich dann von meinen Kollegen, oh. Meistens, wenn die die Chirurgen sehen, besprechen die schon: Bei der nächsten OP, gibt’s was Besonderes? Und dann heißt es: Ja, da müssen wir noch dies und das machen. […] Wir machen auch Team Time-Out.^{Footnote 24} Und oft wird dann erst festgestellt, bevor Schnitt gemacht wird, was noch genau geplant ist bei dem Patienten. Im Team Time-Out. Und das ist zu spät.

Nicht nur die zu Eingriffen angegebenen Informationen sind oft unvollständig, auch die personelle Besetzung lässt sich aus dem Plan nicht zuverlässig ablesen.

Frau Petschel (stellv. OP-Leitung der Speziellen Chirurgie): Und oft gibt es Probleme: Die Chirurgen sind festgelegt, welcher Operateur, welche Assistenten. Dass die nicht abrufbar sind. Nicht ans Handy gehen, oder keine Zeit haben, dass es Veränderungen gibt. […] Wenn der Patient reinfährt, werden die Chirurgen informiert. Und oft dann passiert [es] erst, dass kein Operateur zur Verfügung steht.

Die Suche nach der für die Operation (oder den nächsten Teil der Operation) verantwortlichen Person ist häufig ein Grund für Wartezeiten: ein fast vollständiges OP-Team steht um eine (je nach Phase bereits narkotisierte und teiloperierte) Patient*in und wartet auf die für den nächsten Schritt verantwortliche Operateur*in. Ob und inwiefern Patient*innen dadurch (abgesehen von dem Zeitverlust) Nachteile erleiden, ist nicht bekannt und wird auch in der Sanusklinik nicht thematisiert. Sicher ist, dass Wartezeiten aus organisatorischer Perspektive problematisch sind. Die Spezielle Chirurgie, in der es häufig nicht genug Säle für anstehende Operationen gibt, verliert dadurch nicht nur wertvolle Saalkapazitäten, auch die Motivation der Mitarbeiter*innen leidet darunter:

Dr. Mosser (OP-Koordinator): Weil das natürlich, wenn das über Jahre so geht, bei den Mitarbeitern auch engramiert ist. Ja? Hier wird im Prinzip mit unserer Arbeitskraft Schindluder getrieben, also wir werden nicht als wichtig wahrgenommen und es spielt überhaupt keine Rolle. Hauptsache, es zentriert sich um die Sonne.

Pflegekräfte, Anästhesist*innen und auch Chirurg*innen empfinden die schlechte Planung als Zeichen der Missachtung. Die „Sonne“, die der OP-Koordinator anspricht, ist die Abteilungsleiter*in der Speziellen Chirurgie. Ihre Eingriffe in den Plan führen regelmäßig zu Wartezeiten. Da sie selbst die OP-Pläne nicht respektiert und auch bei ihren Mitarbeiter*innen kein anderes Verhalten durchsetzt, wird sie für die schlechte Planung verantwortlich gemacht. Pflegekräfte haben wenig Einfluss auf die Planungsprozesse, aber üben sporadisch passiven Widerstand: Es kommt vor, dass die einzigen Pflegekräfte, die eine lange und komplexe Operation unterstützen könnten, zum geplanten Startzeitpunkt gerade zu ihrer Mittagspause aufgebrochen sind, so dass die Operation auf den nächsten Tag verschoben werden muss. Als Begründung dafür, dass die OP-Leitung solche Pausen erlaubt, kann dann die generelle Unzuverlässigkeit des Plans herhalten.

Die Koordination in der speziellen Chirurgie funktioniert also mehr schlecht als recht: Es wird zwar operiert, aber von einer effizienten Steuerung der Arbeitsprozesse, durch die Patient*innen eine adäquate Behandlung erhalten und bei der gleichzeitig sorgsam mit den Ressourcen des Krankenhauses (inklusive der Motivation der Mitarbeiter*innen) umgegangen wird, ist die Abteilung weit entfernt. Den Mitarbeiter*innen aller Berufsgruppen gelingt es nicht, die für die Lösung des Handlungsproblems notwendigen Informationen rechtzeitig unter allen Personen zu verbreiten, die sie brauchen. Dies stört nicht nur den OP-Koordinator, sondern – anders als in der Allgemeinen Chirurgie – vor allem die Mitarbeiter*innen. Nicht nur für Pflegekräfte und Anästhesist*innen ist die Situation von Nachteil. Auch die Chirurg*innen trifft die Folgen der unzuverlässigen Planung regelmäßig, nämlich dann, wenn Operationen, die sie selbst durchführen wollen, kurzfristig abgesetzt werden, und sich dadurch die Behandlung ihrer eigenen Patient*innen verzögert.

4.4.3.2 Verteilung der Kontrolle im Spiel mit eMed

Das Planungsspiel mit eMed in der speziellen Chirurgie unterscheidet sich stark von dem in der allgemeinen Chirurgie. Über die Software werden fast alle Aspekte der Unsicherheit bei der OP-Planung in beiden Abteilungen auf identische Weise reduziert. Unterschiede gibt es nur bei den abteilungsspezifischen Vorgaben zu möglichen Operateur*innen im Plan: Teams sind es in der allgemeinen, Individuen in der speziellen Chirurgie. Die Modelle des Organisierens und damit auch Kontrollversuche, die über eMed vermittelt werden, sind gleich. Was sich unterscheidet, ist die Art und Weise, wie die Kontrolle in den beiden Handlungssystemen verteilt ist.

Die Abteilungsleiter*in hat durch ihre Stellung in der Hierarchie der Sanusklinik und mehr noch durch ihren professionellen Status als renommierte Chirurg*in Befehlsgewalt über die Chirurg*innen in der Speziellen Chirurgie. Für die Software interessiert sie sich ebenso wenig wie für die Planung, in die sie immer wieder unvorhersehbar eingreift. Mitarbeiter*innen arrangieren sich (im Zeitraum, der für diese Untersuchung rekonstruiert worden ist) mit diesen Eingriffen; solange die Abteilungsleiter*in nicht interveniert, sind sie frei zu tun, was sie für richtig halten. Die Abteilungsleiter*in spielt nicht direkt im Planungsspiel mit; sie kann sich darauf verlassen, dass Untergebene das Handlungsproblem der OP-Planung irgendwie lösen. Gegen die ständige Unzuverlässigkeit des Plans unternimmt sie nichts – zumindest nichts, was in der Abteilung als Versuch der Problemlösung wahrgenommen wird. Im Spiel um die Steuerung des OP-Bereichs ist der unzuverlässige OP-Plan sogar vorteilhaft: Verlässliche Informationen über das Geschehen in der speziellen Chirurgie sind nicht nur nicht aus eMed zu bekommen, sondern allgemein rar.

Obwohl die Chirurg*innen ebenfalls unter der schlechten Koordination leiden, geben sie weiterhin selbst systematisch falsche Angaben in den OP-Plan ein. Auch regelmäßige Appelle, die die OP-Leitung an die leitende Oberärzt*in richtet, bleiben folgenlos. Die kollegiale Planung führt dazu, dass die leitende Oberärzt*in keine der Ungewissheitszonen im Spiel kontrolliert. Bei der OP-Planung fehlen systematisch Angaben über die personelle Besetzung der Operationen (weil falsche Operateur*innen angegeben werden) und das Operationsaufkommen insgesamt (weil OP-Aufträge ganz fehlen), was die Lösung des Handlungsproblems immer wieder zum Scheitern bringt.

Im Planungsspiel der Speziellen Chirurgie allein findet sich keine Erklärung für die ständigen Fehleingaben der Chirurg*innen. Doch sind diese, anders als die Pflegekräfte, bei der Planung in ein weiteres Spiel verwickelt, das höhere Gewinne verspricht als eine reibungslos verlaufende Planung. Informationen über eine einzelne Operation, die im Planungsspiel der Abteilung nur in der Gesamtschau wertvoll sind, sind Ressourcen der Chirurg*innen in den Spielen um die chirurgischen Karrieren.

4.4.4 Spiele um die chirurgischen Karrieren

Bei der OP-Planung werden nicht nur Patient*innen disponiert, sondern auch Chirurg*innen. Die Frage der personellen Besetzung – wer operiert was – stellt ein eigenes Handlungsproblem dar, dem weit über eine reine Dienstplanung hinaus Bedeutung zukommt. Dieses Handlungsproblem ist typisch für die Chirurgie und überall mit dem Handlungsproblem der OP-Planung verbunden – zumindest dort, wo Medizin und Krankenbehandlung ähnlich wie in modernen westlichen Industriegesellschaften organisiert sind (Vogd 2004b; Egger und Wagner 1993).^{Footnote 25}

Das Operieren bildet den Kern der beruflichen Tätigkeit in der Chirurgie. Um aufzusteigen, müssen Chirurg*innen lernen, sowohl häufig zu erwartende Eingriffe als auch komplizierte und seltene Operationen durchführen zu können. Angehende Chirurg*innen müssen eine umfangreiche Menge an Operationen in vorgeschriebenen Bereichen absolvieren, um zur Fachärzt*innenprüfung zugelassen zu werden. Da Operieren zu großen Teilen eine handwerkliche Fähigkeit ist, die habitualisiert werden muss, kann auch nach der Fachärzt*innenprüfung nur Karriere machen, wer die Gelegenheit bekommt, möglichst viele und auch möglichst komplizierte Operationen durchzuführen. Solche komplizierten Operationen sind selten und bei allen begehrt, die Interesse daran haben, sich beruflich weiterzuentwickeln. Die Sanusklinik ist eine große und renommierte Universitätsklinik, in der deutlich mehr von diesen komplizierten Operationen anfallen als in einem gewöhnlichen Krankenhaus. Passend dazu finden sich hier auch unter den Mitarbeiter*innen mehr Chirurg*innen, die sich von dieser herausfordernden Arbeitsumgebung angezogen fühlen und großes Interesse daran haben, für solche komplizierten Operationen eingeteilt zu werden. So, wie die Verfügbarkeit von chirurgischem Personal eine Ungewissheitszone im Planungsspiel darstellt, ist umgekehrt der Zugang zu den Operationen eine relevante Ungewissheitszone im Karrierespiel. In den meisten Abteilungen wird diese Zone von der OP-Planer*in kontrolliert, die damit eine Machtposition in der Abteilung einnimmt.

Dr. Graf (Oberarzt der Unfallchirurgie): Allgemein versuchen die Leute natürlich auch schon, den OP-Planer zu beeinflussen. Das ist schon klar. Aber ob der Einfluss Erfolg hat, weiß ich nicht. […] Und der OP-Planer weiß auch um seine Macht. Weil er für die Assistenzärzte die mächtigste Person ist. Und das heißt natürlich, mit dieser Person legt man sich nicht an. Weil das unter Umständen für sie negativ ist. Das heißt, es kann sein, sie werden nicht so berücksichtigt, wie sie vielleicht es gerne hätten. Also es ist auch Machtinstrument. Und man kann auch dann […] die Leute bestrafen indem man sagt: Ok, für die nächsten Tage wirst du jetzt nicht in die OP eingeteilt, weil du das und das sozusagen ausgefressen hast. Und zur Bestrafung kommst du nicht in den OP.

Fragt man die Chirurg*innen der Sanusklinik,^{Footnote 26} wie sie selbst diese Chancen zur beruflichen Weiterentwicklung auf die Assistenzärzt*innen verteilen, wenn sie planen, behaupten sie, vor allem auf medizinische und organisatorische Anforderungen wie die nötige Expertise oder die Geschwindigkeit der Operateur*in zu achten. Sie geben an, dass sie auch die Ausbildungsbedürfnisse der Kandidat*innen berücksichtigen und sich um Fairness bemühen. Fragt man jedoch Pflegekräfte und Sekretär*innen mit Planungsrechten, also Akteur*innen, die die Planung kennen, aber nicht am Karrierespiel beteiligt sind, sagen sie aus, dass Status und gute Beziehungen eine weit größere Rolle spielen, als Chirurg*innen eingestehen. Dass die personelle Besetzung bestimmter Operationen Gegenstand machtvoller Auseinandersetzungen ist, ist jedoch ein offenes Geheimnis:

Dr. Graf (Oberarzt der Unfallchirurgie): Es gibt natürlich auch immer dann so gewisse Gruppenbildungen. Und da findet dann schon auch, was so ein bisschen negativ ist, Günstlingswirtschaft statt. […] Es bilden sich schon da so Grüppchen, die da … Also die Gruppe unterstützt sich dahingehend, dass sie da sozusagen an die Töpfe ran wollen.

Beim Versuch, für eine der komplizierten Operationen eingeteilt zu werden gibt es verschiedene Gewinnstrategien: Wer gute Argumente und ein gutes Verhältnis zu leitenden Oberärzt*innen oder der Abteilungsleiter*in hat, kann deren Entscheidung einfacher zu den eigenen Gunsten beeinflussen und auf diese Weise an solch einer begehrten Operation beteiligt werden. Das Wort der Abteilungsleiter*in ist in allen Abteilungen Gesetz, auch wenn nicht alle Abteilungsleiter*innen dies so offen zeigen wie jene der Speziellen Chirurgie. Oft gibt es allerdings mehrere Interessengruppen mit ähnlich starkem Einfluss in der Abteilung, die alle versuchen, die Planer*in auf ihre Seite zu ziehen. Dr. Schneider, Oberarzt in einer anderen chirurgischen Abteilung der Sanusklinik, in der die Planungsverantwortung rotiert, berichtet: Jedes Mal, wenn eine der begehrten Operationen auf dem Plan auftaucht, verbringe er viel Zeit mit Telefonaten mit verschiedenen Kolleg*innen. Diese rufen ihn an, um ihm darzulegen, warum ihre favorisierte Kandidat*in unbedingt für den Eingriff eingeteilt werden muss.

Die Frage, wer in der Speziellen Chirurgie welche konkrete Machtposition im Karrierespiel einnimmt, ist im Rahmen der Untersuchung nicht geklärt worden. Für den Umgang mit eMed sind die Details dieser Machtverteilung unter den Chirurg*innen jedoch weniger bedeutsam als die Rolle, die die Modelle des Organisierens in der Software für die Kontrolle relevanter Ungewissheitszonen spielen. Die für die Frage dieser Arbeit bedeutsame relevante Ungewissheitszone bilden die Informationen über das Operationsaufkommen. In der Speziellen Chirurgie gibt es keine Akteur*in, die diese Ungewissheitszone alleine kontrolliert. Da Informationen über Patient*innen, die einen der seltenen Eingriffe benötigen könnten, auf verschiedenen Wegen (z. B. über die verschiedenen Ambulanzen, die Spezialsprechstunden einzelner Bereiche der Abteilung oder Konsile für nicht-chirurgische Abteilungen der Klinik) eingehen können, pflegen ehrgeizige Chirurg*innen die Beziehungen, die über die Abteilungsgrenzen hinausreichen, um frühzeitig von solchen Patient*innen zu erfahren. Sobald aber ein Eingriff auf den OP-Plan gesetzt wird, ist er für alle Akteur*innen im Spiel sichtbar; die Unsicherheit löst sich auf und die Inhaber*innen der Machtpositionen können beginnen, die Besetzung untereinander auszuhandeln. Um solche Einflussnahme zu verringern oder eigene Besetzungswünsche ohne Intervention hierarchisch höherstehender Chirurg*innen der Abteilung durchzusetzen, sind verdeckende Strategien vor allem für die Chirurg*innen interessant, die keine besondere Machtposition in der Speziellen Chirurgie besetzen. Solche Strategien basieren darauf, begehrte Operationen so lange wie möglich vor machtvolleren Akteur*innen zu verbergen.

4.4.4.1 Widerstände

Die fehlerhaften OP-Aufträge in der Speziellen Chirurgie und ihre Folgen für den Erfolg des Planungsspiels sind in 4.4.3.1 beschrieben. Vor dem Hintergrund des Karrierespiels erscheint das Verhalten, das aus Sicht der Pflegekräfte und Anästhesist*innen wie eine systematische Nachlässigkeit der Chirurg*innen bei der Erstellung von OP-Aufträgen aussah, als rationale Strategie zur Nutzung von eMed: Wer die Einflussnahme machtvoller Akteur*innen auf die Entscheidung über die personelle Besetzung bestimmter Operationen verhindern will, muss die Details dieser Operationen so lange wie möglich geheim halten. Dazu muss ein Zeitraum für die Operation eingeplant werden, ohne dass offensichtlich wird, dass es sich um einen der begehrten Eingriffe handelt. Ein anderer Grund, die Details eines solchen Eingriffs so lange wie möglich zu verbergen ist, dass derjenige, der über die Besetzung entschieden hat, eine Chirurg*in als Operateur*in eingeteilt hat, die einflussreiche Gegner*innen in der Abteilung hat. So, wie junge Chirurg*innen hoffen können, von einem guten Verhältnis zur Abteilungsleiter*in und den leitenden Oberärzt*innen zu profitieren, so müssen sie auch fürchten, dass eine dieser einflussreichen Personen ihnen im Fall eines Konflikts Steine in den Weg legen und versuchen wird zu verhindern, dass sie in Zukunft für eine der begehrten Operationen eingeteilt werden. In eMed ist es nicht möglich, Operationen einzuplanen, ohne dass der OP-Auftrag Details zum Eingriff und zur personellen Besetzung enthält. Was möglich ist, sind unvollständige Informationen über die Operation. Solche Informationen, also zum Beispiel die Angabe nur eines Teils aller Prozeduren, die eigentlich bei dem Eingriff durchgeführt werden sollen, sind typisch für die OP-Aufträge in der Speziellen Chirurgie. Sie ermöglichen es, dass die Akteur*innen im Karrierespiel verdeckende Strategien wie die benutzen, die im Folgenden beispielhaft beschrieben werden. Beide Beispiele sind mir aus anderen chirurgischen Abteilungen berichtet worden, in denen ebenfalls kollegial geplant wird. Die erste Strategie ist die schon angedeutete Erweiterung des Umfangs der Operation: Die begehrte Operation wird mit fehlenden Informationen zu einem Zeitpunkt eingeplant, zu dem die Operation einer Konkurrent*in in einem anderen Saal laufen soll. Erst kurz vor OP-Beginn werden die Daten ergänzt, die zeigen, dass die bisher gewöhnlich aussehende Operation für andere interessant sein könnte. Eine Umbesetzung ist dann nicht mehr oder nur mit hohem Aufwand möglich. Vertreter*innen der im Spiel stärkeren Fraktion sind nicht im Dienst, an einen parallelen Operationssaal gebunden oder haben nicht mehr die Zeit, um ihren Einfluss spielen zu lassen. Die zweite Strategie ist die Angabe einer falschen Operateur*in: Wer unpopulären Kandidat*innen zu Operationen verhelfen will, trägt deren Namen erst im Nachhinein in den OP-Bericht ein und vermerkt im Plan Operateur*innen, die auf den ersten Blick nicht auffallen. Diese Strategie schafft Probleme wie die in Abschnitt 4.4.3 beschriebenen Wartezeiten auf die Operateur*in, wenn die im OP-Plan vermerkte Operateur*in nicht über das Manöver informiert ist oder es vergessen hat und nicht bereit ist, um die Ersatzkandidat*in in den Operationssaal zu schicken, wenn sie (als im Plan vermerkte Verantwortliche) von der zuständigen Pflegekraft über den baldigen Beginn der Operation informiert wird.

4.4.4.2 Verteilung der Kontrolle im Spiel mit eMed

Die spezielle Chirurgie wird von ihrer Abteilungsleiter*in dominiert. Die Besetzung von Operationen ist Teil des kollegialen Planungsprozesses. Kollegiales Entscheiden bedeutet in der Praxis aber weder, dass alle formal Beteiligten gleichberechtigt mitsprechen, noch, dass das Ergebnis allen gefällt. Die Machtverteilung und die Spielregeln sind nur weniger sichtbar als zum Beispiel in den hierarchischen Entscheidungsprozessen, die für die OP-Planung in der Allgemeinen Chirurgie charakteristisch sind. Dies gilt vor allem für Außenstehende (vgl. Vogd 2004b, S. 101–103).^{Footnote 27} Alle Mitglieder der Abteilung, die professionellen Status besitzen oder höhere Positionen in der formalen Hierarchie der Abteilung besetzen, können mitspielen. Die einzige Ungewissheitszone, um deren Kontrolle sich alle in den Spielen um die chirurgische Karriere bemühen können, sind die Informationen über das Operationsaufkommen. Wer sich die Chance sichern will, selbst einen besonderen Eingriff durchzuführen oder ihn anderen zuzuschanzen, muss möglichst lange geheim halten, dass so ein Eingriff ansteht.

Durch eMed ist Geheimhaltung schwierig geworden: Durch die größere Transparenz der Prozesse, die durch den Umgang mit der Software entsteht, verringert sich die Ungewissheit über das Operationsaufkommen bereits zu Beginn des Planungsprozesses. Dadurch können die Mitarbeiter*innen der Abteilung, deren Macht auf anderen Quellen als den Informationen über anstehende Operationen basiert (z. B. auf einer besonderen Expertise als Operateur*in, die der Abteilung Ansehen bringt) stärker als zuvor sehen und beeinflussen, was bei der OP-Planung entschieden wird. In den Karrierespielen kämpfen die Chirurg*innen gegeneinander um die Kontrolle über die relevante Ungewissheitszone „Informationen über das Operationsaufkommen“, aber keine einzelne und keine Gruppe kann sie sich dauerhaft sichern. In den Spielen um die Karriere in der Speziellen Chirurgie ist und bleibt diese Kontrolle verteilt.

Die Koordination mit den Pflegekräften fällt diesen Strategien auch deswegen zum Opfer, weil eMed Planung und Dokumentation eng aneinanderknüpft. Den Pflegekräften fällt zwar auf, welche Angaben regelmäßig falsch sind, aber sie haben keinen alternativen Informationskanal, der zuverlässiger wäre als eMed: In den Karrierespielen gibt es keine zentrale Ansprechpartner*in, da jede für sich spielt und diese Konkurrenz auf die verketteten Planungsspiele durchschlägt.

4.5 Modelle des Organisierens in Organisationsspielen

Zusammenfassend lässt sich feststellen, dass sich die Prozesse rund um die OP-Planung vier Jahre nach der Einführung des Krankenhausinformationssystems im OP-Bereich der Sanusklinik teilweise so verändert haben, wie dies vom Vorstand gewünscht worden ist. Es wird aber auch sichtbar, dass die Akteur*innen in den untersuchten chirurgischen Abteilungen sich den Kontrollversuchen, die über die Software auf ihre Arbeitsprozesse ausgeübt werden, ebenso oft entziehen, wie sie ihnen nachgeben. Welche Rolle spielen nun die Modelle des Organisierens in eMed für den Umgang von Chirurg*innen mit der Software in der allgemeinen und speziellen Chirurgie der Sanusklinik?

Die Standardsoftware bringt mehr Einheitlichkeit in den OP-Bereich, vor allem bei der Dokumentation. Die Arbeitsprozesse sind stärker voneinander abhängig, es gibt mehr Daten über jeden einzelnen Arbeitsprozess und eine zentrale Darstellung von dem, was in der Organisation vor sich geht, die für einige Mitglieder der Organisation (insbesondere aus dem Vorstand) zugänglich ist. Betrachtet man die Situation im OP-Bereich der Sanusklinik nach der Einführung des Krankenhausinformationssystems genauer, zeigen sich Lücken und Widersprüche. Der Umgang mit eMed unterscheidet sich von Abteilung zu Abteilung und auch die Software selbst ist nicht so einheitlich, wie es auf den ersten Blick scheint.

Das KIS der Sanusklinik setzt sich aus mehreren technischen Ebenen zusammen, in denen die Organisation unterschiedlich modelliert ist. In ihnen kommen unterschiedliche Vorstellungen davon zum Ausdruck, wie Arbeitsprozesse in einer Organisation am besten kontrolliert werden können. In diesen Vorstellungen finden sich Hinweise auf die sozialen Systeme, in denen die technischen Ebenen entwickelt worden sind, und auf die Tatsache, dass die Modelle aufeinander aufbauen: Der ERP-Kern ist dazu geschaffen, alle Arbeitsprozesse eines produzierenden Unternehmens über Daten abzubilden, sie miteinander zu integrieren und unterschiedliche Perspektiven darauf bereitzustellen, damit die Organisation mit Hilfe dieser Datenbasis von der Organisationsleitung zentral gesteuert werden kann. Das Modell des Organisierens im ERP-Kern ist eines von informationstechnisch vollständig integrierter Industrieproduktion. Die Organisation, die in IS-H abgebildet ist, unterschiedet sich von der des ERP-Kerns nur durch die Art ihrer Produkte: Sie kombiniert Diagnosen und Behandlungselemente zu Fällen, die zu Pauschalpreisen an Kostenträger*innen verkauft werden. Das Krankenhaus wird als „Fallfabrik“ modelliert, die jenseits der Fallproduktion keine systematischen Unterschiede zu anderen Fabriken aufweist. Eine medizinische Perspektive auf das Geschehen ist in einzelnen Elementen angelegt, aber nicht durchgängig umgesetzt. Die integrierten Arbeitsprozesse orientieren sich vor allem an der Perspektive des Rechnungswesens. Diese entspricht in Krankenhäusern jedoch nicht einfach der in produzierenden Unternehmen.

Mit Hilfe der Funktionen des ERP-Kerns ist es möglich, einen Großteil der Kosten in produzierenden Unternehmen durch die Daten zu erfassen, die im Rahmen der Arbeitsprozesse generiert werden. In IS-H werden ebenfalls viele Daten über die Arbeitsprozesse erhoben, aber die Auswahl und Struktur dieser Daten ist an den Vorgaben des DRG-Systems orientiert. In diesem wird davon ausgegangen, dass Fälle der gleichen Kategorie gleiche Ressourcen verbrauchen; die tatsächlichen Arbeitsprozesse sind irrelevant. In i.s.h.med werden die Modelle von IS-H um zusätzliche Modelle und Anpassungen an bestehenden erweitert, in denen eine medizinische Perspektive auf die Arbeitsprozesse abgebildet wird. Aus dieser medizinischen Perspektive gehören zur Repräsentation eines Krankenhauses in Software Modelle, in denen Mitarbeiter*innen mit unterschiedlichen Qualifikationen, medizinische Abteilungen mit fachspezifischen Anforderungen und andere Aspekte der Krankenbehandlung dargestellt werden, die für die Koordination der Arbeitsprozesse im Krankenhaus relevant sind, wenn die adäquate Behandlung von Patient*innen im Mittelpunkt steht. Mit i.s.h.med wird versucht, ein Modell des Organisierens in das KIS einzuführen, in dem Arbeitsprozesse, die nach unterschiedlichen Logiken funktionieren, durch Datenaustausch problemlos miteinander koordiniert werden können. Dies gelingt jedoch nicht, da i.s.h.med zu sehr von den Strukturen von IS-H abhängig ist. Über i.s.h.med werden den Nutzer*innen vor allem zusätzliche Optionen angeboten, die den Umgang mit dem KIS komplizierter machen. Die systematische Nutzung dieser zusätzlichen Optionen in allen Arbeitsprozessen des Krankenhauses ist in der Praxis schwer durchzusetzen, weil die Modelle in i.s.h.med, in denen die medizinische Perspektive zum Ausdruck kommt, nur Einzelteile der Software betreffen. Die Möglichkeit, das Krankenhaus durchgängig aus der medizinischen Perspektive darstellen zu lassen, bietet i.s.h.med nicht. Die vollständige Integration der Organisationsdaten ist nur aus der Perspektive des Rechnungswesens möglich.

Beim Customizing in der Sanusklinik fallen die Spannungen zwischen den verschiedenen Schichten der Software nicht auf. Die Einführung des komplexen KIS ist aufwändig, der Kernkonflikt des Krankenhauses – ob medizinische Effektivität im Sinne einer adäquaten Krankenbehandlung oder ökonomische Effizienz im Sinne eines sparsamen Umgangs mit verfügbaren Ressourcen wichtiger sind – scheint schon in der Standardversion gelöst. Anpassungen und Erweiterungen der Software werden im Customizingprozess auf ein Minimum beschränkt. Den mächtigen Chefärzt*innen der chirurgischen Abteilungen wird durch abteilungsspezifische Anpassungen gezeigt, dass ihre Autonomie nicht vollständig verschwinden soll. Der Vorstand spielt ein langfristiges Spiel, das zum Teil (vorerst) scheitert, weil aus der buchhalterischen Perspektive im Krankenhaus nicht das erfasst werden kann, was in der Fabrik aus der gleichen Perspektive sichtbar würde. Das Krankenhausinformationssystem, das in der Sanusklinik nach dem Customizing zum Einsatz kommt, und die Logiken der Modelle des Organisierens, die in den einzelnen technischen Ebenen eingebettet sind, sind in Abbildung 4.8 zusammenfassend dargestellt.

Durch Beobachtung der Organisationsspiele wird deutlich, dass die Beschäftigten der Sanusklinik die Software im Arbeitsalltag systematisch anders nutzen, als es vorgesehen ist. Das Modell der informationstechnisch gesteuerten Industrieproduktion des ERP-Kerns koppelt die Praktiken der OP-Planung und -Dokumentation eng aneinander. Durch die Erweiterungen IS-H und i.s.h.med werden die Arbeitsprozesse im OP-Bereich aber nur in den Aspekten vollständig miteinander integriert, die für die standardisierte Abrechnung notwendig sind. Daten, die dafür nicht notwendig sind, können eingegeben, aber schwer überprüft und weiterverarbeitet werden. Formale Regeln der Organisation werden nur dort effektiv durchgesetzt, wo es um diese abrechnungsrelevanten Daten geht.

Die Akteur*innen in den Organisationsspielen machen sich dies zu Nutze, um die Kontrolle über relevante Ungewissheitszonen zu behalten, die durch den exklusiven Zugang zu Informationen über Patient*innen oder Arbeitsprozesse entstehen. In der Allgemeinen Chirurgie tauschen die Leiter*innen der chirurgischen, pflegerischen und anästhesistischen Organisationseinheiten, die in dieser Abteilung zusammenarbeiten, solche Informationen telefonisch aus, um zu verhindern, dass Kolleg*innen innerhalb der Abteilung ihre Arbeit bewerten oder dass sich Außenstehende in die Arbeitsorganisation in der Allgemeinen Chirurgie einmischen. In der Speziellen Chirurgie behalten die Chirurg*innen so viele Details wie möglich so lange wie möglich für sich.

Die Übersetzung der Anforderungen des Gesundheitswesens in IS-H, denen entsprechend das Krankenhaus primär aus buchhalterischer Perspektive modelliert wird, schafft die Illusion, Praktiken im OP-Bereich könnten auf Basis der abrechnungsrelevanten Daten beobachtet und gesteuert werden. Durch die Art und Weise, wie diese Perspektive in den Modellen im Krankenhausinformationssystem umgesetzt worden ist, können alle Akteur*innen formal wie vorgesehen mit dem KIS umgehen, ohne dass sie dabei dazu beitragen müssten, dass die im Customizing-Projekt vorgegebenen Ziele erreicht werden. Beim Umgang mit eMed, der sich im OP-Bereich der Sanusklinik etabliert, können Akteur*innen diese Ziele größtenteils ignorieren und in den Spielen um OP-Planung, Karriere und Ressourcenverteilung weiterhin (wie vor der Einführung von eMed) vor allem ihre eigenen Ziele verfolgen.

Die Praktiken der OP-Planung mit dem KIS werden durch die Software ebenso geformt wie durch die Spiele. Erst die gemeinsame Betrachtung von Software und Spielen ermöglicht es, die innere Rationalität des Handelns der Akteur*innen nachzuvollziehen, also zu verstehen, warum das, was sie tun, auf Basis ihres Wissens, ihrer Ziele und der für sie verfügbaren Handlungsmöglichkeiten als rational betrachtet werden muss.

In der Gesamtbetrachtung zeigt sich an der Fallstudie, dass die Software sowohl in den einzelnen Modellierungsprozessen als auch bei der Anwendung performativ wird. Beim Umgang mit eMed versuchen die Akteur*innen, Kontrolle über die Unsicherheiten der Prozesse im Krankenhaus zu gewinnen oder die Kontrolle, die sie vor Einführung des Krankenhausinformationssystems hatten, zu verteidigen. Durch die Auseinandersetzungen mit der und um die Software wird dabei Kontrolle im Geflecht der verketten Spiele verteilt, in denen Akteur*innen mit dem KIS umgehen. Die Akteur*innen nehmen dabei die Unsicherheitsreduktionen, die in den Modellen enthalten sind, immer auch in Teilen an. Damit vertrauen sie faktisch darauf, dass die Entscheidungen, die bei der Softwareentwicklung über die Modellierung der Krankenbehandlung getroffen worden sind, (auch und zumindest teilweise) den Zwecken dienen, die die Akteur*innen selbst beim Umgang mit der Software verfolgen. Die Nutzer*innen vertrauen damit auch auf die sozialen Systeme, in denen die Modelle in eMed entstanden sind. Durch dieses Vertrauen treten sie einen Teil der Kontrolle über die Prozesse, in denen sie mit eMed umgehen, an diese sozialen Systeme ab. In der Fallstudie wird auch ein Licht auf die Grenzen der Handlungsspielräume der Akteur*innen geworfen, die Erweiterungen des ERP-Kerns entwickeln, und auf die Grenzen der Kontrolle, die sie in ihren Modellierungsprozessen über die Unsicherheiten ausüben, die bei der Nutzung des KIS relevant werden:

(1) Durch die Entscheidungen darüber, wie Unsicherheit in den Modellen der Software reduziert werden soll, die bei der Entwicklung des ERP-Kerns getroffen werden, werden alle weiteren Entwicklungsschritte bis hin zur Anwendung vorstrukturiert. Die meisten Aspekte der Unsicherheit, die die Modellierung eines Krankenhauses mit sich bringt, werden bei der Entwicklung von IS-H nicht bearbeitet. Die Entwickler*innen von IS-H vertrauen auf die Unsicherheitsreduktionen, die in den Modellen des ERP-Kerns vorgenommen worden sind. Damit geben sie Kontrolle über ihr eigenes Arbeitsprodukt (die Software IS-H) an die Entwickler*innen des ERP-Kerns ab. Ob und inwieweit diese Auslagerung von Kontrolle im Entwicklungsprozess von IS-H thematisiert worden ist, ist in der Fallstudie nicht untersucht worden. Aus der Online-Softwaredokumentation und aus dem Umgang der Nutzer*innen mit eMed lässt sich jedoch rekonstruieren, dass die Entwickler*innen von IS-H bei der Modellierung der Arbeitsprozesse eines Krankenhauses nur einen sehr geringen Handlungsspielraum ausgenutzt haben – aus welchen Gründen auch immer.

(2) Die Entwickler*innen von i.s.h.med hingegen nutzen die Handlungsspielräume ausgiebig, die sie beim Umgang mit den Modellen aus dem ERP-Kern und aus IS-H haben, also den Modellen aus den technischen Ebenen, auf die sie ihre Erweiterung aufsetzen. Sie modellieren den Großteil der Arbeitsprozesse im Krankenhaus grundlegend neu und differenzieren ihr Modell des Organisierens damit deutlich von dem des ERP-Kerns. Sie definieren damit in vielen Einzelheiten, wie Aspekte der Unsicherheit im Krankenhausalltag reduziert werden können. Über diese Definitionen werden jedoch nur Details der Nutzung kontrolliert; für die Nutzung der Software ist es nicht notwendig, die neuen Modelle aus i.s.h.med zu übernehmen. Kontrolle über die zentralen Modellelemente, die die Abrechnung und das Berichtswesen strukturieren, verbleibt auch bei der Entwicklung von i.s.h.med in dem sozialen System, das den ERP-Kern gestaltet. Beim Umgang mit dem KIS im Krankenhaus geben die Akteur*innen über ihr Vertrauen in die Modelle zwar Kontrolle über Unsicherheiten in ihren Nutzungsprozessen an die sozialen Systeme ab, in denen die Software produziert worden ist. Welche der Unsicherheitsreduktionen, die in den Modellen enthalten sind, in jedem konkreten Fall angenommen wird, lässt sich aber nicht bei der Softwareentwicklung festlegen. Die Software kann nur Mittel von Kontrollversuchen sein, die Akteur*innen, die mit ihr umgehen, annehmen oder auch ablehnen können. Welche der Kontrollversuche in welchem Ausmaß angenommen werden, ist abhängig von den konkreten sozialen Bedingungen, unter denen die Software eingesetzt wird. Beim Umgang mit eMed im OP-Bereich der Sanusklinik wird der Erfolg dieser Kontrollversuche vor allem durch die professionelle Ordnung, die Organisation des Gesundheitswesens und die konkreten Machtverhältnisse in den einzelnen Abteilungen beeinflusst. Zusammenfassend lässt sich sagen, dass sich durch den Einsatz der Software Kontrolle über die Unsicherheiten in der Sanusklinik innerhalb der Organisation und auch über ihre Grenzen hinaus verschiebt, aber nicht in irgendeinem sozialen System konzentriert wird. Auch wenn die Akteur*innen eine standardisierte Organisationssoftware wie eMed nutzen, die (auch) zu dem Zweck geschaffen worden ist, die Arbeitsprozesse im Krankenhaus zentral steuerbar zu machen, bleibt Kontrolle über die relevanten Ungewissheitszonen der Krankenbehandlung verteilt.

Notes

1.
Das Krankenhausbudget beinhaltet in Deutschland immer auch einen fixen Posten, der nicht für die Behandlungskosten, sondern für den Unterhalt der Gebäude u.ä. gedacht wird. Dieser Anteil spielt in der vorliegenden Arbeit keine Rolle und wird daher nicht weiter ausgeführt.
2.
Alle hier angegebenen Namen und Bezeichnungen aus der Fallstudie sind Pseudonyme.
3.
Der Vorstand nutzt das Budget auch dafür, die Abteilungsleiter*innen zur Einhaltung anderer Regeln der Organisation zu motivieren. So werden Abteilungen, die ihre OP-Berichte nicht innerhalb der vom Vorstand vorgegebenen Frist von sechs Wochen vervollständigen, Anteile der Einnahmen aus den betreffenden Operationen abgezogen.
4.
Weicht die Liegezeit einzelner Patient*innen, also die Zeit, über die diese für eine bestimmte Behandlung stationär betreut werden, zum Beispiel deutlich von der durchschnittlichen Liegezeit für diese Behandlung ab, so bezahlen die Kostenträger*innen nicht die gesamte Fallpauschale, sondern ziehen einen Betrag ab. Diese Abzüge werden an die Abteilung weitergereicht, in der die Patient*in stationär aufgenommen war.
5.
Der Planungszyklus kann abhängig vom Krankenhaus variieren, die genaue Zeitlichkeit (also ob täglich, jeden zweiten Tag etc. für den Folgetag oder für weiter entfernte Tage geplant wird) ändert jedoch nichts an den grundsätzlichen Konturen des Problems.
6.
Eine ausführliche Analyse des Handlungsproblems, die logistische ebenso wie mikropolitische Aspekte, deren Interdependenzen und die Herausforderungen, die daraus für die Entwicklung maßgeschneiderter Software entstehen, deutlich macht, findet sich in Egger und Wagner (1993).
7.
Dieser Vorgang wird Prämedikation genannt.
8.
Eine Ausnahme bilden Fälle, in denen Patient*innen ohne Aufklärung direkt nach der Einlieferung in die Klinik operiert werden müssen, wodurch das Vorgespräch mit der Anästhesist*in und die Einwilligung entfallen. In der Praxis stellen solche Situationen aber die Ausnahme dar, denn auch die meisten dringenden Operationen werden an Patient*innen durchgeführt, die vor dem Eingriff noch bei Bewusstsein sind und in der Regel schon auf einer der Stationen der Klinik liegen.
9.
Für die Analyse des Planungsprozesses gelten als Notfälle hier die Operationen, die kurzfristig, d. h. am gleichen Tag oder am Folgetag, in einen bereits bestehenden OP-Plan eingefügt werden müssen. Was ein Notfall ist, lässt sich nicht allgemein festlegen, sondern hängt trotz bestehender medizinischer Leitlinien endgültig von der Entscheidung der beurteilenden Chirurg*in ab. Die Chance, etwas als Notfall zu definieren, gilt als eine wichtige professionelle Machtressource der Medizin (Freidson et al. 1979, S. 101 f.). Die auch strategische Nutzung der Notfalldefinition wurde bei der Untersuchung als potentiell für die Fragestellung relevantes Element erkannt. Im Laufe des Forschungsprozesses zeigte sich jedoch, dass rein strategische Notfalldefinitionen nicht dazu beitragen, die Rolle von eMed für die Praktiken der OP-Planung in den untersuchten Abteilungen der Sanusklinik zu verstehen. Der Notfall wird daher als ein Aspekt der grundlegenden Problematik der OP-Planung mit zu den durch Patient*innen verursachten Unsicherheiten gezählt.
10.
Diese Beschreibung entspricht einer der technischen Grundstrukturen der Software, der Architektur nach dem Drei-Schichten-Modell, demzufolge Datenhaltungs-, Anwendungs- und Präsentationsschicht konzeptionell und technisch so getrennt sind, dass jede Schicht nur mit den beiden jeweils nächsten über wohldefinierte Schnittstellen Informationen austauschen kann (Ludewig und Lichter 2013, S. 431). Die Anwendungsschicht wird im untersuchten ERP-System als „business logic“ bezeichnet (Mormann 2016, S. 30) und enthält nicht nur Modelle von Geschäftsprozessen in Form von Prozessvorlagen, sondern auch Modelle anderer Organisationsaspekte (a.a.O., S. 54 ff.). Da den Geschäftsprozessen jedoch für die Integration der Praktiken in der Organisation zentrale Bedeutung zukommt, werden sie hier herausgestellt.
11.
Ein Umstand, der auch in der Entwicklung der Bezeichnungen für diese Klasse von Software zum Ausdruck kommt: Vorläufer der standardisierten Organisationssoftware von heute wurden als Systeme für „Materials Requirements Planning“ (MRP), „Manufacturing Resource Planning“ (MRP II) und „Computer-Integrated Manufacture“ (CIM) bezeichnet. Damit wird als Anwendungsgebiet eindeutig die Fertigung genannt, während der vom Industrieanalysten Gartner geprägte Begriff „Enterprise Resource Planning“ (ERP) den Bezug zur Produktion hinter sich lässt (Pollock und Williams 2009, S. 22–24).
12.
Eine Übersicht über verbreitete Erweiterungen findet sich in Boeder und Groene (2014, S. 18).
13.
Zu den Organisationen der Interessenvermittlung im Gesundheitswesen und ihren Beziehungen siehe auch Lange (2016) und Gerlinger (2009).
14.
Eine Bewegung liegt vor, wenn sich die Zuordnung zu einer Organisationseinheit ändert (SAP AG o. J.b, „Bewegung (IS-H)“).
15.
Am Fall wird gespeichert, welche Krankheit der Grund für den Aufenthalt war (als Diagnose), wann der Patient zu welchem (vordefinierten) Zweck welcher Organisationseinheit des Krankenhauses zugeordnet war (als Bewegung) und welche Personen dort welche Teile der Pflege oder Behandlung durchgeführt haben.
16.
Die Zuweisung der architektonischen Komponenten von Haas und Kuhn (2011) zu den Systemen IS-H bzw. i.s.h.med ist nicht ganz trennscharf, denn Funktionen wie die medizinische Leistungskommunikation und die fachspezifische Dokumentation werden grundsätzlich von IS-H bereitgestellt und von i.s.h.med genauer ausdifferenziert.
17.
Die Abteilungsbezeichnungen sind für die Fallstudie verändert worden.
18.
Zur spezifisch chirurgischen Ausprägung der professionellen Identität vgl. die Arbeiten von Joan Cassell (1987). Professionssoziologische Studien gibt es dazu nicht. Die hier erwähnten Besonderheiten der Chirurgie im Vergleich zu anderen medizinischen Spezialisierungen werden aber in soziologischen Studien thematisiert, in denen Chirurg*innen Teil des Forschungsgegenstands sind (z. B. Kellogg 2009, 2011). Die auch im Fall beobachtete starke Bedeutung der Hierarchie speziell in der Chirurgie zeigt auch Vogds Arbeit zu ärztlichen Entscheidungsprozessen im Krankenhaus (Vogd 2004a, 2004b).
19.
Das Verhältnis von Planer*in und Teamleiter*innen wurde nicht untersucht. Die Verfügbarkeit von Chirurg*innen der allgemeinen Chirurgie wurde jedoch von keiner der Befragten in irgendeiner Weise problematisiert. Zumindest, soweit es den Umgang mit eMed betrifft, stellt diese Verfügbarkeit im Untersuchungszeitraum und in der rekonstruierten Vergangenheit faktisch keine Ungewissheit der OP-Planung dar, da sie vollständig durch das Arrangement im Handlungssystem kontrolliert und durch die Software auch nicht beeinflusst wird.
20.
Die interne Organisation der pflegerischen und anästhesistischen Abteilungen, die für die Umverteilung von Sälen relevant ist, wird hier nicht betrachtet. Die Untersuchung hat gezeigt, dass der zentrale Konflikt um die Steuerung zwischen Chirurgie und Verwaltung liegt und die anderen Berufsgruppen keine eigenen Steuerungsinteressen verfolgen. Anästhesie und übergreifende Pflegeleitung greifen in der Sanusklinik nicht direkt in das Spiel ein, sondern formulieren ihre Ansprüche gegenüber dem OP-Koordinator, der diese dann gegenüber der Chirurgie vertritt. Die zweifellos existierenden Unterschiede zwischen den Interessen der Verwaltung, der Pflege, der Anästhesie und anderer im OP-Bereich tätigen Berufsgruppen stehen hinter dem Grundkonflikt Chirurgie – Verwaltung zurück. Die professionelle Hierarchie lässt es plausibel erscheinen, dass dieser Konflikt auch in anderen Krankenhäusern primär zwischen diesen beiden Gruppen ausgetragen wird; erwartet werden sollten aber klinikspezifische Unterschiede in der Frage, ob und auf welcher Seite andere Berufsgruppen beim Steuerungsspiel mitspielen.
21.
Solche „Notfallanmeldungen“ sind bei den Pflegekräften extrem unbeliebt, weil sie viel Zeit für Nacharbeit verschlingen. Die Pflegekräfte sehen die Erstellung eines vollständigen OP-Auftrags als Aufgabe der Chirurg*innen. In der Speziellen Chirurgie, in der Notfallanmeldungen regelmäßig vorkommen, ist die Nachlässigkeit der Chirurg*innen bei der Dateneingabe ein Anlass zu dauerhaftem Frust bei den Pflegekräften.
22.
Ein Beispiel dafür ist er Umgang mit bestimmten Ausrüstungsgegenständen für Operationen, die in der Sanusklinik Zählobjekte genannt werden: Die Pflegekräfte müssen dokumentieren können, dass bei der Operation keine Ausrüstungsgegenstände im Körper verblieben sind. Daher werden Gegenstände, bei denen dies theoretisch möglich ist, vor und nach der Operation abgezählt und die Anzahl verglichen (daher die Bezeichnung Zählobjekte). Belegbare Sorgfalt in dieser Frage hat für die Sanusklinik Priorität vor anderem: Die Programmierung einer Erweiterung von eMed, mit der die Zählung solcher Objekte vor und nach der Operation dokumentiert werden kann, hat sich im Customizing gegenüber anderen Funktionalitäten durchgesetzt, die z. B. die Planung besser an die Anforderungen der Nutzenden angepasst hätten.
23.
Diagnose und zu erbringende Leistungen werden aus im System hinterlegten Katalogen ausgewählt. Die Kataloge enthalten die von den Gremien des Gesundheitssystems erstellten ICD (Diagnosen) und OPS-(Prozeduren)-Codelisten und Zusatzinformationen (z. B. zur Beatmungszeit), die Grundlage der Berechnung der Fallgruppe bilden.
24.
Im Team Time-Out teilen alle Mitglieder des OP-Teams einander mit, was sie über die geplante Operation wissen. Dabei werden Informationen über die Patient*in, ihren Zustand, Allergien und Vorerkrankungen etc. abgeglichen. Diese Maßnahme soll verhindern, dass der falsche Eingriff durchgeführt, die falsche Seite geöffnet wird oder Medikamente verabreicht werden, die die Patient*in bekanntermaßen nicht verträgt.
25.
Im Rahmen der Untersuchung ist es nicht gelungen, Aussagen von Chirurg*innen in der speziellen Chirurgie der Sanusklinik zum Karrierespiel zu bekommen. Die Spielbeschreibung stützt sich daher auf Daten zum gleichen Spiel in anderen Abteilungen der Sanusklinik und umfangreiche (qualitative) Antworten der schriftlichen Befragung aller formal Planungsberechtigten der Klinik, die nicht einer Abteilung zugeordnet werden konnten. Darüber hinaus habe ich mich vor allem an den Erkenntnissen orientiert, die die Analyse des gleichen Phänomens bei Vogd (2004b, S. 216–218) ergibt. In dieser Analyse wird gezeigt, dass es sich bei den von den Mitgliedern der Sanusklinik geschilderten Spieldynamiken um allgemein chirurgische Dynamiken und nicht um abteilungsspezifische Idiosynkrasien handelt. Dennoch ist die Rekonstruktion des Karrierespiels der speziellen Chirurgie aufgrund der Datenlage stärker eine Konstruktion, die in der Gesamtschau der verketteten Spiele den Umgang mit der Software nachvollziehbar macht, als dies bei den anderen drei Typen von Spielen der Fall ist. Die Rekonstruktion der Planungsspiele in der Allgemeinen und der Speziellen Chirurgie sowie die der Spiele um die Steuerung des OP-Bereichs basierte zu großen Teilen auf Interviews und Beobachtungen zu genau diesen Spielen.
26.
Die Aussagen über die Selbst- und Fremdeinschätzung der Kriterien, die bei der OP-Planung angelegt werden, sind das Ergebnis einer schriftlichen Befragung aller eMed-Nutzer*innen in zwei Krankenhäusern, die über die Berechtigung verfügen, OP-Pläne in der Software zu erstellen. Eines der Krankenhäuser aus der Befragung war die Sanusklinik. Mehr zu dieser Untersuchung findet sich in Engelmann et al. (2017).
27.
Vogd bezieht sich bei seinen Aussagen über die Machtverteilung in medizinischen Abteilungen auf Bourdieus Feldtheorie. Diese ist deutlich spezifischer in ihren theoretischen Vorannahmen als die vorliegende Arbeit, ist aber mit der hier genutzten Herangehensweise vereinbar.

Author information

Authors and Affiliations

Technische Universität Berlin, Berlin, Deutschland
Dzifa Ametowobla

Authors

Dzifa Ametowobla
View author publications
You can also search for this author in PubMed Google Scholar

Corresponding author

Correspondence to Dzifa Ametowobla .

Rights and permissions

Open Access Dieses Kapitel wird unter der Creative Commons Namensnennung 4.0 International Lizenz (http://creativecommons.org/licenses/by/4.0/deed.de) veröffentlicht, welche die Nutzung, Vervielfältigung, Bearbeitung, Verbreitung und Wiedergabe in jeglichem Medium und Format erlaubt, sofern Sie den/die ursprünglichen Autor(en) und die Quelle ordnungsgemäß nennen, einen Link zur Creative Commons Lizenz beifügen und angeben, ob Änderungen vorgenommen wurden.

Die in diesem Kapitel enthaltenen Bilder und sonstiges Drittmaterial unterliegen ebenfalls der genannten Creative Commons Lizenz, sofern sich aus der Abbildungslegende nichts anderes ergibt. Sofern das betreffende Material nicht unter der genannten Creative Commons Lizenz steht und die betreffende Handlung nicht nach gesetzlichen Vorschriften erlaubt ist, ist für die oben aufgeführten Weiterverwendungen des Materials die Einwilligung des jeweiligen Rechteinhabers einzuholen.

Reprints and permissions

Copyright information

About this chapter

Cite this chapter

Ametowobla, D. (2022). Die Rolle von eMed in der OP-Planung der Sanusklinik. In: Zur Soziologie der Software. Springer VS, Wiesbaden. https://doi.org/10.1007/978-3-658-37256-9_4

Download citation

DOI: https://doi.org/10.1007/978-3-658-37256-9_4
Published: 04 May 2022
Publisher Name: Springer VS, Wiesbaden
Print ISBN: 978-3-658-37255-2
Online ISBN: 978-3-658-37256-9
eBook Packages: Social Science and Law (German Language)

Publish with us

Policies and ethics