Praxis Variable Guide · PVG-001

SEQN Connects NHANES Files

How to use the respondent sequence number without corrupting participant-level data

Audience
Researchers joining NHANES participant-level component files
Reviewed
Format
One-page PDF · US Letter

Guide overview

The essential idea

SEQN is the NHANES respondent sequence number. It is the participant-level key used to connect information released in separate demographic, questionnaire, examination, laboratory, and dietary files. SEQN makes linkage possible, but it does not make every join safe: the analyst must first understand the number of records each file can contain per participant.

Practical framework

What to apply

What SEQN is

What information does the variable carry?

  • The cycle-specific codebook labels SEQN as the respondent sequence number.
  • It identifies the participant record used to link public-use components within the NHANES release structure.
  • Keep SEQN in raw and analytical files even when it is not displayed in final tables.
  • Store it without arithmetic transformation and protect it from spreadsheet rounding or formatting changes.

Know the file grain

Does each file contain one or several records per SEQN?

  • Many demographic, examination, questionnaire, and laboratory files contain one row per eligible participant.
  • Some dietary, medication, supplement, condition, or event files can contain multiple rows for one participant.
  • Count rows and distinct SEQN values and inspect duplicates before selecting a join relationship.
  • Decide whether repeated records should remain long, be summarized, or be transformed to participant level.

Join deliberately

Which participant set should the merge preserve?

  • Use the demographics file as a common participant backbone when that matches the research design.
  • Choose left, inner, or full joins according to eligibility and participant-flow decisions - not convenience.
  • Include cycle provenance when appending multiple releases and verify that the intended SEQN scope remains unambiguous.
  • Prevent many-to-many joins unless that expansion is explicitly intended and understood.

Audit after joining

Did the merge preserve the expected participant structure?

  • Record row counts, distinct SEQN counts, duplicates, and unmatched keys before and after every join.
  • Confirm that participant-level datasets still contain one row per SEQN where required.
  • Compare expected component eligibility with observed matches and missing values.
  • Inspect a small set of SEQN records across source and merged files as a traceability check.

Before you finish

A short quality review

  1. SEQN type and formatting are consistent across every source file.
  2. Rows per SEQN and duplicate keys are known before joining.
  3. The selected join relationship matches the scientific participant-flow plan.
  4. Cycle provenance is retained when multiple releases are appended.
  5. Pre-join and post-join row, key, and unmatched counts are recorded.
  6. The final dataset has the expected number of records per participant.

A key can link the wrong structure perfectly. The most dangerous NHANES join is often not a failed join. It is a technically successful many-to-many merge that silently multiplies participant records.

Authoritative sources

Continue with the primary guidance