Mary,
A little off topic, but...If you are seriously considering a change request 
to tie the CLM01 value uniquely to the "claim", I would suggest thinking 
about taking this concept even further and proposing a mechanism for the 
provider to uniquely identify each service line with something analogous to 
an "invoice number".  Many payors adjudicate and pay service lines 
independently.  As a provider, I regard each service line as a little 
"claim" or "invoice" to the payor.  I would not enter a "claim" with 6 
service lines into my A/R system as a single entry... it would go in as 6 
separate "charge" entries, one for each service line item.  Medicaids often 
pay one or two service lines on a claim and suspend the others.  The 
concept of "the claim" as a grouping of service lines always struck me as 
arbitrary and fairly useless to both payor and provider.

If it were not for the practical limitation of how many service lines 
conveniently fit on a single sheet of paper, I doubt that we would have 
bothered even inventing the concept of "claim" as an arbitrary grouping of 
service lines.  The concept of "encounter" makes sense because it relates 
to something meaningful to the adjudication rules, but the provider can 
split an encounter into as many claims as he wants and he can put as many 
or as few service lines on each "claim" as he likes.  Why don't we do all 
tracking at the service line level?

Regards,
Chris

At 11:40 AM 8/8/2002 -0500, Mary J Burkinshaw wrote:
>Robert,
>
>I do not believe William is assigning too much to the CLM01 Value as it is
>extremely (and then some) important that this value actually be uniquely
>tied to a Claim as opposed to a particular Patient.  Patient Account Number
>is truely a "Misnomer" (understatement).  It really should be addressed by
>DSMO, it should NOT be so "wishy-washy", but it appears that it was that way
>to tie in with the EMC (NSF) terminology.
>
>If Providers wish to get "paid" for a particular Claim (for a Patient) then
>it would be in their interest to take the responsiblility for assigning a
>(misnomered) "Patient Account Number" that relates to a Specific Claim
>rather that the patient per se, or be working with a Clearinghouse that
>WILL.  (I think getting paid in a timely manner is of interest to
>Providers).
>
>The CLP01 should ALSO relate to a Specified "Claim Number" for
>processing/tracking, as it is too defined as a "Primary Key" for posting.
>It should always be a unique identifier... for the Claim, NOT the Patient
>per se.  Again, PCN is a misnomer.
>
>I work with a number of Clearinghouses, and they internally generate a
>unique value for the Claim, as otherwise the Claim may not adjudicate
>properly.   They convey this to the Provider, and if need be, apply
>extensive edits for the Remittance in effort to submit a Unique Identifier
>for the "CLAIM".
>
>Having some value to track the Claim itself is imperative.   It is really
>part of "Administrative Simplification" as without it, there is no way to
>easily tie it all together.  Key values are an advantage to not only the
>Payer, but the Provider too, not to mention Translation (key values are
>quite important).  Rather than having to try to determine "dupes" from the
>Patient Account Number, Date of Service and Procedure Number (it can happen
>very easily - and could be misconstrued as "Fraudulance", if not caught, -
>that one could end up in litigation, and that DOES happen!!!).  Why not just
>have a value that uniquely identifies the Encounter/Procedures that are
>related?  It would simplify things for everyone.
>
>  The Patient may have an identifier (Member Number or number assigned to
>related incidents) but that should NOT be used for the CLM01 or the CLP01...
>ever.
>
>The changes needed as a result of HIPAA encompass both Payers and
>Providers..... it is not just for one or the other.  Nobody can afford to be
>lazy or leave the burden to someone else here.
>
>Just my opinion,
>Mary
>Axiom Systems, Inc.
>The Managed Care Technical Experts
>763.783.9024 Tel.
>
>-----Original Message-----
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, August 08, 2002 10:17 AM
>To: [EMAIL PROTECTED]
>Cc: WEDi/SNIP ID & Routing
>Subject: Re: 276 routing question, esp. interested in Clearinghouse
>guru's opinion
>
>
>
>William,
>
>I believe that you are assigning too much to the CLM01 value at this point.
>There is a connection to the Patient Account number that is integral to
>this and can not be ignored.  Within the 835, CLM01 must be returned in
>CLP01 - but, CLP01 must also support paper claims.  There, the field is the
>patient account number.  While providers can (and should) assign unique
>numbers in the paper and electronic world, there is no requirement for
>that.  This number IS their number and there is NOT any documented usage by
>other entities, or requirement for a unique value.  Your statement that  "
>it is *not* designated for his own exclusive use" is misleading.  All
>references identify this as the provider's number  - and do *not* designate
>any use by other entities beyond returning the received value unchanged.
>Any payer or clearinghouse that programs aroung CLM01 being a unique number
>(without specific upfront agreement by their provider trading partners)
>does so at their own risk.  Any provider that chooses to not use a unique
>number complicates their posting of the remittance (and other things) but
>is within their rights.  If you want this recommendation for uniqueness to
>become a requirement, I suggest that a DSMO request is the appropriate
>course of action.
>
>Bob
>
>
>
>
>                     "William J.
>                     Kammerer"            To:     "WEDi/SNIP ID & Routing"
><[EMAIL PROTECTED]>
>                     <wkammerer@nov       cc:
>                     annet.com>           Subject:     Re: 276 routing
>question, esp. interested in Clearinghouse
>                                           guru's opinion
>                     08/08/2002
>                     10:58 AM
>
>
>
>
>
>
>Michael:
>
>I'm generally only interested in application problems insofar as they
>affect routing decisions.  This is the only reason I earlier brought up
>suggestions on how the payer might avoid unnecessarily burdening the
>provider with routing decisions which properly are internal to the
>payer.  In an ideal world, the provider shouldn't have to tell the
>payer, via GS03, how to route transactions within the payer's system.
>
>But, since you brought it up: you're right, 004010X098 doesn't really
>say the CLM01 provider-supplied claim number must be unique;  it only
>cautions that it is "...strongly recommend that submitters use
>completely unique numbers for this field for each individual claim."
>
>Frankly, if I were a payer encountering duplicate claim numbers in an
>837 from the same provider, I'd probably just "wipe" out the previous
>claim if it hasn't already been paid, or reject the subsequent claim
>with the 824.  Perhaps I'd further document what I would do with
>duplicates in my "companion" guide, if I even bothered to have one; my
>gut says that the less you have to say in a "companion" guide, the
>better off you and your partners are.
>
>"Patient account number" is probably a misnomer, though a provider might
>very well generate unique claim numbers by concatenating patient numbers
>with an incrementing patient claim number.  Though CLM01 is devised by
>the provider, it is *not* designated for his own exclusive use: it's an
>up to twenty-character "cookie" retained by the payer for identifying a
>claim, guaranteed to be understood by the provider.  If the provider
>can't reconcile a particular claim with the "cookie" he created in the
>first place (returned by the payer in an 835, say), isn't that his
>problem?  - putting aside, for now, the possibility you could get "0"
>back in the case of claims submitted originally on paper.  Nevertheless,
>there's no reason for a provider to unnecessarily complicate life for
>payers.
>
>Shouldn't  we expect providers to use the same consideration (and
>programming acumen) expected of payers?  Nobody, including a payer,
>should have to be a mind-reader.  Though some pieces-parts of the HIPAA
>IGs seem to have CLM01 nailed down, others are downright fuzzy.  If this
>CLM01 stuff in the form of notes could be nailed down, it would
>eliminate one more reason for which anyone would feel compelled to issue
>a "companion" guide.
>
>William J. Kammerer
>Novannet, LLC.
>Columbus, US-OH 43221-3859
>+1 (614) 487-0320
>
>----- Original Message -----
>From: "Michael Mattias/Tal Systems" <[EMAIL PROTECTED]>
>To: "WEDi/SNIP ID & Routing" <[EMAIL PROTECTED]>
>Sent: Wednesday, 07 August, 2002 05:23 PM
>Subject: Re: 276 routing question, esp. interested in Clearinghouse
>guru's opinion
>
>
>
>----- Original Message -----
>From: "William J. Kammerer" <[EMAIL PROTECTED]>
>To: "WEDi/SNIP ID & Routing" <[EMAIL PROTECTED]>
>Sent: Wednesday, August 07, 2002 1:11 PM
>Subject: Re: 276 routing question, esp. interested in Clearinghouse
>guru's opinion
>
>
> > Wouldn't it really be easier for the payer to translate the inbound
> > Status Request once, and then separate the resultant data based on the
> > unique provider-supplied claim number in the 276 (originally, the
>CLM01
> > in the 837)?
>
>
>Yes, it would, but the CLM01 element is not mandated to be unique. It is
>totally under the control of and designated for the exclusive use of the
>provider.
>
>Some places use the "patient account number" here, and so there could
>easily be multiple claims with the same CLM01 value.
>
>I ran into this "duplicate CLM01" thing a couple years ago when I was
>writing a remittance application. I remember when testing I could not
>for the life of me figure out why my sorted remittances were getting
>jumbled up, because I used that CLM01 value right in my sort key. So, I
>RTFM - then sought AND FOUND the duplicates. (I had to add a
>"tie-breaker" to the sort key).
>
>Michael Mattias
>Tal Systems, Inc.
>Racine WI
>[EMAIL PROTECTED]
>
>
>
>
>
>
>
>
>discussions on this listserv therefore represent the views of the
>individual
>participants, and do not necessarily represent the views of the WEDI Board
>of
>Directors nor WEDI SNIP.  If you wish to receive an official opinion, post
>your question to the WEDI SNIP Issues Database at
>http://snip.wedi.org/tracking/.
>Posting of advertisements or other commercial use of this listserv is
>specifically prohibited.
>
>
>
>
>
>
>
>discussions on this listserv therefore represent the views of the individual
>participants, and do not necessarily represent the views of the WEDI Board
>of
>Directors nor WEDI SNIP.  If you wish to receive an official opinion, post
>your question to the WEDI SNIP Issues Database at
>http://snip.wedi.org/tracking/.
>Posting of advertisements or other commercial use of this listserv is
>specifically prohibited.
>
>
>
>
>discussions on this listserv therefore represent the views of the individual
>participants, and do not necessarily represent the views of the WEDI Board of
>Directors nor WEDI SNIP.  If you wish to receive an official opinion, post
>your question to the WEDI SNIP Issues Database at
>http://snip.wedi.org/tracking/.
>Posting of advertisements or other commercial use of this listserv is
>specifically prohibited.

Christopher J. Feahr, OD
http://visiondatastandard.org
[EMAIL PROTECTED]
Cell/Pager: 707-529-2268        


discussions on this listserv therefore represent the views of the individual
participants, and do not necessarily represent the views of the WEDI Board of
Directors nor WEDI SNIP.  If you wish to receive an official opinion, post
your question to the WEDI SNIP Issues Database at
http://snip.wedi.org/tracking/.
Posting of advertisements or other commercial use of this listserv is
specifically prohibited.

Reply via email to