This project has moved and is read-only. For the latest updates, please go here.

Hierarchical Loop failures

Nov 19, 2013 at 3:16 PM
One of the folks that send a large amount of claims data to us has about a 1% Hierarchical Loop Failure on their files. They have researched the error, and since the Insurance companies and clearinghouses that they send the data to accept the data, they have no intention to modify their program.

We have little recourse but to accept their data as is, and make use of it. If I set the flag that turns these errors into warning messages, will these files be imported into my database, or will they just be ignored silently?

My preference is to accept the data, as I do not believe that these errors would cause us a problem.
Nov 21, 2013 at 2:05 PM
I asked if they had checked with the developers about the Hierarchical Loop issue and their responses was;

"I checked with GE in regards to the way their EDI Plugin builds the file and verified that relay health isn't reporting issues. GE didn't go into the why it is built in that order but supplied a list of all known reported issues and upcoming service pack releases - there aren't any indications of HL issues or upcoming updates.

This same EDI creator is used for Emdeon, Availity, and the Centricity Clearinghouse so I would say that while the HL1 is a significant value - the additional HL2+ segments are either correct (the ANSI guidelines are complex to interpret) or the segments are wrong but the clearinghouses/carriers aren't enforcing them. "

This seems to confirm that it will not be changed on their side.
Dec 11, 2013 at 3:33 PM
So the consumer of these files are either not able to consume these segments, but their applications ignore it and no cares or the do some kind of partial parse with the HLs that are present. This is highly unlikely that they can pay a claim with a missing HL loop since you need to know the patient and the payer to complete that transaction.

The only possible feature change I could make is if the HL parent segment exists after the reference to it.
I have always assumed that the HL ids are sequential and that parent segments appear before it, but the spec doesn't really require this. It's just usually the easiest way to implement it.

If you can find a file that is throwing this error, and give me the sequence of just the HL segments (this will allow me to see which HL it is (provider, subscriber, patient) and where are they attempting to reference each other, I can determine if a feature change will fix this.

If the file is just pointing to HL segments that don't exist in the transaction then I can't help you and your best bet is to turn on the flag that will treat it as a warning and not an exception.
Dec 11, 2013 at 11:28 PM
Dannie:

You have signed an HIPPA form to look at this data. I could send you a file with the error, and the error it generates, encrypted. Would that work for you?

Paul R. Stearns
Advanced Consulting Enterprises, Inc.
14411 Commerce Way
Suite 220
Miami Lakes, Fl 33016

Voice: (305)623-0360 x107
Fax: (305)623-4588




From: "dstrubhar" <[email removed]>
Sent: Wednesday, December 11, 2013 10:34 AM
To: [email removed]
Subject: Re: Hierarchical Loop failures [x12parser:470452]


From: dstrubhar

So the consumer of these files are either not able to consume these segments, but their applications ignore it and no cares or the do some kind of partial parse with the HLs that are present. This is highly unlikely that they can pay a claim with a missing HL loop since you need to know the patient and the payer to complete that transaction.

The only possible feature change I could make is if the HL parent segment exists after the reference to it.
I have always assumed that the HL ids are sequential and that parent segments appear before it, but the spec doesn't really require this. It's just usually the easiest way to implement it.

If you can find a file that is throwing this error, and give me the sequence of just the HL segments (this will allow me to see which HL it is (provider, subscriber, patient) and where are they attempting to reference each other, I can determine if a feature change will fix this.

If the file is just pointing to HL segments that don't exist in the transaction then I can't help you and your best bet is to turn on the flag that will treat it as a warning and not an exception.