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
