Synthetic Professional Superbill (Itemized Medical Bill) Data
Synthetic training data — no real PII, fully coherent identities
Generate synthetic itemized medical bills and professional superbills — service lines, diagnosis pointers and a charge-to-balance payment waterfall that reconciles on every document. Training data for medical-bill review, claims processing and payment integrity.
60
Fields per document
1
Page
Healthcare
Category
What this document is
The itemized medical bill — the professional superbill — is the line-level statement a practice produces for an encounter: facility and rendering provider with their NPIs, patient and insurance identifiers, up to four diagnosis pointers, a table of dated service lines with procedure codes, descriptions, units and charges, and a payment waterfall running from total charges through the insurance adjustment and payment to the balance the patient owes.
Why generate synthetically
Itemized bills are the input to every medical-bill review, payment-integrity and patient-advocacy workflow there is, and they are almost impossible to obtain in volume: each one is protected health information belonging to a named patient, and the practices that hold them have no reason to release them. Teams building extraction for this document typically work from a few hundred redacted scans, which is enough to build against and nowhere near enough to measure against. Synthetic bills give you the volume and the ground truth at once.
What makes synthetic data useful
Each generated bill is one coherent encounter. The service lines are dated consistently, the units and charges multiply through, and the payment waterfall resolves — total charges less the insurance adjustment and payment gives the balance due on every document, so a model can be trained to flag a bill that does not add up because none of these do. Diagnosis pointers taper the way real encounters do: every bill carries a primary diagnosis, 74% a second, 46.5% a third and 19.3% a fourth. Procedure code and description are always a matched pair, which makes code-to-description consistency a scoreable property rather than a hope.
Training challenges
The service-line table has a variable number of rows — two on every bill, a third on 77%, a sixth on only 18% — and the empty rows below the last service line sit inside the same ruled grid, which is the classic table-extraction false positive. Every field on the page is typed as free text, so nothing tells an extractor that a cell is a date, a code, a unit count or a dollar amount except its column and its content. And the five financial fields at the bottom are all currency in adjacent labelled rows: confusing the insurance adjustment with the insurance payment produces a balance that looks plausible and is wrong, which is precisely the error a payment-integrity pipeline exists to catch.
Generate synthetic Professional Superbill (Itemized Medical Bill) data
Start with 500 free credits. No credit card required.
Generate NowWho uses this data
Claims-processing and payment-integrity vendors parsing provider-submitted bills, medical-bill review and patient-advocacy platforms that reprice line items, healthcare revenue-cycle automation reconciling statements against remittance, and price-transparency tools that need line-level charge data they are allowed to redistribute.
Document complexity profile
60 fields on a single page, all typed as free text: a provider and facility header with NPI and EIN, patient and payer identifiers, four diagnosis pointer pairs, a six-row service-line table of four columns, and a five-line financial waterfall — joined by 57 annotation relations. Row occupancy, diagnosis-pointer depth and the group-number field all vary per document, so the effective field set differs from bill to bill.
Key stats from our synthetic corpus
Quantitative characteristics of the Professional Superbill (Itemized Medical Bill) documents our generator produces.
| Metric | Value | Detail |
|---|---|---|
| Bills with a fourth diagnosis | 19.3% | Diagnosis pointers taper from 100% for the primary to 74% for the second, 46.5% for the third and 19.3% for the fourth. Sparse trailing slots in a fixed labelled block are where extractors most reliably invent content. |
| Service lines per bill | 2 to 6 | Lines one and two appear on every bill; occupancy falls to 77.4%, 59.4%, 36% and 17.8% for lines three through six. A detector that assumes a fixed table height is wrong on the majority of documents. |
| Fields typed as free text | 100% | Dates, codes, unit counts and dollar amounts are all text fields, exactly as a scan presents them. There is no schema hint to lean on, so column semantics must be inferred from position and content. |
| Rendering provider credentials | 11 kinds | Provider credentials spread across eleven values — DC, DPT, OT, PA-C, NP, PT, LICSW, OTR/L and others — at roughly 8 to 10% each. A flat eleven-way categorical in a short text field is a target models routinely collapse to the modal value. |
| Bills with a group number | 50.2% | The insurance group number is present on 50.2% of bills and absent on the rest, while the member ID is always present. A near-coin-flip conditional field next to an always-present one is the sharpest available test of whether a model reads the label or the position. |
How this document co-occurs with others
Rates at which identities in our corpus that produce a Professional Superbill (Itemized Medical Bill) also produce other documents.
| Correlation | Rate | Detail |
|---|---|---|
| Professional claim for the same encounter | 100% | The same service lines are submitted to the payer on a CMS-1500. Bill-to-claim reconciliation — do the codes, units and charges match what was billed — is the core payment-integrity comparison. |
| Intake that created the account | 100% | The patient account number, payer and member ID on the bill trace back to the registration form. Following an identifier across the two documents is the entity-resolution task revenue-cycle automation has to get right. |
| Employer plan adjudicating the charge | 64% | 64% of patients hold employer coverage elected through a benefits enrollment form. The plan named there is the plan that produced the adjustment line on this bill. |
| Benefits-side income verification | 100% | Households appearing in public-benefits income verification receive the same itemized statements. Medicaid-heavy practices process both, and the identifiers line up across them. |
Prevalence rates and category distributions above are corpus-derived: they were computed over all 1,000 identities in a local synthetic corpus generated by SymageDocs' World Simulation Engine at seed 20260421 — every identity is eligible for this form, so no sub-sampling applies. Field, type and relation counts, the all-text field typing and the synthetic status of the procedure code set come from the shipped itemized medical bill definition in the SymageDocs form library. No real patient or protected health information was used at any stage.
Frequently asked questions
- What data format do synthetic itemized medical bills include?
- Each generated identity produces a rendered PDF plus a structured JSON annotation file with bounding boxes, field types, and ground-truth values for all 60 fields, plus 57 label-to-value relations recording which label each value belongs to and which service-line row it sits in. COCO, YOLO, FUNSD, and BIO/NER exports come from the same job.
- Are the procedure codes real CPT codes?
- No. The codes are drawn from a synthetic code set in CPT and HCPCS format — correctly shaped, consistently paired with their descriptions, and distributed realistically across an ambulatory encounter mix — but they are not the AMA's licensed CPT code set and should not be treated as an authoritative code list. Train layout and structure on them; validate code semantics against your own licensed reference.
- Does the payment waterfall reconcile?
- Yes, on every document. Total charges, the insurance adjustment, the insurance payment, the patient payment and the balance due are internally consistent, which is what lets the corpus support validation logic and not only extraction. If your model returns a set of five numbers that do not reconcile, the corpus can tell you so.
- How many service lines does a typical bill carry?
- Between two and six. The first two lines are populated on every bill, the third on 77.4%, the fourth on 59.4%, the fifth on 36% and the sixth on 17.8%. The taper is deliberate: it exercises the variable-length table across its whole range rather than clustering at one row count.
- Can I use this data commercially?
- Yes. Every patient, provider, facility, identifier and charge is synthetic, contains no real patient or protected health information, and is licensed for commercial use including model training, benchmarking, and redistribution inside your own products.