Integrating healthcare services, Part 1: Using an Enterprise Service Bus for healthcare

Configure a Java Business Integration server to make diverse applications interconnect and interoperate

Ideally, the diverse services that medical patients need should interconnect and interoperate to enhance healthcare quality and efficiency. This article, the first of two parts, discusses the aggregation of healthcare services using Java™ Business Integration (JBI) architecture. Such an aggregation platform — a Healthcare Service Bus (HSB) — can be readily adapted to other industries.

Bilal Siddiqui (xml4java@yahoo.co.uk), Consultant

Bilal Siddiqui is an electronics engineer, an XML consultant, and the co-founder of WaxSys, a company focused on simplifying e-business. After graduating in 1995 with a degree in electronics engineering from the University of Engineering and Technology, Lahore, Pakistan, he began designing software solutions for industrial control systems. Later, he turned to XML and used his experience programming in C++ to build Web- and WAP-based XML processing tools, server-side parsing solutions, and service applications. Bilal is a technology evangelist and a frequently published technical author.



18 May 2010

Also available in Chinese Russian Japanese Portuguese

This two-part article demonstrates the aggregation of various healthcare-related services over a service bus, which I call (aptly enough) a Healthcare Service Bus (HSB). Here in Part 1, I'll start with a use-case scenario in which various applications that serve patient needs are connected to an HSB, and I'll explain the features the HSB should provide. Next, I'll introduce Java Business Integration (JBI) architecture, used for building the HSB. By following the sequence of events that occur inside a JBI server, you'll see how JBI works internally for business integration and how its components coordinate with external applications. The last section of Part 1 provides configuration examples that demonstrate how you can control the behavior of JBI components so that they work for healthcare. In Part 2, you'll learn how to integrate healthcare services using the existing functionality of an open source JBI implementation (Apache ServiceMix) and by implementing new ServiceMix functionality.

A service bus for healthcare

An HSB integrates a variety of healthcare-related services. Imagine the needs of an emergency patient who requires life-saving care, including services such as blood transfusion, emergency prescriptions, and radiology tests.

When the patient arrives at a medical facility, the doctor in charge uses the service bus to check the patient's allergy history from an application running on the patient's cell phone. The doctor also enters initial observations about the patient's condition into a medical prescription application connected to the bus. The doctor's observations travel over the service bus into a Web server hosting the portal of the insurance company that covers the patient.

The doctor then prescribes a blood transfusion for the patient into the same prescription application. The prescription is automatically sent over the service bus not only to a few blood banks, but also to a donor-group application, which sends SMS messages to donors whose blood samples have been prematched with the patient's. The blood requirement to the donor-group application also travels over the service bus.

The doctor also writes a prescription for emergency drugs and a radiology test, which are fed into the same prescription application. The prescription application sends these prescriptions over the bus to the medical facility's in-house pharmacy and radiology department.

Aggregation of services

You can see from this use-case story that the HSB allows diverse applications to interconnect and interoperate, thereby enabling aggregation of services. Two main types of applications — service consumers and service providers — connect to the HSB. The prescription application that sent the blood transfusion requirement to the HSB acted as a service consumer (an application that requests or consumes a service). The donor-group application that sent SMS messages to potential blood donors acted as a service provider (an application that provides the requested service). Interconnection and interoperation are different requirements that together provide aggregation of services. Interconnection means that service providers and service consumers have a common way of connecting to (reaching) one another, so that they can interoperate with one another (exchange information and messages). The HSB uses the popular XML format for interoperable exchange of messages.

HSB as SOA

An architecture such as the HSB's that relies heavily on "services" is called Service Oriented Architecture (SOA). SOA simply means that everything is a service. The donor-group application is a service that sends out SMS messages. The radiology department is also a service, one that performs radiology tests on demand. In an SOA, any application that exposes the service is a service provider and the application that demands, requests, or uses a service is a service consumer.

Figure 1 shows service providers and service consumers connected to the HSB:

Figure 1. Service providers and consumers connected to an HSB
Service providers and consumers connected to an HSB

Note that Figure 1 shows three service providers connected to the HSB: the Insurance Company Portal, Donor Group, and Radiology Department applications. An HSB should be able to interconnect service consumers to both in-house and external service providers, so that they can interoperate with one another. In Figure 1, the Radiology Department application exists within the medical facility; the Donor Group and the Insurance Company Portal applications are outside the medical facility.

Required HSB features

To enable interconnection, the HSB must:

  • Keep a log of all service providers connected to it, so that it can route a service-consumption request from a service consumer to the appropriate service provider.
  • Provide a standard mechanism that lets service providers and service consumers talk to one another through the service bus.
  • Allow other HSBs to interconnect with it.

Interconnection of HSBs

Interconnection of HSBs is an interesting application, the architecture of which is shown in Figure 2:

Figure 2. Interconnection of HSBs
Interconnection of HSBs

Figure 2 shows two HSBs for different medical facilities. One facility has a Blood Bank application, which the Prescription application can invoke through interconnection of the two HSBs.

XML for interoperable healthcare

XML can be used in two ways to enable interoperability of healthcare services:

  • Web services: Web services based on Web Services Description Language (WSDL) and Simple Object Access Protocol (SOAP) are frequently used in many industries, including healthcare. WSDL uses XML to define the service; that is, define the interface that the service provides. SOAP is an XML-based protocol used for actual messaging between service providers and consumers. (See Resources for more information about WSDL and SOAP.) The HSB should be able to interconnect any healthcare application that uses WSDL and SOAP for interoperability.
  • Health Level 7: Health Level 7 (HL7) is a set of popular healthcare standards that define many data structures used to specify healthcare information, such as medical records, prescriptions, and patient discharges summaries. (Older HL7 versions 1 and 2 were based on ASCII. The recent HL7 version 3.X uses XML as its data format for defining message structures.)

Generalizing the HSB to other industries

The interconnection and interoperability requirements discussed here are applicable to industries other than healthcare. For example, the diverse services in the tourism industry — hotels, airlines, car rentals, and tour operators — must interconnect and interoperate to serve their customers. The HSB's three interconnection features are applicable to the tourism industry as well. Different service providers such as hotels and car rentals can easily use WSDL and SOAP to interoperate. And industry-specific XML-based standards like HL7 can exist in any industry.

The HSB that I'll demonstrate can interconnect healthcare applications that use the WSDL, SOAP, and HL7 standards.

ESB: A general architecture for interoperability and interconnection

Such a generalized interoperable and interconnected architecture is typically referred to as Enterprise Service Bus (ESB), which can:

  • Be based on SOA.
  • Allow service providers and consumers to use WSDL and SOAP.
  • Be extensible and flexible in the sense that it allows service providers and consumers to use industry-specific XML-based standards such as HL7.

The idea of an ESB is not new. Several ESB implementations exist today. (See Resources for links to some popular open source ESBs.) This means that there's no need to build an HSB from scratch. You can configure an existing ESB to work for healthcare.


Using JBI as an HSB

The JBI specification defines a standardized Java business-integration environment. JBI provides all the features of an ESB that I have discussed, so I'll use it to build an HSB.

Several JBI implementations are available, including a popular open source implementation from Apache called ServiceMix. The rest of this series is all about using JBI and configuring ServiceMix to build an HSB.

JBI components working together for healthcare

Figure 3 shows how JBI can be used as an HSB:

Figure 3. JBI working as an HSB
JBI working as an HSB

You can see in Figure 3 that the three main components of JBI are Binding Components (BCs), Service Engines (SEs), and a Normalized Message Router (NMR).

I'll explain the working of JBI components with the help of the sequence of events (shown in Figure 4) that happens when the Prescription application (a service consumer) connects to the Donor Group application (a service provider):

Figure 4. Service consumer connecting to a service provider though JBI
Service consumer connecting to a service provider though JBI

The following sequence occurs in Figure 4:

Step 1: The Prescription application (a service consumer) connects to JBI and asks for the service offered by the Donor Group application (a service provider that sits outside the JBI environment).

Step 2: The JBI environment forwards the service request to an appropriate BC — the one that receives all service requests from the Prescription application. Each service consumer or provider that works with JBI has a particular dedicated BC inside the JBI environment.

Step 3: The BC transforms the service invocation request into a normalized format defined by the JBI specification. The purpose of defining the normalized format is to enable interoperation between BCs. All JBI BCs understand the normalized format. Each BC also understands the format of the service provider or consumer to which the BC is attached. In other words, JBI's normalizing feature is a common format into which all BCs transform messages received from their respective service consumers or producers.

Step 4: The Prescription application's BC hands over the normalized message to the NMR shown in Figure 4. The entire JBI environment includes a single NMR.

Step 5: The NMR's job is to receive normalized messages from one BC, identify the target service provider, and forward (or route) the normalized message to another BC of the target service. In this step, the NMR forwards the normalized message to the BC connected with the Donor Group application.

Step 6: The BC of the Donor Group application denormalizes the normalized message, thereby transforming it into the format understood by the Donor Group application.

Step 7: The BC hands over the denormalized message to the Donor Group application.

This sequence of events reveals two simple points about JBI:

  • JBI works on the idea of normalized message routing. Each message is normalized by a BC and handed over to NMR. NMR routes the message to another BC, which denormalizes it into the format understood by the intended service provider.
  • The normalized-message-routing mechanism provides a decoupled architecture. Decoupling means the service providers and consumers interact with one another only through the NMR mechanism. They don't interact directly with one another.

The main advantage of this decoupled architecture is that you implement a particular data format or standard only once, in the form of a BC. Later, all service providers that provide services according to the particular data format simply use an instance of the BC to become integrated into the JBI environment.

For example, if you must integrate HL7 into JBI, you need a BC that understands HL7. If you have the HL7 BC, you can integrate any HL7 service into JBI, thereby forming an HSB.

Part 2 of this series will give you practical steps for building an HL7-based BC and integrating HL7 into JBI. But for the moment, there's more to learn about JBI.

Mixing internal and external services in JBI

The discussion accompanying Figure 4 shows the communication between a service consumer and a service provider that resides outside the JBI environment.

Recall from the use-case story at the beginning of this article that the Prescription application also sent a message to an in-house radiology department. This means that your JBI environment should be able to host the Radiology Department application as an internal service. Internal services in JBI are hosted as SEs.

SEs are just like BCs with one additional feature: An SE also contains the business logic of the internal service (for example, of the Radiology Department application). BCs and SEs are both connected to JBI's NMR, as you saw in Figure 3, which I've modified in Figure 5 to show the Radiology Department application as an SE:

Figure 5. Radiology Department application shown as an SE
Radiology Department application shown as an SE

The sequence of events to access an internal service (that is, an SE) is shown in Figure 6:

Figure 6. A service consumer accessing an internal service provider
A service consumer accessing an internal service provider

The sequence of events shown in Figure 6 represents what happens when a service consumer such as the Prescription application sends a message to the Radiology Department application (an internal service provider):

Step 1: The Prescription application (a service consumer) connects to JBI and asks for the service offered by the Radiology Department application.

Step 2: The JBI environment forwards the service request to the BC of the Prescription application.

Step 3: The BC transforms the service invocation request into a normalized message.

Step 4: The BC hands over the normalized message to NMR.

Step 5: The NMR forwards the normalized message to the Radiology Department application (an SE).

Step 6: The SE internally denormalizes the message and invokes the required business logic.

This sequence of events — which is quite similar to the sequence of events shown Figure 4 — shows that an SE contains the functionality of a BC and also the business logic of the service-provider application.

It may appear that an SE unnecessarily mixes two separate things (the functionality of a BC and the business logic). In Part 2, I will show you how to build the business logic of your internal service on top of an existing BC, without any unnecessary mixing.

Interconnecting JBI-based ESBs

Refer back Figure 2, in which I show the interconnection of HSBs. This interconnection can be achieved through JBI, as shown in Figure 7:

Figure 7. Two interconnected JBI environments
Two interconnected JBI environments

Note that Figure 7 shows different applications connected to two separate JBI environments. The following sequence of events happens when the Prescription application (shown connected to the first JBI in Figure 7) sends a message to the Blood Bank application (a service provider that resides inside the second JBI environment):

Step 1: The Prescription application (a service consumer) connects to the first JBI and asks for the service offered by the Blood Bank application.

Step 2: The first JBI environment forwards the request to the BC of the Prescription application.

Step 3: The BC of the Prescription application transforms the service invocation request into a normalized message.

Step 4: The BC of the Prescription application hands over the normalized message to the NMR.

Step 5: The NMR forwards the normalized message to the BC connected with the second JBI environment.

Step 6: The BC connected with the second JBI environment denormalizes the message.

Step 7: The BC connected with the second JBI environment hands over the denormalized message to the second JBI environment.

Step 8: The second JBI environment receives the request and forwards it to the BC connected with the first JBI environment. This means the two JBI environments connect to each other through appropriate BCs.

Step 9: The BC connected with the first JBI environment transforms the service invocation request into a normalized message.

Step 10: The BC connected with the first JBI environment hands over the normalized message to the NMR.

Step 11: The NMR forwards the normalized message to the Blood Bank application (an SE).

Step 12: The SE internally denormalizes the message and invokes the required business logic.

Message-exchange patterns in JBI

The discussions accompanying Figures 4, 5, 6, and 7 show one-way communication — sending a message from a service consumer to a service provider. The service provider (such as the Donor Group application) does not send a return message. JBI documentation refers to this type of messaging as in-only message exchange. The in-only message-exchange pattern is suitable for services like the Donor Group application, which only needs a one-way message to the group. No information is required to travel back to the requesting Prescription application.

Some other service (such as the Insurance Company Portal application) may be required to send a response. Such a request-response messaging pattern is also allowed in JBI and referred to as in-out. As you might guess, the response also travels in the same manner from the service provider through the JBI environment — BCs, SEs, and NMR — and ultimately to the service consumer. So I won't include another sequence of events to describe in-out messaging.


Configuring and bootstrapping your JBI environment

The JBI specification provides a detailed XML schema for defining the behavior of all BCs and SEs that you wish to host on JBI. Now I will describe how you can use the JBI schema to configure a JBI implementation as an HSB.

I won't discuss the entire JBI schema in this article. I'll focus here on one important JBI tag called <component>. Part 2 will demonstrate the use of more JBI schema tags.

The <component> tag defines a JBI component. A component can be a BC or an SE. Listing 1 shows what the XML configuration of the BC for the Prescription application looks like:

Listing 1. XML configuration for the prescription application's BC
<?xml version="1.0" encoding="UTF-8"?>
<jbi xmlns="http://java.sun.com/xml/ns/jbi" version="1.0">
<component type="binding-component" 
    component-class-loader-delegation="parent-first" 
    bootstrap-class-loader-delegation="parent-first">
    <identification>
        <name>Prescription-Application</name>
        <description>Binding Component for the prescription application</description>
    </identification>
    <component-class-name>
        org.apache.servicemix.cxfbc.CxfBcComponent
    </component-class-
    <component-class-path>
      <path-element>lib/servicemix-cxf-bc-2009.01.jar</path-element>
      <path-element>lib/geronimo-annotation_1.0_spec-1.1.1.jar</path-element>
      <!-- other path-element tags -->
    </component-class-path>
    <bootstrap-class-name>
        org.apache.servicemix.common.DefaultBootstrap
    </bootstrap-class-name>
    <bootstrap-class-path>
      <path-element>lib/servicemix-cxf-bc-2009.01.jar</path-element>
      <path-element>lib/geronimo-annotation_1.0_spec-1.1.1.jar</path-element>
      <!-- other path-element tags -->
    </bootstrap-class-path>
</component>
</jbi>

You can see that Listing 1 contains a <component> tag with a type attribute and five child tags named <identification>, <component-class-name>, <component-class-path>, <bootstrap-class-name>, and <bootstrap-class-path>.

The type attribute specifies whether the component is a BC or an SE. Listing 1 configures the BC for the Prescription application, so the value of the type attribute should be binding-component.

The <identification> tag in Listing 1 provides a name and description for the BC.

The <component-class-name> tag specifies the Java class that implements the logic required by the BC. The JBI specification has a standard interface named javax.jbi.component.Component, which all BCs should implement. I am going to use Apache ServiceMix in this series to demonstrate the working of an HSB. ServiceMix provides a BC that can be used to work with service consumers that consume SOAP-based Web services. The class that implements the logic of this BC is named org.apache.servicemix.cxfbc.CxfBcComponent. In Part 2, I'll use this class to demonstrate how the Prescription application works with JBI. That's why Listing 1 includes org.apache.servicemix.cxfbc.CxfBcComponent as the name of the component class wrapped inside the <component-class-name> tag.

Now look at the <component-class-path> tag in Listing 1. It has two child tags named <path-element>. These tags specify the path to all JAR files that the component class needs in order to execute. This means the <component-class-name> and <component-class-path> tags form a pair that specifies the name of the BC's Java class as well as the complete class path required to execute the Java class.

You will find another pair of tags named <bootstrap-class-name> and <bootstrap-class-path> in Listing 1. This pair is similar to the previous pair of <component-class-name> and <component-class-path> tags. The bootstrap pair specifies the name and class path of the Java class that implements the logic of bootstrapping the BC.

Bootstrapping means putting the BC into service. Bootstrapping occurs when you start your JBI server (ServiceMix). The bootstrapping class contains all the logic to bring the BC to life and get it up and running.

Now look at the <component> tag in Listing 2, which represents an external service provider such as the Donor Group application. Listing 2 has exactly the same structure as Listing 1, so it does not need any explanation.

Listing 2. XML configuration of an external service provider
<?xml version="1.0" encoding="UTF-8"?> 
<jbi xmlns="http://java.sun.com/xml/ns/jbi" version="1.0">
<component type="binding-component" 
    component-class-loader-delegation="parent-first" 
    bootstrap-class-loader-delegation="parent-first">
    <identification>
        <name>Donor-Group-Application</name>
        <description>Binding Component for the Donor Group application</description>
    </identification>
    <component-class-name>
        org.apache.servicemix.cxfbc.CxfBcComponent
    </component-class-
    <component-class-path>
      <path-element>lib/servicemix-cxf-bc-2009.01.jar</path-element>
      <path-element>lib/geronimo-annotation_1.0_spec-1.1.1.jar</path-element>
      <!-- other path-element tags -->
    </component-class-path>
    <bootstrap-class-name>
        org.apache.servicemix.common.DefaultBootstrap
    </bootstrap-class-name>
    <bootstrap-class-path>
      <path-element>lib/servicemix-cxf-bc-2009.01.jar</path-element>
      <path-element>lib/geronimo-annotation_1.0_spec-1.1.1.jar</path-element>
      <!-- other path-element tags -->
    </bootstrap-class-path>
</component>
</jbi>

Listing 3 shows another <component> tag that tells how to configure an SE — an internal service provider (such as the Radiology Department application):

Listing 3. XML configuration of an internal service provider
<?xml version="1.0" encoding="UTF-8"?> 
<jbi xmlns="http://java.sun.com/xml/ns/jbi" version="1.0">
<component type="service-engine" 
    component-class-loader-delegation="parent-first" 
    bootstrap-class-loader-delegation="parent-first">
    <identification>
      <name>Radiology-Department-Application</name>
      <description>Radiology Department Service Application</description>
    </identification>
    <component-class-name>
        org.hsb.radiology.RadiologyBean</component-class-name>
    <component-class-path>
      <path-element>lib/radiology-bean.jar</path-element>
      <path-element>lib/geronimo-annotation_1.0_spec-1.1.1.jar</path-element>
      <!-- other path-element tags -->
    </component-class-path>
    <bootstrap-class-name>
        org.apache.servicemix.common.DefaultBootstrap
    </bootstrap-class-name>
    <bootstrap-class-path>
      <path-element>lib/ radiology-bean.jar</path-element>
      <path-element>lib/geronimo-annotation_1.0_spec-1.1.1.jar</path-element>
      <!-- other path-element tags -->
    </bootstrap-class-path>
  </component>

</jbi>

If you compare Listing 3 with Listing 2, you'll see only one major difference: The type attribute value in Listing 2 is binding-component (because it is a BC representing an external service provider), whereas the value of the type attribute shown in bold in Listing 3 is service-engine because it is an SE representing an internal service.


Coming up next

You have seen how to use JBI's <component> tag to configure your BCs and SEs. JBI also provides a reusability mechanism for building general-purpose BCs that can be used in various scenarios.

JBI implementations such as ServiceMix provide prebuilt BCs that come bundled with the implementation. You don't even need to configure the <component> tag for such BCs. The implementation will already know the classes and other details of such BCs.

Part 2 will put the pieces together and demonstrate how you can use the existing functionality of ServiceMix as well as build and configure new functionality — that is, implement and configure a BC or an SE — to integrate healthcare services.

Resources

Learn

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Java technology on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Java technology, Open source, Industries
ArticleID=490337
ArticleTitle=Integrating healthcare services, Part 1: Using an Enterprise Service Bus for healthcare
publish-date=05182010