[ebxml-msg] The PartyID Conundrum

["William J. Kammerer" <wkammerer@novannet.com>]

If by PartyID, we mean those unique IDs like D-U-N-S, EAN GLN, SCAC, ABA
Routing code, etc., then there's certainly the possibility one or more
of these (even in the same domain, e.g., two or more DUNS numbers) can
be equated to one enterprise.  None of these IDs is ever equated to
multiple enterprises, though; if they could, it would defeat the purpose
of an ID, wouldn't it?

Maybe we've been hung up on this because <PartyId> as used in Messaging
Services should have been called something like <EnterpriseId> or
<OrganizationId>.  The term "Party" is overloaded within ebXML.  It's
use in Core Components implies a functional area or person within an
organization (e.g., "Buyer," "Accounting," "Ship To").

It's nice that - for completeness - a low-level (and oft-changing) URL
can be used for routing within Messaging Services, but I think trading
partners would likely want to use the business (or "Organization" or
"Enterprise") identifiers they're already familiar with.  And they do
that with a VAN today: they slap the DUNS into the X12 ISA or UN/EDIFACT
UNB receiver field, and it's on its way, (somewhat) safely, securely and
reliably - with nary a concern for the port the data will be shunted to.
Internally, the recipient may use the functional group ID (from the
GS) - or another internal routing designation - to ferry the data
onward, but that's not the concern of the sender (or the VAN).

I must not be alone in thinking businesses want to simply address their
electronic data with a single organization identifier (which may be one
of many IBM DUNS!).  See the attached posting made to the WEDi
Transactions listserve today, where a similar issue is being discussed
in the context of HIPAA '96.  Only the front part of the e-mail is
important;  participants in the WEDi SNIP forums have a tendency - like
those in the OASIS ebXML forums - to carry along weeks' worth of a
thread in the body of their postings!

William J. Kammerer
Novannet, LLC.

---

• From: "Koller, Greg" <gkoller@uwsi.com>
• To: "'PETERBARRY@aol.com'" <PETERBARRY@aol.com>, transactions@wedi.org,business@wedi.org
• Date: Wed, 31 Oct 2001 07:55:53 -0600

Peter,

This is some good information.  I struggle with how data can be put into an
835 from a paper form with so much data missing, but I will keep an open
mind.

My big question relates to the topic of Provider EDI numbers.  I agree, it
would be great to have that standardized set.  With regards to payers,
however, that system is pretty much in place and one of the big advantages
of EDI is being able to utilize a single EDI number rather than trying to
figure out correct addresses for larger payers (BC of Wisconsin has one EDI
number compared to at least a dozen physical mailing addresses).  With the
837 requirement of Physical Payer address, this seems to be taking a step
backward.  Any thoughts on how this should be handled?  Are there
requirements that the physical address be accurate or can you use a single
dummy address?

>From a systems perspective, this will increase the size and complexity of a
payer file exponentially.

-----Original Message-----
From: PETERBARRY@aol.com [mailto:PETERBARRY@aol.com]
Sent: Tuesday, October 30, 2001 10:10 AM
To: transactions@wedi.org; business@wedi.org
Subject: Re: Issue from a recent conference


In the email exchange below there are a couple ideas that seem off the
likely 
interpretation of the health plan mandate rule.  So I would like to add some

comments, which are attached.

Peter

Peter Barry
Peter T Barry Company
Ozaukee Bank Building
1425 West Mequon Road
Mequon Wisconsin 53092
(414) 732 5000 (national cell)
peterbarry@aol.com

--------------------------------
In a message dated 10/28/2001 4:56:38 PM Central Standard Time, 
rachelf@ix.netcom.com writes:

> Subj:  RE: Issue from a recent conference
>  Date:    10/28/2001 4:56:38 PM Central Standard Time
>  From:    rachelf@ix.netcom.com (Rachel Foerster)
>  Reply-to:    <A HREF="mailto:transactions@wedi.org">transactions@wedi.org
</A>
>  To:  transactions@wedi.org
>  
>  Wes,
>  
>  You raise excellent questions which can only be answered by any
enforcement
>  rules. Such rules, as we all know, have yet to be proposed let alone
>  adopted. Oh well.....
>  
>  About question b -- also a good question. But, the bigger issue becomes 
what
>  the potential economic liability might be to decide to "take a fine"
rather
>  than comply. In the absence of enforcement rules, one could assume that a
>  violation could be each instance of using a non-standard medical code.
This
>  would make the transaction a violation as well...so the actual number of
>  instances of violations could be quite high and thus not economically
>  acceptable. I believe the definition of the standard to be each 
transaction,
>  each identifier, each code set, but I haven't located the actual language

in
>  the law.
>  
>  Re question c -- I know of at least one health plan that has already made
>  the business decision to accept standard transactions only. Thus, if a
>  provider is not ready, they must use a clearinghouse to accomplish the
>  transformation of the non-standard to a standard.
>  
>  I would take a bit of issue with your statement about clearinghouses. I
>  agree that a clearinghouse can conduct a non-standard transaction, but
only
>  as a business associate of a covered entity and when transforming a
>  non-standard to standard and vice-versa on behalf of a CE. This means
that
>  the clearinghouse is actually a business associate of the covered entity
>  performing a role that could otherwise be performed by the CE itself.
>  However, when it comes to a clearinghouse-to-clearinghouse exchange, then
>  this becomes one CE to another CE and the transactions must be conducted
as
>  standard transactions.
>  
>  From the Transaction Final Rule:
>  § 162.930 Additional rules for health care
>  clearinghouses.
>  
>  When acting as a business associate
>  for another covered entity, a health care
>  clearinghouse may perform the
>  following functions:
>  
>  (a) Receive a standard transaction on
>  behalf of the covered entity and
>  translate it into a nonstandard
>  transaction (for example, nonstandard
>  format and/or nonstandard data content)
>  for transmission to the covered entity.
>  
>  (b) Receive a nonstandard transaction
>  (for example, nonstandard format and/
>  or nonstandard data content) from the
>  covered entity and translate it into a
>  standard transaction for transmission on
>  behalf of the covered entity.
>  
>  
>  Would you agree? I had this discussion just this past week with an
attorney
>  well-versed in all aspects of HIPAA, and this was his take as well.
>  
>  Rachel
>  
>  -----Original Message-----
>  From: Rishel,Wes [mailto:wes.rishel@gartner.com]
>  Sent: Saturday, October 27, 2001 11:56 AM
>  To: 'transactions@wedi.org'
>  Subject: RE: Issue from a recent conference]
>  
>  
>  By definition clearinghouses are permitted to conduct transactions in a
>  non-standard format with one of the two other covered entities involved
in
>  the transaction.
>  
>  The real questions, which remain unanswered, are:
>  
>  a) how will enforcement for the transaction standards occur? how
aggressive
>  will t be?
>  
>  b) will some covered entities take fines as the cost of doing business
>  
>  c) will covered entities who are ready choose to decline non-standard
>  transactions from their stakeholder-trading partners who are not?
>  
>  -----Original Message-----
>  From: Rachel Foerster [mailto:rachelf@ix.netcom.com]
>  Sent: Saturday, October 27, 2001 9:27 AM
>  To: WEDI SNIP 2 (E-mail)
>  Subject: Issue from a recent conference]
>  
>  
>  All,
>  
>  I'm behind in reading these messages, but below is my perspective that I
>  sent to Kepa earlier today. I don't know if I've captured or identified
the
>  core issues, but let's continue the discussion. It certainly would help
if
>  someone who has been following this thread thoroughly could briefly
>  enumerate the core issues/questions we are trying to address.
>  
>  In general terms here's my understanding of the law and regs:
>  
>  1. Covered entities are defined in the law
>  2. Covered entities **must** conduct the specified transactions as
standard
>  transactions on and after 10/16/02
>  3. Covered entities **cannot* conduct transactions between themselves if
a
>  standard transaction and implementation specification has been adopted
>  4. A health care provider can choose to mix/match claims from paper to
>  electronic - as long as the electronic are conducted as a standard
>  transaction
>  5. Once a health care provider conducts **any** of the specified
>  transactions electronically after 10/16/02 they become a covered entity;
>  once a covered entity, always a covered entity, and therefore all the
rules
>  now apply.
>  6. A covered entity is not **required** to conduct a transaction as a
>  standard transaction with a non-covered entity
>  7. Health plans and clearinghouses are **always** a covered entity and
>  **cannot** conduct a transaction as a non-standard with another covered
>  entity; all such transactions between covered entities must be conducted
as
>  a standard transaction
>  
>  What have I missed?
>  
>  Rachel
>  
>  -----Original Message-----
>  From: Rachel Foerster [mailto:rachelf@ix.netcom.com]
>  Sent: Saturday, October 27, 2001 10:28 AM
>  To: 'Kepa Zubeldia'
>  Subject: RE: [Fwd: Re: Issue from a recent conference]
>  
>  
>  Kepa,
>  
>  I'm behind on email since I've been out on the road since last Sunday.
>  However, a quick read of this message you forwarded below leads me to
>  conclude that the assertion seems to be generally. . .
>  
>  1: that any "person" can request a health plan to conduct a standard
>  transaction
>  2: that the "request" may be unanticipated and dynamic by the mere act of
>  receiving a transaction
>  3: that the "request" is dynamic and not pre-determined and pre-agreed to
>  4: that the "person" making the "request" can be any person or entity,
not 
a
>  "covered entity"
>  
>  Is this the essence of the discussion? Have I missed a key point?
>  
>  Whenever I'm unclear as to someone's interpretation of either the law or 
the
>  reg, I first look to the law for clarity. In this case relative to #4, I
>  would say that the law's section on applicability clarifies this issue
when
>  it defines to whom the law applies by describing/defining "covered
>  entities." Thus, my conclusion is that everything else after that in both
>  the law and the regs applies **only** to covered entities as defined in
the
>  law and further that the use of the terms entity or person refers back to
a
>  "covered entity." Thus, in my mind if the person requesting is not a 
covered
>  entity, everything in the law and the regs is off the table and does not
>  apply even though the health plan is a covered entity.
>  
>  So, let's take #1. Sure any person can request a health plan to conduct a
>  standard transaction. But under the law, the health plan is required to
>  conduct a standard transaction **only** with a covered entity, and
further,
>  that a health plan cannot conduct a non-standard transaction with a
covered
>  entity. On the other hand, a health plan is **not** obligated **under the
>  law** to conduct a standard transaction with a non-covered entity, but as
a
>  matter of business, it may either **choose** or not choose to do so.
>  Business reality would indicate that a health plan would certainly want
to
>  **standardize** by using the standard transactions wherever possible
>  regardless of whether the trading partner is a covered entity or not.
>  
>  Re points #2-3. There is nothing in my read of the law that says that the
>  health plan has to conduct a standard transaction on the fly with any 
person
>  that **comes knocking on the door** without the prior establishment of
such
>  a relationship. In other words, a health plan must be prepared to receive
a
>  standard transaction without prior notice. On the other hand, my mind
asks
>  the question, "What about the non-contracted or non-participating
provider
>  that delivers health care to a member and now submits a claim for
payment?"
>  So, generally to this point, I would say that yes, a health plan must be
>  prepared to **at a minimum** take in a standard transaction from another
>  **covered entity** through the EDI front door. Once it's been accepted
>  through the EDI door as a complying standard transaction, then other
>  business rules may and should be applied to determine any subsequent
>  processing. This is a bit different than what one finds in the non-health
>  care EDI environment, where almost all EDI exchanges are established,
>  agreed-to, and tested prior to the actual production exchange of
messages.
>  On the other hand, with the standardization (??!!) of both format and
data
>  content for health care, the dynamic receipt of standard transactions
>  without knowing the originator in advance becomes a possibility -- but
>  **only** (in my opinion) once the standard identifiers for providers, 
health
>  plans and employers are adopted. Without these, the receiving entity has
no
>  way to authenticate the originator, and with assurance respond with
>  **protected health information**. To do so would place the responder,
i.e.,
>  the health plan, at risk for violating the disclosure of PHI provisions
of
>  the law and the privacy reg, and thus become subject to penalty.
>  
>  So, if I was the health plan I would keep in mind the privacy
requirements
>  and establish a policy regarding the receipt of unanticipated standard
>  transactions from unauthenticated entities/persons. My policy and
business
>  rule might go along these lines:
>  
>  1: If a standard transaction is received from an unknown and 
unauthenticated
>  source, first validate that the transaction is in compliance with the
>  standard, then authenticate the originator (tough to do with today's EDI
>  systems that won't find a trading partner relationship set up - so this 
will
>  require some innovative processing here). If the originator can be
>  authenticated in compliance with our authentication rules, then further
>  processing of the transaction **may** proceed.
>  
>  2: It is our policy that all transactions will be conducted by us as
>  standard transactions. Therefore, if a non-covered entity requests us to
>  conduct non-standard transactions with them when a standard transaction
can
>  be used, we will deny that request and work with the requester to
establish
>  the exchange of standard transactions for the requested information
>  exchange.
>  
>  And most certainly, the health plan (covered entity) **must** have its
>  policies and rules established for **authenticating** any person/entity
>  (covered or not) prior to responding to any request for information or to
>  conduct a transaction (whether electronic or not) which would result in
the
>  disclosure of PHI. It's in this area that I think a lot of the privacy
>  consultants/lawyers/gurus are overlooking the EDI aspect of HIPAA.
>  
>  Kepa, does this get to the heart of the matter, or have I missed
something?
>  Feel free to post my comments to the list in which this discussion
started.
>  
>  Rachel
>  
>  -----Original Message-----
>  From: Kepa Zubeldia [mailto:Kepa.Zubeldia@claredi.com]
>  Sent: Friday, October 26, 2001 9:42 PM
>  To: Rachel Forester
>  Subject: [Fwd: Re: Issue from a recent conference]
>  
>  
>  Rachel,
>  
>  Have you followed this thread ?
>  
>  Kepa
>  
>  
>  -------- Original Message --------
>  Subject: Re: Issue from a recent conference
>  Date: Fri, 26 Oct 2001 11:42:59 -0400
>  From: mmacintosh@humana.com
>  Reply-To: <transactions@wedi.org>
>  To: <transactions@wedi.org>
>  
>  
>  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:
>  transactions@wedi.org
>                      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
>  
>  
>  mmacintosh@humana.com 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:
>  "'transactions@wedi.org'"
>  >                     <Ruth.Tucci-Kaufhold@u
<transactions@wedi.org>
>  >                     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
>  > ruth.tucci-kaufhold@unisys.com
>  >
>  > -----Original Message-----
>  > From: mmacintosh@humana.com [mailto:mmacintosh@humana.com]
>  > Sent: Thursday, October 25, 2001 2:41 PM
>  > To: transactions@wedi.org
>  > 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:
>  > "'transactions@wedi.org'"
>  >                     hcare.com>              <transactions@wedi.org>
>  >
>  >                                             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:Steve.Hanson@trizetto.com]
>  > Sent: Thursday, October 25, 2001 1:24 PM
>  > To: 'transactions@wedi.org'
>  > 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:THauser@mahealthcare.com]
>  > > Sent:         Thursday, October 25, 2001 8:30 AM
>  > > To:           'transactions@wedi.org'
>  > > 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, go to:
http://snip.wedi.org/unsubscribe.cfm?list=business
and enter your email address.

**********************************************************************
To be removed from this list, go to: http://snip.wedi.org/unsubscribe.cfm?listūss
and enter your email address.

---