Bestellen für Krankenhäuser: ein Webshop und eine Scan-App für den OP – Case Study

Kontext

Eine große Einkaufsgenossenschaft im deutschen Gesundheitswesen bündelt den Einkauf ihrer Mitgliedskrankenhäuser. Ab Mitte 2025 habe ich mit einem Backend-Entwickler zwei neue Produkte für sie aufgebaut:

einen Bestell-Webshop, in dem Einkaufsleitungen und strategische Einkäufer den täglichen und wöchentlichen Bedarf ihres Hauses bestellen. Gefüllte Warenkörbe gehen an das bestehende Bestellsystem, das die Bestellung abschickt.
eine Scan-App für Pflegekräfte im OP: Artikel direkt am Einsatzort scannen und nachbestellen, Schränke verwalten, Inventur erfassen.

Mein Beitrag

Die Backend-Architektur (.NET) hat mein Kollege entschieden und gebaut. Bei mir lagen Entscheidung, Planung, Aufbau und Administration von allem anderen: das Web-Frontend (React, TypeScript), die Mobile-App (React Native mit DataWedge für die Hardware-Scanner), die Datenbank (PostgreSQL) sowie Cloud-Services und Infrastruktur auf Azure.

Meine Verantwortung endete bei der Frage, was gebaut wird. Wie Einkäufer arbeiten, wusste ich anfangs nicht. Die fachliche Definition lag deshalb eine Ebene über mir, bei jemandem, der IT und Einkauf kennt: wie Prozesse abzubilden sind, wie die Workflows aussehen, wo sie möglichst leicht sein müssen und wo Details und Dynamik zählen.

Die schwierige Entscheidung: das BFF zurückbauen

Am Anfang stand vor dem React-Frontend ein Backend-for-Frontend (BFF) in Java/Spring Boot, gebaut nach dem Muster eines bestehenden Portals der Genossenschaft. Es übernahm Authentifizierung, Cookie-Handling und Routing.

Mit der Zeit wanderte das Routing in React Router, und vom BFF blieb im Wesentlichen ein Proxy zwischen Frontend und Backend. Ich habe vorgeschlagen, es zu entfernen. Der Hauptgrund war das Team: Bei zwei Entwicklern hieß Java neben .NET und TypeScript eine dritte Sprache und Laufzeitumgebung, die gewartet, deployt und von jedem Nachfolger beherrscht werden muss. Ohne das BFF besteht der Stack aus .NET im Backend und TypeScript im Frontend, und das Frontend spricht typisiert direkt mit der API. Das macht es deutlich leichter, eine Nachfolge für das Projekt zu finden.

Die Authentifizierung selbst hing nie am BFF: Sie lief vorher wie nachher über einen zentralen Identity-Provider. Heute meldet sich das Frontend dort direkt per OAuth 2.0 mit PKCE an.

Zusammenarbeit

Backend-Kollege: gemeinsame Abstimmung der API zwischen Backend und Frontend.
Technische Leitung: Design und Planung des Projekts.
Pilothaus: alle zwei Wochen ein Termin mit der Einkaufsleitung eines Mitgliedskrankenhauses, um Feedback aus der Praxis einzuholen.

Ergebnis

Stand bei meiner Übergabe im Juli 2026:

Scan-App: Die Parser für HIBC, GS1, EAN und GTIN waren vollständig fertig, abgesichert durch mehrere hundert Unit-Tests. Damit liest die App die Codes, die auf Medizinprodukten tatsächlich vorkommen.
Webshop: Artikelsuche über mehr als eine Million Artikel, Organisationsstrukturen der Häuser, ein Berechtigungssystem sowie das Anlegen und Befüllen von Listen und Warenkörben.

Rückblick

Das BFF hätte es von Anfang an nicht geben dürfen. Es entstand aus Routine, weil ein bestehendes Portal so gebaut war, nicht aus einer Planung für dieses Projekt. Die Lehre für mich: Jede Schicht braucht zu Beginn einen Grund, der aus diesem Projekt kommt, nicht aus dem letzten.

Produkt- und Kundennamen, interne Kennzahlen und Screenshots lasse ich bewusst weg. Im Gespräch erzähle ich gern mehr, soweit es meine Verschwiegenheit erlaubt.