In a "test" mode, it would seem easier to pack only "test" transactions into an interchange anyway... so the T/P indicator should be useful right where it is. But the CPP record could certainly carry information that supports other ways of distinguishing test from real data.
I believe we are attempting to create a blueprint here for massively enabling communication between "EDI veterans" and a [possibly] large # of EDI neophytes (doctors, labs, DME suppliers, etc.). If the Big Boys are currently using "creative" implementations of the ISA information, I don't think that should deter us from recommending that the ISA be used exactly the way the standard envisioned it. If providers do enable themselves to create X12 interchanges, I would not be surprised to see lots of ISA/ISE envelopes containing a single transaction (e.g., a "real time" 270) or an interchange with 4 or 5 claims in it. Large batches of different transactions with multiple addressees is probably an artifact caused by the mere existence of the traditional form of the CH industry. As the CH industry develops new value-added services to support a model in which payors and providers collaborate more directly through EDI, then I suspect interchanges to get smaller and become more homogenous and more numerous. Regards, Chris At 08:06 AM 5/22/02 -0600, Ronald Bowron wrote: >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 Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268
