1

CDISC - Operational Data Model

Presented by

© CDISC 2015 2
CDISC Educational Materials
Intellectual Property Notice
Sharing, copying, recording or reselling any
CDISC educational material is strictly prohibited.

This includes face-to-face and eLearning audio, handouts,

slides, quizzes, and all other materials provided as part of
CDISC Educational offerings.

© CDISC 2013
2015
 Topics
• Introduction to the ODM

• Use Cases

• Why XML?

• The Model in Detail

• Interchange Process

• Other CDISC XML Standards

4
© CDISC 2015
 Course Objectives
At the end of the course students will
• Understand the purpose of the ODM.
• Know how the ODM represents clinical trials data and
metadata.
• Understand how the ODM administrative data supports US
FDA requirements for Computer Systems Used in Clinical
Trials.
• Know how to plan a successful ODM implementation
project.
• Know how the ODM harmonizes with other CDISC models.
5
© CDISC 2015
Introductions
• Name

• Job function/role

• CDISC Models & XML background

6
© CDISC 2015
 Topics

Introduction to the ODM

Operational
Data Model Use Cases

Why XML?

The Model in Detail

Interchange Process

Other CDISC XML Standards

7
© CDISC 2015
Design
CDISC XML Technology

Protocol CDASH SDTM ADaM

Study Design Lab SEND

XML Data Exchange Define-XML

SDM-XML ODM
SDM-XML ODM Dataset-XML
Define-XML

Glossary

BRIDG Therapeutic Areas

SHARE Questionnaires

Controlled Terminology Healthcare Link

© CDISC 2015
 Protocol CDASH SDTM ADaM

Study Designc Lab SEND

XML Data Exchange

Define-XML
SDM-XML
SDM-XML ODM
ODM Define-XML
Dataset-XML

Glossary
Therapeutic Areas
BRIDG

SHARE Questionnaires

Controlled Terminology Healthcare Link

© CDISC 2015
Introduction to CDISC XML Technologies
• CDISC has developed a family of XML based
standards for clinical trials data.
• Core model is the Operational Data Model.

ODM
SDM- Define-XML
XML Dataset-XML

10
© CDISC 2015
Role of CDISC XML Technologies
• Standardize XML representations of clinical study
data
• Provide an industry standard to enable integration
of clinical systems
• Promote interoperability of clinical data
applications between organizations and across
vendor platforms
• Provide a clinical data archive format compliant
with applicable FDA guidance
• Facilitate ‘end-to-end’ CDISC implementations

11
© CDISC 2015
 Clinical Systems

Trial
z
Management
System
Clinical Trial
Protocol
z
ETL

z
EDC

Data/
Documents
Metadata
z
SAS

Protocol z
Lab Setup
IRB
Amendments

CSR SAP Metadata

Data

12
© CDISC 2015
ODM Support for Clinical Systems
Integration
• ODM provides a standard for representation of
 Metadata
 Administrative data
 Subject related clinical data
 Reference data
• ODM provides flexibility needed to support the
natural variations in
 Study designs
 Data collection methods
 Application functionality
• ODM is harmonized with the CDISC foundational
standards and is compatible with the ‘Semantic
Stack’
13
© CDISC 2015
ODM Support for Interoperability
BRIDG

CDISC Controlled Terminology

SHARE

XML platform
ODM XML Schema
Flexible Metadata

14
© CDISC 2015
Clinical Data Archiving
• Why archive?
 FDA data retention requirements
 Reduce clutter
 Easier system upgrades
 Manage storage costs

• Challenges
 Retaining data context
 Archive format must be compatible with new software
versions

15
© CDISC 2015
 CDISC “end-to-end” process
CRO Sponsor

Archive

Investigator

Subject LABs

16
© CDISC 2015
 CDISC “end-to-end” process
CRO Sponsor

SDTM+/-

Investigator

Subject LABs

17
© CDISC 2015
 CDISC “end-to-end” process
CRO Sponsor

SDTM+/- Archive
ODM

Investigator

Subject LABs

18
© CDISC 2015
 ODM Use Cases
• Automated setup of EDC / CDM systems
• Data transmission from 3rd party data providers (CROs,
EDC vendors) to sponsors
• Clinical data archiving
• Clinical data standards metadata repositories
• Submission of SDTM and ADaM metadata
• Proposed replacement for SAS XPT for submissions
(FDA Pilot)
• Electronic Health Record Integration

19
© CDISC 2015
Automated Study Setup

EDC Design

Standard Form
Definitions

20
© CDISC 2015
 Automated Setup of EDC/eCRF systems

ODM
XML

• ODM Metadata can be used to configure data

collection tools
• eCRF systems
 Several vendors using ODM-based mechanisms
• eDiary/ePRO systems
 At least one system uses ODM for configuration
purposes

21
© CDISC 2015
 e-CRF example 1

XForms eCRF Layout

Courtesy of Assero 22
© CDISC 2015
 e-CRF example 2

Courtesy of Formedix 23
© CDISC 2015
 e-CRF example 3

XClinicial eCRF Layout

Courtesy of XClinical 24
© CDISC 2015
 e-CRF example 4

Courtesy of XML4Pharma

25
© CDISC 2015
 e-CRF example 5

Courtesy of Outcome 26
© CDISC 2015
Data Interchange Process
• Typical scenario
 Sponsor provides study
specifications to CRO
 Data management works with
EDC vendors to setup study
 At pre-specified time points study
data is provided for review &
quality management
 At pre-specified study milestone,
data is provided for interim
analysis
 At end of study, sponsor receives
final database
 Changes are made to study data
collection plan if needed to
improve data quality

27
© CDISC 2015
 Data Provider Use Case
• Many clinical trials involve outsourcing to CROs,
EDC providers, ePro providers, etc
• Typical work flow

SPONSOR Specifications Data Provider

SPONSOR Data Provider

CollectedData

28
© CDISC 2015
Data Interchange Process
• ODM enabled metadata interchange
process

PDF

Specifications
Word
ODM XML

Excel

• ODM enabled data interchange

process

ASCII

ODM XML SAS

Transport
CollectedData

SAS
Datasets

29
Data Flow for ODM Interchange
EDC/CRO Sponsor

Specifications
Meta Meta
Data Data
StudySetup
MetaData

Timeline
Study
CRF
Data New and EDC/CRO Data
Data Changed Data

Coding

Lab Data

30
© CDISC 2015
 Evolving Use Case: integration with Electronic
Health Records
Sponsor
• ODM supports integration of
EHR with sponsor systems
• ODM being employed to help Sponsor
meet regulatory requirements Database

ODM

Source
Data EHR

31
© CDISC 2015
 Retrieve Form for Data Capture (RFD)

2. Request 1. Form
Form Definition

ODM &
XForms

ODM

3. Enter Offline: Use

Data 4. Submit ODM metadata
ODM Data to create form
Single Entry
EHR Double Use
CDM

Sponsor
Site ODM

5. Archive Data
(eSource!) Form Archiver 32
© CDISC 2015
Define-XML
Provides metadata for
data submissions
• Developed to support
submission of CDISC
datasets to the FDA

33
© CDISC 2015
Define-XML provides Dataset-XML Metadata

© CDISC 2015
 Topics

Introduction to the ODM

Operational
Data Model Use Cases

Why XML?

The Model in Detail

Interchange Process

Other CDISC XML Standards

35
© CDISC 2015
Why XML?
• Designed for interchange of data between
heterogeneous systems
 Enables automated data exchange between applications
• Well suited for clinical data applications
• Text based, human readable format
• Vendor neutral
• Platform independent
• Flexible

36
© CDISC 2015
World Wide Web Consortium
• Mission of W3C is to develop interoperable
technologies to lead the Web to its full potential
• Web Address
 http://www.w3.org

37
© CDISC 2015
W3C

38
© CDISC 2015
What is XML?
• XML (Extensible Markup Language) is a
markup language for documents containing
structured information
 Derived from SGML – as is HTML
• A markup language provides a way to
identify structures in a document. The XML
specification defines a standard way to add
markup to documents
• The focus of XML is on content and
structure, not presentation
 In contrast to HTML where focus is on
presentation 39
© CDISC 2015
Tags
• Tags
 Enclosed within < and > characters
• Start Tag
<TAG>
• End Tag
</TAG>
• Can Combine
<TAG/>

40
© CDISC 2015
Elements
• An element
 Everything between the start of a start-tag to the end of
the end-tag
<TAG>This is the tag content</TAG>
 Element name: TAG
 Element content: This is the tag content

41
© CDISC 2015
Elements
• Elements can be hierarchical
<Name>
<FirstName>Fred</FirstName>
</Name>
 FirstName is a child of Name
 Name is the parent of FirstName

42
© CDISC 2015
Elements
• Can also have siblings
<Name>
<FirstName>Fred</FirstName>
<LastName>Smith</LastName>
</Name>

43
© CDISC 2015
Elements
• Comments
<!-- This is a comment -->
<!–- A another comment
over a line -->

44
© CDISC 2015
Elements
• Tags must be balanced
• Either
<TAG> ……… </TAG>
• Or
<TAG/>

45
© CDISC 2015
Elements
• Tags must not overlap. The following is invalid
<ContactList>
<Name>
<FirstName>Fred</FirstName>
<LastName>Smith
</Name> </LastName>
</ContactList>

46
© CDISC 2015
Elements
• The highest level element in the document file is
known as the root element
<ContactList>
<Name>
<FirstName>Fred</FirstName>
<LastName>Smith</LastName>
</Name>
</ContactList>

• ContactList is the root element

47
© CDISC 2015
Elements
• Only one root element is permitted in an XML file
<Name>
<FirstName>Fred</FirstName>
<LastName>Smith</LastName>
</Name>
<Name>
<FirstName>Fred</FirstName>
<LastName>Smith</LastName>
</Name>

48
© CDISC 2015
Attributes
• Start-tags can also have attributes
 <FirstName
nickname="Cat">Catherine</FirstName>
 Attribute name: nickname
 Attribute value: Cat
• Can have multiple attributes
 <TAG attr1="1" attr2="2">Content
Here</TAG>
 or
 <TAG attr1="1" attr2="2"/>

49
© CDISC 2015
Example

50
© CDISC 2015
<PlayList name="MyPlaylist"
CreationDate="2013-09-19"> Root Element
<Song PlayTime="227">
<Title>Shattered</Title>
<Artist>Rolling Stones</Artist> Attributes
<Album Genre="Rock">
<Title>Some Girls (Deluxe Edition)</Title>
</Album>
</Song>
Elements
<Song PlayTime="231">
<Title>Eet</Title>
<Artist>Regina Spektor</Artist>
<Album Genre="Alternative">
<Title>Far</Title>
</Album>
</Song>
…
</PlayList>

51
© CDISC 2015
<PlayList name="MyPlaylist"
CreationDate="2013-09-19"> Root Element
<Song PlayTime="227">
<Title>Shattered</Title>
<Artist>Rolling Stones</Artist> Attributes
<Album Genre="Rock">
<Title>Some Girls (Deluxe Edition)</Title>
</Album>
</Song>
Elements
<Song PlayTime="231">
<Title>Eet</Title>
<Artist>Regina Spektor</Artist>
<Album Genre="Alternative">
<Title>Far</Title>
</Album>
</Song>
…
</PlayList>

52
© CDISC 2015
XML File Validation
• XML files are known as XML Documents

• XML Documents must be “well-formed”

 Must have a root element
 Each element must have a closing tag
<Playlist> …</Playlist>
Any well formed XML document can be displayed in a
browser.
• In order to automatically validate the content of
an XML Document an XML schema must be
defined and referenced.

53
© CDISC 2015
XML Schemas
• Definition:
 XML documents that describe structure and content for
a specific type of XML document
• Purpose:
 Standardize contents of XML documents for a specific
use case.
• XML namespace declarations
• Define allowable elements and attributes
• Define allowable datatypes for element and
attributes
• Define relationships between elements and attributes
• Define enumerations
 Support validation of XML documents

54
© CDISC 2015
Playlist Schema
Playlist Attributes name

CreationDate

Song Attributes Playtme

Title

Artist

Album Attributes Genre

Title

© CDISC 2015
 http://en.wikipedia.org/wiki/XML_namespace

XML Namespaces

57
© CDISC 2015
What Do Schemas Do ?
• Declare XML Namespaces
• Define data types, elements, attributes
• Define relationships between elements,
repeatability
• Provide an outline for an XML instance document
• Support standardization of XML documents
• Enable validation of XML documents

58
© CDISC 2015
ODM Document Conformity
Compliant with normative content in ODM
specification

&
Validates to ODM Schema

59
© CDISC 2015
 Transformations
• XSL – Extensible Stylesheet Language
• Used to transform an XML document
• Requires a tool known as XSLT processor
• Focuses on presentation while XML focuses on content and
structure

XML Document New Document

XSLT
Processor

<?xml version="1.0"?> XSL Document

<xsl:stylesheet version="1.0“ ... 60
© CDISC 2015
Playlist Transformed by XSL

© CDISC 2015
Applying XSL
• XSL may be use stand-alone to convert CDISC
ODM XML files into a variety of formats, including
HTML, CSV and SAS
• XSL may be used in tandem with other
technologies for more sophisticated applications

62
© CDISC 2015
XSL and ODM

ODM file displayed with no

stylesheet!

63
© CDISC 2015
Stylesheet #1

64
© CDISC 2015
Stylesheet #2

65
© CDISC 2015
 The ODM

Operational
Data Model
Break

66
© CDISC 2015
 Topics

Introduction to the ODM

Operational
Data Model Use Cases

Why XML?

The Model in Detail

Interchange Process

Other CDISC XML Standards

67
© CDISC 2015
Diagram Conventions
ODM Required element

Study Optional element

= 0 to many
= 1 to many
= has child elements

attributes

@ Description Required attribute

@ FileType Optional attribute

68
© CDISC 2015
 ODM Element
attributes
ODM
@ Description

@ FileType
Study
@ Granularity

@ Archival
AdminData
@ FileOID

ReferenceData @ CreationDateTime

@ PriorFileOID
ClinicalData @ AsOfDateTime

@ ODMVersion
Association @ Originator

@ SourceSystem
ds:signature
@ SourceSystemVersion

@ ID
69
© CDISC 2015
 ODM Element
<?xml version="1.0" encoding="ISO-8859-1"?>
<ODM xmlns="http://www.cdisc.org/ns/odm/v1.2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xlink="http://www.w3.org/1999/xlink"
xsi:schemaLocation="http://www.cdisc.org/ns/odm/v1.2 ODM1-2-0.xsd"

FileOID="CES_001"
FileType="Transactional"
Granularity="All"
CreationDateTime="2005-01-01T12:00:00+01:00">

<Study OID="CES">
<!-- more here -->
</Study>

<AdminData StudyOID="CES">
<!-- more here -->
</AdminData>

<ClinicalData StudyOID="CES" MetaDataVersionOID="CES_MDV_V1">

<!-- more here -->
</ClinicalData>

</ODM>

70
© CDISC 2015
ODM Element
• ODM is the root element for all ODM XML
documents
 First XML tag in the XML file.
 Every XML document must have a root element
• Serves as a header – provides important
information about the enclosed data
 Which version of the ODM? (Enumerated list)
 When was it created? (date time stamp)
 How current is the data?
 Who sent it?
 Which options are enabled?

 XML Namespace, schema location

71
© CDISC 2015
ODM Document Files
• May contain information for one or more studies
 File size limitations for many email programs, source
code control systems
 Transmission of very large files problematic
• Data for a single study may be broken into several
files
 Use @PriorFileOID attribute in ODM element
 Refer to OID scoping in ODM specification

72
© CDISC 2015
 ODM Element
attributes
ODM
@ Description

@ FileType
Study MetaData @ Granularity

@ Archival
AdminData
@ FileOID

ReferenceData @ CreationDateTime

@ PriorFileOID
ClinicalData Data & Audit @ AsOfDateTime
@ ODMVersion
Association @ Originator

@ SourceSystem
ds:signature
@ SourceSystemVersion

@ ID
73
© CDISC 2015
 ODM: MetaData

Site Details

Site No.:_______

ODM
Subject's Characteristics

Number:_______

Sex: M [] F[]
XML
Height: _________ cm

Weight: _________ kg

74
© CDISC 2015
 ODM Metadata
Study

MetaData

Protocol

StudyEvent

Form

ItemGroup

Item

75
© CDISC 2015
 ODM Metadata
Study

MetaData

Protocol

StudyEvent

Form

ItemGroup

Item

76
© CDISC 2015
 Study Element
attributes
Study

GlobalVariables @ OID

BasicDefinitions

MetaDataVersion

77
© CDISC 2015
 GlobalVariables Element
GlobalVariables

StudyName

StudyDescription

ProtocolName

<GlobalVariables>
<StudyName>CDISC Example Study</StudyName>
<StudyDescription>A simple trial to demonstrate the end-to-end
application of the CDISC Standards</StudyDescription>
<ProtocolName>CDISC Example Study</ProtocolName>
</GlobalVariables>

78
© CDISC 2015
 BasicDefinitions Element
BasicDefinitions
attributes

MeasurementUnit @ OID

@ Name
Symbol
attributes
TranslatedText

attributes
@ xml:lang

Alias
@ Context

@ Name

79
© CDISC 2015
 80
© CDISC 2015
 BasicDefinitions Element
<BasicDefinitions>
<MeasurementUnit OID="MU.4372" Name="BPM">
<Symbol>
<TranslatedText xml:lang="en">Breaths Per Minute</TranslatedText>
</Symbol>
</MeasurementUnit>
<MeasurementUnit OID="MU.4371" Name="C">
<Symbol>
<TranslatedText xml:lang="en">Celsius</TranslatedText>
</Symbol>
</MeasurementUnit>
<MeasurementUnit OID="MU.4377" Name="CM">
<Symbol>
<TranslatedText xml:lang="en">Centimeters</TranslatedText>
</Symbol>
</MeasurementUnit>
<MeasurementUnit OID="MU.4376" Name="KG">
<Symbol>
<TranslatedText xml:lang="en">Kilograms</TranslatedText>
</Symbol>
</MeasurementUnit>
<MeasurementUnit OID="MU.4378" Name="KG/M">
<Symbol>
<TranslatedText xml:lang="en">Kilograms/Meter</TranslatedText>
</Symbol>
</MeasurementUnit>
</BasicDefinitions> 81
© CDISC 2015
 MetaDataVersion Element
MetaDataVersion
attributes
Include
@ OID
Protocol
@ Name
StudyEventDef
@ Description
FormDef

ItemGroupDef

ItemDef

CodeList

Presentation

ConditionDef

MethodDef

82
© CDISC 2015
 Protocol Element
attributes
Protocol
@ StudyEventOID

StudyEventRef @ OrderNumber

Alias @ Mandatory

<Protocol>
<StudyEventRef StudyEventOID="BASELINE" Mandatory="Yes" OrderNumber="1"/>
<StudyEventRef StudyEventOID="WEEK_1" Mandatory="Yes" OrderNumber="2"/>
<StudyEventRef StudyEventOID="WEEK_2" Mandatory="Yes" OrderNumber="3"/>
<StudyEventRef StudyEventOID="DIARY" Mandatory="Yes" OrderNumber="4"/>
<StudyEventRef StudyEventOID="AE" Mandatory="No" OrderNumber="5"/>
</Protocol>

83
© CDISC 2015
 StudyEventDef Element attributes
StudyEventDef
@ OID
FormRef
@ Name
attributes
Description @ Repeating
@ FormOID
@ Type
Alias @ OrderNumber
@ Category
@ Mandatory

<StudyEventDef OID="BASELINE"
Name="Baseline Visit"
Repeating="No"
Type="Scheduled">
<FormRef FormOID="F_BASELINE" Mandatory="Yes" OrderNumber="1"/>
<FormRef FormOID="F_CM" Mandatory="Yes" OrderNumber="2"/>
<FormRef FormOID="F_LAB" Mandatory="Yes" OrderNumber="3"/>
</StudyEventDef>

84
© CDISC 2015
 Description
StudyEventDef
attributes

Description @ OID
TranslatedText @ Name
FormRef
@ Repeating

Alias attributes @ Type

@ xml:lang @ Category

85
© CDISC 2015
 Alias Element

attributes

Alias @ Context

@ Name

Provides support for mapping identifiers between applications.

May be used on any MetaData element: Protocol, StudyEventDef,
FormDef, ItemGroupDef, ConditionDef, MethodDef or with the
MeasurementUnit element

86
© CDISC 2015
 FormDef Element attributes
FormDef

@ OID
ItemGroupRef
@ Name
attributes
ArchiveLayout @ Repeating
@ ItemGroupOID
Description
0..1
@ OrderNumber

Alias @ Mandatory

<FormDef OID="F_WEEK_1_2"
Name="Week 1 and 2 Form"
Repeating="No">
<ItemGroupRef ItemGroupOID="IG_COMMON"
Mandatory="Yes"
OrderNumber="1"/>
<ItemGroupRef ItemGroupOID="IG_PE_WEEK"
Mandatory="Yes"
OrderNumber="2"/>
</FormDef> 87
© CDISC 2015
 ArchiveLayout Element

attributes

ArchiveLayout @ OID

@ PdfFileName

@ PresentationOID
PDF file stores eCRF layout

88
© CDISC 2015
 ItemGroupDef Element attributes
ItemGroupDef

@ OID
Description
@ Name
ItemRef attributes
@ Repeating
@ ItemOID @ IsReferenceData
Alias
@ OrderNumber @ SASDatasetName

@ Mandatory @ Domain

@ Origin
@ KeySequence
@ Role
@ MethodOID
@ Purpose
@ Role @ Comment

@ RoleCodeListOID

@ CollectionExceptionConditionOID

89
© CDISC 2015
 Derivations and Conditional
Navigation attributes
ItemGroupDef

@ OID
Description
@ Name
ItemRef attributes
@ Repeating
@ ItemGroupOID @ IsReferenceData
Alias
@ OrderNumber @ SASDatasetName

@ Mandatory @ Domain

@ Origin
@ KeySequence
@ Role
@ MethodOID
@ Purpose
@ Role @ Comment

@ RoleCodeListOID

@ CollectionExceptionConditionOID

90
© CDISC 2015
 MethodDef
MethodDef
attributes

@ OID
Description
TranslatedText @ Name
FormalExpression
@ Type
Alias attributes

@ Context
Notes:
• Description is MANDATORY
• OID must match ItemRef/@MethodOID

91
© CDISC 2015
 ConditionDef
ConditionDef
attributes

@ OID
Description
TranslatedText @ Name
FormalExpression

Alias attributes

@ Context

Defines when entry will be skipped.

<ConditionDef Name="Non-Smoker" OID="COND.NSMK">
<Description>
<TranslatedText xml:lang="en">Subject has never smoked.</TranslatedText>
</Description>
<FormalExpression Context="MyLang">SmokingStatus = "No"</FormalExpression>
</ConditionDef>
92
© CDISC 2015
 ItemDef Element
ItemDef
attributes

Description @ OID

Question @ Name

@ DataType
ExternalQuestion
@ Length
MeasurementUnitRef @ SignificantDigits

@ SASFieldName
RangeCheck
@ SDSVarName

CodeListRef @ Origin

@ Comment
Alias

93
© CDISC 2015
 ItemDef Element
<ItemDef OID="I_SITE"
Name="Site Number"
DataType="text"
Length="3"
SDSVarName="SITEID"
SASFieldName="SITEID">
<Description>
<TranslatedText xml:lang="en">Site # where
subject is enrolled</TranslatedText>
</Description>
<Question>
<TranslatedText xml:lang="en">Site #</TranslatedText>
</Question>
</ItemDef>

94
© CDISC 2015
 CodeListRef and CodeList Elements

CodeListRef attributes

@ CodeListOID

CodeList
attributes

attributes @ OID
OR
@ CodedValue
@ Name
CodeListItem @ Rank
@ SASFormatName

OR Decode TranslatedText

EnumeratedItem attributes

@ CodedValue
ExternalCodeList
95
© CDISC 2015
 CodeList Element
<CodeList OID="CL_SEX"
Name="Sex"
DataType="text"
SASFormatName="$SEX">
<CodeListItem CodedValue="M">
<Decode>
<TranslatedText xml:lang="en">Male</TranslatedText>
<TranslatedText xml:lang="fr">Masculin</TranslatedText>
<TranslatedText xml:lang="de">Männlich</TranslatedText>
</Decode>
</CodeListItem>
<CodeListItem CodedValue="F">
<Decode>
<TranslatedText xml:lang="en">Female</TranslatedText>
<TranslatedText xml:lang="fe">Féminin</TranslatedText>
<TranslatedText xml:lang="de">Weiblich</TranslatedText>
</Decode>
</CodeListItem>
</CodeList>

96
© CDISC 2015
 RangeCheck Element

RangeCheck

CheckValue
attributes
OR
FormalExpression @ Comparator
@ SoftHard
MeasurementUnitRef

ErrorMessage

<FormalExpression context="javascript">
this.item.test(previous.item.text)
</FormalExpression>

97
© CDISC 2015
 MetaDataVersion Element
MetaDataVersion

Include

Protocol StudyEventRef

StudyEventDef FormRef

FormDef ItemGroupRef
ConditionRef
ItemGroupDef ItemRef
MethodRef
ItemDef CodeListRef

CodeList

ConditionDef

MethodDef

98
© CDISC 2015
Exercise
•
 Develop the ODM metadata for
the simple form shown below

Site Details

Site No.: _______

Subject's Characteristics

Number: _______

Sex: M [] F[]

Height: _________ cm

Weight: _________ kg
100
© CDISC 2015
 Exercise
Study

MetaData

Protocol
Site Details
StudyEvent
Site No.: _______
Form
Subject's Characteristics
ItemGroup
Number: _______
Item
Sex: M [] F[]

Height: _________ cm

Weight: _________ kg

101
© CDISC 2015
 Exercise
Study

MetaData

Protocol

StudyEvent

Form

ItemGroup

<Study OID="CES"> Item

<!-- Something here -->
</Study>

102
© CDISC 2015
 Exercise
Study

MetaData

Protocol

StudyEvent

Form

ItemGroup
<Study OID="CES">
<!-- Something here --> Item
<MetaDataVersion OID="CES_MDV_V1"
Name="CDISC Example Study Metadata">
<!-- Something here -->
</MetaDataVersion>
</Study>

103
© CDISC 2015
 Exercise
Study

MetaData

Protocol

StudyEvent

Form

<Study OID="CES"> ItemGroup

<!-- Something here -->
Item
<MetaDataVersion OID="CES_MDV_V1"
Name="CDISC Example Study Metadata">
<Protocol>
<!-- Something here -->
</Protocol>
</MetaDataVersion>
</Study>

104
© CDISC 2015
 Exercise
Study

MetaData

Protocol
Site Details
StudyEvent
Site No.: _______
Form
Subject's Characteristics
ItemGroup
Number: _______
Item
Sex: M [] F[]

Height: _________ cm

Weight: _________ kg
Single Event

105
© CDISC 2015
 Exercise
Study

MetaData

Protocol

StudyEvent

Form

ItemGroup

<Protocol> Item
<StudyEventRef StudyEventOID="BASELINE"
Mandatory="Yes"
OrderNumber="1"/>
</Protocol>

106
© CDISC 2015
 Exercise
Study

MetaData

Protocol
Site Details
StudyEvent
Site No.: _______
Form
Subject's Characteristics
ItemGroup
Number: _______
Item
Sex: M [] F[]

Height: _________ cm

Weight: _________ kg
Single Form

107
© CDISC 2015
 Exercise
Study

MetaData

Protocol

StudyEvent

Form

<StudyEventDef OID="BASELINE" ItemGroup

Name="Baseline Visit"
Item
Repeating="No"
Type="Scheduled">
<FormRef FormOID="F_BASELINE"
Mandatory="Yes"
OrderNumber="1"/>
</StudyEventDef>
108
© CDISC 2015
 Exercise
Study

MetaData

Protocol
Site Details
StudyEvent
Site No.: _______
Form
Subject's Characteristics
ItemGroup
Number: _______
Item
Sex: M [] F[]

Height: _________ cm

Weight: _________ kg Two ItemGroups

109
© CDISC 2015
 Exercise
Study

MetaData

Protocol

StudyEvent

<FormDef OID="F_BASELINE" Form

Name="Baseline Visit Form"
ItemGroup
Repeating="No">
<ItemGroupRef ItemGroupOID="IG_COMMON" Item
Mandatory="Yes"
OrderNumber="1"/>
<ItemGroupRef ItemGroupOID="IG_VS"
Mandatory="Yes"
OrderNumber="2"/>
</FormDef>
110
© CDISC 2015
 Exercise
Study

MetaData

Protocol
Site Details
StudyEvent
Site No.: _______
Form
Subject's Characteristics
ItemGroup
Number: _______
Item
Sex: M [] F[]

Height: _________ cm

Weight: _________ kg Five Items

111
© CDISC 2015
 Exercise
Study

MetaData

Protocol

<ItemGroupDef OID="IG_COMMON"
StudyEvent
Repeating="No"
SASDatasetName="COMMON"
Name="Common" Form
Domain="DM">
<ItemRef ItemOID="I_SITE"
ItemGroup
Mandatory="Yes"
OrderNumber="1"/> Item
<ItemRef ItemOID="I_SUBJECTID“
Mandatory="Yes"
OrderNumber="2"/>
<ItemRef ItemOID="I_SEX"
Mandatory="Yes"
OrderNumber="3"/>
</ItemGroupDef>

112
© CDISC 2015
 Exercise
Study

MetaData

Protocol

StudyEvent

Form
<ItemDef OID="I_SITE"
ItemGroup
Name="Site Number"
DataType="text"
Item
Length="3"
SDSVarName="SITEID"
SASFieldName="SITEID">
<Question>
<TranslatedText xml:lang="en">Site
No.</TranslatedText>
</Question>
</ItemDef>

113
© CDISC 2015
 Exercise
Study

MetaData

Protocol

StudyEvent

Form
<ItemDef OID="I_SEX"
ItemGroup
Name="Sex"
DataType="text"
Item
SDSVarName="SEX"
Length="1"
SASFieldName="GENDER">
<Question>
<TranslatedText xml:lang="en">Sex</TranslatedText>
</Question>
<CodeListRef CodeListOID="CL_SEX"/>
</ItemDef>
114
© CDISC 2015
 ODM: Data

Site Details

Site No.:___5___

ODM
Subject's Characteristics

Number:__12___

Sex: M [Y] F[]

XML
Height: ___1560__ cm

Weight: ___87.2___ kg

115
© CDISC 2015
 ODM Data
ClinicalData

SubjectData

StudyEvent

Form

ItemGroup

Item

116
© CDISC 2015
 ODM Data
ClinicalData

SubjectData

StudyEventData

FormData

ItemGroupData

ItemData

117
© CDISC 2015
 ClinicalData Element
ClinicalData
attributes

@ StudyOID
SubjectData
@ MetaDataVersionOID

AuditRecords

Signatures
<ClinicalData StudyOID="MyStudy"
Annotations
MetaDataVersionOID="MDV1">
<SubjectData SubjectKey="1001"/>
<SubjectData SubjectKey="1002"/>
…
</StudyEventData>

118
© CDISC 2015
 SubjectData Element
SubjectData

attributes
Audit

Signature @ SubjectKey

InvestigatorRef @ TransactionType

SiteRef Audit
Annotation Signature

Annotation
StudyEventData Audit

FormData Signature

ArchiveLayoutRef

Annotation Audit

Signature
ItemGroupData Annotation

ItemData

119
© CDISC 2015
 StudyEventData Element
StudyEventData
attributes
Audit

Signature @ StudyEventOID

Annotation @ StudyEventRepeatKey

@ TransactionType
FormData

<StudyEventData StudyEventOID="BASELINE">
<FormData FormOID="F_CONSENT"/>
<FormData FormOID="F_DEMOG"/>
<FormData FormOID="F_Inclusion"/>
<FormData FormOID="F_Exclusion"/>
</StudyEventData>
© CDISC 2015
120
 FormData Element
FormData
attributes
Audit

Signature @ FormOID

ArchiveLayoutRef @ FormRepeatKey

Annotation @ TransactionType

ItemGroupData

<FormData FormOID="F_BASELINE”>
<ItemGroupData ItemGroupOID="IG_COMMON"/>
<ItemGroupData ItemGroupOID="IG_DEMOG"/>
<ItemGroupData ItemGroupOID="IG_LAB" />
<ItemGroupData ItemGroupOID="IG_VITALS“/>
</FormData>

121
© CDISC 2015
 ItemGroupData Element
ItemGroupData
attributes
Audit

Signature @ ItemGroupOID

Annotation @ ItemGroupRepeatKey

@ TransactionType
ItemData

<ItemGroupData ItemGroupOID="IG_VS">
+ <ItemData ItemOID="I_HEIGHT" Value="67">
+ <ItemData ItemOID="I_WEIGHT" Value="117">
<ItemData ItemOID="I_SYSBP" Value="110"/>
<ItemData ItemOID="I_DIABP" Value="80"/>
</ItemGroupData>
122
© CDISC 2015
 Item Data Element
ItemData attributes

Audit @ ItemOID

Signature @ TransactionType

MeasurementUnitRef @ Value

Annotation @ IsNull

attributes

@ MeasurementUnitOID

<ItemData ItemOID="I_HEIGHT" Value="67">

<MeasurementUnitRef MeasurementUnitOID=“mu.inch”/>
</ItemData>

124
© CDISC 2015
ItemData AuditRecord Element
attributes

@ ItemOID

@ TransactionType
AuditRecord attributes
@ Value
@ EditPoint
@ IsNull
UserRef
@ UsedImputationMethod
LocationRef

DateTimeStamp

ReasonForChange

SourceID

Signature

MeasurementUnitRef

Annotation

125
© CDISC 2015
 Signature Element
ItemData

AuditRecord
attributes

Signature @ ItemOID

@ TransactionType
UserRef
@ Value
LocationRef
@ IsNull
SignatureRef

DateTimeStamp

CryptoBindingManifest

MeasurementUnitRef

Annotation

126
© CDISC 2015
 Annotation Element
ItemData attributes

Audit @ ItemOID

Signature @ TransactionType

MeasurementUnitRef @ Value

Annotation @ IsNull
attributes

@ SeqNum
Comment
@ TransactionType
Flag
attributes
FlagValue
@ CodeListOID
FlagType attributes

@ CodeListOID
127
© CDISC 2015
 Audit, Signature & Annotation
<ItemData ItemOID="ID.DDT" Value="P03Y11M07DT16H">
<AuditRecord>
<UserRef UserOID = "USR.inv001"/>
<LocationRef LocationOID = "LOC.site001"/>
<DateTimeStamp>2002-02-04T14:11:32-05:00</DateTimeStamp>
<SourceID>46881304</SourceID>
</AuditRecord>
<Signature>
<UserRef UserOID="USR.inv001"></UserRef>
<LocationRef LocationOID="LOC.site001"></LocationRef>
<SignatureRef SignatureOID="SD.cdisc001-es"></SignatureRef>
<DateTimeStamp>2002-02-04T14:11:32-05:00</DateTimeStamp>
</Signature>
<Annotation SeqNum="001">
<Comment>This item had an audit, a signature
, &amp; an annotation.</Comment>
</Annotation>
</ItemData>

128
© CDISC 2015
Transaction Types
• Insert, Update, Remove
• Upsert – Insert if new, else Update
• Context – contextual information provided as part
of an incremental transfer to facilitate matching of
records

129
© CDISC 2015
 Data Transactions
<ClinicalData StudyOID="CES" MetaDataVersionOID="CES_MDV_V1">
<SubjectData SubjectKey="SUBJECT_11"
TransactionType="Insert">
<StudyEventData StudyEventOID="BASELINE">
<FormData FormOID="F_BASELINE">
<ItemGroupData ItemGroupOID="IG_COMMON">
<ItemData ItemOID="I_SITE" Value="2"/>
<ItemData ItemOID="I_SUBJECTID" Value="11"/>
<ItemData ItemOID="I_VISIT" Value="2005-05-23"/>
</ItemGroupData>
</FormData>
</StudyEventData>
</SubjectData>
<SubjectData SubjectKey="SUBJECT_11" TransactionType="Update">
<StudyEventData StudyEventOID="BASELINE">
<FormData FormOID="F_BASELINE">
<ItemGroupData ItemGroupOID="IG_COMMON">
<ItemData ItemOID="I_SITE" Value="3"/>
</ItemGroupData>
</FormData>
</StudyEventData>
</SubjectData>
</ClinicalData>
130
© CDISC 2015
Clinical Data Element Ordering
• Data Elements must occur in file with increasing
value of DateTimeStamps (newer records should
be added at the bottom)
• When entity is signed, signature applies to all data
transactions that appear above the signature in
the file.
• Programs can process the file ‘in order’ received

131
© CDISC 2015
 ItemData[TYPE] Element
ItemData[TYPE]

attributes

@ ItemOID

@ TransactionType
@ AuditRecordID
@ SignatureID

@ AnnotationID
@ MeasurementUnitOID

<ItemDataInteger ItemOID="I_HEIGHT">67</ItemDataInteger>

132
© CDISC 2015
 Audit
<ItemDataInteger ItemOID="I_HEIGHT" AuditRecordID="1"
MeasurementUnitOID="MU003">67<ItemDataInteger/>

<AuditRecords>
<AuditRecord ID="1">
<UserRef UserOID="USR.inv001"/>
<LocationRef LocationOID="LOC.site001"/>
<DateTimeStamp>2002-02-04T14:11:32-05:00</DateTimeStamp>
<SourceID>46881304</SourceID>
</AuditRecord>
</AuditRecords>

Signature and Annotations handled in exactly the same fashion

133
© CDISC 2015
Example
 Develop the ODM data for the
simple form shown below

Site Details

Site No.:___5___

Subject's Characteristics

Number:__12___

Sex: M [Y] F[]

Height: ___1560__ cm

Weight: ___87.2___ kg
134
© CDISC 2015
 Example
ClinicalData

SubjectData

StudyEvent

Site Details Form

Site No.:___5___
ItemGroup
Subject's Characteristics
Item
Number:__12___

Sex: M [Y] F[]

Height: ___1560__ cm

Weight: ___87.2___ kg

135
© CDISC 2015
 Example
ClinicalData

SubjectData

StudyEvent

Form

ItemGroup

Item

<ClinicalData StudyOID="CES" MetaDataVersionOID="CES_MDV_V1">

<!-- Something here -->
</ClinicalData>

136
© CDISC 2015
 Example
ClinicalData

SubjectData

StudyEvent

Form

ItemGroup

Item

<ClinicalData StudyOID="CES" MetaDataVersionOID="CES_MDV_V1">

<SubjectData SubjectKey="SUBJECT_12" TransactionType="Insert">
<!-- Something here -->
</SubjectData>
</ClinicalData>

137
© CDISC 2015
 Example
ClinicalData

SubjectData

StudyEvent

Form

ItemGroup

Item

<ClinicalData StudyOID="CES" MetaDataVersionOID="CES_MDV_V1">

<SubjectData SubjectKey="SUBJECT_12" TransactionType="Insert">
<StudyEventData StudyEventOID="BASELINE">
<!-- Something here -->
</StudyEventData>
</SubjectData>
</ClinicalData>

138
© CDISC 2015
 Example
ClinicalData

SubjectData

StudyEvent

Form

ItemGroup

Item
<ClinicalData StudyOID="CES" MetaDataVersionOID="CES_MDV_V1">
<SubjectData SubjectKey="SUBJECT_12" TransactionType="Insert">
<StudyEventData StudyEventOID="BASELINE">
<FormData FormOID="F_BASELINE">
<!-- Something here -->
</FormData>
</StudyEventData>
</SubjectData>
</ClinicalData>
139
© CDISC 2015
 Example ClinicalData

SubjectData

StudyEvent

Form

<ClinicalData StudyOID="CES" MetaDataVersionOID="CES_MDV_V1">

ItemGroup
<SubjectData SubjectKey="SUBJECT_12" TransactionType="Insert">
<StudyEventData StudyEventOID="BASELINE">
<FormData FormOID="F_BASELINE"> Item
<ItemGroupData ItemGroupOID="IG_COMMON">
<!-- Something here -->
</ItemGroupData>
<ItemGroupData ItemGroupOID="IG_PE">
<!-- Something here -->
</ItemGroupData>
</FormData>
</StudyEventData>
</SubjectData>
</ClinicalData>
140
© CDISC 2015
 Exercise
Site Details ClinicalData

Site No.:___5___ SubjectData

Subject's Characteristics StudyEvent

Number:__12___
Form
Sex: M [Y] F[]
ItemGroup
Height: ___1560__ cm
Item
Weight: ___87.2___ kg

<ItemGroupData ItemGroupOID="IG_COMMON">
<ItemData ItemOID="I_SITE" Value="5"/>
<ItemData ItemOID="I_SUBJECTID" Value="12"/>
<ItemData ItemOID="I_SEX" Value="M"/>
</ItemGroupData>
<ItemGroupData ItemGroupOID="IG_PE">
<ItemData ItemOID="I_HEIGHT" Value="1560"/>
<ItemData ItemOID="I_WEIGHT" Value="87.2"/>
</ItemGroupData>
141
© CDISC 2015
 The ODM

Operational
Data Model
Coffee Break

142
© CDISC 2015
 ReferenceData Element

ReferenceData
attributes

ItemGroupData @ StudyOID

@ MetaDataVersionOID

AuditRecords

Signatures

Annotations

143
© CDISC 2015
ODM: Administrative Data

ODM
XML

144
© CDISC 2015
 AdminData Element
AdminData

User attributes

@ StudyOID
Location

SignatureDef

<AdminData StudyOID="CES">
<User OID="USER_1" UserType="Investigator">
<!-- More elements -->
</User>
<Location OID="LOCATION_1" Name="Boston Medical Center">
<!-- More elements -->
</Location>
<SignatureDef OID="SIG_1" Methodology="Digital">
<!-- More elements -->
</SignatureDef>
</AdminData>
145
© CDISC 2015
 User Element
User attributes

@ OID
LoginName
Email
@ UserType
DisplayName

FullName Picture

FirstName Pager

LastName Fax

Organization
Phone
Address
LocationRef

Certificate

146
© CDISC 2015
 User Element
<User OID="USER_1" UserType="Investigator">
<FullName>Dr Fred Smith</FullName>
<FirstName>Fred</FirstName>
<LastName>Smith</LastName>
<Organization>Boston Medical Center</Organization>
<Address>
<StreetName>Freedom Walk</StreetName>
<City>Boston</City>
<StateProv>MA</StateProv>
<Country>USA</Country>
<PostalCode>12345</PostalCode>
</Address>
<LocationRef LocationOID="LOCATION_1"></LocationRef>
</User>

147
© CDISC 2015
 Location Element
Location attributes

@ OID
MetaDataVersionRef
@ Name

@ LocationType
attributes

StudyOID

MetaDataVersionOID

EffectiveDate

148
© CDISC 2015
 Location Element

<Location OID="LOCATION_1" Name="Boston Medical Center">

<MetaDataVersionRef StudyOID="CES"
MetaDataVersionOID="CES_MDV_V1"
EffectiveDate="2004-05-01“ />
</Location>

149
© CDISC 2015
 SignatureDef Element
SignatureDef

attributes
Meaning
@ OID
LegalReason
@ Methodology

<SignatureDef OID="SIG_2" Methodology="Digital">

<Meaning>Legal Signature</Meaning>
<LegalReason>Approval</LegalReason>
</SignatureDef>

150
© CDISC 2015
 Topics

Introduction to the ODM

Operational
Data Model Use Cases

Why XML?

The Model in Detail

Interchange Process

Other CDISC XML Standards

151
© CDISC 2015
Data Interchange Process
• Typical scenario
 Sponsor provides study
specifications to CRO
 Data management works with
EDC vendors to setup study
 At pre-specified time points study
data is provided for review &
quality management
 At pre-specified study milestone,
data is provided for interim
analysis
 At end of study, sponsor receives
final database
 Changes are made to study data
collection plan if needed to
improve data quality

153
© CDISC 2015
 Data Interchange Process
• Typical process flow

SPONSOR Specifications Data Provider

SPONSOR Data Provider

CollectedData

154
© CDISC 2015
Data Interchange Process
• ODM enabled metadata interchange
process

PDF

Specifications
Word
ODM XML

Exce
l

• ODM enabled data interchange

process

ASCII

ODM XML SAS

Transport
CollectedData

SAS
Datasets

155
Data Flow for ODM Interchange
EDC/CRO Sponsor

Specifications
Meta Meta
Data Data
StudySetup
MetaData

Timeline
Study
CRF
Data New and EDC/CRO Data
Data Changed Data

Coding

Lab Data

156
© CDISC 2015
 Sponsor’s Data Flow
Trial
z
Management
System
Clinical Trial
Protocol
z
ETL

z
EDC

Data/
Metadata
Documents
z
SAS

Protocol z
Lab Setup
IRB
Amendments

CSR SAP Metadata

Data

157
© CDISC 2015
 CRO/TPO Data Flow
Trial
z
Management
System
Clinical Trial
Protocol
z
ETL

z
EDC

Data/
Metadata
Documents
z
SAS

Protocol z
Lab Setup
IRB
Amendments

CSR SAP Metadata

Data

158
© CDISC 2015
 Interchange Options
attributes
ODM
@ Description

@ FileType

@ Granularity
Which data components need to
@ Archival
be exchanged? @ FileOID
Frequency of data downloads? @ CreationDateTime

@ PriorFileOID
Time points for metadata
@ AsOfDateTime
exchange?
@ ODMVersion
ODM Version? @ Originator

File naming conventions @ SourceSystem

@ SourceSystemVersion

@ ID
159
© CDISC 2015
 Interchange Options
attributes
ODM
@ Description

• Granularity @ FileType

 MetaData @ Granularity
 AdminData @ Archival
 ReferenceData @ FileOID
 AllClinicalData @ CreationDateTime
• Clinical data only @ PriorFileOID
 SingleSite @ AsOfDateTime
• Clinical data for an individual site
@ ODMVersion
 SinglePatient
@ Originator
• Clinical data for an individual
patient @ SourceSystem
 All @ SourceSystemVersion

@ ID
160
© CDISC 2015
 Interchange Options

attributes
ODM
@ Description

@ FileType
• FileType
@ Granularity
 Snapshot
@ Archival
 Transactional @ FileOID

@ CreationDateTime

@ PriorFileOID

@ AsOfDateTime

@ ODMVersion

@ Originator

@ SourceSystem

@ SourceSystemVersion

@ ID
161
© CDISC 2015
SnapShot Transfers
• Current state of study (or subset)
• May include fully qualified data elements
 ItemData
 MeasurementUnitRef
 Annotation
• TransactionType = "Insert" (implicit)
• No AuditRecords or Signatures
• ODM AsOfDate indicates date of SnapShot
• Any Granularity

162
© CDISC 2015
Transactional Transfers
• Fully attributed Clinical Data
 AuditRecord
 Signatures
• New and changed records included in each
interchange transmission

163
© CDISC 2015
Transactional Transfer
EDC/CRO Sponsor

Specifications
Meta Meta
Data Data
StudySetup
MetaData

Timeline
Study
CRF
Data New and EDC/CRO Data
Data Changed Data

Coding

Lab Data

164
© CDISC 2015
 File Linking for Transactional
Transfers
attributes
ODM @ Description

@ FileType
• Chaining of files uses FileOID and
@ Granularity
PriorFileOID
@ Archival
• FileOIDs are internal identifiers.
@ FileOID
Partners will need to establish file
naming conventions to be able to @ CreationDateTime

automate processing of linked @ PriorFileOID

files. @ AsOfDateTime

@ ODMVersion

@ Originator

@ SourceSystem

@ SourceSystemVersion

© CDISC 2015
@ ID 165
 ODM File Linking
<ODM FileType="Snapshot"
FileOID="004_010"
ODM File
CreationDateTime="2004-03-01T12:00:00.000+01:00">
…
</ODM>

<ODM FileType="Snapshot"
FileOID="004_020" ODM File
PriorFileOID="004_010"
CreationDateTime="2004-03-01T15:08:43.000+01:00">
…
</ODM>

166
© CDISC 2015
 Transactional FileType
attributes
@ Description
ODM
@ FileType

• Could be any Granularity @ Granularity

– usually AllClinicalData @ Archival
• A series of Transactional @ FileOID

@ CreationDateTime
Files ‘File Stream’ will be
@ PriorFileOID
linked by PriorFileOID
@ AsOfDateTime
• AsOfDate will increase with
@ ODMVersion
each incremental transfer @ Originator
• Archival attribute indicates @ SourceSystem

‘no overlapping dates’  no @ SourceSystemVersion

duplicate records in archive @ ID

167
© CDISC 2015
OIDs
• Link elements in different sections of the model
• Associate clinical data with metadata definitions
• Associate clinical data with audit/administrative
information
• Associate clinical data with reference data
• May be used to link elements in different files
• XML IDs/IDREFs must resolve within file

168
© CDISC 2015
 Best Practices for OIDs
• OIDs are similar to database keys – used to
connect elements in different parts of the
document

• OID values should/may be computer generated --

UUIDs

• Keep them simple

169
© CDISC 2015
 ODM OID Scoping

Study Series of files

User Series of files
Location Series of files
SignatureDef Series of files
MeasurementUnit Study
MetaDataVersion Study

StudyEventDef MetadataVersion
FormDef MetadataVersion
ItemGroupDef MetadataVersion
CodeList MetaDataVersion

Refer to ODM specification for complete information about

OID Scoping

170
 Link Study Data and MetaData
ODM

Study

attributes

@ OID

MetaDataVersion

attributes

@ OID

@ Name

@ Description
AdminData

ClinicalData
attributes
Association

ds:signature @ StudyOID

@ MetaDataVersionOID
171
© CDISC 2015
 MetaData Inheritence
MetaDataVersion

Include
attributes
Protocol
@ StudyOID
StudyEventDef
@ MetaDataVersionOID

FormDef

ItemGroupDef

ItemDef

CodeList

ImputationMethod

Presentation
172
© CDISC 2015
 Clinical Data Keys
attributes @ StudyOID

ClinicalData
@ SubjectKey
attributes

SubjectData
@ StudyEventOID
attributes @ StudyEventRepeatKey
StudyEventData

@ FormOID
attributes @ FormRepeatKey
FormData

@ ItemGroupOID
attributes
@ ItemGroupRepeatKey
ItemGroupData

@ ItemOID
attributes
ItemData 173
© CDISC 2015
 Clinical Data Keys
<ClinicalData StudyOID="CES" MetaDataVersionOID="CES_MDV_V1">
<SubjectData SubjectKey="SUBJECT_11"
TransactionType="Insert">
<StudyEventData StudyEventOID="BASELINE“
StudyEventRepeatKey="3">
<FormData FormOID="F_BASELINE">
<ItemGroupData ItemGroupOID="IG_COMMON">
<ItemData ItemOID="I_SITE" Value="2"/>
</ItemGroupData>
</FormData>
</StudyEventData>
</SubjectData>
</ClinicalData>

KEY
"CES" + "SUBJECT_11" + "BASELINE" + "3" + "F_BASELINE" + ? +
"IG_COMMON" + ? + "I_SITE"

174
© CDISC 2015
 KeySet Element
KeySet
attributes
@ StudyOID

@ SubjectKey

@ StudyEventOID

@ StudyEventRepeatKey

@ FormOID

@ FormRepeatKey

@ ItemGroupOID

@ ItemGroupRepeatKey

@ ItemOID
175
© CDISC 2015
 Association Element

Association
attributes
KeySet
@ StudyOID
KeySet
@ MetaDataVersionOID
Annotation

176
© CDISC 2015
 Best Practices for ODM Interchange
• Use vendors with ODM certification
• Agree on Transfer Type, transfer frequency, transfer validation.
• Specify and validate all ODM header attributes
 Need to specify ODMVersion for each transfer
• For Transactional transfers, agree on format of FileOID & PriorFileOID
and corresponding file naming conventions
• Agree on frequency of Administrative Data and Reference Data element
interchange
• Synchronize Metadata at beginning of clinical data collection
• Test clinical data transfer cycle early in data collection process

178
© CDISC 2015
 Best Practices Interchange Information
attributes
@ Description
ODM
@ FileType

@ Granularity
• FileOID
@ Archival
 Recommend establishing
naming convention @ FileOID
• ODMVersion @ CreationDateTime

 Version 1.1 is default @ PriorFileOID

• Optional attributes @ AsOfDateTime

• Originator @ ODMVersion

• SourceSystem @ Originator
• SourceSystemVersion @ SourceSystem
• ID @ SourceSystemVersion

@ ID 179
© CDISC 2015
Checklist for ODM Interchange
Projects
Develop requirements

Specify bi-directional data mappings

Document assumptions

Development and testing

180
© CDISC 2015
 Topics
Introduction to the ODM

Operational Use Cases

Data Model
Why XML?

The Model in Detail

Interchange Process

Other CDISC XML Standards &

Compliance
181
© CDISC 2015
ODM Compliance
• Like all of the CDISC XML Technology standards,
the ODM is considered to be compliant if it passes
XML schema validation AND conforms to the
ODM specification.
• The ODM specification document includes both
narrative and normative material.
 The normative material can be made visible in the html
specification document.
• Conformity rules are defined in the specification.

182
© CDISC 2015
XML Schema Validation
• Data completeness
 All required elements and attributes are present
 Example: For ItemDef OID, Name, DataType are
required
• Data structure
 Basic structure matches the schema
• Order of elements
• Position within hierarchy
• Data correctness
 XML Attribute data types
 XML Attribute enumerations
Provides basic level of correctness – but not ‘fit for
use’
Necessary but not sufficient!! 183
© CDISC 2015
Limitations of Schema Validation
• Checks compliance of a single document or file

 ODM, by necessity, requires multiple files or documents

for even small study

• No support for ‘business rules’

184
© CDISC 2015
 Conformance to the standard
1. A computing system that processes information in ODM format can claim conformance to this
standard only if it obeys the following rules.
2. Generated ODM files must satisfy all the correctness rules in this standard, both syntactic and
semantic.
3. A receiving system must be able to read any ODM file that satisfies all the correctness rules in
this standard, both syntactic and semantic.
4. ODM files must validate against the ODM schema for the ODM version indicated in the ODM
root element.
5. Information included in generated ODM files must be accurate according to the rules of this
standard as defined in this specification.
6. A receiving system must interpret information read from an ODM file accurately according to the
rules of this standard as defined in this specification.
7. Generated ODM files need not include information that is not normally handled or stored by the
generating system.
8. A receiving system may selectively ignore information read from an ODM file if that information
is not normally handled or stored by the receiving system.
9. A receiving system may constrain the range of data values, keys, names, and so on, that it is
capable of handling or storing.
10. Systems that receive ODM clinical data files but do not normally support one or more of the
datatypes specified in section 2.14, should accept clinical data of the unsupported types as text.
11. All system limitations (rules 6 through 9) must be documented.
12. If conformity is dependent on certain modes or settings, this must also be documented.

185
© CDISC 2015
 ODM Certification
• Formal process for assessing ODM compliance
for vendor system.
 Initiated in 2006.
 ~14 organizations have been certified for at least one
use case.
• Goal of the certification program is to encourage
ODM adoption by sponsors by ensuring that
vendors provide high quality ODM delivery
services.

http://www.cdisc.org/odm-certified-products

186
© CDISC 2015
ODM Extensions
• ODM was designed to support data interchange
and archive. Initial target was CDM and eDC
systems.
 80/20 approach

• Vendor extension mechanism was developed to

encourage vendor adoption of ODM by providing a
way to add specialized vendor specific
functionality.
 E.g. Validation rules, Form layouts, Instructions, …

187
© CDISC 2015
 Rules for Vendor Extensions
1. Vendors must provide a schema for their extensions.
2. Extended ODM files must reference the extension
schema.
3. Added elements and attributes must not render standard
ODM obsolete.
4. Extensions may not be used for content normally
expressed using ODM.
5. New attributes and elements must use a distinct XML
namespace.
6. Removing all vendor extensions must result in a
meaningful and accurate standard ODM.
7. Vendors should be able to produce ODM files without
extensions on request
188
© CDISC 2015
ODM Extensions
• Developed by CDISC:
 SDM-XML: Study Design
 Define-XML: Submissions Metadata
 Dataset-XML: Submissions Data
 Analysis Results Metadata: Metadata for analysis results
(in development)
 Controlled Terminology
 CDASH
• Most vendor products or sponsor developed
applications use extensions

189
© CDISC 2015
 ODM
Define-XML
SDM-XML CDASH-XML
Dataset-XML

Study
CDASH SEND SDTM ADaM
Design

190
© CDISC 2015
Study Design Model (SDM)
Extension
• ODM Extension to support interchange of study
design information

191
© CDISC 2015
Benefits of the SDM in XML
• SDM extension can be used to
 Represent information in the protocol document in a
computable form.
 Facilitate integration of study data for ISS, ISE.
 Facilitate combination of data across compounds.
 Provide information about clinical studies to healthcare
information systems.
• Step toward developing Protocol-XML
 Machine readable Protocol information is essential for
automating Health-care/Clinical Research integration

192
© CDISC 2015
 Extending ODM Protocol Element to
Support SDM
attributes
Protocol
@ StudyEventOID

StudyEventRef @ OrderNumber

Alias @ Mandatory

sdm:Summary

sdm:InclusionExclusionCriteria

sdm:Structure

sdm:Workflow

sdm:Timing

193
© CDISC 2015
Controlled Terminology Extension
• Extension of ODM CodeLIst elements to support
electronic distribution and management of CDISC
SDTM Controlled Terminology
• Available from NCI EVS ftp site for production CT
Versions

194
© CDISC 2015
 Extensions to Support Controlled
Terminology
attributes

attributes
CodeList
@CodedValue
@ OID
@nciodm:ExtCodeID
@ Name
EnumeratedItem
@ SASFormatName
nciodm:CDISCSynonym
@nciodm:ExtCodeID
nciodm:CDISCDefinition
@nciodm:CodeListExtensible
nciodm:PreferredTerm

attributes

CodeListItem @CodedValue

nciodm:CDISCSynonym @nciodm:ExtCodeID
nciodm:CDISCSubmissionValue
nciodm:CDISCDefinition
nciodm:CDISCSynonym
nciodm:PreferredTerm
nciodm:PreferredTerm
195
© CDISC 2015
SDTM Terminology.odm.xml

http://evs.nci.nih.gov/ftp1/CDISC/SDTM/

196
© CDISC 2015
 197
© CDISC 2015
Benefits of controlled terminology
XML
• CDISC Controlled Terminology is maintained in
the National Cancer Institute’s Enterprise
Vocabulary System (NCI EVS).
+ Centrally managed
+ Benefits from NCI tools for managing vocabulary
development process
- Difficult to access from programs
• CDISC Terminology releases are now provided
both in XLS and XML formats
 XLS supports individual browsing using desktop tools
 XML can be loaded into a database or used directly from
programs used to check data conformity.

198
© CDISC 2015
CDASH in XML
• CDASH forms are an important component of a
CDISC end-to-end solution

199
© CDISC 2015
Benefits of ODM Based CDASH
Form Library
• Easy access, easy to integrate
• Unambiguous source
• Easy to browse, copy and extend

200
© CDISC 2015
 Topics
Introduction to the ODM

Operational Use Cases

Data Model
Why XML?

The Model in Detail

Interchange Process

Other CDISC XML Standards &

Compliance
201
© CDISC 2015
Wrap Up

202
© CDISC 2015
Thank You!

203
© CDISC 2015
Thank you for attending.
Please complete the feedback survey that will be
sent to your inbox within the next couple of days.
PDF certificates of attendance will shortly follow.

Learn CDISC from CDISC!

Authoritative. Global. Vendor-neutral.
training@cdisc.org

© CDISC 2013
2015
CDISC Membership Benefits
• Gold Membership
 Access to Member’s Only area of website
 Access to Members Only Webinars
 20% off all CDISC-hosted conferences and education
events
 Opportunity to obtain CDISC ODM Certification
 Opportunity to obtain CDISC Registered Solution
Provider
 Opportunity to participate in CDISC licensed course
program
 Personalized company plaque

© CDISC 2015
Membership Benefits Cont’d
• Platinum Membership
 All Gold Membership benefits
 40% (already includes 20% discount for Gold
Membership) discount on CDISC-hosted events and
Education courses
 Representation on CDISC Advisory Council
• Networking opportunities with clients, visionaries, and other peers
• Opportunity for Board Committee Representation (Financial,
Strategy, Technical)
• Voting privileges for Board of Directors
• Participation in town hall meetings with regulators and CDISC
Board Members
• Free one-time access to F2F training of Global Approach to
Accelerating Medical Research course

© CDISC 2015
Contact Information and Helpful Links
• For membership inquiries, please contact
membership@cdisc.org
• For education inquiries, please contact
training@cdisc.org
• For general CDISC inquiries, please contact
info@cdisc.org

• Click here for more info on CDISC Education

• Click here for more info on CDISC Membership

© CDISC 2015 207

 208
© CDISC 2015
Extra slides

209
© CDISC 2015
ODM Document Conformity
Compliant with normative content in ODM
specification

&
Validates to ODM Schema

212
© CDISC 2015
 http://en.wikipedia.org/wiki/XML_namespace

XML Namespaces

213
© CDISC 2015
 Define.XML schema(s)

• Define-ns.xsd – declares namespace (def) and

defines extended elements

• Define-extension.xsd – extends ODM attributes

and elements using xs:redefine

• Define1-0-0.xsd – assembles extended and

redefined ODM elements

Note: Schema architecture is design to allow co-existence of multiple

extensions.

214
© CDISC 2015
CDISC XML Standard for Representation of
SDTM and ADaM Dataset Metadata

© CDISC 2015
Origin/Source

• Can be used at variable

or value level
• Content can be adapted
for either SDTM or ADaM
• When Origin is a CRF
page references link to
AnnotatedCRF.

© CDISC 2015
 aCRF Links

<def:Origin Type="CRF">
<def:DocumentRef leafID="LF.blankcrf">
<def:PDFPageRef PageRefs="3 6" Type="PhysicalRef"/>
</def:DocumentRef>
</def:Origin>

© CDISC 2015
Schema Documentation

© CDISC 2015