Intelliware TEAL

TEAL is an Intelliware component that can be used to format and parse HL7 messages in Java.

The HL7 message specifications are sufficiently complicated that traditional XML to Java binding tools like JAXB or XMLBeans don't produce easy-to-use Java classes, so TEAL is a smarter, more HL7-specific marshalling technology.

Understanding HL7 Standards in Canada

To understand how TEAL works, there are a few things that you must understand about HL7, and how e-Health standards are published in Canada. The e-Health standards are managed by a group called the Standards Collaborative group, overseen by Canada Health Infoway. Various Standards Collaborative Working Groups work on the definitions of the HL7 and other standards, and release those standards as packaged "releases". For developers, the release tends to contain 3 key deliverables:

1. message format definitions;
2. vocabulary (codeset) standards; and
3. data type standards.

There is a fourth item, often more fully defined by the jurisdiction:

4. Transport-specific standards.

Each of these deliverables is taken into consideration in the TEAL component.

Message Definitions

First, let's turn our attention to message definitions. The message formats are defined in a number of documents:

• Standard XML XSDs.
• HL7-specific XML formats called MIFs (which define the individual components of a message) and DMIFs (which define the final assembly of componets into an interaction).
• More recently, a new MIF standard has been released

There are a number of advantages to XSDs: they're fairly well standardized, with many viewers, editors, and other tools available to manipulate them. Unfortunately, the XSDs for the HL7 messages are less-than-ideal in a number of ways. First, some information relating to the message definition is not always well-represented in the XSDs. And secondly, some information is represented in a "de-normalized" format that hampers one's ability to use and manipulate them (to, for example, generate code).

Although XML is a key technology in HL7, the unfortunate truth is that work on HL7 version 3 started before the earliest XML standards were published; The HL7 version 3 standards made choices that seemed valid at the time, but which have hindered the ability to fully exploit the power of XML.

As a result, the MIF/MIF2 formats tend to be a better source: they contain all of the information necessary to properly represent messages, and they don't suffer from the denormalization present in the XSDs. The truth is, though, that the structure of MIFs/MIF2s are not the easiest structure to work with. First, because it's not a well-documented structure and second, because the format supports a large number of complicated formats for handling references to other MIFs, specialization, and choices. Part of the complication of the MIF format relates to the fact that MIFs are also used as the source for the visual editor in which the message parts are defined.

TEAL, then, uses a very simple XML format that is constructed from some of all of these other sources. It extracts the salient information, and represents that information in the most straight-forward manner possible. These message sets are one of the most useful elements of TEAL.

The TL7 site makes use of message set in a variety of ways. First, we use the message sets to perform message validation. Further, we use the message sets to provide documentation about the various messages (including version comparison).

But most importantly, we use the message sets to help us to marshall and unmarshall HL7 XML messages.

Marshalling and Unmarshalling

The Java world contains a large number of ways to convert XML into Java and vice-versa: JAXB, XML Beans, Apache's Digester, Simple XML, etc. These tools often read in XSDs and produce Java beans that can be programmatically populated.

In our experience, these tools can't mitigate some of the pain that results from HL7's rather complicated XSDs. Recall, above, how we said that:

1. the HL7 XSDs contain "de-normalized" information; and
2. the HL7 XSDs are missing some crucial details about message format.

Because of these two limitations (and because the HL7 structure is a bit more complicated than it probably should be), most tools produce Java classes that are an order of magnitude too complicated, and which exclude important information necessary to properly format the message (such as, for example, date precision: yyyyMMdd versus yyyyMMddhhmmss.SSS).

Also, because the information is denormalized, such tools often generate near-identical Java beans that represent the common attributes of two different messages. The "near-identical" part has unfortunate consequences for reuse and isolating functionality in common code.

Finally, the HL7 standards produced by the Standards Collaborative sometimes contain minor quirks and idiosyncracies that almost look like errors or inconsistencies. Take, for example, the idea of the "assigning Id Organization" associated with "Other Ids" in the client registry messages. In one message (the "Get Demographics Query Response"), this concept is referred to as a "scoping Id organization", but otherwise the notion is identical. This kind of inconsistency has a significant effect on creating common code for message processing.

The TEAL answer to these limitations is based on building a Java-to-XML marshaller that is optimized for the HL7 standards. The TEAL message transformer uses a set of pre-packaged Java beans that represent the various HL7 messages. These beans use the full power of Java static typing to help developers understand how to populate the fields. A developer simply has to populate the Java bean, and let the message transformer do its work.