Part of Dataset Foundry — synthetic, documented, citable datasets across domains
Insurance
Log in
Methodology · Health

What Insurance's health line actually does

This page is meant to be citable directly in a methodology chapter. Everything below is a design decision, not a discovery — Insurance does not model real Ghanaian insurer or health-utilization data, it encodes a documented set of assumptions about how utilization and cost-of-care risk factors should relate to health claims, so the relationships can be recovered and used to teach or test statistical methods. The structure mirrors the motor and life lines' two-stage frequency/severity model, but this line genuinely mixes both existing lines' mechanisms rather than following either one wholesale — see section 1.

1. Two-stage model

Every policy-year record is generated in two stages, same shape as motor and life:

  1. Frequency — whether at least one claim occurs this policy year is table-rated, life's technique, not motor's from-scratch logistic regression. An age-band claim-incidence table is the actuarial anchor; chronic-condition, smoker status, and BMI band each apply a multiplicative utilization loading on top of whichever band an applicant's age falls into. This keeps the age-band table itself the thing a reviewer can check directly, and the loadings legible as loadings on it, rather than opaque coefficients in a regression.
  2. Severity — for policy years that do have a claim, the cost is a log-normal multiple of a base claim cost, closer to motor's approach than life's table-rated frequency side, since "how much did this episode of care cost" isn't naturally a lookup table the way an age band is. Claim category (what kind of care was needed) and plan tier (which network the policy buys access to) both push the multiple up or down from the base — not any demographic factor. Age is deliberately excluded from severity here: cost-per-episode does rise with age in reality, but adding it would blur the frequency/severity split this line is deliberately keeping clean.

Which stage count to generate is itself a runtime choice on the generator page — two-stage (the default) runs both steps above; single-stage runs the frequency step only. The frequency logic and its coefficients are identical either way, so claim_occurred, claim_id, claim_category, and claim_date are the same regardless of mode. claim_amount_ghs — the only severity-side column — is entirely absent from the output in single-stage mode, not null-filled. Whichever mode you pick is recorded in the dataset's manifest and citation, same reasoning motor's own stage_mode toggle documents.

2. The four hypotheses

Same as life, all four of health's core hypotheses are on claim frequency, not severity — severity here is driven by product/plan features (claim category, network tier), not by the same demographic and behavioral factors that drive whether a claim happens at all. This also means all four apply, and are verified, in both stage modes.

FactorDirection on claim frequencyRationale encoded
Applicant age Positive Older applicants sit in higher age bands on the claim-incidence table — the anchor itself, not a separate coefficient.
Chronic condition Positive A diagnosed chronic condition (vs. none) carries an elevated utilization loading, reflecting routine monitoring and complication-related care.
Smoker status Positive Smokers carry a modest elevated utilization loading for care outside what's already captured by chronic-condition status, not a repeat of the same effect.
BMI band Positive Overweight and Obese bands carry an elevated utilization loading relative to Normal/Underweight.

3. Coefficients

Claim probability is modeled as p = clip(base_rate(age_band) · chronic_condition_loading · smoker_loading · bmi_band_loading, min_probability, max_probability), where base_rate(age_band) is the age-band claim-incidence table lookup and each loading is a named term keyed off the applicant's chronic condition, smoker status, and BMI band. Claim cost, when a claim occurs, is modeled as claim_amount = exp(log_base + log(claim_category_multiplier) + log(plan_tier_multiplier) + ε), where claim_category_multiplier and plan_tier_multiplier are named terms keyed off the claim category and plan tier, and ε is normal noise. These coefficients are illustrative, chosen to produce a clearly recoverable signal at typical sample sizes — the health line's own hypothesis tests use n=5,000, the same default motor uses, since a health claim in a given policy year is a less rare event than a death claim, which is why life's tests needed a larger n=20,000 instead. Exact magnitudes aren't published on this page and aren't derived from real Ghanaian health-utilization or claims data — see the current defaults, and change them, in the Advanced: customize the model panel on the health generator if your thesis calls for weaker or stronger effects, and note in your write-up which values you changed from the defaults.

4. Determinism

Generation runs server-side using a seeded generator (numpy's default_rng, PCG64) rather than an unseeded source of randomness — same mechanism as motor and life. The same seed, record count, and generator version (stamped in every citation and manifest — see the Cite section on the generator page) will always reproduce byte-identical output. Report the seed and record count alongside your dataset — that pair, together with the generator version, is sufficient for anyone to regenerate exactly what you analyzed.

5. What's decorative vs. load-bearing

Region, insured name, and premium calculations exist to make records look like real Ghanaian health policies and are internally consistent with each other, but they are not the object of the four hypotheses above. Treat the premium figures as an illustrative table-rated approximation, not as calibrated to any actual insurer's rate card. insured_name is excluded from generated output only if you disable it in a future name-inclusion toggle (not yet built — see ROADMAP.md Phase 4.5.3); today it's always present, same as every other field.

6. Known limitations

  • This is synthetic data. It should never be presented as, or mistaken for, real insurer or health-utilization data in a publication.
  • Frequency is table-rated with multiplicative loadings, not a from-scratch regression — no interaction effects between chronic condition, smoker status, and BMI band are modeled beyond simple multiplication, unless you add them yourself downstream.
  • Plan tier names (Basic/Standard/Premium/Executive) are illustrative only and not calibrated to any real insurer's actual tier definitions.
  • If your thesis needs a different balance between the four frequency-side hypotheses, adjust the relevant loadings in the Advanced: customize the model panel on the health generator and say so in your write-up.

7. Citing this tool

Something like: "Synthetic data generated using Dataset Foundry (seed = 42, n = 5,000), a deterministic health insurance data generator built for this thesis in the absence of accessible real-world health-utilization data." Include the seed and record count so the exact dataset is reproducible from the tool alone — or use the auto-generated citation block on the generator page, which also includes the generator version and any advanced-config changes.