Re: Testing. The ISA I14 Usage Indicator (e.g., P for Production Data,
T for Test Data) applies to the entire interchange - we can't change the
X12 standards here. I'd say just put the production transactions (and
functional groups) in one production interchange, and the test
transactions in another. This technique requires nothing of the CPP,
since theoretically a test interchange is sent to the same portal using
the same IDs in the ISA as production data.
Unlike the ISA I14 T/P indicator, which is universally understood - if
not universally implemented, some (or most) organizations demand that
test interchanges be sent using a "testing" ISA receiver ID. I think
we can handle this, too. There's nothing to keep us from adding the
capability into the CPP for specifying a Test ID and Qualifier - along
with the production pair. This would be done on a Delivery Channel
("EDI Address") basis, with some means to differentiate the production
and test (and maybe even "real-time") ISA receiver ID and qualifier
pairs. For example, in effect, the CPP would say if you end up using
Delivery Channel X, then production data is sent with the ISA receiver
field saying NAIC co-code 54901, but a test interchange would be sent
with the "mutually defined" ID "54901TEST" - the NAIC with "TEST"
appended. This is an augmentation of what we discussed before, where
the CPP specifies what's stuck in the ISA receiver field depending on
the circumstances; see "Why do we flap our lips so much....," at
http://www.mail-archive.com/routing%40wedi.org/msg00438.html, from 12
April.
Re: Sharing financial information like routing codes and account
numbers. Providers who have set up debit blocks, as NACHA's Priscilla
Holland talked about, could safely place their account information in
the CPP; see "Electronic Funds Transfer and Security" at
http://www.mail-archive.com/routing@wedi.org/msg00570.html, Others
will probably have no choice but to use some kind of notation to
indicate where a payer could obtain that information, e.g., an e-mail
address or telephone number - necessarily involving a manual process.
Even if we had a fool-proof method of protecting the registry from read
access except by "vetted" participants, most people (providers) would
still feel uncomfortable sharing that information.
I don't know any way around that issue! Except if, as I suggested, the
837 were changed to include it so it could be sent directly from the
provider to the payer (encrypted or over a secure channel). A REF
segment, in the Pay-to or Billing Provider loop, can handle this. The
following says, in effect, bank account number 26000001538215 at
Fidelity Federal Bank & Trust of West Palm Beach, Florida (ABA No.
267087358):
REF*11*26000001538215**01:267087358~
Some people wouldn't even like that (i.e., the provider giving the EFT
information directly to the payer via the claim). Bruce T LeGrand, my
"Deep Throat" Blue contact, says:
My EDI portal is not secure. Since I support dial-up, NDM,
FTP, .. .. ..ad nauseam ad infinitum, my process is fairly
open. And I don't care. If a provider identifies himself to
me properly in a claim, there is no way anyone can spoof me
into sending the payment somewhere it is not supposed to go.
I verified that initially with him and that data is secure
within my system. If it comes in the claim, it can go
anywhere. This is not a secure network like the banks have,
and I don't see any reason why we should incur the costs of
that on top of everything else. When I move money, it will
be the bank portals that service that transaction.
Re: Certification. "Certification," as we use it in WEDI/SNIP, is
defined in the Testing ("Transaction Compliance and Certification")
whitepaper. It only "certifies" that an entity is capable of sending
(or receiving?) syntactically and semantically correct standard
transactions.
Re: Fraud and Trust. We can't address fraud, except insofar as we can
guarantee (through X.509 technology and CA-signed digital certificates)
that only the entity which owns a particular ID (e.g., a NAIC co-code)
can create the CPP which purportedly belongs to it. Once you are sure
that you have a CPP really belonging to Saint Therese Hospital in
Waukegan, our job is done. If Saint Therese Hospital's lack of internal
controls result in false or over-billings, or the Insurance company
lacks the controls to detect fraud, it's not our problem. All a payer
could be reasonably sure of is that the 837 claims indeed came from
Saint Therese Hospital, and that remittances, statuses and payments
actually are returned to Saint Therese Hospital.
Likewise, hospitals would be sure that whomever they sent 837s to really
was the payer they intended - as long as they used the correct ID to
obtain the CPP. Valid digital signatures of incoming claims would
indicate that the payer could trust the claim was coming from whom they
thought - not that they can necessarily trust the sending entity itself.
We can only guarantee identity on the Internet, not honesty or financial
robustness. Since we're going to use X.509 digital certificates to
buttress our trust model, we're dependent on the Trusted third-party
CAs (such as Verisign) to properly vet entities.
If out-of-network providers send standard transaction claims to a payer,
I would expect that electronic EOBs would be sent to the provider, and
that paper EOBs and a check would be sent to the patient. It only makes
sense to send payment to the patient, since in this case the payer only
has a contract with the patient - not the provider. Actually, you would
think that it would be prudent for the payer to always send some type of
paper EOB to the patient, in or out of network, to increase the odds
that funny business will be caught. Given the paper EOB, a patient
treated in-network might have an incentive to report provider
over-billing simply because it applies to his lifetime max.
I don't know how you could keep a provider from submitting an
out-of-network over-billing to the payer (which would only benefit the
patient since she receives the check). It's not my problem - I'm not
paid to worry about it. But standard electronic transactions don't
exacerbate the problem: these are probably also concerns when using the
old HCFA paper form for out-of-network claims.
William J. Kammerer
Novannet, LLC.
Columbus, US-OH 43221-3859
+1 (614) 487-0320
----- Original Message -----
From: "Ronald Bowron" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, 22 May, 2002 10:06 AM
Subject: Re: Updated CPP Spreadsheet and Model Diagram
Per William's request, I'm posting this response to the list. I had
originally sent it directly to William.
William,
To be honest, I haven't thought much about specific data elements. I
was more interested in ensuring that user's of the CPP have the ability
to establish testing requirements as well as production requirements.
Getting down to the ISA routing level:
It would be nice if everyone had the ability to process transactions
based on the testing indicator as recommended by the X12 User Guides.
And that all the information in the ISA would be used for both
Production and Testing. Then the only data element to change when going
live would be the Test/Production indicator. The problem with this
indicator is it is not transaction specific - therefore it assumes all
transaction within the interchange are valid for production. This is
not always the case - for example, an entity may be in production with
sending eligibility requests, but not claims.
Also, not many institutions have used the T/P indicator properly. Most
organizations didn't setup their test environments to represent their
production environments when it comes to sender and receiver ID's.
Therefore, a sender may have one ID for testing and another for
production - assuming the ID is dictated by the receiver (i.e. via ZZ
codes). It's possible that some may consider building x-ref tables to
address this and the use of standard identifiers like the D&B numbers.
With regards to the specific data elements that are released in the
CPP, I somewhat agree with your analogy regarding ABA and other types of
information. Once they are in the public domain, we don't have much
control over how and when they get used. But, if such information can
only be used to benefit (i.e. receive deposits), then there is no reason
for concern. But, if such information can be used to access protected
assets (i.e. make withdraws/payments), then different levels of
protection may be required.
With regards to "Certification". "Certification" will not guarantee
that the transactions are not fraudulent, only that they are properly
formatted and contain valid content based on the standards. Not that
the content is appropriate for payment.
So, much like the Public Trust model discussed in another thread, when
does one consider a business entity a trusted entity? How do you
determine whether or not payment is valid?
In the old days, when a patient was "Out of Network", the physician
simply billed the patient. It was the patients responsibility to
forward the claim to the payer (this is still used today, my dentists
bills this way). The payer then knows that the patient actually did
visit the physician and received the services. With the CPP, does this
become an automated process? What roll will the patient play, if any,
to ensure the claim is sent to the proper insurance plan for payment?
How does the Insurance Plan verify that the patient actually received
the billed services?
I didn't post this to the list, because much of it is out of scope, but
I believe without answers to these types of questions, the CCP may not
have many early adopters.
-Ronald Bowron
