These are not new or theoretical events. The provider submits a "required" set of
information to an individual payer today. That same set of information is still
required
to adjudicate a claim. The implementation guide spells out how to format that existing
set
of "required" data. In very few instances are there any "new" data elements. The
"required" data is primarily existing data elements with some standardized
translations in
a new format. Where there is a new provider/payer relationship, some definition of the
requirements for claim submission will be required just as it is required today. In
many
cases there is a contractual relationship which contains the requirements.
Today, we have providers submitting claims, many via electronic media, to payers and
receiving payments, many electronic, and EOBs, mostly paper.
The biggest change is that the formats will no longer be payer specific, but will be a
national standard. The data requirements for submission to any specific payer will
remain
the same.
In the specific instance of provider ID, until national provider ids exist, local
provider ids will be put into the REF segment. When you are required to actually map
real
data, e.g finalized claims to 835s, the major problems are not the implementation
guides
but the existing problems/ limitations in the adjudication system in terms of balancing
and code sets.
> Jan,
> In the institutional guide, Loop 2010AA NM108 only has 24 (Employer
> Identification Number), 34 (Social Security Number) and XX National
Provide> r> ID. There really is no qualifer in the NM1 segment for submitting
current> > provider numbers. So you are really forced to use the REF segment until
th> e> national provider id is implemented. Applies to both guides if your
> number for the provider is not thier social security or employer ID.
>
> joanne
>
>
>
>
> ----- Original Message -----
> From: Jan Root
> To: [EMAIL PROTECTED]
> Sent: Friday, September 07, 2001 10:52 AM
> Subject: Re: Situational Data Elements
>
>
> Candice
> For things like secondary patient identification numbers (actually any
> secondary/additional identification numbers), yes, payers may require that
> the provider submit that information (hopefully you've got some easy way
fo> r> the provider to get that information in the first place!). The
requirement> > here is not a syntax requirement (these secondary ID REFs are
situational
a> s> you point out). The requirement here is a business requirement.
Secondar> y> ID REFs are situational in the imp guide because not all payers use more
> than one ID. Payers may require this information as a business decision
if> > they need it to find the patient in their
adjudication/eligibility/whatever> > files. This is one of the key pieces of
information
that payers should
b> e> telling providers: "Put this number in the NM109 and this other number in
> the REF using (you pick) qualifier." The guide is meant to encompass many
> different situations. In many ways it is a floor upon which you build
your> > business decisions.
> [Also, remember, the primary patient identification number goes in
> NM108/09. The REF is only used if you require more than one number to
> identify the patient (recalling that Plan/Group Name/Number are carried in
> SBR03 & 04).]
>
> I always like to think of implementation has having three levels of
> control
> 1: Imp guide syntax: this varies from guide to guide, but generally
> speaking, if an element is required, then it must be sent. If there is a
> syntax problem with a transaction, then it can be rejected on those
grounds> ..> Basically, this means that if something is required then it is sent
> (realizing that it's not always easy to figure out when an element is
> required).
> 2. Business decisions: If you need 2 numbers to identify a patient or a
> provider, then you can make a business decision to require two numbers in
> your adjudication process. There is usually room in the 837 (and other
> transactions) for more than one identifier for many entities. Here, if a
> transaction comes in with only one number and you need two, then it can be
> rejected as not meeting your business needs (you can't locate the
patient).> > Just make sure your provider base knows which two numbers you need and
> where to put them in the imp guide (and which qualifier(s) you prefer)
> The guide does limit the scope of certain business decisions. For
> example your system might be able to handle 100 lines on a professional
> claim. The 837P is limited to 50 lines. Hence, all your 100 line claims
> will now come in on two claims. You are not allowed to make a business
> decision to accept 100 line claims. However, you can still make the
> business decision that "these services must be split out this way and
these> > other services must be split out another way, and these must be lumped,
> etc., etc.".
> 3. Customary practices. These are of necessity vague and vary from
regio> n> to region, but they still exist and most contracts have something in them
> about following customary billing practices.
>
> Hope this helps.
>
> j
>
> Candice Craig wrote:
>
> The 837 Professional IG states (page 49) if no rule appears in the
note> s> for
> a situational element, the item should be sent if available to the
> sender.
> As a payer (receiver) can we require the provider (sender) to collect
> and
> therefore transmit the information? For example, using Loop 2010CA -
> Patient Secondary Identification (page 166). This loop is situational
> if
> additional information is required to adjudicate the claim/encounter.
> If we
> require social security numbers for reporting to the state, can we
> require
> that this loop be always used to collect social security numbers? It
i> s> not
> necessary to process the claim, but we must use it when reporting
> encounters
> to the state.
> Thanks for any input!
>
> Candice Craig
> GUI Designer/HIPAA Implementation Team
> Kent County Community Mental Health
> [EMAIL PROTECTED]
>
> This message has been prepared on resources owned by Kent County, MI.
I> t> is
> subject to the Acceptable Use Policy of Kent County. Candice Craig,
> CMH,
> 616-336-8930.
>
>
**********************************************************************>
> 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.
>
>
> --
> This electronic message contains information that may be legally
> confidential and/or privileged. The information is intended solely for
the> > individual or entity named above and access by anyone else is
unauthorized.> > If you are not the intended recipient, any disclosure, copying,
> distribution, or use of the contents of this information is prohibited and
> may be unlawful. If you have received this electronic transmission in
> error, please reply immediately to the sender that you have received the
> message in error, and delete it.
> --
>
>
>
>
> **********************************************************************
> 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.
>
---------------------------------------------
This message was sent using Voicenet WebMail.
http://www.voicenet.com/webmail/
**********************************************************************
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.
