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.
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:;21136 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.
