Ringholm-Logo Ringholm  Whitepaper Ringholm page header

The Role Agent: a new middleware concept

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


Abstract

Healthcare IT applications synchronize their data by exchanging messages. These messages are mostly based on the HL7 version 2 standard. The HL7 version 3 standard raises some entirely new requirements for the migration of other messaging standards to HL7 version 3. These requirements can be met by new type of message-broker middleware: a Role Agent.

It is assumed that the reader is familiar with the basic concepts of HL7 version 3.

1. Integration issues

A typical healthcare organization uses a multitude of separately developed IT applications. The exchange of healthcare related data between these systems is required both for administrative as well as clinical reasons.

The problems associated with systems integration in healthcare IT have been well known for years, and have lead to the development of messaging standards such as HL7. Message Oriented Middleware (MOM, a.k.a. message broker or communication server) are being used to deal with some of the integration issues, e.g. the reformatting of encoding layers (ITS), code translations, event mappings and message routing. This paper won't address these well-known issues.

The publication of the HL7 version 3 (HL7 v3) standard has given rise to some new aspects of systems integration issues. These issues have always been present, but are highlighted by the introduction of HL7 v3.

This paper aims to describe some of these new issues as well as the requirements made as to the functionality of middleware required to solve the issues. These include the migration issues raised by having mixed environments of HL7 v3 and HL7 v2 applications.

When describing the integration issues this paper will use some terminology as used by the HL7 v3 HL7 Development Framework (HDF) [v3Guide]. These terms will also be used in a non-HL7 context.

  • Interactions are at the heart of messaging. The formal definition of an interaction is: A unique association between a specific message type (information transfer), a particular trigger event that initiates or "triggers" the transfer, and the responsibilities of the receiving application (in terms of how it should respond to a message). It is a unique, one-way transfer of information.
  • A trigger event is an explicit set of conditions that initiate the transfer of information between system components. A trigger event is described by a name and the description of the condition that would cause information to flow. More than one interaction can be initiated by the same trigger event, but each interaction is triggered by only one trigger event.
  • Application roles describe the type of system component that sends and receives the message. The scope of responsibility for a particular application role is the complete set of interactions in which the system component participates, either as a sender or a receiver.

1.1 Interactions

1.1.1 Interaction Subsets

Conformance to HL7 V3 is specified in terms of Application Roles. These are abstractions that express a portion of the messaging behaviour of an information system. A vendor of a healthcare application describes its conformance by asserting that it completely supports all trigger events, messages and data elements associated with one or more Application Roles. This level of specificity allows clearer pre-contractual understanding between vendors and buyers and will serve as a basis for conformance testing.

It is one of the aims of HL7 v3 to decrease the optionality in terms of interactions. The reduced optionality will greatly help HL7 to approach plug and play specificity.

Although the concept of application role can be applied to any message standard, HL7 v3 will make it mandatory (at some point in the future) that each application role has to support the entire set of interactions that have been assigned to that role.

If the application role takes care of the receipt of messages, the application also has to take care of the "Receiver Responsibilities". Receiver responsibilities refer to the receiving application role's additional interactions. Receiving a message may be considered a trigger event that causes information to flow, or there may be additional conditions that must be fulfilled prior to subsequent message(s) being sent.

It is unlikely that all applications will be able to conform to the requirements made by specific Application Roles. The application may use HL7 v2, DICOM or a proprietary format, or the application vendor may have decided not to be compliant. Examples of requirements include:

  • A laboratory system with a HL7 v2 messaging interface is to be integrated with an ordering application that has a HL7 v3 messaging interface. The laboratory system accepts order messages without acknowledging them and sends laboratory results when there is a need to do so. The ordering system expects the laboratory system to support all interactions related to the roles 'Order Filler' and 'Intent Filler'. These e.g. also require the laboratory system to support status requests messages as well as queries for laboratory results.
  • The IHE Technical Framework [IHE] describes the roles and interactions related to imaging-related workflow processes (using either DICOM or HL7 messages). Actors (i.e. an application that claims conformance to a role) have to support all interactions specified in the workflow process.

MOM can play a role in bridging the expectations as to the support for specific interactions by Application Roles.

Middleware requirements:
I. The middleware component should be able to act as an application that conforms to a particular Application Role, even when the applications it exchanges messages with don't conform to an application role.
II. In order to achieve (I), all data that is received should be stored in a structured manner for use in future interactions.
III. The middleware component should be able to receive as well as sent messages encoded according to the specifications of HL7 v2, HL7 v3, as well as EDIFACT and other messaging standards.

1.1.2 Interaction Model

Messages may be sent using many modes and topologies. Messages may be sent in a manner that requires an immediate response (e.g. query-response), as a result of a publish/subscribe mechanism, as unsolicited updates, or in batches where the manner and timing of message transfer is not specified. In case the expectations with regard to the interaction model differ between the systems involved, a middleware component may be required to bridge the differences.

Example: Imaging Modalities and PACS systems are mainly (DICOM based) query/response oriented and frequently need to exchange messages with the Radiology Information System (RIS). RIS applications use an (HL7-based) event-triggered mechanism. Appointments are scheduled in the RIS and sent to interested applications. Imaging Modalities typically request to receive a working list once a day. MOM can play a role in bridging the different interaction models, e.g. by caching data until it is requested.

Middleware requirements:
IV. The middleware component should be able to store (cache) all data that is received for it may be queried by another application.
V. The middleware component should be able to generate events based on changes in data or a particular point in time.

1.2 Routing

HL7 v3 messages may be sent using many modes and topologies. Messages may be sent as unsolicited updates through a store and forward network. HL7 v3 includes support for "one-to-many", store-and-forward distribution of messages by an external software agent [v3backbone].

HL7 does not require a specific mapping of messages in a one-to-many environment, but the HL7 V3 notion of application roles strongly suggests one useful paradigm. When a trigger event occurs in a system that is fulfilling one application role it will frequently have an obligation to interact with multiple systems that implement different application roles.

The sending system can send a single Broadcast Message that contains the information for all the application roles that are on the network. These messages are candidates for one-to-many distribution. A Broadcast Message includes all the message elements that must be sent from one application role to all other application roles in response to a trigger event. [v3Glossary].

The interaction concept as described in HL7 v3 relies heavily on the fact that any application is aware what other applications exist and what role they perform. This will have to be configured in an application.

Example: If a Broadcast Message is sent by an HIS system to a MOM product, the message may or may not be explicitly addressed to a number of receiving applications. Implicit addressing has the advantage that the routing of the messages is transparent to the individual sender or receiver. The MOM product broadcasts the applicable subset of the received data to the interested parties.

Middleware requirements:
VI. The middleware component should be able to send the data encapsulated in broadcast messages to the appropriate destination applications.
VII. The middleware component has to be aware what applications exist and what roles and/or interactions they support.


1.3 Trigger Events

The set of conditions that causes a Trigger Event must be systematically recognizable by an automated system. Trigger events can be as simple as manual intervention, where a human user "invokes" a specific message transfer. In many cases the successful completion of a particular business transaction is also a trigger to send messages, such as a particular point in time (e.g., at midnight send all queued update transactions), or a relative interval of time (e.g., every 12 hours send accumulated information to a tracking system). A message may also be sent as a result of an "alert" event that results from monitoring a complex set of data elements for a particular pattern of values.

Although the mapping of events by means of traditional MOM is common, this mapping leads to problems in practice. This is also due to the fact that the current MOM products tend to be transaction oriented, i.e. the data contained in the message will only be available as long as the message is in transit. Reuse of the data when a related event occurs isn't possible.

Example: The SAP IS-H system has an event model that differs from the event model of HL7. The SAP events tend to be more atomic in nature. If a MOM product is being used to bridge these differences, then an HL7 event may have to be triggered when certain data elements have been changed in the course of processing various SAP events. An HL7 event may have an equivalent in the form of 0 or more SAP events.

Middleware requirements:
VIII. The middleware component should be able to both 'translate' events as well as autonomously generate events based on changes in data, a particular point in time, or a time relative to another event.
IX. In order to achieve VIII, all data that is received should be stored in a structured manner, both in order to be able to detect trigger events as well as for their use in future interactions.

1.4 Message Detail

Application Roles are sometimes identified as being "loosely coupled" versus "tightly coupled." This distinction refers to whether or not additional information about the subject classes participating in a message may be commonly available to system components outside of the specific message. Loosely coupled application roles do not assume common information is available, while tightly coupled application roles do assume information is available. Information may be common because both system components have access to a common data store or repository or there may be separate, but synchronised, data stored within each system.

Another issue related to the availability of data is the granularity of detail (of attributes). An attribute is defined as a property of a real-world object and can be interpreted as a message element. HL7 v3 will be more 'granular' than HL7 v2. Increasing granularity is a near impossibility.

Example: Assume that a MOM product is being used to cache all data as it is received in the form of messages that are sent by applications. If a HL7 v2 message is received, its data may be subject to a process of data cleansing (or data enrichment) with the aid of data that was previously received from other sources. The result can then be sent to a receiving application.

Middleware requirements:
X. The middleware component should be able to send a message related to a particular event that contains a different set of data elements and/or a different level of granularity than that of the message it received.
XI. In order to achieve X, all data that is received should be stored in a structured manner for use in future interactions.

2. The Role Agent

Chapter 1 discusses some of the integration issues that have been highlighted by the introduction of the new HL7 v3 standard. Each of the issues identified has lead to new requirements as to the functionality of a MOM product in order to cover these issues. A new type of middleware, the structure of which is described in this chapter, covers these requirements.

A Role Agent is an application that acts as an Application Role on behalf of another application that doesn't support that Application Role.

2.1 Functional Requirements

A Role Agent should at least cover the requirements identified in chapter 1. A summary of these requirements is listed below.
  • The Role Agent should act as a storage facility for structured healthcare data, both in order to be able to detect trigger events as well as their use in future interactions. An internal data model based on widely accepted modelling standards should be adopted. (See requirements I,II,IV,IX,XI)
  • The Role Agent should allow for the import and export of data using various methodologies. It should be possible to extract data using a number of standard message formats (e.g. HL7, EDIFACT); it should be possible to export the entire contents of the database. (See requirement III)
  • The Role Agent should be able to send the data encapsulated in broadcast messages to the appropriate destinations. (See requirement VI)
  • The Role Agent has to be aware what applications exist and what roles and/or interactions they support. (See requirement VII)
  • The Role Agent should maintain meta information related to the status of objects and transactions, e.g. who has created a visit, what is its status.
  • The Role Agent should be able to trigger an event based upon object-state changes. It should be able to trigger a reply-event as the result of a query-event. It should be able to generate an event based on values of various (medical) data, or on the simple fact that a certain time has elapsed after another event. (See requirements V,VIII,X)
  • The Role Agent should facilitate the migration of vocabulary/coding standards in order to ensure long-term consistency of the semantic content. This can be achieved by using a vocabulary server.

2.2 Architecture of a Role Agent

A possible architecture of a Role Agent consists of 3 basic layers:
  • The Storage Layer. This layer is responsible for the persistent storage of the data. The implementation of this layer can be based on an existing Electronic Health Record (EHR) application (e.g. based on CEN-HISA or OpenEHR).
  • The Transaction/Interaction Manager (TIM). This layer monitors the status of transactions and generates trigger-events based on messages that were received by the I/O layer and or the data in the Storage Layer.
  • The I/O layer: This layer is responsible for the encoding and decoding of messages as well as the storage and/or retrieval of data from the Storage Layer.

Schematic showing the message flow between 3 applications and a role agent.

The typical message flow is as follows: All messages sent by applications to the Role Agent are processed by the I/O layer. The data will be stored in the Storage Layer and the TIM will be informed of the event code. The TIM contains rules that define how the event should be dealt with, i.e. what outbound events to what systems should be the result of the inbound event. If the inbound event results in outbound events, the appropriate event code is handed over to the I/O layer. This layer will fetch the data required for a message of the outbound event type from the Storage Layer and encode it according to a messaging standard.

3. Concluding Remarks

The HL7 version 3 standard dramatically reduces optionality and unambiguously defines the application boundaries. Adoption of version 3 is likely to take considerable time, if only because of the initial development costs of version 3 interfaces as well as the efforts required to migrate any existing interfaces. Vendors will be slowly forced to support version 3 (next to version 2) due to market pressure. Both versions will probably coexist for years.

A Role Agent is a MOM product that is useful in integration projects in healthcare, especially in environments that use a mixture of HL7 version 3 and other standards.

4. References

[IHE] "IHE Technical Framework", 2008, http://www.ihe.net/
[v3Backbone] "HL7 version 3 Backbone", /foundationdocuments/helpfiles/backbone.htm (part of the version 3 standard), 2008, http://www.hl7.org/
[v3Guide] "HL7 V3 Guide", /foundationdocuments/helpfiles/v3guide.htm (part of the version 3 standard), 2008, http://www.hl7.org/
[v3glossary] "HL7 Version 3 Glossary", /foundationdocuments/helpfiles/glossary.htm (part of the version 3 standard), 2008, http://www.hl7.org/


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.