Jonathan
Well, sometimes what is logical is not necessarily what it important. The 'prime,
secondary, etc' indicator is only that: an indicator. Providers submit claims in
the order that they guess is correct (or they may submit one claim to several
payers simultaneously). Payers are ultimately the ones who often determine who is
actually prime, secondary, etc. The long and short of it is that the 'prime,
seconardary, etc' on the claim doesn't mean very much. Much more important will
be the date the claim (or the line) was paid. In many ways, that would be a truer
indicator of who was prime, secondary etc.
As far as prime, secondary, etc applies to a line: it doesn't really apply at that
level. Even if a benefit is not covered by the prime, that line is still
adjudicated by that payer and returned on the 835. There will be a CAS segment on
that line even if the payment is $0.00. So, whoever is prime on the claim is
prime on every service line whether they actually pay anything on it or not.
j
[EMAIL PROTECTED] wrote:
> I'll try to be more specific. The 837 COB has a claim level element to
> explain if the payer paid as prim, sec, tri, etc. The point brought up on
> yesterday's call was that a claim can have COB on some lines on a claim but
> not on all lines of a claim. Some examples... Transition to Medicare,
> Changing Jobs and having dual coverage for some time, Spouse having the
> Primary insurance drops the insurance now the Secondary becomes prime after
> that date.
>
> It seemed logical to me that if it is important enough to have the
> transactions indicate Paid as Prime, Secondary, Tertiary, etc at the claim
> level...that's important right?.... then would not it be logical to
> communicate that information at the line level if such a situation exists?
>
> If it is deemed that communicating this at the claim and line level is
> important but the guides don't support it at the line level, you would have to
> split the claim so that only the claim level element could be used to indicate
> how the claim was paid.
>
> Thanks!
>
> Jonathan Showalter
> Omaha NE USA
> 402-343-3381
> [EMAIL PROTECTED]
> ------------------( Forwarded letter 1 follows )---------------------
> Date: Wed, 29 Aug 2001 11:35:38 -0600
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> From: Jan.Root[janroot]@uhin.com
> Sender: [EMAIL PROTECTED]
> Reply-To: [EMAIL PROTECTED]
> Subject: Re: Adding COB info to Line Level
>
> Jonathan
> I'm not 100% sure I understand your question but let me take a shot at it.
> I'm
> looking at this from the payer perspective ('in' = into the payer, 'out' =
> generated by the payer and sent out)
>
> I think it's actually a non-issue. The rule is, if a payer receives a claim
> which
> has 10 lines, they adjudicate the claim and must return at least 10 lines in
> the
> 835. If one line is not a covered benefit, then the payment on that line is
> adjusted to $0.00. BUT, the rule of thumb is 10 lines in = 10 lines out. So,
> in
> a COB 837, for EVERY payer (regardless of whether the line represents a
> covered
> benefit or not), the payer gets 10 lines in, they produce an 835 with 10
> lines.
> This includes even when a payer bundles (see the excellent discussion on
> bundling
> in the 835 Intro). If a payer bundles a line they still must include that
> bundled
> line (with zero payment) in the outgoing 835. So, the rule is 10 lines in =
> 10
> lines out = 10 lines on the next outgoing COB claim = 10 lines in the next
> 835,
> etc.
>
> Unbundling
> If a payer unbundles a line, the payer may create a situation where it's 10
> lines
> in = 11 lines out. This is acceptable in the 835 (again, see the unbundling
> example). However, for the next COB 837, that 837 still has 10 lines. The
> unbundling is shown by running the 2430 loop twice under the unbundled 2400
> line.
> So, in the case where one payer unbundled a line, the claim would look like
> this:
> 10 lines into Payer A (837) = 11 lines out of Payer A (835) = 10 lines into
> Payer
> B (the COB 837 where the 2430 loop is run twice under the unbundled 2400
> loop/line) = 10 lines out of Payer B (assuming B didn't unbundle any lines in
> their 835), etc.
>
> If a payer splits a claim, the equation may be altered to a two (or more) step
> process like this:
>
> 10 lines in = 5 lines out on Monday
> = 5 (more) lines out on Friday
>
> However, in the end, all 10 lines come back to the provider even if it is in
> several 835s.
>
> The net result is that all payers past the prime can see how each line was
> paid
> (assuming the claim was adjudicated at the line level). If a payer 'didn't
> pay'
> on a line, the line is still included in the 835 with zero payment and the
> appropriate claim adjustment reason code explaining why the line was adjusted
> to
> "0".
>
> Does this make sense?
>
> j
>
> [EMAIL PROTECTED] wrote:
>
> > In reviewing the COB white paper today on the business issue call, an issue
> > came up that I wanted to see if any of you had thought about this.. or.. if
> > you are on an X12 workgroup.. had they thought about this. The issue is
> that
> > if a claim has more than one line. Line 1 may be paid out as Primary and
> > Secondary while line to may only have a Primary Payer. One example of when
> > this is common is when line one has a date range and during that date two
> > insurance companies have coverage but the other lines have dates when there
> is
> > only a single payer.
> >
> > The way to resolve this is to add information to the line level that allows
> > payers to respond how they paid or split the claim into multiple claims.
> One
> > claim would show line one and the other claim would have the other lines for
> > that claim
> >
> > Thanks!
> >
> > Jonathan Showalter
> > Omaha NE USA
> > 402-343-3381
> > [EMAIL PROTECTED]
> >
> > **********************************************************************
> > To be removed from this list, send a message to: [EMAIL PROTECTED]
> .
> > Please note that it may take up to 72 hours to process your request.
>
> **********************************************************************
> To be removed from this list, send a message to: [EMAIL PROTECTED]
> Please note that it may take up to 72 hours to process your request.
>
> **********************************************************************
> To be removed from this list, send a message to: [EMAIL PROTECTED]
> Please note that it may take up to 72 hours to process your request.
begin:vcard
n:Root;Jan
tel;fax:801-466-7169
tel;work:801-466-7705 x202
x-mozilla-html:FALSE
org:Utah Health Information Network
version:2.1
title:Standards Manager
adr;quoted-printable:;;1939 South 300 West=0D=0ASuite 186-11;Salt Lake City;Ut;84115;
x-mozilla-cpt:;17520
fn:Jan Root, Ph.D.
end:vcard
**********************************************************************
To be removed from this list, send a message to: [EMAIL PROTECTED]
Please note that it may take up to 72 hours to process your request.
