Were you able to find this spreadsheet?
Any chance you could spare 20 mins on the phone today to help me outline the
scope of this and related issues for a research note? If so, please call me
on my cell phone 425 985 8650 (I am still in DC after the WEDI meeting.)
In general I understand the kinds of things that represent business policies
not regulated by the HIPAA transaction standards and accommodated by
situational elements in the IGs.
What I am less clear on is:
a) the extent that using existing business policies requires new
instructions, and the form that such instructions should take (i.e., do they
read like an IG or are they described more in business terms).
b) any way of categorizing the kinds of changes that must be specified into
groups that would be easy to describe (e.g., situational presence/absence of
data, changes to coding usage to become standard, bundling, ...)
c) do any of the changes that must be specified drop down to the lower
levels of certification? or are they all at the level of business issues? (I
suspect that the answer is no, by definition)
d) what might be a reasonable expectation for the means of communicating
this from payers to providers
e) what provider development must be deferred until they have this
information. Is it just a matter of last-minute mapping changes or do they
impact deeper remediation issues?
-----Original Message-----
From: Kepa Zubeldia [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 10, 2001 3:59 PM
To: [EMAIL PROTECTED]
Subject: Re: Situational Data Elements
George,
It goes beyond that. Potentially there could be different requirements
for each Type of Bill in the UB92 or each specialty claim in the
Professional guide, and for COB cases with different types of Secondary
payers, and for different provider specialty, etc.
A few years ago we used to use a spreadsheet to identify these
requirements in multiple columns. I still remember using these during
the initial development of the 837 transaction. Perhaps it is time to
resurrect those old notes.
The 837 is still the "kitchen sink" even though we have now three
different colors of it.
Kepa
[EMAIL PROTECTED] wrote:
>
> Jan,
>
> I thought you did a very nice job laying out how information that is
> needed by the payer's system to adjudicate a claim that is not part of the
> required segments of the 837 transaction can be accommodated by the
> situational segments (e.g. since the NPI won't be ready in time, a system
> may require a proprietary provider number which would have to be placed in
> the REF segment in that loop). Wes then asked about an implementation
> guide for the implementation guide and that is what I responded to.
Payers
> could put out a big complex document that would describe what all doctors
> and pharmacies and hospitals and ancillary providers would need to put
into
> various situational segments but it seems more efficient to me to handle
> this in a more simple trading partner agreement. This would be like
> saying, "You know that provider number you use when you submit claims to
us
> now. We'll still need that number to process your claim and we'd like you
> to put it in the REF segment of this loop."
>
> George Mueller
> IT Advisor
> Anthem West BCBS
> (303) 831-2402
>
> CONFIDENTIALITY NOTICE: This email messsage, including any attachments,
is
> for the sole use of the recipient(s), and may contain confidential and
> privileged information. Any unauthorized review, use, disclosure or
> distribution is prohibited. If you are not the intended recipient, please
> contact the sender by reply email and destroy all copies of the original
> message.
>
>
> Jan Root
> <janroot@uhin To: [EMAIL PROTECTED]
> .com> cc:
> Subject: Re: Situational Data
Elements
> 09/10/2001
> 10:12 AM
> Please
> respond to
> transactions
>
>
>
> George
> What would a TPA do here?
>
> j
>
> [EMAIL PROTECTED] wrote:
>
> > Unless I'm mistaken, I thought this is the area where TPA's come
> into
> > play.
> >
> > George Mueller
> > IT Advisor
> > Anthem West BCBS
> > (303) 831-2402
> >
> > CONFIDENTIALITY NOTICE: This email messsage, including any attachments,
> is
> > for the sole use of the recipient(s), and may contain confidential and
> > privileged information. Any unauthorized review, use, disclosure or
> > distribution is prohibited. If you are not the intended recipient,
> please
> > contact the sender by reply email and destroy all copies of the original
> > message.
> >
> >
> > "Rishel,Wes"
> > <wes.rishel@ga To:
> "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> > rtner.com> cc:
> > Subject: RE: Situational
> Data Elements
> > 09/07/2001
> > 01:58 PM
> > Please respond
> > to
> > transactions
> >
> >
> >
> > It sounds like what you are saying is that payers need to release an
> > implementation guide for the implementation guide.
> >
> > Do you think a lot of payers have done so?
> >
> > Has UHIN prepared this (and similar) guidance or is it specific to a
> payer?
> >
> > -----Original Message-----
> > From: Jan Root [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, September 07, 2001 7:53 AM
> > To: [EMAIL PROTECTED]
> > 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
> > for the provider to get that information in the first place!). The
> > requirement here is not a syntax requirement (these secondary ID REFs
are
> > situational as you point out). The requirement here is a business
> > requirement. Secondary 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 be 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
> region
> > 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
> > notes 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
> > is 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.
> > It 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.
> >
> > **********************************************************************
> > 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.
> >
> > CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,
> is
> > for the sole use of the intended recipient(s) and may contain
> confidential
> > and privileged information. Any unauthorized review, use, disclosure or
> > distribution is prohibited. If you are not the intended recipient,
> please
> > contact the sender by reply e-mail and destroy all copies of the
original
> > message.
> >
> > **********************************************************************
> > 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.
> (See attached file: janroot.vcf)
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
> for the sole use of the intended recipient(s) and may contain confidential
> and privileged information. Any unauthorized review, use, disclosure or
> distribution is prohibited. If you are not the intended recipient, please
> contact the sender by reply e-mail and destroy all copies of the original
> message.
>
> **********************************************************************
> 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.
