I am maintaining a legacy mirth system. We get some incoming HL7 messages with a repeating ZP1.36 segment. As far as I can tell, mirth is dividing these repeating segments into an array of repeating segments via a split function.
var repeat36 = msg['ZP1']['ZP1.36'].toString().split("</ZP1.36>"); //I think returns an array of ZP1.36 segments
But in the raw data, I don't see the string ZP1.36...
I'm used to using split functions in VB/Java/C# that divide strings into tokens around a certain character, like this:
var myTokens = "hello^world".toString().Split("^"); //returns a 2 item array {"hello", "world"}
Mirth's split function doesn't seem to be working this way. It seems to be parsing the messages based on the assumed structure of the HL7 message.
Is this what's going on? Am I missing something? What are the rules for the split function in mirth?
Cross-posted on mirth community http://www.mirthcorp.com/community/forums/showthread.php?p=26203#post26203
I know you already found and accepted a sufficient answer to your question (reposted from the Mirth forums), but I thought it might be helpful to give a bit more information in a separate answer.
At its heart, Mirth leverages a couple of pre-existing technologies in order to work with HL7 data.
From the examples that Dans provided you on the Mirth forums:
This snippet is in the standard XML format for HL7 v.2x:
<ZP1.36>
<ZP1.36.1>Hello</ZP1.36.1>
<ZP1.36.2>World</ZP1.36.2>
<ZP1.36>
This JavaScript code is utilizing E4X notation to parse and access HL7 data that has been reinterpreted into E4X XML and XMLList data types:
var zp1361 = msg['ZP1']['ZP1.36']['ZP1.36.1'].toString();
var zp1362 = msg['ZP1']['ZP1.36']['ZP1.36.2'].toString();
msg
is the E4X XML object holding the HL7 datamsg['ZP1']
produces an E4X XMLList object that holds a list of ZP1 segments.