Why Represent Doses as Events?
A pharmacometric data set may contain concentration observations, covariates, and drug administrations. A dose is not just a value attached to a subject: it is an event associated with a subject and a time. If the data record does not make clear which administrations actually occurred, a model may be given a dose history that describes intentions rather than evidence.
The record grain established in the earlier material on pharmacometric record grain applies here: decide what one row represents before assembling the data. For dose-event data, the natural grain is one row per documented administration. The earlier material on event-type coding distinguishes dose records from observation records; this tutorial specifies what information a dose record should carry and how to keep it separate from a planned dose.
At minimum, the record should be interpretable in terms of five questions: who received the drug, when the administration occurred, how much was administered, by what route, and under what regimen context. The fields may be stored in a wider data table that also contains observation records, but the meaning of a dose row should remain unambiguous.
What Belongs in a Dose-Event Record?
A practical specification names each field and defines its meaning, not just its column label. Subject identifiers and time conventions should follow the project-wide conventions established in earlier data-specification material. The amount and route should reflect the administration record; do not invent a value when source information is absent. Relevant regimen context can include a regimen identifier or other field needed to interpret which prescribed regimen applied. It should not replace the record of what was administered.
| Information | Question answered | Record-level meaning |
|---|---|---|
| Subject identifier | Who received the drug? | The identifier of the subject to whom this administration belongs. |
| Administration time | When did it occur? | The time assigned to the documented administration, using the project's stated time convention. |
| Administered amount | How much was administered? | The amount supported by the source record, with its unit represented consistently with the data specification. |
| Route | By what route? | The route recorded for this administration, using the project's defined representation. |
| Regimen context | Which regimen or instruction applied? | A relevant regimen identifier or related context; it does not itself prove that a planned dose occurred. |
| Event identity | Which administration is this? | A key or sequence value that can distinguish this administration from other records for the same subject, including records at the same time. |
The exact columns depend on the study and data source. A field may be unavailable or not applicable, but its absence should be represented according to the project's missing-value conventions. In particular, an unknown amount is not an amount of zero. A dose amount, unit, route, or other detail should not be inferred from the usual regimen unless the source supports that inference.
Administrations Are Not Plans
A planned regimen describes what was intended: for example, a schedule or instruction for future dosing. A dose-event record describes an administration documented as having occurred. These are different kinds of information, even if a scheduled dose and an observed administration happen to have matching times and amounts.
A useful design stores the planned regimen separately, or clearly labels regimen fields as planned context. When linking an administration to a regimen, retain the distinction between the regimen instruction and the event record. A regimen identifier can help explain which instruction applied, but the identifier does not establish the actual administration time or amount.
This distinction also clarifies counts. The number of planned entries is not necessarily the number of administrations. Conversely, an administration record should not be discarded solely because it differs from a plan; the discrepancy is information to preserve, not a reason to overwrite the source with the intended value.
Worked Example: One Documented Administration
Suppose a hypothetical source record documents that subject S014 received 100 mg by oral route at 08:00 on study day 2. The subject is assigned to regimen R-A. The project uses study day and clock time to record event time.
Step 1: Identify the event. The source supports one administration to S014 at the recorded time. Therefore, the dose-event table receives one row for this administration.
Step 2: Populate the event fields. The row contains subject identifier S014, the study-day-2 08:00 administration time, amount 100 mg, route oral, and regimen context R-A. An event identifier is also retained if the project uses one.
Step 3: Check the meaning. The amount and route are recorded as documented, not filled in merely because they are typical for regimen R-A. The row says that an administration was documented; it is not a row representing every dose that regimen R-A might prescribe.
Why One Record per Administration?
The record grain has a direct consequence for counting and reconstructing events. Suppose the administration history contains \(N\) documented administrations, and the table has exactly one row for each one, with no duplicate rows and no omitted administrations. Then the number of dose-event rows is \(N\). This follows directly from pairing each administration with one and only one row: the pairing is one-to-one, so it preserves the count.
If instead one row represents a subject's entire regimen, or a planned dose occasion, that one-to-one relationship no longer holds. Row counts then cannot be interpreted as administration counts, and the table may not identify when each administration occurred. This is why record grain is not a cosmetic choice: it determines which statements can be made from the data.
This equality is justified only when the table is complete for the target set of administrations, each administration is represented once, and no non-administration plan entries are mixed into it. The equality does not establish that the source itself is complete or correct. Those remain data-quality questions to investigate.
Worked Example: Separating a Schedule from Administration Records
In a hypothetical study, the planned schedule lists a 100 mg dose for subject S021 at 08:00 on each of three consecutive days. The administration log documents two events: 100 mg at 08:00 on day 1 and 100 mg at 09:10 on day 2. It contains no administration entry for day 3.
Represent the plan. The three scheduled entries belong in planned-regimen information, clearly identified as planned. They describe the intended schedule, not three confirmed administrations.
Represent the documented events. The dose-event table contains two rows: one for the day-1 administration at 08:00 and one for the day-2 administration at 09:10. Both rows carry the supported amount, route if documented, and relevant regimen context.
Interpret the difference. The day-2 event time is the time documented for that administration; it is not replaced with the planned 08:00 time. The absence of a day-3 administration entry does not justify inserting a dose-event row from the plan. Whether the day-3 entry reflects a missed, held, or otherwise unrecorded dose requires evidence and classification beyond this basic record distinction.
Repeated Times, Keys, and Data Checks
A subject identifier and time are not always sufficient to identify a unique event. Two administrations can be recorded for the same subject at the same time, or a data source can contain multiple records that share those fields. Do not automatically remove one as a duplicate merely because subject and time match. Use the event key or sequence conventions defined for the data set, and investigate whether matching rows are separate events or repeated representations of one event.
The earlier material on record keys and within-subject sequence provides the general principles: keys must distinguish records at the chosen grain, and ordering information should not be invented. For dose events, the practical implication is to preserve a source event identifier when available, or use a documented key that can distinguish administrations. If the source cannot distinguish a repeated record, flag the ambiguity for resolution rather than silently choosing an interpretation.
Worked Example: Two Records With the Same Subject and Time
A hypothetical administration log has two entries for subject S033 at study day 5, 12:00. Each entry is recorded as a separate administration with its own source event identifier, E701 and E702. Both entries list 50 mg and the same route.
Step 1: Test the grain. The source identifies two separate administrations, so there should be two dose-event rows, not one row formed by collapsing the entries.
Step 2: Preserve identity. Store E701 and E702 as distinct event identifiers, alongside the shared subject and time fields. The matching time does not erase their separate identities.
Step 3: Avoid unsupported ordering. The records establish two events at the same recorded time, but do not necessarily establish which occurred first. Preserve the source information and do not create an order unless the data support one.
Useful checks include comparing dose-event counts with source logs, checking that every event has a subject identifier and interpretable time, checking for duplicate event identifiers, and reviewing repeated subject-time combinations. Also check that regimen identifiers refer to defined regimen information and that plan-only entries have not entered the actual administration table. A check can reveal a problem, but a matching or nonmatching value alone may not explain its cause.
Alternative Representations and Their Limits
A long event table is usually the clearest representation when administrations occur repeatedly over time. Alternatives can be useful for specific purposes, but they answer different questions.
| Representation | Useful for | Limitation for administration history |
|---|---|---|
| One row per administration | Representing the time and details of each documented event. | Requires explicit event identity and careful handling of repeated subject-time values. |
| One wide row per subject with dose-time columns | A fixed, small set of visits or a presentation summary. | Becomes awkward as events vary in number and may obscure the one-row-per-event grain. |
| One row per planned regimen entry | Describing intended schedules or instructions. | Does not, by itself, establish that any listed dose was administered. |
These representations are not interchangeable. A wide table or a regimen schedule can supplement administration records, but neither should be treated as an actual dose-event table without a clear, defensible transformation. A long event table also has limits: it can faithfully organize the information supplied, but it cannot recover undocumented administrations, resolve ambiguous source entries, or establish details that were never recorded.
Common Mistakes and Failure Modes
- Turning every scheduled dose into an event. This treats intention as administration. Keep planned entries separate unless evidence documents an administration.
- Replacing actual time with scheduled time. This changes the record of what the source says occurred. Preserve the documented administration time and retain the plan as context.
- Using regimen fields as substitutes for event fields. A regimen identifier does not supply a missing administration time or prove an amount was given.
- Collapsing rows that share subject and time. Shared values do not prove that records describe the same event. Check event identity and source evidence before deduplicating.
- Filling unknown values with familiar values. A typical amount or route is not evidence for the value in an individual record. Preserve unknown or unavailable information according to the data conventions.
When a check fails, the next step is to return to the source and the field definitions. Do not make the table look consistent by changing supported event information to match a planned schedule. Record unresolved uncertainty explicitly so downstream users can distinguish a known event from an assumption or a data-quality issue.
Check Your Understanding
Answer each question using the distinction between administration records and planned information.
- A schedule lists four intended doses, but the administration log documents three. How many dose-event rows should be created from the documented log, and why?
- Two records share a subject identifier and time but have different source event identifiers. Should they automatically be collapsed into one row?
- A regimen identifier is known, but the source does not state the amount for one administration. Should the usual regimen amount be inserted as though observed?
- A planned administration is listed for tomorrow, but no administration has yet occurred. Does it belong in the actual dose-event table?
Solutions. (1) Create three dose-event rows, one for each documented administration; the fourth planned entry is not evidence of an administration. (2) No. Retain the two rows while checking the source, because the distinct event identifiers support separate event identities. (3) No. Preserve the amount as unavailable according to the data conventions; a regimen value does not establish the administered amount. (4) No. Keep it in planned-regimen information, because it is intended rather than documented as administered.