I am sure there is a much more elegant solution than;
// “*” . $claim->patientMiddleName() .
Likely some use of an empty variable if and then statement, but I don’t think I will learn enough PHP by the January 1 onset of 5010 billing to get that correct. In the meantime, this seems to work unless you are trying to put in a middle name. The government rules on this as usual appear ambiguous, as they require Jan 1 compliance, but delay enforcement until March 1. I am not really sure what they mean by that, but not getting claims paid from january to march would not be a good thing.
Thanks for the middle name fix there.
If I can get a documentation check on the 835 stuff so that I can proceed, I want to finish converting all the 837 NM segments and elements into a function with db field arguments instead of the repeating code. Things like the middle name standard should be worked out instead of bypassed/ignored of course, 'cause you never know when there is some shitty little insco that may want the middle name….but I’m gonna use your fix for now, because we almost never use middle names.
I am pretty sure we are only using 5 digit zips….but we either need to put the zip fields as two separate boxes, or put in code to strip any non-numeric characters. Prolly the latter.
However, I don’t see anything in the spec that indicates a trailing empty field is an error. Note that non-trailing empty fields are accepted and necessary.
Sorry I havn’t been around to help field some of these questions, I went to Big Bear for a quick break before the Jan 1 5010 changeover. I downloaded your new patch and sent a test into PalmettoGBA. They, once again kicked it because of the NPI number being present on the performing provider line. If I take it off then the billing is accepted. Got any new ideas or insite on this issue? I don’t have the spec and have been unable to find out why they are doing this. I tried to call but anyone I get have no clue what I am even talking about.
On the trailing field stuff. I have found that any empty value will cause a trailing field error. Some places in the code asume that the data field being written is not null so the field delim (*) is output and then the NULL value causing an error. NULL fields can be a larger problem when several delims preceed the one being output such as:
“*” . $claim->insuredTypeCode() .
“*” .
“*” .
“*” .
“*” . $claim->claimType() .
If $claim->claimType() is NULL then everything under $claim->insuredTypeCode() must not be output else an error will occure.
I am also working on the ERN stuff and will be online and working hard.
Don’t count on there being a grace period until march unless you have filled out and submitted all the required forms explaining why you are unable to comply. This is not an automatic grace period, you must beg for forgiveness and file a plan on how you are going to be able to comply. Oh, buy the way this should have been done by 12/1/2011 and defiantly must be in place by 1/1/2012.
Remember, they would prefer that you fail on these requirements thus giving them another reason to deny your claims.
I have been through this before, it took 6 months before I could bill again.
I am glad to have provided some help, instead of just looking for help. It looks like Rod wrote in the elegant solution I asked about. I believe the 9 digit zip code requirement is just for billing/provider addresses, not for patient addresses, so I just entered it under the facility address as 9 digits. I had already made a new test file with that and my rudimentary fix above and resent it to Officeally for testing. If and when I hear back what works, I will post back.
I have no clue about PalmettoGBA and NPI. I suggest a formal written request that they explain the reason for the rejection. In the meantime of course, you do what you have to do.
Re trailing empty fields, I’ll commit a fix for the ones noted in this thread. Thanks.
I think that fix would be a good idea just for safety against NULL fields on line end. I will check for your commit with Git. I am getting ready to go live this weekend, may the force be with me.
Rod,
Just want to confirm what the purpose of your new code is. You are replacing empty fields(delimited by *) at the end of a record (delimited by ~) with just the record delimiter (~).
So ****~ (1 or more * followed by ~) just becomes ~.
As an example, anywhere in the x12 file, where there is something like
KY CLINIC*****24*~N3*~N4***~NM1*87*2*KY CLINIC*****24*~N3*~N4***~
becomes.
KY CLINIC*****24~N3~N4~NM1*87*2*KY CLINIC*****24~N3~N4~
I just got off the phone with the department managing the 5010 conversion.
Office ally will continue to accept 4010 claims. they convert them to 5010 format.
I have been sending claims with openemr4.1.0_5 successfully, even though they are going in the 4010 format.
The most important, according to them is the office address issue (cannot be PO Box), and the 9 digit zip code for provider address and office address. (patient addresses are not affected). BTW no hyphen.
the test file by 1/1/12 requirement and the proposals regarding the plan to change to 5010, that need to be sent if the test file fails, is for those practices that transmit to medicare directly.
If I have errors after the deadline officeally will reject my claims with specific information on the needed changes. But I can continue to send 4010. Again, they convert to 5010
Cverk mentioned that we should strip - (hyphens) from the zip code since zip+4 is required. Should be pretty simple.
function billingFacilityZip() {
return x12clean(str_replace('-','',trim($this->billing_facility['postal_code'])));
}
Rod, think that makes sense?
A nicer “to do” would be to confirm that the zip is also indeed valid, (9 digit) and generate a warning in the log if not.
My test file to OfficeAlly using my original rudimentary fix of just commenting out middle names, seems to have passed their edit, with only one small remaining error. I had to remove the zip code hyphen from insurance company zip codes as well as our facility zip code. The 5010 standard really doesn’t seem to like hyphens in the middle of zip codes, even though that is the way the postal system writes zip codes.Tomorrow I will start sending some actual claims and we will see what happens. I presume because this is supposed to be a nationalized standard, that the same corrections would apply to all clearinghouses.
Kevin, I believe paper claims require the hyphen in the zip code whereas X12 claims forbid it. So Claim.class.php is probably not the best place to do this. What I’d suggest is putting a function into both gen_x12_837.inc.php and gen_hcfa_1500.inc.php to format zip codes as needed for each, and working correctly regardless of whether the dash is in the database or if there are 5 digits or 9. And this should be done consistently for all zip codes, not just for billing facility.
I directly submit to Medicare and they do not want the hyphen. I would like to use them in the database and remove them when required ala 5010 billing. Without the hyphen the 9 digit number is confusing.