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.

Reply via email to