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: 
bettina_lieske
Product and Topic Expert
Product and Topic Expert


Have you ever made the experience that within a group of people you had problems understanding each other, but as soon as someone starting drawing a picture, everyone was on the same page?
This is exactly the purpose and essence or modeling: it helps you better understand a real world situation by getting rid of the details and by describing it in an abstract way.

In general, you can use models for both, for explaing something that exists and for depicting something that you plan to build later on.
This also applies to software industry: a model can be used to explain how the business process platform for Healthcare (BPP4HC) behaves and what functionalty it offers. But it can also be used for specifying and designing the future scope (like interfaces) of the BPP4HC.

Since the 1970s, modeling techniques are being used to describe system behaviour (like IDEF or general purpose modeling techniques), and the need for models persists and even grows in the SOA world. This was the reason why we supervised a diploma thesis in this area. This thesis by Nadine Häsner with the title "Modeling a Service-Oriented IT-Architecture for Healthcare Service Providers" will be made available via the BPX in the next weeks.

SAP developed a modelling methodology for Enterprise SOA based on the following building blocks:

Business Objects

Business Objects are entities of the real world that the different systems of a given system landscape want to communicate about, like a patient, an invoice or an encounter.  

Process Components
Process components are logical components that provide a product independent view on the IT landscape. Examples are Patient Financials or Patient Encounter Management. The value of defining process components is twofold:

  • A precisely defined functional scope

  • A clear responsibility for each prcoess component answering the question who (which system) covers the functional scope in a particular customer situation.
    Each business object belongs to one and only one process components (e.g. the business object encounter belongs to the process component Patient Encounter Management).


Services
Services are offered at a business level of abstraction upon the defined  BO’s .There are simple services called “CRUD” services (CRUD = create, read, update, delete) , but also more complex services like Find Patient Encounters by Elements which answers the question: Which patients have been admitted during the last month?

Maybe an example can illustrate some of these building blocks: Imagine you wanted to integrate three systems (a clinical system, the industry solution SAP Patient Management and the SAP ERP) like shown in this figure:



The process component model then helps you to define the cut between these three systems in terms of responsibilities for the different functional blocks. In the first situation, the clinical systems takes over the responsibility for Patient Encounter Management and for Scheduling, whereas this is done by SAP Patient Mangement in the second situation:

Situation 1:                                                             Situation 2:

  "

Based on the defined building blocks, four different models can be defined, each of them offering a dedicated view on the BPP 4HC. SAP Enterprise Modeling Applications by IDS Scheer is the modelling tool being used at SAP. The following paragraphs give a short overview of these models.

The Scenario Integration Model gives an overview of the connected systems and shows where communication takes place. The example below gives you a little glance of this model:



The Consumer Model describes sample processes (e.g industry best-practices) and shows how single process steps correspond to Enterprise Services.

The Process Component Interaction Model helps the integration experts of the IT department to understand the details of a given interaction between two process components. Starting from this model view they can drill down to the technical formats of XML messages and understand the design of the communication patterns, e.g. request/confirmation, query/response, notification etc. as well as the Business Objects.



Last, the Provider Model offers a "white box view" of a process component. It show in detail which Business Objects are exposed through their Service Operations to the outside world.

You want to learn more? All the mentioned building blocks and models are at your fingertips through the Enterprise Services Workplace where you can drill down to the enterprise services through the applications or directly via the solution maps or via the Enterprise Services Bundles Wikis. You can drill through the ES Wikis to the Process Components and down to each individual enterprise service with its WSDL.

The attentive reader might have noted that I am the one responding to Engineering a Business Process Platform for Healthcare Part 2 - Key Concepts & Components of providing insights on SAP's modeling methodology.