A couple of life-times ago I had the pleasure of dealing with an HL7 feed from an Emergency Room. I finally ended up in sheer desparation building individual routines to cope with the five or six (seventeen at last count) different record-types I was getting in my input. I ended up with a switch/case construct reading the file and calling the appropriate routine for each record type.

After the fifth "Oh, didn't we mention we are getting XXX types as well" from the medical 'Analysts', I started work on an OO framework to handle a generalized HL7 record-type, which I still have somewhere in the Archive. (Methods to extract each of the subfields correctly, and build a common Parse Structure for HL7, v2.x. It was most ugly, variable numbers of fields with variable lengths, with variable field-markers (depending on where in the structure you are, the eof mark changes) -- oh my. I finally figured out that an HL7 data type is really a four dimensional structure -- an array of 3-d arrays. It helped to visualize what I was trying to do, but it was a main-pain to process. Can you say sparse variable-length arrays? Can you say storage hog??)

Your approach is pretty much going the right way (in so far as there is a 'right way' w.r.t. HL7). You might ask the folks who are supplying your data if they plan to go to Version 3 any time soon. V3 was supposed to define the XML support constructs for all the HL7 record types and that will make the parsing problem much easier/more complicated (Take your pick).

Best of luck