This project has moved. For the latest updates, please go here.

Validation of X12

Aug 27, 2012 at 1:06 AM

We currently use EDIFECs to validate the X12 files and then, if valid, split claims into their individual XML files.  This is a pretty expensive solution so I was considering switching to this tool to save a few dollars.  It appears that this code base would easily fit those needs.  I was worried about the statement on the front page saying "The built-in specs and transformations are not meant to be complete, only provide the most common data elements".

Does this just mean that I may need to modify the  837 specification files?  Are there any other gotchas out there that I should be aware of?

Thanks for your help. 

Aug 27, 2012 at 3:46 AM

I am working on finishing up some validation methods as a part of discussion

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  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: