The HL7 parser in Iguana X 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 Iguana X. 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 Iguana X’s 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 Iguana X 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 Iguana X 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