Why the Table Structure Matters
Population pharmacokinetic analysis uses information measured at different levels: characteristics of participants, dose administrations, concentration samples, and covariate measurements. Those records do not share the same natural row structure. A participant may have multiple doses and multiple samples, while some covariates are measured once and others repeatedly. If all information is placed in one undifferentiated table, it becomes easy to duplicate records, confuse a measurement with a participant-level attribute, or lose the meaning of a field.
The goal is not to choose a particular software format. It is to define a stable schema: what one row represents, what each field means, what type of value it can contain, and how records are uniquely identified. The sampling schedules considered in the earlier material on sparse sampling determine which observations a study plans to collect; the schema must be able to represent the observations that are actually recorded.
The design below assumes records belong to an identified study and that each person has a stable study-specific identifier. It also assumes that recorded values preserve their measurement meaning: a dose amount, concentration, time, and weight are not interchangeable merely because all can be stored as numbers. The exact dose-event representation, timing reconciliation, and event-order rules require additional decisions beyond this schema overview.
Four Tables With Distinct Row Grains
A useful starting design separates participant-level information from repeated records. The table names are illustrative; a project may use different names as long as the definitions remain explicit.
| Table | One row represents | Typical identifying key | Example fields |
|---|---|---|---|
| Subject | One participant in one study | STUDYID + ID | Study identifier, participant identifier, treatment group, baseline characteristics |
| Dose | One recorded dose administration | STUDYID + ID + DOSEID | Dose record identifier, amount, amount unit, route, administration time |
| Sample | One participant’s result for one sample and analyte | STUDYID + ID + SAMPLEID + ANALYTE | Sample identifier, analyte, collection time, concentration, concentration unit, result status |
| Covariate | One participant’s recorded covariate value at one assessment | STUDYID + ID + COVRECID | Covariate name, value, value type, unit, assessment time |
The study identifier is useful even when a file currently contains data from just one study: participant codes such as 001 or 014 may be reused in another study. Dose and sample identifiers distinguish repeated records for the same participant. The analyte is included in the sample key because one specimen can produce results for more than one analyte. If a project has exactly one analyte and defines SAMPLEID as one result record, its key can be simplified, but that convention must be documented.
A key is a design commitment, not a field added after analysis. Each key must be present, and its complete combination must be unique. Participant identifiers in the repeated-record tables must also refer to a participant represented in the subject table. These checks establish identity and referential integrity; they do not, by themselves, decide how records are ordered or how elapsed times are reconstructed.
Worked Example: Choosing Keys for Repeated Records
Consider a hypothetical study with participant identifiers P01 and P02. P01 has two recorded administrations and three concentration results; P02 has one administration and two results. The sample results are all for one analyte, DRUGA. Choose keys and check the resulting record counts.
The subject table has two rows, identified by STUDYID and ID. The dose table has three rows. If the dose record identifiers are D01 and D02 for P01 and D01 for P02, then the dose keys are (STUDY1, P01, D01), (STUDY1, P01, D02), and (STUDY1, P02, D01). Reusing D01 across participants is safe because the complete composite key differs.
The sample table has five rows, identified by study, participant, sample, and analyte. For example, (STUDY1, P01, S01, DRUGA) and (STUDY1, P01, S02, DRUGA) are distinct. If P01’s S01 specimen has results for both DRUGA and METABOLITE1, the analyte component distinguishes those two result rows.
There are 2 subject rows, 3 dose rows, and 5 sample-result rows. These counts differ because their row grains differ. Requiring one row per participant in every table would either discard repeated information or place several values into a single cell, making the records difficult to validate and analyze.
Fields, Types, and the Data Dictionary
Every field needs both a type and a meaning. Identifiers are usually stored as character strings, even when they contain only digits; their role is to identify records, not to support arithmetic. Measurements should use numeric types, while categories should use a defined set of labels. Dates and timestamps should use a recognized date/time type when supported; if stored as text for transfer, their format must be specified. A field name alone is not a sufficient definition.
A compact dictionary might include the following entries. The example units and labels are hypothetical and must be replaced or confirmed for the actual study.
| Table.field | Type | Meaning and units | Allowed values or rule |
|---|---|---|---|
| Subject.STUDYID | Character | Study identifier | Nonmissing; consistent study code |
| Subject.ID | Character | Participant identifier within study | Nonmissing; unique with STUDYID |
| Subject.ARM | Categorical | Assigned treatment group | For example, CONTROL or ACTIVE |
| Dose.DOSEID | Character | Identifier for a dose record | Unique with STUDYID and ID |
| Dose.AMT | Numeric | Recorded dose amount | Positive when administration occurred; see DOSEUNIT |
| Dose.DOSEUNIT | Categorical | Unit for AMT | For example, mg; never inferred from AMT alone |
| Sample.SAMPLEID | Character | Specimen identifier | Nonmissing; stable within participant |
| Sample.CONC | Numeric | Measured concentration | Use with CONCUNIT and result-status fields |
| Sample.CONCUNIT | Categorical | Unit for CONC | For example, ng/mL; allowed values documented |
| Covariate.COVNAME | Categorical | Name of measured or derived covariate | For example, WT or ALB |
| Covariate.COVVALUE | Typed value | Recorded covariate value | Type and unit determined by COVNAME |
| Covariate.COVUNIT | Categorical | Unit for a quantitative covariate | Documented for each applicable COVNAME |
The dictionary should also specify whether fields may be missing and what missing means. A blank can indicate not collected, unavailable, or not applicable; those meanings should not be silently combined. Do not use an arbitrary numeric value such as -99 to represent missing concentration unless a documented import convention is converted to a proper missing value before analysis. A value of zero is a measured value, not a general-purpose missing code.
Covariate design deserves special attention. A fixed characteristic such as sex may be stored once in the subject table. A measurement that can change, such as body weight, may be stored as repeated covariate records with an assessment time. Either arrangement can be sound if the row grain, timing meaning, units, and key are stated. Repeating a baseline value in every sample row creates redundant copies that can disagree after editing.
Worked Example: Making a Covariate Field Unambiguous
In a hypothetical study, participant P01 has body-weight assessments of 68.4 kg at baseline and 66.9 kg at a later assessment. The source file has a column called WT containing the text values “68.4 kg” and “66.9 kg.” Convert this into analysis-ready fields without changing the measurements.
Store COVNAME as the categorical value WT, COVVALUE as the numeric values 68.4 and 66.9, and COVUNIT as kg. Store the assessment time in a separately defined field using the study’s documented time convention. Assign distinct COVRECID values, such as C01 and C02, so the two assessments have separate records.
The values remain 68.4 kg and 66.9 kg; the difference is 68.4 - 66.9 = 1.5 kg. Because COVVALUE contains numbers rather than number-plus-unit text, numeric operations are possible, while COVUNIT preserves the scale. A dictionary entry that merely says “WT: weight” would be incomplete: it must also state the numeric type, unit, assessment meaning, and missing-value rule.
Why Separate Tables Prevent Record Multiplication
The separation follows directly from the row grains. Suppose one participant has two dose records and three sample records. Combining the dose and sample tables using only the participant identifier produces every dose-sample pairing for that participant. The number of resulting rows is the product of the two record counts:
Each dose is repeated three times, and each sample is repeated twice. That combined table may be useful for a deliberately constructed analysis, but it is not a faithful replacement for the original dose and sample tables. Counting those six rows as six dose records or six concentration results would be incorrect. Preserving each table at its own grain makes record counts interpretable and reduces accidental duplication.
A wide table is an alternative: one participant row can contain columns such as SAMPLE1, SAMPLE2, SAMPLE3 and DOSE1, DOSE2. It can be convenient for a fixed small schedule, but adding an extra sample requires adding columns, and participants with fewer observations have structurally empty cells. A flat long table is another alternative, with a record-type field and many partially empty columns. It may be convenient for a particular software workflow, but its mixed row meanings make validation harder. Separate tables are generally clearer when the numbers of doses, samples, or covariate assessments vary by participant.
Worked Example: Diagnosing an Inflated Flat Table
A hypothetical participant has two dose rows, D01 and D02, and three sample rows, S01, S02, and S03. An analyst creates a flat table by matching records on participant ID alone. Determine how many rows appear and why that result cannot be interpreted as the number of samples.
The flat table contains 2 × 3 = 6 rows: each dose is paired once with each sample. Therefore S01 appears twice, S02 appears twice, and S03 appears twice. There are still only three sample results and two dose records; the six rows represent pairings, not six independent observations.
A practical check is to compare distinct sample keys before and after the transformation. Before combining, the sample table has three unique sample-result keys. In the combined table, there are six rows but only three distinct sample-result keys. If an analysis counts rows rather than unique sample results, its sample count is doubled in this example. Keep the source tables at their defined grains and document any derived combined dataset separately.
Validation Checks and Common Failure Modes
Schema checks can be performed before model fitting. They do not establish that every value is scientifically plausible, but they identify structural problems early. Apply checks at the level each table represents:
- Key checks: confirm that required key fields are nonmissing and that each complete primary-key combination occurs once.
- Reference checks: confirm that each participant identifier in a dose, sample, or covariate record exists in the subject table.
- Type checks: verify that numeric measurements are numeric, identifiers remain identifiers, and category values match the dictionary.
- Unit checks: require a documented unit for quantitative dose, concentration, and covariate values. A numeric value without its unit is incomplete.
- Grain checks: confirm that each row is one record of the stated kind, rather than a summary or a repeated copy of another table’s record.
- Missingness checks: distinguish a missing measurement from a measured zero and from a value not applicable to that record.
Warning signs include a supposedly unique key appearing twice, a sample record with no participant, concentration values stored as mixed text such as “2.1” and “<0.5,” or the same participant characteristic disagreeing across repeated rows. These findings require investigation, not an automatic deletion or recoding rule. Some apparent duplicates may reflect distinct analytes or assessments; some conflicting values may reflect data entry errors. The data dictionary and source records determine how to resolve them.
No schema can repair missing source information or guarantee that a record is scientifically valid. The tables document and organize what was recorded; they do not establish that a reported administration occurred as intended, that a time was captured correctly, or that an assay result is reliable. Those questions need study-specific review and additional quality-control procedures.
Check Your Understanding
Answer each question, then compare your reasoning with the solutions.
- A participant has four sample results. What should be the row grain of the sample table, and why is one row per participant insufficient?
- Two participants in the same study both have a dose record called D01. Is this necessarily a duplicate key if the dose key includes STUDYID and ID? Explain.
- A concentration field contains the text “3.2 ng/mL.” What fields would make its numeric value and measurement unit explicit?
- One participant has two dose records and five sample records. How many rows result from pairing every dose with every sample on participant ID alone? What do those rows represent?
- When might body weight belong in a repeated covariate table rather than only in the subject table?
Solutions. (1) One row should represent one sample result for the specified participant and analyte. Four distinct results need four records; one participant-level row cannot represent them without packing repeated observations into one cell or losing information. (2) No. The composite keys differ because the participant identifiers differ, even though D01 is reused. (3) Store 3.2 as a numeric concentration value and ng/mL as a documented concentration unit; define any result-status or qualifier separately if applicable. (4) 2 × 5 = 10 rows. They represent dose-sample pairings, not ten doses or ten samples. (5) If body weight was measured at multiple assessments and may change over time, a repeated covariate table can preserve each value and its assessment time; a single subject-level value would not represent that history.