In my opinion, we have to separate two things here. There is today - and
the desired future.
Today, an open door can not work. There ARE security issues and
connectivity issues and identification issues and contract issues and
validation issues and - well, you get the point. We can not ignore those
or just make them go away.
But, there must also be a vision for the future. I have had that vision
for years, and shared it here. But, that IS very much a future vision
today. We should be able to use the internet for open healthcare EDI. But
that requires security and non-repudiation solutions and databases that
provide identification and routing and validation and connectivity
information. We do not have those today. This is not a simple situation.
The problem that I see with the current discussion is that we are not
actively recognizing that we have a today and a future. The talk often
sounds like one side saying "The future is here, accept it" and the other
side saying "I am not ready for it".
As I recall from the beginning, the focus was on trying to establish a
direction for the future vision and to facilitate the move to that future,
not to impose the future. And, this group's focus is on only part of the
total problem.
I guess what I would like to see is a general tone of "This is were we
should try to go". We could even identify the other issues or problem that
must be solved before we can even go there. The interoperability work is
part of that. The national identifiers is part. There will be a need for
identifiers for other entities not specifically ID'd under HIPAA. And this
will get even more complicated - I foresee a need for increasing payer to
payer EDI. I don't recall any discussion about that dimension.
Greg is right about healthcare today. Mimi is right about what healthcare
needs to become at some tomorrow. The transition will be a bear, and will
not happen overnight. I am hoping that this group can describe the
destination, and maybe start to build the road map.
I guess that's enough preaching for today. Maybe I'll see some of you next
week at the X12 meeting.
Bob
"Mimi Hart"
<HartAM@crstlu To: <[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
kes.com> cc:
Subject: RE: TA1 responding to
non-participating health care
05/30/2002 providers
04:30 PM
I understand your argument Greg...but isn't healthcare different in the
following:
1. Walmart uses EDI when it places an order with a supplier...who it
has talked to initially, probably had several meetings with, and
exchanged trading partner agreements and companion documents and
pricing. A supplier does not "walk in the door" unannounced and declare
itself in need......
2. Healthcare providers have "customers" walk in the door, declare
themselves in need...and pretty much, regardless of whether they have
treated them before or not (especially with EMTALA provisions).. need to
treat them. To stay in business..they need to create a claim and send
it....regardless of whether they have ever worked with their customers
insurer or not....
How can the two situations be compared? Just because "closed' works for
a Walmart...how is it going to work for us?
Mimi Hart
Research Analyst, HIPAA
Iowa Health System
319-369-7767 (phone)
319-369-8365 (fax)
319-490-0637 (pager)
[EMAIL PROTECTED]
>>> "Koller, Greg" <[EMAIL PROTECTED]> 05/30/02 03:11PM >>>
I completely disagree with the concept of an "open" portal. You are
discussing a strategy that violates basic security principal, and
frankly is
not achievable today.
The reference to treating like paper was used. First of all, paper is
pre-screened by the post office before received into the payers
mailroom.
(Hopefully that takes care of the Anthrax)
What is my comfort level with a virus received from an unknown
electronic
source. (Yes, I know I am playing a bit here, but think about it)
I have websites open to the general public, but there is no way in %$#%
that
I open up a production system capable of data exchange to an unknown
entity.
As the industry moves more and more to FTP with some sort of PGP
encryption
as the main communication method (for batch transactions anyway) how
can the
open portal occur? An exchange of Keys must occur before a file can
be
opened.
A mention was made that a trading partner agreement is not mandated by
HIPAA. This is true, but it is strongly recommended. This is a
contradiction to open portal. If it is best practice to have an
agreement,
how can it be argued that open portal is required?
HIPAA allows for Payers to continue to define business rules. One
business
rule I would require is proof of testing with an entity like Claredi
before
accepting transactions. I cannot see how or where such a requirement
flies
against the rule. It does, however, eliminate open portal.
Finally, lets get to the base argument, the main reason for HIPAA (for
the
sake of this argument) is to promote electronic commerce in a health
care
industry that lags behind other industries as far as technological
efficiencies. I have worked in other industries that are "more
efficient"
with electronic commerce, I have never seen an "open" portal utilized
there.
I think the concept of free flow information is a wonderful panacea.
However, without some sort of qualifier (Kepa has referred many times
to
banking and ATM networks) where there is certification required to be
a
member of such a network and to have "trust" among all member, the
open
portal is not achievable. And I think the interpretation that it has
to be
one is not valid.
Greg Koller
Manager of Operations and Business Development
United Wisconsin Proservices
(414)226-5520
[EMAIL PROTECTED]
Be sure to visit our website at http://www.uwproservices.com/
-----Original Message-----
From: Rachel Foerster [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 30, 2002 2:11 PM
To: [EMAIL PROTECTED]
Subject: RE: TA1 responding to non-participating health care
providers
Hi Bruce,
Thanks for describing your procedures. Having procedures and processes
to
deal with this potential scenario has been my point all along.....not
that
HIPAA requires a payer to process a claim from an unknown provider. It
appears to me that you do take the interchange into your electronic
mailroom
and then make a decision on what to do with it.
Rachel
-----Original Message-----
From: Bruce T LeGrand [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 30, 2002 7:52 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: TA1 responding to non-participating health care providers
Hello Rachel,
What we will do is return a response to the submitter, depending on if
it is
an unknown trading partner or an unknown provider within data from a
known
trading partner. We will reject a transaction from an unknown trading
partner.
We will front end deny an unknown provider.
We have many obligations related to paying providers. Working an
unknown is
not one of them. And I did not see anything in the rules requiring us
to do
so.
A provider is not our customer, but potentially a trading partner. We
have
the
liability of properly reporting income to the IRS and state income
boards
for
payments to that provider. We will insist that they become known, not
necessarily participating, to us before accepting their claims.
------------------( Forwarded letter 1 follows )--------------------
Date: Wed, 29 May 2002 16:43:36 -0500
To: [EMAIL PROTECTED]
From: Rachel.Foerster[rachelf]@ix.netcom.com.comp
Sender: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: RE: TA1 responding to non-participating health care providers
Martin,
My apologies for mis-using the term non-par (non-participating) when I
truly
did mean unknown.....I think some of the scenarios posted today
describe
this potential circumstance.
And by no means did I have say that a payer has to adjudiciate every
claim
received. Only that there is the potential to receive a claim from an
unknown (to you) provider and that you cannot reject it out of hand.
You at
least have to take it in through your electronic mailroom and then
decide
what to do with it the same as you would have to do with a paper claim
that
hit your paper mailroom. This is where the TA1 segment could be used
since
of course, your EDI system won't recognize the ISA sender (or perhaps
it
could, if the sender was a clearinghouse with which you already do
business
and the provider isn't known until you peel back the transaction.) In
that
case, what do you plan to do?
Rachel
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 29, 2002 2:31 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: TA1 responding to non-participating health care providers
Rachel,
I'm thinking we have a simple misunderstanding of the terms
"participating"
and "non-participating". There is a difference between "unknown" and
"non-participating".
When you say "non-participating", do you mean it to indicate the
provider's
relationship with us as a submitter/receiver of standard transactions?
>From my perspective, it is a long-standing industry term used to
reference
to the provider's contractual status with us as a plan. Their
par(ticipating) or non-par(ticipating) status dictates reimbursement
rates
for certain plans/services and in many cases, who gets the
check/Explanation
Of Benefits.
Given the standard usage for this term, I totally agree with you on
the
first three of your points.
For item 4... We do anticipate receiving data from both par and
non-par
providers and processing/adjudicating those claims. If we receive
claims
from providers we can't identify or discern from what was received,
they are
not/will not be adjudicated whether they are received on paper or via
EDI.
Additionally, we reserve the right to not load data into our system
that is
coming from a submitter (which may be a provider) we don't know.
And 5... We process it (provided we can identify the provider).
_____
Martin A. Morrison
-----Original Message-----
From: Rachel Foerster [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 29, 2002 9:15 AM
To: [EMAIL PROTECTED]
Subject: RE: TA1 responding to non-participating health care providers
Martin,
Not to belabor my point, but the point I was trying to make is this:
1. It is potentially possible for a payer to receive an electronic
claim
from a non-participating provider
2. The payer cannot refuse to receive the claim
3. The payer is not obligated to process/adjudicate the claim
4. The payer, in my opinion, should anticipate the potential for
receiving
electronic claims from unknown providers and have a procedure for
dealing
with them
5. This process would be no different than what happens today if a
payer
receives a paper claim from a non-par provider....what do you do with
it?
Rachel
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
Sent: Tuesday, May 28, 2002 8:16 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: TA1 responding to non-participating health care providers
Rachel,
I was afraid I'd be misunderstood.
Let me address the points you raise, as I see them, in the order you
present.
I'm NOT saying, under HIPAA, that ANY payer has the option of not
accepting
a valid 837 based on the provider's non-participation status with said
payer.
We did have a policy like that some years ago. I believe some other
payers may still.
It was better for the bottom line to take in as many receipts as we
could
via EDI, so we dropped that restriction.
We have NO intention of restricting submission of claims to
participating
providers.
Our TPA's will not include any restrictive clauses not allowed in
§162.915.
We are writing our processes to the IG's trying to allow for as much
flexibility on the submitters part as possible by including a lot of
new
business intelligence logic. We will only be including requirements
that,
if not met, will cause the transaction to be unprocessable by us.
While
these requirements (primarily codes) are specific to the HIPAA IG's,
they
correlate directly to elements contained in a paper submission. Bad
data is
bad data.
If a covered entity wishes to conduct a standard transaction with us,
we
will accommodate their request, set them up and take their data or, if
the
transaction is an outbound transaction like the 835, we will start
routing
the data to the portal identified during the set-up. Their claims
generation and accounts receivables may not be on the same platform or
use
the same transmission medium. We are not, in any way discriminating
against
submitters who want to conduct standard transactions. We have no
intention
of violating any clauses under §162.925. The closest thing we have
here the
necessary *adversity* of bullet "(2)": (Allowing us to set-up the
submitter
in our system in order to reliably conduct the transaction(s)). There
has
to be some reasonable thought applied to all of this. Certain things
are
just understood under HIPAA. Certain questions are never asked.
Like...
If we wished to do away with paper Explanations Of Benefits in favor
of
HIPAA-standard 835's, must all providers we process a claim for be able
to
receive an 835?
I don't want to see this whole thing revert back to business as it has
been
done in the past and welcome the automation possibilities available to
all
of us under HIPAA. We should have been able to do all of this long
ago
without federal mandates, but we didn't. If we assume, now, that it's
just
a matter of opening all the spigots, I'm afraid we'll all drown.
_____
Martin A. Morrison
-----Original Message-----
From: Rachel Foerster [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, May 28, 2002 4:49 PM
To: [EMAIL PROTECTED]
Subject: RE: TA1 responding to non-participating health care providers
Martin,
I don't share your perception that a payer can choose **not** to
receive an
electronic claim from a non-participating provider. I haven't seen
anything
in the statute or the electronic transaction rule that gives a payer
the
option of **not** receiving a HIPAA electronic transaction from a
non-par
provider. If you get them on paper today, you can and should
anticipate
getting them electronically in the future. Functionally, this is no
different than a claim or other transaction on paper coming in through
your
company's mailroom or appearing on your fax machine.
Furthermore, there is NO requirement for a trading partner agreement
under
HIPAA.
§ 162.915 Trading partner agreements.
A covered entity must not enter into
a trading partner agreement that would
do any of the following:
(a) Change the definition, data
condition, or use of a data element or
segment in a standard.
(b) Add any data elements or
segments to the maximum defined data
set.
(c) Use any code or data elements that
are either marked ''not used'' in the
standard's implementation specification
or are not in the standard's
implementation specification(s).
(d) Change the meaning or intent of
the standard's implementation
specification(s).
If you strongly disagree with this potential scenario and whether or
not
your organization is obligated to at a minimum receive the electronic
interchange and enclosed transaction(s) in through your electronic
front
door then I strongly recommend that you consult with your
corporatation's
legal counsel on the issue.
>From the Electronic Transaction Final Rule:
§ 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) A health plan may not reject a
standard transaction on the basis that it
contains data elements not needed or
used by the health plan (for example,
coordination of benefits information).
(4) A health plan may not offer an
incentive for a health care provider to
Rachel Foerster
Principal
Rachel Foerster & Associates, Ltd.
Professionals in EDI & Electronic Commerce
39432 North Avenue
Beach Park, IL 60099
Phone: 847-872-8070
Fax: 847-872-6860
http://www.rfa-edi.com
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
Sent: Tuesday, May 28, 2002 5:23 PM
To: [EMAIL PROTECTED]
Subject: RE: TA1 responding to non-participating health care providers
Whoa!, Bill...
You make it sound as if payers will be obligated to open their
gateways,
carte blanch, to any who wish to direct a file our way. While there
may, in
the past, for some payers, have been requirements that a provider must
be
"participating" in order to submit their claims electronically or
otherwise
capitalize on their EDI investment(s), that in no way means that we
have to
take in a file from entities we haven't entered into a Trading Partner
Agreement with and set up in our system(s)(participating or not).
If a provider were to unilaterally determine how to route data to us
and get
it wrong, it would increase the chance that we might be receiving
another
carriers information in error. There is also the issue of our not
being
able to process their information or inquiry as certain basic
identifiers
(part of the TPA) were not used or used correctly. I know it flies in
the
face of admin simp., but, until all the identifiers are finalized, we
will
have TPA's that look a lot like what we have today.
If I have missed something in this thread or misinterpreted your
intent,
please accept my apologies in advance.
_____
Martin A. Morrison
Project Management Consultant
HIPAA Implementation/Coordination
Blue Shield of California
4203 Town Center Bl., Ste. D1
El Dorado Hills, Ca 95762
Ph: (916) 350-8808
Fx: (916) 350-8623
-----Original Message-----
From: William J. Kammerer [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, May 28, 2002 2:59 PM
To: WEDi/SNIP ID & Routing
Subject: TA1 responding to non-participating health care providers
Just one more reminder - this time from the EDI-L mailing list - that
we
have to keep in the back of our mind something almost no other
industry
has wrestled with in EDI before: Unsolicited Transactions, à la
Open-EDI, from non-participating providers.
Payers will have to be prepared for taking in anything coming along
from
providers - if they would have taken paper before, they can't put
roadblocks up discriminating against the equivalent Federally mandated
HIPAA standard transactions! Not only will they have to make
available
an open portal for receiving electronic claims and eligibility
inquiries
(advertised in our Healthcare CPP Registry), but they will have to
make
sure their translators can accommodate ISA senders they've never seen
before.
William J. Kammerer
Novannet, LLC.
Columbus, US-OH 43221-3859
+1 (614) 487-0320
----- Original Message -----
From: "Rachel Foerster" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, 28 May, 2002 01:32 PM
Subject: RE: [EDI-L] TA1
On the other hand, the TA1 may become a useful/important ack in health
care under HIPAA since it's entirely possible that a payer/health
plan/insurance company could receive an unsolicited interchange
containing health care claim transactions from non-participating
health
care providers. In this scenario, the translator won't know about the
sender in advance, but the receiver needs to know it's received an
interchange from an unknown sender and then take appropriate action.
Rachel Foerster
Principal
Rachel Foerster & Associates, Ltd.
Professionals in EDI & Electronic Commerce
39432 North Avenue
Beach Park, IL 60099
Phone: 847-872-8070
Fax: 847-872-6860
http://www.rfa-edi.com
-----Original Message-----
From: DPR [mailto:[EMAIL PROTECTED]]
Sent: Sunday, May 26, 2002 11:19 AM
To: [EMAIL PROTECTED]
Subject: [EDI-L] TA1
In my experience, I have never found anyone who wanted or cared about
a
TA1 segment. About all it says is roll call "I'm here'. There are
quite
a number of translators who don't even know what a TA1 is and choke if
one gets through.
So save your time and money and forget about the TA1.
If the ISA/IEA is bad, you will never get a 997 in return.
Dennis Robinson
