Operational Data Model, or ODM for short, is a vendor-neutral, platform-independent CDISC format for exchanging and archiving clinical and translational research data. It can consolidate clinical data, metadata, administrative and reference data, as well as audit information. ODM therefore describes a transport and archiving model that enables systems to exchange information across the study lifecycle.<\/p>\n
ODM can represent data for individual participants, aggregated groups of people, and integrated research studies. In addition to the observed data, the model takes the associated metadata into account, for example the definition of form items. Administrative details, reference data, and audit information are also included. This combination is important because an isolated value table does not explain which question was asked or under which rules a data point was captured.<\/p>\n
In EDC environments, ODM is often used to represent case report form content. This allows a form specification to be transferred between systems without tying the domain concept to a specific vendor. However, actual adoption still requires checking target functions such as visit logic, permissions, validation rules, and local configurations; a transmitted format is not an automatically production-ready study application.<\/p>\n
According to CDISC, ODM v2.0 is intended for information shared between software systems when setting up, conducting, analysing, submitting, and archiving a study. The standard can be serialised in XML, JSON, and other formats; CDISC provides an XML schema for ODM v2.0. The model\u2019s function remains the same, even if the technical representation differs.<\/p>\n
The shared foundation facilitates extensions: CDISC cites Define-XML, SDM-XML, Dataset-XML, Dataset-JSON, CTR-XML, and CT-XML as standards that refer to ODM or use a common basis. The result is not interchangeability of the documents. Rather, a data flow can combine different specialised standards, provided it is clear in each case whether forms, table values, or metadata are being described.<\/p>\n
ODM transports data and associated information between systems or preserves them for archiving. Define-XML, by contrast, describes the content of a submitted data set for the regulatory reviewer, such as variables, codelists, and derivations. Define-XML therefore cannot replace the operational transfer of an eCRF model, while ODM alone does not provide the complete submission interpretation of an SDTM or ADaM package.<\/p>\n
Dataset-JSON is a dedicated JSON-based format for tabular data. Although ODM v2.0 can also be serialised as JSON, this does not mean that every ODM JSON file is Dataset-JSON. This distinction prevents errors in interface specifications because the two formats have different target objects and metadata expectations.<\/p>\n
File-level interchangeability does not remove responsibility for semantics and governance. Two systems may be able to read the same ODM structure but apply different rules for required fields, repeating groups, or local codings. Before adoption, representative forms and test subjects should therefore be used to verify whether the transferred data have the same meaning and the same processing status in the target system. The handling of audit information and technical identifiers must also be explicitly agreed.<\/p>\n
For archiving, ODM offers the opportunity to preserve data and descriptive information together. However, long-term readability, storage location, and responsibility must also be governed separately. An ODM export is not a substitute for an archiving concept if it remains unclear which viewers, schemas, or reference files will be available in the future. The benefit only arises through a complete archiving environment with controlled access.<\/p>\n
For every migration, a back-check should also be planned to verify whether samples in the target system actually reproduce the expected form structure, repetitions, and value handling.<\/p>\n
This makes migrations visible that are formally successful but substantively incorrect.<\/p>\n
ODM is particularly relevant when a study form is to be transferred from a build system into an EDC, when data are handed over during a vendor change, or when study information is to be archived long term. Before exchange, the source and target systems must clearly specify which ODM elements are used and how deviations are handled. Especially with complex repeating structures, an apparently complete import can create scientifically incorrect visits or forms.<\/p>\n
Full-service CROs such as Mediconomics support ODM-based eCRF specifications, the review of export and import files, and the documentation of system handovers. Data Management and Clinical Operations can coordinate mapping tables, user acceptance tests, and the controlled release of the transferred form logic, while Quality Assurance assesses the evidence for archiving or vendor changes.<\/p>\n
Is ODM only an XML format?<\/strong><\/p>\n No. According to CDISC, ODM v2.0 can be serialised in XML, JSON, and other formats. A dedicated schema is available for XML.<\/p>\n Can ODM generate an eCRF directly in every EDC system?<\/strong><\/p>\n ODM can represent and exchange CRF content. Whether a target system correctly adopts all elements depends on its implementation and on the agreed configurations.<\/p>\n Does ODM fully describe the analysis derivations of an ADaM package?<\/strong><\/p>\n Not as its primary purpose. For the submission-related description of datasets, variables, and derivations, Define-XML is the dedicated metadata standard.<\/p>\n Operational Data Model, or ODM for short, is a vendor-neutral, platform-independent CDISC format for exchanging and archiving clinical and translational research data. It can consolidate clinical data, metadata, administrative and reference data, as well as audit information. ODM therefore describes a transport and archiving model that enables systems to exchange information across the study lifecycle. […]<\/p>\n","protected":false},"author":10,"featured_media":0,"parent":0,"template":"","meta":{"_acf_changed":false,"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"glossary-cat":[25],"class_list":["post-8028","glossary","type-glossary","status-publish","hentry","glossary-cat-datenmanagement-eclinical"],"acf":[],"related_terms":"","external_url":"","internal_reference_id":"","_links":{"self":[{"href":"https:\/\/mediconomics.com\/en\/wp-json\/wp\/v2\/glossary\/8028","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mediconomics.com\/en\/wp-json\/wp\/v2\/glossary"}],"about":[{"href":"https:\/\/mediconomics.com\/en\/wp-json\/wp\/v2\/types\/glossary"}],"author":[{"embeddable":true,"href":"https:\/\/mediconomics.com\/en\/wp-json\/wp\/v2\/users\/10"}],"version-history":[{"count":0,"href":"https:\/\/mediconomics.com\/en\/wp-json\/wp\/v2\/glossary\/8028\/revisions"}],"wp:attachment":[{"href":"https:\/\/mediconomics.com\/en\/wp-json\/wp\/v2\/media?parent=8028"}],"wp:term":[{"taxonomy":"glossary-cat","embeddable":true,"href":"https:\/\/mediconomics.com\/en\/wp-json\/wp\/v2\/glossary-cat?post=8028"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Regulatory References<\/h2>\n
\n