This project has moved and is read-only. For the latest updates, please go here.

Message: There is an error in XML document (826, 142)

Sep 11, 2013 at 3:35 PM

How can I troubleshoot this kind of error?

Message: There is an error in XML document (826, 142)

I assume the numbers 826 & 142 are significant. But I have no idea what they mean.
Sep 11, 2013 at 3:40 PM
Do you have the full stack trace?

This is most likely using the claim parser which transforms the raw X12 into a ClaimDocument.
And it is most likely happening when you are trying to deserialize it into the ClaimDocument object model.
When you break on the the line that throws this error you should be able to inspect the xml. The 826 and 142 are the row and column where the error is occurring.

Many times this will happen because of illegal characters that need to be escaped, or a date field that is an invalid date value.
Sep 11, 2013 at 4:41 PM
I have run the program in visual studio with the debugger. The program execution "broke" at the line

document = transformationService.Transform837ToClaimDocument(interchange)

The full error is;

System.InvalidOperationException occurred
Message=There is an error in XML document (826, 142).
   at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, String encodingStyle, XmlDeserializationEvents events)
   at System.Xml.Serialization.XmlSerializer.Deserialize(TextReader textReader)
   at OopFactory.X12.Hipaa.Claims.ClaimDocument.Deserialize(String xml)
   at OopFactory.X12.Hipaa.Claims.Services.ClaimTransformationService.Transform837ToClaimDocument(Interchange interchange)
   at ImportClaimsToDB.Main.Main(String[] args) in I:\FCDSApps\ClaimsProcessor\ImportClaimsToDB\ImportClaimsToDB\Main.vb:line 169
InnerException: System.FormatException
   Message=Input string was not in a correct format.
        at System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal)
        at System.Number.ParseDecimal(String value, NumberStyles options, NumberFormatInfo numfmt)
        at System.Xml.XmlConvert.ToDecimal(String s)
        at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderClaimDocument.Read40_Claim(Boolean isNullable, Boolean checkType)
        at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderClaimDocument.Read41_ClaimDocument(Boolean isNullable, Boolean checkType)
        at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderClaimDocument.Read42_ClaimDocument()
I cannot find anything in the variables that looks like a traditional XML structure to inspect.

How do I proceed?
Sep 11, 2013 at 6:48 PM
public ClaimDocument Transform837ToClaimDocument(Interchange interchange)
            var xml = interchange.Serialize();

            var transformStream = Assembly.GetExecutingAssembly().GetManifestResourceStream("OopFactory.X12.Hipaa.Claims.Services.Xsl.X12-837-To-ClaimDocument.xslt");

            var transform = new XslCompiledTransform();
            if (transformStream != null) transform.Load(XmlReader.Create(transformStream));

            var outputStream = new MemoryStream();

            transform.Transform(XmlReader.Create(new StringReader(xml)), new XsltArgumentList(), outputStream);
            outputStream.Position = 0;
            xml = new StreamReader(outputStream).ReadToEnd();

            return ClaimDocument.Deserialize(xml);
In the code above the xml variable that passes into the Deserialize method at the last step is where you can expect for a wrong data type.
Sep 11, 2013 at 10:51 PM
Took me a while, but I did get some xml out. May not be the right xml. The beginning of the xml is;
<?xml version=\"1.0\"?>
<Interchange segment-terminator=\"~\" element-separator=\"*\" sub-element-separator=\":\">
    <!--Author Information Qualifier-->
    <ISA01>00<!--No Authorization Information Present--></ISA01>
    <!--Author Information-->
    <ISA02>          </ISA02>
    <!--Security Information Qualifer-->
    <ISA03>00<!--No Security Information Present--></ISA03>
    <!--Security Information-->
    <ISA04>          </ISA04>
    <!--Interchange ID Qualifier-->
    <ISA05>ZZ<!--Mutually Defined--></ISA05>
    <!--Interchange Sender ID-->
    <ISA06>800222771      </ISA06>
    <!--Interchange ID Qualifier-->
    <ISA07>ZZ<!--Mutually Defined--></ISA07>
    <!--Interchange Receiver ID-->
    <ISA08>133052274      </ISA08>
    <!--Interchange Date-->
    <!--Interchange Time-->
    <!--Inter Control Standards Identifier-->
    <!--Inter Control Version Number-->
    <!--Inter Control Number-->
    <!--Acknowlegment Requested-->
    <ISA14>0<!--No Acknowledgment Requested--></ISA14>
    <!--Usage Indicator-->
    <ISA15>P<!--Production Data--></ISA15>
    <!--Component Element Separator-->
      <ISA1601 />
      <ISA1602 />
When I get to around line 826 of that xml, it does not have any lines that are close to 142 bytes long.

The xml above came from the routine;
        public virtual string Serialize(bool suppressComments)
            MemoryStream memoryStream = new MemoryStream();

            memoryStream.Seek(0, System.IO.SeekOrigin.Begin);
            StreamReader streamReader = new StreamReader(memoryStream);
            string xml = streamReader.ReadToEnd();

            if (suppressComments)
                XmlDocument doc = new XmlDocument();
                doc.PreserveWhitespace = true;

                xml = doc.OuterXml;
            return xml;
in the module Interchange.cs.

Where do I go from here? I can't seem to get the debugger to go into the module you mentioned.
Sep 11, 2013 at 11:21 PM
OK, I figured out that I needed to compile the .Hippaa module and put the dll & pdb file in the lib folder as well.

OK lines around 826 look like this;
    <Identification Qualifier=\"FY\" Id=\"NOCD\">Claim Office Number</Identification>
  <Claim Version=\"005010X222A1\" Type=\"Professional\" TransactionCode=\"0001\" ClaimNumber=\"\" BillTypeCode=\"111\" PatientControlNumber=\"99536CVD\" TotalClaimChargeAmount=\"\" ProviderSignatureOnFile=\"Y\" ProviderAcceptAssignmentCode=\"A\" BenefitsAssignmentCertificationIndicator=\"Y\" ReleaseOfInformationCode=\"Y\" MedicalRecordNumber=\"99536\">
    <ServiceLocationInfo FacilityCode=\"11\" Qualifier=\"B\" FrequencyTypeCode=\"1\" />
The long line is of course line 826. I cannot see an issue at position 142 irrespective of the "\"s but maybe you recognize something I don't.
Sep 12, 2013 at 2:43 PM

This error is happening on all files from a specific vendor, and I need to tell them what the issue is. Unfortunately I don't see the issue. Hopefully you can spot it. I will be happy to get you any additional info you may require.

There may be some fits & starts as I work in 3 (at least) different development environments, and .NET is not my most frequent.
Sep 12, 2013 at 2:47 PM
The line you copied is not the problem, it only has text fields. The problem is usually with a date, integer or decimal field. Try the line before and after or perhaps I got it swapped and it's line 142 at column 826.
I see it happen most often with Date fields. If you figure out what the problem is, I am thinking of having the xslt suppress bad dates and write to another string attribute so you can still get to it and report on it.
Sep 12, 2013 at 3:12 PM
Should dates be yyyy-mm-dd?
Sep 12, 2013 at 3:45 PM
In the raw x12 file there are no dashes.
Each date field will indicate the format expected. Most places it is YYYYMMDD, but a few might be YYMMDD.
Some place have a date range YYYYMMDDYYYYMMDD.
Sep 12, 2013 at 4:02 PM
The dates in the XML do have dashes, though.

I saved the xml captured from the breakpoint, after replacing all "\r\n" with real returns, and replacing all "\" with "".

I then downloaded CAM Template Editor ( and when I try to open the xml file I created it gives the following error;
org.jdom.input.JDOMParseException: Error on line 891 of document file:/I:/FCDSApps/ClaimsProcessor/test-file.xml: The element type "BillingInfo" must be terminated by the matching end-tag "</BillingInfo>".
And when I look in the original file, it does not have the close BillingInfo tag that is opened at 891.

Is this a potential problem with the code, or did I do something wrong in extracting the xml?
Sep 12, 2013 at 4:06 PM
You should not have to do it that way. When you click on the magnifying glass next to the xml variable it should present it as xml. The closing tag should be </ClaimDocument>.
Knowing that the dates have dashes in your raw X12 file is probably the problem. Has this vendor sent these through a clearinghouse or are they sending them to you as test files directly? Any clearinghouse would have rejected these files for the same reason for not following x12 specifications.
Sep 12, 2013 at 4:27 PM
Thanks for that tip. It made the false error above go away. It will also help me in the future.

I believe I may know what the problem is. Is it possible that your xml structure requires that "TotalClaimChargeAmount" must contain a value. On the line in question , at position 142, that attribute has a value of "", and every other one in the file has a number.
Sep 12, 2013 at 4:29 PM
Okay cool, I will check the 837 to see if that's a required field, if so then that would be reason. If not then I'll modify so that this can sum up from the lines.
Sep 13, 2013 at 2:26 PM
Please let me know if I need to tell the vendor to fix their data.

If possible, especially since I do not care about financial stuff, I would like to be able to default these line items to 0 when null. My program actually wipes out all financial data when we store it because we are only interested in diagnosis and treatment data.
Sep 14, 2013 at 2:38 AM
I just double checkd the 837P and 837I implementation guides and both list CLM02 as a required field.
The generic X12 837 spec list it as optional. I think it is within your bounds to tell your vender they are expected to follow the 837P/837I guides, but in case you don't get that change in a timely manner, I will change the xslt to turn blank CLM02 values into zero.
Sep 14, 2013 at 2:57 AM
I have released version 3.0.6 which will compensate for the CLM02 being blank.
Sep 18, 2013 at 6:00 PM

Sorry for taking a few days to get back to you. The new version allowed all of this vendor's data to be imported properly. Thank you for the quick fix.

When asked why they put nulls in that field they said that the insurance company provides certain drugs to them directly, and they cannot charge for them. When I asked why couldn't they put in a 0, they said it would be a PITA to get their software developer to make the change.

Us evil software developers, are always the problem.