William, Holy Wars have been started for less provocation! ;-)
All kidding aside, what many compliance checking solutions do is compare the EDI (X12 or NCPDP) to a set of rules appropriate to the HIPAA Implementation Guides and do not actually translate the data into any other format. It is a pass-through process. Any data which passes compliance is then sent (still as X12 or NCPDP data) to a translation map and transformed according to the business needs of the receiver. HIPAA compliance cannot be applied after translation as the compliance rules apply to the structure of the EDI message itself as well as to the data contained within. Don't ask me why, I didn't write the Implementation Guides! The rationale behind making this a two step process is that handling HIPAA-related data really involves two distinct processes: A regulatory process mandated by the Feds and your internal business processes. In an all-in-one solution if there are any changes to either of these you are forced to modify the whole solution. With a two step process if either process changes you only have to tinker with or replace the pertinent process. Internal business process change on a different timetable than do the HIPAA regulatory processes. When HHS originally dropped HIPAA on us I was of the mind that just doing it all in one map was more sensible, but I eventually came around to the belief that it made sense (IMO) to break this into the two distinct processes. Still, there are compelling arguments to either case. With a two-step solution you can (in most cases) keep your current translation solution whether it supports HIPAA compliance or not, and add a front-end process for the HIPAA regulatory bits. This can be more cost-effective, as compliance checking tools are generally significantly less expensive than full-featured translation solutions. The downside to this is you now are probably now maintaining two different sets of tools, potentially from different vendors. Examples of front-end compliance checking solutions are Foresight, Claredi and EDIFECS. They market tools that are dedicated compliance checking solutions, after which the data is then sent for translation to whichever translation solution the receiver chooses to use. Sybase offers a compliance checking toolset as an extension of their EDI Server product, but it is still in effect a two part process: Front-end compliance checking which passes data to the translator for conversion to the receiver's internal data format. Other vendors offer an all-in-one solution, where compliance checking is part of the translation process. Ascential and SeeBeyond are the best examples I can recall for this. Regards, John Murray -----Original Message----- From: William J. Kammerer [mailto:[EMAIL PROTECTED] Sent: Friday, September 17, 2004 4:32 PM To: 'EDI-L Mailing List' Subject: Re: [EDI-L] Level 5....??? How do you perform "[c]ompliance checking [of EDI data]... before any translation takes place?" That itself would require translation of EDI data! If you're translating twice, you're undoubtedly doing something terribly wrong. Why not just translate the EDI transaction set *once* and be done with it? After translation, the resultant claims can be examined for both HIPAA compliance and business suitability. ------------------------ Yahoo! Groups Sponsor --------------------~--> $9.95 domain names from Yahoo!. Register anything. http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/OIFolB/TM --------------------------------------------------------------------~-> . Please use the following Message Identifiers as your subject prefix: <SALES>, <JOBS>, <LIST>, <TECH>, <MISC>, <EVENT>, <OFF-TOPIC> Access the list online at: http://groups.yahoo.com/group/EDI-L Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/EDI-L/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
