Michael: Thanks for your input. Any good technical junk regarding Healthcare Partner profiles (CPP) and Registries is welcome for discussion on the list. I have heard comments from some folks that there's just too much e-mail on this list, but I figure there can't be enough discussion of technical issues.
And besides, it would be far better to somehow eliminate off-topic discussions - like the AHA vs. DHHS issue of late - if we really need to have some liposuction done on the ID & Routing mailing list. That's not to say it's not an important issue, but it should be moved to the Business Issues mailing list, with no cross-posting. I encourage folks to please review Zon Owen's e-mail on SNIP Listserv Usage & Etiquette Guidelines that he posted to the Business Issues Listserve at http://www.mail-archive.com/business%40wedi.org/msg00311.html on April Fool's Day. Quite reasonably, Zon suggests that "[postings] to subordinate listservs [like the WEDi/SNIP ID & Routing mailing list] should be relevant to the specific activities and work products of those subgroups." Your suggestions - technically reasonable or not - seem to be right on target for developing the Elements of the Healthcare Collaboration-Protocol Profile (CPP). If you were to send your suggestions just to Chris, it would put too much of an administrative burden on him to consolidate and share with the others on his team. There's supposed to nothing secret in an open standards development effort (except administrivia like meeting arrangements and coup d'�tat planning), and this is just the right stuff to engender thought-provoking discussions, fur-ruffling and polite arguments. As a technical aside, I might suggest that the CPP elements be designed in a more general fashion. For example, instead of a number of elements like "ExpectedTestDate837I," "ExpectedTestDate837P," "ExpectedTestDate837D" and "ExpectedTestDate270," perhaps an overloaded "ExpectedTestDate" element might do the trick where the functional group (e.g., 004010X098 for the 837P) is specified as an attribute or subordinate element. This would better accommodate mechanical processing of the XML elements in the CPP, and further, make our CPP generally applicable to all "legacy" EDI as opposed to simply Healthcare. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 ----- Original Message ----- From: "Michael Mattias/Tal Systems" <[EMAIL PROTECTED]> To: "WEDI/SNIP Listserve" <[EMAIL PROTECTED]> Sent: Sunday, 05 May, 2002 10:17 AM Subject: Re: CPP Data elements draft for comment ----- 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 ap plications 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]
