Encode Dose Events in Longitudinal Records

Why Event Coding Matters

A longitudinal pharmacokinetic data set is more than a list of concentrations. It also needs to tell the analysis when a dose was administered, when a sample was collected, and what other relevant changes occurred. Each record contributes to a subject’s timeline. If a dose is mistakenly represented as a sample, or a sample is coded as a dose, the analysis may process a different sequence of events from the one that occurred.

The earlier material on linking subjects, samples, doses, and occasions establishes why those records must be connected to the correct subject and study period. Here the focus is how each record declares its event type and carries fields appropriate to that type. The examples use elapsed time in hours from a defined study origin; they do not address how timestamps are converted to elapsed time or how records at the same time are ordered.

A common analysis-ready layout uses one row per event and includes fields such as subject identifier, time, event code, dose amount, compartment, observed value, and a missing-dependent-variable indicator. The exact field names and code meanings depend on the software and the data specification. They must be documented and applied consistently; a number in an event-code column has no universal meaning unless the analysis conventions define it.

Event Types and Record Fields

In a widely used NONMEM-style convention, EVID records the event type: EVID=0 denotes an observation record, EVID=1 a dose record, and EVID=2 another event. That convention also defines reset-related codes, but their use is outside this tutorial’s focus. Other software or project-specific formats may use different codes, so an analyst should verify the data dictionary and the model’s interpretation rather than assume that a code is self-explanatory.

The event code is not a substitute for the other fields. In a typical record, AMT stores an administered amount, DV stores an observed dependent variable such as concentration, and CMT identifies the relevant model compartment when the model uses compartments. A dose row and an observation row generally populate different fields. For example, an observation row may have a concentration in DV and no administered amount, whereas a dose row records the administered amount and has no observed concentration.

In some analysis formats, MDV indicates whether a dependent-variable value is available for the likelihood contribution: commonly, MDV=0 marks an observation to be analyzed, while MDV=1 marks a record with no dependent-variable observation. It is a separate concept from the event type. A dose row is not made a dose by setting MDV=1; its event code and dose fields must identify it as a dose. Likewise, an observation row needs a valid observation value and the appropriate observation status.

A visit, phone call, or administrative note does not automatically need its own model event row. Include a row when the event is needed to represent the analysis timeline—for example, if it marks a model-relevant change—and ensure that the analysis knows what the row means. A calendar entry with no defined model use can remain in a separate operational data source. Conversely, if a relevant change is represented only in a note and omitted from the analysis data, the model cannot use it as an event.

How Coding Reconstructs a Timeline

An analysis program typically uses dose records to update the model’s input history and observation records to compare model predictions with measured values. This distinction gives a direct justification for separate event types: the two kinds of rows have different computational roles. A dose record supplies an input at a time; an observation record supplies a value against which the model is evaluated. Treating them as interchangeable would not preserve those roles.

This is a conceptual mapping, not a pharmacokinetic equation. Its practical consequence is that a record must be checked as a whole. For example, a row with a dose event code but no usable dose amount is not a complete dose record. A row coded as an observation but lacking an observation value cannot supply the intended measured response. A timeline sorted by time can reveal the sequence, but it cannot repair an incorrect event type or missing field.

Checks, Failure Modes, and Alternatives

A practical quality-control pass should test both the coding rules and the sequence they imply. Useful checks include:

• Confirm that each subject’s records use only event codes allowed by the study’s data specification.
• Check that dose records have the required dose fields and that observation records have the required measured-value and observation-status fields.
• Check that nonapplicable fields follow one documented convention, rather than alternating unpredictably between blank, zero, and other placeholders.
• Review each subject’s records in time order and compare the resulting event sequence with the source records or dosing and sampling schedule.
• Flag other-event records for which the code is present but the event’s meaning or associated fields are not defined.

These checks detect different kinds of problems. A code-frequency summary can reveal an unexpected event code, but it cannot show whether the codes were assigned to the right rows. A field-consistency check can identify a dose row with no amount, but cannot establish whether the recorded amount matches the source. Timeline review helps assess sequence, but source-data comparison is still needed to confirm that the sequence represents what happened.

An alternative is to keep doses and samples in separate files and combine them during analysis. Separate source files can be useful for data capture, but the analysis still needs a consistent way to merge them into one interpretable event history. A single event-level table makes the sequence explicit and is convenient for many modeling workflows; it also creates a risk that inconsistent row conventions will be propagated unless validated. Neither storage arrangement removes the need for a data dictionary and checks.

Event coding has limits. A well-coded row cannot recover an event that was never recorded, determine whether source documentation is correct, or resolve ambiguous timing on its own. It also does not specify every modeling choice associated with a dose. Keep the coding scheme focused on identifying event type and linking it to the correct fields; represent additional details only according to the project’s defined data conventions.

Common Mistakes

• Using a missing-value indicator as an event code. Setting MDV=1 does not declare that a row is a dose. The event-type field must do that.
• Assuming the column name guarantees interpretation. A concentration stored in DV is not necessarily analyzed as an observation if the event code says otherwise.
• Putting every visit or administrative contact in the model event table. Include a record only when its role in the analysis is defined; otherwise it can add rows without useful model information.
• Allowing undocumented placeholders. If zero, blank, and missing all appear in a field, the analyst may be unable to distinguish a meaningful zero from a nonapplicable or unavailable value.
• Checking codes without checking fields. A valid event code paired with incompatible or incomplete fields still produces an invalid or misleading record.