I am working on finishing up some validation methods as a part of discussion http://x12parser.codeplex.com/discussions/390657.
I will probably update soon with a more concise specification for the 5010 837D and 837P. THe 837I is checked in, but has not yet been released.
What has been released is focused more on the ability to parse. Occassionally creators of EDI choose to add things that aren't part of the spec. I have also noticed in creating unit tests, that sometimes the sample EDI that is provided doesn't
always conform to the specification document in which it is placed. So to accommodate this some of the specs add more than what is in any official specification.
The disclaimer on the website is more to address that outside of the HIPAA set of transactions are tightly controlled by WPC, most of the other transactions were created by randomly sampling 2 to 5 implementation guides across the internet. This doesn't
always guarantee completeness, but they were tested against what examples I were able to find of each transaction set.
The included specifications are included as is with no guarantee of correctness. You should know what you are expecting from your trading partners and review yourself to determine if you need to override with your own by seeing this http://x12parser.codeplex.com/wikipage?title=Injecting%20your%20own%20X12%20Specification.
You might choose to use a tighter specification for your validation and acknowledgment.
The other interesting thing about the 837, is that it is difficult to determine if you are working with the D, P or I version until you have actually parsed the transaction beyond just the ST segment. Unfortunately they are inconsistent in the identification
of Loops based on an NM1's entity identifier code.
For instance, the 2310B loop is a rendering provider in the 837P, but in a 837I the same loop ID is an Operating Physician. For this reason the default spec uses the LoopId's from the 837P spec first, and then attempts to add the additional loops so
the document is also parsable for the 837I and the 837P. When you know ahead that you are parsing an 837I or 837P, you just need to inject a different SpecificationFinder if you want you xml to 100% correct to each specification.
I am going to address this issue better in the next release, hopefully no more than 2 weeks from today.
I hope you did also see that there is an Unbundling feature that will handling splitting claims that you mentioned you will need. See here: http://x12parser.codeplex.com/wikipage?title=Unbundling%20an%20X12%20file%20by%20Loop%20ID