Does anyone have any thought about the 835 transaction? What if one adjustment code is invalid, in one CAS segment, in the whole file? What do we reject? What if it is a code is found on the file that is marked as "Inactive for 004010", for example? If we reject the whole 835 file we are jeopardizing the posting of cash. If we pull one claim payment (ie., patient) out - then we do not balance.
Pat Wijtyk Sr. Consultant, HDX 610-219-1825 Jan Root <[EMAIL PROTECTED]> on 10/12/2001 10:42:52 AM To: [EMAIL PROTECTED] cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Code Editing Kepa There is an additional solution D. Reject the specific 'claim' in the transaction with a 277 Front-End Acknowledgement transaction indicating an invalid code. The 276/277 WG has nearly completed work on this implemention guide. True, it is not a HIPAA guide, but UHIN, along with several other entities, are planning on using it to solve this problem. j Kepa Zubeldia wrote: > All, > > If you have been following this thread you can see an interesting > dilemma. > > 1. If the transaction has one bad code, like V22, it is non compliant > 2. A non compliant transaction should not be put through the > adjudication system. > 3. Without putting the transaction through the adjudication system some > people will not be able to generate a 277 or an 835. So, how do you > reject the non compliant transaction? > > Personally I think there are three solutions: > A. Reject the entire file with a 997. Since the transaction is > syntactically compliant with X12, the 997 rejection is not appropriate. > B. Reject the specific "claim" in the transaction with an 824. But we > don't have a standard 824 implementation guide yet. > C. Put the non compliant transaction through the adjudication system and > reject or deny that claim with an 835 or a 277 as appropriate. > > Obviously, what we can do today is C, but that implies that the > recipient will be knowingly accepting an processing non-standard > transactions, which is contrary to some generalized trend that > non-compliant transactions MUST be rejected in the front-end and never > put through the adjudication system. > > Are we cornered yet? > > Thoughts? > > Kepa > > Julie Thompson wrote: > > > > A transaction using a non compliant code makes the entire transaction non > > compliant. > > > > There is no need to use non compliant codes. Code specific to an application > > that are not used within HIPAA can be cross walked within the EDI gateway or > > as part of the processing after the EDI gateway into the applicaiton. > > > > Method 1: Some code significant to processing may be validated and rejected > > at the EDI gateway. > > > > Method 2: Code value are validated within the core application system in > > which they are used. If there are invalid codes, the claim would suspend (or > > deny?) > > > > For full details on resolving all code set issues, please feel free to join > > our Code Set Resolution Group. To subscribe go to: > > > > http://snip.wedi.org/forms/form.cfm?id=4 > > > > Within Transaction box, click on code sets to receive white paper working > > documents. > > > > Julie A. Thompson, chairman > > SNIP Code Set Resolition White Paper > > > > From: "Polson, Noelle" <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > > Subject: Code Editing > > Date: Wed, 10 Oct 2001 15:10:04 -0400 > > > > > HIPAA ANSI (v4010) Implementation Guides list valid codes or direct you > > to > > > an external source. When applying edits to transactions that are > > received > > > how are you addressing the following? > > > > > > 1. The IG provides a specific list of codes. When this data > > > element is REQUIRED: > > > a. Do you edit to validate that a value is > > > there, > > > b. Do you validate that the value is one of the > > > ones allowed, > > > c. Do you validate that the value is valid? > > > (i.e.; 834 - Enrollment, Loop 2000 - Member Level Detail, Data Element > > > 1069 - Individual Relationship Code) > > > d. If the value is invalid, do you reject the > > > transaction or do you accept the transaction into your processing system > > > and apply a business rule (i.e.; suspend for manual correction, etc.)? > > > > > > 2. The IG directs you to external sources for some codes (i.e.; > > > zip codes, ICD9, NDC, etc.). > > > a. Will you edit to verify that the value is > > > valid or will you just check to see if a value is present? > > > b. If the value is invalid, do you reject the > > > transaction or do you accept the transaction into your processing system > > > and apply a business rule (i.e.; suspend for manual correction, etc.)? > > > > > > 3. If the field is REQUIRED (i.e.; 834 - Enrollment, Loop 2100 > > > - Member Residence City, State Zip Code, Data Element 116 - Postal Code) > > > but you do not need it for business processing purposes to what depth of > > > editing do you go before allowing the transaction into your processing > > > system? > > > > > > 4. Is there any risk (penalty for non-compliance) to the payer > > > if a code, that is content compliant but invalid, is passed into the > > > processing system(s)? > > > > > > Your feedback would be appreciated. > > > > > > Noelle Polson > > > Blue Cross Blue Shield of Florida > > > HIPAA-AS Corporate Integration > > > > > > Building DC6-4 > > > 4800 Deerwood Campus Parkway > > > Jacksonville, FL 32246 > > > > > > Phone (904) 905 - 0052 / Fax (904) 997-5399 > > > Email [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > > > > > Click on link to visit us on the BCBSFL Intranet > > <http://hipaa.bcbsfl.com > > > > > > > > > CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, > > is > > > for the sole use of the intended recipient 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. > > > > > > > > > > Blue Cross Blue Shield of Florida, Inc., and its subsidiary and > > affiliate companies are not responsible for errors or omissions in this > > e-mail message. Any personal comments made in this e-mail do not reflect the > > views of Blue Cross Blue Shield of Florida, Inc. > > > > ********************************************************************** > > 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. > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > > > > ********************************************************************** > > 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. (See attached file: janroot.vcf) ------------------------------------------------------------------------------- This message and any included attachments are from Siemens Medical Solutions Health Services Corporation and are intended only for the addressee(s). The information contained herein may include trade secrets or privileged or otherwise confidential information. Unauthorized review, forwarding, printing, copying, distributing, or using such information is strictly prohibited and may be unlawful. If you received this message in error, or have reason to believe you are not authorized to receive it, please promptly delete this message and notify the sender by e-mail with a copy to [EMAIL PROTECTED] Thank you ********************************************************************** 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.
janroot.vcf
Description: Binary data
