An EDI 837I 5010 parser in C# and T-SQL

Implement the parsing, relational storage and serializing of Healthcare EDI files using straightforward T-SQL and C# patterns. The "connecting lines" between source and destination formats using "visual mappers" is no way to live. Go the code route I say.

The benefits of parsing the entire transaction (all loops and segments):

Comment 1: I've heard the comment that writing a parser per specification results in a very large class and it adds unnecessary complexity because the CURRENT requirements are only concerned with a subset of the entire data set.

Response 1: What is more complex? - writing a large parser per spec one time or writing a smaller parser and then over time having to "add" additional logic or refactor every time a new requirement arrives and then having to regression test and re-deploy the whole thing all over again?

Response 2: I've seen whole companies grow out of the data that is parsed from lesser known loops and segments and making available those data in the form of "additional" information and analytics to their customers.

Response 3: Take for instance the BIN segment in an 837. It and its contents are rarely parsed in their entirety. Idea = parse and data mine the embedded HL7 2.x ORU messages (or HL7 3.x CDA observation entries) within your BIN segments - what could that be worth to the consumers of your data, to make available those unexplored data streams? Don't know, but a good question to think about?