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


failure on sbr field 837p


I'm trying to validate some 837p in order to get ready to generate new ones for the same provider. I ran into an issue where the parser is quitting on SBR. The same invoices pass other parsers/validators, and are valid according to our payer. Luckily I have a sample invoice that throws the same issues.

here's a link

I posted this in the discussion, wasn't sure if anyone saw it. I need to resolve this, I'm not sure if I need to change something in the xml document... please advise.

(i attached the x12 to this post.)

file attachments

Closed Sep 30, 2016 at 10:52 PM by DonZoeggerle
This has been resolved in version 6.7.5


jleach wrote Apr 15, 2015 at 6:05 PM

Hi, I had an interesting development. When examining some of my transactions, a few had newlines present. One of them i tested, and it passed fine. (which is why i posted this, many work, others quit on SBR). I removed them, and the software i used (notepad++) left some spaces in the document. I tried again, before removing the spaces, and it failed. removed the extra spaces (searched '~ ' replaced with '~'), and it passed. I don't know how helpful that will be... but thanks for any info anyone has. I need to get this to work for these guys.

DonZoeggerle wrote Apr 15, 2015 at 10:17 PM


I played with the file you attached and to me it looks incorrect per the definition. What happens is that the second SBR is searched after the HL, which was found in G_TS837_2000C instead of G_TS837_2000B. This is the expected behavior IMHO, because it would always skip G_TS837_2000C.

In case you won't be using G_TS837_2000C at all, a quick solution would be to open the class file 837_P.cs and comment out the reference to G_TS837_2000C on line 21639 and the public property, e.g.

[System.CodeDom.Compiler.GeneratedCodeAttribute("Xsd2Code", "")]
[System.Xml.Serialization.XmlTypeAttribute(AnonymousType=true, Namespace="")]
[System.Xml.Serialization.XmlRootAttribute(Namespace="", IsNullable=false)]
public partial class G_TS837_2000B {

    private S_HL_SubscriberHierarchicalLevel s_HL_SubscriberHierarchicalLevelField;

    private S_SBR_SubscriberInformation s_SBR_SubscriberInformationField;

    private S_PAT_PatientInformation s_PAT_PatientInformationField;

    private A_NM1_3 a_NM1_3Field;

    private List<G_TS837_2300> g_TS837_2300Field;

    //private List<G_TS837_2000C> g_TS837_2000CField;

    public S_HL_SubscriberHierarchicalLevel S_HL_SubscriberHierarchicalLevel {
        get {
            return this.s_HL_SubscriberHierarchicalLevelField;
        set {
            this.s_HL_SubscriberHierarchicalLevelField = value;

    public S_SBR_SubscriberInformation S_SBR_SubscriberInformation {
        get {
            return this.s_SBR_SubscriberInformationField;
        set {
            this.s_SBR_SubscriberInformationField = value;

    public S_PAT_PatientInformation S_PAT_PatientInformation {
        get {
            return this.s_PAT_PatientInformationField;
        set {
            this.s_PAT_PatientInformationField = value;

    public A_NM1_3 A_NM1_3 {
        get {
            return this.a_NM1_3Field;
        set {
            this.a_NM1_3Field = value;

    [System.Xml.Serialization.XmlElementAttribute("G_TS837_2300", Order=4)]
    public List<G_TS837_2300> G_TS837_2300 {
        get {
            return this.g_TS837_2300Field;
        set {
            this.g_TS837_2300Field = value;

    //[System.Xml.Serialization.XmlElementAttribute("G_TS837_2000C", Order=5)]
    //public List<G_TS837_2000C> G_TS837_2000C {
    //    get {
    //        return this.g_TS837_2000CField;
    //    }
    //    set {
    //        this.g_TS837_2000CField = value;
    //    }
This way it properly found the correct HL and then the SBR. Hope it helps.


jleach wrote Apr 16, 2015 at 5:23 PM

I'm looking at the NUCC 1500 claim form map to the X12N Health Care Claim Professional 837, and it indicates using loop 2000C. This is for the 837p IG from CMS, suggests the same information you provided, that the 2000C is not used. In fact, it states that the fields PATIENT HIERARCHICAL LEVEL, and PATIENT INFORMATION, will cause it to fail. So I will try this solution, and see if it validates the claim. Thank you for your advice, I will give another update as soon as i can. Look forward to getting more involved in x12 processing, thanks to this library!

jleach wrote Apr 16, 2015 at 6:16 PM

About the class G_TS837_2000C in 837_P.cs, Should I comment that out as well? I need to generate the claims by reading from db, creating x12 from service data, and then validate it. I noticed that there is still a 2000c object when I go to use the object. Ideas?

jleach wrote Apr 16, 2015 at 8:20 PM

The file passes now, so that's a good sign. I didn't comment out the class in the cs file, only the section you suggested. Still trying to discover the best way to generate a test document. The full suite of fields required doesn't seem to be fully delineated in the Supplementary IG from MaineCare.

jleach wrote Apr 20, 2015 at 9:36 PM

That's sorted, but now the parser is throwing up not finding D_143_1. The files i'm using are valid, they get paid. I'm trying to generate an x12 and I got as far as S_ST. I don't know what to do with these segments. I know i'm doing it wrong, but there's no indication. I created an XML file from one of my invoices and now i'm trying to feed it back through. same error.

jleach wrote Apr 20, 2015 at 9:48 PM

ok, stop the presses. My vs2013 was being wonky. I restarted the thing, and then it pulled the vaules for the enums. wierd, but resolved. thank you for this awesome library.

jleach wrote Apr 20, 2015 at 9:50 PM

well maybe not. if i don't resolve by the time you get back awesome. otherwise, please help?

DonZoeggerle wrote Sep 30, 2016 at 10:52 PM

This has been resolved in version 6.7.5

wrote Sep 30, 2016 at 10:52 PM