The Role Agent: a new middleware concept
Copyright Ringholm bv © 2002,2010. All Rights Reserved.
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 issuesA 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.
1.1.1 Interaction SubsetsConformance 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:
MOM can play a role in bridging the expectations as to the support for specific interactions by Application Roles.
1.1.2 Interaction ModelMessages 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.
1.2 RoutingHL7 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.
1.3 Trigger EventsThe 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.
1.4 Message DetailApplication 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.
2. The Role AgentChapter 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 RequirementsA Role Agent should at least cover the requirements identified in chapter 1. A summary of these requirements is listed below.
2.2 Architecture of a Role AgentA possible architecture of a Role Agent consists of 3 basic layers:
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 RemarksThe 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 bvRingholm 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.