Why Explicit Population Flags Matter
A pharmacometric analysis does not use every record in every source file. A concentration record might lack a usable assay result, have no attributable dose, or be unsuitable for a particular analysis under its prespecified rules. If such a record simply disappears during data preparation, a reviewer cannot tell whether it was deliberately excluded, accidentally lost, or never received. Explicit inclusion flags and reason codes make the decision visible while preserving the record for review.
The first decision is not which records to remove. It is what population is being defined and what is the unit being classified? A subject-level population classifies people; an observation-level population classifies individual records. A subject can qualify for a safety population while some of that subject’s concentration records do not qualify for a particular concentration analysis. Those decisions need separate, clearly named flags.
Specify the Decision Before Coding It
A useful population definition states four things: the analysis purpose, the unit classified, the eligibility conditions, and the handling of unresolved information. For example, “records eligible for the concentration-time analysis” is incomplete unless it says which records count and what makes a concentration record eligible. A defensible operational rule might require both a usable reported result and an attributable dose, with any additional study-specific restrictions stated separately.
Let \(A_i=1\) when record \(i\) has a usable result and \(D_i=1\) when its dose is attributable; otherwise each indicator is 0. If the stated rule requires both conditions, the record is included only when both are true:
Here \(I_i=1\) means included and \(I_i=0\) means excluded. This expression is the logical “AND” of the two conditions: multiplication gives 1 only when both binary indicators equal 1. A reason code should identify each failed condition, rather than merely repeat that the record is excluded. More than one reason may apply to a record.
Reason codes should be specific enough to explain the decision and consistent enough to summarize. Examples include RESULT_UNUSABLE, DOSE_NOT_ATTRIBUTABLE, and OUTSIDE_ANALYSIS_WINDOW. A controlled set of codes is preferable to free-text explanations that describe the same situation in many spellings. If several conditions fail, retain all applicable codes when the data structure allows it. If a system also requires one primary reason, define the priority rule in advance and retain the full set of reasons separately.
Worked Example: Record-Level Eligibility for a Concentration Analysis
Worked Example: Record-Level Eligibility for a Concentration Analysis
Suppose, hypothetically, that a concentration-time analysis requires each record to have both a usable assay result and an attributable dose. The table gives six retained records and the two conditions. “Yes” means the condition is met.
| Record ID | Usable result? | Dose attributable? |
|---|---|---|
| R101 | Yes | Yes |
| R102 | Yes | No |
| R103 | No | Yes |
| R104 | No | No |
| R105 | Yes | Yes |
| R106 | Yes | No |
For R101, \(A_{101}=1\) and \(D_{101}=1\), so \(I_{101}=1\times1=1\). It is included and has no exclusion reason. For R102, \(A_{102}=1\) and \(D_{102}=0\), so \(I_{102}=1\times0=0\). Its result is usable, but the dose is not attributable; assign DOSE_NOT_ATTRIBUTABLE. Do not say that both required conditions failed: only the dose-attribution condition failed.
For R103, \(A_{103}=0\) and \(D_{103}=1\), giving \(I_{103}=0\times1=0\), with RESULT_UNUSABLE. For R104, both indicators are 0, giving \(I_{104}=0\); assign both reason codes because both conditions fail. R105 is included because \(1\times1=1\). R106 is excluded because its dose is not attributable, so it receives DOSE_NOT_ATTRIBUTABLE.
The arithmetic check is \(2\) included records and \(4\) excluded records, for \(2+4=6\) retained records. The reasons are not four unique records of failure: R104 has two reasons. Counting reason-code occurrences gives three dose-attribution failures (R102, R104, R106) and two unusable-result failures (R103, R104). The count of excluded records remains four.
Why the Reason Logic Works
The inclusion rule is a conjunction: both eligibility conditions must be true. Its complement gives the exclusion rule. By De Morgan’s law, “not both conditions are met” is equivalent to “at least one condition is not met.” Therefore, the record is excluded if the result is unusable or the dose is not attributable, or both:
This distinction prevents a common coding and reporting error. “Both required conditions are not met” can mean that both failed, whereas “not both required conditions are met” means the conjunction is false and allows either one or both to have failed. When describing an individual record, state the actual failed condition or conditions, not an ambiguous paraphrase.
Worked Example: Subject-Level and Record-Level Populations
Worked Example: Subject-Level and Record-Level Populations
Consider a hypothetical study with three subjects. For a specified subject-level analysis, the rule is to include a subject who received at least one dose. Separately, the concentration-record rule requires a usable result and an attributable dose. Subject S02 received a dose but has one concentration record without an attributable dose.
S02 meets the subject-level rule, so the subject-level inclusion flag is 1. That decision does not make every record for S02 eligible. The concentration record with a usable result but no attributable dose has a record-level inclusion flag of 0 and reason code DOSE_NOT_ATTRIBUTABLE. Another concentration record for S02 could still be included if it meets both record-level requirements.
Suppose S01 and S02 received at least one dose, while S03 received none. The subject-level population contains 2 of the 3 subjects. Suppose the concentration file contains five records: two eligible records for S01, two for S02 (one eligible and one with no attributable dose), and one for S03 with no usable result and no attributable dose. The record-level population contains \(2+1=3\) eligible records; two records are excluded. The S03 record has two reasons, but is still one excluded record. Subject and record counts are different quantities and must not be combined as if they described the same units.
Worked Example: Retaining Records and Reconciling Counts
Worked Example: Retaining Records and Reconciling Counts
Imagine a hypothetical preparation step begins with 12 identified concentration records. The prespecified rule yields 8 included records, 3 final exclusions, and 1 record awaiting confirmation of dose attribution. A traceable disposition summary should report these as separate statuses:
| Disposition | Count | Interpretation |
|---|---|---|
| Included | 8 | All required conditions are met |
| Excluded | 3 | At least one required condition has failed |
| Pending review | 1 | A required fact is unresolved; no final eligibility decision yet |
| Total retained records | 12 | Included + excluded + pending |
The reconciliation is \(8+3+1=12\). Coding the pending record as excluded would change the reported final-exclusion count to 4 without establishing that it failed a rule. Dropping it would instead leave only 11 identifiable records and conceal the unresolved decision. Keep the record, its identifier, its available source information, and its pending status until the question is resolved; then update the final flag and reason information according to the rule.
Implementation, Diagnostics, and Alternatives
A robust population dataset preserves a stable identifier for each classified unit, the population-specific inclusion flag, the applicable reason code or codes, and enough source linkage to locate the original record. Store separate flags when definitions differ, such as a subject-level population and a record-level concentration population. A single generic field named “included” is ambiguous if it could refer to several analyses.
After assigning decisions, check the logic and the counts. Useful checks include:
- Every final included unit satisfies every required inclusion condition.
- Every final excluded unit has at least one applicable reason code.
- No unit is simultaneously marked included and excluded for the same population.
- The mutually exclusive disposition counts (included, excluded, pending) sum to the number of retained identified units.
- Every reason code corresponds to an actual failed rule, and multiple reasons on one unit are not mistaken for multiple excluded units.
- Excluded and pending records remain linkable to their source identifiers rather than disappearing from the reviewable data.
Filtering to included records can be useful when creating a specific analysis input, but filtering is not a substitute for recording dispositions. Keep the classified records and their decisions available, and create the analysis-specific subset from the explicit flag. Similarly, a single “excluded” marker says that a decision was made but not why; specific reason codes support review and summary. Free-text comments can add detail, but should not replace stable coded reasons.
These practices do not decide which scientific or protocol criteria are appropriate. The population rules must be justified for the intended analysis and applied consistently. A flag also cannot repair missing source data, resolve a contradictory dose history, or establish that a measurement is scientifically valid. It makes the disposition transparent; the underlying criteria and source evidence still require review.
Common Pitfalls
- Confusing subject and record eligibility. A subject may qualify for one population while an individual observation does not qualify for another. Use flags whose names and units make the distinction clear.
- Treating unknown as failed. An unresolved attribution is not automatically proof that attribution failed. Use a pending status until the decision is supported.
- Using an ambiguous reason. “Excluded” does not explain the cause. Record the specific failed condition, and record multiple applicable reasons where appropriate.
- Deleting before documenting. Once an excluded row is removed without a retained disposition trail, accidental loss and intentional exclusion may be impossible to distinguish.
- Miscounting reasons as records. A row with two reason codes is one excluded row, not two.
Check Your Understanding
Answer each question, then compare your reasoning with the solutions below.
- A record has a usable result but its dose is not attributable. Under a rule requiring both conditions, what is its disposition and reason code?
- A record has neither a usable result nor an attributable dose. How many excluded records and how many reason-code occurrences does it contribute?
- There are 15 retained records: 9 included, 4 excluded, and 2 pending. Does the disposition count reconcile? Should pending records be counted as final exclusions?
- A subject meets a subject-level population rule, but one of the subject’s concentration records fails a record-level requirement. Must that record be included because its subject qualifies? Explain.
Solutions. (1) The record is excluded because not both required conditions are met: the dose is not attributable. Record DOSE_NOT_ATTRIBUTABLE; the usable result condition is met. (2) It is one excluded record with two reason-code occurrences: RESULT_UNUSABLE and DOSE_NOT_ATTRIBUTABLE. (3) Yes: \(9+4+2=15\). No; pending records are unresolved, not final exclusions. (4) No. Subject-level eligibility and record-level eligibility apply to different units; assign the record its own flag and the reason code for the failed record-level condition.