837 Claims

An 837 is hierarchical. Loop 1000A identifies the submitter, 1000B the receiver. Loop 2000A carries the billing provider, 2000B the subscriber, 2000C the patient when the patient is not the subscriber. Loop 2300 is the claim itself; 2400 carries the service lines.

Almost every structural rejection traces to a hierarchy error rather than a content error. The most common is the subscriber/patient distinction: when the patient is the subscriber, patient information belongs in loop 2000B and loop 2000C must not be present. When the patient is a dependent, 2000C is required. Systems that populate both, or populate 2000C unconditionally, generate rejections that look like data problems and are actually structural ones.

Understanding this matters because the rejection message a payer returns rarely says "your hierarchy is wrong." It says something narrower and less useful, and the correction is applied at the symptom.

They share a base standard, and the resemblance ends there. The 837P is built around a rendering provider and CPT/HCPCS procedure coding at the service line. The 837I is built around a facility, a type-of-bill code, revenue codes, occurrence and value codes, condition codes, and a statement-covers period.

The practical consequence is that institutional claims fail for reasons professional claims cannot. A missing or wrong type-of-bill, a revenue code that does not pair with the HCPCS submitted, an occurrence code date outside the statement period: none of these have a professional analogue. Organizations that treat 837I as "837P with different fields" find this out through denials.

837D adds a third structure again, with tooth numbers, surfaces, and oral cavity designations.

A claim passes through several gates and each one reports differently. The TA1 reports interchange-level problems: the envelope itself was malformed. The 999 (formerly 997) reports syntax: did the transaction conform to the X12 implementation guide. The 277CA (Claim Acknowledgment) reports the payer's front-end business edits: was the claim accepted for adjudication.

The 277CA is the one organizations most often under-use. A claim can pass the 999 cleanly and be rejected at 277CA for a payer-specific business reason. That claim is not in the payer's adjudication queue and nobody is working it, but the submitter's system may show it as "submitted." Claims that sit in this gap age silently until someone notices the AR.

Only after 277CA acceptance does adjudication occur, and only then does an 835 follow. The distinction between "we sent it," "it parsed," "they accepted it," and "they adjudicated it" is four different states, and collapsing them is a reliable way to lose money slowly.

• TA1: interchange envelope acknowledgment
• 999: syntax and implementation guide conformance
• 277CA: payer front-end business edit acceptance or rejection
• 835: adjudication result and payment explanation

The cost of a claim error scales with how late it is found. Caught at the point of submission, it is a correction. Caught at 999, it is a resubmission cycle. Caught at 277CA, it is a resubmission cycle plus aged AR. Caught at adjudication as a denial, it is a rework cycle, a possible appeal, and a timely-filing risk. Caught after timely filing has expired, it is a write-off.

Shift-left validation means enforcing implementation guide conformance and known payer edits at ingestion, before transmission, and returning the failure to the submitter while the claim is still in front of the person who can fix it.

PNT validates 837 transactions against the implementation guide and payer-specific edits at the boundary.

Validation and routing require reading the claim. They do not require keeping it. PNT authenticates, validates, translates where required, and routes the 837 to the payer, then retains no PHI at rest. The submitter's system remains the system of record, which it is in any case, since that is where a correction and resubmission originate.