Why Check Ranges and Valid Values?
A value can be entered in a data set without being a value that the variable is supposed to have. A negative number of children, a temperature far outside the possible scale for the recorded measurement, or a category code that is not defined in the data dictionary can indicate a recording or data-entry problem. These issues may go unnoticed if the data are analyzed without checks.
A validation rule is a specific test for whether a recorded value meets an agreed requirement. It can identify records that deserve review, but it cannot by itself establish that a value is wrong. An extreme measurement may be genuine, while an ordinary-looking value may still have been entered incorrectly. The goal is to find and investigate potential problems, not to remove unusual data automatically.
Writing a Clear Rule
A useful rule states exactly which values are allowed and why. For a numeric variable, the rule may specify an inclusive range from a lower limit \(L\) to an upper limit \(U\). A recorded value \(x\) passes if \(L \leq x \leq U\). It fails if it is below \(L\) or above \(U\). The endpoints matter: if a value equal to a limit is allowed, the rule must include that endpoint.
This rule is appropriate only when the range is justified for the particular variable and context. Some limits follow from definition: a count of clinic visits cannot be negative. Other limits may come from the measurement protocol or the population being studied. A range chosen only because it contains most of the observed values is not necessarily a valid rule; it could incorrectly flag real but uncommon observations.
For a categorical variable, define the permitted values as a set \(S\). The value passes when it is an element of \(S\), and fails when it is not. For example, if a field records a participant's response to a particular question and its allowed codes are “Yes,” “No,” and “Not sure,” then a code such as “Y” or “2” should be investigated unless the data dictionary explicitly defines it as an allowed code.
A rule should also make clear what it applies to. The limits for one variable should not be borrowed for another simply because the values look similar. Check the variable's definition and the collection context before deciding what counts as allowable. Missing values are a separate issue: a blank or designated missing-value code is not automatically an invalid value, and it should be handled according to the field's missing-data conventions.
Worked Example: Flagging Values Outside a Supported Range
Worked Example: Flagging Values Outside a Supported Range
Suppose a hypothetical clinic records the number of follow-up calls made to each patient during a defined 30-day period. The protocol states that the field is a count of calls made in that period, and the collection system permits values from 0 through 12. The recorded values for six records are 0, 2, 5, 12, 13, and \(-1\). Apply the range rule and identify what should happen next.
The stated rule is \(0 \leq x \leq 12\). A value passes only if it is at least 0 and no more than 12.
For 0, 2, 5, and 12, the inequality holds, so these values pass the check. The value 13 is above the upper limit because \(13>12\), and \(-1\) is below the lower limit because \(-1<0\). Those two records are flagged.
There are \(2\) flagged records among \(6\). The fraction flagged is \(2/6=0.3333\), or about \(33.3\%\). This summarizes the result of this check in these six records; it does not estimate the rate of errors in a broader population.
The count definition makes \(-1\) impossible as a number of calls. The value 13 conflicts with the protocol's stated limit, but the flag alone does not show why it occurred. Review both records against the original collection source and protocol. Do not replace either value or remove either record solely because the check failed.
Impossible Values and Unusual Values
The strength of a range check depends on the reason for the limits. An impossible value contradicts the variable's meaning or a firm constraint of the process. For example, a count of completed appointments cannot be negative. A value outside a protocol-defined range may instead be a protocol violation, a recording error, or evidence that the situation was not covered as expected. It still needs investigation.
An unusual value is uncommon or far from typical, but may be possible. For instance, one person might report far more hours of exercise in a week than most participants. A statistical outlier rule could flag that observation as unusual, but rarity alone does not make it invalid. Such a rule is different from checking a hard range or permitted values. Do not turn a description of what is common into a claim about what is allowed.
Even an apparent impossibility should prompt a careful check rather than an automatic edit. The recorded value might use a different convention than expected, or the field may have been misunderstood. Confirm that the rule matches the variable and the data collection before changing anything.
Worked Example: Checking Permitted Category Codes
Worked Example: Checking Permitted Category Codes
In a hypothetical survey, a field records whether a respondent completed a follow-up interview. The data dictionary specifies the permitted codes as “Complete,” “Incomplete,” and “Declined.” Seven records contain: Complete, Incomplete, Complete, Declined, Pending, Incomplete, and “complete” (lowercase). Which records fail the rule?
Here the permitted set is \(S=\{\text{Complete},\text{Incomplete},\text{Declined}\}\). The first six entries all match a permitted value except “Pending,” which is not in \(S\). The seventh entry, “complete,” also does not exactly match “Complete” as defined. Thus, two of the seven records are flagged.
The flagged fraction is \(2/7=0.2857\), or about \(28.6\%\). That fraction reports how many records failed this particular exact-code check. It does not establish that both entries are mistakes. “Pending” may indicate a response state that was omitted from the documented set, while lowercase “complete” may be a capitalization inconsistency or may have some other explanation.
Check the survey instrument, data-entry guidance, and source records. If the source confirms the intended value, any later correction should follow the project's documented data-handling process. If the source does not resolve the meaning, keep the uncertainty visible rather than guessing. A category that appears obvious to one analyst may have a specific meaning to the people who collected the data.
Why a Flag Is Not a Verdict
A flag is a screening result: it says that a record did not meet a specified test. A failed test can arise from a typo, a misunderstood code, a data-entry convention that was not documented, a measurement outside the expected range, or a flaw in the rule itself. The flag cannot distinguish these explanations without additional evidence.
For each flagged value, investigate questions such as:
- Does the rule match the variable's definition and the collection protocol?
- Is there an original form, instrument, or other source that can confirm what was recorded?
- Could the value reflect an allowed convention that has not been documented?
- Is the value genuinely impossible, or only outside what is typical?
- Can the issue be resolved from evidence, or should the uncertainty remain recorded?
A careful check starts from preserved source data and treats the flagged record as something to understand. If evidence supports a correction, the reason should be clear and the original information should not be silently lost. If evidence does not support a change, do not invent one just to make the value pass a rule. Whether an unresolved value is retained, set aside for a particular analysis, or handled another way depends on the situation and should be justified.
Worked Example: Reviewing a Flag Before Changing Data
Worked Example: Reviewing a Flag Before Changing Data
A hypothetical study records the number of days a participant experienced a symptom during the previous week. The questionnaire defines the response as a whole-number count from 0 to 7. One record contains 77. Apply the rule and decide what can be concluded.
The allowed range is \(0 \leq x \leq 7\). Since \(77>7\), the value fails the rule and the record is flagged. The result establishes only that 77 does not fit the stated count and reference period.
Next, consult the original questionnaire or source record. If it says “7,” then there is evidence that an extra digit was entered in the data; a correction to 7 can be justified and the discrepancy should remain traceable. If the source also says “77,” the source itself conflicts with the questionnaire's defined response range, so the value remains unresolved until the collection process can clarify it. If no source is available, there is not enough evidence to determine whether the intended answer was 7 or something else.
In none of these cases does the range check alone justify replacing 77 with 7. The rule identifies a problem to investigate; evidence supports any subsequent decision.
A Practical Validation Sequence
A disciplined sequence helps keep checks focused and prevents flags from being mistaken for cleaned data.
Confirm what the variable represents, including its reference period and the meaning of its recorded values.
Specify a justified numeric range or the exact permitted category codes. Make clear whether boundary values are included.
Identify the records that do not satisfy it. Keep the test separate from any decision to edit or exclude a value.
Compare flagged values with the collection instructions and available source records. Consider whether the rule itself needs review.
Do not silently discard an unusual or flagged value. Make any later change only when supported, and retain a clear account of what was found.
Common Mistakes
- Deleting every value outside a chosen range. A failed rule is a reason to investigate, not automatic proof that the observation is unusable.
- Using typical values as hard limits. A rare value can be valid. Limits should follow the variable's meaning or a justified collection rule, not merely what most records contain.
- Assuming a flag identifies the right correction. A value of 77 in a field with a maximum of 7 might be a typo, but the intended value cannot be known without evidence.
- Ignoring the category definition. A numeric or text code is valid only if it is permitted for that field. Do not assume an undocumented code means what it seems to mean.
- Applying one rule to unlike fields. Similar-looking numbers can represent different variables with different meanings and allowable values.
A useful way to check your reasoning is to distinguish three statements: “the value passed the rule,” “the value failed the rule,” and “the value is correct.” The first two follow from comparing data with the stated condition. The third requires evidence beyond that comparison.
Check Your Understanding
Answer each question by referring to the rule and the evidence available.
- A data dictionary permits a count from 0 through 20, inclusive. Which of the values \(-1\), 0, 20, and 21 fail the range check?
- A categorical field permits “Yes” and “No.” A record contains “Unknown.” What can the validation check establish, and what should be investigated?
- Why is a value that is far from most observations not necessarily invalid?
- A value fails a range check, but the original source record is unavailable. Why is it inappropriate to replace the value with the nearest allowed value automatically?
- Explain the difference between flagging a record and deciding to exclude it from an analysis.