>>>>>How flexible do you want to make this?
>>>>>
>>>>>Will you be parsing all the HIPAA transactions?
>>>>
>>>>I will probably add a column for the 271, 270, etc to make it more flexible for the future, but for the moment I'm just looking to work through the 271.
>>>
>>>We normalized our tables because we parse most of the transactions.
>>>
>>>You might consider adding a Pre-assignment hook column (memo). That allows a totally table-driven solution.
>>
>>Could you explain that a bit more? How would that work, and why a memo field?
>
>We used a memo so we could enter an arbitrary number of lines of code. It was written in VFP 6.0, so we used macro to call code line by line. We used it to append a blank record in the database when we hit a certain segment, commit a transaction, etc
>
>Some pseudocode:
>
>Do while not EOF
>Parse segment from file
>Parse element from segment
>Convert element to correct type
>Execute pre-assignment hook code (if any)
>Save element data to view or form property
>
>
>There are several potential gotchas with EDI. If you accept transactions from multiple sources be aware that not all sources use *:~ as seperators. See doc on ISA segment
>
>EDI doesn't really have lines. Most of the files we process are one long string.
>
>I apologize if you know this stuff. I've seen it bite others just getting started in this arena.
>
>HTH
>
>Bruce

Yeah, some of this I'm already on top of. I grab the delimiter from the message and put each segment on a new line before parsing. Don't assume I know anything though; it's nice to have confirmation that I'm doing it like others.

Ok, I think I understand. I'm going to have a table that contains all the incoming elements (fields). I'm building another table that contains basically all the possible elements and their related values, if applicable. I think where you are going is to have code in a memo field in this driver table that says what should be done with that element/value if it is part of the incoming message. I can loop through the message table and lookup in the driver table and find what to do. Then do that and put the result somewhere else (form properties, objects, etc). Does that sound right?