Doug: Since it is not yet 2002-10-16 (or even 2003-10-16, assuming "WPS Medicare B" has filed an ASCA exemption), any payer can restrict use of electronic transactions any way they please (consonant with existing law, if applicable).
I think something I just wrote to the ID & Routing group has some relevance: When we discuss things here, please work under the assumption of an environment conforming to the HIPAA TCS and Privacy rules, more or less as they are promulgated today. It would be too clumsy to preface everything we say with "If HIPAA TCS were still the law and compliance were required..." Or, if you prefer using the Buckeye subjunctive, something like "If it *wuz* the law..." Rest assured that if the HIPAA TCS Rule were abandoned, cancelled, de-promulgated, de-enacted, obliterated - or whatever - that probably a lot of things we've discussed.... won't have any relevance, let alone the force of law. Kepa Zubeldia made the distinction between *now* and *then* (i.e., H-Day) quite clear in his posting last Thursday, when addressing (artificial) requirements imposed by payers: ...if they really intended to modify the HIPAA requirements by "requiring" something that is not used in the HIPAA guides even after 10/16/03, I am sure you can point to the Final Rule on transactions where it says that you cannot do that. I saw no exemptions in the HIPAA IGs or TCS Rule to the effect that you can make any arbitrary restrictions you feel like as long as you're Medicare. So, yes, it would seem that enforcing such arbitrary changes to the X12 or HIPAA IG syntax rules would be non-compliant under HIPAA. There's plenty of time before H-Day for WPS Medicare B to either 1) fix their translator or processes, or 2) lobby the DSMO process to have the HIPAA IGs themselves reflect the simpler interchange packaging they desire. I certainly would have no objection to option 2 (i.e., changing the guide) - I just don't know why it wasn't chosen long before so folks wouldn't be tempted to invent their own syntax restrictions in "companion" guides. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 ----- Original Message ----- From: "Doug Webb" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, 17 July, 2002 12:55 PM Subject: Re: Multiple ISA/IEA segments See the WPS Medicare B Bulletin, January 2002 issue, pp 22-45 for an example of this type of restriction. They explicitly state that they will process only one transmission type (records group) per transmission, only one GS-GE Functional Group within an ISA-IEA interchange, and only one ST-SE set within a GS-GE Functional Group. Does enforcing these restrictions make them non-complient? My software will generate transmissions that comply with these restrictions because it makes the program simpler. ----- Original Message ----- From: "William J. Kammerer" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, 17 July, 2002 10:22 AM Subject: Re: Multiple ISA/IEA segments As Jonathan Allen has assured us, it is certainly valid X12 usage to include multiple interchanges within a single transmission. The HIPAA IGs go even further, and confirm that it is perfectly permissible to embed multiple transactions within a single functional group, or multiple functional groups within a single interchange. There are even pictures of this in the appendices covering control structures! So, certainly, if the implementation guides themselves say this is acceptable, wouldn't a payer who refuses to accept, or rejects, transactions packaged in Dana's example be non-compliant? If folks thought this might be too difficult to handle, shouldn't the HIPAA IGs have said something else - or explicitly put restrictions on the number of functional groups per interchange or the like? Now, if I were cobbling together outbound transactions, I would probably choose to use the simplest structure - in effect, the lowest common denominator of a single transaction within a single functional group per interchange - just to be safe. I'm a considerate and thoughtful guy. But it seems the recipient would have no business *demanding* the simpler structure in any case; if the sender insisted on submitting a multiply packed interchange, I can't see how the receiver could balk at processing it: she should either just fix her EDI translator or manually break apart the transactions. Or she could always participate in the DSMO process to have the HIPAA IGs changed. Jonathan suggests that there might be "trading partner considerations" here. What does that mean? Are we back to one-off interpretations of implementation guides, where the dominant partner (usually the payer) arbitrarily re-interprets the standard? As it stands, there are probably far too many places in the HIPAA IGs subject to partner "negotiation." For example, use of "extended" characters (see Appendix A.1.2.3) like the at-sign (@) and lower-case characters are presumably subject to partner negotiation! Just how the heck do you send an e-mail address in the PER segment without using the at-sign? Or do you have to negotiate a tedious TPA just to use characters present on every keyboard? Does it grate you that you need "permission" to use lower-case characters? I've used those since 2nd grade; why can't payers handle them? Wouldn't it be simpler for the HIPAA IG to say you can use any character allowed by X12? - in effect, any graphic shared by EBCDIC and ISO 8859 Latin-1 - so you should be able to handle names of those with umlauted pretentiousness, like "Larry von B�low". Hmmm... are the sundry testing and certification vendors checking for this type of stuff? William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 ********************************************************************** To be removed from this list, send a message to: [EMAIL PROTECTED] Please note that it may take up to 72 hours to process your request. ====================================================== The WEDI SNIP listserv to which you are subscribed is not moderated. The 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.
