I agree with Rachel as to what a "transaction" is and the structure behind it. However it still concerns me that a group of claims would be rejected because of one claim's error. One, and I stress one, approach is to make sure your Trading Partner understands the rules of the game that you both are playing under. This will give the provider a chance to look at how they build the transaction stream. For example, smaller groups of claims where a reject of one would not cause financial harm to the group of claims being rejected. Along the lines of the value of the claims to make sure high amount claims are not mixed with the smaller amount claims. Of course this is a "work around". And again I have to agree with Rachels definition of a transaction and my knowledge of transaction theory.
>>> "Rachel Foerster" <[EMAIL PROTECTED]> 10/12/01 11:46AM >>> Jan, With your scenario I think you still have the unsolved problem of accepting (i.e., conducting) a non-compliant transaction, which I believe then violates the Transaction final rule. The final rule uses the term **transaction** and not individual claim or service line. In the underlying X12 parlance, a transaction is everything enveloped (contained) within the ST/SE control segments. I don't see where one can evaluate the contents of this envelope and selectively choose which to accept and which to reject on the basis of non-compliance with the HIPAA IG. It's an all or nothing situation in my opinion. Of couse, this will be interpreted a variety of ways, and ultimately an orgnaization's legal counsel may get involved. But, I still think this is a big gray area that needs clarification for the entire industry. Rachel Foerster -----Original Message----- From: Jan Root [mailto:[EMAIL PROTECTED]] Sent: Friday, October 12, 2001 9:43 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. ********************************************************************** 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.
