The cliff SAP set in 2022
In October 2022, SAP announced that the Industry Solution for Healthcare — IS-H — would not have a like-for-like successor in the S/4HANA world. The product covers patient administration, hospital billing, materials management, pharmacy, catering, and the maintenance functions hospitals run from a central ERP. Regular support is set to end in 2027 and the paid extension runs to 2030. After that, the platform is frozen and the customer is on its own.
A third-party consortium is building a successor product called GS-H on S/4HANA. The intent is to give existing IS-H customers a continuity path. The reality is that the consortium is doing the work SAP chose not to do, on a timeline the consortium controls, with commercial terms separate from the SAP relationship. Hospitals running IS-H today have three options as the cliff approaches. Wait for GS-H. Switch to a different vendor's hospital information system. Rebuild the workflows the hospital actually depends on, module by module, on owned software that integrates back to the EHR.
This piece is the third option. It is not theoretical. The pattern is the one we run for every regulated estate where the vendor's transition path does not match the institution's pace of decision-making.
What IS-H actually contains at a Middle East hospital
The IS-H deployments we have looked at across Middle East hospital groups share a common shape. The patient administration module handles registration, the master patient index, the admission-discharge-transfer flow, and the encounter management. The billing module handles the payer relationships, the claim generation, the receivables workflow, and the patient self-pay surface. The materials management module handles consumables, pharmacy inventory, surgical supply, and the integration into purchasing. The catering and maintenance modules handle the non-clinical operations.
Around the core IS-H instance, the integrator typically has built ten years of customisations. Insurance scheme rules specific to the Middle East market. The Daman, Thiqa, Bupa Arabia, and Mednet adjudication patterns. The cash-payer workflows for the medical-tourism segment. The corporate-account billing for the large employer accounts. The pharmacy substitution rules. The clinical-trial billing. Each of those is a configured workflow that the hospital depends on. Each of those is institutional knowledge that lives partly in the integrator's heads and partly in the configuration tables.
The 2030 cliff is not only a software cliff. It is a knowledge cliff. The hospital that does not move before the cliff loses the integrator's bench at the same moment it loses the support contract.
The replacement sequence
The sequence we run is workflow-led, not module-led. The clinical decision support stays in the EHR — Cerner, Epic, or the regional HIS the hospital operates — and the workflows that depended on IS-H move to owned software on a schedule that respects the regulator's posture and the hospital's operational rhythm.
Sprint one — billing and insurance adjudication. The billing module is almost always the first workflow to move. The reasons are operational and commercial. The integrator's billable work on billing customisations is the highest single line on the IS-H operating cost. The insurance-scheme rule sets are the most volatile element of the estate; new schemes arrive and existing schemes change rules on a cycle the SAP release calendar cannot match. The replacement is a clean four-to-six-week build. The output is an owned billing engine that handles the Middle East insurance landscape on the hospital's calendar, with the integration boundary back to the patient administration module on one side and the general ledger on the other.
Sprint two — patient administration and the master patient index. The patient administration module is the second move because the integration surface to the clinical systems is the most sensitive boundary in the estate. The master patient index, the admission-discharge-transfer flow, and the encounter management move to owned software. The clinical systems — the EHR, the lab system, the imaging system, the pharmacy dispensing — continue to read patient identity from the integration boundary the hospital now owns. The boundary is the artefact the clinical governance team signs off on before go-live.
Sprint three — materials management and pharmacy inventory. The materials management module is a six-week build. The pharmacy inventory, the consumables ordering, the surgical-supply replenishment, the chargemaster updates. The integration into the purchasing function and the supplier-management workflow moves with it. The pharmacy substitution rules, which have been a continuous source of friction at every Middle East hospital we have looked at, become editable by the pharmacy team rather than the integrator.
Sprint four — corporate and self-pay billing surfaces. The corporate-account billing for large employers, the cash-payer surfaces for medical tourism, the patient self-pay portal. These move to owned software on the existing billing engine the hospital owns from sprint one. The customer experience improves materially because the team designing it owns the surface and can iterate on it.
Sprint five — clinical-trial billing. Hospitals running active research operations carry a clinical-trial billing surface inside IS-H. The trial protocols, the sponsor relationships, the per-arm billing splits, the milestone payments — all are configured workflows the research team manages through the integrator. The replacement is a tighter build than the others because the user community is small and the requirements are well-documented, but the trial governance team must sign off on every workflow change.
Sprint six — catering, maintenance, and the non-clinical operations. The last sprint covers the non-clinical operations that round out the IS-H footprint. The catering function, the maintenance scheduling, the facilities-management workflows. These are the smallest user communities in the estate and the easiest to move, but they have been left until last because the regulatory and clinical-governance work has been front-loaded into the earlier sprints.
What stays where it is
The clinical record. The clinical decision support. The order-entry workflow that drives medication and investigation decisions. The clinical documentation that the physicians author. The clinical reporting the regulator examines. None of those move in the sequence above. The EHR continues to be the system of record for everything that touches a clinical decision. The patient safety architecture the hospital has validated does not change.
What moves is the operational and financial scaffolding around the clinical record. The scaffolding is what IS-H provided. The scaffolding is what the replacement provides on the hospital's terms.
The Middle East dimension
Three things make this work in the Middle East specifically.
The insurance market complexity is higher than it is in most of Europe and most of North America. The Middle East adjudication rules are tighter, the corporate-account billing is more nuanced, and the cash-payer mix is more variable. The owned billing engine is materially better positioned to handle this complexity than the generic IS-H configuration.
The regulator's posture on technology change has matured. The UAE health regulators and the Saudi Ministry of Health have published expectations for technology resilience and continuity that the IS-H 2030 cliff arguably contradicts. The hospital that runs the replacement above is in a stronger position on the supervisory conversation, not weaker.
The talent ecosystem has matured. The hospital can hire the engineering and operations capability to run the replacement after handover. Three years ago the talent argument was thinner. Today it is not.
The total timeline
The full sequence above runs in 14 to 18 months for a mid-sized Middle East hospital group. The first sprint pays for the second. The second pays for the third. The full operating cost at the end of the sequence is materially below the trajectory the hospital was on, and the 2030 cliff becomes a non-event because the workflows that depended on IS-H no longer do.
The saasinator perspective
The hospitals that wait for GS-H are betting on a vendor consortium delivering on a timeline that is not in the consortium's control either. The hospitals that switch to a different HIS are accepting a different vendor's lock-in. The hospitals that run the rebuild above are the ones that own the workflows the institution depends on, at the institution's pace, on the institution's calendar.
The patient safety architecture is the line we do not cross. Everything else is negotiable. The 2030 cliff is the catalyst the IS-H customer base did not ask for and now has to act on. The work to start is the first sprint. Every subsequent decision is easier with the first sprint complete.
What to bring to the diagnostic
If your hospital group is running IS-H today and the 2030 cliff is on the technology roadmap, the conversation worth having is which sprint flips first. Bring the IS-H module breakdown, the integrator retainer schedule, the insurance-scheme configuration burden, and the clinical-governance position on technology continuity.
The diagnostic is 15 working days. The output is the sprint recommendation, the architecture sketch, and the first-sprint scope that respects every regulatory and clinical-governance consideration the institution operates against.