In my last blog I have mentioned our HL7 solution based on the Healthcare Enterprise SOA and technical platform Netweaver.
After that I have got several questions from my blog readers asking whether SAP could really support HL7, how does it work and so on.
I am really very happy to have got your feedbacks and to know that your are interested in this topic! So now I am going to give you a little bit technical explanations of this.
First, will SAP Healthcare be able to “talk” HL7?
Yes, we will!
All our customers know that before eSOA ISH could only “speak” HCM (SAP healthcare communication module) format but not HL7. In order to get ISH understood from others a “translator” is necessary.
But this will be changed!
How could SAP “talk” HL7?
The answer is via XI and its adapters!
To explain how it works, I need to give you a picture about how do we define the enterprise services.
The picture above shows a process model of a simple workflow, in which SAP Patient Management acts as a Patient Encounter Management (blue box on the right side) and reacts to a HL7 message from a non-SAP healthcare application (orange box on the left side).
One HL7 message (see the pink box on the left side) is sent from a non-SAP application to SAP. In react of this a notification message interface shall be defined. That is the one in the pink box on the right side. In this sample: Patient Encounter Create Notification.
This interface connects to an appropriate service operation which is called “Patient Encounter Created Notification”, this service operation is an inbound service to trigger the backend function module: CreatePatientEncounter.
Thus one patient encounter will be created!
What are the roles of XI?
1. Repository of Data, Business Objects, Mappings
Still the same picture above. There will be many processes models defined during the Enterprise Service Definition phase. To make all these processes really happen, technical data are also defined. These data are like Business Objects, Data Types, Service Interfaces, and Message Types and so on. All these technical data are stored in XI Enterprise Service Repository (ESR). They are the fundamentals to enable the business process in our case the healthcare process.
All these will be packed as a Healthcare “service packet” delivered to customers.
2. Yellow pages of Enterprise services
Enterprise Service Registry is like a yellow page.
It provides customers or partners a service discovery tool. It help them easily find the services they need to reuse and to build their own business processes. Also it allows customers and partners to publish their own services.
3. SAP Healthcare XI content
Now the most interesting part: healthcare XI content. What is it?
Please see the picture below. You see the ESR is on bottom; on top of the ESR there are mappings (I just take out the mappings from ESR and put on top of it in order to make it better visible). The left side of the mappings are the SAP healthcare scenarios and the right side of the mappings are the standard messages in an XML format.
The Service operations that we have defined in the business process model are on the left side on this picture. For example Admit Patient, Change Patient and so on. Each service operation will be generated in XI in a XML format, this XML message will be mapped to a HL7 XML format. Afterword they are the “output” from XI and “input” to an HL7 Adapter.
So generally all the service interfaces which are defined by SAP Healthcare, all the appropriate mappings for those services interfaces to HL7 XML are the Healthcare XI Content.
4. HL7 “translator” – via XI and its adapters
XI provides an Adapter Framework. Various and plenty of industry adapters are and can be integrated in the framework. These adapters could be SAP own generic adapters, industry standard adapters and Adapters from 3rd parties.
Currently there are 2 solutions provided from XI in regarding to HL7. (Sure XI Adapter Framework is open for every industry adapters from 3rd parties.)
One is a conversion tool which is called SAP Conversion Agent powered by Informatica. It converts HL7 message to XML format and vice versa. Using the Conversion Agent for HL7 solution at least one of the XI generic technical adapters is required for transport protocol.
Another HL7 solution is a HL7 adapter which is from a 3rd party: iWAY HL7 adapter. This is a complete HL7 adapter not only does the conversion but also supports protocol.
Base on these HL7 solutions, the HL7 XML message, which is mapped in XI content could be converted to a real HL7 message and sent to any non-SAP healthcare application.
5. SAP sends applications the “HL7” message
On the other hand SAP could also send a notification message to notify all its subsystems e.g. a patient is created.
Again at the backend system one function module works and triggers one outbound service operation, the service interface which is connecting to this service operation will be generated in XI in an XML format. This XML message will then be mapped to a real HL7 message and sent to other application via HL7 adapter.
So till now I hope I could give you the answer to my blog title in a “simplified” technical point of view.
I am looking forward to your feedbacks.