stephen-smith wrote on Thursday, June 17, 2010:
New bug: https://sourceforge.net/tracker/?func=detail&aid=3017701&group_id=60081&atid=493001
bradymiller wrote on Thursday, June 17, 2010:
Stephen,
Hold on this commit until get attention of an X12 expert (ie. Rod).
-brady
sunsetsystems wrote on Friday, June 18, 2010:
Whoops, I just posted and deleted an incorrect analysis. Sorry about that.
My spec says 1000A NM109 is “Electronic Transmitter Identification Number (ETIN) Established by trading partner agreement.” It’s not at all clear to me that this should be the same as $claim->x12gssenderid() - that is used for ISA06 which is described as “Identification code published by the sender for other parties to use as the receiver ID to route data to them”.
We may need a new X12 Partner field, but I don’t recall this coming up before. Who is complaining, and what do they say they want there?
stephen-smith wrote on Friday, June 18, 2010:
Currently, the organization I work for uses a piece of software called PES, which was provided by Arkansas Medicaid, to submit X12 directly to Arkansas Medicaid. (There’s no clearing-house involved, Arkansas Medicaid is both the Insurance Company and the X12 Partner).
The documentation on the Wiki says that OpenEMR and PES use the X12 Submitter ID. When we actually ran a batch and looked at the code, OpenEMR was apparently pulling a Federal Tax Id instead of our X12 Submitter ID assigned by Arkansas Medicaid. My patch reuses the X12 Submitter ID configured on the X12 Partner page.
However, I know that the wiki documentation isn’t based on a read-through/summary of the standard but rather a one-man (ytiddo), one-implementation (PES) reverse-engineering of the X12 files being submitted by PES to Arkansas Medicaid. Of course, PES is our gold standard here, we know that files formatted with PES will be accepted by Arkansas Medicaid, and we are hesitant to experiment with the formatting at all.
sunsetsystems wrote on Friday, June 18, 2010:
I think the safest approach is to have separate identifiers for all of the different places in the spec that describe them differently. Here is what I suggest:
Currently the X12 Partner form has a field described as “ID Number (ETIN)”. This is used for NM109 in loop 1000B. Rename this to “Receiver ID (1000B)”. The add a new field just above it to the form (and to the x12_partners table) called “Submitter ID (1000A)”. Add a corresponding function submitterETIN() to Claim.class.php (use clearingHouseETIN() as a model).
Doesn’t have to be exactly like that, but you get the idea.
stephen-smith wrote on Friday, June 18, 2010:
I can get behind that plan.
tmccormi wrote on Friday, June 18, 2010:
I’m good with that. The ECLAIMS, INC clearinghouse requires an REF02 block in 2010AA in addition to the REF*EI
REF*G5*0001~
Can we this kind of stuff easily as well?
-Tony
tmccormi wrote on Friday, June 18, 2010:
PS: they call it the Provider Site Number….
sunsetsystems wrote on Friday, June 18, 2010:
Tony, G5 is already available as a provider number type. Just select that in Practice -> Insurance Numbers and it should generate that segment for you.
tmccormi wrote on Saturday, June 19, 2010:
So, cool.
If you leave the INSCO at Default then it will apply to all of them that are not otherwise overridden, I presume.
-Tony
sunsetsystems wrote on Saturday, June 19, 2010:
Yes, the “Default” insurance info would apply where there is not a form created for payer-specific settings.
tmccormi wrote on Monday, June 21, 2010:
Rod,
I use the method about and eclaims rejected it as follows:
> EClaims says that the G5 only needs to be in the 2010AA Loop and it needs to be removed from the 2310B Loop.
Ideas?
-Tony
sunsetsystems wrote on Monday, June 21, 2010:
Tony, if I ordered a steak dinner and didn’t like the carrots it came with, I wouldn’t send the whole dinner back.
But if you don’t want to fight that battle, you can edit gen_x12_837.inc.php and take out that segment.
tmccormi wrote on Monday, June 21, 2010:
Well, I certainly agree, I was just hoping there was some other option besides code changes …. sigh.
-Tony