01
Where it fits—and where it doesn’t
Use these four checks before committing implementation time.
- Use it when
- Computable clinical concepts that connect protocol, collection design, tabulation metadata, and downstream automation.
- Do not use it as
- Do not treat CDISC BCs as a complete solution on its own. Content is informative and incrementally curated; concept, specialization, terminology, and downstream standard versions must be pinned together.
- Best for
- Teams working with Clinical data across Plan → Acquire → Harmonize.
- Maturity
- ScalingUsable today, with adoption or tooling still scaling; pilot the exact stack you plan to run.
02
See it in the workflow
A standard creates value by changing a handoff, not by existing in a catalog.
- InputWhat starts
Clinical data, metadata, and the local decisions around them
- CDISC BCsWhat changes
CDISC BCs applies a shared data model / schema across Plan → Acquire → Harmonize
- OutputWhat becomes possible
A more consistent, reviewable handoff for the next system or team
03
A concrete example
A study standards team selects a versioned Biomedical Concept, binds its terminology, and reuses its SDTM Dataset Specialization in metadata-driven study build.
Why it matters: Makes clinical concepts and variable relationships more computable, but does not validate source data, labels, or model fitness.
04
What it fits with
Complements CDISC Foundational Standards and terminology; can support CRF, Define-XML, SDTM specialization, and cross-standard mappings.
- StandardCDISC
Both support Clinical work and meet around Plan, Acquire, Harmonize. Compare their roles before treating them as interchangeable.
Explore relationship - Metadata vocabularyDPV
Both support Clinical work and meet around Plan, Acquire, Harmonize. Compare their roles before treating them as interchangeable.
Explore relationship - FrameworkFAIR
Both contribute at Plan, Acquire, Harmonize, with different domains or implementation roles.
Explore relationship - Data model / schemaISA
Both contribute at Plan, Acquire, Harmonize, with different domains or implementation roles.
Explore relationship
05
Implementation starter
Start with one bounded handoff. Pin, test, and review it before scaling.
Name an accountable owner and the decision CDISC BCs must support.
Pin the exact version and companion artifacts: COSMoS semantic layer · current library releases.
Map one representative input to the required data model / schema artifacts.
Test the result against the canonical source and record every exception.
Preserve the source data, mappings, and review evidence before scaling.
06
Limitation to test first—and the tests that catch it
Content is informative and incrementally curated; concept, specialization, terminology, and downstream standard versions must be pinned together.
Run one representative end-to-end pilot and record exactly where CDISC BCs loses context, needs an extension, or depends on another standard.
A structured or machine-readable result can still be unfit for analysis or AI.
Test the output for missing context, provenance, terminology alignment, time leakage, and the intended downstream decision. Makes clinical concepts and variable relationships more computable, but does not validate source data, labels, or model fitness.
07
Why we believe this
Checked against the canonical source plus implementation or adoption evidence reported by the steward or its community.
Evidence notation: E1 + E3. The code is shorthand; the plain-language statement above is the claim.
08
Source shelf
Official diagrams, examples, specifications, and explainers. Nothing external loads until you choose to open it.
CDISC Biomedical Concepts
The canonical publisher or steward source used to verify this data model / schema profile.
- Publisher
- CDISC
- Rights
- Rights remain with the publisher; this knowledge base links to the source rather than copying it.
- Access
- Opens the publisher's source in a new tab; no external media loads on this page.
- Verified
- 2026-07-13