Exports

Exports is a governed page in the trial Build step. It keeps export history and conformance evidence attached to the governed trial snapshot. Standards preferences are edited in the Standards section of Trial Summary, while Build > Control coordinates readiness, amendment impacts, governed owners, and delivery state without becoming another authoring form.

Keep evidence together

flowchart LR
    Trial[Governed trial] --> Preferences[Summary standards section]
    Trial --> Control[USDM and DDF]
    Trial --> Export[Standards export]
    Control --> Export
    Export --> Manifest[Manifest and checksum]
    Export --> Details[Preview, findings, and CORE evidence]

The trial summary keeps authored standards preferences authoritative. Control uses the same governed section layout as the rest of the trial: it identifies the current authoritative version and routes verification, change review, and delivery back to their existing owner pages. Exports map the governed snapshot into a selected standards profile and retain their manifest and checksum. An authored protocol version remains the external version identity in USDM; TrialStack’s internal governed revision is retained for lineage and is used as the export version only when no protocol version was authored.

Available exports

The creation dialog exposes only artifacts with a concrete, supported purpose:

Profile	Output	Intended use
USDM 4.0	JSON	Versioned exchange of TrialStack’s mapped trial-definition scope against the pinned USDM 4.0 schema and CORE rules
SDTM Trial Design	ZIP containing Dataset-JSON 1.1, SAS XPORT v5, Define-XML 2.1, manifest, and checksums	Review and delivery of the TA, TE, TV, TI, and TS trial-design domains
SDTM mapping	Canonical JSON or review XLSX, plus capability-gated neutral JSON handoff	Govern participant-domain mapping metadata and external execution expectations without participant data
ADaM build configuration	Review JSON/XLSX, draft Define-XML, and capability-gated neutral JSON handoff	Govern the exact SDTM-to-ADaM metadata contract and deliver it to an external build system
Electronic SAP	JSON, XLSX, DOCX, or PDF	One checksummed ESapSpecification from pinned Trial and Trial Statistical versions plus the fixed eSAP profile
ODM 2.0 study definition	XML	Vendor-neutral exchange of the governed study-definition scope supported by TrialStack
Viedoc workflow scaffold	ODM 1.3.1 + SDM-XML 1.0 XML	Importable visit workflow and governed timings for Viedoc Study Designer; forms, edit checks, and RTSM are excluded
Viedoc design	ODM 1.3.1 + SDM-XML 1.0 XML	Statically validated workflow, scheduled activities, and exact pinned Form placements
REDCap	ZIP	Deterministic dictionary, event/instrument mapping, repetition, manifest, findings, lineage, and checksums
ICH M11 CeSHarP electronic protocol	JSON, XLSX, DOCX, or PDF	One versioned TrialStack specification aligned to the pinned ICH M11 profile; not an official ICH serialization

USDM Schedule Timeline, FHIR Vulcan Schedule of Activities, and the historical EDC ODM Handoff wrapper are not offered in the creation dialog. Schedule projections remain visible in the governed design and activities surfaces. The current FHIR Vulcan SoA implementation guide is not a stable production conformance target. Viedoc is exposed separately as a workflow scaffold so its deliberately limited content is visible before export.

ICH M11 defines the CeSHarP protocol template and technical component requirements, but does not prescribe TrialStack’s JSON or workbook serialization. TrialStack therefore compiles one versioned M11ProtocolSpecification from the pinned trial snapshot and Step 5 profile, then renders JSON, XLSX, DOCX, and PDF with the same semantic checksum and finding report. JSON is the complete TrialStack specification and XLSX is its review workbook; neither is presented as an official ICH serialization. DOCX and PDF contain reviewer-facing protocol content and omit technical component tables, hashes, and mapping paths. The structured representations and artifact metadata retain the source-locked 575-component dispositions, authored values, applicability, rule results, and human-review requirements. These checks are never presented as official ICH conformance or certification.

Electronic SAP export follows the same pinned-profile principle without asking the user to select a document template. TrialStack captures the exact Trial and Trial Statistical versions and the immutable eSAP profile, then renders JSON, XLSX, DOCX, and PDF from one first-class ESapSpecification with the same semantic checksum and findings. The initial section registry is informed by the checksum-pinned TransCelerate SAP Core TEE v005 as advisory evidence, not as a normative standard or conformance target. Participant data and statistical execution remain outside the artifact.

Understand the coverage boundary

Standards support is profile-specific. TrialStack names the exact source snapshot, output, validator, and retained evidence rather than claiming general CDISC, ICH, or vendor compliance.

The checksum-locked USDM 4.0 claim packet is currently inactive while the current-only contract refactor is requalified and independently reviewed. TrialStack therefore does not currently publish a 100% parity claim. The retained evidence continues to report property coverage, schema, CORE, semantic-reference, retained round-trip, atomic-application, divergent multi-design, public-protocol, and schedule-corpus results separately.

Capability	Current boundary	Not currently claimed
USDM	USDM v4.0 JSON from the governed canonical trial, complete pinned JSON Schema preflight, and CDISC CORE evidence	Complete coverage of every optional USDM design pattern or an unreleased USDM version
ICH M11	First-class TrialStack M11ProtocolSpecification JSON plus XLSX/DOCX/PDF representations and source-locked Step 5 applicability and mapping evidence	An official ICH serialization, certification, or protocol approval
Electronic SAP	First-class ESapSpecification JSON plus XLSX/DOCX/PDF review representations from pinned Trial, Trial Statistical, and eSAP profile identities	A user-selected SAP template, participant data, statistical execution, or TransCelerate conformance
SDTM Trial Design	TA, TE, TV, TI, and TS in the retained delivery package	TD or TM without governed disease-assessment or milestone semantics
SDTM mapping	Versioned domain, variable, source, terminology, unit, record-selection, lineage, and findings metadata; neutral handoff to an exact capability-governed system version	Participant records, transformation programs, populated SDTM datasets, operational CORE results, or vendor-runtime compatibility
ADaM build	Versioned datasets, variables, stable SDTM row identities, target-neutral derivation narratives, populations, treatments, parameters, value-level metadata, planned outputs, readiness evidence, and a neutral handoff pinned to exact Analysis, SDTM mapping, relationship, and system versions	Participant data, executable transformation code, populated ADaM datasets, operational validation, submission-ready Define-XML, or named vendor compatibility
ODM	Versioned trial-definition XML validated against the complete pinned XSD graph	Subject data, operational edit checks, calculations, roles, alerts, or direct EDC deployment
Viedoc	Statically validated workflow scaffold and separate design profile with pinned Forms for ODM 1.3.1 + SDM-XML 1.0	Publish-ready deployment, edit-check/runtime parity, RTSM, or an unrestricted compatibility claim
Acquisition automation	Target-neutral package with governed Forms, placements, rules, calculations, contact-owned role intent, computerized-system-connection-owned source mappings, concept mappings, lineage, QC, and a checksummed target handoff manifest. Viedoc and REDCap have released static package adapters; other target families are canonical handoffs only.	Operational parity or direct deployment across EDC, eCOA/ePRO, IRT, LIMS, eSource/EHR, imaging, or DHT systems without a named, version-pinned adapter, qualification, package validation, and authorized round trip

The released standards baseline used for planning is USDM v4.0, SDTM v2.0, SDTMIG v3.4, CDASH Model v1.3, CDASHIG v2.3, and CDISC Controlled Terminology P61 dated 27 March 2026. TrialStack can import an exact authorized CDISC Library Biomedical Concept and SDTM Dataset Specialization release into immutable governed catalogs, calculate a deterministic checksum, and retain mappings from activities and Form fields to specialization variables. The configured credential returned the CDISC Library members-only response for the documented v1 and v2 package-list endpoints on 15 August 2026. TrialStack therefore does not publish unobserved catalog counts or a release checksum; authorized import, count/checksum review, and licensing review remain required before claiming concept-level parity for the 6 April 2026 release.

The CDISC USDM Schedule of Activities project, USDM v4.1, and later Digital Data Flow implementation handbooks are treated as emerging guidance until released. TransCelerate Digital Data Flow use cases are treated as implementation evidence rather than conformance rules. Existing artifacts remain bound to the released profile that created them and are never silently reinterpreted after a new release.

TrialStack’s canonical model now includes executable conditions and branching, deterministic expansion of complex timeline and participant-journey patterns, protocol randomization, first-class governed Biomedical Concepts and Dataset Specializations, and a target-neutral acquisition package. It retains a queryable protocol-to-artifact lineage graph, persisted amendment impacts, and generated decision, journey, timing, Form, randomization, and amendment-regression scenarios. Fixed cycles expand with retained authored lineage; variable cycles require governed scenario counts and are never guessed. Deterministic verification can identify invalid graphs, cycles, uncovered outcomes, unresolved repetitions, unsupported mappings, and downstream impact. Retained source-locked acceptance evidence verifies this internal architecture. Complete licensed SDTMIG 3.4 review, authorized CDISC Library ingestion, and named Viedoc/REDCap semantic round trips remain external gates. Unsupported or lossy behavior remains visible as a finding instead of being fabricated by an exporter or AI workflow.

USDM 4.1, the future HB2 Schedule of Activities profile, and the future HB3 Biomedical Concept/Define profile are reserved as non-executable candidates. TrialStack will activate them only as parallel profiles after official release assets, checksums, reviewed deltas, trace coverage, accepted fixtures, and validators all pass. Existing artifacts remain bound to the profile and evidence that created them.

Required authored structure

TrialStack maps versioned trial data through one versioned canonical contract before creating USDM and downstream exports. High-risk relationships are never guessed:

• eligibility criteria require an authored ID, code, type, and text;
• visits require an authored visit number;
• trial-arm paths require explicit arm, epoch, element, and order values;
• endpoints must be explicitly linked from objectives;
• intervention products preserve every authored ingredient and ingredient strength; administration dose is never reused as substance strength, and placebo products remain substance-free unless an ingredient was authored;
• the Section 4.4 Start of Trial and End of Trial definitions are authored independently and are never inferred from planned or actual trial dates;
• exactly one Recruitment population segment must be marked as the design population;
• only separate Recruitment segments marked as study cohorts become USDM cohorts;
• Statistical analysis populations may reference those cohorts but do not define them.

Every canonical mapping finding identifies the versioned mapping-contract entry that produced it. That entry records the governed source, the approved owner route, canonical and USDM targets, any SDTM trial-design target, terminology and null handling, provenance policy, and fixture evidence. Missing identities or relationships can therefore be routed to their owning Trial Summary, Design, Activities, Recruitment, Interventions, or Statistical surface instead of being treated as an unexplained export warning.

New ICH M11 reviewer exports use the pinned EMA Step 5 Technical Specification published on 11 December 2025 and effective on 11 June 2026. Legacy artifacts retain their captured ICH Step 4 profile rather than being silently reinterpreted. Both source locks preserve all source columns for all 575 Appendix 1 components: 284 headings and 291 non-heading components, with a reviewed Step 4-to-Step 5 delta. Existing M11-TS-* field keys remain stable local identifiers, headings use the separate M11-TS-H-* sequence, and ICH concept identifiers such as C218736 and C218737 for the two Section 4.4 definitions remain the authoritative source concepts. Semantic hierarchy normalization is stored separately instead of rewriting source text.

Every M11 artifact records the selected profile identity and effective date, PDF checksum, complete component-row checksum, heading and non-heading checksums, exact component-value bindings, applicability-aware data-availability rows, TrialStack rule outcomes, and explicit generation findings in metadata. Missing applicable authored content is reported; conditional content remains undetermined until it has a governed applicability decision or value. The exporter does not substitute values such as Not specified, version 1.0, today’s date, zero enrollment, or empty narrative text. Audit-trail requests are rejected because the M11 Technical Specification does not define an audit-trail payload.

Controlled terminology is projected only after the M11 component projector has selected the governed source or an exact component fallback. The evidence records the stable authored value, target profile, rule version, pinned terminology release, exact target codelist, code, and decode. Trial phase uses ICH M11 C217045 for authoring; values that are not members of the pinned USDM SDTM phase target are omitted from that target with a blocking terminology finding instead of being relabelled. Amendment reasons retain their DDF authoring provenance and use a reviewed term-by-term M11 C217276 crosswalk. Original-protocol and amendment-history responses are derived only when the selected protocol version has authoritative amendment lineage.

Mapping, semantic, and projection findings remain attached to a completed artifact when TrialStack can safely omit an invalid fragment without inventing trial intent. A complete-schema or rendering failure instead fails the request. Resolve each finding at its named owner, then create a new export.

Check readiness before exporting

The Exports page evaluates the current governed trial for USDM, ODM, SDTM Trial Design, and ICH M11 before a new artifact is created. The Profile description summarizes only the readiness state that applies to the selected profile. It distinguishes an available draft from semantic blockers and mentions CORE only for USDM. Exchange-shape validation remains an export-time check against the generated artifact instead of appearing as a pre-export status row. ADaM and SDTM mapping handoffs keep their readiness guidance beside the exact version and target fields that control delivery. A reviewable draft can therefore remain available while semantic blockers are still visible; neither draft creation nor semantic readiness is presented as a successful schema or CORE result. The deprecated combined ready projection remains available to older API clients.

The page also owns the SDTM mapping configuration drawer, where source compilation and review happen before JSON, XLSX, or neutral handoff delivery. The Analysis page owns ADaM metadata authoring, stable row references, generation, and version history. When an ADaM handoff is prepared, the export modal owns the exact immutable SDTM mapping-version selection, source refresh reconciliation, and current readiness findings so stale evidence cannot be mistaken for export-time readiness. Each blocker names its owning route, tab, and section. CORE is eligible only when the USDM semantic blockers are clear; the generated USDM document must still pass the pinned JSON Schema preflight before CORE executes, and its actual outcome remains attached to that export artifact.

When creating an export, first choose a profile grouped by its actual standard or target owner, then choose an available output grouped as a specification, review file, handoff, or delivery package. Each output choice shows the artifact name as its title and the file type in smaller text beneath it. The TrialStack eSAP profile remains under TrialStack; its TransCelerate source is advisory evidence, not profile ownership or conformance.

Use Improve All in Trial Summary to run the durable whole-trial generation plan. The plan works through Design, Recruitment, Statistical, and Summary sections in dependency order, writes each result through its owning governed version, and refreshes the live trial after completion. It does not invent ambiguous arm order, objective-to-endpoint links, analysis-population relationships, or intervention identities. Relationships that remain ambiguous stay as owner-routed blockers for review.

Repairs are scoped to one trial, one expected trial version, and the current Design transaction when design structure is involved. The repair-proposal API returns review-required actions with stable same-arm assignment or objective/endpoint choices and never auto-selects or applies them. If the trial version or relevant Design transaction changes during review, the proposal is rejected as stale and must be regenerated. Existing export artifacts remain immutable; after approved repairs are saved, create a new export and compare its retained evidence.

The SDTMIG 3.4 Trial Design export covers TA, TE, TV, TI, and TS because those five domains have governed TrialStack sources. It does not create TD disease-assessment or TM disease-milestone rows from adjacent data. Add those domains only after the corresponding scientific concepts have explicit authoring and governance. The ZIP is the supported artifact: the former standalone JSON was a TrialStack inspection model rather than Dataset-JSON, and the former workbook was a convenience view rather than a CDISC exchange standard.

Within the supported profile, the final ZIP enforces the SDTMIG contract. Arm paths keep their authored order and relationships. Elements require a start rule plus an end rule or duration. Planned visits require stable visit numbers and start rules, exclude unscheduled visits, never use Study Day 0, and populate both arm code and arm description when visits differ by arm. Eligibility exports keep the criterion text distinct from its short code, project common sponsor identifiers such as dotted, dashed, numeric-leading, or overlength codes into valid eight-character IETESTCD values, and resolve every collision deterministically. Arbitrary malformed identifiers remain blocking findings. The package also carries the protocol criteria version and normalizes delivery text to the SAS XPORT v5 character and length limits without changing the richer governed source. Trial Summary uses standard parameter codes and retains terminology provenance when available.

Cycle expansion does not renumber visits by display position. The first cycle preserves authored visit numbers; later cycles derive deterministic numbers from those values and the configured cycle. If cycle expansion is stale, open-ended, or otherwise unsafe, TrialStack omits it with a finding and exports the authored schedule instead. Invalid authored planned visits can still block SDTM delivery.

The same no-inference boundary applies in reverse. A USDM import retains the exact source artifact and unknown extensions, inventories only source objects that actually exist, and reports unsupported structures rather than manufacturing governed identities. Its round-trip report separates exact, normalized, preserved, and unsupported values. Import analysis is not persistence: reviewed conflicts must be resolved against the current trial version before TrialStack creates a governed version and linked draft amendment.

Completed artifacts distinguish Completed with errors, Completed with warnings, and Completed with findings from a clean Completed result. Those labels summarize the normalized finding report without changing execution state: the artifact remains downloadable because TrialStack safely omitted or qualified the affected projection. Failed is reserved for serialization, DOCX/PDF rendering, mandatory-validator, USDM JSON Schema, ODM XSD, or other execution failures that prevent a trustworthy artifact. The artifact download and the findings JSON export remain separate actions.

How teams use it

1. Configure the trial’s SDTM target in Trial Summary under Standards when a recipient requires a supported earlier pair. New trials default to the latest pair supported by TrialStack.
2. Open Control to confirm the current governed version, then use the workflow cards to open verification evidence, amendment impacts, or downstream delivery.
3. Open Exports and create the required USDM or SDTM trial-design output.
4. Select an export card to preview JSON as an interactive tree, ODM XML as highlighted source, or an ICH M11 review artifact as rendered protocol prose. The same drawer retains findings and separate USDM CORE evidence where applicable.
5. Download the generated artifact from a completed export.
6. Resolve findings in the owning trial forms, then verify or export again.

ODM exports use offline, checksummed mirrors of their complete XML Schema import graphs. The vendor-neutral option emits ODM 2.0. The Viedoc workflow scaffold emits ODM 1.3.1 with SDM-XML 1.0 from the same canonical trial-definition projection, then applies a Viedoc-specific identifier and timing adapter before serialization. Every generated artifact is validated by a mandatory bundled libxml2 WebAssembly runtime, so export workers do not depend on a system-installed XML executable. Validator absence or XSD failure fails the request. Define-XML is a separate ODM-based extension that describes tabular dataset metadata; it is included with the SDTM package and is not a second name for an ODM study-definition export.

The ODM scope is the governed study definition that TrialStack actually owns. It includes protocol metadata, arms, epochs, visits, authored timing relationships, interventions and product details, objectives, endpoint links, estimands, analysis-population and intercurrent-event relationships from the current Statistical snapshot, the design population, and eligibility criteria. Authored elements become reusable study segments, while arm/epoch/element assignments become study cells. Visits are attached to a segment only when the arm/epoch relationship resolves uniquely; ambiguous cells, unresolved references, and rules that can only be retained as text produce owner-routed findings instead of a fabricated ODM workflow graph.

ODM durations use the ISO 8601 duration contract. Signed values are accepted only where an authored timing offset can be negative; visit durations and pre/post window magnitudes must remain non-negative. Conflicting week/day timing values, event-driven placeholder offsets, invalid durations, and missing design paths are omitted with findings rather than guessed. Structured XML contains the authored prose but removes Markdown footnote markers and definitions; footnotes and source annexes are retained only in document-oriented exports such as DOCX and PDF. ODM does not invent eCRF forms/items, administration records, reference data, subject clinical data, annotations, or audit records. An ODM request with includeAuditTrail enabled is rejected because an AuditRecord cannot be represented correctly without the subject or item data to which it belongs.

The Viedoc adapter keeps TrialStack UUIDs as source identity but projects concise OIDs from governed immutable codes, with stable UUID-derived fallbacks and collision suffixes. It rewrites definitions and references as one registry operation and retains the identifier map in artifact and handoff evidence. Scheduled-event timing follows Viedoc’s native design ODM shape: one relative constraint per workflow successor, day granularity, an actual predecessor-date basis, and explicit pre/post windows including zero-second windows. The event at the workflow root becomes Viedoc Study Start and therefore has no proposed-date calculation of its own. Later scheduled visits retain their canonical target-day differences and asymmetric windows; unrepresentable timing is omitted with an actionable finding, and unscheduled events receive no invented fixed timing. The workflow scaffold intentionally excludes Forms. The separate Viedoc design emits actual ordered scheduled activities and exact pinned Form placements, including the event-level Form references required by SDM. Both remain static, statically validated artifacts; unsupported edit checks, calculations, permissions, vendor functions, and operational RTSM are reported as findings rather than invented.

On the page

Surface	What it shows	What teams check
Trial Summary Standards	Trial-level standards configuration	Optional CDISC therapeutic area guide and the supported SDTM/SDTMIG target pair
Control	Cross-workflow governed study-definition status	Current version and owner-routed workflow cards
Exports	Standards export requests and artifacts	Profile, format, execution status, latest activity, and downloadable artifact
Export details	Evidence retained with one export	Execution error, export-check findings, CORE result, checksum, and rule evidence

Card timestamps use the browser’s local time. The page’s updated timestamp follows the most recently updated export rather than the date the trial was last edited.

Controlled terminology

Controlled terminology appears as named, field-specific choices in the existing trial forms. Protocol authors do not select catalogs, releases, codelists, or codes. TrialStack keeps that source information behind the field so validation and exports can identify the exact EVS release, codelist, NCIt code, and decode.

Authoring forms do not warn when hidden code-system or release metadata is absent. They show read-only terminology evidence only when genuine source, codelist, or release evidence is available; raw code, code-system, and release fields remain unavailable for unrestricted authoring.

Existing values that are no longer offered by the current field value set remain visible and can be preserved, but they are not offered for new authoring. Updating a source release never silently rewrites saved trial data.

CDISC Protocol terminology is retained as a retired source for historical provenance. A retired term remains readable and is never rewritten automatically. TrialStack disables it for new authoring only after a reviewed, field-owned successor mapping is activated; a related term in another codelist is not treated as a successor. Regional terminology overlays remain part of the selected M11 technical-specification profile and cannot become selectable without a pinned source manifest, checksum, and reviewed delta.

TrialStack checks the governed SDTM and SDTM Implementation Guide versions as a supported pair. SDTM versioning remains configurable at the trial level because receiving authorities and downstream systems may require a supported earlier pair; silently switching every export to the newest release would make the same governed trial produce a different contract. The export dialog does not duplicate those controls. USDM is different: this exporter is explicitly pinned to USDM 4.0 and therefore has no version selector.

A CDISC Therapeutic Area User Guide (TAUG) extends foundational standards with disease-specific metadata, examples, and implementation guidance. TrialStack records the selected TAUG with the SDTM export for review context. That selection does not by itself establish disease-specific conformance or change mappings that are not explicitly implemented.

Activity forms show protocol-authoring fields such as activity type, visit, duration, sampling details, parent activity, and timeline. Technical code-system metadata, biomedical-concept and procedure identifiers, and scheduled-decision identifiers remain internal to imports, exports, and validation. Timing type and relative relationship are selected in the Schedule Timeline timings editor from the current DDF value sets.

Schedule projections

Cycle definitions live in the Cycles section of Plan > Design. Each row selects authored source visits and defines the first cycle, planned or actual last cycle, and cycle length. Plan > Activities applies the derived cycle projection automatically across its Grid, Flow, and Timing views. An open-ended group keeps its authored source visits visible as the cycle template until a planned or observed last cycle supports finite expansion. SDTM delivery omits unresolved cycle expansion with a finding and exports the authored schedule. Authored visit sections remain available below those views. The projection remains read-only and never updates the authored design.

Interpret results carefully

Export execution and USDM CORE conformance are separate results:

• Completed means TrialStack generated the requested artifact with no findings.
• Completed with errors, Completed with warnings, or Completed with findings means the artifact is downloadable with retained mapping, semantic, projection, or format findings at the indicated highest severity.
• Failed means serialization, rendering, or mandatory schema validation did not produce a trustworthy artifact.
• CORE uses conformant, nonconformant, not run, or execution error for the generated USDM snapshot.

Before CORE runs, the generated USDM document passes the complete pinned USDM 4 JSON Schema preflight. A schema failure fails the request and retains actionable validator evidence. Canonical mapping and TrialStack semantic errors can remain on a completed artifact, but they block CORE and produce an explicit Not run reason with an owner path. CORE executes all 207 pinned rules only when those blocking preflight findings are absent.

A required controlled value with no exact USDM target member follows that completed-artifact path: the export remains downloadable, the finding report identifies the blocking terminology rule and owner, and CORE is recorded as Not run with that finding as the cause.

A completed export may therefore be nonconformant and retain unresolved validation findings. A conformant CORE result means that the exported snapshot passed the displayed CDISC CORE version and ruleset. It does not replace scientific, regulatory, statistical, or operational review of the trial.