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 At 09:17 AM 5/5/02 -0500, Michael Mattias/Tal Systems wrote: >----- Original Message ----- >From: Christopher J. Feahr, OD <[EMAIL PROTECTED]> > > > Here's the link to my proposed CPP template/spreadsheet. (thanks, William): > > http://www.novannet.com/wedi/CPP_Elements.xls > > You may want to hold off on commenting until you have seen a similar CPP > > template proposal that Dick Brooks has been working on. > >Very, very nice...I like it. I look forward to Mr. Brooks' version, too. > >Just one question: Looking through this I noticed the absence (can you >notice an >absence?) of some data fields needed for an applications developer (e.g., me). > >What I am looking to do when I query the registry is to end up with all >the data >I would need to create a document (837, 270, 276, etc), send an ANSI >interchange >and have it get to the receiver, then have it pass the receiver's >(non-medical) >edits; that is, including such things as the applications identifiers. > >For example, some data fields which occur to me right off the top of my >head...(270=Eligibility Inquiry) > >AcceptsRealTime270 - does this Information Source (payer) accept >realtime 270's? >AccceptsBatch270 - does this Information Source accept batch 270's? >ApplicationID270RealTime - GS ID for payer for 'realtime' 270 >ApplicationID270Batch - GS ID for payer's 'batch' 270 >BatchLimit270 - maximum number of requests per single 270 in >batch mode >RealTimeTimeout - if no response to a 270 in 'n' seconds/minutes, >give up. >BatchTurnaroundTime - if no response to a 270 in 'n' hours/days, >consider >'overdue' > >(Your 'NormalResponseTime" and SessionTimeout fields may cover the >Timeout/Turnarounds, but I would like to see it expanded to allow for >different >times for different documents) > >Right now I am focused on the 270/271 (like you hadn't figured that out) >and can >provide a bunch of data fields for inclusion. > >(A DOCUMENT section in addition to CONNECTION would be just fine). > >To whom shall we send these suggested additions, or do we just post 'em >here and >hope for the best? ( Moderator help?) > >(Note: I sent this to a communications expert with whom I may work and he may >comment as well). > >Michael Mattias >Tal Systems, Inc. >Racine WI >[EMAIL PROTECTED] Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268
