Ringholm-Logo Ringholm
 Whitepaper
Ringholm page header
Training    Services   |   Whitepapers    Blog    Events    Links   |   About us    Partners    Clients    Contact

SAP IS-H Interfacing capabilities

The contents of this whitepaper are published under the Creative Commons Attribution-Share Alike license.
See http://www.ringholm.com/docs/00630_en_SAP_ISH_HL7.htm for the latest version of this document.
Author: René Spronk, Sr. consultant, Ringholm.
Document status: Final, version 0.8 (2009-05-21)
Please send questions and comments to rene.spronk@ringholm.com.


Summary

What interfacing capabilities does the SAP IS-H application have, and how do I support HL7 interfaces? That question is at the heart of this whitepaper. It describes the three interfacing options and how those can be used to import and export data.

1. Introduction

IS-H (Industry Solution for Healthcare) is a Hospital Information System (HIS), an enhancement of the standard SAP R/3 System designed specifically for use in hospitals. It supports patient management, medical and nursing documentation, and patient accounting. It is one of the main HIS systems implemented in German speaking countries, mostly in large hospitals. IS-H has also been implemented (to a lesser degree) in other countries.

The SAP IS-H solution has the following interfacing capabilities (most of which have been present in unchanged form since about 2002) that are in regular use today:

  • HCM interface (and a deprecated HL7 version 2.1 interface based on HCM)
  • BAPI Remote Procedure calls
  • Patient Management Enterprise Services
Please note: this document uses the word ‘case’ to identify a case (German: Fall) using its SAP definition. A case is mostly equal to an encounter or visit. The exact meaning of ‘case’ is discussed in Appendix A.

2. HCM interface

The term ‘HCM’ is used to refer to two different things:
  1. The communications module of IS-H which allows for messages to be sent by IS-H to other applications
  2. The message format used by those messages. This whitepaper has its focus on the exchange of data between applications and hence uses HCM to refer to the message format.
The HCM interface has been present in IS-H since its inception. The HCM interface is bidirectional and allows for the export of HCM messages (whenever an associated trigger event happens with IS-H) as well as for the import of HCM messages.

2.1 Structure of HCM messages

HCM messages are defined as a sequence of segments (identified by a 3-character name, e.g. HEA, PAT, FAL, END). The contents of the HCM segments are loosely based on HL7 version 2. Each segment is defined as a sequence of fields. Each field has a fixed-width – filled with trailing spaces if the actual data is of a smaller size. A HCM message is communicated as one long string which consists of the concatenation of (segment names, field contents in a segment).

The HCM export interface supports only a couple of different message structures (known as SY011, SY012, SY013, SY018). (in HL7 version 2 terms: the message structures ADT_A01, ADT_A02, ADT_A03, ADT_A18; in HL7 version 3 terms: Encounter Update R-MIM, Patient registry Update R-MIM). Each message structure is used for conveying data related to multiple trigger events.

The HCM import interface supports a couple of different message structures (e.g. SY021, SY104 and SY102). (in HL7 version 2 terms: BAR_PO1, DFT_P03; in HL7 version 3 terms: the Account and Billing domain/Account and Billing Topic).

2.2. Trigger Events

Whenever an application-level trigger event occurs the IS-H application will add it to a table of trigger event codes. This trigger event table in turn causes the HCM export module to create a corresponding HCM message. The list of trigger events is relatively elaborate, most triggers exist in the area of patient demographics and patient encounters (in HL7 version 2 terms: those triggers defined for ADT messages/chapter 3, in HL7 version 3 terms: those triggers present in the Patient Administration/Encounters and Patient registry topics). The HCM import functionality is limited to data which supports the billing process: diagnoses codes, case-related procedure codes, diagnoses/procedures related to a surgical operation. Note: case-related procedures codes can’t be imported via HCM.

2.3. Transport

HCM messages are imported/exported via a file based transfer mechanism.

2.4. HL7 version 2.1

The HL7 version 2.1 interface of IS-H was created in the mid 1990s. It is a translation of the HCM-messages to HL7 version 2.1 messages. HL7 version 2.1 messages are created and sent whenever a trigger event happens within IS-H. There is no support for query messages. Development was effectively abandoned around 1997. HL7 version 2.1 was only partially implemented, with support for only a few trigger events and segments. Although one can still use it today, it is known to be incomplete. In current implementations of IS-H this interface isn’t used – the HCM-message interface provides a better alternative.

Advertisement for Ringholm training.

3. BAPI Interface

The BAPI interface is an API based RPC interface (e.g. in Java) which allows other applications to call the functions as available within IS-H. Note that BAPIs use a request-response mechanism; there is no trigger event based mechanism for the export of data. Full documentation of all available BAPIs can be found in the online documentation of IS-H itself. IS-H contains a long list of standard BAPIs. Using the standard BAPI as shipped with IS-H one is able to (for example):
  • Register a new/update patient or case information in a third party application and export them to IS-H
  • Upload coded procedures, coded diagnoses and other relevant billing information above and beyond that which is possible in HCM.
A developer/consultant that has knowledge of SAP R/3 has the ability to create new BAPIs and/or to modify the existing BAPI should those not meet the requirements for the exchange of data.

3.1. Link with HCM

Given that there is no trigger event based mechanism for the export of data using BAPIs a combination of HCM and BAPIs can be used instead. Upon the receipt of an HCM message (effectively: a notification that a specific trigger event has happened) one can call a BAPI to get hold of additional data not present in the HCM message. For an example of this approach, see a whitepaper on the reuse of HCM triggers to call BAPIs.

4. Patient Management Enterprise Services

The Patient Administration ES bundle uses application-to-application (A2A) services to seamlessly integrate SAP Patient Management (based on SAP ERP 6.0) with the many third-party systems typically deployed in today's healthcare facilities in the areas of Patient Identification and ADT (Admission, Discharge, Transfer). The full list of services can be found here.

The Patient Management ES bundle will be available for production use from May 2009 onwards. Using a combination of this services bundle and Netweaver SAP now supports various IHE profiles (Profile PDQ; Transaction Patient Demographics Query (ITI-21); Actor Patient Demographics Supplier ; Profile PAM; Transaction Patient Identity Feed (ITI-030); Actor Patient Demographics Consumer ; Profile PAM; Transaction Patient Identity Feed (ITI-030); Actor Patient Demographics Supplier.). Netweaver is SAP’s “communication server”.

4.1. Trigger Events

Whenever an application-level trigger event occurs the IS-H application will add it to a table of trigger event codes. This trigger event table (effectively the same table used by the HCM export interface) in turn causes a service to be called on Netweaver XI - effectively exporting the data from IS-H to Netweaver. The export of data involves a four-step process:
  1. Enterprise Services creates a proprietary XML format (which corresponds to SAP’s internal object model, as used for exchanges between all kinds of SAP solution)
  2. ES calls a Netweaver service using the XML as its 'payload'
  3. The XML format is mapped to v2.XML (using Netweaver XI)
  4. V2.XML is mapped to ‘classic’ v2 format using a third party solution

5. Summary

Almost all known implementations of IS-H in the german-speaking countries use a third-party communication server to translate between HL7 version 2 messages and HCM/BAPI (and vice versa).

The new Patient Management Enterprise Services are intended to be used in combination with NetWeaver XI .

The use of a communication server effectively encapsulates the IS-H interfacing capabilities in a (IHE compatible) HL7 version 2 interface. HCM lends itself relatively well to translations to HL7 version 2. There are some noticeable caveats, e.g. the ones related to the support for movements (see appendix B) and the case concept (see appendix A). HL7 version 2 has no support for such concepts.

Some clinical applications in the German market are tightly integrated with IS-H (notably IS-H MED). These applications will have native support for HCM, BAPIs and (in future) Patient Management Enterprise Services.

Appendix A: Case

A case (as defined in German re-imbursement regulation) consists of 1 or more related ‘atomic’ encounters/visits. A case is a unit used for billing; costs and diagnoses/procedure codes are associated with a case. A case could me more than just 1 encounter, but it is considerably less than that which is generally referred to as a ‘clinical pathway’.

A case in IS-H is usually associated with exactly one encounter/visit. One of the exceptions is related to ‘pre-inpatient-care’ and ‘post-inpatient-care’ (in German: Vorstationäre Behandlung, Nachstationäre Behandlung). All diagnostic tests done in preparation for an upcoming inpatient-care encounter and all activities performed up to 14 days after the discharge of the patient are associated with one single case. The type of a case changes over time, e.g. in terms of messaging one could first receive a “new case #1 of type pre-inpatient-care for patient ABC”, followed by a “change case-type of case#1 from pre-inpatient-care to inpatient”, followed by a “discharge case #1”.

In HCM messages a case# may be communicated jointly with the encounter type of one of its component encounters. This leads to a number of synchronization issues: e.g. as far as a departmental system is aware there is an ‘active inpatient encounter’, and yet it receives data associated with the same case# of type ‘outpatient’. This type of synchronization issue typically occurs in applications that don’t support one and the same underlying case model as supported by SAP.

HL7 only has the concept of encounter/visit (both are modeled in the same fashion), defined as either a single inpatient stay or a single outpatient visit. Depending on how the IS-H case concept is being used it may be difficult to map the data between HL7 and IS-H.

Appendix B: Movement

A movement is either a transfer of the location of the patient, or a transfer or responsibility for the patient. Each and every movement has an identifier (a sequence number – with the context of a case) associated with it. The movement concept doesn't translate very well to HL7 concepts.

One of the other issues related to movements is the fact that under some circumstances data will be communicated about ‘historic movements’ (i.e. a movement not equal to the latest movement for a case/encounter). Most third-party systems don’t support ‘movements’, they only track/store ‘the latest/current status’. Updates about historic movements are often erroneously processed as if they were related to the latest movement.

In order to detect if a movement is the latest one for a case/encounter, one would have to know the ‘latest movement number’. The HCM export module can be changed (by a SAP consultant) to add an historic-movement indicator (a Boolean flag) to all exported HCM messages. By using this indicator all systems that don’t support the movement concept will have the ability to ignore historic movements. An alternative method of determining whether a HCM message is related to the latest/a historic movement is (upon receipt of the HCM message) to call a BAPI and request the latest movement number for the case identified in the message.


About Ringholm bv

Ringholm bv is a group of European experts in the field of messaging standards and systems integration in healthcare IT. We provide the industry's most advanced training courses and consulting on healthcare information exchange standards.
See http://www.ringholm.com or call +31 33 7 630 636 for additional information.