CDISC 360 Explained

CDISC's mission and where 360i fits

CDISC states its mission as amplifying data's impact to advance research by creating connected standards across the study information lifecycle — making data accessible, interoperable, and reusable for more meaningful and effective research. CDISC 360i ("the next step to realizing standards-driven research") is the concrete program built to deliver on that mission: intelligent, protocol-driven research automation that improves patient outcomes by removing the manual, error-prone re-transcription that happens at every standards handoff today.

How 360i actually works

360i's core move is deceptively simple: define end-to-end standards once, and link concepts to representation standards. Concretely, that means:

• Digitalizing information from protocol through reporting.
• Linking concepts to representation standards — forms definitions, electronic data transfer specs (eDTs), SDTM specs, ADaM specs, and TFL (tables/figures/listings) specs.
• Enriching those links with transformation and derivation logic, so a single concept definition can drive multiple downstream artifacts automatically.
• Automating study builds by selecting concepts and concept groups directly in a digital Schedule of Activities.

The starting point for all of this, in CDISC's own description of 360i, is: starting with linking the Schedule of Activities to Concepts (and Concept Groups) — which is exactly the job USDM's Activity, BiomedicalConcept, and BiomedicalConceptCategory classes do.

USDM's role in the 360i chain

Without USDM, 360i has nothing concrete to automate from — there is no structured Schedule of Activities to link Biomedical Concepts to in the first place. USDM supplies that structured entry point: every Activity in a USDM study design can reference one or more standardized Biomedical Concepts, each of which is a CDISC Library-defined, reusable unit of clinical meaning (e.g., "Systolic Blood Pressure," C25298) with its own properties, required/enabled flags, and response codes.

Once that link exists, everything downstream becomes derivable rather than hand-authored: CRF form definitions (CDASH), SDTM dataset specializations, ADaM specs, and TFL specs can all be generated or strongly guided from the same Biomedical Concept definitions, because the concept was defined once, centrally, and referenced — not redefined independently by each downstream team.

Design, Build, Run, Adapt

CDISC 360i frames the full lifecycle as a loop:

This loop is why CDISC frames 360i's benefit across five distinct audiences: patients get data that's easier to understand and extract; sponsors get study-design-driven automation that reduces time-to-results and increases quality; regulators get reduced variability and click-through traceability from analysis back to source; researchers get a lower barrier to entry through ready-to-use, open-source implementable standards; and technologists get machine-readable inputs and outputs that are easier for software to adopt.

Real automation examples already demonstrated

• Automated SDTM Trial Design domain creation from USDM-to-SDTM mappings expressed as JSONata queries run against the USDM API JSON.
• Automated cost, patient-burden and complexity scoring derived from activities, timings and assessments already captured in the SoA.
• Patient journey visualizations generated automatically from Arm/Epoch/Encounter/ScheduledInstance combinations.
• Lab specification alignment, using Biomedical Concept code aliases to link a study's standard test description to LOINC or country-specific lab codes without re-specifying it by hand.

360i compared to a traditional CDISC standards workflow

It helps to see the two workflows side by side, because 360i's value proposition is entirely about what it removes, not what it adds on top:

The point isn't that every step becomes fully automatic on day one — it's that each handoff becomes a derivation from a shared, structured concept definition instead of an independent, manual re-interpretation of the protocol text by a different team.

Why "linking the Schedule of Activities to Concepts" is the hard, valuable first step

CDISC's own framing is specific about where 360i work should start: "Starts with linking Schedule of Activities to Concepts (and Concept Groups)." This is deliberate sequencing, not an arbitrary starting point. Every later automation step (form generation, SDTM specialization, ADaM derivation) depends on knowing, unambiguously, which standardized concept each SoA activity actually refers to. Skip this step, or do it loosely, and every downstream "automation" is really just automating the propagation of an ambiguity — which is arguably worse than a manual process, because the error becomes systematic instead of one-off.

A worked mini-example: from SoA text to five downstream artifacts

Take a single SoA row: "Vital Signs." In a 360i-aligned pipeline, that one Activity, once linked to the BiomedicalConceptCategory "Vital Signs" (containing Systolic/Diastolic Blood Pressure and Heart Rate BCs), can drive: (1) a CDASH-aligned CRF form with the correct fields and pick lists; (2) an SDTM VS dataset specialization with the right variable mappings; (3) an ADaM ADVS derivation spec reusing the same variable names; (4) a standard TFL shell for vital signs summary tables; and (5) an automated cost/burden estimate for that assessment, all traceable back to one BC definition instead of five independently-authored specifications.

How 360i relates to the CDISC Library

The Biomedical Concepts that 360i links Activities to don't need to be authored from scratch by every sponsor — standard BCs (like Systolic Blood Pressure, C25298) are published in the CDISC Library and its Biomedical Concepts browser, complete with their Data Element Concepts, standard code references, and CDASH/SDTM dataset specializations. This is the mechanism that lets 360i automation scale across the industry rather than staying locked inside one company's internal metadata repository: a BC defined once in the CDISC Library can be referenced by any USDM study design, at any sponsor, and still drive the same downstream specialization logic.

Frequently asked questions