Mediconomics – für individuelle CRO-Lösungen.

Glossar

Dataset-JSON is a CDISC data exchange format for tabular data based on JSON. It is designed for different exchange use cases, including regulatory submissions and transmission via APIs. Dataset-JSON transfers rows and columns in a technical format; the more detailed subject-matter description of the dataset can be provided via a reference to Define-XML.

Table values in a JSON structure

JSON is a widely used data format that is well suited to automated interfaces. Dataset-JSON transfers tabular study data not as a classic SAS transport file, but as a structured JSON representation. This allows a system to retrieve or provide data without the transfer being tied to a specific statistical client or desktop application.

However, the format does not determine which study variables are collected or how they are derived from a subject-matter perspective. It provides a technical framework for values and tables. Terms, labels, controlled terminology, and derivation logic require an additional metadata layer if a recipient does not already know the data from a shared specification. This is precisely where Dataset-JSON can optionally reference a Define-XML with more extensive metadata.

Use for interfaces and submissions

CDISC cites regulatory submissions and API-based data exchange as intended use scenarios. In the API case, applications can exchange tabular data automatically, for example between a data platform and a review or analysis tool. For submissions, it also remains decisive which formats and versions the responsible authority supports or requires at the relevant time.

The CDISC standards page lists Dataset-JSON v1.1 as well as the dates December 5, 2024 and August 23, 2023. For a submission strategy, this publication information is not sufficient: the FDA Data Standards Catalog distinguishes between supported versions and versions for which an implementation start date has been set as a requirement. The technical advantage of JSON therefore does not replace a regulatory format check.

Distinction from Define-XML and ODM

Dataset-JSON is an exchange format, not a metadata standard. Define-XML, by contrast, explains what a submitted dataset contains: datasets, variables, terminologies, and, where applicable, derivations. Dataset-JSON’s optional reference to Define-XML shows how the two artefacts complement each other, but it does not eliminate their different roles.

The Operational Data Model provides a broader framework for the exchange and archiving of clinical research data, including metadata, administrative data, reference data, and audit information. Although ODM v2.0 also allows JSON serialization, Dataset-JSON is a format specifically geared to tabular data. A project should therefore not record “JSON” alone as a requirement, but should name the specific CDISC artefact and its intended use.

Choosing Dataset-JSON can also affect validation tools and recipient systems. A check must not only determine syntactically whether valid JSON is present, but also verify that the table, the order, and the data values comply with the agreed standard. If date values, missing values, or numeric precision are interpreted differently, discrepancies can arise during import that were not visible in the source system. Such cases belong in test data and acceptance criteria.

For a controlled data package, it should also be clear which files belong together. Dataset-JSON without an associated metadata reference, Reviewer Guide, or version information may be technically exchangeable, but can make review more difficult. The package structure must therefore enable the recipient to consistently bring together table values, the standard version, and explanatory metadata. This applies regardless of whether the exchange takes place via an API or as a submission package.

For each handover, it must therefore be documented which file constitutes the authoritative delivery and which technical and subject-matter checks were performed before release.

This keeps the package’s release status traceable.

Relevance for clinical trials

Dataset-JSON becomes relevant when standardised SDTM or ADaM tables are to be handed over between applications or to an authority. Before use, dataset names, data types, character sets, metadata references, and the expected version must be aligned in the data exchange plan. Otherwise, a technically readable JSON package may still be incomplete because the recipient cannot reliably map the semantic meaning of individual columns.

Full-service CROs such as Mediconomics support the selection of submission-ready exchange formats, Dataset-JSON exports, and linking the files with Define-XML and reviewer documentation. Programming, data management, and Regulatory Affairs can jointly manage format checks, version alignment against the Data Standards Catalog, and assembly of the electronic data package.

Frequently asked questions (FAQ)

Is Dataset-JSON an alternative to SDTM?

No. SDTM describes the organisation of clinical tabulation data. Dataset-JSON is the technical format in which tabular data can be exchanged.

Does every Dataset-JSON file have to reference Define-XML?

The CDISC page describes the reference as an optional possibility. Whether and how metadata must be provided depends on the exchange use case and, where applicable, on the requirements of the receiving authority.

Why is “JSON” not sufficient as a specification for a handover?

JSON describes only a general technical notation. Dataset-JSON additionally defines the structure for tabular data; further metadata may be required for its subject-matter interpretation.

Regulatory References

  • CDISC Dataset-JSON – defines the JSON-based exchange of tabular data and the intended use cases.
  • CDISC Dataset-JSON v1.0 – documents a published version of the format.
  • FDA Data Standards Catalog – distinguishes supported and, where applicable, mandatory standard versions.
  • FDA Study Data Technical Conformance Guide – explains technical expectations for standardised study data submissions.

Seite medizinisch geprüft von: Dr. Richard Smith (9. October 2026)

Scroll to Top