Chris: Any kind of "response timing" would probably apply at the transport layer. Though some kind of service level agreement for application transaction set processing would be nice - guaranteeing that real-time 270s are turned around with a 271 within 2 minutes, or that a claim will be processed and definitively rejected or accepted within 24 hours - I don't see the need for it right now to be specified in the CPP. I do think it would be reasonable to have a specification which says TA1 and 997s will be returned in a certain period of time. But as long as providers can query on the status of claims with the 276, or payers can keep them "posted" with the unsolicited 277, application response timing is overkill.
Application level things like "timeToPerform" in the ebXML CPP pertain to Business Processes, but I really don't think we're going to be able to apply more than the most rudimentary "default" business process to primitive "legacy" EDI messaging. Actually, I really have no problem with the way primitive "legacy" EDI works, including the HIPAA standard transactions. But I'm still in the habit of saying "legacy" because you look stupid - or just don't "get it" - if you fail to sneer at EDI in front of Venture Capitalists! We've discussed selecting alternate Delivery Channels based on functional group (e.g., "real-time" 270 vs 837 batch), but I didn't think Plan ID was ever considered as a selection criteria. That wouldn't be impossible, I suppose. But consider the implications for a VAN or other intermediary who would have no idea what Plan ID applied to the transaction without drilling into the transaction set and looking at application segments like the SBR in the 837. Besides, an 837 would contain claims for multiple plans to be processed by a single payer or TPA. I would suggest that we stay away from criteria for selecting Delivery Channels which can only be obtained from the guts of the application transaction set - or which could very well be non-unique within an interchange. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 ----- Original Message ----- From: "Christopher J. Feahr, OD" <[EMAIL PROTECTED]> To: "Michael Mattias/Tal Systems" <[EMAIL PROTECTED]>; "WEDI/SNIP Listserve" <[EMAIL PROTECTED]> Sent: Monday, 06 May, 2002 06:12 PM Subject: Re: CPP Data elements draft for comment Great comments... thanks! Here are a couple thoughts/responses. 1. Adding more fields to describe the "response timing" that a sender could expect sounds helpful. I was envisioning a separate "CONNECTION" record for each supported TransactionName/TransactionVersion combination. This would enable the receiver to state "response timing" differently for each transaction, if desired. Could SessionTimeOut be used to represent your concept of "RealTimeTimeout/give up" time? I'm not entirely sure how someone would use "SessionTimeOut" programatically... I just copied the field from the X12 "trading partner profile" summary that Dave Minch compiled. 2. I'm a little fuzzy on the security/encryption/authentication requirements... so I was hoping someone would suggest adding, combining, or eliminating fields as appropriate. Certainly, if a public encryption key was needed for a transaction, I'd want to find it (or its location) in the CPP somewhere. To be perfectly honest, I have no idea what the data in CONNECTION fields #19, 20, and 21 would look like. If another field is required to actually hold an encryption "key", that's fine... but don't most PEK systems already utilize some sort of "public key registry/server", meaning that our CPP might only require the address of the key-server? (I'm fairly ignorant about "security"... so hopefully, the experts will jump in!) 3. Regarding the transaction-specific testing and certification data that I stuck in the RECEIVER table, I was hoping to get some input from the group on this. Maybe a whole separate table will be needed for HIPAA readiness, certification, anticipated "go-live dates", etc. The reason that I did not suggest putting this down in the CONNECTION table was that each CONNECTION record represents a scenario for something that WORKS NOW. Whereas, the HIPAA readiness information is more about how things will work in the future, how "certified-compliant" they are, etc. In fact, this info might often be a way of justifying or explaining why a particular combination of PlanID-TransactionName is NOT found as a CONNECTION record for a particular RECEIVER. 4. My thinking on the split between the info in the RECEIVER table and that in the CONNECTION table was that the former would relate to the receiver business as an enterprise or a major division of an enterprise. Perhaps the other table should be called "TRANSACTION" instead of "CONNECTION". It seems conceivable, however, that a RECEIVER enterprise might want to organize his "EDI connection capabilities" around several different concepts. The most important seem to be: 1. the particular transaction supported 2. the type of physical connection supported, and 3. the PlanID As long as the information I have stuck into "CONNECTION" can be indexed and searched on any of these 3 attributes, then it probably doesn't matter what we name the table. The prospective sender will be coming into this registry, knowing the identity of the RECEIVER. If desired, he should be able to pull up all the CONNECTION records for that RECEIVER... or just the subset that are common to the PlanID he's interested in, the type(s) of physical connections he supports, and/or the type/version of the transaction that he intends to send. If a payor, for example, was able to accept "batch" eligibility requests through one "door" and real-time elig. requests through a different one, he would need two CONNECTION records for that transaction: one CONNECTION record in which TransactionName was "270" and NormalResponseTime was small number and another record with TransactionName = 270, but a larger value for NormalResponseTime. Thanks again for all the comments. I will be glad to accept/keep track of these comments/issues about the "CPP elements"and to summarize them for the time being on a second "sheet" inside the main spreadsheet at http://www.novannet.com/wedi/CPP_Elements.xls Thanks again, -Chris Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268
