Chris: We're in luck: there are already a number of standard formats out there for representing implementation guides (or IG-like companion guides) in a machine-readable format:
(1) IMPDEF, a standard UN/EDIFACT message, at http://www.unece.org/trade/untdid, (2) gXML (Guideline XML) at http://www.oasis-open.org/cover/gxml.html, (3) SEF, the Standards Exchange Format, and (4) igML, the Implementation Guide Markup Language, at http://www.oasis-open.org/cover/igml.html You'll see that some discussion of representing HIPAA companion guides in IMPDEF has already ensued on the EDI-L mailing; see Rachel's posting from Wednesday (below). I've invited some of the proponents of these various formats to join us - perhaps they can educate us as to the advantages of their respective favorites! I don't care which of these is used, though I guess if we handled companion guides at all, I might have a slight preference for some kind of XML format - in order to be consistent with most of the other machine readable stuff pointed by the ebXML CPP electronic partner profile. The fact that I devised both SEF and igML - and practically invented the whole concept of machine-readable implementation guides over a decade ago (while I was a high school intern because I'm really, really young) - should not bias our selection. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 ----- Original Message ----- From: "Christopher J. Feahr, OD" <[EMAIL PROTECTED]> To: "'WEDi/SNIP ID & Routing'" <[EMAIL PROTECTED]> Sent: Friday, 12 July, 2002 01:09 PM Subject: RE: CPP and COB [and companion guides] While the mission of this group is superficially about how to "find and connect with" partners, our discussion has consistently included consideration of how to "find, connect, and do business with" a partner. If the CPP will be the primary source of information about this, then it will definitely need to include or point to the details of various supported COB arrangements and any important "companion guide" info. To me, this seems no less critical than information about which transactions are supported, real-time vs. batch mode support, what sort of testing certification is required, etc. In "phase one" we want to at least identify all the CPP elements, but I think it's safe to assume that none of them will be machine-understandable in the first version. In the context of this workgroup, I would suggest that the "legality" of a companion guide element is irrelevant because all CG or IG elements are simply instructions. The goal of the CPP is to convey those and all other relevant instructions to the sender system. At the moment both "guides" are published exclusively in human readable form and everyone already has a copy of (or knows where to find) one of them, so only the supplemental CG instructions need to be referenced in the CPP. I'm not sure if anyone is currently working on a methodology for reducing all X12 IG instructions (whether the "real" or the "companion" variety) to a universal, machine readable XML format... but this would be a terrific idea. When IGs are machine-readable by compliant EDI manager applications, the maintainers of the CPP standard may wish to consider supplementing the pointer to the .pdf version of the CG with a group of XML instructions for auto-implementation of the CG instructions. SIDE BAR: There seems to be a general feeling today that CGs are "bad" because they move us away from "true standardization"... i.e., that CGs essentially spawn different "flavors" of the standard, leading to a world that looks like the one we are trying to get away from. As a provider, however (and I can't imagine that payors would feel differently) I could care less if there 100 or 1000 "flavors" of the "837-P"... or even a unique one for every payor... provided there was an EASY/CHEAP/AUTOMATIC means for my system to discover and implement these business requirements. The requirements, themselves, do not have to be identical... only the method for implementing them. Same goes for the main IGs coming out of the X12 workgroups. As long as my billing system can suck new IGs in as easily as QuickBooks gobbles down and installs its updates every few weeks, then I could care less how complex they are or how may variants are supported. Payor-payor COB and companion guides might be examples of trading partner business requirements that are not fully fleshed out and agreed upon at the moment... in which case, the CPP should at least include a place-holder element to let the world know that we consider the CPP to be the ultimate home for this information. Regards, Chris Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268 ----- Original Message ----- From: "Rachel Foerster" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, 10 July, 2002 04:40 PM Subject: RE: [EDI-L] (Machine readable) Documentation of Jonathan, In spite of HIPAA's intent to standardize transaction set specifications for certain health care financial transactions in the U.S., the vision is not being achieved. Rather, many (most) of the major insurance companies (payers) are creating their own company-specific "companion documents" so that the providers submitting claims, etc. via the 837 and other HIPAA transactions will know specifically what each payer will use to adjudicate a claim. Now....daydreaming a bit more....wouldn't it be a huge cost-savings to health care as they struggle with implementing X12 EDI here if these companion docs were available in the IMPDEF format rather than Word .doc or Adobe .pdf or even some flavor of XML??? Just think about it!!!! Oh....the heat wave has addled my brain! Take care. Rachel Rachel Foerster Principal Rachel Foerster & Associates, Ltd. Professionals in EDI & Electronic Commerce 39432 North Avenue Beach Park, IL 60099 Phone: 847-872-8070 Fax: 847-872-6860 http://www.rfa-edi.com -----Original Message----- From: Jonathan Allen [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 10, 2002 8:46 AM To: [EMAIL PROTECTED] Subject: Re: [EDI-L] (Machine readable) Documentation of Phil, > Ah well, it was fun to start my day off with a little daydreaming ;) The only daydream is of the major VANs and translator vendors allowing their customers that much choice and freedom. Once everyone'e IGs are available in IMPDEF, you can switch VANs and translators at the flick of a switch. It stops the main players having a lock on their customers. It even stops major hubs being able to manipulate their trading partner spokes as to the translator or VAN they must use to keep the hub's business, because all software would be able to process the data. It would level the playing field for translator and trading partner management software, so that you would be able to select the package that suited you based on real performance, support and price. Kind of has something going for it from a user's point of view though, don't you think ? Jonathan ------------------------------------------------------------------------ ---- -- Jonathan Allen | [EMAIL PROTECTED] | Voice: 01404-823670 Barum Computer Consultants | | Fax: 01404-823671 ------------------------------------------------------------------------ ---- -- To unsubscribe from this group, send an email to: [EMAIL PROTECTED] Message Identifiers: <SALES>, <JOBS>, <LIST>, <TECH>, <MISC>, <EVENT>, <OFF-TOPIC> Access the list online at: http://groups.yahoo.com/group/EDI-L discussions on this listserv therefore represent the views of the individual participants, and do not necessarily represent the views of the WEDI Board of Directors nor WEDI SNIP. If you wish to receive an official opinion, post your question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/. Posting of advertisements or other commercial use of this listserv is specifically prohibited.
