Compose X12 270 Eligibility Benefit Inquiry using OopFactory X12 Parser

Question

I'm starting a .NET project for which I'll need to submit HIPAA eligibility inquiries using the x12 270 format.

In my online searches, I've come across X12 Parser. However as Murphy would have it, the class I think I'll be needing, EligibilityBenefitInquiry, is stubbed with a //TO-DO.

Has anyone achieved this task using the X12 Parser or perhaps a different tool?

Stumer

Do you need to generate the 270? Or parse it? EDI is just text. If the document is inbound, once you inspect the ISA segment and get the delimiters, you should be able to parse it on your own. Commercial EDI translators exist for a reason. – Burchett

I need to generate the 270 and then parse the 271 I get back. I'm having difficulty even finding an online example of what a 270 looks like. – Stumer

A quick Google search took me to cms.gov/Research-Statistics-Data-and-Systems/… Look at Appendix A near the bottom. There is a sample 270 document. ISA/GS/ST are envelopes with SE/GE/IEA being the close of the envelope. The specification is there. You didn't specify what version, the link I provided is 5010. – Burchett

You should be able to acquire an implementation guide from whomever you are trading with. Different states have different requirements. Download EDI Notepad from Liaison to help you look at the data. – Burchett

It's HIPAA so confusion, obfuscation, complexity usually rules the day. Sometimes it takes sending one bad test to them for them to say "no no no..this is what we want". Sad it has to be that way, but that's some of the things I've seen. – Burchett

Answer 1

Since you want to generate the 270, you don't want to use a "parser". The Parser tool might work for the inbound 271 response. To write your own translator (generator), you should get an implementation guide from your trading partner. An example of the 270 can be found here: CMS 270. That should give you a good idea of how to create the segments and elements needed to transmit the document. EDI is text based on a standard. The implementation guide should give you a fairly good representation of the partner's usage of that standard.

Obviously, commercial software would allow you to model your source data (database, XML, etc) and your target and allow you to drag / drop easier than writing your own mapping for some of these complex HIPAA documents. The open source parsers generally only "translate" to a generic XML file giving you less control over the workflow, and generally introducing another step (usually middleware or XLST).

Burchett

I suspect my trading partner isn't interpreting the EDI himself; I think he's passing it on to yet another partner, but I'll verify. – Stumer