Brian, This a a combination of a few different issues.
In the HIPAA guides there is nothing "optional". An element is either "required", "not used", or "situational". The definition for the Industry Usage is at the end of the Section 3.1 of each guide. For a "Situational" element it says: "SITUATIONAL. The use of this element varies, depending on data content and business context. The defining rule is generally documented in a syntax or usage note attached to the item.* The item should be used whenever the situation defined in the note is true; otherwise the item should not be used. *NOTE If no rule appears in the notes, the item should be sent if the data is available to the sender." So, the question is: What is the "situation" defined for that SBR04 element? If the situation is true, the element becomes "required". If the situation is false, the element becomes "not used". In that specific element, the situation becomes "required" when no group number is reported in SBR03. There has been, and continues to be, much debate over the word "should" in the text that I quoted. The question is this: is "should" the same as "must" but in a polite form, or is "should" somehow different from "must". Either the industry decides a consensus meaning of "should" or HHS decides this one at some point. For now there is not a consensus yet. There is a letter of interpretation from X12N/TG8 (Insurance/Architecture) that has not been endorsed or approved by X12N/TG2 (Insurance/Healthcare) that discusses this topic to a great extent. If you have not seen it yet, you can get it from http://www.x12.org/x12org/subcommittees/X12N/N0800_Opinion_Data_Element.PDF Just in case, the users of the Claredi system can choose two different sets of testing rules: one set applies the strict definition of "should means must" and the other set applies the more relaxed definition of "should is not really a requirement at all" as per the TG8 letter. We don't take a position one way or the other and the testers make that choice. If and when this issue is resolved, we may (will? :-) have to limit this choice. But there is another part of the TG8 letter of interpretation and the definition of situational that I quoted above, that says that when there is no condition specified, the sending of the data is an option of the SENDER. What we are seeing is that the RECEIVER of the data is making these decisions instead of leaving it up to the sender. This flies against the X12 compliance recommendations from X12C, against the text quoted above, and against some of the concepts (minimum data set) described in the transaction final rule. However, some of the receivers feel free to require the sender to obtain the missing data, just because the receiver needs it. When the guides were written it was contemplated that if the data was not available, the receiver would just have to do without it. How and when were the tables turned is hard to explain. Now, going back to your particular SBR03/04 issue... This is a problem with the implementation guide, since there are some cases (Medicare, Medicaid) where neither group number nor group name is available. As a temporary solution you should just put the word "Medicare" in SBR04 to keep the syntax checkers happy. This will be corrected in future implementation guides. I hope this helps clarify the issue. I do not wish to start a long series of emails over the merits of the definition of "situational" in the guides. There are so many problems caused by this definition that X12N/TG4 has issued new guidelines to the Implementation Guide authors so this scenario can be avoided in future guides. The new guidelines include the fact that the "situation" has to be defined with words with very precise meaning, and that when the situation is false, it must specify that either the data must not be sent, or the data is sent at the option of the submitter. We hope that the future guides will resolve these ambiguities. Kepa On Tuesday 22 October 2002 08:42 am, Young, Brian wrote: > Morning all, > > Question from an 837I tester... I have been testing with a few of CMS's FIs > and have been getting different information with each test. Granted I am > using data from providers that the FI would serve; but, are we still hitting > a moving target? I am getting conflicting information about when to use > what elements. And these testing environments one would expect to be the > same. They are all CMS FIs. > > > Case in point: > > I have tested with UGS and AdminaStar. Both tests have cleared front end > edits and have received approval from AdminaStar for the transmission > elements described above. In these 2 elements I do not supply any data as > they are optional fields. I supply the Medicare policy number in the NM109 > field as described in the SBR03 notes. > > The kicker on the latest testing, the intermediary says that one of these 2 > fields is required. They are indicating that if SBR03 is empty then SBR04 > must be filled. The question I have is, is this true? I read the notes > from SBR04 and it reads "Used only when no group number is reported in > SBR03." Now I'm not sure about their interpretation of English, but I dont > see the words "must be used if" in that sentence. Am I wrong? How do I > push back on this? > > Like I said... I feel like I have been trying to hit a moving target. And > if the target is moving... then my program must move too. Now do I go back > and retest? Granted its only one now... but later it could be dozens. > > Please excuse the small rant... but could use some help. > > Thx, > > BCY > > Brian C. Young > Accu-Med Services Inc. > An OmniCare Company > Milford, OH 45150 > 513.831.1207 ********************************************************************** 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.
