Kept,
I don't think you'll ever see that. HHS has worded the language of the
law to set a tone of compliance and encourage a "self-policing"
environment, with the threat of fines for non-compliance. To adopt your
simpler approach could lead to a less uniform interpretation of the
Guides.
More consistent guides, a named (by law), transaction to report IG
edits issued with the original transactions, better supporting
documentation and faster response to industry questions could alleviate
a lot of this pain.
Sorry for the venting.
Jonathan Fox
eCommerce Analyst
Independent Health
CONFIDENTIALITY NOTICE. This e-mail and attachments, if any, may
contain confidential information which is privileged and protected from
disclosure by Federal and State confidentiality laws, rules or
regulations. This e-mail and attachments, if any, are intended for the
designated addressee only . If you are not the designated addressee,
you are hereby notified that any disclosure, copying, or distribution of
this e-mail and its attachments, if any, may be unlawful and may subject
you to legal consequences. If you have received this e-mail and
attachments in error, please contact Independent Health immediately at
(716) 631-3001 and delete the e-mail and its attachments from your
computer. Thank you for your attention.
>>> [EMAIL PROTECTED] 06/29/02 12:54PM >>>
Chris,
The solution is, I think, surprisingly simple.
If the transaction is in X12 syntax and the version is the version
adopted as
the HIPAA standard, and the "Version / Release / Industry Identifier
Code"
represented in GS08 is one of the valid GS08 values under HIPAA, the
sender
is saying that it is a HIPAA transaction. It may be imperfect, but it
is
supposed to be a HIPAA transaction. In that case, the receiver of that
transaction would not be held liable for accepting the transaction even
if it
has some data missing or some error in it. And the receiver may reject
such
imperfect transaction in the front-end, the back-end, or not at all.
If the transaction is not in X12, or does not have the HIPAA GS08 code,
then
the receiver, based on the HHS FAQ, is responsible for not accepting
such
transaction from a covered entity.
Now, if we could get HHS to adopt this simple approach, life would be
so much
easier for everybody...
Comments?
Kepa
On Friday 28 June 2002 06:33 pm, Christopher J. Feahr, OD wrote:
> Kepa,
> I believe you have illustrated the core of the ambiguity: By making
100%
> conformance to a standard a defining attribute of a "standard
transaction",
> we do not allow ourselves a way to define a "basically standard, but
> flawed" transaction... something there will always be plenty of. I
think
> we should define the minimum attributes of a transaction that would
allow
> it to be brought under the general umbrella of "standard", so as to
> distinguish it from obviously non-standard formats like NSF/UB92.
>
> "Standard transactions" would then come in two flavors: Compliant and
> Non-Compliant. ("Non-standard" transactions would only have one
flavor
> because there is no standard yardstick by which they could be
measured for
> compliance.)
>
> Perhaps we could enumerate the elements of a "standard transaction
shell"
> and require that they all be present along with the correct version
> information in ISA12, in order to qualify as a "standard
> transaction". Would this conflict with the current rule in any
way?
>
> Regards,
> Chris
>
>
> At 03:35 PM 6/28/02 -0600, Kepa Zubeldia wrote:
> >Roger,
> >
> >This is a complicated issue. When the law first came out, HHS had a
good
> >number of presentations in which they (mostly Bill Braithwaite)
explained
> >that HIPAA mandated the health plans to accept standard
transactions, but,
> >technically speaking, did not require the health plans to
discontinue non
> >standard transactions. But since the providers are required to only
send
> >standard transactions, there is nobody left the could actually send
the
> >non-standard transactions, therefore the HIPAA transactions become
the only
> >option. We did not have the NPRM on Transactions yet.
> >
> >The transactions final rule is still consistent, requiring payers to
receive
> >the standard transactions and providers to send the standard
transactions.
> >The addition in the final rule is that a covered entity can only
conduct
> >standard transactions with another covered entity. So, even though
the
> >health plans can, technically, still receive NSF/UB82, they can't
receive
> >them from providers.
> >
> >The problem comes, in my opinion, from the answer to the FAQ:
> >
> >"Assigning responsibility for non-compliant transactions
(11/2/2001)
> >Question: If a health care provider electronically conducts a
non-compliant
> >transaction (transmits an old National Standard Format or a
proprietary
> >format) directly to a health plan after the transaction regulation
compliance
> >date, and the health plan accepts and processes the non-compliant
> >transaction, who is in violation of the regulation? Is it the health
care
> >provider or the health plan?
> >
> >Does the acceptance and processing of a non-compliant transaction by
a
health
> >plan from a health care provider constitute a violative trading
partner
> >agreement between the health plan and the health care provider?
> >
> >Answer: If a health care provider electronically conducts a
non-standard
> >transaction with a health plan after the transaction regulation
compliance
> >date, the health care provider and the health plan are both out of
> >compliance. Section 162.923(a) of the rule requires a covered
entity
> >conducting an electronic transaction for which a standard has been
adopted
> >with another covered entity to conduct it as a standard
transaction.
> >
> >If the health plan by agreement required the health care provider to
conduct
> >non-standard electronic transactions, such agreement would not by
its terms
> >violate section 162.915. However, if either party were to abide by
the
> >agreement, they would be out of compliance with section 162.923(a),
for the
> >reason stated above."
> >
> >As I understand it, the question was clearly asked in the context
of
> >transmitting NSF or a proprietary format. The answer, however, is
most of
> >the time interpreted as making the receiver responsible for
detecting the
> >compliance or non-compliance of the sender. And it seems to
indicate that
if
> >the receiver takes a non-compliant transaction, the receiver is out
of
> >compliance.
> >
> >However, I think this is an unreasonable burden on the receiver of
a
> >presumably HIPAA transaction. A transaction sent mostly according
to the
> >HIPAA Implementation Guides but that has an error in it, perhaps an
invalid
> >CPT or ICD9 code, or something of that nature, should not send the
receiver
> >into non-compliance. This is very different from the receiver
accepting
NSF,
> >UB82, or proprietary formats.
> >
> >I think that the sender needs to make a reasonable effort to send
only
> >compliant transactions. The receiver needs to make a reasonable
effort to
> >receive only compliant transactions. And if a non-compliant
transaction is
> >received, the receiver response rejecting or denying the transaction
needs
to
> >be "reasonably compliant". But perfection is probably an
unrealistic goal.
> >
> >For example: A claim for a newborn that has not yet received a first
name
> >could be sent with "Baby" or with nothing as the first name. The
payer,
upon
> >receiving a claim without a first name should be able to suspend it
to
> >research coverage, and upon adjudication, return a response without
being
> >penalized. For example, the 277 or 835 should go back without a
first name
> >if the original claim did not have a first name. This should not
penalize
> >the payer as "non compliant". Just my personal opinion.
> >
> >We run the risk of putting so much of the compliance burden on one
of the
> >parties that the situation becomes unreasonable. It is impossible
to have
> >total perfection. And to put the burden of perfection on one of the
trading
> >partners (the payer) is going to create big implementation
problems.
> >
> >Just my opinion. I hope it is consistent with what I have said in
the
past...
> >
> >Kepa
> >
> >
> >
> >
> >
> >On Thursday 27 June 2002 02:06 pm, [EMAIL PROTECTED] wrote:
> > > 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.
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >--
> >This email contains confidential information intended only for the
named
> >addressee(s). Any use, distribution, copying or disclosure by any
other
> >person is strictly 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.
>
> Christopher J. Feahr, OD
> http://visiondatastandard.org
> [EMAIL PROTECTED]
> Cell/Pager: 707-529-2268
>
>
>
>
**********************************************************************
> 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.
>
>
--
This email contains confidential information intended only for the
named
addressee(s). Any use, distribution, copying or disclosure by any other
person is strictly 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.
**********************************************************************
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.
