SAP for Healthcare Blogs
Discover insights and practical tips to optimize your healthcare operations and improve patient outcomes with SAP. Share your own experiences in a blog post.
cancel
Showing results for 
Search instead for 
Did you mean: 
SteffenGr
Advisor
Advisor





COVID created an explosion in demand for numerous technological developments that are well suited to accelerate digitization in healthcare with corresponding remote services and greater acceptance of such services. During that time, SAP built services like Corona Warn App and SAP Bed Capacity Management within month, got them to market quickly and focused on delivering monthly iterations and incremental capabilities for these new applications. It was a new approach and certainly involved learning along the way, but it was crucial to give it into customers’ hands to learn for early adaption and input on areas for improvement.

This shows how much the importance of innovative power, flexibility, and capability to deliver in time has increased. Protecting critical infrastructure and supply chain lines has never been more fundamental. In addition, SAP has decided to stop developing industry-specific applications and focus on efforts on services related to SAP’s future key strategic direction. The two main focal points here are:




  • #1 SAP offer a modular healthcare system landscape to run ERP processes enriched by partner capabilities for customers to benefit from the flexibility and a solid foundation to plan a transition to SAP S/4HANA prior to the end of maintenance of SAP Business Suite

  • #2 Forming an open healthcare partner ecosystem, inviting partners complementing our portfolio and offerings




That way SAP’s customers will be benefitting from future modular hospital information landscapes, where partners can provide their industry-specific solutions, whereas SAP puts focus on core customer non-industry-specific business scenarios and business technology. With this comprehensive approach, SAP intends to address hospital chains and health customers of all sizes, even across industry boundaries.












This blog is an attempt to work out whether technological and content paradigms from our learnings would be suitable in the long term to become successful as a platform and infrastructure provider in the healthcare industry sharing a perspective on things like:

  • What is a reasonable definition of a platform, what is its purpose and what capabilities does it need to provide?

  • What role does cloud infrastructure play?

  • Whether or not to leave the field to Amazon, Google, or Microsoft?









Definitions











A platform in this context refers to so-called 'digital health platforms' (DHP) as information exchange infrastructure where applications and systems are built to deliver health services supporting healthcare delivery. To highlight some of their qualities I would like to draw attention to some characteristics...

.



#1




There is no one-fits-all platform approach. Typically, DHPs manage a couple of business scenarios in a way that connects different user groups in a meaningful way (e.g., physicians and patients, researchers and patients, or hospitals and payers) and is categorized to serve specialized business models in both clinical and non-clinical contexts. Here are some examples:


  • Research and Data Management platforms, to support clinical studies, like those introduced by Microsoft and SilverCloud Health, AWS for Health, or Google Health


  • E-Health platforms, to support remote healthcare delivery in rather large territories, like Teamplay by Siemens Healthineers


  • E-Procurement and purchasing platforms, like Healthcare Content Data Portal by SANA

  • Technology and development platforms to provide tools to build health-related applications, like the Lightning platform by Salesforce


#2












DHP architecture principles are typically 2-fold. They all leverage cloud technology and an integrated ‘horizontal’ technology (platform) layer that sits between infrastructure and application.


Inbuilt interoperability ties different components and external applications together into a streamlined and cohesive construction.


By offering a common set of APIs, such platforms free customers from complex API management, which reduces complexity on their end and positively impacts times to market.



#3



Looking into capabilities associated with DHP's, a study by GARTNER, categorizes health platforms along the following requirements:




  • Provides healthcare-provider-specific healthcare cloud offerings


  • Offer most of the capabilities across all three layers of the reference architecture


  • Supports any one or more than one of these open standards such as FHIR, OMOP, OpenEHR, IHE, STDM


  • Offers healthcare-specific prebuilt data and analytics


  • Supports features specific to clinical care and care delivery, and secure messaging for collaboration


  • Offers capabilities to be directly used by patients/consumers, such as patient portal, mobile app, costing tools


  • Offers capabilities to assist in virtual care, and connectivity to medical devices for remote monitoring


Such platforms are designed to facilitate and accelerate the development of regulated software applications and tools and manage health data exchange while ensuring compliance with regulatory standards. In short, a well-designed platform will improve health systems by ensuring that existing digital health applications work together more consistently and effectively.










The future Hospital is a platform














On the one hand, a question that arises is whether and what clever ideas exist to replicate experiences made, so they can be used in other contexts.

Not too long ago SAP opted for an open technology platform model for the healthcare industry and communicated this to its customers and partners. This means nothing less than a long-term, sustainable reorientation that underlines our clear understanding that digital transformation only will succeed if traditional silos and procedures to a certain extent will be broken away.

To necessarily cope best with industry and consumer trends, political and economic uncertainties, and challenges ahead the design of required future industry technology capabilities and apps look totally different from what it has been in previous decades. An undisputed result of digitization is that like in other industries, the healthcare industry generates unprecedented and ever-growing volumes of (siloed) data. Such data require a robust IT infrastructure able to handle large volumes of sensitive data while ensuring compliance with local privacy, security, and regulations. Achieving this on local development platforms and infrastructure is rather challenging as it needs investment, entails significant operating costs, requires sizeable teams of experts and expertise, and needs to ensure security and product compliance to meet mandatory regulatory requirements.

But - who can afford to do this? Our industry customers aren't tech companies, nor are they financially flexible, so more likely they will consider leveraging a digital health technology platform in the form of a platform as a service (PaaS) as this enables them to manage complexity of building what they need and focus on their core business.

2nd, with the objectives of making health data universally usable and market participants becoming eco-system partners, the business opportunity is gigantic! So, in the midterm, it is commercially absolutely reasonable and viable to develop an offering and a strategy to connect most important players and make necessary changes possible.

Health platforms are on the rise and here to stay for the purpose of reshaping the industry into integrated data and engagement platforms leveraging cloud infrastructure and services. By embracing cloud technology and qualities software and services will be delivered in a more modern and iterative way, ready to cope with future challenges and opportunities. Consequences are big as the next wave of competitors is already building solutions to re-design the entire industry value chain from drug manufacturing to clinical medication, remote patient monitoring, and clinical trials.

To reflect and put this in SAP strength and perspective. there's no doubt the task is overwhelming as it is hardly imaginable a single vendor is able to fix it all. So, it requires beyond huge enthusiasm and naivety, strategic thinking and technical capabilities, a broad partner ecosystem, and strategic alliances to become an established market participant. Moreover, fully managed integration is key to giving customers flexible capabilities to integrate with a multitude of application backgrounds even through hybrid infrastructures.

Future-wise SAP could look certainly a role model for combining the innovative power and flexibility of a (health) platform provider and the deep expertise as an industry applications provider. As we have to acknowledge recent trends in healthcare, SAP will very much be operating at the health platform and network level, so beyond the enterprise of a single landscape. Given the power of the cloud and the things we already do, there is an opportunity to have much more relevance in broader networks and provide nationwide capabilities.











Platform Design














The leading paradigm in this concept is SAP the is the key actor on infrastructure, platform, and network layer, complemented by, ERP, etc. capabilities, whilst clinical domain expertise and capabilities are added by partners.



To ensure interoperability between all actors to access, exchange, integrate, and cooperatively use data SAP is leveraging the HL7 FHIR standard, introducing SAP Health Data Services for FHIR a PaaS and integration service on SAP BTP and SAP HANA Cloud as central service of the envisioned platform design. Once available, partners and customers can leverage this service to support the design, implementation, and operation of a native cloud application or service relying on health-related data. The service is meant to provide a synchronous REST and asynchronous messaging-based API capable of supporting the necessary FHIR capabilities. Naturally, it is planned to use the in-memory database SAP HANA Cloud as persistence to be able to fulfill the needs for high-performance transactional applications.


Introducing the FHIR R4 data model into our portfolio, the intention is to address intersectoral use cases and demand to come from providers, payors, researchers, and policymakers. The first selection currently under investigation concerns applications and services intended to be built or integrated/onboarded to DHP by leveraging SAP Health Data Services for FHIR and additional SAP BTP services.

by Solution Area:​



  • Developing new transactional apps or extensions with intelligent workflows, building upon readily available domain-specific profiling  ​

  • Health data pooled for research and personalized medicine: Shared health resources (data, infrastructure, expertise…) allow targeted and faster research, diagnosis, and treatment

  • Insurance: Leverage interaction between payer, provider, and patient (e.g., utilization management, denial management)​

  • Public Sector: National eHealth Infrastructure (e.g., ​e-Prescription, Health-X)​

  • Secure access and exchange of health data: Users securely access their health data and health providers (doctors, pharmacies…) can exchange them across the regions


An early detailed profile of our capabilities for quick readers...
















INTEGRATION CAPABILITIES BUSINESS CAPABILITIES COMPOSITION TOOLS


  • FHIR R4-compliant health data model on SAP BTP and SAP HANA Cloud

  • Indexing, structuring, and resource profiling provide appropriate API extensibility

  • Content-driven, persistent FHIR data service with extensibility for resources, events, and workflows

  • Event-driven business processes management supporting both visual and code-based interface




  • Enterprise & Support Service

  • Population health management, Emergency & Response

  • Operational and clinical analytics

  • Information Governance, Data integration, and visualization

  • Terminology Services

  • Predictive Analytics




  • No-code/low-code composition workbench, Business Application Studio, mobile SDKs

  • containerized API Management, Integration Suite, REST, SOAP, and O-data APIs

  • AI Business Services / Launchpad

  • Identity Management

  • In-memory data processing




It is important to note that the specifics depend on the requirements and constraints of the individual project. As a consequence, creating a customer-tailored design requires a deep understanding of the problem and the technical skills to solve it, collaboration with customer experts is a must. Security and compliance are essential to guarantee success.


Overall, capabilities like those depicted below are assumed critical to the success of digital health platforms as they allow the network to collect, manage, and analyze data, engage with patients, coordinate care, and generate revenue.



















Component design as integrated and re-usable data and functional fabric layer Technical design draft might include the depicted SAP and partner entities.



 

 












Preparing for the next normal











What overall reasonable conclusions might now be drawn based on the above...


  1. Digital Health Platforms are becoming harder and harder to ignore, as growth in health data generated by devices and other systems of record requires robust but flexible and innovative IT infrastructure and data governance approach. This is especially important while developing health-related applications.

  2. Build-or-buy is the most strategic decision with implications far beyond the IT embedded into an overall corporate strategy.

  3. One-fits-all won't work as DHPs follows purpose-driven demand and consequently architecture. Usually, they are bridging different health data silos from across the health ecosystem, intending to generate innovation, for the ultimate benefit of patients.

  4. Design and architecture in particular have significant long-term implications. No platform is plug-and-play.




As platforms begin to transform the healthcare sector, players must carefully consider their future path. SAP is committed to investing in this area and designing and developing a 'Digital Health Platform' strategy as outlined in this blog. The starting point is promising as we as a company have already laid the exciting functional and technological foundation, but it still is a long road, and many legal and technical aspects are still being discussed and articulated.

The opportunity is hot, and concerning my initial question: Whether or not to leave the field to our competitors..? Certainly not.

We are in the process of defining a strategy roadmap i.e., in areas such as interoperability, enterprise support, e-health, and data management, with an open and transparent, realistic conclusion.

What we do in detail is…




  • Fine-tuning our radar --> identifying the biggest impact opportunities


  • Selecting our foundation --> based on local strategies and frameworks set appropriate focus


  • Choosing our role --> self-positioning within the DHP provider market


  • Find our market entry point --> beyond provider industry boundaries


  • Strengthen collaboration -->  forming partner alliances


To give a full insight into the capabilities and key differentiators of a Digital Health Platform by SAP, we will publish a blog series covering additional aspects and share conceptual updates in the coming weeks and months. We are also happy to get your feedback, questions, or thoughts in a comment.

Stay tuned!


--------------------------------------------------------------


Co-Authors: Vladimir Ljubicic and Martin Burger


References:
E-Health Ireland
GARTNER, Market Guide for Digital Health Platforms
Blaise Jacholkowski, Digital Health Platforms



1 Comment
Top kudoed authors