The count that looks like an answer
Ask a claims database how many people have a condition and it will give you a number with no hesitation. For a broken hip or a heart attack, that number is close to the truth: the event is acute, the diagnosis is certain, and nearly everyone ends up in front of a clinician who codes it. For conditions such as myalgic encephalomyelitis/chronic fatigue syndrome (ME/CFS), long COVID, fibromyalgia and several autoimmune conditions, the same query returns a figure that can sit far below the number of people actually living with the illness. The query did not fail. It answered a different question than the one you asked.
This matters because claims-based counts drive real decisions. They size research programs, set budget lines, inform disability policy and shape which conditions a health department tracks. A program office that treats a code count as prevalence will underfund the response to exactly the conditions that are already hardest for patients to get recognized.
The rest of this piece explains where people go missing, how to estimate how many, and what to ask of anyone who hands you an estimate.
Four ways a person disappears from claims
Claims data record billable encounters with a diagnosis attached. A person living with one of these conditions can be absent from that record for at least four separate reasons, and each one needs a different correction.
The diagnosis arrives late or not at all. When symptoms fluctuate and no single lab test confirms the condition, reaching a diagnosis often takes years and several clinicians. During that time the person appears in claims under a scatter of symptom codes: fatigue, joint pain, sleep disturbance, dizziness, cognitive complaints. The Institute of Medicine's 2015 report on ME/CFS estimated that a large majority of people with the condition had never been diagnosed. Every one of them is invisible to a code-based count.
The code is nonspecific or changed. Even after diagnosis, the code a clinician selects depends on the code set, the payer's rules and local habit. Some of these conditions were coded under broad or shared categories for years. Long COVID received its own ICD-10-CM code, U09.9, only in October 2021, and ME/CFS later received a more specific code of its own. A time series built on those codes shows a jump at the code change that is a coding event, not a change in illness.
Care happens outside the insured system. People who have exhausted conventional options often pay cash for specialists, use out-of-network clinics or rely on care that does not generate a claim in the dataset you hold. Others lose employer coverage when they lose work, moving to another payer whose data you do not have.
The disability never produces a claim. The heaviest burden of these conditions is often reduced capacity: fewer working hours, a job left, school missed, a household that runs on someone else's care. None of that is billed. A person can be substantially disabled and generate only a handful of routine claims in a year.
Why a code count is a floor
Every one of those four mechanisms removes people from the count. None of them adds people who do not have the condition in any meaningful volume. Miscoding cuts both ways in principle, but for these conditions the net bias runs one direction: down.
That is the precise sense in which a code count is a floor. It is the minimum number of people the health care system has recognized and billed under specific codes, within the population covered by your data, in the window you chose. It says nothing about how far above the floor the true number sits. Two claims-based counts can differ by a factor of two simply because one requires a single code and the other requires two codes thirty days apart. Neither is wrong. Both are floors with different heights.
A code count tells you how many people the system has recognized, not how many people are ill. The practical rule follows. Never present a claims count alone as prevalence for a condition with long diagnostic delay. Present it as the recognized, coded population, and pair it with at least one estimate built from a source that does not depend on diagnosis and billing.
What each data source sees and what it misses
No single source answers the question. Each sees a different slice of the affected population, and the useful work comes from understanding exactly where each one is blind.
| Source | What it sees | What it misses for these conditions |
|---|---|---|
| Insurance claims | Billed encounters with codes, procedures, prescriptions and costs for enrolled members | The undiagnosed, nonspecific coding, cash-pay care, people who changed or lost coverage, all unbilled disability |
| Electronic health records | Clinical notes, symptoms, test results and problem lists inside one health system | Care at other systems, people who stopped seeking care, and documentation styles that vary by clinician |
| National health surveys | Self-reported diagnosis and, increasingly, self-reported symptoms and limitation, weighted to the population | People too ill to respond, people in institutions, and anyone not yet told they have the condition unless symptom questions are asked |
| Patient registries and apps | Detailed symptom and function histories from people who chose to enroll | Anyone not connected to a patient organization or not able to use the app; enrollment is self-selected |
| Disability and employment records | Work loss, benefit applications and awards, often with a coarse diagnosis category | People who never applied, were denied, or left work without a formal record; diagnosis detail is limited |
The pattern in the right-hand column is the argument for triangulation. The sources fail in different places, so where two or three of them agree, the estimate is far stronger than any one alone.
Code-pattern phenotyping
The first improvement on a raw code count is a computable phenotype: a rule, or a model, that identifies likely cases from the full pattern of a person's records rather than a single code. For these conditions, a phenotype typically combines a diagnosis code where one exists, a persistent pattern of related symptom codes over a minimum period, the exclusion of conditions that better explain the pattern, and sometimes specialty visits or prescriptions.
A phenotype is only as good as its validation. The standard is a chart review: draw a sample of people the phenotype flags and a sample it does not, have clinicians review the records against an accepted case definition, and compute positive predictive value and sensitivity. A phenotype with high predictive value and low sensitivity is still a floor, just a more accurate one. Report both numbers and the case definition used for review, because a phenotype validated against one case definition will perform differently against another.
Phenotypes also travel badly. One built on a large academic health system's records will behave differently in a rural Medicaid population, where coding habits, specialist access and documentation all differ. Revalidate on a sample from the population you are estimating.
Survey-based prevalence
Surveys reach people the claims system never sees, which is why they are the essential second source. The national household surveys ask whether a health professional has ever told the respondent they have a condition, and for some conditions they now ask about symptoms and their duration directly. Survey-based estimates of long COVID, for example, have generally run well above what counts of the diagnosis code alone would suggest.
Surveys have their own blind spots. Self-report of a diagnosis inherits the diagnostic delay problem. Symptom-based questions catch the undiagnosed but can also catch people whose symptoms have another cause, so the question wording is the case definition and deserves the same scrutiny as a phenotype. People who are severely ill are less likely to complete a survey, which biases estimates down for the most affected. Weighting corrects for who was sampled, not for who was too ill to answer.
For subnational estimates, state surveys and model-based small-area estimates help, with the caution that a modeled county estimate borrows from demographics and will smooth over real local clusters.
Patient-reported data and registries
Patient registries, research cohorts and symptom-tracking apps capture what neither claims nor surveys can: how function changes week to week, which activities trigger a decline, and how long recovery takes. For conditions defined by fluctuation, that time structure is the substance.
The limitation is who enrolls. People connected to patient organizations, comfortable with technology and well enough to log data consistently are overrepresented. That makes registry data excellent for describing the course of illness among participants and weak for estimating how many people are affected. Use it to characterize severity and burden per person, and pair it with a population source to count people.
Linking to employment and disability data
The burden these conditions carry shows up most clearly in work and income, which is exactly where claims are silent. Linking health records to employment and disability data is how analysts make that burden visible.
The National Center for Health Statistics links its national surveys to Medicare and Medicaid records, Social Security benefit data and the National Death Index, with access through secure research data centers. A linked file lets an analyst compare work history and benefit receipt among people reporting a condition against similar people who do not. State agencies can sometimes link unemployment insurance wage records with Medicaid data under data sharing agreements. Disability program statistics, published by diagnostic group, give a coarse but independent signal, with the caveat that applying, being approved and the category recorded all depend on the program's rules rather than on the illness alone.
Every linkage of this kind needs a legal basis, a data use agreement, a privacy review and a plan for small cells. Budget months, not weeks, for access.
Putting the estimates side by side
Once you have two or more sources, the question becomes how to combine them without pretending more certainty than you have. Two methods do most of the work.
Capture-recapture. When two independent sources identify cases among the same population, the overlap tells you about the people neither found. With an illustrative 400 cases in source A, 300 in source B and 60 in both, the classic two-source estimate is 400 × 300 ÷ 60, or 2,000 people, far more than the 640 distinct people the two lists contain. The method assumes the sources find people independently, which is rarely true: the people most likely to appear in claims are also the people most likely to be in a registry. Positive dependence biases the estimate down, so treat it as a better floor, not a ceiling.
Bracketing. Present the claims floor, the phenotype estimate, the survey estimate and any linked estimate as a ladder, each with its definition. The decision-maker sees a range with a documented reason for every rung, which is more honest and more useful than a single blended figure.
Where AI helps, and where it overreaches
Machine learning and language models have a real place in this work. They also have a specific way of going wrong, which is learning the shape of the diagnosed population and calling it the shape of the illness.
- Reading clinical notes. Language models can find symptom descriptions, functional limitations and clinician suspicion in free text that never became a code. This often finds candidates a code-based phenotype misses.
- Learning phenotypes from records. A model trained on chart-reviewed cases can weigh hundreds of signals at once. Trained only on diagnosed people, it learns who gets diagnosed, which repeats the bias it was meant to fix.
- Structuring patient diaries. Models can turn free-text symptom logs into consistent fields for analysis, provided every extracted value traces to the words the person wrote.
- Flagging, not deciding. The safe role is to rank records for human review. A model that labels people as cases without review produces a count nobody can audit.
The test for any AI component is the same as for any phenotype: a validation sample reviewed by clinicians against a stated case definition, with predictive value and sensitivity reported separately for the subgroups the program cares about. A vendor who reports one overall accuracy figure for a case-finding model has told you nothing about whether it works.
What a program office should require
Before a prevalence or burden estimate for one of these conditions shapes a budget, ask for the following. A credible analyst will have most of it ready.
- The case definition, written out, with the codes, symptom criteria or survey questions that define a case.
- At least two independent sources, with the estimate from each shown separately before any combination.
- Validation of any phenotype or model: positive predictive value and sensitivity from a reviewed sample, by subgroup.
- The population covered and excluded, including people outside the insured or surveyed population.
- Treatment of code changes and any break in the time series they cause.
- A stated direction of bias for each source, and the range that results.
- The linkage and privacy basis for any combined data, with small-cell handling described.
Language that respects patients and clinicians
How an analysis describes people affects whether patients trust it and whether clinicians accept it. Undercounting is not evidence that a condition is rare or mild, and an analysis should say so plainly. Describe people as living with a condition. Describe missing diagnoses as a feature of the data, not as a judgment on anyone. Clinicians code within the rules and the time they are given, and many of these conditions lacked specific codes or accepted criteria for years.
Involving patient organizations in reviewing case definitions and survey wording is good method, not just good manners. They know which questions people answer honestly, which terms they find dismissive, and where the existing data are most misleading.
Frequently asked questions
Claims count only people who have been diagnosed, coded with a specific code, and seen within the covered population. Long diagnostic delays, nonspecific coding, care outside insurance and disability that never generates a bill all remove people from the count. Surveys reach some of those people directly.
No. Surveys miss people who are too ill to respond or who live in institutions, and symptom-based questions can include people whose symptoms have other causes. The point is that surveys fail in different places than claims, so comparing them reveals the gap.
It can flag records worth review, particularly by reading clinical notes. It should not label people as cases without human review, and a model trained only on diagnosed people tends to learn who gets diagnosed rather than who is ill.
Ask for the case definition and the sources, shown separately. An estimate that cannot show how each source defined a case, and what each one found before any combination, cannot be checked.