Splitting a claim that outgrows the 837P

A behavioural-health encounter arrives from the practice with sixty-three service lines across eighteen distinct diagnoses. It is a legitimate encounter: a day programme, several clinicians, a patient with a long problem list. The biller submits it. The clearinghouse rejects it before a payer ever sees it.

Nothing is wrong with the encounter. The problem is the envelope.

The limits, and where they come from

The 005010X222A1 professional claim carries its diagnoses in a single HI segment, and that segment holds twelve: the principal in HI01, up to eleven more in HI02 through HI12. Each service line points at the diagnoses that justify it through SV107, a composite that holds at most four pointers. The implementation guide caps a claim at fifty service lines.

These are not configurable. X12 has been asked directly whether there is somewhere else to put the overflow, and the answer is that no segment is designated for diagnosis codes beyond the single repeat of HI. It has also confirmed that the number of pointers may not exceed the number of codes actually sent — you cannot point at a diagnosis you did not transmit.

So an encounter that needs more than twelve diagnoses or more than fifty lines cannot be expressed as one claim. It has to become several.

Worth being precise about what kind of rule this is. Splitting is not described in the implementation guide. It is what clearinghouses and payers tell you to do, which means the details — how they expect the splits to be identified, whether they will treat them as duplicates — belong to your trading partner, not to the standard. Read the companion guide before you write the code.

The split that looks right and is not

The obvious implementation is a slice. Take the first fifty lines and the first twelve diagnoses; put the rest on a second claim. It is a few lines of code and it is wrong in a way that will not show up in testing.

SV107 does not reference a diagnosis code. It references a position in that claim's HI segment. A pointer of 3 means "the third diagnosis on this claim", and nothing more.

Consider a line on the second claim that originally pointed at position 2, say F33.41. On the second claim, position 2 is now whatever diagnosis happens to have landed there — Z79.899, perhaps. The pointer is in range. The claim is syntactically valid. It passes the clearinghouse, reaches the payer, and is adjudicated against a diagnosis the clinician never associated with that service.

That is the failure worth dwelling on, because it does not announce itself. A dangling pointer that exceeds the diagnosis count gets rejected, and a rejection is a gift: somebody notices. A pointer that has silently come to mean something else gets paid, and the error surfaces months later in an audit, if at all.

It is a packing problem, not a slice

Think in terms of lines rather than a global diagnosis list. Every service line carries its own small set of diagnoses — at most four, by the pointer limit. The question is not "which twelve diagnoses do we keep" but which lines can travel together.

A claim is valid if the lines on it reference no more than twelve distinct diagnoses between them, and there are no more than fifty of them. That is bin packing with two constraints, and the second is the awkward one: it is not additive. Two lines that share diagnoses cost less together than apart, so the order in which you pack decides how many claims you end up with.

A greedy pass is enough at this scale — encounters run to tens of lines, not thousands:

1. Group lines that carry identical diagnosis sets. They will never benefit from being separated, and grouping them first shrinks the problem.
2. Open a claim with the group carrying the largest diagnosis set.
3. Repeatedly add whichever remaining group adds the fewest new diagnoses to the claim in progress, while the line count still fits.
4. When nothing more fits, close the claim and open another.

Choosing by marginal diagnosis cost rather than by input order is what keeps the claim count down. A single line can never be unplaceable — it carries at most four diagnoses — so the loop always terminates.

Rebuilding each claim

Packing decides which lines go where. Each claim then has to be rebuilt as if it had always been its own claim.

Collect the diagnoses actually referenced by that claim's lines. Not the first twelve of the original list — the ones its own lines point at.

Decide what to do about the principal. Every claim needs a principal diagnosis in HI01, and the original principal may not be referenced by every group of lines. Carrying it onto each split as HI01 keeps the claims clinically coherent and matches what adjudicators expect, at the cost of one of your twelve slots. Transmitting a diagnosis that no line points at is permitted; the prohibition runs the other way. This is a judgement call and it should be a documented one.

Renumber the pointers. Build a map from the old position to the new one for that claim, and rewrite every SV107 through it. This is the step the naive implementation skips.

Recompute CLM02. The total claim charge is the sum of SV102 across that claim's lines, not the encounter's total.

Assign claim identifiers. CLM01 has to be unique per claim or the payer may treat the second as a duplicate of the first, and it has to trace back to one encounter or your own reporting falls apart. A derived scheme — the encounter identifier with a suffix — gives you both, provided you keep the mapping.

A worked fragment

Before, as a single claim that will be rejected:

CLM*ENC10432*4125***11:B:1*Y*A*Y*Y~
HI*ABK:F3341*ABF:F1120*ABF:Z79899*ABF:I10*ABF:F411 ... (eighteen in all)
LX*1~
SV1*HC:90834*125*UN*1***1:3~
LX*2~
SV1*HC:90853*85*UN*1***2:4~

After, as the first of several, with pointers rewritten against its own HI:

CLM*ENC10432-01*1250***11:B:1*Y*A*Y*Y~
HI*ABK:F3341*ABF:Z79899~
LX*1~
SV1*HC:90834*125*UN*1***1:2~

The line still points at F33.41 and Z79.899. Only the numbers changed.

What bites once it is live

Duplicate detection at the payer. Same patient, same date of service, same billing provider, arriving twice within minutes. The lines are disjoint, so the splits are not duplicates — but payers vary in how they decide that, and some will need the submissions spaced or identified in a particular way. This is the first thing to confirm in a companion guide.

The remittance comes back in pieces. One encounter is now several CLP segments, possibly on different days, possibly under separate remittances. Payment posting has to reassemble them, and every question you ask about an encounter — is it paid, what is outstanding, what does the patient owe — now spans claims. Splitting is not only a submission problem. It creates a reconciliation problem downstream, and that is the part people underestimate.

Corrections apply to a split, not an encounter. A corrected claim replaces one of them and references that claim's own payer control number. Resubmitting the encounter as a whole will not do what you want.

Testing it

Example-based tests will not catch the pointer bug, because the bug produces output that looks fine. Generate encounters instead, and assert properties of the result:

• The lines across all claims are exactly the original lines — none lost, none duplicated.
• The sum of CLM02 equals the original total charge.
• For every line, the set of diagnosis _codes_ it points at after the split is identical to the set it pointed at before. This is the assertion that matters. It checks meaning rather than position, and it is the only one that fails when the remap is wrong.
• No claim exceeds twelve diagnoses or fifty lines.
• No pointer exceeds the diagnosis count on its own claim.

The third of those is worth writing before the algorithm.

What we do

Our platform splits on the way out, holds the mapping from encounter to claims, and reassembles on the way back in, so posting and reporting still answer questions about the encounter rather than about the fragments. The split is a transport detail. Nobody using the system should have to think about it.