3 Headers and Lines
Before writing a query against a claims table, finish this sentence: one row represents… If we cannot answer it precisely, we are not ready to count rows or sum dollars.
A claim has information that applies to the whole bill and repeating detail about the services or charges on that bill. We call these the header and the lines. In this chapter, we’ll use that structure to understand the grain of a claims dataset and avoid some of the most common errors in healthcare analytics.
3.1 The header describes the claim
The header contains information shared by the claim’s lines. Common examples include the patient identifier, billing provider, claim identifier, and total submitted charge. Institutional claims also carry information about the billing period, admission, and patient discharge status.
An adjudicated claims extract can add claim-level payment status, allowed and paid amounts, and processing dates. These are fields supplied by the payer or derived in the extract; they are not all fields from the provider’s original bill. Keeping that distinction in mind helps when reconciling submitted claims with remittance or payer data.
Header-level does not always mean a single value. A claim can contain an ordered list of diagnoses, several provider roles, or multiple occurrence codes. The important distinction is that these records belong to the claim as a whole unless the source explicitly associates them with a service line.
3.2 Lines describe billed services and charges
A line is a repeating item within a claim. Depending on the claim type, it can contain a procedure code, revenue code, modifiers, service dates, units, and charge amount. Adjudicated data may also provide line-level allowed amounts, payment amounts, and adjustment reasons.
The NUCC instructions describe professional service lines, including dates, place of service, procedures, diagnosis pointers, charges, units, and rendering-provider information. Institutional lines instead center on revenue-code detail and can also contain HCPCS codes, dates, units, and charges, as described in CMS’s institutional billing instructions.
A line does not necessarily represent one visit, one procedure, or one day. It may bill several units, span multiple dates, or describe a charge included in another payment. Units also have different meanings across services. Two units of a drug code and two units of a time-based therapy code cannot be added to produce a meaningful total of “services.”
3.3 Follow the dollars through a simple claim
Suppose a professional claim contains the following three lines. The services and amounts are illustrative.
| Claim | Line | Service | Billed | Allowed | Payer paid |
|---|---|---|---|---|---|
| A100 | 1 | Office evaluation | $150 | $90 | $70 |
| A100 | 2 | Laboratory service | $200 | $150 | $120 |
| A100 | 3 | Diagnostic service | $100 | $80 | $60 |
| Claim total | $450 | $320 | $250 |
Here the header totals equal the sums of the corresponding lines. That equality is part of this example’s data contract. In an actual feed, confirm whether the payer supplies a complete allocation to lines and whether claim-level adjustments are included.
Now suppose the payer delivers a flat file with one row per line and repeats the header paid amount on every row:
| Claim | Line | Line paid amount | Header paid amount |
|---|---|---|---|
| A100 | 1 | $70 | $250 |
| A100 | 2 | $120 | $250 |
| A100 | 3 | $60 | $250 |
Summing line_paid_amount gives $250. Summing header_paid_amount gives $750. Both columns contain accurate values; only one is additive at the table’s grain.
The solution is to aggregate each measure at the grain where it is defined. Use one header record per claim version for header totals. Use line amounts when they are truly line amounts. Do not use sum(distinct paid_amount) as a shortcut: two unrelated claims can have the same payment, and that expression would count it only once.
If a source supplies only a header payment, we can report the payer’s payment for the claim. We cannot directly observe what the payer paid for each line. Dividing the total equally or allocating it by charges creates an estimate. Such an allocation may be useful, but it needs an explicit method and should remain distinguishable from a reported payment.
3.4 Claims, versions, and lines need different identities
A typical medical claims dataset has at least three levels of identity:
| Level | What it identifies | Example |
|---|---|---|
| Claim family | The original bill and related corrections or reversals | A100 and its replacements |
| Claim version or transaction | A particular submission, adjudicated state, or financial event | The second adjudicated version of A100 |
| Claim line | A particular item within that version or transaction | Line 2 on that version |
The source may represent these levels with one identifier, several identifiers, or a combination of identifiers and sequence fields. Include the source or payer context in the key: claim number A100 from one source is not automatically the same claim as A100 from another.
Line numbers are generally meaningful within their parent record. Line 2 on a corrected claim is not guaranteed to be the same service as line 2 on the original. A correction may insert, remove, split, or reorder lines. Matching versions by line number alone can attach a payment or diagnosis to the wrong service.
Repeated identifiers therefore call for investigation, not immediate deletion. They may represent valid lines, claim versions, or repeated deliveries of the same record. Establish the intended key before treating repetition as a data quality error. Adjustments, Denials, and Reversals develops the version problem further.
3.5 A claim is not an encounter
Imagine an emergency department visit with imaging. The hospital can submit a facility claim, an emergency physician group can submit a professional claim, and a radiologist can submit another professional claim. Those bills may arrive on different dates and use different claim identifiers even though they relate to the same visit.
The reverse also happens: a bill can span multiple service dates, and an institutional stay can be split across billing periods. Counting claims is therefore a measure of billing records. Counting encounters requires an additional definition that groups the relevant records into healthcare events.
The same distinction applies to procedures. A facility line and a professional line may describe different billable components of one procedure. Two appearances of a procedure code do not, by themselves, establish that the patient underwent the procedure twice.
3.6 Joins can quietly change the grain
Suppose our three-line claim has four header diagnoses. Joining every diagnosis directly to every line produces twelve rows. This may be appropriate for exploring the claim’s diagnoses alongside its services. It is not safe for summing the line payments: each payment now appears four times.
Professional diagnosis pointers can associate a line with specific entries in the claim’s diagnosis list. Preserve those relationships when the source supplies them. A pointer is a position in that list, not a diagnosis code, and it must be resolved within the correct claim version. When pointers are absent, do not pretend the extract establishes which diagnosis motivated each line.
For analyses that ask whether a claim has a condition, an existence check or a separately aggregated condition flag often avoids multiplying the financial rows. For analyses that need all diagnoses, keep the diagnosis table separate and join only after deciding the target grain.
3.7 Check the structure before using the totals
For each source, we want evidence that the chosen line key is unique, header values are consistent within a claim version, and joins preserve the expected row count. Where the source promises that line amounts reconcile to header totals, verify that relationship and investigate exceptions.
These checks answer a practical question: can we explain how the original records became the rows in our analysis? Once we can, the meaning of the individual fields becomes much easier to establish. We’ll turn to those meanings in Claims Data Elements.