S4.health as the SAP ISH Successor: Architecture, Migration Path, and Interoperability for German Hospitals – A Technical Deep Dive from “S4.health” by Lara von der Kall (ATSP)

Context: Why a successor to SAP ISH is urgent

In her talk “S4.health,” Lara von der Kall (ATSP) laid out the stakes plainly: SAP will no longer support SAP ISH, the system many hospitals rely on for patient management and billing. For organizations with sizeable ISH footprints, that’s more than a maintenance note—it’s a strategic turning point. S4.health steps in as the successor for the German market, driven by a 2024 partnership between ATSP and RZV and built on a core provided by T-Systems Austria.

The goals are clear: preserve ISH’s functional breadth while modernizing the technical foundation on S/4HANA, reduce migration risk, and ensure interoperability via established standards such as HL7 and FHIR. Von der Kall emphasized that the team works under Scrum—agile, iterative, responsive to requirements—and intends to keep it that way “to react as quickly as possible to requirements.”

Partnership model and product strategy (2024)

The ATSP–RZV partnership, formed in 2024, consolidates three strengths:

• years of product expertise around SAP ISH
• deep technical know-how for S/4HANA-based development
• domain expertise in the German market (via RZV)

This alignment underpins a shared roadmap that accelerates S4.health and reduces complexity for hospitals transitioning from ISH. It centers on a core by T-Systems Austria, with country versions layered on top: T-Systems Austria for Austria and Switzerland, ATSP and RZV for Germany.

Crucially, what starts as “core + country version” turns into one merged product. S4.health is delivered as an add-on atop the hospital’s S/4HANA core modules—organizationally separated in development, but consolidated as a product in operations.

Target architecture: S/4HANA-first, add-on model, and KISS integration

Von der Kall outlined a crisp target architecture:

• a HANA database, specifically an S/4HANA database, at the bottom
• existing SAP core modules (e.g., FI, CO, Logistics) already running on S/4HANA
• S4.health installed as an add-on on top
• hospital KISS systems connected to S4.health
• deployment either On-Premise or in a Private Cloud
• interoperability as a guiding principle: committed support for HL7 and FHIR; ESIC is particularly relevant in Germany

One standout detail is continuity at the UI and transaction layer. The SAP GUI remains the primary interface and familiar transactions are preserved. As von der Kall put it, when users “turn off their computer in the evening … it basically looks the same as before, only with a different foundation underneath.” For hospitals, that translates into continuity of processes, fewer training needs, and a modernized stack beneath the surface.

Today’s ISH vs. tomorrow’s S4.health

The session juxtaposed the two setups. At the base remains a HANA database; above it, SAP standard code—now on S/4HANA. The change happens in the ISH layer: ISH is “removed” and replaced by S4.health. For end users, little changes: the SAP GUI and transaction logic remain. At the same time, S4.health opens the door to new use cases and rethinking processes—if and when hospitals want it.

Key points:

• The system architecture essentially remains the same—on a modernized foundation.
• Functional parity: “Everything ISH can do today, S4.health can cover in the future.”
• Customer-specific code and transactions are made compatible through conversion.
• Optional process redesign is possible without sacrificing parity.

This migration philosophy—stability up front, modernization underneath—reduces risk and eases planning for mission-critical hospital operations.

From core to country version—and back to a unified product

Technically, S4.health is built on the TSHC core by T-Systems Austria. On this core sit country versions:

• T-Systems Austria: Austria, Switzerland
• ATSP & RZV: Germany

Organizationally separate, but merged into one product for delivery: core and country version “fuse into a product.” S4.health becomes an add-on within the hospital’s S/4HANA landscape, leveraging existing core modules. It’s a bridge between country-specific capabilities and standardized provisioning.

Interoperability as a first principle

Von der Kall underscored interoperability repeatedly:

• commitment to support HL7 and FHIR
• ESIC is particularly relevant in Germany
• aim to remain KISS-neutral and enable individual solutions—grounded in open standards

For technical teams, S4.health positions itself not as a monolith but as a component that integrates into existing KISS landscapes—via standards-based interfaces.

The migration path: Three conversion packages

S4.health doesn’t require a “big bang.” ATSP provides a structured implementation path through three conversion packages that make the transition gradual and predictable.

1) ISH Readiness Check – semi-automated system analysis

The ISH Readiness Check is the entry point and prerequisite. It’s an environment analysis that “brings everything to the surface we need to know.” It includes:

• identifying enhancements and modifications
• surfacing “baggage” (what accumulated historically but is no longer needed)
• classifying what can be removed vs. what must be remodeled/adjusted/rebuilt
• producing a roadmap that can be worked through systematically, with a precise effort estimate for the follow-on project

Accurate effort estimation is crucial for hospital IT: teams need a reliable basis for capacity and resource planning. The Readiness Check provides it, and also clarifies which preparatory tasks belong on the legacy R/3 system.

These preparatory tasks can be performed by the hospital—depending on available personnel and resources. ATSP can support as needed, drawing on past experience. The key is flexibility: each organization decides how much external support to use.

2) Custom Code Conversion – automated migration service

The second package targets conversion of customer-specific code. As described in the session:

• customer custom code is extracted from the hospital system and brought onto an ATSP system
• automated conversion is performed—primarily changes to names (e.g., tables, data elements) that result from the new product and transition
• the goal is compatibility with the “new world,” i.e., S4.health and S/4HANA

As an intermediate step, the new S/4 system can already be prepared. Tasks identified in the Readiness Check reappear here and can be executed at this stage. It’s an iterative, orchestrated flow aligning technical and organizational work.

3) Data Conversion – fully automated data transfer with delta loads

The third package handles data transfer—“completely automated,” focusing on “all functional and process-relevant data elements.” Operationally, downtime is the central concern. Here, S4.health relies on early delta loads, a stepwise transfer approach designed to keep the final downtime “relatively low.”

This turns data migration from a one-time cutover into a controlled transition with ongoing synchronization. The result is a staged go-live where the actual stop can be kept short.

Execution patterns: Stability, iteration, realism

The talk communicated a pragmatic stance throughout:

• stability where users need it (GUI, transactions, functional coverage)
• modernization where it matters technically (S/4HANA database, add-on architecture, interoperability standards)
• iterative delivery (Scrum-based product development and staged conversion packages)
• operational realism (delta loads to reduce downtime, On-Premise or Private Cloud delivery)

That balance is essential for hospital IT programs with high dependencies and 24/7 responsibility.

Recommendations from the session: Start early, be systematic

Von der Kall’s guidance is practical: “the earlier you start thinking about which surrounding systems you have … the better.” There’s already DACH experience with Readiness Checks—some customers “are completely finished,” others are “at the starting line.” For IT leaders and engineering teams, that translates into concrete next steps.

What to do now—technical and organizational

• Inventory the environment
• Which KISS systems are connected (the “KISS systems that are connected in your house”)?
• Which enhancements/modifications exist in the ISH stack?
• Which interfaces and data flows are critical?
• Plan and run the ISH Readiness Check
• transparency on code, enhancements, historical baggage
• roadmap and effort estimates for capacity planning
• Prioritize preparatory work on R/3
• identify what can be removed
• identify what needs to be remodeled/adjusted/rebuilt
• decide how to split the work between in-house resources and ATSP support
• Prepare Custom Code Conversion
• define scope of customer-specific code
• establish technical contacts and transport routes
• Orchestrate Data Conversion
• plan delta-load strategy and cadence
• align test windows and go-live planning
• Anchor the target architecture
• review S/4HANA core modules (FI, CO, Logistics)
• decide on add-on deployment (On-Premise vs. Private Cloud)
• align interoperability requirements (HL7, FHIR, ESIC)

Optional process redesign—stepwise, where it adds value

S4.health keeps optionality: hospitals can rethink processes and define new use cases. Von der Kall is explicit—this is an option, not an obligation. For many organizations, the sensible path is to stabilize critical flows first and pursue process improvements as a subsequent or parallel track. Technically, S4.health accommodates both; organizationally, each hospital can calibrate its approach.

User perspective: Familiarity lowers friction

Keeping the SAP GUI and familiar transactions is a deliberate user-centric design. It lowers friction in several ways:

• reduced training needs
• continuity for clinical and administrative workflows
• a lower-risk cutover for operations

At the same time, teams gain the advantages of a modern data and application foundation better aligned with evolving standards (e.g., FHIR).

Interoperability in practice: HL7, FHIR, ESIC, and KISS neutrality

The standards aren’t just labels; they guide the product direction. The commitment to HL7 and FHIR is explicit, and ESIC is important in Germany. The goal of KISS neutrality acknowledges common reality: heterogeneous hospital environments. Standards are the enabler for flexible, individual solutions—“that’s why these standards are relevant.”

Delivery options: On-Premise and Private Cloud

S4.health will be provided On-Premise or in a Private Cloud—giving hospitals control to align with governance and operations constraints. Both options fit the add-on model atop S/4HANA core modules.

Governance and planning: Effort estimation as an anchor

The Readiness Check yields a “very precise effort estimate”—a key anchor for governance, budgeting, and capacity management. In resource-constrained hospital IT, this level of predictability is vital. It aligns milestones (preparatory tasks, code conversion, data transfer) with organizational activities (change windows, acceptance tests, go-live preparation).

Memorable takeaways from the talk

Conclusion: A predictable path from ISH to S4.health—technical continuity with an open future

Lara von der Kall’s “S4.health” session makes a clear case: the end of SAP ISH support is real, but the transition to S4.health is manageable—keeping user-facing stability, moving to an S/4HANA-based core, and offering a migration path that respects both technical and operational realities. The add-on model lets S4.health reuse existing SAP core modules, connect KISS systems, and align with interoperability standards.

For engineering and IT teams in hospitals, the next moves are straightforward: schedule the Readiness Check, prioritize R/3 pre-work, orchestrate custom code and data conversions—while choosing between On-Premise and Private Cloud. Starting early surfaces the necessary details about surrounding systems, legacy code, and interfaces. That transparency is what ensures “everything stays the same” for users—while the underlying platform evolves reliably.

• 

  

  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.

  Watch now

• 

  

  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.

  Watch now