Specification for the Operational Data Model (ODM)

The Operational Data Model (ODM) is a vendor neutral, platform independent format for interchange and archive of clinical trials data. The model includes the clinical data along with its associated metadata, administrative data, reference data and audit information. All of the information that needs to be shared among different software systems during the setup, operation, analysis, submission or for long term retention as part of an archive is included in the model.

This document contains the specification for the CDISC ODM standard. Most of the text in this standard expresses requirements on systems that read or write ODM files. Some, however, is commentary, usage notes or examples. All such "unofficial" text is segregated into paragraphs or sections prominently marked as non-normative, a note, or an example.

An XML file conforms to this standard only if it satisfies all the criteria detailed in this standard. These criteria include both syntactic constraints and semantic ones.

The syntactic constraints are

This specification includes normative statements and commentary. You can view a copy of this specification with the normative content highlighted by removing the comment tags surrounding the ODM 1.3 normative content style definition near the top of the file.

Example of prolog and top level ODM element:

<?xml version="1.0" encoding="ISO-8859-1"?>
<ODM xmlns="http://www.cdisc.org/ns/odm/v1.3"
     xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 
    xsi:schemaLocation="http://www.cdisc.org/ns/odm/v1.3 ODM1-3-0.xsd"
 
    ODMVersion="1.3"
    FileOID="000-00-0000"
    FileType="Transactional"
    Description="Sample ItemData Extension"
 
    AsOfDateTime="2005-04-04T07:57:00"
    CreationDateTime="2005-04-06T10:30:00">

The semantic constraints are expressed throughout the rest of this document.

The ODM version XML Schema file can be used with a validating XML parser to test that an ODM file is syntactically valid. To ensure semantic correctness the use of an ODM Validation application is recommended.

[Commentary] The value of the ODM standard, like any information standard, is enhanced when systems can be developed with the assumption that ODM files have a high level of conformity. However, the ODM also provides value in that it provides both a standard and a technology for the interchange of clinical data were none has existed in the past. The conformity statements below represent an attempt at balancing the need for quality control with respect to the standard with the need for flexility when encouraging adoption and innovation:

A computing system that processes information in ODM format can claim conformance to this standard only if it obeys the following rules.

1. Generated ODM files must satisfy all the correctness rules in this standard, both syntactic and semantic.
2. A receiving system must be able to read any ODM file that satisfies all the correctness rules in this standard, both syntactic and semantic.
3. ODM files must validate against the ODM schema for the ODM version indicated in the ODM root element.
4. Information included in generated ODM files must be accurate according to the rules of this standard as defined in this specification.
5. A receiving system must interpret information read from an ODM file accurately according to the rules of this standard as defined in this specification.
6. Generated ODM files need not include information that is not normally handled or stored by the generating system.
7. 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.
8. A receiving system may constrain the range of data values, keys, names, and so on, that it is capable of handling or storing.
9. 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.
10. All system limitations (rules 6 through 9) must be documented.
11. If conformity is dependent on certain modes or settings, this must also be documented.

The ODM has been designed to provide a standard format for interchange and archive of clinical trials data and metadata. Although the model has proven to be usable with a wide variety of clinical data applications, it is sometimes the case that individual clinical data systems store information that cannot be expressed conveniently in the ODM model. To encourage these systems to adopt the use of the ODM standard for interchange and archive and to improve interoperability of clinical research applications, the use of the ODM Vendor extensions is recommended.

Requirements for Vendor extensions to the ODM model are:

An ODM document (file) can be viewed as a set of instructions telling how to modify a target database so that it can be brought into alignment with a source database. A single ODM document could contain all the information about the source database -- all the subjects, all the metadata, all the clinical data, and all the changes to each item of clinical data. However, it's not always convenient to create such a large document. So we allow a series of ODM files to incrementally provide this information.

An ODM document's Granularity is intended to give the sender a shorthand way to describe the breadth of the information in the document, for certain common types of documents. Here are the intended meanings of these categories:

	Category	Document contains
	All	Any and all types of data and metadata
	Metadata	Metadata only
	AdminData	Admin data only
	ReferenceData	Reference data only
	AllClinicalData	Clinical data only
	SingleSite	Clinical data for a single site only
	SingleSubject	Clinical data for a single subject only

If these shorthand categories are not sufficient, use the document's Description attribute to give details.

Archival

The Archival attribute is optional.

Archival=Yes states that this file (or collection of files) is intended to meet the requirements of an electronic record as defined in 21 CFR 11. More specifically, the file (or set of files) must clearly establish a complete and non-redundant set of insertions, updates, and deletions of data values with full auditing and signature information (if available).

Archival=Yes requires

Each data element has an optional TransactionType attribute. This attribute can be one of Insert, Update, Remove, or Upsert.

A TransactionType of Insert means that the data entity is new (does not currently exist in the study) and must be added to the study data along with all the properties provided. It is an error if the data entity already exists, or if the data entity's parent does not exist.

A TransactionType of Update means that the data entity already exists and must be modified to have the new properties provided. Properties not mentioned are not modified. It is an error if the data entity does not exist.

A TransactionType of Remove means that the data entity already exists and must be deleted along with all its properties and children. It is an error if the data entity does not exist.

Note: The use of the word "delete" above does not imply that all record of the data entity is expunged, just that the next transaction on that entity (if any) must be an Insert rather than Update or Remove.

A TransactionType of Upsert is the same as Update if the data entity exists, and the same as Insert otherwise.

Note: Upsert allows the sender to ignore whether the data entity exists or not. (A capability that may be needed by certain data collection systems.) This capability is potentially dangerous and may be removed in future versions of this standard.

A TransactionType of Context means that the data is explicitly being resent for context purposes only. An example of this would be sending an ItemGroup containing demographic data every time (with a TransactionType of Context) to permit matching and checking of Patient IDs between the sender and receiver systems.

A child element that does not specify its own TransactionType inherits the TransactionType of its parent. The TransactionType of a top level data element must be explicit.

Transaction processing proceeds in the order in which data elements appear in the ODM document. If two transactions for an entity are included in an ODM document, they are applied in the order in which they appear.

If an entity has a TransactionType of Remove, the only TransactionType its descendants can have is Remove (they can also have no TransactionType, and thus inherit the Remove type). A program that processes ODM files should look ahead far enough to determine if an element breaks this rule before processing the element.

If a Snapshot document includes a TransactionType, only TransactionType=Insert is permitted.

The elements in an ODM file that apply to a single entity must occur in temporal order. That is, the transactions on each entity are applied in the order in which that entity's elements occur in the file, and Signatures and AuditRecords must occur in increasing value of their DateTimeStamps.

In general, the elements for distinct entities do not have to be ordered relative to one another. However, when an entity is signed, all transactions on that entity that occurred before the time of the signature must be present earlier in the same ODM file or in a prior ODM file in a linked series.

All the DateTimeStamps in a file must precede the CreationDateTime of that file.

In a linked series of ODM files, the AsOfDateTimes of those files must occur in temporal order, and the DateTimeStamps in each file must be later than the AsOfDateTimes of the prior file.

A data entity (like a form) can be represented as a series of data elements. These elements can contain data for disjoint parts of the entity (properties and children), sequential changes to the same parts, or a mixture of the two.

In a study, the initial or default value of any clinical data is assumed to be NULL. Thus it is not necessary to include NULL valued items in a Snapshot transfer. Neither is it necessary to include a NULL value as the first in a series of insertions and updates of an item.

Systems that generate ODM files should attempt to minimize the number of elements in such files. Thus, if two elements for the same entity can be merged into one without changing the semantics of the events described (and without violating any of the ordering rules), the merged version is recommended. Similarly, unnecessary elements should be omitted.

In the ODM, there are many instances where one element needs to reference another -- both within the same file and across files within a series of ODM documents. To accomplish this, the target element is given a unique "name" (its OID). All elements that need to reference that target element just use its OID.

Example: Say we have an item definition (ItemDef) called "Systolic Blood Pressure". We set the OID attribute of this ItemDef to "SBP". Then any specific instance of that data item (ItemData) can link back to the definition by setting its own ItemOID attribute to "SBP".

The OIDs used have to be unique, but only within certain contexts. The uniqueness rules are:

• The OID for a Study, User, Location, or SignatureDef must be unique within a related series of ODM documents.
• The OID for a MeasurementUnit, MetaDataVersion, StudyEventDef, FormDef, ItemGroupDef, ItemDef, CodeList, Presentation, ConditionDef, and MethodDef must be unique within a single study (within a related series of ODM documents). It is permitted to reuse OIDs for these elements in different studies.
• The OID for an ArchiveLayout must be unique within a single form definition (within a study). It is permitted to reuse OIDs for this element in different form definitions.

The syntax of each XML element is specified as follows:

Element-Name Body: content-specification Attributes: attribute-name data-format optionality semantic-details ...

The content specification can be "EMPTY", a data format name, or an element group. EMPTY means that this element has no body (nested content). A data format name means that the body can be any text string matching the named format. An element group means that the named elements can be directly nested within this element.

An element group consists of one or more element names (or element groups) enclosed in parentheses, and separated with commas or vertical bars. Commas indicate that the elements (or element groups) must occur in the XML sequentially in the order listed in the group. Vertical bars indicate that exactly one of the elements (or element groups) must occur. An element or element group can be followed by a ? (meaning optional), a * (meaning zero or more occurrences), or a + (meaning one or more occurrences).

All XML attribute values and some element bodies are text strings. These strings are defined by data format. Each data format specifies the allowable form of the string, the corresponding XML Schema datatype, and the intended use of the value. The set of ODM data formats follows:

	Format Name	Schema Datatype	Allowed String Pattern
	integer	xs:integer	-?digit+
	float	xs:decimal	-?digit+(.digit+)?
	date	xs:date	YYYY-MM-DD
	time	xs:time	hh:mm:ss(.n+)? ((+|-)hh:mm)?
	datetime	xs:dateTime	YYYY-MM-DD T hh:mm:ss(.n+)? ((+|-)hh:mm)?
	text	xs:string	any sequence of characters
	oid	xs:string	any sequence of characters
	oidref	xs:string	any sequence of characters
	subjectKey	xs:string	any sequence of characters
	repeatKey	xs:string	any sequence of characters
	name	xs:string	any sequence of characters
	sasName	xs:string	( letter | _ )( letter | digit | _ )*
	sasFormat	xs:string	( letter | _ | $ )( letter | digit | _ | . )*
	fileName	xs:string	( letter | digit | _ | . )+
	languageTag	xs:language	LL (-CC)* (see below)

	string	xs:string	Semantically equivalent to text but directly supported as XML schema datatype
	boolean	xs:boolean	(true | false | 1 | 0)
	double	xs:string	(((\+|-)?[0-9]+(\.[0-9]+)?((D|d|E|e)(\+|-)[0-9]+)?)|(-?INF)|(NaN))
	hexBinary	xs:hexBinary	hex-encoded binary stream data
	base64Binary	xs:base64Binary	binary stream encoded using Base64 Alphabet
	hexFloat	xs:hexBinary	up to 16 characters
	base64Float	xs:base64Float	up to 12 characters
	partialDate	xs:date	YYYY[-MM[-DD ]]
	partialTime	xs:time	hh[:mm[:ss(.n+)? ((+|-)hh:mm)?]]
	PartialDatetime	xs:dateTime	YYYY[-MM[-DD ]]T hh[:mm[:ss(.n+)? ((+|-)hh:mm)?]]
	intervalDatetime	xs:string	partialDatetime/partialDatetime)|(durationDatetime/partialDatetime)|(partialDatetime/durationDatetime)
	durationDatetime	xs:duration	(((+|-)?P((((n(n+)?)Y)?((nn+)?)M)?((nn+)?)D)?)(T(((n(n+)?)H)?((n(n+)?)M)?((n(n+)?)((\.n+)?)S)?)?)?|(((n(n+)?)W))))
	incompleteDatetime	xs:string	[YYYY|-]-[MM |-]-[DD|-]]]T[hh|-]:[mm|-]:[ss.s|-][?(+|-)nn:nn|Z]
	URI	xs:anyURI

Numbers (integer and float) are represented in base 10. Floats are allowed to have fractional parts.

Note: Certain integer attributes (KeySequence, OrderNumber, and SeqNum) are used to define an order among related entities. For these attributes, we recommend using consecutive integer values starting at 1.

A text value is any character or sequence of characters valid within the XML document encoding. When embedded in ODM files, text strings must be represented applying the standard XML quoting and character escaping rules.

Dates are represented in the Gregorian calendar. The year (YYYY) ranges from 0001 to 9999. The month (MM) ranges from 01 to 12. The day (DD) ranges from 01 to 31. ODM dates are a slightly restricted form of the XML Schema datatype date: no timezone specification is allowed.

Times are clock readings within a 24 hour period. The hour (hh) ranges from 00 to 23. The minutes (mm) and the seconds (ss) range from 00 to 59. The optional fractional part (.nnn) expresses fractional seconds. ODM times are a slightly restricted form of the XML Schema datatype time: only the ±hh:mm form of timezone is allowed.

Datetimes combine a date, a time and (optionally) a timezone. ODM datetimes are a slightly restricted form of the XML Schema datatype dateTime: only the ±hh:mm form of timezone is allowed.

Dates, times, and datetimes are to be interpreted as local clock readings at the place the data was collected. In a datetime, the ±hh:mm is the offset in hours and minutes to add to (or subtract from) Universal Time to get the local clock reading at the time the data was collected. A missing timezone specification means that the relationship between the local clock and Universal Time is not known.

Example: 3:14 pm on 3 January 2001 in Chicago (6 timezones west of Greenwich, standard time) would be represented as "2001-01-03T15:14:00-06:00". 3.5 seconds after midnight on the morning of July 20th 2001 in Chicago (daylight time) would be represented as "2001-07-20T00:00:03.500-05:00".

Starting in ODM 1.3.0, there are two forms of the ItemData element -- the element used by the ODM for transmitting clinical data item values. These are the untyped and typed forms. The ItemData element, present in all previous ODM versions, is the form used for untyped data transmissions. The ItemData[TYPE] elements are the form used for typed data transmission.

The ODM schema for Version 1.3 includes the following ItemDataTYPE elements:

	ItemDataAny
	ItemDataString
	ItemDataInteger
	ItemDataFloat
	ItemDataDate
	ItemDataTime
	ItemDataDatetime
	ItemDataBoolean
	ItemDataDouble
	ItemDataHexBinary
	ItemDataBase64Binary
	ItemDataHexFloat
	ItemDataBase64Float
	ItemDataPartialDate
	ItemDataPartialTime
	ItemDataPartialDatetime
	ItemDataDurationDatetime
	ItemDataIntervalDatetime
	ItemDataIncompleteDatetime
	ItemDataURI

All typed data value elements carry their data value as the element's PCDATA content.. For example, an ItemDataInteger element would appear as:

  <ItemDataInteger ItemOID="ID.114">100</ItemDataInteger>

[Commentary] Systems that generate or receive ODM files are encouraged to provide typed data transmission.

Systems that receive ODM clinical data files but do not normally support one or more of the datatypes listed in this section should accept clinical data of the unsupported types as text. In cases where these systems transmit clinical data by generating a new ODM file with the unsupported type, the generated file should include the original datatype information.

For example, if a system that does not normally support HexBinary or HexFloat datatypes receives an ODM XML file containing data for an Item defined as having datatype 'HexFloat', the clinical data for the Item may be stored as TEXT. If that system generates an ODM file that includes data for that item, the ItemDef must still define the datatype as HexFloat.

Body:

(Study*, AdminData*, ReferenceData*, ClinicalData*, Association*, ds:Signature*)

Attributes:

	Description	text	(optional)	The sender should use the Description attribute to record any information that will help the receiver interpret the document correctly.
	FileType	( Snapshot | Transactional )		Snapshot means that the document contains only the current state of the data and metadata it describes, and no transactional history. A Snapshot document may include only one instruction per data point. For clinical data, TransactionType in a Snapshot file must be Insert. Transactional means that the document may contain more than one instruction per data point. Use a Transactional document to send both what the current state of the data is, and how it came to be there.
	Granularity	( All | Metadata | AdminData | ReferenceData | AllClinicalData | SingleSite | SingleSubject )	(optional)	Granularity is intended to give the sender a shorthand way to describe the breadth of the information in the document, for certain common types of documents. All means the entire study; Metadata means the MetaDataVersion element; AdminData and ReferenceData mean the corresponding elements; AllClinicalData, SingleSite, and SingleSubject are successively more tightly focused subset of the study's clinical data. If these shorthand categories are not sufficient, use the Description attribute to give details.
	Archival	(Yes | No)	(optional)	Set this attribute to Yes to indicate that the file is intended to meet the requirements of an electronic record as defined in 21 CFR 11. See Single Files and Collections for an fuller discussion of the meaning of this attribute, as well as its interaction with other ODM attributes. Use this attribute only when FileType is Transactional.
	FileOID	oid		A unique identifier for this file.
	CreationDateTime	datetime		Time of creation of the file containing the document.
	PriorFileOID	oidref	(optional)	Reference to the previous file (if any) in a series.
	AsOfDateTime	datetime	(optional)	The date/time at which the source database was queried in order to create this document.
	ODMVersion	text	(optional)	The version of the ODM standard used.
	Originator	text	(optional)	The organization that generated the ODM file.
	SourceSystem	text	(optional)	The computer system or database management system that is the source of the information in this file.
	SourceSystemVersion	text	(optional)	The version of the "SourceSystem" above.
	ID	ID	(optional)	May be used by the ds:Signature element to refer back to this element.

The AsOfDateTime is the latest date/time of any new data or updates to data included in the current file. This attribute is implied, and if omitted, it is assumed that the AsOfDateTime is equal to the CreationDateTime. It is an error to supply an AsOfDateTime that is later than the CreationDateTime.

The ODMVersion attribute was not defined in ODM 1.1, so a missing ODMVersion should be interpreted as "1.1". Documents based on ODM 1.3 should have ODMVersion="1.3".

Body:

(GlobalVariables, BasicDefinitions?, MetaDataVersion*)

Attributes:

OID

oid

Contained in:

ODM

This element collects static structural information about an individual study.

Body:

(StudyName, StudyDescription, ProtocolName)

Attributes:

NONE

Contained in:

Study

GlobalVariables includes general summary information about the Study.

Body:

name

Attributes:

NONE

Contained in:

GlobalVariables

This is a short external name for the study.

Body:

text

Attributes:

NONE

Contained in:

GlobalVariables

This is a free-text description of the study.

Body:

name

Attributes:

NONE

Contained in:

GlobalVariables

This is the sponsor's internal name for the protocol.

Body:

(MeasurementUnit*)

Attributes:

NONE

Contained in:

Study

Body:

(Symbol)

Attributes:

	OID	oid
	Name	text

Contained in:

BasicDefinitions

The physical unit of measure for a data item or value. The meaning of a MeasurementUnit is determined by its Name attribute. Examples include kilograms, centimeters, cells/milliliter, etc.

Note: Standardizing the names of measurement units is beyond the scope of the ODM.

Body:

(TranslatedText+)

Attributes:

NONE

Contained in:

MeasurementUnit

A human-readable name for a measurement unit.

Body:

text

Attributes:

xml:lang

languageTag

(optional)

Contained in:

Decode, ErrorMessage, Question, Symbol, Description

Human-readable text that is appropriate for a particular language. TranslatedText elements typically occur in a series, presenting a set of alternative textual renditions for different languages.

To find the text appropriate for a target language with tag LT, search for a TranslatedText element whose xml:lang attribute matches LT exactly (ignoring case). If that fails, remove the ending subtag from LT and repeat. A TranslatedText without an xml:lang attribute should be used if no other element is a better match.

To avoid ambiguity, a particular language tag should not occur more than once in a series of TranslatedText elements.

Note: The xml:lang attribute is part of the XML standard.

The way metadata versioning works is as follows. An individual Study element may contain multiple MetaDataVersions, reflecting one or more mid-stream study design changes. The initial version contains a full set of metadata. Each subsequent version typically contains only modified or newly added metadata elements, inheriting the previous metadata by an explicit reference. The same metadata elements in different versions will have the same OID. This approach is used to allow the older versions of the metadata to remain intact, while simultaneously providing a concise way to represent changes.

Body:

(Include?, Protocol?, StudyEventDef*, FormDef*, ItemGroupDef*, ItemDef*, CodeList*, ImputationMethod*Deprecated, Presentation*, ConditionDef*, MethodDef*)

Attributes:

	OID	oid
	Name	name
	Description	text	(optional)

Contained in:

Study

A metadata version defines the types of study events, forms, item groups, and items that form the study data.

The Include element references a prior metadata version. This causes all the definitions in that prior metadata version to be automatically included in this one. Any of the included definitions can be replaced (overridden) by explicitly giving a new version of the definition (with the same OID) in the new metadata version. New definitions (with new OIDs) can be added in the same way.

Note: The current metadata model does not include any scheduling information such as the time ordering of events, the spacing of events, conditional occurrence of events, and so on. The analogous information for forms is also not included. Future versions of this standard will probably provide such information.

Body:

EMPTY

Attributes:

	StudyOID	oidref		References the Study that provides a prior metadata version.
	MetaDataVersionOID	oidref		References the prior MetaDataVersion (within the above Study).

Contained in:

MetaDataVersion

Body:

(Description?, StudyEventRef+)

Attributes:

none

Contained in:

MetaDataVersion

The Protocol lists the kinds of study events that can occur within a specific version of a Study. All clinical data must occur within one of these study events.

Note: A study whose metadata does not contain a protocol definition cannot have any clinical data. Such studies can serve as "common metadata dictionaries" -- allowing sharing of metadata across studies.

Body:

(TranslatedText+)

Attributes:

NONE

Contained in:

StudyEventDef, FormDef, ItemGroupDef, ItemDef, ConditionDef, MethodDef

A free-text description of the containing study metadata component.

Body:

EMPTY

Attributes:

	StudyEventOID	oidref		Reference to the StudyEventDef.
	OrderNumber	integer	(optional)
	Mandatory	(Yes | No)
	CollectionExceptionConditionOID	oidref	(optional)	Reference to a ConditionDef

Contained in:

Protocol

A reference to a StudyEventDef as it occurs within a specific version of a Study. The list of StudyEventRefs identifies the types of study events that are allowed to occur within the study. The StudyEventRefs within a single MetaDataVersion must not have duplicate StudyEventOIDs nor duplicate OrderNumbers.

The OrderNumbers provide an ordering on the StudyEventDefs for use whenever a list of StudyEventDefs is presented to a user. They do not imply anything about event scheduling, time ordering, or data correctness.

The Mandatory flag indicates that the clinical data for the containing study would be incomplete without an instance of this type of study event. ODM clinical data files that are incomplete in this sense may be considered incomplete for study review and analysis purposes.

If the CollectionExceptionConditionOID attribute is provided, it references a ConditionDef that describes the circumstances under which data for this StudyEvent should not be collected.

Body:

(Description?, FormRef+)

Attributes:

	OID	oid
	Name	name
	Repeating	(Yes | No)
	Type	(Scheduled | Unscheduled | Common)
	Category	text	(optional)

Contained in:

MetaDataVersion

A StudyEventDef packages a set of forms. Scheduled Study Events correspond to sets of forms that are expected to be collected for each subject as part of the planned visit sequence for the study. Unscheduled Study Events are designed to collect data that may or may not occur for any particular subject such as a set of forms that are completed for an early termination due to a serious adverse event. A common Study Event is a collection of forms that are used at several different data collection events such as an Adverse Event or Concomitant Medications log.

The Repeating flag indicates that this type of study event can occur repeatedly within the containing study.

The Category attribute is typically used to indicate the study phase appropriate to this type of study event. Examples might include Screening, PreTreatment, Treatment, and FollowUp.

Body:

EMPTY

Attributes:

	FormOID	oidref		Reference to the FormDef.
	OrderNumber	integer	(optional)
	Mandatory	(Yes | No)
	CollectionExceptionConditionOID	oidref	(optional)	Reference to a ConditionDef

Contained in:

StudyEventDef

A reference to a FormDef as it occurs within a specific StudyEventDef. The list of FormRefs identifies the types of forms that are allowed to occur within this type of study event. The FormRefs within a single StudyEventDef must not have duplicate FormOIDs nor OrderNumbers.

The OrderNumbers provide an ordering on the FormDefs (within the containing StudyEventDef) for use whenever a list of FormDefs is presented to a user. They do not imply anything about event scheduling, time ordering, or data correctness.

The Mandatory flag indicates that the clinical data for an instance of the containing study event would be incomplete without an instance of this type of form. ODM files that are incomplete in this sense are perfectly legal -- just not sufficient for clinical analysis.

The Mandatory flag indicates that the clinical data for an instance of the containing study event would be incomplete without an instance of this type of form. ODM clinical data files that are incomplete in this sense may be considered incomplete for study review and analysis purposes.

If the CollectionExceptionConditionOID attribute is provided, it references a ConditionDef that describes the circumstances under which data for this Form should not be collected.

Body:

(Description?, ItemGroupRef+, ArchiveLayout*)

Attributes:

	OID	oid
	Name	name
	Repeating	(Yes | No)

Contained in:

MetaDataVersion

A FormDef describes a type of form that can occur in a study.

The Repeating flag indicates that this type of form can occur repeatedly within the containing study event.

Body:

EMPTY

Attributes:

	ItemGroupOID	oidref		Reference to the ItemGroupDef.
	OrderNumber	integer	(optional)
	Mandatory	(Yes | No)
	CollectionExceptionConditionOID	oidref	(optional)	Reference to a ConditionDef

Contained in:

FormDef

A reference to an ItemGroupDef as it occurs within a specific FormDef. The list of ItemGroupRefs identifies the types of item groups that are allowed to occur within this type of form. The ItemGroupRefs within a single FormDef must not have duplicate ItemGroupOIDs nor OrderNumbers.

The OrderNumbers provide an ordering on the ItemGroupDefs (within the containing FormDef) for use whenever a list of ItemGroupDefs is presented to a user. They do not imply anything about event scheduling, time ordering, or data correctness.

The Mandatory flag indicates that the clinical data for an instance of the containing form would be incomplete without an instance of this type of item group. ODM clinical data files that are incomplete in this sense may be considered incomplete for study review and analysis purposes.

If the CollectionExceptionConditionOID attribute is provided, it references a ConditionDef that describes the circumstances under which data for this ItemGroup should not be collected.

Body:

(Description?, ItemRef+, Alias*)

Attributes:

	OID	oid
	Name	name
	Repeating	(Yes | No)
	IsReferenceData	(Yes | No)	(optional)
	SASDatasetName	sasName	(optional)
	Domain	text	(optional)
	Origin	text	(optional)
	Role	name	(optional)	Deprecated
	Purpose	text	(optional)
	Comment	text	(optional)

Contained in:

MetaDataVersion

An ItemGroupDef describes a type of item group that can occur within a study.

The Repeating flag indicates that this type of item group can occur repeatedly within the containing form (or reference data).

If IsReferenceData is Yes, this type of item group can occur only within a ReferenceData element. If IsReferenceData is No, this type of item group can occur only within a ClinicalData element. The default for this attribute is No.

Body:

EMPTY

Attributes:

	ItemOID	oidref		Reference to the ItemDef.
	OrderNumber	integer	(optional)
	Mandatory	(Yes | No)
	KeySequence	integer	(optional)
	ImputationMethodOID	Deprecated
	MethodOID	oidref	(optional)
	Role	NMTOKENS	(optional)
	RoleCodeListOID	oidref	(optional)
	CollectionExceptionConditionOID	oidref	(optional)	Reference to a ConditionDef

Contained in:

ItemGroupDef

A reference to an ItemDef as it occurs within a specific ItemGroupDef. The list of ItemRefs identifies the types of items that are allowed to occur within this type of item group. The ItemRefs within a single ItemGroupDef must not have duplicate ItemOIDs nor OrderNumbers.

The OrderNumbers provide an ordering on the ItemDefs (within the containing ItemGroupDef) for use whenever a list of ItemDefs is presented to a user. They do not imply anything about event scheduling, time ordering, or data correctness.

The Mandatory flag indicates that the clinical data for an instance of the containing item group would be incomplete without an instance of this type of item. ODM clinical data files that are incomplete in this sense may be considered incomplete for study review and analysis purposes.

The KeySequence (if present) indicates that this item is a key for the enclosing item group. It also provides an ordering for the keys.

The MethodOID references a MethodDef used to derive the value of this item.

The Role attribute provides a set of role names describing the use of this data item. If the Item serves more than one role with the containing ItemGroupDef, more than one Role can be listed. (NMTOKENS is a list of XML names separated by spaces.)

If the set of Roles is defined by a standard terminology, the RoleCodeListOID may be used to reference a CodeList that defines the full set roles from which the Role attribute values are to be taken as a set of EnumeratedItem elements. This attribute should not be present unless the Role attribute is defined. If Role is defined, RoleCodeListOID is still optional.

If the CollectionExceptionConditionOID is provided, it references a ConditionDef that defines the circumstances under which collection of the Item can be omitted i.e. when the FormalExpression evaluates to True. For example, an data collection instrument designed to collect data for an item 'IsPregnant' for an item group 'InclusionCriteria' may be omitted for male subjects. The referenced ConditionDef would be defined as illustrated below. When the FormalExpression evaluates to True, the Item with OID IG.ISPREG will not be collected.

<ItemGroup OID="INCLUSION" Name="Inclusion Criteria" >
		   ...
		   <ItemRef OID="IDef.GENDER" Mandatory="Yes"/>
		   <ItemRef OID="IDef.ISPREG" Mandatory="Yes" CollectionExceptionConditionOID="CECID.ISMALE"/>
</ItemGroup>

<ConditionDef OID="CECID.ISMALE">
     <TranslatedText xml:Lang="en">Do not collect data for Male subjects </TranslatedText>
	 <FormalExpression context="PL/SQL">
	 	  <!<[CDATA[INCLUSION.IDef.GENDER &eq; 'Male']]>     <!--  <>   means not equal to -->
	 </FormalExpression>
</ConditionDef>
	 

Body:

(Description?, Question?, ExternalQuestion?, MeasurementUnitRef*, RangeCheck*, CodeListRef?, Role* Deprecated, Alias*)

Attributes:

	OID	oid
	Name	name
	DataType	(text | integer | float | date | time | datetime | string | boolean | double | hexBinary | base64Binary | hexFloat | base64Float | partialDate | partialTime | partialDatetime | durationDatetime | intervalDatetime | incompleteDatetime | URI )
	Length	integer	(optional)
	SignificantDigits	integer	(optional)
	SASFieldName	sasName	(optional)
	SDSVarName	sasName	(optional)
	Origin	text	(optional)
	Comment	text	(optional)
	MethodDefOID	oidref	(optional)

Contained in:

MetaDataVersion

An ItemDef describes a type of item that can occur within a study. Item properties include name, datatype, data size, measurement units, range or codelist restrictions, and several other properties.

The DataType attribute specifies how the corresponding Value elements are to be interpreted for comparison and storage. The Length attribute is required when DataType is text or string and can be ignored for the other datatypes. The SignificantDigits attribute is always optional.

Note: In version 1.2 the SignificantDigits attribute was required for ItemDef elements with data type Float.

If DataType=integer, Length=N is a requirement that the receiving system be able to process and store all whole number values of magnitude less than 10^N. Larger values may be rejected.

If DataType=float, Length=N and SignificantDigits=S is a requirement that the receiving system be able to process and store all numeric values of magnitude less than 10^N-S that are multiples of 10^-S. Larger values may be rejected. Intermediate values may be rounded to the nearest multiple of 10^-S.

If DataType=text, Length=N is a requirement that the receiving system be able to process and store all text string values of length less than or equal to N. All characters are allowed in text string values. Data of type Text should be transmitted in an ItemDataString element.

Note: Length and SignificantDigits are statements about an item's data values, not the number of characters used to represent these values in Value elements. For example, the character "<" might be represented as "&lt;".

Note: Data characters that are not included in the encoding character set for a particular ODM file must be represented using XML entities or character references. For example, Æ could be represented as "&#198;".

Body:

(TranslatedText+)

Attributes:

NONE

Contained in:

ItemDef

A human-readable label used to name an item on paper or on a screen.

Body:

EMPTY

Attributes:

	Dictionary	text	(optional)	The name of the external question dictionary.
	Version	text	(optional)	The version designator of the external question dictionary.
	Code	text	(optional)	A code selecting the particular question within the external dictionary.

Contained in:

ItemDef

A reference to an externally defined question.

Body:

EMPTY

Attributes:

MeasurementUnitOID

oidref

Reference to the MeasurementUnit definition.

Contained in:

ItemData, ItemDef, RangeCheck

A reference to a measurement unit definition.

Body:

(CheckValue+ | FormalExpression+, MeasurementUnitRef?, ErrorMessage?)

Attributes:

	Comparator	(LT | LE | GT | GE | EQ | NE | IN | NOTIN)		Comparison operator used to compare the item and value(s).	(optional)
	SoftHard	(Soft | Hard)

Contained in:

ItemDef

A RangeCheck defines a constraint on the value of the enclosing item. It may defined as an explicit 1 or 2 sided range or as an expression that evaluates to True when the ItemData value is valid or False when the ItemData value is invalid.

A one-sided constraint on an item value (a full range check will require two RangeCheck elements, one for the lower bound and one for the upper bound). The constraint is equivalent to

itemValue comparator checkValue(s)

If an actual data value fails the constraint, it is either rejected (a Hard constraint) or a warning is produced (a Soft constraint).

For the following comparison operators, one check value is required.

A set of check values is required for these two comparators:

Examples:

	Value must be positive	<RangeCheck Comparator="GT"><CheckValue>0</CheckValue></RangeCheck>
	Value must be between 18 and 65	<RangeCheck Comparator="GE"><CheckValue>18</CheckValue></RangeCheck> <RangeCheck Comparator="LT"><CheckValue>65</CheckValue></RangeCheck>
	Value must be one of (1, 5, 7)	<RangeCheck Comparator="IN"><CheckValue>1</CheckValue><CheckValue>3</CheckValue><CheckValue>5</CheckValue>

A FormalExpression element may be used in place of a Check Value. In this case, the comparator is ignored and the formal expression shall accept the value of the ItemData element and it shall return a boolean TRUE when the value is valid or a boolean FALSE when the value is invalid.

If a measurement unit is specified, the corresponding item values must have interconvertible measurement units (either explicitly or by default). Proper conversion of units must be done as part of the range check.

If a measurement unit is not specified, the corresponding item values must not have measurement units (either explicitly or by default).

Body:

value

Attributes:

NONE

Contained in:

RangeCheck

A comparison value used in a range check. It must match the value type declared in the containing ItemDef.

Body:

(TranslatedText+)

Attributes:

NONE

Contained in:

RangeCheck

Error message to be used when a range check is violated.

Body:

EMPTY

Attributes:

CodeListOID

oidref

Reference to the CodeList definition.

Contained in:

ItemDef

A reference to a CodeList definition. The DataType attributes of the referenced CodeList and the containing ItemDef must be the same.

Body:

EMPTY

Attributes:

	Context	text
	Name	text

Contained in:

ItemDef, ItemGroupDef

An Alias provides an additional name for an ItemDef or an ItemGroupDef. The Context attribute specifies the application domain in which this additional name is relevant.

Body:

(CodeListItem* | ExternalCodeList | EnumeratedItem*)

Attributes:

	OID	oid
	Name	name
	DataType	(integer | float | text | string )
	SASFormatName	sasFormat	(optional)

Contained in:

MetaDataVersion

Defines a discrete set of permitted values for an item. The definition can be an explicit list of values (CodeListItem+|EnumeratedItem+) or a reference to an externally defined code