The Board Decides, the CIO Delivers: A Digital Health Platform Powered by SAP
In my previous posts I described SAP’s global healthcare industry strategy, a modular, data-driven, open, and interoperable platform, and I argued that a digital health platform (DHP) is ultimately a business decision that belongs on the CEO’s desk. Once the board has made that call, however, the mandate lies with the CIO, who turns a strategic ambition into a governed and sequenced delivery program that runs alongside daily operations without disrupting them. This post is written for that very role, and it tries to focus on two questions: what does a digital health platform powered by SAP actually consist of, and why does it make the CIO’s task easier instead of adding yet another program to an already full portfolio?
A landscape grown by change, not by design
In my experience, most healthcare providers definitely do not suffer from a lack of applications; they suffer from a system landscape that has grown over many years and rarely by design, and the figures show this: a symplr survey of health system clinicians and CIOs found that a majority of organizations run somewhere between 50 and 500, sometimes even more, different software solutions to operate their healthcare business, and in the United States alone the sector saw more than 900 hospital merger and acquisition transactions between 2014 and 2024, each of which brought their own systems, teams, and technical debt into somebody else’s landscape. So, there is an electronic medical record (EMR) system, or several of them after mergers, one or more revenue cycle management (RCM) systems for billing and patient accounting, a sometimes aging enterprise resource planning (ERP) system, a number of departmental specialty systems, research databases, and a long tail of point solutions, each of which brings its own data model, its own integration approach, and its own vendor release schedule. In such a landscape, every new capability becomes its own project, and every project has to solve integration, data quality, and compliance all over again, and the pace of change of the whole institution is effectively set by whichever vendor moves slowest.
The timing pressure is real, too. Many hospitals still run SAP Business Suite 7 (ECC), whose mainstream maintenance ends in 2027, with extended maintenance through 2030 and a Transition Option in SAP Private Cloud through 2033, and in Europe the secondary-use provisions of the European Health Data Space (EHDS) Regulation begin to apply in March 2029, which means the CIO’s delivery window for both obligations is essentially the same three to four years. And the platform market itself is being shaped in exactly that window: Gartner estimated in its April 2024 research “Innovation Insight: Digital Health Platforms Accelerate Transformation” that the digital health platform market was only around five percent penetrated, with adoption expected to play out over five to ten years, so the institutions making their architectural choices now are the ones whose requirements the market will form around.
The EHR-first instinct, and where it ends
Before laying out our answer, let me name the objection I hear most often, because it deserves a serious analysis. Many health systems reasonably prefer to look at their EMR vendor first for any new capability; successive Bain and KLAS surveys have found that roughly two out of three look first to their existing vendors, and especially their EMR vendor, before considering anyone else. I understand the instinct, since the EMR carries the clinical workflows and much of the clinical data, and nobody wants another vendor relationship without good reason. Yet the same market research paints a sobering picture of how that instinct works out in practice, with only about a quarter of executives in a Sage Growth survey saying their EMR vendor fully lives up to its promises. The deeper issue, though, is not vendor performance but scope: the decisions a CIO is now asked to support, from cost transparency per procedure to workforce planning to supply chain resilience to research data provisioning, depend on finance, procurement, workforce, and logistics data that does not live in the EMR and never will, and a system built to document and bill for care was simply never designed to be the enterprise data and AI foundation of a health system. This is, incidentally, also where the analyst community has landed: Gartner has addressed its digital health platform research explicitly to healthcare provider CIOs since its initial Market Guide in 2021, describing a shift away from monolithic, EMR-centric application suites towards a platform architecture, and in its most recent framing “Digital Health Platforms (Transitioning to Healthcare Provider Industry Cloud Platforms) Reviews and Ratings” positions the category as evolving into Healthcare Provider Industry Cloud Platforms whose purpose is to let a CIO adjust the application portfolio at the pace of business change. That last phrase describes the job better than I ever could.
Connect, govern, innovate, transform
Our strategy for the digital health platform powered by SAP addresses exactly this in four dimensions: connect, govern, innovate, and transform. Let me take them in the order an actual delivery program would.
To connect means to bring disparate systems into a single, coherent view across clinical and enterprise operations. The platform speaks the standards your landscape already uses, among them HL7 FHIR®, openEHR, IHE (Integrating the Healthcare Enterprise), OMOP (the common data model of the Observational Medical Outcomes Partnership), and, in Germany, ISiK as the national interoperability standard for hospital information systems. It connects EMR and revenue cycle management systems as well as EHDS-related sources, alongside SAP and non-SAP applications, whether they run as software as a service, cloud-native, hybrid, or on-premises. The AnyEMR/MultiEMR and AnyRCM/MultiRCM principles I described in the strategy post apply here, too: the platform integrates across whatever clinical and billing systems you have chosen rather than locking you into a single vendor’s stack, and since SAP does not build EMR or RCM systems itself, we unify across them together with and through our partner ecosystem.
To govern is, for the CIO, the most consequential of the four: in most institutions today, governance is a per-project exercise: every integration project defines its own access rules, every research request triggers its own anonymization effort, every audit finding produces its own remediation plan, and the sum of all this is a patchwork of controls that nobody can fully describe, let alone defend under time pressure. On the platform, governance becomes a managed capability instead. Master data governance, identity and access, consent and rights management, pseudonymization and anonymization, and data sovereignty compliance are built into the architecture and travel with every data product, so a rule defined once, for example who may see identifiable patient data and under which consent, is enforced wherever that data flows, whether into an operational dashboard, an AI model, or a research extract. That does not make audit readiness automatic, because audits will always also examine processes and people, but it makes audit readiness sustainable, since the technical controls no longer have to be reconstructed and re-documented for every new use of the data. And where residency requirements demand it, the same architecture can be deployed on sovereign-cloud options, so that the jurisdiction question is answered by design rather than negotiated per project. This is also where regulation stops being only a burden: an institution whose consent, provenance, and de-identification are managed capabilities enters the EHDS era prepared, while one that handles them project by project will spend those same years catching up.
To innovate then builds on that foundation rather than around it: a composition layer with analytics from descriptive to predictive, knowledge graphs for reasoning across clinical, operational, and financial domains, healthcare-specific semantics and ontologies, which are expanding to include terminologies such as SNOMED CT and the OMOP data models, and AI domain models including clinical natural language processing, all accessible through build tools from low-code to pro-code, so that extensions live safely outside a clean core and survive the next upgrade, a lesson many of us learned the hard way in the ERP world. And to transform is simply what follows when the first three are in place: decisions powered by governed data and embedded AI, at a pace the institution sets for itself.
The architecture, seen from the delivery side
At the top level, the DHP architecture consists of three layers, and increasingly a fourth. A data foundation provides clinical, enterprise, and ecosystem connectivity, including the healthcare interoperability standards mentioned above. A digital innovation layer carries the intelligence and the health-specific business context. A healthcare experiences layer offers applications such as patient portals, clinical workplaces, health apps and dashboards, and scenarios like clinical trial matching, patient identity resolution, and the EHDS health record. And on top of these sits the AI layer, in which embedded intelligence, assistants, and increasingly agentic capabilities operate on the governed layers beneath them rather than beside them. Readers who know Gartner’s published DHP reference architecture from their “Market Guide for Digital Health Platforms” will recognize the shape of the first three: an integrated data fabric with health data connectors, data curation and enrichment, metadata management, a healthcare-specific data model, and privacy and consent controls; a layer of packaged business capabilities; and a composition layer with low-code tooling for building tailored experiences. Our architecture is a concrete instantiation of exactly that pattern, and it deliberately extends it in the one dimension that has moved fastest since the pattern was first described: the AI layer on top. And for readers who want to explore how this platform category is developing across the wider market, Vince Kuraitis’s series “Platforming Healthcare – The Long View” offers a thorough long-term perspective.
What binds these layers together is the data product, and it comes in two kinds. Primary data products are sourced directly from a clinical or enterprise application and represent the original, unprocessed data: claims records from the revenue cycle management system, encounter summaries from the EMR, patient records from a clinical data repository (CDR), or financials from SAP Cloud ERP. Derived data products are curated and enriched on top of them, and here, health-specific content such as Patient 360, treatment cost, clinical workforce readiness, and patient risk scores, which deliver ready-to-use insight without additional integration effort, are being built out. Anyone who has run a hospital integration program knows why this matters: instead of maintaining n×m point-to-point integrations between sources and consumers, you build governed, reusable assets once and consume them everywhere, with lineage and policy enforced from the start.
This is what that AI layer changes in practice: because it is grounded in exactly this governed, contextualized data, and because it acts through the platform’s managed capabilities rather than around them, AI can be deployed where it demonstrably relieves pressure in daily operations. SAP Joule, our AI assistant, is being extended by SAP and partners with healthcare scenarios to address the everyday pain points of running a hospital, from clinical documentation, coding and DRG optimization, and denial management to medication replenishment, patient scheduling, regulatory reporting, and workforce planning, while differentiating industry scenarios around Patient 360, clinical workforce optimization, and denial prevention and revenue recovery build on the very same foundation. The CIO needs neither a separate AI stack nor a separate governance regime for it, and no separate integration program to feed it, because the platform itself is the AI foundation. It is also the path to what we at SAP call the Autonomous Enterprise: operations in which routine work increasingly runs itself, under the institution’s own rules and controls. That kind of autonomy cannot be installed; it becomes possible only once connected data, business context, and governance are already in place, which is exactly what the layers beneath the AI provide.
That this approach works in practice is not a hypothesis: Hirslanden, Switzerland’s largest private hospital group, modernized its core processes and systems to support new clinical practices, regulatory standards, and cost reimbursement using SAP Signavio business transformation solutions, an example of how process intelligence grounded in a common platform accelerates transformation in healthcare rather than adding to the project load.
An ecosystem by design
No single vendor covers healthcare end to end, and we at SAP do not pretend to. Partners extend the platform with the clinical capabilities and industry solutions, built on SAP Business Technology Platform and SAP Business Data Cloud, delivered through SAP PartnerEdge, and available via SAP Store. For the CIO, that translates into freedom of choice at the edges and a stable, standards-based core in the middle.
A pragmatic sequence, not a big bang
Given the maintenance and regulatory horizons described above, a deliberate sequence is in fact the lower-risk path. It begins with mapping the landscape and agreeing on three to five cross-functional use cases that span clinical and operational domains. It continues with setting up the data foundation and publishing the first data products with governance in place, and with modernizing the ERP core at the institution’s own pace, be it with GROW with SAP for first-time adopters or with RISE with SAP for existing landscapes, where most providers favor separating the ERP and hospital information system transformations, with ERP first, to harmonize master data before clinical systems are subsequently integrated. It then connects the EMR, RCM, and priority partner solutions through standards-based integration including HL7 FHIR®, and it proves value early with time-boxed pilots before scaling responsibly.
The outcome is what the board asked for in the first place, and it is what running best means in healthcare: an institution that adopts innovation at its own speed, meets its regulatory obligations by design, and, where it chooses to, takes part in emerging health data collaborations on its own terms. I will not promise any CIO that a platform shrinks the portfolio overnight, because none does, and every practitioner knows that platforms are additive in the first place before they are consolidating. What it does provide is something more important: an operational model with a credible, governed path from a landscape that dictates its own terms to one that follows yours.
In my previous posts I described SAP’s global healthcare industry strategy, a modular, data-driven, open, and interoperable platform, and I argued that a digital health platform (DHP) is ultimately a business decision that belongs on the CEO’s desk. Once the board has made that call, however, the mandate lies with the CIO, who turns a strategic ambition into a governed and sequenced delivery program that runs alongside daily operations without disrupting them. This post is written for that very role, and it tries to focus on two questions: what does a digital health platform powered by SAP actually consist of, and why does it make the CIO’s task easier instead of adding yet another program to an already full portfolio?
A landscape grown by change, not by design
In my experience, most healthcare providers definitely do not suffer from a lack of applications; they suffer from a system landscape that has grown over many years and rarely by design, and the figures show this: a symplr survey of health system clinicians and CIOs found that a majority of organizations run somewhere between 50 and 500, sometimes even more, different software solutions to operate their healthcare business, and in the United States alone the sector saw more than 900 hospital merger and acquisition transactions between 2014 and 2024, each of which brought their own systems, teams, and technical debt into somebody else’s landscape. So, there is an electronic medical record (EMR) system, or several of them after mergers, one or more revenue cycle management (RCM) systems for billing and patient accounting, a sometimes aging enterprise resource planning (ERP) system, a number of departmental specialty systems, research databases, and a long tail of point solutions, each of which brings its own data model, its own integration approach, and its own vendor release schedule. In such a landscape, every new capability becomes its own project, and every project has to solve integration, data quality, and compliance all over again, and the pace of change of the whole institution is effectively set by whichever vendor moves slowest.
The timing pressure is real, too. Many hospitals still run SAP Business Suite 7 (ECC), whose mainstream maintenance ends in 2027, with extended maintenance through 2030 and a Transition Option in SAP Private Cloud through 2033, and in Europe the secondary-use provisions of the European Health Data Space (EHDS) Regulation begin to apply in March 2029, which means the CIO’s delivery window for both obligations is essentially the same three to four years. And the platform market itself is being shaped in exactly that window: Gartner estimated in its April 2024 research “Innovation Insight: Digital Health Platforms Accelerate Transformation” that the digital health platform market was only around five percent penetrated, with adoption expected to play out over five to ten years, so the institutions making their architectural choices now are the ones whose requirements the market will form around.
The EHR-first instinct, and where it ends
Before laying out our answer, let me name the objection I hear most often, because it deserves a serious analysis. Many health systems reasonably prefer to look at their EMR vendor first for any new capability; successive Bain and KLAS surveys have found that roughly two out of three look first to their existing vendors, and especially their EMR vendor, before considering anyone else. I understand the instinct, since the EMR carries the clinical workflows and much of the clinical data, and nobody wants another vendor relationship without good reason. Yet the same market research paints a sobering picture of how that instinct works out in practice, with only about a quarter of executives in a Sage Growth survey saying their EMR vendor fully lives up to its promises. The deeper issue, though, is not vendor performance but scope: the decisions a CIO is now asked to support, from cost transparency per procedure to workforce planning to supply chain resilience to research data provisioning, depend on finance, procurement, workforce, and logistics data that does not live in the EMR and never will, and a system built to document and bill for care was simply never designed to be the enterprise data and AI foundation of a health system. This is, incidentally, also where the analyst community has landed: Gartner has addressed its digital health platform research explicitly to healthcare provider CIOs since its initial Market Guide in 2021, describing a shift away from monolithic, EMR-centric application suites towards a platform architecture, and in its most recent framing “Digital Health Platforms (Transitioning to Healthcare Provider Industry Cloud Platforms) Reviews and Ratings” positions the category as evolving into Healthcare Provider Industry Cloud Platforms whose purpose is to let a CIO adjust the application portfolio at the pace of business change. That last phrase describes the job better than I ever could.
Connect, govern, innovate, transform
Our strategy for the digital health platform powered by SAP addresses exactly this in four dimensions: connect, govern, innovate, and transform. Let me take them in the order an actual delivery program would.
To connect means to bring disparate systems into a single, coherent view across clinical and enterprise operations. The platform speaks the standards your landscape already uses, among them HL7 FHIR®, openEHR, IHE (Integrating the Healthcare Enterprise), OMOP (the common data model of the Observational Medical Outcomes Partnership), and, in Germany, ISiK as the national interoperability standard for hospital information systems. It connects EMR and revenue cycle management systems as well as EHDS-related sources, alongside SAP and non-SAP applications, whether they run as software as a service, cloud-native, hybrid, or on-premises. The AnyEMR/MultiEMR and AnyRCM/MultiRCM principles I described in the strategy post apply here, too: the platform integrates across whatever clinical and billing systems you have chosen rather than locking you into a single vendor’s stack, and since SAP does not build EMR or RCM systems itself, we unify across them together with and through our partner ecosystem.
To govern is, for the CIO, the most consequential of the four: in most institutions today, governance is a per-project exercise: every integration project defines its own access rules, every research request triggers its own anonymization effort, every audit finding produces its own remediation plan, and the sum of all this is a patchwork of controls that nobody can fully describe, let alone defend under time pressure. On the platform, governance becomes a managed capability instead. Master data governance, identity and access, consent and rights management, pseudonymization and anonymization, and data sovereignty compliance are built into the architecture and travel with every data product, so a rule defined once, for example who may see identifiable patient data and under which consent, is enforced wherever that data flows, whether into an operational dashboard, an AI model, or a research extract. That does not make audit readiness automatic, because audits will always also examine processes and people, but it makes audit readiness sustainable, since the technical controls no longer have to be reconstructed and re-documented for every new use of the data. And where residency requirements demand it, the same architecture can be deployed on sovereign-cloud options, so that the jurisdiction question is answered by design rather than negotiated per project. This is also where regulation stops being only a burden: an institution whose consent, provenance, and de-identification are managed capabilities enters the EHDS era prepared, while one that handles them project by project will spend those same years catching up.
To innovate then builds on that foundation rather than around it: a composition layer with analytics from descriptive to predictive, knowledge graphs for reasoning across clinical, operational, and financial domains, healthcare-specific semantics and ontologies, which are expanding to include terminologies such as SNOMED CT and the OMOP data models, and AI domain models including clinical natural language processing, all accessible through build tools from low-code to pro-code, so that extensions live safely outside a clean core and survive the next upgrade, a lesson many of us learned the hard way in the ERP world. And to transform is simply what follows when the first three are in place: decisions powered by governed data and embedded AI, at a pace the institution sets for itself.
The architecture, seen from the delivery side
At the top level, the DHP architecture consists of three layers, and increasingly a fourth. A data foundation provides clinical, enterprise, and ecosystem connectivity, including the healthcare interoperability standards mentioned above. A digital innovation layer carries the intelligence and the health-specific business context. A healthcare experiences layer offers applications such as patient portals, clinical workplaces, health apps and dashboards, and scenarios like clinical trial matching, patient identity resolution, and the EHDS health record. And on top of these sits the AI layer, in which embedded intelligence, assistants, and increasingly agentic capabilities operate on the governed layers beneath them rather than beside them. Readers who know Gartner’s published DHP reference architecture from their “Market Guide for Digital Health Platforms” will recognize the shape of the first three: an integrated data fabric with health data connectors, data curation and enrichment, metadata management, a healthcare-specific data model, and privacy and consent controls; a layer of packaged business capabilities; and a composition layer with low-code tooling for building tailored experiences. Our architecture is a concrete instantiation of exactly that pattern, and it deliberately extends it in the one dimension that has moved fastest since the pattern was first described: the AI layer on top. And for readers who want to explore how this platform category is developing across the wider market, Vince Kuraitis’s series “Platforming Healthcare – The Long View” offers a thorough long-term perspective.
What binds these layers together is the data product, and it comes in two kinds. Primary data products are sourced directly from a clinical or enterprise application and represent the original, unprocessed data: claims records from the revenue cycle management system, encounter summaries from the EMR, patient records from a clinical data repository (CDR), or financials from SAP Cloud ERP. Derived data products are curated and enriched on top of them, and here, health-specific content such as Patient 360, treatment cost, clinical workforce readiness, and patient risk scores, which deliver ready-to-use insight without additional integration effort, are being built out. Anyone who has run a hospital integration program knows why this matters: instead of maintaining n×m point-to-point integrations between sources and consumers, you build governed, reusable assets once and consume them everywhere, with lineage and policy enforced from the start.
This is what that AI layer changes in practice: because it is grounded in exactly this governed, contextualized data, and because it acts through the platform’s managed capabilities rather than around them, AI can be deployed where it demonstrably relieves pressure in daily operations. SAP Joule, our AI assistant, is being extended by SAP and partners with healthcare scenarios to address the everyday pain points of running a hospital, from clinical documentation, coding and DRG optimization, and denial management to medication replenishment, patient scheduling, regulatory reporting, and workforce planning, while differentiating industry scenarios around Patient 360, clinical workforce optimization, and denial prevention and revenue recovery build on the very same foundation. The CIO needs neither a separate AI stack nor a separate governance regime for it, and no separate integration program to feed it, because the platform itself is the AI foundation. It is also the path to what we at SAP call the Autonomous Enterprise: operations in which routine work increasingly runs itself, under the institution’s own rules and controls. That kind of autonomy cannot be installed; it becomes possible only once connected data, business context, and governance are already in place, which is exactly what the layers beneath the AI provide.
That this approach works in practice is not a hypothesis: Hirslanden, Switzerland’s largest private hospital group, modernized its core processes and systems to support new clinical practices, regulatory standards, and cost reimbursement using SAP Signavio business transformation solutions, an example of how process intelligence grounded in a common platform accelerates transformation in healthcare rather than adding to the project load.
An ecosystem by design
No single vendor covers healthcare end to end, and we at SAP do not pretend to. Partners extend the platform with the clinical capabilities and industry solutions, built on SAP Business Technology Platform and SAP Business Data Cloud, delivered through SAP PartnerEdge, and available via SAP Store. For the CIO, that translates into freedom of choice at the edges and a stable, standards-based core in the middle.
A pragmatic sequence, not a big bang
Given the maintenance and regulatory horizons described above, a deliberate sequence is in fact the lower-risk path. It begins with mapping the landscape and agreeing on three to five cross-functional use cases that span clinical and operational domains. It continues with setting up the data foundation and publishing the first data products with governance in place, and with modernizing the ERP core at the institution’s own pace, be it with GROW with SAP for first-time adopters or with RISE with SAP for existing landscapes, where most providers favor separating the ERP and hospital information system transformations, with ERP first, to harmonize master data before clinical systems are subsequently integrated. It then connects the EMR, RCM, and priority partner solutions through standards-based integration including HL7 FHIR®, and it proves value early with time-boxed pilots before scaling responsibly.
The outcome is what the board asked for in the first place, and it is what running best means in healthcare: an institution that adopts innovation at its own speed, meets its regulatory obligations by design, and, where it chooses to, takes part in emerging health data collaborations on its own terms. I will not promise any CIO that a platform shrinks the portfolio overnight, because none does, and every practitioner knows that platforms are additive in the first place before they are consolidating. What it does provide is something more important: an operational model with a credible, governed path from a landscape that dictates its own terms to one that follows yours.
Go to Source
2026-07-20 16:24
Except for the headline, this story has not been edited by Healthcare Central is published from a syndicated feed.
