Yeah, Steve, this has been a bit of learning curve for me. I think that the ones I'm going to be pulling in for the billing side will always be the same and will come in groups of 7 lines per message. I was going to cursors with a data dictionary to add flexibility for the future more than anything. I could slam the stuff into the tables, but would like to try and do it the right(?) way. This isn't the big "do all hl7 parser/populator" engine, but rather one small piece of taking the messages for charges as they come in a populating our process tables, which are then processed/populated into the base tables by further procedures. I think I'm almost there for this part, but maybe I'll find out that I'm way off base and will have to explain to my boss that I'm not quite as smart as we both thought I was... <g>

>Hello Jay,
>
>Can't an HL7 file contain several events, or messages? If so, your code will only put one of them (the last one, I suppose) into cursors. And I'm not sure what you gain by having them in cursors in the first place, because those cursors still need to be mapped to something meaningful.
>
>Also, does an HL7 "event" span multiple segments? I'd love for one of you who's dealt with HL7 to clarify this point. Because if it does, throwing the segments out to 7 cursors gains you even less....you've still got to fit them together and take each event as a whole.
>
>
>>I usually don't ask for code reviews, but in this case, with so many people giving a hand, I would like to know if there are any glaring issues with the code below. It seems to take the HL7 message and parse it correctly and also populates the 7 cursors as well. It's not the finished version, but before I went to far along...
>>