Trial Design

Shape the trial structure

flowchart LR
    Trial[Trial] --> Design[Design]
    Trial --> Decisions[Decisions]
    Trial --> Journeys[Participant journeys]
    Trial --> Randomization[Randomization]
    Design --> Generate[Generate structured design]
    Generate --> Review[Review and save]
    Design --> Compare[Compare and restore]

The Plan step separates four authoring concerns while retaining one governed canonical trial-design transaction:

• Design owns the selected design’s Overview metadata and core structure: design name, primary status, design characteristics, arms, epochs, elements, visits, activities, timelines, concept mappings, and acquisition configuration.
• Decisions owns typed conditions, decision points, outcomes, transitions, protocol events, and applicability.
• Participant journeys owns alternate and overlapping paths, nested periods and cycles, encounter groups, event anchors, and review scenarios.
• Randomization owns allocation plans, stages, factors, strata, eligible populations, ratios, sequences, and triggers. Operational allocation lists, blinding secrets, kits, and supply remain outside this planning model.

Each page shows and generates only its own sections. Saving retains the other three scopes unchanged, so stable references between decisions, journeys, randomization, and the core design are not lost.

Every governed design appears as a tab and has an Overview section. A new trial starts with the neutral name Design 1 rather than reusing the trial title. Edit its Name and USDM Characteristics there; the governed name identifies the corresponding design in USDM export. A non-primary design can also be promoted with Primary; the current primary remains selected until another design is promoted. The separate Matrix section shows element assignments by arm and epoch. These fields use the same reviewed page save as the rest of the Design form. Use the tabs to move between designs and the page menu to create another design. Delete design removes the selected non-primary design while retaining its governed history. To delete the current primary, promote another design first.

Decisions and Participant journeys remain sections of the selected design rather than separately named page-level records. Their headers, and the Randomization header, show the selected design context; the primary context is prefixed with Primary:.

Randomization plans are addressable records within the Randomization page. The first visit shows an empty state; creating a plan opens the same naming step used for later plans and suggests Randomization plan 1, then increments the number. Tabs appear after confirmation, including for a single plan. Opening a plan keeps its identity in the URL and presents its Overview, Factors, Strata, and Stages as one review surface. Create another plan from the page menu; delete the open plan from that same governed action menu.

Keep the design surface separate

The design module exists because structural design work deserves its own governed place instead of being diluted inside the broader trial record.

Use it when the structure changes

Use this workflow when the trial design itself is evolving and the team needs a reviewable record of those changes.

Generate and review the complete design

Design generation can propose arms, epochs, elements, assignments, schedule timelines, visits, activities, sampling profiles, and cycle definitions. Decision logic, Participant journeys, and Randomization provide their own scoped Generate or Improve action. A section action updates only its exact nested collection, not sibling collections that happen to share the same parent object.

Use Improve on a verification finding to address the affected field in its owning generation section. For example, a finding about an arm type targets Arms even when the finding is grouped under Trial design. The review grouping does not broaden the request to the whole design.

TrialStack generates independent Decision sections together, then generates outcomes and transitions after the conditions, decisions, and protocol events they reference. Participant journey timeline variants are generated before scenarios and periods, with encounter groups following their periods. TrialStack resolves generated relationship references to the unique governed records they identify, keeps activity definitions and their scheduled placements together, and preserves element-to-intervention, parent, predecessor-visit, timeline, sampling-profile, decision, journey, and allocation links. Element intervention and visit predecessor links must belong to the same trial.

Randomization generation proposes the selected plan in dependency order: Overview first, then Factors and Strata, then Stages. Objective, endpoint, design population, cohort, protocol-event, condition, outcome, and arm relationships must match one current governed record. TrialStack keeps existing valid links and omits unresolved or ambiguous proposals with a scoped finding. In the form, grouped endpoint choices retain their authored level and order, relationship choices include their supporting description, and a relationship control remains disabled until its owning records exist.

Incomplete generated subgraphs are retained with reviewer findings instead of being completed with invented values or silently deleted. Named decisions keep their valid outcomes and transitions even with fewer than two outcomes; the gap is reported as a blocking finding at use. Participant journey variants that cannot be linked to one governed schedule timeline, and planned visits without a source-supported nominal day, are still omitted with their unsupported parent. Meaningful sibling content remains reviewable, and every remaining required planned visit must have activity coverage before the generated schedule can be accepted.

When a proposed arm is saved under a governed identity, TrialStack remaps visit applicability to that persisted arm instead of retaining the temporary generated id. Generated findings, section markers, and source-run provenance travel with the same governed design snapshot so reopening the page does not detach the reviewed design from the run that produced it.

Review generated sections in the same form used for authored changes. Saving keeps the governed design, schedule, and activity relationships together instead of treating generated output as a separate document. Fields omitted by a generated patch do not erase schema-managed nested data; an explicit reviewed clear remains distinct from omission.

A generated randomization plan can be saved as a named draft before every stage, factor level, or allocation is defined. TrialStack assigns stable plan, factor, and stage identities deterministically and keeps the exact missing nested content as readiness findings for later review instead of discarding the draft.

Section headers retain an AI Generated badge after the design is saved or reopened. Hover over the badge to review any field- or section-specific generation findings, including unsupported content and recommended follow-up, and use its run link to inspect the originating generation evidence.

Restore a governed version

Restoring from Activity recreates the captured design structure, including versioned arms and schedule linkage fields, and records the justification supplied during restore. The form refreshes to the restored server state so the visible baseline matches the new governed version.

Watch the downstream impact

Design updates can affect later trial modules, so teams should treat them as governed changes and use history or restore when a design decision is being revisited.

Standard values

Timing types, timing relationships and design characteristics use field-specific standard lists. Each choice retains its code system, release and codelist. Built-in standard subsets are distinguished from imported catalog releases; an unavailable imported release is never replaced automatically with a subset.

A saved historical reference remains visible when its source is unavailable. Changing the value requires a valid choice from the field’s bound catalog. Saved enum choices, including arm types, show their retained source release. If an old snapshot has no source evidence, it is shown as unversioned rather than attributed to the current release. Saving unrelated changes does not reclassify the existing value. No manual mapping approval is required.

USDM export preserves authored terminology versions. An observational design without a time perspective produces a finding; it is not assumed prospective.

Arm versions retain their type evidence at the time of saving. Restoring a version retains that evidence; older versions without evidence remain readable. Copying a controlled Trial field to a destination with an incompatible pinned binding is rejected.