From Protocol to Recorded Data
A target-trial protocol states what would be assigned, to whom, when follow-up begins, and how outcomes would be measured. An observational database does not record that protocol directly. It records encounters, diagnoses, prescriptions, procedures, and other traces of care. The practical task is to connect each protocol element to fields that can represent it, while making the gaps and assumptions visible.
A mapping is not a claim that the database perfectly reproduces a randomized trial. It is a documented argument that particular fields, interpreted under specified rules, represent particular protocol elements closely enough for the intended question. A field name alone is not evidence of a valid mapping: “medication date,” for example, could mean an order date, dispensing date, or administration date, each of which represents a different event.
The mapping should be prepared before estimating effects. It makes operational choices inspectable, helps reveal impossible or ambiguous definitions, and distinguishes limitations of the data from limitations of the causal design. The earlier material on target-trial protocols supplies the hypothetical trial elements; the focus here is how to represent them in observed data.
What a Useful Mapping Records
For each element, record both the protocol definition and the proposed data representation. A compact mapping table is usually more useful than a list of available database columns because it shows where each field enters the emulation and what interpretation it supports.
| Mapping item | What to specify | Why it matters |
|---|---|---|
| Protocol element | Eligibility, treatment strategy, assignment, time zero, follow-up, outcome, or causal contrast | Identifies exactly what the field is intended to represent |
| Data source and field | Table, variable, provider, and relevant code system or version | Allows another analyst to locate and understand the source |
| Operational rule | Codes, date rules, look-back period, value thresholds, and handling of duplicates | Turns a broad concept into a reproducible classification |
| Timing | When the value is measured relative to eligibility, assignment, and follow-up | Clarifies whether information is baseline, treatment, or outcome data |
| Representation status | Direct measure, proxy, partially observed, or unavailable | Prevents a proxy or data gap from being mistaken for direct observation |
| Limitation and response | Likely error, validation plan, alternative definition, or resulting scope restriction | Connects the mapping to a defensible analysis decision |
The data dictionary and source documentation are starting points, not substitutes for this work. A diagnosis code may capture a documented clinical label rather than the underlying condition itself. A prescription order may show a clinician’s intent, while a dispensing record shows a medication was supplied; neither necessarily establishes that the patient took it. The mapped concept must match the protocol’s strategy, not merely resemble its wording.
Worked Example: Mapping Eligibility and Time Zero
Suppose a hypothetical protocol asks whether initiating treatment A rather than treatment B changes the risk of a specified event within 180 days among adults with condition C who are eligible for either treatment. The database contains encounter dates, age, diagnosis codes, medication orders, and dispensing dates.
Eligibility. Define adults using age recorded on the candidate index date. Define condition C using a prespecified diagnosis-code list during the 365 days before that date. The diagnosis list is an operational representation of the protocol’s clinical condition; it does not prove the condition was clinically present if coding is incomplete or inaccurate. The 365-day window and code list must therefore be written down, not left to an analyst’s discretion.
Treatment and time zero. If the strategy is initiation, a dispensing record for A or B can serve as a proxy for treatment initiation. Define the index date as the first qualifying dispensing date, and use that same date as time zero for eligibility and follow-up. If dispensing data are unavailable, an order date is a weaker proxy because an order need not be filled; the mapping must say so. People with both strategies recorded on the same date require a prespecified rule, such as classifying them as ambiguous and excluding them from the primary definition.
Follow-up and outcome. Follow-up runs from the index date through day 180 under the protocol’s censoring rules. A qualifying event code recorded after time zero may represent the endpoint, but the code list, care settings included, and event-date convention must be specified. The protocol-to-data mapping can establish that the database has fields for these elements; it cannot establish that the codes are accurate or that all eligible patients appear in the database.
Timing, Measurement, and Coding Rules
Every mapped field needs a time interpretation. A baseline covariate must be measured before the protocol’s time zero if it is to represent a characteristic present at assignment. For a variable \(X\), a measurement at time \(t_X\) is baseline for an index time \(t_0\) only when \(t_X < t_0\), subject to the protocol’s specified measurement window. A value recorded after \(t_0\) may reflect treatment or subsequent health changes; it should not silently be substituted for a baseline value.
This temporal requirement follows from the meaning of a baseline characteristic. The protocol uses baseline information to describe or adjust for pre-assignment differences. If the recorded value is measured after assignment, it may be affected by assignment. Treating it as though it preceded assignment changes the variable’s role and can distort the intended comparison. The mapping should therefore identify the date attached to each observation, define the allowable window, and state what happens when no qualifying measurement exists.
Coding rules also need enough detail to reproduce the classification. State whether a qualifying event requires one code or repeated codes, whether inpatient and outpatient records count, how conflicting entries are handled, and whether dates are based on service, order, or entry into the database. For laboratory values, specify units, the acceptable window, and rules for multiple results. When code systems change over time, document the versions or calendar periods used.
Worked Example: Separating an Order From Treatment Received
Consider a hypothetical emulation whose protocol compares starting a prescribed medicine with not starting it at time zero. A claims database records a prescription order on day 0 for one person and a dispensing claim on day 4.
The order directly supports the statement “a clinician ordered the medicine.” The dispensing claim supports the narrower statement “the medicine was dispensed on day 4.” Neither field directly records ingestion. If the protocol’s strategy is defined as assignment to an order, using the order date may be a direct operational measure of that recorded decision. If the strategy is defined as receiving treatment immediately at time zero, a day-4 dispensing claim is only a proxy and does not establish treatment on day 0.
The discrepancy is four days: \(4 - 0 = 4\). That arithmetic does not determine which field is correct; the protocol definition does. The mapping should label the order and dispensing fields separately, specify which defines exposure, and state the unobserved feature—actual medication use. If the strategy cannot be represented with the available fields, report that limitation or refine the question to one the data can support. Do not describe an order as proof that treatment was taken.
Proxies and the Consequences of Measurement Error
A proxy can be useful when the intended concept is not directly recorded, but it introduces a measurement assumption. The analyst must say what the proxy is expected to capture, why it is plausible, and what errors remain possible. Validation against a more direct source, such as a blinded record review in a suitable sample, can assess the proxy’s performance. If validation is not feasible, alternative operational definitions can show whether conclusions depend strongly on one coding choice, although agreement across definitions does not prove accuracy.
For a binary outcome, sensitivity is the probability that the database marks an event when the event truly occurred; specificity is the probability that it marks no event when none occurred. Even when these properties are the same in both treatment groups, outcome misclassification can change the measured risk difference.
Worked Example: Quantifying Outcome Misclassification
Suppose, purely hypothetically, the true event risks are 0.20 under one strategy and 0.10 under another. Assume the database outcome has sensitivity \(Se=0.80\) and specificity \(Sp=0.95\) in both groups. For illustration, also assume these values apply equally to both strategies and that the recorded outcome is classified using the same rules.
For the first strategy, the recorded event risk is $$ 0.80(0.20) + (1-0.95)(1-0.20) = 0.16 + 0.05(0.80) = 0.20. $$ For the second strategy, it is $$ 0.80(0.10) + (1-0.95)(1-0.10) = 0.08 + 0.05(0.90) = 0.125. $$
The true risk difference, first strategy minus second, is \(0.20-0.10=0.10\), or 10 percentage points. The recorded risk difference is \(0.20-0.125=0.075\), or 7.5 percentage points. Under these assumptions, the recorded contrast is smaller by 2.5 percentage points. This calculation isolates one measurement issue; it does not establish that the observed contrast is causal or that the assumed sensitivity and specificity are known in an actual application.
Unavailable Features, Diagnostics, and Alternatives
Some protocol features have no corresponding field. Routine records may not reveal why a clinician chose a treatment, whether a patient preferred one option, whether an assignment was concealed, or whether a patient followed instructions. Mark such features as unavailable rather than implying that a nearby field measures them. An unavailable feature may be irrelevant to the data representation of a particular element, or it may make the proposed emulation incapable of addressing the stated question.
Before analysis, audit the mapping for contradictions and unsupported leaps:
- Coverage: Is every protocol element linked to a field, a clearly named proxy, or an explicit “unavailable” status?
- Temporal order: Do eligibility and baseline fields precede time zero, and do outcome fields fall within the stated follow-up period?
- Meaning: Does each field represent the protocol concept, or merely a related event such as an order instead of receipt?
- Reproducibility: Could another analyst implement the code lists, windows, and tie-breaking rules without guessing?
- Feasibility: Are the fields populated for the intended population and calendar period, and can key dates be linked reliably?
- Validation: Is there an appropriate reference source for checking an important proxy or code-based definition?
The response to a mismatch depends on its importance. If a field is a defensible but imperfect proxy, retain the protocol concept, label the proxy, and assess its limitations. If a better source is available, link or validate against it. If a rule is ambiguous, prespecify a primary definition and a limited set of alternatives. If the defining feature is absent and cannot be approximated credibly, revise the estimand or question transparently rather than treating an unsupported proxy as equivalent.
These choices differ from simply choosing a statistical adjustment method. Matching or another analysis approach cannot repair a treatment, covariate, or outcome that was misrepresented in the source data. Nor does a detailed mapping prove exchangeability, positivity, or correct model specification; those are causal-design and analysis requirements. The mapping supports those later assessments by showing what was actually measured and when.
A strong mapping is therefore both a design record and a diagnostic tool. It can reveal that the database does not contain an eligible population, that treatment cannot be dated at the intended time, or that the endpoint is only weakly measured. Finding such a limitation early can prevent a precise analysis of a question the data do not answer.
Check Your Understanding
Answer each question, then compare your reasoning with the solutions below.
- A protocol defines baseline blood pressure as measured before time zero. The database’s only blood pressure value is from two weeks after time zero. Can it represent baseline blood pressure without qualification? Why?
- A database has prescription orders but no dispensing records. Give one statement the order field supports and one it does not establish.
- A binary outcome has \(Se=0.90\), \(Sp=0.90\), and true risk \(p=0.10\). Calculate the recorded event risk using the mapping equation.
- Name two details needed to make a diagnosis-code outcome definition reproducible.
Solutions. (1) No. The measurement is after time zero, so it may reflect post-assignment information rather than a baseline characteristic; it can only be described as a later measurement or proxy. (2) It supports that a prescription was ordered; it does not establish that it was dispensed or taken. (3) \(0.90(0.10)+(1-0.90)(1-0.10)=0.09+0.10(0.90)=0.18\), so the recorded risk is 0.18, or 18%. (4) Examples include the code list and code-system version, the relevant care setting, the event-date convention, and whether one or repeated codes are required.