Chris: Thanks for continuing your discussion on the main listserve so as to ensure all technical ideas and business requirements are captured. The rationale behind what finally appears in the recommendations can too easily become lost if no record is made; this has happened far too often in the ebXML initiative itself, where the reason or background was discussed in Face-to-Face meetings, but never put anywhere so people could find out why the heck something was done the way it was in the normative specifications.
Besides, if you bounce ideas off the wall in the main playground, you never know who might come along and interject the most crazy idea that breaks a logjam - who knows? - maybe even my good friend Dave Frenkel might come along and have something to say of actual relevance. To illustrate the value of a transcript in standards development, the answer to your question about the X12 838 Trading Partner Profile transaction set can be found in Dave Minch's e-mail posted on 06 March entitled "Use of the 838 for electronic exchange of TPA data," in the WEDi/SNIP ID & Routing mailing list archives at http://www.mail-archive.com/routing@wedi.org/msg00299.html. Dave did compile trading partner data attributes, and provided a synopsis on the listserve. He was unable to really map to the 838, which we needed to know so we could honestly say we considered the 838 - we tried to eat our own EDI "dog food" and found it wanting! The matrix Dave shows will probably be useful to you in devising your CPP elements to describe partner capabilities. Having all prospective CPP data elements organized (and continually maintained) in a spreadsheet or wish-list at one place is certainly superior to having to scrounge through the archives, but I hope it's now apparent why these important discussions should transpire on the public listserve so they're permanently archived. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 ----- Original Message ----- From: "Christopher J. Feahr, OD" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "Rishel,Wes" <[EMAIL PROTECTED]>; "William J. Kammerer" <[EMAIL PROTECTED]> Sent: Saturday, 20 April, 2002 02:30 PM Subject: Data Elements for the WEDI-SNIP-CPP All right, then... As I recall, Dick Brooks was looking at the X12 transaction used for describing preferred addressing and connection protocols for other transactions (I can't recall the X12 transaction # but it was apparently used by OASIS as a template for much of the CPP structure). Anyway... has someone extracted a list of data elements from that transaction? If so, that would be a good start on the basic connection elements. Rachel, do you know if the CPP specification is entirely about the registry *structure*, or has the OASIS group actually enumerated minimum/required data elements for the CPP record? My assumption is that each "industry" using the CPP would have an industry-specific, standard library of XML tags defined for the CPP elements that people are most often interested in. This is the part I was curious to know whether it had been discussed at the level of OASIS's UBL Liaison Committee. Kepa, could you provide us with a "brain dump" of what your were thinking about for the "HIPAA-readiness and certification" data elements? At a minimum, I would think that we would need a Y/N element for each HIPAA transaction with regard to whether the entity is "ready to test" and/or "ready to go live". Maybe we want fields to indicate level of testing passed for each transaction... who the certifying agency was, type of test data used, etc. TANGENTIAL ISSUE: Kepa, have you decided to group or specialize your test/sample data by general area of healthcare... as it relates to this ADMINISTRATIVE consideration? If so, we might want to include the general type of test data the CE used to obtain its certification. For example, if we ever get our eyewear/vision code set, optometrists will want to know that sending in a claim with the new vision codes will not make the receiving system puke. I'm not sure we even have a suitable standard breakdown of the industry into "segments with similar claim and eligibility data requirements" (like "vision", "ambulance", "anesthesia", "in-patient surgical", etc.). It feels like the taxonomy breakdown, but probably doesn't have to be as granular. Maybe a subgrouping of the standard taxonomy codes would do the trick, but since taxonomy is primarily organized around the practice of medicine, it may not map exactly to areas of special transaction handling, special code-sets, etc. I will volunteer to organize all prospective CPP data elements into a spreadsheet/wish-list... then you can all attack it with your virtual machetes! -Chris At 01:28 PM 4/20/02 -0400, William J. Kammerer wrote: >Yes, definitely, I think we should "... jump right into the enumeration >of the data elements now." - in effect, that might be a way of getting >requirements into the open when you see what it entails. Can we take >your discussion and musings onto the Routing listserve? > >William J. Kammerer >Novannet, LLC. Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268
