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.
