2

In some of our BizTalk 2009 development environments, when attempting to process a HIPPA X12 file, 4010 270 file type, any element defined in the schema to be type X12_AN is throwing an "Invalid character in data element" error; e.g. NM103__InformationReceiverLastOrOrganizationName. The invalid character that it is complaining about is the letter "U". It's only the capital letter "U" and not a lowercase "u".

This error only presents in our development environments that exist in Citrix VDIs running Windows Server 2003 R2 Enterprise X64 Edition. The instance of BizTalk Server 2009 installed on the VDIs has been updated with the most recent hotfix.

So far, I tried everything I can think of from converting the input file encoding, to retyping the entire file manually. I recompiled and deployed both the schemas and maps. I even enabling and disabling EDI validation at the party level. Nothing seems to be working.

Has anyone seen this type of error before? Is there any way to modify or override the character set that is used for element validation in BizTalk?

Any information that you can offer would be greatly appreciated!

dramatix01
  • 65
  • 7

2 Answers2

1

It looks like you have a couple of different issues here. I can't speak to the differences (implied by your post) between your Dev and Production environments.

As to the rest:

Yes, you can modify the X12 Validation. I don't have it in front of me but I believe you can just turn it off completely (if that's what you want). Otherwise, you have to (essentially) create a custom 270 schema that allows the character (you can even do this to make elements that would otherwise be invalid valid), and then use that custom schema for any partner that hits that validation rule.

What I've always done is to modify the incoming file: send it through a regex that will change that character in that field to a lowercase 'u'. As long as you're keeping a copy of the original (unedited) message, and you're not changing any actual data values, you won't run into any HIPAA regs.

I would also encourage you to go through the offending files with the proverbial fine-toothed comb. Usually (not always) there is something else that is actually causing the error, but it only manifests noticeably in circumstance X (in your case, a capital U in your NM103).

AllenG
  • 8,112
  • 29
  • 40
  • Thanks for your quick response. Unfortunately for our purposes we cannot disable validation completely. Validation needs to be enabled in order to generate 997 acknowledgements which we need to send to some trading partners. – dramatix01 Jul 13 '11 at 15:19
  • Then you're stuck with a custom schema to change that validation or modifying the incoming file. At least, I've never found a better option. – AllenG Jul 13 '11 at 15:24
  • For testing purposes we did replace the offending character and everything processed as expected, but I have yet to go through the remainder of the file to see if there are any other problems that could be causing this issue to manifest. – dramatix01 Jul 13 '11 at 15:29
  • After attempting everything you mentioned in your post above, I have not been able to fully rectify the issue. Your suggestions are very valid for troubleshooting issues like this, so I marked your post as answered based on the suggestion of replacing all instances of "U" with "u". Without making any changes to the schema or test files, the issue does not exist in our traditional development and production environments. This is only happening in a Windows Server 2003 64-bit VDI environment running the BizTalk 2009 64-bit service. – dramatix01 Jul 15 '11 at 18:44
  • At this point, I'd send all that data over to Microsoft. Look up your local Developer Evangelist and s/he can get you in touch with someone who can probably help you figure it out. – AllenG Jul 15 '11 at 18:46
1

Revisiting this issue after a couple of weeks I found the fix for this issue to be much simpler than expected.

We work in the the healthcare industry and are currently supporting HIPAA 4010 applications while actively upgrading those applications in our development environment to meet the HIPAA 5010 requirements. As such, this issue was caused in BizTalk when the party property "Use ISA11 as repetition separator" was CHECKED within the configuration of a party used only for 4010 development. Since the default ISA11 value for 4010 is "U", BizTalk reported that character as invalid everywhere it was found.

I hope this saves someone else a lot of headaches. It's fun to be reminded every now and then that you should always check the obvious, simple solutions first, even if you KNOW they're not the issue!

dramatix01
  • 65
  • 7