Kepa,
Unfortunately I find myself in disagreement with both you and Jonathan.
The only worse fate (for me) would be if Rachel agrees with you guys.
It's hard to believe HHS could make something entitled "Administrative
Simplification" so complicated. Best regards, Mark
My interpretation of 162.925 and this issue between us is as follows:
� 162.925 Additional requirements for
health plans.
(a) General rules. (1) If an entity
requests a health plan to conduct a
transaction as a standard transaction,
the health plan must do so.
(2) A health plan may not delay or
reject a transaction, or attempt to
adversely affect the other entity or the
transaction, because the transaction is a
standard transaction.
(3 -5) omitted.
The key words are "entity" and "requests". The wording does not say
"covered entity", therefore the rule requires that ANY (non-covered) entity
(sponsor, employer, etc) may require a standard transaction from the health
plan.
The other key word, "requests", is where I think you are getting it wrong.
"Requests" are accomplished by deed (sending a standard transaction) not by
word (written or otherwise).
While some health plans may want to respond to all transactions (paper or
otherwise) from all entities (non-covered) with a standard transaction, and
are free to do so if the other (non-covered) entity agrees; these other
(non-covered) entities cannot require (force) health plans to respond to a
non-standard transaction with a standard transaction.
Providers who submit paper are treated as any other (non-covered) entity
for purposes of that transaction and any response to that transaction.
The way any entity "requests" the health plan to conduct a standard
transaction is by submitting a standard transaction.
A "request" can not be done by throwing a paper claim through a window with
a note attached with the words "send it back in a hipaa standard
transaction". The submission of a standard transaction from a non-covered
entity to the health plan is the "request"
"............................... If a person conducts a transaction (as
defined in � 160.103) with a health plan as a standard transaction, the
following apply: ........... The health plan may not refuse to conduct the
transaction as a standard transaction. ............"
".................We interpret this provision to mean that there should be
no degradation in the transmission of, receipt of, processing of, and
response to a standard transaction ...................................."
(full text and cite below)
The commentary at 50316 Federal Register / Vol. 65, No. 160 / Thursday,
August 17, 2000 / Rules and Regulations speaking to 162:923 and 162.925
supports this.
4. Conducting the Transactions
Proposal Summary: If a person
conducts a transaction (as defined in
� 160.103) with a health plan as a
standard transaction, the following
apply:
(1) The health plan may not refuse to
conduct the transaction as a standard
transaction.
(2) The health plan may not delay the
transaction or otherwise adversely
affect, or attempt to adversely affect, the
person or the transaction on the ground
that the transaction is a standard
transaction.
commentary omitted...................
Response: Section 1175 of the Act
prohibits a health plan from delaying a
standard transaction, or otherwise
adversely affecting, or attempting to
adversely affect any person desiring to
conduct a transaction referred to in
� 1173 (a)(1) of the Social Security Act
or the transaction on the ground that the
transaction is a standard transaction.
We interpret this provision to mean that
there should be no degradation in the
transmission of, receipt of, processing
of, and response to a standard
transaction solely because the
transaction is a standard transaction.
Thus, health plans must process
standard transactions from any person,
including, but not limited to, covered
entities, in the same time frame in
which they processed transactions prior
to implementation of HIPAA.
Kepa Zubeldia
<Kepa.Zubeldia@cl To: [EMAIL PROTECTED]
aredi.com> cc:
Subject: Re: Issue from a recent
conference
10/26/2001 02:10
AM
Please respond to
transactions
I know this is not a very likely case, but a provider could choose to
not send electronic claims at all, and still be a covered entity under
HIPAA. Perhaps because the provider does electronic eligibility
transactions. Perhaps because the provider desires to receive
electronic remittance advice.
If a provider desires to conduct a transaction, such as remittance
advice, as a standard transaction, the health plan may not refuse to do
so. Nowhere in HIPAA it says that a provider must submit an electronic
claim before he can receive electronic remittance advice.
Oh, well, I am sure this email did not make very many friends, and I am
going to be flamed for this, but, I would like to understand where some
of the logic in the messages below fits in HIPAA.
As a common practice today, there are many payers that will send 835
transactions to providers that desire to receive 835s. In most of these
cases, once a provider makes that choice, all the remittance advices are
reflected in 835s, whether the claim was submitted on paper or
electronic. I am not saying everybody does that, but as far as I know,
most of the 835 files that I have seen also contain payments on claims
that were submitted on paper. I don't see that practice changing with
HIPAA. In fact, I think that if a provider desires to receive all its
remittance advices electronically, the payer must do so. I don't think
the payer can pick and choose certain payments to go on paper remittance
advice and others to go on 835. At least as I understand the HIPAA
regulations.
Dissenting opinions are welcome.
Kepa
[EMAIL PROTECTED] wrote:
>
> I strongly disagree. 162.925 (the rule you quote as authority) is not
> applicable to providers who conduct PAPER submissions. 162.925 et al
are
> only applicable to providers who conduct (submit) EDI transactions. The
> definitions on applicability are clear on this:
>
> 50365 Federal Register / Vol. 65, No. 160 / Thursday, August 17, 2000 /
> Rules and Regulations
> � 160.102 Applicability.
> Except as otherwise provided, the
> standards, requirements, and
> implementation specifications adopted
> under this subchapter apply to the
> following entities:
> (a) A health plan.
> (b) A health care clearinghouse.
> (c) A health care provider who
> transmits any health information in
> electronic form in connection with a
> transaction covered by this subchapter.
>
>
> "Tucci-Kaufhold, Ruth
> A." To:
"'[EMAIL PROTECTED]'"
> <Ruth.Tucci-Kaufhold@u <[EMAIL PROTECTED]>
> nisys.com> cc:
> Subject: RE: Issue
from a recent conference
> 10/25/2001 02:55 PM
> Please respond to
> transactions
>
>
>
>
> The provider can submit paper and request that a payer provide an 835
> remittance. The rule allows this ... the health plan cannot refuse to
> provide that provider with the 835 if that provider asks the health plan
to
> do so. (p. 50469 ss162.925)
>
> The issue of the lack of data can be solved by the payer requiring those
> data elements from the provider ... that is permissible.
>
> Ruth Tucci-Kaufhold
> UNISYS Corporation
> 4050 Innslake Drive
> Suite 202
> Glen Allen, VA 23060
> (804) 346-1138
> (804) 935-1647 (fax)
> N246-1138
> [EMAIL PROTECTED]
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, October 25, 2001 2:41 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Issue from a recent conference
>
> I haven't been fully following this thread, but on the question of a
> submitter "requiring" an 835 response from a paper submission, I
disagree
> strongly.
>
> Paper transaction submissions are exempt from HIPAA transaction
standards.
> HIPAA transaction requirements are expressly limited to EDI transactions.
> The content (lack of) of the paper claim submission would make a
compliant
> 835 EDI response difficult if not impossible.
>
> I fail to see how a submitter, who (at their option, by sending 'paper')
> 'exempts' a transaction from HIPAA, may 'un-exempt' the same transaction
> once it reaches the payor, by requiring an EDI response from the payor.
> Where is this written?
>
> Lastly, a non-compliant EDI response to a paper submission, would place
> only the payor in violation of HIPAA. To permit a submitter to force a
> payor to respond to a paper submission with a non-compliant EDI
> transaction, thereby risking violation and fine, where the reason for the
> non-compliance is solely due to the format and content of data presented
by
> the submitter, is absurd.
>
> "Hauser, Tarry"
>
> <THauser@mahealt To:
> "'[EMAIL PROTECTED]'"
> hcare.com> <[EMAIL PROTECTED]>
>
> cc:
>
> 10/25/2001 02:31 Subject: RE: Issue from a
> recent conference
> PM
>
> Please respond
>
> to transactions
>
> Thanks all....I do think your approach Steve - and that of Jonathan -
> is/are
> the most reasonable given current circumstances. Though it is true that
it
> does raise more questions.
>
> -----Original Message-----
> From: Hanson, Steve [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, October 25, 2001 1:24 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: Issue from a recent conference
>
> We assume that this is a matter that individual providers must work out
> with
> payers, and are modifying our provider demographic data to include
controls
> for this. We also assume that this control applies regardless of whether
> or
> not we receive an 837; that is, we must issue an 835 to a provider who
has
> previously requested this method of payment for both 837 and paper claim
> submissions.
>
> Unfortunately, I can't tell you what parts of the regs we were looking at
> when we reached this conclusion.
>
> Steve Hanson
> Senior Product Technical Consultant, The TriZetto Group, Inc.
> "Pluralitas non est ponenda sine necessitate" - Ockham's Razor (14th
> century)
> for which my favorite corollary is:
> The simplest solution that is both necessary and sufficient is best.
>
> > -----Original Message-----
> > From: Hauser, Tarry [SMTP:[EMAIL PROTECTED]]
> > Sent: Thursday, October 25, 2001 8:30 AM
> > To: '[EMAIL PROTECTED]'
> > Subject: Issue from a recent conference
> >
> >
> >
> > "There did not seem to be a definite answer on how we know that we
should
> > send an 835 transaction back when we receive an 837. At one point there
> > was to be a routing # if the Provider wanted the 835 back. However,
there
> > is nothing in the data field such as a routing # to know."
> >
> > This question cam back to me after one of our own attended an SPBA
> > conference. Do we have an answer for this anywhere in the regs?
> >
> > Tarry L. Hauser
> > Applications Specialist
> > Medical Associates Health Plans
> > 700 Locust Street Ste 230
> > PO Box 5002
> > Dubuque, IA 52004-5002
> > (319)584-4830
> > FAX (319)556-5134
> >
> >
> >
> >
> > **********************************************************************
> > 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.
>
> **********************************************************************
> 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.
