I need to create a DB to store HIPAA claim transactions.
This question will focus on 837Professional transactions.
I would like some feedback/research on table layout.
The sooner the better.

Basically a hipaa electronic transaction looks like this.
There are 'Loops' which have 'Segments' which have 'Elements' which have 'Codes'
Only the 'Elements' contain actual data. 'Codes' are list of possible
values. Not all elements have codes.

Loop A
	Segment A
		Element A
			Possible Code values
		Element B
		Element C
	Segment B
		Element A
			Code Values
		Element B
Loop B
.
.
.		

My question involves the best way to store this data.
Each claim will have an integer 'ClaimNumber' identifying it.
I would like to retreive the entire claim with a ClaimNumber from the DB.

There are 3 possibilities which we have discussed so far.
1. Store each element of data in 1 table with some other information
to describe the order the elements were received in.
2. Store each Segment(collection of elements) in 1 of 70 unique
segment tables with some other information to describe the order the
segments were received in.
3. Store each Element in 1 of 130 unique element tables with some
information to describe the order the elements were received in.

I am leaning toward #3.
I am also considering storing only unique values in the element tables
to cut down on size.

The data going in to the DB can be slow, as the job will run batch at night.
The data comming from the DB needs to be as fast as possible.
Once the data is in the DB it will not be altered.

Some research about the format of an 837P transaction will be necessary.

If it matters i will be using sql server 2000/VB.net
Please discuss index's or other information pertaining to space/time
effeciency that will be useful.

Thank You