S4.health als SAP ISH-Nachfolge: Architektur, Migrationspfad und Interoperabilität für deutsche Krankenhäuser – Ein technischer Deep Dive aus der Session „S4.health“ von Lara von der Kall (ATSP)

Kontext: Warum eine ISH-Nachfolgelösung jetzt entscheidend ist

In ihrer Session „S4.health“ stellte Lara von der Kall (ATSP) klar: SAP wird SAP ISH – vielerorts das Rückgrat für Patientenmanagement und -abrechnung – nicht weiter supporten. Für Krankenhäuser mit gewachsenen ISH-Landschaften ist das keine Randnotiz, sondern eine strategische Zäsur. Genau hier setzt S4.health an: eine ISH-Nachfolgelösung für den deutschen Markt, getragen von einer Partnerschaft zwischen ATSP und dem RZV, aufbauend auf einem Core der T-Systems Austria.

Die Motivation ist eindeutig: Krankenhäuser benötigen eine zukunftsfähige, S/4HANA-basierte Plattform, die den Funktionsumfang von ISH erhält, technisch modernisiert, Migrationsrisiken reduziert und Interoperabilität auf Basis gängiger Standards wie HL7 und FHIR gewährleistet. Von der Kall betont, dass das Team nach Scrum arbeitet – agil, iterativ, nah an Anforderungen, um „möglichst schnell auf Anforderungen reagieren zu können“ und diese Arbeitsweise fortzuführen.

Partnerschaftsmodell und Produktstrategie (2024)

Die Partnerschaft ATSP–RZV wurde 2024 geschlossen, um mehrere Stärken zu bündeln:

• ISH-Produktexpertise über viele Jahre
• technische Kompetenz in S/4HANA-basierter Entwicklung
• fachliches Know-how im deutschen Markt (über den RZV)

Das Ergebnis ist ein gemeinsamer Fahrplan, der die Entwicklung von S4.health beschleunigt und gleichzeitig die Komplexität im Übergang von ISH reduziert. Zentraler Baustein ist ein Core, bereitgestellt von der T-Systems Austria, auf den Landesversionen aufsetzen: T-Systems Austria verantwortet Österreich und die Schweiz, ATSP und RZV die Landesversion Deutschland.

Ein wichtiges architektonisches Detail: Aus dem klassischen Muster „Core + Landesversion“ wird am Ende ein verschmolzenes Produkt. S4.health wird als Add-on auf die bestehenden S/4HANA-Core-Module des Krankenhauses gesetzt – eine klare Trennung der Ebenen in der Entwicklung, aber ein konsolidiertes Produkt im Betrieb.

Zielarchitektur: S/4HANA-first, Add-on-Ansatz und KISS-Anbindung

Von der Kall zeichnet die Zielarchitektur eindeutig:

• Grundlage ist eine HANA-Datenbank, konkret eine S/4HANA-Datenbank.
• Bestehende SAP-Core-Module (z. B. FI, CO, Logistics) laufen bereits auf S/4HANA.
• S4.health wird als Add-on darüber installiert.
• KISS-Systeme im Haus können an S4.health „angedockt“ werden.
• Bereitstellung wahlweise On-Premise oder in der Private Cloud.
• Leitprinzip Interoperabilität: Commitment zur Unterstützung von HL7 und FHIR; in Deutschland ist insbesondere ESIC relevant.

Architektonisch bemerkenswert ist die Kontinuität in der Oberflächenlogik. Die Session machte deutlich, dass die SAP GUI und die gewohnten Transaktionen erhalten bleiben. Die Nutzerperspektive ist zentral: „Wenn Sie Ihren Computer an dem einen Abend ausmachen … es schaut grundsätzlich alles genauso aus wie davor, nur dass es in der Tiefe eine andere Grundlage hat.“ Für Kliniken heißt das: gewohnte Prozesse, geringere Schulungsaufwände – und dennoch eine modernisierte technische Basis.

Vergleich: Heute (SAP ISH) vs. Morgen (S4.health)

In der Session wurde das Bild klar nebeneinandergelegt. Unten bleibt eine HANA-Datenbank; darüber bleibt SAP-Standardcode – nun auf S/4HANA-Technologie. Der Wechsel passiert in der ISH-Schicht: ISH wird „ausgelöst“ und durch S4.health ersetzt. Aus Anwendersicht ändert sich wenig: die SAP GUI bleibt, die Anzeige- und Transaktionslogik bleibt erhalten. Gleichzeitig eröffnet S4.health Optionen für neue Use Cases und Prozessneugestaltung – wenn Kliniken das möchten.

Wesentliche Punkte:

• Die Systemarchitektur bleibt im Kern gleich – nur auf modernem technologischen Fundament.
• Funktionsumfangsparität: „Alles, was das ISH heute kann, kann das S4.health in Zukunft abdecken.“
• Kundeneigener Code (Custom Code) und Kundentransaktionen werden kompatibel gemacht – per Conversion.
• Optional: Prozesse „neu denken“ und neu definieren, ohne die Parität aufzugeben.

Diese Migrationsphilosophie – Stabilität an Oberfläche und Funktion, Modernisierung in der Tiefe – minimiert Risiken und erleichtert die Projektplanung in Häusern, die auf Kontinuität in den Abläufen angewiesen sind.

Vom Core zur Landesversion – und zurück zum Produkt

Technisch basiert S4.health auf dem TSHC-Core der T-Systems Austria. Darauf liegen Landesversionen:

• T-Systems Austria: Österreich, Schweiz
• ATSP & RZV: Deutschland

Organisatorisch ist das eine Trennung, fachlich-architektonisch aber bewusst zur Produktreife zusammengeführt: Core und Landesversion „verschmelzen zu einem Produkt“. S4.health wird als Add-on in die S/4HANA-Landschaft des Krankenhauses eingebracht und nutzt die vorhandenen Core-Module. Dieser Ansatz ist ein Brückenschlag zwischen länderspezifischer Ausprägung und standardisierter Bereitstellung.

Interoperabilität als Leitprinzip

Von der Kall unterstreicht mehrfach den Grundsatz der Interoperabilität:

• Unterstützung von HL7 und FHIR – Commitment bereits jetzt ausgesprochen.
• In Deutschland ist ESIC relevant; S4.health richtet sich daran aus.
• Ziel: KISS-Neutralität und individuelle Anbindungen – auf Grundlage offener Standards.

Für technische Teams heißt das: S4.health positioniert sich nicht als monolithischer, geschlossener Block, sondern als Baustein, der in vorhandene KISS-Landschaften integriert werden kann – mit standardbasierten Schnittstellen.

Der Migrationspfad: Drei Conversion-Pakete

S4.health kommt nicht als „Big Bang“, sondern mit einem strukturierten Umsetzungspfad. ATSP hat dafür drei Conversion-Pakete geschnürt, die den Wechsel Schritt für Schritt planbar machen.

1) ISH Readiness Check – teilautomatisierte Systemanalyse

Der ISH Readiness Check ist Startpunkt und Voraussetzung. Ziel ist eine Umfeldanalyse, die „alles an die Oberfläche bringt, was wir wissen müssen“. Dazu gehören:

• Identifikation von Erweiterungen und Modifikationen
• Transparenz über Altlasten („was ist aufgrund der Vergangenheit dazugekommen, aber heute nicht mehr relevant?“)
• Klassifikation: Was kann entfallen? Was muss modelliert/anpasst/umgebaut werden?
• Ergebnis: eine Roadmap, die systematisch abgearbeitet werden kann – mit genauer Aufwandsschätzung für das Folgeprojekt

Gerade die Aufwandsschätzung ist in Klinik-IT-Projekten zentral. Teams brauchen eine belastbare Basis für Kapazitäts- und Ressourcenplanung. Der Readiness Check liefert diese Grundlage und zeigt, welche Vorarbeiten auf dem alten R/3-System sinnvoll sind.

Wichtig: Diese Vorarbeiten können vom Krankenhaus selbst durchgeführt werden – abhängig von Ressourcen und Personal. ATSP kann hierbei begleiten; es gibt Erfahrungswerte „aus der Vergangenheit“. Entscheidend ist die Flexibilität: Häuser wählen, in welchem Umfang sie Unterstützung nutzen.

2) Custom Code Conversion – automatisierter Migrationsservice

Das zweite Paket richtet sich an die technische Konvertierung des kundeneigenen Codes. Ablauf aus der Session:

• Der kundeneigene Custom Code wird vom Kundensystem abgezogen und auf ein ATSP-System gebracht.
• Dort wird der Code automatisiert konvertiert – im Kern geht es um Namensänderungen (z. B. Tabellen, Datenelemente), die sich durch das neue Produkt und die Umstellung ergeben.
• Ziel ist Kompatibilität „für die neue Welt“, also die S4.health- und S/4HANA-basierte Zielumgebung.

Als Zwischenschritt kann das neue S/4-System bereits vorbereitet werden. Dabei tauchen erneut Aufgaben aus dem Readiness Check auf, die in dieser Phase abgearbeitet werden können. Es ist ein iterativer, planbarer Ablauf, der technische und organisatorische Aufgaben verzahnt.

3) Data Conversion – vollautomatisierte Datenübernahme mit Delta Loads

Das dritte Paket ist die Datenübernahme – „komplett automatisiert“ und fokussiert auf „alle funktions- und prozessrelevanten Datenelemente“. Aus Sicht des Betriebs ist der Umgang mit Downtime kritisch. Hier setzt S4.health auf einen pragmatischen Ansatz: frühzeitige Delta Loads, also schrittweise Übernahmen, um die finale Downtime „relativ gering halten“ zu können.

Damit wird die Datenmigration nicht als einmaliger Schnitt verstanden, sondern als gesteuerter Übergang mit fortlaufender Synchronisierung. Ergebnis: Ein vorzubereitender Go-Live, bei dem der eigentliche Stopp kurz gehalten werden kann.

Auf die Umsetzung gesehen: Stabilität, Iteration, Realismus

Die Session vermittelte einen konsequent praxisnahen Ansatz:

• Stabilität, wo sie Anwendern wichtig ist (GUI, Transaktionen, Funktionsumfang)
• Modernisierung, wo sie technisch relevant ist (S/4HANA-Datenbank, Add-on-Architektur, Interoperabilitätsstandards)
• Iteratives Vorgehen (Scrum-inspirierte Produktentwicklung und gestaffelte Conversion-Pakete)
• Realistische Betriebsaspekte (Delta Loads zur Downtime-Reduktion, On-Premise oder Private Cloud)

Diese Balance macht den Unterschied in Krankenhaus-IT-Programmen mit hohen Abhängigkeiten und Betriebsverantwortung.

Empfehlungen aus der Session: Jetzt anfangen, systematisch vorgehen

Von der Kall schlägt vor, „je eher man anfängt, sich zu überlegen, welche Umsysteme es gibt … umso besser“. Im DACH-Raum liegen bereits Erfahrungen mit Readiness Checks vor – einige Kunden sind „komplett fertig“, andere stehen „in den Startlöchern“. Für IT-Leitung und Engineering-Teams lassen sich daraus konkrete Schritte ableiten.

Was jetzt zu tun ist – technisch und organisatorisch

• Bestandsaufnahme der Umgebung
• Welche KISS-Systeme sind angebunden (die „KISS-Systeme, die bei Ihnen im Haus angebunden sind“)?
• Welche Erweiterungen/Modifikationen liegen im ISH-Stack?
• Welche Schnittstellen und Datenflüsse sind kritisch?
• ISH Readiness Check planen und durchführen
• Transparenz über Code, Erweiterungen, Altlasten
• Roadmap und Aufwandsschätzung als Basis für Kapazitätsplanung
• Vorarbeiten auf R/3 priorisieren
• Was kann entfernt werden?
• Was muss modelliert, angepasst, umgebaut werden?
• In welchem Umfang interne Ressourcen vs. Unterstützung durch ATSP nutzen?
• Custom Code Conversion vorbereiten
• Scope des kundeneigenen Codes festlegen
• technische Ansprechpartner und Transportwege klären
• Data Conversion orchestrieren
• Delta-Load-Strategie und Taktung planen
• Testfenster und Go-Live-Planung ausrichten
• Zielarchitektur verankern
• S/4HANA-Core-Module (FI, CO, Logistics) prüfen
• Add-on-Deployment (On-Premise vs. Private Cloud) entscheiden
• Interoperabilitätsanforderungen (HL7, FHIR, ESIC) abgleichen

Optional: Prozesse neu denken – mit Augenmaß

S4.health ermöglicht neue Use Cases. Von der Kall stellt klar: Das ist eine Option, kein Muss. Die Parität der Funktionen wird gewahrt. In vielen Häusern ist es sinnvoll, kritische Pfade zunächst stabil zu migrieren – und Potenziale für Prozessverbesserungen im Anschluss oder in separaten Strängen zu heben. Technisch ist das Modell dafür angelegt; organisatorisch entscheidet jedes Haus je nach Risikoappetit und Ressourcenlage.

Nutzerperspektive: Bewährtes bleibt – das senkt Reibung

Ein starkes Signal an Fachbereiche und Anwender ist die bewusste Beibehaltung der SAP GUI und bekannter Transaktionen. Das reduziert Reibungsverluste:

• geringere Schulungsbedarfe
• vertraute Workflows für medizinische Fachabteilungen und Verwaltung
• minimiertes Umstellungsrisiko in kritischen Betriebsphasen

Gleichzeitig profitieren Teams von einer modernen Daten- und Applikationsbasis, die zukünftige Standards (z. B. FHIR) besser und nachhaltiger tragen kann.

Interoperabilität konkret: HL7, FHIR, ESIC und KISS-Neutralität

Die technischen Standards stehen nicht als Schlagworte im Raum, sondern sind handlungsleitend. Das Commitment zu HL7 und FHIR ist ausgesprochen; ESIC ist im deutschen Kontext besonders relevant. Das Ziel der KISS-Neutralität adressiert eine verbreitete Realität: heterogene Kliniklandschaften mit gewachsenen Systemverbünden. Standards sind hier der Hebel für flexible und individuelle Lösungen – „dafür sind diese Standards relevant“.

Bereitstellungsmodelle: On-Premise und Private Cloud

S4.health wird als On-Premise- oder Private-Cloud-Lösung bereitgestellt. Für Krankenhäuser eröffnet das Wahlfreiheit entlang eigener Governance- und Betriebsmodelle. Beide Optionen sind kompatibel mit dem Add-on-Ansatz über S/4HANA-Core-Module.

Governance und Planung: Aufwandsschätzung als Projektanker

Der Readiness Check liefert eine „sehr genaue Aufwandsschätzung“ – ein zentraler Anker für Governance, Budgetierung und Kapazitätssteuerung. Gerade in Kliniken mit knappen Ressourcen ist diese Planbarkeit entscheidend. Sie schafft Verlässlichkeit in Meilensteinen (Vorarbeiten, Code-Conversion, Datenübernahme) und verknüpft technische mit organisatorischen Aktivitäten (z. B. Change-Fenster, Abnahmetests, Go-Live-Vorbereitung).

Zentrale Aussagen, die hängen bleiben

Fazit: Ein planbarer Weg von ISH zu S4.health – mit technischer Kontinuität und offener Zukunft

Die Session „S4.health“ von Lara von der Kall (ATSP) zeichnete ein klares Bild: Der Ausstieg aus SAP ISH ist gesetzt, aber der Einstieg in S4.health ist planbar – mit wenigen Bruchstellen für Anwender, einer stabilen, S/4HANA-basierten Zielarchitektur und einem Migrationspfad, der technische wie organisatorische Realitäten ernst nimmt. Der Add-on-Ansatz macht S4.health zu einem Baustein, der vorhandene SAP-Core-Module nutzt, KISS-Systeme integriert und Interoperabilitätsstandards erfüllt.

Für Engineering- und IT-Teams in Krankenhäusern sind die nächsten Schritte eindeutig: Readiness Check terminieren, Vorarbeiten priorisieren, Custom Code und Datenmigration orchestrieren – und dabei die Wahl zwischen On-Premise und Private Cloud bewusst treffen. Wer früh beginnt, verschafft sich die nötige Transparenz über Umsysteme, Altlasten und Schnittstellen. Und genau diese Transparenz ist die Voraussetzung, damit der Satz „alles bleibt gleich“ für Anwender stimmt – während sich darunter die technologische Grundlage verlässlich erneuert.

• 

  

  Michael Hofstetter, Leitung Software Development bei ATSP

  Leitung Software Development bei ATSP Michael Hofstetter spricht im Interview über das Development Team, das Recruiting und Onboarding, sowie den technologischen Schwerpunkt im Unternehmen.

  Jetzt ansehen

• 

  

  Laura Neuner, SAP Consultant bei ATSP

  Laura Neuner von ATSP erzählt im Interview über ihren Weg in die IT, was ihrer Ansicht nach für Neueinsteiger wichtig ist und gibt Einblicke in den Arbeitsalltag im SAP Consulting.

  Jetzt ansehen