Kepa,
Have we not been around this block before? I think the regulations state
that both parties are obligated to conduct a standard transaction. I'm not
trying to split hairs, but I interpret "conduct" to mean "transmit". The
conduct of electronic transactions occurs between two parties, covered
entities in this case. Therefore, both sender and receiver are obligated
to abide by the standard. So how do you reason that the receiver has an
out in not validating data they won't use? Are you saying they have an out
or are you saying that the risk to validate codes is up to the receiver?
The onus on the sender is to generate a compliant transaction WITH
compliant codes (medical and non-medical). The receiver has choices
depending on the amount of risk s/he is willing to accept. The choices run
the gamut from not running compliance and validity checks (faith) to
validating every last detail of the transaction. At the very least I would
suspect all receivers are going to run level one and two compliance checks
to make sure they can transform the X12 to formats they can use.
But what about code set compliance? Does you or others have any insights
or recommendations to share? I take a strict interpretation of the
regulations and implementation guides. If an element requires data from a
specific named code source, then only values from that code source are
acceptable. If, as a receiver of a transaction, I choose to validate
elements containing code source data and my system finds codes not in those
sets, I must reject the transaction regardless of my business need to
process the data or not. Non-standard codes would render the transaction
non-standard. If I intend to store all transactions regardless of whether
I use all the data contained in them, then by storing them or accepting
them into my system, I am saying that they are compliant.
It may not have been anyone's intention to put the burden of compliance on
transaction receivers, but the way that the regulations are structured, how
can one be sure that what one is getting is compliant with respect to
anything beyond level two compliance and going through a certification
process?
I don't disagree with you. Your comment, however, throws me for a loop
considering everything I've read from you for the past year. I would
certainly respect your opinion and logic as it applies to this situation.
And thanks for all of your efforts in this complicated arena.
Roger Wolkoff
Information Systems Analyst
WEA Trust
45 Nob Hill Road
Madison, WI 53713
(608) 661-6688
[EMAIL PROTECTED]
www.weatrust.com
Kepa Zubeldia
<Kepa.Zubeldia@cl To: <[EMAIL PROTECTED]>, "Robbi
McClane" <[EMAIL PROTECTED]>
aredi.com> cc:
Subject: Re: Level of Validation
needed for Inbound Claims...
06/26/2002 09:00
PM
Please respond to
transactions
Robbi,
Here is my understanding. The receiver needs to be able to accept HIPAA
compliant transactions. So you need to be able to receive transactions
with
both CPT and HCPCS codes. You also need to be able to accept dialysis
transactions involving EPO and having the Patient Weight. Even if you do
not
use the Patient Weight in your processing. If you don't use it, that is
not
a reason to reject the transaction. After accepting the transaction,
whether
you use the Patient Weight or not is your business decision.
But, let's say that you get a transaction with the Patient Weight in it,
and
your translator discards the Patient Weight. Later, in adjudicating the
transaction you find that you need the patient weight. At that point,
since
the original claim already had it, you should not go back to the provider
asking for the patient weight. Perhaps instead of just discarding what you
don't need you should store it somewhere.
As far as your validating your trading partners transactions for compliance
and rejecting transactions because they are "not compliant" in an area that
is not of interest to you... I still can't find where in the Final Rule it
says that you need to do that. There is an HHS FAQ that seems to indicate
that you are not allowed to receive and process a non-compliant
transaction,
but I don't think that it was HHS' intention to put all the burden of
compliance on the receiver of the transaction.
Other opinions?
Kepa
On Tuesday 25 June 2002 12:22 pm, Robbi McClane wrote:
> There have been similar individual questions posted on various mail
lists
which are related and beg the bigger question in regards to compliance of
INBOUND transactions..
>
> Is the RECEIVER of an HIPAA transaction OBLIGATED to perform all levels
of
validations - beyond X12 and HIPAA syntax in order to be considered in
COMPLIANCE? Specifically, in regards to two areas:
>
> 1) external code sets - both medical and non-medical (e.g. postal codes,
HIN
numbers, etc.)
> and
> 2) product or service specific (e.g. Patient Weight is required on
claims
invoking EPO for patients on dialysis)
>
> My personal interpretation of is that I must be able to RECEIVE and
PROCESS
codes from the external code sets - which is not necessarily the same as
validating - for example, as long as my adjudication system can accept a
code
but doesn't utilize and therefore doesn't kick it out if it is incorrect
that
I am okay... - but I'm not sure if the same logic can apply to #2 (e.g. I
don't require patient weight...)
>
> any thoughts? differences of opinion??
**********************************************************************
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.
======================================================
The WEDI SNIP listserv to which you are subscribed is not moderated. The
discussions on this listserv therefore represent the views of the
individual participants, and do not necessarily represent the views of the
WEDI Board of Directors nor WEDI SNIP. If you wish to receive an official
opinion, post your question to the WEDI SNIP Issues Database at
http://snip.wedi.org/tracking/.
Posting of advertisements or other commercial use of this listserv is
specifically prohibited.
**********************************************************************
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.
======================================================
The WEDI SNIP listserv to which you are subscribed is not moderated. The discussions
on this listserv therefore represent the views of the individual participants, and do
not necessarily represent the views of the WEDI Board of Directors nor WEDI SNIP. If
you wish to receive an official opinion, post your question to the WEDI SNIP Issues
Database at http://snip.wedi.org/tracking/.
Posting of advertisements or other commercial use of this listserv is specifically
prohibited.
