X12 standard questions

tmccormi wrote on Monday, March 23, 2015:

The gen_x12 program is wrapping each claim in ST/SE pairs. According to the X12 specs (and a new clearing house I’m working with) there should only be ONE ST and SE that wraps the whole.

This is backed up by every EDI guide and spec I have found online so far.

Oddly no one has ever complained / rejected claims on that, and in fact they say that their two other OpenEMR users are following the spec.

Does anyone know why the gen_x12 was implemented that way.

–Tony

belinda-ramirez wrote on Monday, March 23, 2015:

Tony you are correct on the ST and SE tags.
B.Ramirez

fsgl wrote on Monday, March 23, 2015:

Never got an error message from Office Ally to that effect.

Availity users have written about the Sender Code in Florida & ETIN in Florida/Illinois. Nothing else.

For the user’s part, if remittances arrive in a timely fashion, we don’t lose sleep over the 837P format.

The proof is in the eating.

sunsetsystems wrote on Monday, March 23, 2015:

My guess is it was done this way because FreeB (the earlier billing code) did that and nobody ever complained.

Anyway, gen_x12_837.inc.php generates one claim per call with a full transaction set per claim. If we want only one ST/SE pair for multiple claims, the place to fix that is in the append_claim() function in billing_process.php.

Rod
http://www.sunsetsystems.com/

tmccormi wrote on Monday, March 23, 2015:

OK, good. I’d like to fix that, Do you think I should make it an option? I’d hate to break someones billing process that’s working.

–Tony

sunsetsystems wrote on Monday, March 23, 2015:

No, sounds like it’s really the standard, so just ask volunteers to test it.

Rod
http://www.sunsetsystems.com/

aethelwulffe wrote on Saturday, February 13, 2016:

Got referred to this thread.
In using the standard and OpenEMR output as example, I must have blushed over the “Segment Repeat 1” bit, thinking “Oh that must be per claim”…
…so, I put about 250 hours into a program that mostly depends on that structure.
Rewrite time!