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

Creating and Enhancing an Interface

Copyright Ringholm bv © 2002,2008. All Rights Reserved.
See http://www.ringholm.com/docs/00200_en.htm for the latest version of this document.
Authors: Frank Oemig, René Spronk, Sr.Consultants - Ringholm bv.
Document status: Draft 1.5 (2003-03-04)
Please send questions and comments to frank@oemig.de.


There are generally two ways to achieve data integration in healthcare: either use one single application (and database) throughout a healthcare provider organisation, or synchronize the data between the healthcare IT applications by exchanging messages. These messages are formatted according to one of many message standard (e.g. HL7, DICOM, xDT, EDIFACT) that are used in healthcare. The vendors of applications in healthcare face a number of challenges when developing messaging interfaces.

1. Introduction

This paper focuses on the situation where a vendor has created the core functionality of a new application and now has to create a messaging interface. For the purpose of this document we will assume that the whole of the application has been finished with the exception of the messaging interface.

The following definitions will be used throughout this document:

  • A Message is a character string that contains data encoded according to a particular set of encoding rules. Encoding rules determine how (i.e. using what syntax) data elements are stored within messages.
  • A Messaging Interface or Interface identifies that part of an application that is responsible for
    1. The receipt of messages, the decoding of messages, and the process of storing the data elements which have been received in the application database;
    2. The retrieval of data elements from the application database, the encoding of that data into a message, and the transmission of the data to another application.
The development process of a messaging interface for an application generally constitutes of three phases: requirement analysis, interface design and implementation.

2. Requirement Analysis

The functional requirements of the interface(s) and a testing plan should be drawn up and agreed upon prior to the start of the implementation phase. The requirements analysis starts with the identification of the use cases for data interchange. If messages are to be used to exchange data between applications the integration requirements have to be identified and described. The requirement analysis is based on those scenarios (a.k.a. use-cases) where the processes covered by the new application are part of a larger process. In such cases there is probably a need for data to be exchanged between the systems that support these processes.

This amounts to the identification of event-triggers and the definition of the scope of data that has to be exchanged. An event-trigger is a real world event, mostly reflected as a state-change within the application, that triggers the transmission of data. All events are associated with a set of data relevant to the event. The design of event-triggers should be derived directly from functional descriptions and analysis of current work and data flow as well as vendor capabilities to support.

The Interfacing requirements of an application depend for a large part on the applications that the application has to be integrated with. The scope of data required by these applications determines the minimum dataset that has to be sent by the interface; the scope of data sent by other applications determines the maximum dataset that can be imported by the interface.

3. Design of the Interface

The design of the interface hinges on 2 major implementation decisions: the encoding rules (or message format) that is to be used, and the method in which the messages will be transported (the transport protocol).

It is very important that decisions made during interface design be thoroughly and clearly documented and kept up to date. Interface programming, testing, support, maintenance, and upgrades will all be facilitated by detailed, accurate design documentation.

3.1 Message Format

The message format can be either based on one of the many available message standards (e.g. HL7, DICOM, xDT, EDIFACT) or it can be a proprietary format. It is advisable to create an interface that is based on an official standard; the use of proprietary format mostly leads to problems at a later point in time. If there is a standard that is widely used by applications one has to communicate with then the best choice will be to support that standard, since this will greatly ease future integration projects.

You will need to understand the chosen standard to a relatively high degree. Using the documentation of the standard and some example messages you should be able to specify what messages have to be exchanged. Identify the trigger events supported by the chosen messaging standard that correspond to the state-changes in the application. Make sure to document what action in the originating system triggers specific transactions over the interface.

Be aware of the risk of misinterpreting a standard, this often leads to new "variants" of the standard and incompatibilities. "Training on the job" and "external coaching" by those that have practical experience with the standard may help to understand the standard and lower the risks of misinterpretation.

3.2 Transport Protocol

Interfaces can be implemented in a number of environments, including among applications on a single system, point-to-point between systems, or over a network. The interface will be built on top of some media and data transport protocol. Most transport protocols used for the exchange of messages are asynchronous in nature. They are either on-line (e.g. based on TCP/IP or HTTP) or off-line (e.g. the exchange of files). An on-line communications link is bi-directional in nature, which allows for error and flow control.

Off-line communication is often described as import or export functionality, i.e. the application processes or writes files using a specific file naming format. The processing of files is based upon polling, i.e. available files will be processed after a set interval.

TCP/IP is currently the de-facto on-line communication standard. Almost all interfaces support a transport protocol based on TCP/IP. This also includes IPsec, and HTTP/HTTPS. Other on-line communication standards include SNA LU6.2 and RS232. These transport protocols are mostly supported by legacy systems although they're likely to support TCP/IP as well.

When developing the interface one should create procedures to handle transport protocol issues such as system and interface restarts, recovery and re-synchronization.

4. Implementation of the Interface

The code that has to be developed does not just include the interface code for each application, but also includes additions or modifications to system or application software, communications software and perhaps network management or diagnostic software. The problems encountered during the development process are quite often far from trivial.

If one (rather unrealistically) chooses to implement a simple message format and an off-line communication protocol the interface can be written quite easily. But if one decides to facilitate a more complex messaging standard the use of a message parser will be necessary. If you decide to develop (yet another) message parser, this will take anything from a week to a couple of months. We urge you to consider using a third party library or toolkit to implement the interface. There are various commercial or public-domain toolkits that facilitate the development of the interface.

The addition of new application systems may increase the number of duplicate tables or dictionaries stored in multiple systems. In order to minimize transactions that are rejected by the interfaces due to unsynchronised tables, you'll have to develop procedures to control the order and frequency of table maintenance in application systems. You will have to agree upon any master files that need to be built to facilitate interface(s) as well as provisions for their creation and maintenance. Any references by data elements within the messages to tables and dictionaries should be documented. The analysis of tables and dictonaries involved should not be taken lightly, the correct interpretation of data is impossible if systems use values derived from different reference tables.

You should also create interface documentation that documents the message structure and the transport protocols supported. This document will be used by other vendors to create/modify their interfaces. This document can be based on the internal project documentation but should not be burdened by product-internal details. The documentation process is never a favourite of the development department, and this is especially true for documentation as is required by third parties.

Aim to reach an agreement as to who supports the interface(s) once they are implemented and live. Develop a list of all of the support responsibilities for the new system(s) and interfaces including items such as end-user help desk support, routine maintenance, and interface monitoring. Determine resource and skill requirements for all support responsibilities. Identify personnel who will be responsible for support and develop a training program to address any skills deficiencies. In order to be able to support the interface, the support team needs to have knowledge of the messaging standards and transport protocols as supported by the interface.

Define high-level implementation and testing strategies. This should be reviewed with all parties (users, resources, etc.). This document should include all procedures, processes, criteria, data, and documentation to be used. This approach will be finalized as part of the implementation phase of the project. Before finishing the development process the interface has to be tested against other applications. This includes performance testing to ensure that the interface will support the amount of messages that it will have to deal with when deployed at a customer site. Systems integration is mostly still a form of art, which means that testing should be thoroughly done.

The software can be used at a customer site once testing has been completed and your organisation is ready to support the interface module.

5. Summary

The following key points should be kept in mind when developing a new interface module:

  1. Before launching the development process identify the use cases for data interchange.
  2. Use a well established messaging standard (e.g. HL7, EDIFACT, DICOM) in order to achieve interoperability of applications.
  3. Consider using an open source or commercial toolkit before developing yet another message parser.
  4. Support the TCP/IP socket protocol in addition to any other transport protocols mandated by your customer base.
  5. The outsourcing of the interface to outside specialists may help to save resources, both in terms of time and money.
  6. Document all stages of the development, implementation and testing process. Create documentation of the interface aimed at other vendors who will connect their application to yours.
  7. Test the interface thoroughly before considering rollout to a customer site.

6. References

[HL7] "HL7", 2006, http://www.hl7.org/ and http://www.hl7.de/
[Dicom] "DICOM", ACR-NEMA, 2006, http://medical.nema.org/
[xDT] "xDT", 2001, http://www.kbv.de/ and http://www.zi-koeln.de/

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.