From the protocol to the analysis.
A study’s meaning carried all the way through: the design in OpenStudyBuilder and CDISC USDM, every observation bound to a CDISC biomedical concept, every endpoint linked to an analysis concept, an ADaM variable and the result it reports. Each mapping is proposed by rule, signed by a person and pinned to the standards version it was made against.
The chain
Six links from an activity to the number in the table.
This is the chain CDISC’s 360i program describes, implemented. Each link is a read over the study’s accepted model: it proposes, a standards reviewer and a statistician decide.
- Biomedical concept
- A standard, machine-readable definition of one clinical observation, such as systolic blood pressure, with the data elements it needs and their controlled terminology. CDISC publishes them through COSMoS, with dataset specializations for SDTM.
- Analysis concept
- What an analysis does with an observation: the derivation, the method and the result it reports. CDISC’s Analysis Concepts and Derivation Concepts work is a working-group draft; AccuraTrials uses a pinned version and names it on every result.
On a real protocol
ACTT-1, read as written
The public protocol of the Adaptive COVID-19 Treatment Trial, run through the two reads.
- Distinct observations
- 242 from 325 stated observation claims
- Bound to one CDISC concept
- 35 for example ALT → C64433 · ALTSERPL · LB
- Endpoint statements classified
- 40 of 72 23 left unclassified rather than guessed
- Transformations selected
- 9 only where the endpoint was unambiguous
OpenStudyBuilder
How we integrate with OpenStudyBuilder.
OpenStudyBuilder is the open-source study definition platform started by Novo Nordisk. AccuraTrials runs it inside the platform, behind the same sign-in, tracking its upstream releases, and writes to it only through its own API.
01
Facts with their evidence
The protocol and its documents are read into the semantic layer as source claims: each one a stated fact with the page and passage it came from. They are never rewritten; decisions select what they mean.
02
Mapped by rule, decided by a person
A versioned ruleset proposes each mapping into the study design as a candidate that always requires review. A reviewer signs the decision, citing the candidates it accepts.
03
Two outputs, nothing lost
The reviewed study becomes an OpenStudyBuilder study bundle shaped for its own API, and a CDISC USDM v4.0 design document. A conservation census proves both conversions account for every element.
04
Applied through the study routes
The bundle is applied through OpenStudyBuilder’s native study routes in dependency order. Library objects are referenced only by identities from a registered candidate set, never invented.
05
Read back, released, received
The study’s snapshot is read back and compared. Only a signed release, carrying a manifest of every standard version it used, configures the EDC, and a deployment counts only when the EDC returns its receipt.
What we map to
Every standard on the path, with its status stated.
Design, capture, tabulation, analysis and results. Where something is working software rather than a qualified system, or a draft rather than a published standard, the table says so.
In production live in AccuraTrials EDC Built working software, not yet qualified for submission Draft standard a CDISC working-group draft
| Standard | What it carries | How AccuraTrials uses it | Status |
|---|---|---|---|
| CDISC USDM v4.0 | The study design | The canonical design in the semantic layer, edited and validated through OpenStudyBuilder; the EDC exchange is pinned to USDM 4.0.0 | Built |
| ICH M11 | The structured protocol | Protocol sections authored natively in OpenStudyBuilder and rendered as M11 previews | Built |
| CDASH and ODM 1.3 | Data capture | eCRFs built against a CDASH-aligned field library; ODM XML export of the study and its audit trail | In production |
| CDISC biomedical concepts (COSMoS) | What each observation means | Bindings to a pinned COSMoS release and its SDTM dataset specializations; sponsor drafts marked not bindable | Built |
| SDTM | Tabulation datasets | Reviewed DM, AE, LB and VS mappings; TA, TE, TV, TI and TS drafted from the USDM design; synthetic SDTM generated from a Define-XML or USDM specification | Built |
| ADaM | Analysis datasets | ADSL with population flags; BDS with parameters, baseline, change, windows and ANLzzFL flags; OCCDS; ADTTE; ADRS under RECIST 1.1; ADPC and ADPP | Built |
| Define-XML 2.1, Dataset-JSON 1.1, SAS XPORT v5 | Dataset metadata and transport | Generated with complete lineage and checked offline against the pinned official schemas | Built |
| CDISC ARS 1.0 | Analyses and their results | Planned reporting events before any data exist, then released results attached to the same identities | Built |
| Analysis and Derivation Concepts | Endpoint, derivation and method | Endpoints classified into derivation concepts and candidate transformations, read under a pinned commit | Draft standard |
| ICH E9(R1) estimands | What a treatment effect means | Population, variable, treatment, intercurrent-event strategies and summary measure as reviewed objects analyses reference | Built |
| Terminology | Shared meaning for every value | CDISC CT and NCIt codes, LOINC and UCUM for laboratory data, STATO for statistical methods, MedDRA and WHODrug for coding | In production Built |
Terminology is in production for coding and capture in AccuraTrials EDC; its use in concept bindings and analysis outputs is built. Dictionary licences such as MedDRA remain the sponsor’s.
A public protocol, end to end
From design to SAP draft, on synthetic data.
NCT02953665, a liraglutide trial in Parkinson disease, taken from its design through SDTM, ADaM, conformance checks, independent QC, planned analyses, tables and a SAP draft. Every value was synthetic, and the reviewers were test accounts, not clinical reviewers.
What the run did not prove
Engineering behaviour on synthetic data, not a study’s clinical or regulatory result.
- The CORE errors
- AEDECOD is empty because MedDRA is not licensed locally; EPOCH is missing on some CM records; TS lacks three design parameters the design never stated; two rules read RELREC and FA, which the package does not contain.
- Draft ADaM rules
- The draft ADaMIG 1.3 CORE rules could not run against the package, so they give no conformance evidence either way.
- One dataset not re-derived
- ADQS is not yet programmed in R, so its independent QC is open.
- Not a submission
- The workbench is not yet a qualified submission system, and the analysis concepts framework is a draft. Your validation decides what is submitted.
FAQ
Concepts, OpenStudyBuilder and ADaM, answered plainly.
Updated October 2026
What is a CDISC biomedical concept?
A biomedical concept is a standard, machine-readable definition of one clinical observation, such as systolic blood pressure, with the data elements it needs (the result, its unit, the specimen, the timing) and their controlled terminology. CDISC publishes them through its COSMoS program, with dataset specializations that say how each concept lands in an SDTM domain.
What are CDISC analysis concepts?
Analysis concepts describe what an analysis does with an observation: the derivation (a change from baseline, a time to event, a responder flag), the method that analyses it and the result it reports. CDISC’s Analysis Concepts and Derivation Concepts work is a working-group draft, not yet a published standard. AccuraTrials uses a pinned version of it, and every result built on it names the version it was read under.
Does AccuraTrials integrate with OpenStudyBuilder?
Yes. AccuraTrials runs OpenStudyBuilder, the open-source study definition platform started by Novo Nordisk, inside its platform. The semantic layer turns a study’s reviewed content into an OpenStudyBuilder study bundle and a CDISC USDM v4.0 design, checks both conversions for lost content, and applies the bundle through OpenStudyBuilder’s own study routes, using library identities from a registered candidate set rather than inventing them.
Can AccuraTrials map study data to SDTM and ADaM?
Yes, in its biometrics workbench, which is working software but not yet a qualified submission system. Reviewed mappings produce SDTM domains, including DM, AE, LB, VS and the trial design domains, and ADaM datasets including ADSL, BDS parameters with baseline and change, OCCDS, ADTTE, ADRS under RECIST 1.1 and ADPC. Every derived cell is traced to its source, and an independent R program re-derives the result for QC.
Does AccuraTrials produce Define-XML and Analysis Results Standard output?
Yes. It generates Define-XML 2.1, Dataset-JSON 1.1, CSV and SAS XPORT v5 files checked against the pinned official schemas, and CDISC ARS 1.0 reporting events: for planned analyses before any data exist, and for released results afterwards. A schema check is not full conformance, so CDISC CORE conformance results are reported separately.
How are mappings reviewed?
Every mapping is proposed by a versioned rule, never by text similarity, and marked as needing review. A person signs the decision, and each study release pins the exact standards versions it used, so a mapping can always be traced to who approved it and what it was made against. Anything a rule cannot classify is left unclassified rather than guessed.
Is the output ready for a regulatory submission?
Not on its own. The SDTM and ADaM packages are generated, schema-checked, checked against CDISC CORE conformance rules and independently re-derived in R, but the workbench is not yet a qualified submission system, and the analysis concepts framework it uses is a draft. Your own validation and standards review still decide what is submitted.
Bring a protocol and a SAP. Follow one endpoint through.
We will trace one of your endpoints from its protocol sentence to its concept, its ADaM variable and its planned analysis, on the real platform.
Or email us: jgui@accuratrials.com