aethelwulffe wrote on Friday, December 10, 2010:
Hello. I am having trouble with location code 03:school. In the 837 it shows up as 3 and not 03. I checked the database and sure enough school location value is “3”. I could not change it to 03, as it converts that to the integer significant digits as “3”. I thought I would find something about this on the forum, but no luck.
Windows, XAMPP, 3.2.0
aethelwulffe wrote on Friday, December 10, 2010:
Found where the data comes from:
<option value="01" >01: Unassigned</option>
<option value="02" >02: Unassigned</option>
<option value="03" selected>03: School</option>
<option value="04" >04: Homeless Shelter</option>
Hard-coded into the facility_admin page.
pos_code is a tinyint(4).
How shall I go about fixing this?
sunsetsystems wrote on Saturday, December 11, 2010:
I’m not sure offhand which segment you’re talking about, but the place to fix it would be library/gen_x12_837.inc.php. The code there is pretty easy to understand.
To turn an integer into a 2-character string try something like “sprintf(’%02d’, $integer)”.
aethelwulffe wrote on Saturday, December 11, 2010:
Thanks Rod.
I’ll look at the gen code you pointed out. I have to admit that just because the EBR file SAYS the code submitted was “3” and just because the value of pos_code is int(3), doesn’t mean that the file generator isn’t making correct input and it isn’t some squirrely insurance company fodelerol saying:
Value of sub-element CLM05-01 is incorrect. Expected value is from external code list - Place of Service (237). Segment CLM is defined in the guideline at position 130. Invalid data: 3|2300|CLM|05||||
….however, I found this:
~CLM*18-4619*180.00***3::1*Y*A*Y*Y*C~DTP
…showing it really is output as a just a 3 and not 03.
I shall take a swing at that include, dude! Thank you VERY much for pointing me there. I see that school is in company with services for homeless and indians in the <10 service code locations, so it does not surprise me that this is a rarely spotted bug.
aethelwulffe wrote on Saturday, December 11, 2010:
I found what I think we need in Claim.class.php This reads the value that is used in the generator:
function facilityPOS() {
return x12clean(trim($this->facility['pos_code']));
}
It is actually written to the 837 here in gen_x12_837,inc.php:
++$edicount;
$out .= "CLM" . // Loop 2300 Claim
"*$pid-$encounter" .
"*" . sprintf("%.2f",$clm_total_charges) . // Zirmed computes and replaces this
"*" .
"*" .
"*" . $claim->facilityPOS() . "::" . $claim->frequencyTypeCode() .///Should we mod here or in the class???
//
"*Y" .
"*A" .
"*" . ($claim->billingFacilityAssignment() ? 'Y' : 'N') .
"*Y" .
"*C" .
"~\n";
May I request some assistance with code here? I just don’t know the language at all. I need a case or if statement that adds a zero to the beginning of the string only IF the value is <10. Perhaps a better way would be to convert it to a string, get the length of the string, then assign the zero AND send a note to the log. Off the top of my head, I can’t recall if there are ever anything but numbers in the POS codes (01-99 I think), so perhaps a php version of " if (pos_code<10){facilitypos=“0”+real_to_string(poscode);}
sunsetsystems wrote on Saturday, December 11, 2010:
OK, open wide… 
Change this:
"*" . $claim->facilityPOS() . "::" . $claim->frequencyTypeCode() .
to:
"*" . sprintf('%02d', $claim->facilityPOS()) . "::" . $claim->frequencyTypeCode() .
aethelwulffe wrote on Saturday, December 11, 2010:
CLM*18-4619*180.00***03::1*Y*A*Y*Y*C~DTP*
SUCCESS!!! It now writes 03
I guess that ‘%02d’ writes anything to 2 digits, and ‘%03d’ would correct it to three. I assume that this little gem will not alter an existing integer of double digits ('cause your a smart guy and you tossed it to me), so I won’t bother to test it with code 11. …though my pessimistic streak tells me “too easy of a fix!”. Should we change the HCFA as well? Should we pop in a bug report too?
sunsetsystems wrote on Saturday, December 11, 2010:
You’re right that it should be fixed for the HCFA also, so better to make the change in Claim.class.php. I’ll take care of that along with another fix I have pending for that module.
aethelwulffe wrote on Saturday, December 11, 2010:
Keep us posted pls. I would be interested in knowing the change specifics, 'cause I have already altered my generator code, and altering the class with a patch to the class on top of it might produce unexpected behavior…for me personally that is. 8*)
aethelwulffe wrote on Tuesday, December 21, 2010:
More issues with the x12 generator… I would really like to get working on a few EMR development projects, like forms and such, or maybe learning 4.0 a bit and PHP so I can work on stuff, but I have not gotten basic billing nailed down yet. I am having header content problems.
PROBLEM(s): Duns and Bradstreet identifier is showing up as ZZ and not 01. Possibility of wrong number of spaces in the GS02 entry identifiers (might have attended to that by taking out spaces at the end of the entries in the EMR, possibly I needed more spaces that are not there.
Mind you, after coming to the above solution to the billing location issue, I have done the following with my version of 3.2.0:
1. Restored the mysteriously missing users_facility table
2. (Possibly) Enabled the default facility for providers in globals (might have only done that in a testing install).
I have these settings:
I have tracked down and copied the following bits (less the variable declarations and such) of files I think are relevant to my issue:
//Output 837 file header:
//ISA*00* *00* *ZZ*AV09311993 *ZZ*030240928 *101221*1714*U*00401*021549495*0*P*:~GS*HC*AV09311993 *030240928 //*20101221*1714*1*X*004010X098A1~ST*837
//****NOTE: Duns&Bradstreet identifier ISA07 is showing up as ZZ. GS02 may have wrong number of spaces etc... as well.
//source of x12payer_id
<tr>
<td COLSPAN="1" ALIGN="LEFT" VALIGN="MIDDLE" >Receiver ID Qualifier (ISA07)</td>
<td COLSPAN="2" ALIGN="LEFT" VALIGN="MIDDLE" ><select name="x12_isa07">
<option label="Duns (Dun & Bradstreet)" value="01" selected="selected">Duns (Dun & Bradstreet)</option>
<option label="Duns Plus Suffix" value="14">Duns Plus Suffix</option>
<option label="Health Industry Number (HIN)" value="20">Health Industry Number (HIN)</option>
<option label="Carrier ID from HCFA" value="27">Carrier ID from HCFA</option>
<option label="Fiscal Intermediary ID from HCFA" value="28">Fiscal Intermediary ID from HCFA</option>
<option label="Medicare ID from HCFA" value="29">Medicare ID from HCFA</option>
<option label="U.S. Federal Tax ID Number" value="30">U.S. Federal Tax ID Number</option>
<option label="NAIC Company Code" value="33">NAIC Company Code</option>
<option label="Mutually Defined" value="ZZ">Mutually Defined</option>
</select>
</td>
</tr>
<tr>
//From gen_x12_837.inc.php
$out .= "ISA" .
"*00" .
"* " .
"*00" .
"* " .
"*" . $claim->x12gsisa05() .
"*" . $claim->x12gssenderid() .
"*" . $claim->x12gsisa07() .
"*" . $claim->x12gsreceiverid() .
"*030911" .
"*1630" .
"*U" .
"*00401" .
"*000000001" .
"*" . $claim->x12gsisa14() .
"*" . $claim->x12gsisa15() .
"*:" .
"~\n";
///from X12Partner.class.php
function X12Partner ($id = "", $prefix = "") {
parent::ORDataObject();
$this->id = $id;
$this->_table = "x12_partners";
$this->processing_format_array = $this->_load_enum("processing_format",false);
$this->processing_format = $this->processing_format_array[0];
//most recent x12 version mandated by HIPAA and CMS
$this->x12_version = "004010X098A1";
$this->x12_isa05 = "ZZ";
$this->x12_isa07 = "ZZ";
$this->x12_isa14 = "0";
if ($id != "") {
$this->populate();
}
}
function get_idqual_array() {
return array(
'01' => 'Duns (Dun & Bradstreet)',
'14' => 'Duns Plus Suffix',
'20' => 'Health Industry Number (HIN)',
'27' => 'Carrier ID from HCFA',
'28' => 'Fiscal Intermediary ID from HCFA',
'29' => 'Medicare ID from HCFA',
'30' => 'U.S. Federal Tax ID Number',
'33' => 'NAIC Company Code',
'ZZ' => 'Mutually Defined',
);
}
I wish I knew enough to make a little output debugger that could interface with the database to do corrections! Anywho, I KNOW from the above code that function X12Partner loads the ZZ value, and then later the id qualifier array value chosen is supposed to replace the ZZ with “01”. I bet I could make the “default” ZZ into an “01” and have this bit solved with a kludge, but I am still just dealing with Availity, and I don’t know if I am going to need to change from an 01 to something else for submitting to payers not linked with Availity.
-Puhleez….I swear up and down that I will be a good little contributing and donating Indian to the cause here. At the moment, I need another unpaid/unearned favor, cause my Wife will absolutely KILL me if this all goes to shit on us. I am not likely to survive the process……Any advice, code, methods, or bus tickets out of town will be appreciated.
-I need a drink.
-Art
aethelwulffe wrote on Wednesday, December 22, 2010:
OK, here is all is confirmed to be happening:
ISA07 is not including the options to change zz. ISA05 may not be affected either, though I have it set to zz anyway.
ISA14 needs the flag for "Yes, and outputs a “0”. I am guessing this might be wrong.
GS02 is putting out the value of ISA06!!!!! At least it is adding spaces for 15 digits!
I need another drink.
sunsetsystems wrote on Wednesday, December 22, 2010:
Dunno… you might try replacing ZZ in some places with 01 and determine which one is the culprit. That might help to identify the cause of the problem.
aethelwulffe wrote on Wednesday, December 22, 2010:
Thanks Rod, I’ll try that right after I fire my current set of plans:
I have re-booted the server (just in case). I am now going to check the output again. Then I will examine the files involved in generating the x-12.
Can anyone verify the list I have of files that are involved in generating the x-12, verify that restoring the users_facility table would not have affected this, and perhaps point me to where/what actual tables and fields might store the data for the variables that load the data (aside from “x12_partners”)?
Gonna be a loooong night, and I spent most of last night watching the lunar eclipse. stupid.
aethelwulffe wrote on Wednesday, December 22, 2010:
OKOKOKOK…call off the hounds.
IGNORE THIS THREAD:
Aparently, I have two different versions of 3.2.0. Might be good to have a version config file (dunno, maybe you do) to notify you what patch you have. I have a completely different version of the x12 gen file on my test-bed as the running version. The test bed sets some hard “ZZ” values where the active instance has code that calls the variables holding the data from the x12 partners table. Unfortunatly, I patched the x12gen file from a modded file off my testbed to fix the location code. It is possible that it did work a bit after that until the x12 partner data got changed…or maybe not.
I think I have a working version now. I am flushing my old test bed install in favor of the many-times over upgraded active version, and I am not patching S#!T until 4.0 comes out.
Sorry to bug you guys. I owe you a case just for plugging your e-mail with this crap. Art runs off to fetch a dustpan to clean up all the bullets he’s been sweating……
sunsetsystems wrote on Wednesday, December 22, 2010:
I’m glad you figured it out. One beer will sufficient, thanks. 