From Protocol Language to a State Diagram
A clinical protocol often describes eligibility, disease status, treatment response, and follow-up in prose. A state diagram makes the resulting process explicit: its nodes name the conditions participants can occupy, and its arrows name the state changes the protocol permits the study to represent. The diagram is not merely a clinical sketch. Its states and arrows determine what counts as a transition in the analysis, so unsupported arrows can encode assumptions the protocol never made.
The construction should begin with the study question and the protocol’s operational definitions. An arrow requires support from an event rule or a clearly specified clinical pathway. A plausible clinical event is not automatically a permitted transition. Likewise, when the protocol leaves a pathway unclear, the diagram should show that uncertainty rather than silently resolving it.
For a participant, write \(X(t)\) for the state occupied at time \(t\), using the protocol’s time origin and observation rules. The diagram describes possible changes in \(X(t)\). A state should represent a condition or status relevant to the study question, not simply every measurement, visit, treatment, or recorded event. If repeated measurements leave the participant in the same defined condition, they do not by themselves create a state transition.
State definitions should be operational: a reader should be able to determine from the protocol and available records which state applies at a given time. The states should be mutually exclusive at a given time, and they should cover the participants and conditions that the study intends to represent. If a participant can occupy two proposed states simultaneously, or cannot be classified in either, the definitions need revision or an explicitly defined additional state.
A Protocol-First Construction
Before drawing arrows, identify the target population, the time origin, the outcome or clinical process of interest, and the follow-up endpoint. Then extract the protocol’s event definitions and ask, for each proposed state change: what exact event moves a participant out of the origin state, and what evidence establishes entry into the destination state? This guards against confusing a recorded event with a fully specified transition.
Specify which participants and period of follow-up the diagram represents, and use the protocol’s stated time origin.
Use the protocol’s criteria for statuses such as active disease, controlled disease, or alive. Check that each relevant participant can be classified at a given time.
Record what constitutes entry into a state, a change of status, a recurrence, or the end of follow-up. Preserve distinctions the protocol makes.
For each event, identify both the origin and destination states. If either is unspecified, mark the transition as unresolved and seek clarification.
Confirm that the initial state is defined, that each arrow matches an allowed event sequence, and that any terminal-state claim follows from the protocol.
The protocol may make some transitions impossible, for example by defining a treatment phase that must be completed before a later phase begins. That is different from silence: an explicitly prohibited pathway can be excluded, while an unaddressed pathway remains unknown. Record the distinction in the diagram notes or accompanying specification.
Worked Examples
Worked Example: Disease Control and Explicitly Defined Death Pathways
Hypothetical protocol. A study follows participants from treatment initiation. At each assessment, disease is classified as active or controlled using prespecified criteria. The protocol defines progression from controlled to active disease as relapse, permits disease control after active disease, and states that death may occur from either disease status and is recorded as an endpoint. Construct the states and permitted arrows.
The protocol supports three states: \(A\), active disease; \(C\), controlled disease; and \(D\), death. The time origin is treatment initiation, but the initial disease state is unspecified for the hypothetical participants considered here. The explicit rules support \(A\to C\) for control, \(C\to A\) for relapse, \(A\to D\) for death while active, and \(C\to D\) for death while controlled.
Because death is defined as an endpoint with no subsequent modeled state, \(D\) is absorbing in this diagram. The arrows into \(D\) are justified here by the protocol’s explicit statement that death can occur from either disease status; they would not follow merely from the fact that death is recorded. The diagram represents permitted pathways, not a claim that each pathway must be observed in the study.
Worked Example: Death Recorded but Its Origin Unspecified
Hypothetical protocol. A study classifies participants as having active disease or controlled disease at scheduled visits. It records deaths, and status follow-up ends at death. The protocol does not state the disease status at death, whether status is assessed immediately before death, or from which status death can occur in the process being modeled. What can the diagram contain?
The protocol supports states \(A\) and \(C\) for the observed disease statuses, and supports an endpoint record for death. But it does not establish either \(A\to D\) or \(C\to D\): ending status follow-up at death does not identify the origin state or establish an arrow from each possible status. Even adding a death node \(D\) to the diagram does not resolve the missing origin.
The appropriate representation is therefore \(A\) and \(C\), with any protocol-supported disease-status transitions, plus an explicit note that the death transition’s origin is unresolved. The analyst should ask whether status at death is available, whether the protocol permits death from both statuses, and how death is intended to enter the modeled process. If clarification establishes that both origins are permitted, add both arrows. If it establishes only one, add only that arrow. Until then, do not draw either as a supported transition.
This distinction matters because the diagram is a specification of what the study defines, not a guess about what biology makes possible. A missing arrow in this case is not evidence that death cannot occur from that state; it records an information gap that needs resolution.
Worked Example: A Recurring Clinical Event
Hypothetical protocol. After an acute episode, participants are classified as symptomatic or recovered. A new episode can occur after recovery, and participants can recover again. The protocol does not define a separate state for episode number, but it records each transition between symptomatic and recovered status. Build the diagram for status over follow-up.
Let \(S\) denote symptomatic and \(R\) denote recovered. The stated events support \(S\to R\) for recovery and \(R\to S\) for a new episode. The state set and permitted arrows are
A possible path is \(S\to R\to S\to R\). It is allowed because the protocol explicitly permits another episode after recovery and another recovery afterward. By contrast, this two-state diagram does not encode how many episodes have occurred: participants with different episode counts can occupy the same status state. If episode count is essential to the study question, it must be represented in the state definition or otherwise recorded as history. The protocol as stated does not justify adding separate states for first episode, second episode, and later episodes.
Why the Diagram Is a Specification, Not a Markov Guarantee
A state diagram defines the states and possible jumps; it does not by itself show that the current state is a sufficient summary of history. In a Markov model, the future distribution conditional on the present state does not additionally depend on earlier history (under the model’s stated time structure). If, for example, the chance of relapse depends on time spent in controlled status or the number of prior episodes, a diagram with only a controlled state may omit relevant history. Earlier material on the Markov property and state refinement addresses that modeling question. For this task, the key point is to make the protocol-defined state distinctions explicit before making a Markov assumption.
A short justification for requiring protocol support for arrows is that an observed path must be a sequence of events recognized by the study definition. If the protocol defines a transition only when event \(e\) occurs from state \(i\) and produces state \(j\), then the corresponding jump is \(i\to j\). If it records \(e\) but does not identify \(i\), it cannot establish that particular origin-to-destination pair. Thus an arrow from every plausible origin would add information not entailed by the event record.
When a state definition is revised, reconsider all arrows connected to it. Splitting “controlled” into “controlled with prior relapse” and “controlled without prior relapse,” for example, changes which transitions are possible and how records are classified. Conversely, combining states can hide differences relevant to the study question. State aggregation and the consequences of hidden heterogeneity are distinct from the basic protocol-to-diagram translation, but they are reasons to document the chosen definitions carefully.
Diagnostics, Alternatives, and Limitations
Review a draft diagram against the protocol and, where available, sample records. For each arrow, point to the rule that supports it and specify the event that determines its timing. Then check that each participant has a defined initial state, that state criteria do not overlap, and that every intended record can be classified. A pathway that appears in records but not in the diagram signals either a coding error or a missing protocol rule; it should not be handled by silently adding an arrow.
- Unexplained arrows: If no protocol criterion supports an arrow, remove it or label it unresolved pending clarification.
- Unclassified records: If participants can be in multiple states or none of the states, revise the operational definitions before proceeding.
- Endpoint ambiguity: A recorded endpoint does not automatically identify its immediately preceding state. Clarify the event origin and ascertainment rules.
- Impossible-looking paths: Check whether the path is prohibited by the protocol or merely unobserved in the available data. Absence of observed examples alone does not prove impossibility.
- Excessive detail: A node for every visit or measurement can mistake repeated assessment for a clinical transition. Include a new state only when the study question and event rules require it.
A prose event table can be useful alongside a diagram: list each event, its required origin, its destination, and the protocol clause or definition that supports it. A diagram is more effective for checking overall pathway structure; the table is often better for recording operational criteria and unresolved details. Neither substitutes for the protocol. The diagram’s limitations include ambiguity in the source document, incomplete event ascertainment, and differences between what the protocol permits and what participants actually experience.
Check Your Understanding
Answer each question using the protocol-first rule. Brief solutions follow.
- A protocol allows movement from “stable” to “progressed” and records death, but does not specify status at death. Should the diagram automatically include stable \(\to\) death? Why?
- A protocol explicitly states that participants in either “active” or “controlled” status may die, and death ends follow-up. What death arrows are supported, and what kind of state is death?
- Participants are measured at monthly visits, but the protocol defines no change in clinical status between visits. Does each visit create a new state transition?
- A protocol permits relapse after recovery but does not track the number of previous relapses. What arrows are supported in a two-state symptomatic/recovered diagram, and what information does it omit?
- What is the difference between a pathway the protocol explicitly prohibits and a pathway it does not mention?
Solutions. (1) No. Recording death without specifying its origin does not establish stable \(\to\) death; the origin is unresolved and needs clarification. (2) Include active \(\to\) death and controlled \(\to\) death, because both origins are explicitly permitted; death is absorbing if no later modeled state follows it. (3) No. A visit or repeated measurement is not a transition unless it changes the protocol-defined state. (4) Include symptomatic \(\to\) recovered and recovered \(\to\) symptomatic; the diagram represents repeated status changes but not the number of prior relapses. (5) An explicit prohibition supports excluding the pathway; silence leaves it unspecified, not proven impossible.