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[Study definition control]
    Trial --> Export[Standards export]
    Control --> Export
    Export --> Manifest[Manifest and checksum]
    Export --> Details[Execution, export checks, 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.

Available exports

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

Profile	Output	Intended use
USDM 4.0	JSON	Full-fidelity exchange of the governed study definition against TrialStack’s 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
CDISC ODM 2.0	XML	Vendor-neutral exchange of the governed study-definition scope supported by TrialStack
ICH M11 protocol outline (preview)	DOCX or PDF	Human review of an M11-aligned protocol outline; not an official ICH M11 exchange artifact

USDM Schedule Timeline, FHIR Vulcan Schedule of Activities, and EDC ODM Handoff 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, and TrialStack does not yet present its EDC handoff workflow as ready for operational delivery.

ICH M11 defines a protocol template and a technical representation of protocol content, but does not prescribe XML, JSON, spreadsheet, or CSV serialization. The creation dialog therefore exposes a clearly labelled DOCX/PDF review projection. Those reviewer files contain protocol content and omit technical component tables, hashes, and mapping paths. TrialStack retains the source-locked 575-component dispositions, authored values, applicability, rule results, and human-review requirements as compact export metadata. These checks are never presented as an official ICH exchange schema, conformance result, or certification.

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;
• the Section 4.4 Start of Trial and End of Trial definitions are authored independently and are never inferred from planned or actual study 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.

The ICH M11 registry is pinned to the Step 4 Final Technical Specification published on 19 November 2025. It preserves all source columns for all 575 Appendix 1 components: 284 headings and 291 non-heading components. 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 PDF checksum, complete component-row checksum, heading and non-heading checksums, exact component-value bindings, applicability-aware dispositions, TrialStack rule outcomes, and explicit generation findings in metadata. Missing required authored content is reported; 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.

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

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 and carry the protocol criteria version. 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. Missing or duplicate source visit numbers block final 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.

SDR interoperability uses an explicit compatibility profile rather than a general compatibility claim. The current fixture-backed boundary is SDR RI User Guide V8.0, API v5, and USDM 4.0. TrialStack negotiates that pair before version-specific retrieval, records selective responses as partial, and prevents partial content from becoming an authoritative import. Exact remote responses, checksums, upload-version identity, and conformance receipts remain attached to import evidence. Study submission is not part of this profile.

Completed with findings means the artifact was generated and remains downloadable, but its normalized finding report contains errors, warnings, or information. Failed is reserved for serialization, DOCX/PDF rendering, mandatory-validator, USDM JSON Schema, ODM XSD, or other execution failures that prevent a trustworthy artifact.

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 inspect execution details, export-check findings, and retained USDM CORE evidence.
5. Download the generated artifact from a completed export.
6. Resolve findings in the owning trial forms, then verify or export again.

ODM exports target CDISC ODM 2.0 using an offline, checksummed mirror of the complete official XML Schema import graph. TrialStack exposes study-definition XML because that is the concrete, schema-validated ODM 2.0 serialization it supports. Every generated artifact is validated by the mandatory xmllint runtime; 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, objectives, endpoint links, estimands, the design population, and eligibility criteria. It 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.

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.

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. 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 findings means the artifact is downloadable with retained mapping, semantic, projection, or format findings.
• 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 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 study.