CDISC ODM (Operational Data Model): ODM-XML v1.3.2 vs. ODM v2.0, Study Metadata Hierarchy, 21 CFR Part 11 Audit Trails, and Define-XML

The CDISC Operational Data Model (ODM) is a vendor-neutral, platform-independent transport and archival standard maintained by the Clinical Data Interchange Standards Consortium (CDISC) for representing clinical trial metadata, administrative definitions, reference laboratory ranges, and subject-level clinical data. Whereas CDISC SDTM (Study Data Tabulation Model) and ADaM organize finalized, analysis-ready datasets for regulatory review, CDISC ODM governs the operational lifecycle of a clinical trial—from study build and electronic Case Report Form (eCRF) configuration inside an Electronic Data Capture (EDC) platform to real-time data exchange, audit-trail tracking, and long-term regulatory archiving.

What Is CDISC ODM and How Is It Used in Clinical Research and Healthcare?

First introduced by CDISC in 1999 and deployed across global biopharmaceutical trials via ODM-XML v1.3.2 and the modernized ODM v2.0 specification, the Operational Data Model solves a fundamental interoperability challenge in CDISC clinical data standards: how to move a complete clinical study—both its structural metadata (visits, forms, fields, data types, edit checks, and codelists) and its collected patient observations (including every historical edit, query resolution, and investigator e-signature)—between heterogeneous software systems without proprietary database lock-in.

In clinical research operations, CDISC ODM serves four primary functions:

1. EDC Study Design Portability and Metadata Exchange: Trial sponsors and Contract Research Organizations (CROs) store validated form libraries aligned with CDASH (Clinical Data Acquisition Standards Harmonization) in a Metadata Repository (MDR) and export ODM metadata files to automatically build study databases in platforms such as Medidata Rave, OpenClinica, Castor EDC, Veeva Vault CDMS, Oracle Clinical One, and REDCap.
2. Operational Data Transport (EDC, eCOA, IRT, and Central Labs): During an active trial, ODM files stream transactional or snapshot subject data between the central EDC system, Interactive Response Technology (IRT/RTSM) randomization engines, electronic Clinical Outcome Assessment (eCOA/ePRO) mobile apps, and safety pharmacovigilance databases.
3. Regulatory Submission Metadata (Foundation of Define-XML): CDISC ODM is the underlying XML schema for CDISC Define-XML (v2.0 and v2.1), the mandatory machine-readable data definition file (`define.xml`) required by the U.S. Food and Drug Administration (FDA) and Japan’s Pharmaceuticals and Medical Devices Agency (PMDA) to describe SDTM, ADaM, and SEND submission datasets.
4. ICH E6(R3) and 21 CFR Part 11 Investigator Site Archiving: At study closeout, sponsors generate self-contained ODM-XML archives containing all subject eCRF entries, complete timestamped audit logs, and electronic signatures so principal investigators retain independent, human- and machine-readable custody of their site’s source records outside the sponsor’s commercial EDC environment.

Architectural Hierarchy of a CDISC ODM Document

Every CDISC ODM file is encapsulated within a root <ODM> element that declares document-level attributes including FileOID (a globally unique file identifier), FileType (either "Snapshot" or "Transactional"), CreationDateTime (ISO 8601 timestamp), ODMVersion ("1.3.2" or "2.0"), and optional Granularity (such as Metadata, AdminData, SingleSite, or SingleSubject).

Inside the root <ODM> element, data is partitioned into four top-level container sections linked by immutable Object Identifiers (OIDs):

Top-Level ODM Container	Core Child Elements	Operational Role in Clinical Trial Systems
<Study>	<GlobalVariables>, <BasicDefinitions>, <MetaDataVersion>	Defines the study protocol schedule, visit matrix, eCRF forms, item groups, individual data fields, measurement units, and controlled terminology codelists.
<AdminData>	<User>, <Location>, <SignatureDef>	Catalogs clinical investigators, data coordinators, clinical trial sites (LocationType="Site"), labs, and the legal meaning of electronic signatures.
<ReferenceData>	<ItemGroupData>, <ItemData>	Stores non-subject-specific baseline reference tables, such as site- or laboratory-specific normal reference ranges stratified by age and sex.
<ClinicalData>	<SubjectData>, <StudyEventData>, <FormData>, <ItemGroupData>, <ItemData>	Contains the actual patient-level clinical observations linked by MetaDataVersionOID, plus embedded <AuditRecord>, <Signature>, and <Annotation> elements.

The <MetaDataVersion> Structural Hierarchy

Within <Study>, the <MetaDataVersion> element versions the eCRF specification so mid-study protocol amendments can add or modify forms without corrupting previously collected subject records. In ODM-XML v1.3.2, metadata definitions follow a strict six-tier parent-child reference model (where parent definitions reference children via *Ref elements and Mandatory="Yes|No" flags):

1. <Protocol>: Lists the scheduled and unscheduled clinical trial visits via <StudyEventRef>.
2. <StudyEventDef>: Defines a clinical visit or timepoint (such as Screening, Baseline/Day 1, Week 4, or Early Termination), classified by its Type attribute as Scheduled, Unscheduled, or Common (for logs such as Adverse Events and Concomitant Medications), and references one or more forms via <FormRef>.
3. <FormDef>: Represents an individual eCRF page (such as Vital Signs, Demographics, or 12-Lead ECG), with Repeating="Yes|No", referencing item groups via <ItemGroupRef>.
4. <ItemGroupDef>: Groups related fields into a logical section or repeating table (often mapped directly to an SDTM domain such as VS or AE via the Domain attribute), referencing individual items via <ItemRef>.
5. <ItemDef>: Defines a single clinical data variable, specifying its OID, Name, DataType (such as text, integer, float, date, datetime, partialDate, or boolean), Length, SignificantDigits, SASFieldName, SDSVarName, display prompt (<Question><TranslatedText>), and optional <RangeCheck> or <CodeListRef>.
6. <CodeList>: Enumerates permissible coded values (<CodeListItem CodedValue="..."> or <EnumeratedItem>) linked to NCI Enterprise Vocabulary Services (EVS) CDISC Controlled Terminology codes via <Alias Context="nci:ExtCodeID">.

Snapshot vs. Transactional Files and 21 CFR Part 11 Audit Trails

What standards or regulatory requirements govern CDISC ODM? When clinical trial records are inspected by the FDA under 21 CFR Part 11 (Electronic Records; Electronic Signatures), the European Medicines Agency (EMA) under EudraLex Volume 4 Annex 11, or ICH E6(R3) Good Clinical Practice, regulators require complete data provenance aligned with ALCOA+ principles (Attributable, Legible, Contemporaneous, Original, Accurate, Complete, Consistent, Enduring, and Available).

CDISC ODM supports two distinct file modes via the FileType attribute:

• FileType="Snapshot": Represents the current state of the study metadata and clinical database at the exact CreationDateTime. In a Snapshot file, every TransactionType defaults to Insert.
• FileType="Transactional": Preserves the chronological sequence of database operations across time. Each clinical data element can carry a TransactionType attribute: Insert (initial data entry), Update (modification of a previously entered value), Remove (soft deletion of an erroneously entered value), Upsert (insert if new, update if existing), or Context (structural parent node navigation).

Within <ClinicalData>, every <SubjectData>, <StudyEventData>, <FormData>, <ItemGroupData>, or <ItemData> record can attach three regulatory compliance child blocks:

• <AuditRecord>: Captures <UserRef UserOID="..."/> (who made the entry or change), <LocationRef LocationOID="..."/> (which clinical site), <DateTimeStamp> (exact ISO 8601 timestamp), <ReasonForChange> (such as “Transcription error corrected per source lab report”), and <SourceID>.
• <Signature>: Records the investigator’s legally binding electronic sign-off, linking <UserRef>, <LocationRef>, <SignatureRef SignatureOID="..."/> (referencing the legal attestation text in <AdminData>), and <DateTimeStamp>.
• <Annotation>: Stores data management comments, protocol deviation flags, or coding notes via <Comment> and <Flag>.

ODM-XML v1.3.2 vs. CDISC ODM v2.0

While ODM-XML v1.3.2 remains the most widely deployed production format across commercial and academic EDC systems, CDISC published ODM v2.0 to modernize clinical trial data exchange for cloud APIs and biomedical concepts:

Architectural Dimension	CDISC ODM-XML v1.3.2	CDISC ODM v2.0
Serialization Formats	XML only (validated against W3C XML Schema ODM1-3-2.xsd).	Dual native serialization in both ODM-XML and ODM-JSON for RESTful web APIs.
Form and ItemGroup Structure	Separate <FormDef> and <ItemGroupDef> layers.	Consolidates <FormDef> into nested, recursive <ItemGroupDef> structures that can represent forms, sections, and sub-groups.
CDISC Library & Biomedical Concepts	Links to controlled terminology via basic <Alias> tags.	Native semantic links to CDISC Library Biomedical Concepts (BCs), HL7 FHIR coding systems, and richer workflow/branching expressions.
Extensions Architecture	Uses XML namespace extensions (`def:` for Define-XML v2.0/v2.1, `sdm:` for Study Design Model, `mdsol:` for Medidata Rave).	Integrates Study Design, SDM-XML, and Dataset-JSON/Define-XML v2.1 alignment directly into the core model.

How Does CDISC ODM Integrate with EHR and Health Informatics Workflows?

In modern clinical trials, manually transcribing patient data from an hospital Electronic Health Record (EHR) into an EDC system’s eCRF is a major source of query volume and monitoring cost. Health informatics pipelines bridge EHRs and CDISC ODM through three standardized pathways:

1. HL7 FHIR Questionnaire and Structured Data Capture (SDC) Mapping: Through the joint HL7 Vulcan Accelerator and CDISC mapping specifications, an ODM <FormDef> / <ItemGroupDef> definition translates directly into an HL7 FHIR Questionnaire resource, while an ODM <ClinicalData> submission maps to a FHIR QuestionnaireResponse. Using the FHIR SDC $populate operation, an EHR can pre-populate an eCRF with vital signs (Observation), medications (MedicationStatement), and lab results, then export the validated values as a CDISC ODM transaction into the sponsor’s EDC.
2. EDC Native ODM Web Services (Rave Web Services, OpenClinica, REDCap): Commercial EDC platforms such as Medidata Rave (via Rave Web Services [RWS] clinical and metadata endpoints), OpenClinica, Castor EDC, and REDCap natively consume and emit CDISC ODM-XML files. REDCap’s “Project XML” export format is a compliant CDISC ODM-XML v1.3.2 file containing either metadata-only or full metadata plus clinical data and audit trails.
3. Automated Transformation to SDTM and Dataset-JSON: Because ODM <ItemDef> and <ItemGroupDef> elements embed CDASH variable names and SDTM domain mappings, ETL pipelines transform operational ODM extracts directly into submission-ready SDTM tables accompanied by an ODM-based define.xml manifest.

Frequently Asked Questions

What is CDISC ODM and how is it used in clinical research and healthcare?

The CDISC Operational Data Model (ODM) is a vendor-neutral, platform-independent data exchange and archiving standard developed by the Clinical Data Interchange Standards Consortium (CDISC). It is used in clinical trials to transport and archive study metadata (protocol visit schedules, eCRF forms, item definitions, and controlled terminology codelists), administrative metadata (users, sites, and signature definitions), and subject-level clinical data alongside complete audit trails and electronic signatures across Electronic Data Capture (EDC) systems.

What standards or regulatory requirements govern CDISC ODM?

CDISC ODM is governed by the CDISC ODM-XML v1.3.2 and ODM v2.0 specifications and serves as the base schema for CDISC Define-XML (v2.0 and v2.1), which is mandated by the U.S. FDA and Japan’s PMDA Study Data Technical Conformance Guides for SDTM, ADaM, and SEND regulatory submissions. Its embedded <AuditRecord>, <Signature>, and <Annotation> elements are specifically engineered to satisfy FDA 21 CFR Part 11, EU Annex 11, and ICH E6(R3) Good Clinical Practice requirements for electronic source records and end-of-study investigator eCRF archives.

How does CDISC ODM integrate with EHR and health informatics workflows?

CDISC ODM integrates with Electronic Health Records (EHRs) and clinical trial systems through automated EHR-to-EDC eSource pipelines and bidirectional mappings with HL7 FHIR R4. Under the HL7 Vulcan and CDISC FHIR-to-CDISC Joint Mapping initiatives, FHIR Questionnaire and QuestionnaireResponse resources (using the Structured Data Capture [SDC] Implementation Guide) map directly to ODM FormDef/ItemGroupDef metadata and ClinicalData subject records, enabling EDC platforms such as Medidata Rave, OpenClinica, Castor EDC, and REDCap to ingest structured clinical data.