Actually, all of our claims to Magellan (the only insurance company that we WERE actually able to format an x12 well enough to send to and actually receive ERA’s that would process as well) are not going through, and I have seen only one of the ibr’s myself (with only two claims) but it was an HL error. I have to take some time from the marina to check the pertinent facts of this though.
I am currently using version 4-dev and running ubuntu-maverick with apache 2.2.16 php 5.3.3-1 mysql 5.1.49-1. The error I am receiving is “The HL parent ID is incorrect. Segment HL is defined in the guideline at position 001.” The claim I am sending is a Tricare claim and I am sending it to Availity. When I called Avality they stated that 2000B loop has a 0 instead of a 1. Here is the line from the file I sent to Avality HL*2*1*22*0 I checked the entries in OEMR and it shows the policy holder is the spouse. I might be missing something somewhere else. Any help would be greatly appreciated. Thanks in advance John
Sounds like exactly what Tony was talking about. Frankly, there is no way around this one. The “0” is hard-coded in. Perhaps other folks are using different parameters for their insurance data input that make the 0 acceptable.
Tony is talking about 2000C and not 2000B.
My x12gen files and class have had several modifications already (real pain when I have to upgrade) for more compatability with Availity and ValueOptions. I should be familliar enough with this to do some digging on the side of my current oemr project. Can you send me a de-personalized copy of the IBT or whatever file you got the reject from, as well as any other report files you got for the claim from Availity and the insurance company? Some of the reports have great concise info, and others leave you guessing.
Here is the lay-out of 2000B and 2000C:
Loop 2000B - SUBSCRIBER HIERARCHICAL LEVEL
HL - Subscriber Hierarchical Level
HL03 - Subscriber Hierarchical Level
PAT - Patient Information
PAT08 - Patient Weight
SBR - Subscriber Information
SBR01 - Destination Payer Responsibility Sequence #
SBR02 - Patient Relationship to Insured
SBR03 - Insured Group or Policy Number
SBR04 - Group Name
SBR05 - Insurance Type Code
SBR09 - Claim Filing Indicator
Loop 2000C - PATIENT HIERARCHICAL LEVEL
HL - Patient Hierarchical Level
HL03 - Patient Hierarchical Level
PAT - Patient Information
PAT01 - Individual Relationship Code
aethelwulffe, thanks so much for your help, I would be happy to send you whatever information you need. What is the best way to get that info to you, post here? I did call Avality and they stated that it was the 2000B loop not the 2000C and that it had to do with the last digit in the line I posted above. I looked at the x-12 generation file within OEMR and did see where the 0 was hard coded for the 2000C loop but it didn’t look like there was a 0 hard coded for the 2000B loop. The file that I received from Availity is called “activity log-rejection.pdf” inside the file its states its a “AVAILITY 997 FUNCTIONAL ACKNOWLEDGEMENT” The self insured claims seem to process correctly, no errors. Just let me know the best way to proceed from here. Thanks again for your quick response and your help it is greatly appreciated. John
I have been working on this, here was my solution. It seems to work but this might not be the correct way to resolve this. I have never done any programing at all so please provide some feedback. It seems that I am probably entering in information into the software incorrectly as no one else seems to have this issue. Here is what I did to attempt to resolve this. I edited the ~/libary/gen_x12_837.inc.php file and replaced
“*22” .
“*$PatientHL” .
“~\n”;
with
“*22” ;
if ($claim->insuredRelationship() == “18”) {
$out .= “*0” ;
} else {
$out .= “*1” ;}
$out .= “~\n”;
Art would you still like the file if so I will get that sent off this evening. Thanks again for your assistance. John
$PatientHL is a useless variable here. It is not incrimented, and is set to 0 anyway. From what I see, it can never ever ever put out anything but a 0, which means that someone decided that it has no real use. It has worked for lots of other folks, but just like the loop 2000B, it is not coded for a logical relationship…It just puts catch-all zeros in.
For your code alteration, which looks like a good tweak, I would leave the code you modified alone, and change the variable declaration. instead of $PatientHL=0; , do this:
Then the normal code can pop in the value using the variable PatientHL, and perhaps we can declare that variable in the claim class and use it with others to accuratly control the output for the patient/subscriber.
I myself have some very useful changes for the x12 gen file and the x12 partner configuration. I just gotta code the upgrade sql stuff and get someone to help my ignorant ass get them into the GIT repository for review. I’ll check this out more closely, and see if there is more I can do to the gen file to effect this more thoroughly. Hopefully Tony will have some input as well. I myself just dont’ understand the whole patient/subscriber heirarchy. I gotta check the 837 guide and see what all possible values are used there, and all that.
Could you check Tricare 837 Companion guide for any peculiarities they may have for these loops? I will check some medicaid providers companion guides, but since the problem was in a Tricare claim, that might give us the best hints as to why they care, and no-one else does, I would really like to include this when I start begging to get my x12 partner and gen changes included in the release (cause i hate manual updates after a patch, and there are others who could use some of it, I am sure!)
Your comment looks like it may be getting somewhere. The HL is the hierarchical level. I don’t understand how it works, but it would be very helpful if someone could post an explanation of how the HL code is supposed to work, because it is part of the x12 specifications and it is supposed to be correctly used.
Wish I knew more…but apparently the hierarchical level reflects who the patient is vs. the subscriber, right? We track both of those elements in the insurance information, so we should be able to use them when generating an x12 file. It’s just that the x12 gen has worked for many people in the past with just the hard-coded element, but does not do such a good job when we run into insurance companies that demand more in-depth use of the format. I think I should just go through the whole file and identify every bit that could use some improvement (well, actually everything involved in EDI) and maybe organize an effort to flesh out some of the areas where the original code has sort of glossed over.
I wish I was working this as a full-time effort, but “projects” keep coming up due to the efforts of termites and bats….major projects.
Art, thanks much for your reply and your insight, especially for my programing abilities or lack their of “smile”. I called Availity as they are the ones who rejected the claim and wouldn’t even forward on because of that error. They stated that only a “0” or a “1” should be in the 2000B HL04 position. I also called Blue Cross as they are the other ones that are rejecting the claims anytime the subscriber is not the patient. I found the companion guide like you suggested. It is way over my head but I am providing a link if it is helpful. All my claims to the four different clearinghouses I send to are fine as long as the subscriber is the patient. http://www.wpsic.com/hipaa_news/tricare.shtml Let me know if you would like me contribute in any other way. John
I am learning more and more and experimenting more and more. I followed the advice of aethelwulffe on 2011-04-16 and cut and pasted his code as instructed. The claim went through after making this change.
I am assuming I will have to make this change again when I upgrade to 4.1.
I know nothing about billing, but if you get this working in 4.1, it sounds like it will be useful (ie. seems to be a bug fix) to get it into the main codebase to avoid needing to change things like this every upgrade. At that time, getting it into a patch or github commit would be best way to ensure this happens.