Martin,
Here is some unsolicited advice to providers.
While it is true that the Implementation Guides allow multiple patients per
subscriber, and a claim under subscriber and another claim under each one of
the patients for that same subscriber... or even multiple claims under the
same patient... Most payers today don't handle it that way. All payers are
supposed to accept the complex nesting of the claims as described in the
implementation guides, but they are at different X12 expertise levels.
So, as a provider, you could try to stretch the compliance boundary to its
implementation guide limits, or you could be very conservative and take a
simplistic approach to the implementation guide. I suspect the simplistic
approach has a better probability of being handled correctly by most payers.
Of course, it is the provider's choice.
I would start my HIPAA claim implementation the simplistic way:
Subscriber #1
Patient #1
Claim#1
Subscriber #1
Patient #1
Claim#2
Subscriber #1
Patient #2
Claim#1
and so on. Even though this is less "efficient" it probably has a better
chance of getting paid. Then, as trading partners understand these
transactions better, I could start introducing more efficiency. The goal is
not the ultimate X12 efficiency, but, in my view, to get these transactions
paid faster and more accurately.
Just some food for thought...
Kepa
On Thursday 06 June 2002 09:32 am, Martin Scholl wrote:
> You can have:
> 1.) Multiple claim lines per claim; Loop range 2400; Service line Level
> starts with LX
> 2.) Multiple claims per patient; Loop range 2300; Claim Level; starts with
> CLM
> 3.) multiple patients per subscriber; Loop range 2000C; Patient Level;
> starts with HL*n*n*23
> 4.) Multiple subscribers per bill provider; range 2000B; Subscriber level
> starts withHL*n*n*22
> 5.) Multiple bill providers per transaction Set; range 2000A; Billing
> Provider level starts with HL*n**20
> 6.) Multiple transactions per Group Transaction set level; starts with ST
> 7.) Multiple groups per interchange; functional group level; starts with GS
>
> There are 7 possible levels, of which 2, GS and ST, have rarely multiple
> occurences.
>
> Whenever you come to one of these segments (Except LX) you should assume
> the beginning of a new claim.
>
> Martin Scholl
> Scholl Consulting Group, Inc.
> 301-924-5537 Tel
> 301-570-0139 Fax
> [EMAIL PROTECTED]
> www.SchollConsulting.com
>
>
> ----- Original Message -----
> From: "Bradford, Jim" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Cc: "Bradford, Jim" <[EMAIL PROTECTED]>
> Sent: Tuesday, June 04, 2002 11:01 AM
> Subject: Nesting of 2000A, 2000B, 2000C in the 837
>
> > Hi all,
> >
> > I have a question on the 837 Professional regarding the
> > 2000A, 2000B and 2000C loops:
> >
> > It isn't clear from the IG whether or not these loop nest. That
> > is, in a transaction, do you have to have all the 2000A loops
> > (Providers) followed by all the 2000B loops (Subscribers)
> > followed by all the 2000C loops (Patients)?
> >
> > ... or ...
> >
> > Can you have a Provider, followed by a Subscriber, followed by all
> > that Subscribers' dependants, followed by the next Subscriber,
> > their dependants, etc., then followed by the next provider and
> > so forth?
> >
> > The existence of the HL segments and the way they are used seems to
> > indicate that the first approach is required. But in the 837 IG on
> > page 600-605 it seems to show the second approach.
> >
> > The test data I have seen typically includes a single Provider,
> > Subscriber and Patient, so it could be read either way.
> >
> > The tools I've seen that translate from EDI to XML have DTD's that
> > require the loops NOT nest.
> >
> > So. Is either approach equally valid? Is it a matter for Trading
> > Partner agreements?
> >
> > Thanks in advance,
> >
> > Jim Bradford
--
This email contains confidential information intended only for the named
addressee(s). Any use, distribution, copying or disclosure by any other
person is strictly prohibited.
