Kepa, I think your suggestion is eminently the most practical and obvious solution to the issue. The next core issue is who/what will make the "official" determination that this is what constitutes a standard versus non-standard HIPAA transaction and how soon will that official determination be made available.
In the absence of such an official determination, the industry is left to interpret on a company-by-company basis and then to implement technology solutions based on their interpretation. Not a very cost effective or efficient scenario in my opinion. 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: Kepa Zubeldia [mailto:[EMAIL PROTECTED]] Sent: Saturday, June 29, 2002 11:54 AM To: [EMAIL PROTECTED]; Christopher J. Feahr, OD; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Level of Validation needed for Inbound Claims... Chris, The solution is, I think, surprisingly simple. If the transaction is in X12 syntax and the version is the version adopted as the HIPAA standard, and the "Version / Release / Industry Identifier Code" represented in GS08 is one of the valid GS08 values under HIPAA, the sender is saying that it is a HIPAA transaction. It may be imperfect, but it is supposed to be a HIPAA transaction. In that case, the receiver of that transaction would not be held liable for accepting the transaction even if it has some data missing or some error in it. And the receiver may reject such imperfect transaction in the front-end, the back-end, or not at all. If the transaction is not in X12, or does not have the HIPAA GS08 code, then the receiver, based on the HHS FAQ, is responsible for not accepting such transaction from a covered entity. Now, if we could get HHS to adopt this simple approach, life would be so much easier for everybody... Comments? Kepa On Friday 28 June 2002 06:33 pm, Christopher J. Feahr, OD wrote: > Kepa, > I believe you have illustrated the core of the ambiguity: By making 100% > conformance to a standard a defining attribute of a "standard transaction", > we do not allow ourselves a way to define a "basically standard, but > flawed" transaction... something there will always be plenty of. I think > we should define the minimum attributes of a transaction that would allow > it to be brought under the general umbrella of "standard", so as to > distinguish it from obviously non-standard formats like NSF/UB92. > > "Standard transactions" would then come in two flavors: Compliant and > Non-Compliant. ("Non-standard" transactions would only have one flavor > because there is no standard yardstick by which they could be measured for > compliance.) > > Perhaps we could enumerate the elements of a "standard transaction shell" > and require that they all be present along with the correct version > information in ISA12, in order to qualify as a "standard > transaction". Would this conflict with the current rule in any way? > > Regards, > Chris > > > At 03:35 PM 6/28/02 -0600, Kepa Zubeldia wrote: > >Roger, > > > >This is a complicated issue. When the law first came out, HHS had a good > >number of presentations in which they (mostly Bill Braithwaite) explained > >that HIPAA mandated the health plans to accept standard transactions, but, > >technically speaking, did not require the health plans to discontinue non > >standard transactions. But since the providers are required to only send > >standard transactions, there is nobody left the could actually send the > >non-standard transactions, therefore the HIPAA transactions become the only > >option. We did not have the NPRM on Transactions yet. > > > >The transactions final rule is still consistent, requiring payers to receive > >the standard transactions and providers to send the standard transactions. > >The addition in the final rule is that a covered entity can only conduct > >standard transactions with another covered entity. So, even though the > >health plans can, technically, still receive NSF/UB82, they can't receive > >them from providers. > > > >The problem comes, in my opinion, from the answer to the FAQ: > > > >"Assigning responsibility for non-compliant transactions (11/2/2001) > >Question: If a health care provider electronically conducts a non-compliant > >transaction (transmits an old National Standard Format or a proprietary > >format) directly to a health plan after the transaction regulation compliance > >date, and the health plan accepts and processes the non-compliant > >transaction, who is in violation of the regulation? Is it the health care > >provider or the health plan? > > > >Does the acceptance and processing of a non-compliant transaction by a health > >plan from a health care provider constitute a violative trading partner > >agreement between the health plan and the health care provider? > > > >Answer: If a health care provider electronically conducts a non-standard > >transaction with a health plan after the transaction regulation compliance > >date, the health care provider and the health plan are both out of > >compliance. Section 162.923(a) of the rule requires a covered entity > >conducting an electronic transaction for which a standard has been adopted > >with another covered entity to conduct it as a standard transaction. > > > >If the health plan by agreement required the health care provider to conduct > >non-standard electronic transactions, such agreement would not by its terms > >violate section 162.915. However, if either party were to abide by the > >agreement, they would be out of compliance with section 162.923(a), for the > >reason stated above." > > > >As I understand it, the question was clearly asked in the context of > >transmitting NSF or a proprietary format. The answer, however, is most of > >the time interpreted as making the receiver responsible for detecting the > >compliance or non-compliance of the sender. And it seems to indicate that if > >the receiver takes a non-compliant transaction, the receiver is out of > >compliance. > > > >However, I think this is an unreasonable burden on the receiver of a > >presumably HIPAA transaction. A transaction sent mostly according to the > >HIPAA Implementation Guides but that has an error in it, perhaps an invalid > >CPT or ICD9 code, or something of that nature, should not send the receiver > >into non-compliance. This is very different from the receiver accepting NSF, > >UB82, or proprietary formats. > > > >I think that the sender needs to make a reasonable effort to send only > >compliant transactions. The receiver needs to make a reasonable effort to > >receive only compliant transactions. And if a non-compliant transaction is > >received, the receiver response rejecting or denying the transaction needs to > >be "reasonably compliant". But perfection is probably an unrealistic goal. > > > >For example: A claim for a newborn that has not yet received a first name > >could be sent with "Baby" or with nothing as the first name. The payer, upon > >receiving a claim without a first name should be able to suspend it to > >research coverage, and upon adjudication, return a response without being > >penalized. For example, the 277 or 835 should go back without a first name > >if the original claim did not have a first name. This should not penalize > >the payer as "non compliant". Just my personal opinion. > > > >We run the risk of putting so much of the compliance burden on one of the > >parties that the situation becomes unreasonable. It is impossible to have > >total perfection. And to put the burden of perfection on one of the trading > >partners (the payer) is going to create big implementation problems. > > > >Just my opinion. I hope it is consistent with what I have said in the past... > > > >Kepa > > > > > > > > > > > >On Thursday 27 June 2002 02:06 pm, [EMAIL PROTECTED] wrote: > > > Kepa, > > > > > > Have we not been around this block before? I think the regulations state > > > that both parties are obligated to conduct a standard transaction. I'm not > > > trying to split hairs, but I interpret "conduct" to mean "transmit". The > > > conduct of electronic transactions occurs between two parties, covered > > > entities in this case. Therefore, both sender and receiver are obligated > > > to abide by the standard. So how do you reason that the receiver has an > > > out in not validating data they won't use? Are you saying they have an out > > > or are you saying that the risk to validate codes is up to the receiver? > > > > > > The onus on the sender is to generate a compliant transaction WITH > > > compliant codes (medical and non-medical). The receiver has choices > > > depending on the amount of risk s/he is willing to accept. The choices run > > > the gamut from not running compliance and validity checks (faith) to > > > validating every last detail of the transaction. At the very least I would > > > suspect all receivers are going to run level one and two compliance checks > > > to make sure they can transform the X12 to formats they can use. > > > > > > But what about code set compliance? Does you or others have any insights > > > or recommendations to share? I take a strict interpretation of the > > > regulations and implementation guides. If an element requires data from a > > > specific named code source, then only values from that code source are > > > acceptable. If, as a receiver of a transaction, I choose to validate > > > elements containing code source data and my system finds codes not in those > > > sets, I must reject the transaction regardless of my business need to > > > process the data or not. Non-standard codes would render the transaction > > > non-standard. If I intend to store all transactions regardless of whether > > > I use all the data contained in them, then by storing them or accepting > > > them into my system, I am saying that they are compliant. > > > > > > It may not have been anyone's intention to put the burden of compliance on > > > transaction receivers, but the way that the regulations are structured, how > > > can one be sure that what one is getting is compliant with respect to > > > anything beyond level two compliance and going through a certification > > > process? > > > > > > I don't disagree with you. Your comment, however, throws me for a loop > > > considering everything I've read from you for the past year. I would > > > certainly respect your opinion and logic as it applies to this situation. > > > And thanks for all of your efforts in this complicated arena. > > > > > > Roger Wolkoff > > > Information Systems Analyst > > > WEA Trust > > > 45 Nob Hill Road > > > Madison, WI 53713 > > > (608) 661-6688 > > > [EMAIL PROTECTED] > > > www.weatrust.com > > > > > > > > > > > > > > Kepa > > Zubeldia > > > > > <Kepa.Zubeldia@cl To: > ><[EMAIL PROTECTED]>, "Robbi McClane" > ><[EMAIL PROTECTED]> > > > aredi.com> cc: > > > > > Subject: Re: Level of > >Validation needed for Inbound Claims... > > > 06/26/2002 > > 09:00 > > > > > PM > > > > > Please respond > > to > > > > > transactions > > > > > > > > > > > > > > > > > > > > > > > > > > > Robbi, > > > > Here is my understanding. The receiver needs to be able to accept HIPAA > > > compliant transactions. So you need to be able to receive transactions > > > with > > > both CPT and HCPCS codes. You also need to be able to accept dialysis > > > transactions involving EPO and having the Patient Weight. Even if you do > > > not > > > use the Patient Weight in your processing. If you don't use it, that is > > > not > > > a reason to reject the transaction. After accepting the transaction, > > > whether > > > you use the Patient Weight or not is your business decision. > > > > > > But, let's say that you get a transaction with the Patient Weight in it, > > > and > > > your translator discards the Patient Weight. Later, in adjudicating the > > > transaction you find that you need the patient weight. At that point, > > > since > > > the original claim already had it, you should not go back to the provider > > > asking for the patient weight. Perhaps instead of just discarding what you > > > > > > don't need you should store it somewhere. > > > > > > As far as your validating your trading partners transactions for compliance > > > > > > and rejecting transactions because they are "not compliant" in an area that > > > > > > is not of interest to you... I still can't find where in the Final Rule it > > > says that you need to do that. There is an HHS FAQ that seems to indicate > > > that you are not allowed to receive and process a non-compliant > > > transaction, > > > but I don't think that it was HHS' intention to put all the burden of > > > compliance on the receiver of the transaction. > > > > > > Other opinions? > > > > > > Kepa > > > > > > > > > > > > On Tuesday 25 June 2002 12:22 pm, Robbi McClane wrote: > > > > There have been similar individual questions posted on various mail > > > lists > > > which are related and beg the bigger question in regards to compliance of > > > INBOUND transactions.. > > > > > > > > Is the RECEIVER of an HIPAA transaction OBLIGATED to perform all levels > > > of > > > validations - beyond X12 and HIPAA syntax in order to be considered in > > > COMPLIANCE? Specifically, in regards to two areas: > > > > > > > > 1) external code sets - both medical and non-medical (e.g. postal codes, > > > HIN > > > numbers, etc.) > > > > and > > > > 2) product or service specific (e.g. Patient Weight is required on > > > claims > > > invoking EPO for patients on dialysis) > > > > > > > > My personal interpretation of is that I must be able to RECEIVE and > > > PROCESS > > > codes from the external code sets - which is not necessarily the same as > > > validating - for example, as long as my adjudication system can accept a > > > code > > > but doesn't utilize and therefore doesn't kick it out if it is incorrect > > > that > > > I am okay... - but I'm not sure if the same logic can apply to #2 (e.g. I > > > don't require patient weight...) > > > > > > > > any thoughts? differences of opinion?? > > > > > > > > > ********************************************************************** > > > 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. > > > > > > > > > > > > > > > > > > > > > >-- > >This email contains confidential information intended only for the named > >addressee(s). Any use, distribution, copying or disclosure by any other > >person is strictly prohibited. > > > > > >********************************************************************** > >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. > > Christopher J. Feahr, OD > http://visiondatastandard.org > [EMAIL PROTECTED] > Cell/Pager: 707-529-2268 > > > > ********************************************************************** > 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. > > -- This email contains confidential information intended only for the named addressee(s). Any use, distribution, copying or disclosure by any other person is strictly prohibited. ********************************************************************** 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. ********************************************************************** 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.
