X12 errors

jwallace00 wrote on Thursday, December 31, 2009:

Hi guys,

  We’re trying to switch over to use OpenEMR’s billing through MD online.   We tested submission of our first batch of claims and got several errors returned by them.  It appears that we have several required pieces of information missing from our submission but I don’t know what information is needed to satisfy the error messages.   Does anybody have any experience with the following error messages?

"

env Element GS02 is empty.  It is a mandatory element for this segment.

env Element GS03 is empty.  It is a mandatory element for this segment.

trans Element REF02 is empty.  It is a mandatory element for this segment.

1000A Element PER02 is empty.  It is a mandatory element for this segment.

1000B Element NM103 is empty.  It is a mandatory element for this segment.

1000B Element NM109 is empty.  It is a mandatory element for this segment.

2010BB Element NM109 is empty.  It is a mandatory element for this segment.

"

Thanks in advance for any help provided.

ideaman911 wrote on Thursday, December 31, 2009:

Hi;

I cannot tell you exactly what is NOT happening which should, because the cause might be that you don’t have that info in your database(s) yet.  But it is pretty simple to diagnose why the error by looking in …/library/gen-x12-837.inc.php (substitute underscores, which cannot display here, for the dashes shown here).  Each of the codes will be found, and you must assure the needed info in your database(s) is available in order for it to print anything in that field for the X12. 

Note also that some (we have found the Aetna and UHC portals specifically) have errors which show for nobody else.  In those cases, you might wish to have “contingent” code which will substitute a value which will be accepted when that X12 partner code (usually the payer code) is involved.  Making those changes can be done by you, or by most of the commercial providers like me for a fee.  Remember that if you make such changes, you must assure they are made in every subsequent upgrade, patch, etc, because those will overwrite.  As an example, were I to do that, I would make a copy of the file after revisions, and call it gen-x12-837-Joe310P5.inc.php to reflect my code in the latest ver 3.1.0 patch 5 upgraded.  Then, even if I inadvertently overwrite with a patch, which only overwrites the original file, I have the fixed one copy as a model to change section by section as needed.  You might wish to first make a copy of the original called gen-x12-837-orig.inc.php so you can fix if you make a syntax error (bracket count is typical).  Hope that helps.

Joe Holzer    Idea Man    315-622-9241     im@holzerent.com
http://www.holzerent.com

jwallace00 wrote on Monday, January 11, 2010:

Thanks for the tip, Joe. 

We’re still getting several errors that are mysterious to me.  

MD on-line sends us an error report which I’m using to identify the loop/code information in question.     For example,  in one of our test claims we have the following response from md on-line:  “Loop: 2000B  Error:  When HL04 from loop 2000B = 0 then SBR02 must equal 18” 

In loop 2000B,   HL04 is always hardcoded to a value of zero.    here’s the snippet from gen_x12_837.inc.php:

"
$PatientHL = 0;

  ++$edicount;
  $out .= “HL” .        // Loop 2000B Subscriber HL Loop
    “*$HLcount” .
    “*$HLBillingPayToProvider” .
    “*22” .
    “*$PatientHL” .
    “~\n”;

  $HLSubscriber = $HLcount++;

  if (!$claim->payerSequence()) {
    $log .= “*** Error: Insurance information is missing!\n”;
  }
  ++$edicount;
  $out .= “SBR” .       // Subscriber Information
    “*” . $claim->payerSequence() .
    “*” . $claim->insuredRelationship() .
    “*” . $claim->groupNumber() .
    “*” . $claim->groupName() .
    “*” . $claim->insuredTypeCode() . // applies for secondary medicare
    “*” .
    “*” .
    “*” .
    “*” . $claim->claimType() . // Zirmed replaces this
    “~\n”;
"

PatientHL is the value being assigned to HL04 in that loop and it is always set to zero.    This is confusing since the value for SBR02 fo the same loop gets its value dynamically from the Claim object dependnig on the value in the database.   

In the example we’re trying to submit,  it’s a claim for the child of the subscriber.    The subscriber information is what’s showing up in the x12 submission.   I *think* that’s normal, however HL04 appears to be hard coded to always represent a “self” subscriber relationship.   

This is the line in question we’re submitting in x12 format:

HL*2*1*22*0~SBR*P*19*SBS235******16~

Field HL04 = 0  but field SBR04 = 19,  which is the relationship for a child.    The bottom line is, the SBR section of the loop is being coded correctly while the HL section is not.    

I’m new to x12 and OpenEMR’s claims process so it’s entirely likely we’ve not set something up right on our end,  but that hard coded PatientHL value didn’t look right at first glance.    Can anybody shed some light on this for us?   

Thanks

ideaman911 wrote on Monday, January 11, 2010:

I am having a terrible problem with slow response from Sourceforge.  Send me an email address and I’ll send you a revised X12 generator - you can see how I dealt with exactly the same problem with UHC, so some of my others might be same for you as well.  There are a few where they made NO sense, but turned out to be another problem than the indicated code, so see my notes for all.

Joe Holzer    Idea Man    315-622-9241     im@holzerent.com
http://www.holzerent.com  or  http://www.EMRofCNY.com