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

The role of Message Brokers: a management overview

Copyright Ringholm bv © 2002,2010. All Rights Reserved.
See http://www.ringholm.com/docs/00100_en.htm for the latest version of this document.
Author: René Spronk - Sr.Consultant, Ringholm bv
Document status: Final, version 1.2 (2003-10-15)
Please send questions and comments to Rene.Spronk@Ringholm.com.


Abstract

The diminishing use of monolithic applications and the growing number of best-of-breed applications are leading to an ever-increasing number of applications in the average healthcare provider organisation. This leads to fragmentation of healthcare data. At the same time there is an increasing demand for a unified view on all patient data. A Message Broker is a middleware product that is used to bridge this ever-widening gap.

1. Interfacing

Most of the information used in Healthcare-related processes is either stored in a paper folder or in one of the main information systems (e.g. HIS/PAS, Laboratory, Radiology). There is an increasing need to be able to view of all of the patients’ medical data from any place at any time. In order to be able to collect and present patient data contained in- and collected by applications the level of integration of the applications ranges from the exchange of data between systems to the creation of a unified electronic patient record. The application interface is that part of the application which takes care of the communication with other applications, e.g. by means of sending and receiving messages. Integration is the process of sharing data via the application interfaces of 2 or more applications.

The structure of Healthcare provider organisations and the way they are financed have led to a high degree of autonomy of departments with respect to their choice of IT applications. Departments tend to choose the application that suits their particular requirements best, often referred to as the best-of-breed solution. While these applications in their standalone capacity support the activities of the departmental processes, the integration of these applications has a clear added value for the organisation as a whole.

The diminishing use of monolithic applications and the growing number of best-of-breed applications lead to an ever-increasing number of applications in the average healthcare provider organisation. At the same time there is an increasing demand for a unified patient view that allows both care as well as administrative personnel to have access to patient data. Integrating the applications is a necessary step to bridge this ever-widening gap.

The traditional way of integration is based on point-to-point connections. The healthcare provider organisation has very little control over the creation, maintenance and upgrading of this type of proprietary solution, and the dependency on the vendors involved is relatively high. More often than not there is a per-interface based yearly maintenance fee and a change of one of the systems involved causes the whole point-to-point connection development cycle to start all over again.

1.1 An Analogy: The Telephone System

[Tannenbaum99] When Alexander Graham bell patented the telephone in 1876 there was an enormous demand for his new invention. The initial market was for the sale of telephones, which came in pairs. It was up to the customer to string a wire between them. If a telephone owner wanted to talk to n other telephone owners, separate wires had to be strung to all n houses. Within a year, the cities were covered with wires passing over houses and trees in a wild jumble. It became immediately obvious that the model of connecting every telephone to every other telephone was not going to work.

Bell saw this and formed the Bell Telephone Company, which opened its first switching office in 1878. The company ran a wire to each customer’s house or office. To make a call, the customer would crank the phone to make a ringing sound in the telephone company office to attract the attention of an operator, who would then manually connect the caller to the called using a jumper cable. Pretty soon, Bell System switching offices were springing up everywhere and people wanted to make long-distance calls between cities, so the Bell system began to connect the switching offices. While there have been many improvements –e.g. automatic switching- since then, the basic Bell System model has remained essentially intact for over a 100 years. 

Using this analogy, creating the point-to-point interfaces between applications is the equivalent of paying the vendors of the applications to “string a separate wire between 2 telephones”. Should an organisation decide to upgrade or replace a system, a new point-to-point connection has to be created. This is akin to buying a new telephone and having to replace the wire to the other phone as well. 

A Message Broker can be thought of as a Bell switching office, taking care of all connections between the various systems in an organisation. Like the switching office a Message Broker has 1 connection to each system. In addition to the provision of connectivity services and automatic message routing (switching), most Message Brokers also provide translation services. Systems are likely to use different data formats just as telephone users may use different languages.

2. The Message Broker Concept

A Message Broker takes care of all connections between the applications in an organisation. One connection is created between each system and Message Broker, and messages transported via this bi-directional connection can be translated, filtered, archived, modified and routed to their final destination(s). 

The transport of messages can be based on one of many transport protocols supported by the broker (e.g. TCP/IP, files). The Message Broker takes care of translations between the data formats used by the various systems. All commonly used message formats are supported in the base product (e.g. HL7, EDIFACT, XML, delimited formats, SAP/HCM, flat records).

Most modern Message Brokers can be configured and maintained using a GUI interface. Because of the flexibility of the GUI knowledge of programming can be kept to an absolute minimum. Instead of programming point-to-point connections a connection can be set up using a graphical toolset.

The use of a Message Broker offers a scalable platform that has access to data sent by many applications in the organisation, it improves the reliability and accessibility of data and it concentrates all available message flows in one point. Because of the fact that the message broker processes all messages, a copy of the data contained in the messages can easily be forwarded to analytical, management database or other applications. Creating a focal point for data thus adds to the quality of care, the integration of data, and the central management of the connections.

2.1 Typical applications of Message Brokers

This section describes how a Message Broker is typically used in a healthcare provider organisation. The following examples will be provided provided:
  1. Its role as an open integration tool – managed by the healthcare provider organisation
  2. Its role as an application migration tool
  3. Its role as an outsourced or ASP integration tool

2.2 Using the Message Broker as an open integration tool.

A Message Broker is mostly used in its role as a strategic and open integration platform. Given the problems and costs associated with point-to-point connections a majority of healthcare provider organisations use a Message Broker to manage their system interfacing requirements. Being an open solution it provides the organisations with full control over the integration process. In this scenario, most organisations elect to implement and maintain the product and the interfaces themselves.

The initial development, i.e. the migration of the existing point-to-point connections to Message Broker is mostly taken care of by the vendor of the Message Broker or by a consultancy company in close cooperation with the employees of the healthcare provider organisation. This phase of the implementation project is often combined with a form of “training on the job” for the responsible employees of the organisation. An implementation project typically includes training of the employees with respect to the configuration and maintenance of the Message Broker application, enabling them to define as well as maintain message structures, translations and protocol connections used by the applications in their organisation. 

After the handing over of the interfaces and the supporting documentation the day-to-day management of the interfaces as well as the development of additional interfaces can be taken care of by the organisation’s own employees. A 24-hour, 7 days a week helpdesk is available to assist in case problems or questions arise. 

By using Message Broker as a strategic solution for all integration requirements the maintenance costs of point-to-point connections are significantly lowered and new connections can be created at little costs using the organisation’s own resources.

2.3 Using the Message Broker as an application migration tool

When used in its role as an application migration tool Message Broker facilitates the migration of the application interfaces, resulting in the alleviation of a resource bottleneck within the overall migration project.

In those cases where most of the integration is based on point-to-point connections and one of the main systems has to be replaced by an alternative solution, all point-to-point connections between the system that has to be replaced and the systems it is connected to need to be redeveloped. 

The development of these new connections can be a major problem, mainly because of the fact that it has to be done at the same time as the introduction of the new application. Having to deal with all migration-related issues at the same time usually leads to resource problems in terms of available personnel. 

If application A has point-to-point connections with B, C and D and application A is replaced, all these connections have to be created anew. A Message Broker can be used to alleviate the resource problem by using a strategy that deals with the connectivity issue before the new system is introduced. Using the example used before, 1 connection would be created from Message Broker to each of the applications A, B, C and D using the message formats and transport protocols as currently in use by those point-to-point connections. The applications are not even aware that something has changed and that Message Broker is now processing (and possibly translating) the messages. Replacing application A with X requires the development of 1 new link to X and the translation of the X messages into the old formats used by B, C and D. 

By using a Message Broker as a migration tool the overall scope of work is considerably smaller, the migration of the interfaces requires minimal involvement of application vendors, and most of it can be completed before starting the actual migration process –which frees up the time of scarce resources during the actual application testing and migration process.

2.4 Using the Message Broker as an outsourced or ASP-based integration tool

When a Message Broker is used in its role as a component in an outsourced or ASP-based integration service, the whole process of developing, updating and maintaining the various connections is dealt with by a third party (mostly a Message Broker distributor or reseller). Small healthcare provider organisations or those organisations without an IT department typically seek to outsource their application maintenance to third parties. There are at least 2 ways of outsourcing an organisation’s integration requirements:
  • Outsourcing (traditional style): The required integration services are provided by means of a Message Broker installed at the Healthcare organisation’s site. The Message Broker will be remotely configured, monitored and maintained by a third-party.
  • ASP (Application Service Provision): The required integration services are provided by means of a Message Broker installed at the site of the ASP-provider and by transporting the messages to and from the healthcare provider organisation’s site by means of a VPN (Virtual Private Network, an encrypted link using the Internet). Message Broker will be configured, monitored and maintained internally within the support department of the third-party.
IT-related tasks such as the provision of integration services may be regarded as non-core issues by a healthcare provider organisation. By using Message Broker as part of an outsourcing or ASP arrangement, organisations aren’t burdened with the task of having to deal with the increasing demand for connectivity.


3. Summary

The increasing demand for systems integration in Healthcare and the costs/problems associated with point-to-point connections require that one uses an open Message Broker. The use of a Message Broker has a much better cost/benefit ratio than point-to-point connections: the costs of maintaining the connections is lower, the migration of systems is eased, the cost of creating new connections is significantly lower and the exchange of data is improved, ultimately leading to a raised quality of care. As illustrated in the typical applications section the functionality of the product can be offered either as an open strategic integration platform (with your own employees having full control) or as an outsourced (or ASP) service. 

In terms of the analogy introduced in the telephone system section, the use of a Message Broker to integrate an application is the closest thing to the simple act of plugging in a new telephone. 

4. References

[Tannenbaum99] “Computer Networks”, Andrew S. Tanenbaum, Prentice Hall, 1999.


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.