The line identifier is already in there. It is stored in an REF segment
with a qualifier 6R (Provider Control Number). The guides leave its usage
to the provider, but if one is assigned by the provider in the claim (837),
then the payer is required to return it in the remittance (835).
Bob
And the gander does that - to the extent required now - we do not send 835s
to a clearinghouse or bank until the provider requests it and the
clearinghouse or bank verifies that they can receive 835s.
But - on the more inflamatory aspects, the business relationship that
exists is between the pro
I hate to say this, but the 835 will be a totally different beast.
The provider CAN say that they want the 835 to be delivered to their bank,
or a different clearinghouse.
The 835 route can be different than the claim route - in fact, there does
not have to BE a claim route - paper claims go on
In my opinion, we have to separate two things here. There is today - and
the desired future.
Today, an open door can not work. There ARE security issues and
connectivity issues and identification issues and contract issues and
validation issues and - well, you get the point. We can not ignore
We currently use login information at the ISA level. This is then cross
referenced with the system login/password that transmitted the interchange.
Interchange/ISA information is not forwarded to the applicable application.
Within the transactions we would use our business level IDs for the
submi
Rachel,
I think that what has happened is that many people have not needed to use
the GS for the original purpose. As a result, they have defaulted its
function to being a restatement of the ISA values. That is different than
morphing. Its fine to retain that default content when no other need
Ok - pet peeve time.
The GS segment does not have either a Sender ID or a Receiver ID. What it
has is an Application Sender's Code and an Application Receiver's Code.
These are very different. They are intended to be used for routing and
translation map identification. We are using these element
Just a few comments from the peanut gallery.
First - I was one of the first people to state that I expect to eventually
see and want a clean, secure, Internet way for Health Care to conduct
Ebusiness. But that is a long way off.
Second - that does not necessarily mean 'open' as I have seen it
Kepa,
I appreciate your tutorial.
I agree that this is a valid and desirable vision for the future, when we
can pull routing together with security, authentication and
non-repudiation. I share that vision. At that point, except for the HIPAA
definition of Clearinghouse as format converter, th
William,
I know I sound like a broken record, but I doubt very much that many
providers will be dumping transactions into any VAN. The norm will be to
dump the transactions into a clearinghouse. Providers will probably have
direct connects to a few payers with whom they do a large amount of
bu
Peter,
I regret that due to my current committments (or over-committments as the
case may be) I will not be able to participate in the Seattle session. I
will be in the Claim Payment WG.
Bob
I can agree with the proposed direction.
Bob
By the way, we do use the straight NAIC code at the ISA level. The NAIC
does support an optional payer assigned suffix. We may be using that
suffix at the GS and transaction levels.
Rachel,
You are preaching to the choir.
But, when the fact is that it is an uphill battle to get people to consider
implementing the 835 and actually eliminating the use of a paper remittance
advice to the provider, how can we expect to get the industry look at the
big picture? This is a step b
Dave,
Testing is a different issue.
We have not come to a final testing position, but the one that seems to be
the most probable is quite interesting.
While we will probably support a testing capability, we may not require it.
With true 'standards' under HIPAA, we can alow productin submission
To my knowledge, the operative for the trading partner decisions is not the
IGs. It is the Privacy Rule and the security NPRM (and expected security
rule).
These have caused our lawyers to decide that we need agreements with our
direct trading partners - the clearinghouses, billing services and
Chris,
Right - I was not talking about secondary claims.
What I was saying was - if you define sender and receiver as original
sender and ultimate receiver then you loose the one to one relationship.
A clearinghouse can receive 10 837s from 10 providers. Each provider can
be sending claims to
Rachel,
Our legal area is not on the same page with the people that say we can do
business without an agreement between the provider and the payer. In fact,
this is a topic that has had EXTENSIVE debate here. The reigning opinion
is that HIPAA will be forcing all payers toward agreements with
There are additional issues with the 835.
HIPAA does not link the 835 with the 837. A provider can ask for the 835
without sending electronic claims.
Providers sometimes send claims through multiple routes. They can even
want to the 835 to return through a different route (like a bank). The
p
Dave,
The section about loop 1000 in the 837 states that it is difficult to
define and describe. From my perspective, loop 1000B is effectively
useless.
If you are using a VAN, then the 1000B contains the receiver of the
interchange as defined in figure 5 of the 837P guide. If not, then the
s
Chris,
I have edited my responses into your message.
Bob
"Christopher
William,
Well, we are definitely at a crossroads.
I strongly disagree with your assertion that use of ZZ and proprietary IDs
could be construed as adversley impacting and therefore non-compliant.
I understand fully your intent and where you are going.
I disagree strongly with that direction a
I would like to reiterate - these ID are sometimes (frequently) an integral
part of the security of an EDI system. For instance, that proprietary ID
assigned by the payer to the submitter (provider/billing service or
clearinghouse) may be the ID of an ID/password pair used in securing access
to
I think that the assumption about clearinghouses never needing to aggregate
claims when the provider submits an 837 is not true. There is still the
role of a clearinghouse outside of the HIPAA clearinghouse definition.
The 837 allows for one transaction to contain claims for multiple payers.
Th
Sorry - I just did a reply earlier and usually that gets where it needs to
go.
- Forwarded by Robert D Poiesz/ISG/CORP/Highmark on 01/22/2002 11:47 AM
-
24 matches
Mail list logo
