Comparing with Chameleon message matching

One problem an HL7 parser needs to solve is how to identify the message type being parsed. This is what an example HL7 message looks like:

MSH|^~\&|EPIC|EPICADT|iFW|SMSADT|199912271408|CHARRIS|ADT^A04|1817457|D|2.5|
PID||0493575^^^2^ID 1|454721||DOE^JOHN^^^^|DOE^JOHN^^^^|19480203|M||B|254 MYSTREET AVE^^MYTOWN^OH^44123^USA||(216)123-4567|||M|NON|400003403~1129086|
NK1||ROE^MARIE^^^^|SPO||(216)123-4567||EC|||||||||||||||||||||||||||
PV1||O|168 ~219~C~PMA^^^^^^^^^||||277^ALLEN MYLASTNAME^BONNIE^^^^|||||||||| ||2688684|||||||||||||||||||||||||199912271408||||||002376853

See the “ADT^A04” in field 9 of the first MSH line of the message? This indicates the ‘type’ of the message. In this case an this is a patient registration message in the Admit Discharge Transfer category of messages.

So every HL7 parser needs a way to configure it so that rules can defined as to what message grammar should be used to parse the message. We call that a message matching system.

The HL7 parser in IguanaX has a greatly simplified message matching system compared to Chameleon.

In Chameleon the matching algorithm for deciding the type of an HL7 message has more complexity than how we have done it in IguanaX. This how the matching works in Chameleon:

See how you can specific matching rules that have three parts:

The segment - i.e. MSH or PID etc.
The field to match in the segment
A regular expression to match against the field value

By comparison the matching options in the IguanaX built in message matching system is a lot simpler. You only have the ability to specify a single wild card matching rule like “ADT^A04” or “ADT*” etc. to match against the MSH.9 field:

How does that work if a message uses a non standard sub field delimiter instead of a “^” character? We solve that problem by pre-processing each HL7 message to ‘normalize’ the message to use the default standard HL7 characters.

So the new system of matching is a lot simpler than Chameleon but also a lot less flexible.

What do you do if you want more flexibility?

Well we did think about that.

The hl7.parse{} command in IguanaX has an a new optional “name” parameter which can be used by the caller to override the default matching rules defined in the vmd grammar file. So this means it’s possible to have more power and flexibility with IguanaX than was possible with Iguana 6. As a user you can call a piece of custom parsing code to identify the what message grammar should be used to parse a message and pass that name into the hl7 parse call. Here’s a small code example:

function main(Data)
   local Name = IdentifyMessage(Data);
   local Msg = hl7.parse{data=Data, vmd='adt.vmd', name=Name}
   ProcessMsg(Msg); 
end

Hopefully this solution makes sense for our user base. It’s a design choice we are open to discussing as we get more real world feedback from users

What if you want to match a few different ADT events to one message?

That’s quite easy to do with IguanaX. There is nothing preventing you from making a few different matching rules which match to one message, like:

Richard and I discuss this point in this video: