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 codelist (ExternalCodeList).

The DataType restricts the values that can appear in the CodeList whether internal or external.

The SASFormatName must be a legal SAS format. Like the DataType, it restricts the values that can appear in the CodeList. However it may be more precise.

Body:

(Decode)

Attributes:

	CodedValue	value		Value of the codelist item (as it would occur in clinical data).
	Rank	number	optional	Numeric order of CodedValue relative to CodedValue for other CodedItems in CodeList.

Contained in:

CodeList

Defines an individual member value of a codelist including display format. The actual value is given, along with a set of print/display-forms. The CodedValue must be an acceptable value of the DataType of the containing CodeList.

The CodeListItems within a single CodeList element must not have duplicate CodedValues, (as interpreted by the CodeList's DataType).

The Rank attribute may be used where the relative value corresponding to an enumeration cannot or should not be determined by its lexical order. For example, if you have a list of enumerated text values including "Low", "Medium", and "High" and wish to assign these relative numeric values 1, 2, and 3 respectively, you should include a Rank attribute for each EnumeratedItem defined. Without the applied rank attribute, the normal lexical ordering would be "High", "Low", and "Medium".

Body:

(TranslatedText+)

Attributes:

NONE

Contained in:

CodeListItem

The set of print-forms for a codelist value.

Body:

EMPTY

Attributes:

	Dictionary	text	(optional)	The name of the external codelist.
	Version	text	(optional)	The version designator of the external codelist.
	ref	text	(optional)	Reference to a local instance of the dictionary.
	href	text	(optional)	URL of an external instance of the dictionary.

Contained in:

CodeList

A reference to an externally defined codelist.

Body:

EMPTY

Attributes:

	CodedValue	value		Text of the enumerated item (as it would occur in clinical data).
	Rank	number	optional	Numeric order of CodedValue relative to CodedValue for other EnumeratedItems in CodeList.

Contained in:

CodeList

Defines an individual member value of a valid value list. Only the coded value is given. If print/display-forms are needed, CodeListItem should be used. CodeListItems and EnumeratedItems may not be mixed within a single codelist. The CodedValue must be an acceptable value of the DataType of the containing CodeList.

The EnumeratedItems within a single CodeList element must not have duplicate CodedValues (as interpreted by the CodeList's DataType).

The Rank attribute may be used where the relative value corresponding to an enumeration cannot or should not be determined by its lexical order. For example, if you have a list of enumerated text values including "Low", "Medium", and "High" and wish to assign these relative numeric values 1, 2, and 3 respectively, you should include a Rank attribute for each EnumeratedItem defined. Without the applied rank attribute, the normal lexical ordering would be "High", "Low", and "Medium".

Body:

EMPTY

Attributes:

	OID	oid
	PdfFileName	fileName		Name of a Adobe PDF file containing the screen layout.
	PresentationOID	oidref	(optional)	Reference to a Presentation definition.

Contained in:

FormDef

A visual image of the screen layout used to collect the data on a form. Useful in archiving a study.

Body:

(Description, FormalExpression*)

Attributes:

	OID	oid
	Name	name
	Type	(Computation| Imputation| Transpose | Other)

Contained in:

MetaDataVersion

A MethodDef describes how a data value can be obtained from a collection of other data values.

A MethodDef must contain a Description element. It may or may not contain a FormalExpression. That is, a text description of actions defined in the Formal Expression whether or not the FormalExpression is provided.

Body:

text

Attributes:

	OID	oid
	xml:lang	languageTag	(optional)

Contained in:

MetaDataVersion

Body:

(Description, FormalExpression*)

Attributes:

	OID	oid
	name	name

Contained in:

MetaDataVersion

A ConditionDef defines a boolean condition. The Description element must be provided and should include a prose description. The ConditionDef is referenced by the CollectionExceptionConditionOID attribute within a study metadata component which may be omitted under circumstances defined by the condition i.e. when the FormalExpression evaluates to True.

If a FormalExpression is provided, it must contain a machine-readable expression that will evaluate to True or False.

If an application cannot interpret the FormalExpression or does not normally support conditional data collection, data for the referencing study metadata component should be collected for all subjects.

Body:

(PCDATA)

Attributes:

Context

text

A free-form qualifier to suggest an appropriate computer language to be used when evaluating the FormalExpression content.

Contained in:

ConditionDef, MethodDef, RangeCheck

A FormalExpression used within a ConditionDef or a RangeCheck must evaluate to True or False. A FormalExpression referenced within a MethodDef with MethodType Imputation, Computation or Transpose must evaluate to the correct DataType for an Item that may be imputed or computed using the Method.

Body:

(User*, Location*, SignatureDef*)

Attributes:

StudyOID

oidref

(optional)

Reference to a StudyDef.

Contained in:

ODM

Administrative information about users, locations, and electronic signatures.

If StudyOID is not provided, it is assumed that AdminData definitions apply to all studies defined within the current ODM file and/or to all studies within a sequence of ODM files linked through the PriorFileOID mechanism.

Body:

(LoginName?, DisplayName?, FullName?, FirstName?, LastName?, Organization?, Address*, Email*, Picture?, Pager?, Fax*, Phone*, LocationRef*, Certificate*)

Attributes:

	OID	oid
	UserType	(Sponsor | Investigator | Lab | Other)	(optional)

Contained in:

AdminData

Information about a specific user of a clinical data collection system. This may be an investigator, a CRA, or data management staff. Study subjects are not users in this sense.

Body:

text

Attributes:

NONE

Contained in:

User

The user's login identification.

Body:

text

Attributes:

NONE

Contained in:

User

A short displayable name for the user.

Body:

text

Attributes:

NONE

Contained in:

User

The user's full formal name.

Body:

text

Attributes:

NONE

Contained in:

User

The user's initial given name or all given names.

Body:

text

Attributes:

NONE

Contained in:

User

The user's surname (family name).

Body:

text

Attributes:

NONE

Contained in:

User

The user's organization.

Body:

(StreetName*, City?, StateProv?, Country?, PostalCode?, OtherText?)

Attributes:

NONE

Contained in:

User

The user's postal address.

Body:

text

Attributes:

NONE

Contained in:

Address

The street address part of a user's postal address.

Body:

text

Attributes:

NONE

Contained in:

Address

The city name part of a user's postal address.

Body:

text

Attributes:

NONE

Contained in:

Address

The state or province name part of a user's postal address.

Body:

text

Attributes:

NONE

Contained in:

Address

The country name part of a user's postal address. This must be represented by an ISO 3166 two-letter country code.

Example: FR for France, JP for Japan.

Body:

text

Attributes:

NONE

Contained in:

Address

The postal code part of a user's postal address.

Body:

text

Attributes:

NONE

Contained in:

Address

Any other text needed as part of a user's postal address.

Body:

text

Attributes:

NONE

Contained in:

User

The user's email address.

Body:

EMPTY

Attributes:

	PictureFileName	fileName
	ImageType	name	(optional)

Contained in:

User

A visual depiction of the user.

Body:

text

Attributes:

NONE

Contained in:

User

The phone number of the user's pager.

Body:

text

Attributes:

NONE

Contained in:

User

The phone number of the user's facsimile machine.

Body:

text

Attributes:

NONE

Contained in:

User

The user's voice phone number.

Body:

EMPTY

Attributes:

LocationOID

oidref

Reference to a Location definition.

Contained in:

AuditRecord, Signature, User

A reference to the user's physical location.

Body:

text

Attributes:

NONE

Contained in:

User

The user's digital signing certificate.

Note: The Certificate element is not defined further in CDISC ODM V1.3. It is a placeholder for future development.

Body:

(MetaDataVersionRef+)

Attributes:

	OID	oid
	Name	name
	LocationType	(Sponsor | Site | CRO | Lab | Other)	(optional)

Contained in:

AdminData

A physical location -- typically a clinical research site or a sponsor's office.

Body:

EMPTY

Attributes:

	StudyOID	oidref		References the Study that uses this metadata version.
	MetaDataVersionOID	oidref		References the MetaDataVersion (within the above Study).
	EffectiveDate	date

Contained in:

Location

A reference to a MetaDataVersion used at the containing Location. The EffectiveDate expresses the fact that the metadata used at a location can vary over time.

Body:

(Meaning, LegalReason)

Attributes:

	OID	oid
	Methodology	(Digital | Electronic)	(optional)

Contained in:

AdminData

Body:

text

Attributes:

NONE

Contained in:

SignatureDef

A short name for this kind of signature (e.g., authorship, approval).

Body:

text

Attributes:

NONE

Contained in:

SignatureDef

The responsibility statement associated with a signature (e.g., "The signer accepts responsibility for the accuracy of this data.").

Body:

(ItemGroupData*)

Attributes:

	StudyOID	oidref		References the Study that defines the metadata for this reference data.
	MetaDataVersionOID	oidref		References the MetaDataVersion (within the above Study) for this reference data.

Contained in:

ODM

Reference data provides information on how to interpret clinical data. For example, reference data might include lab normal ranges. Signature elements nested within ReferenceData have no meaning, and should be ignored.

The StudyOID and MetaDataVersionOID attributes select a particular metadata version. All metadata references (OIDs) occurring within this ReferenceData element refer to definitions within the selected metadata version.

The TransactionType attribute behaves the same within ReferenceData as it does within ClinicalData.

Note: Since reference data can be independent of any particular study, it may be desirable to keep the reference metadata separate from clinical metadata. This can be done by creating a Study element with no Protocol, StudyEventDef, or FormDef elements. All the ItemGroupDefs would have IsReferenceData=Yes. Such a study would have no clinical data.

Body:

(SubjectData*, AuditRecords*, Signatures*, Annotations*)

Attributes:

	StudyOID	oidref		References the Study that uses the data nested within this element.
	MetaDataVersionOID	oidref		References the MetaDataVersion (within the above Study) that governs the data nested within this element.

Contained in:

ODM

Clinical data for multiple subjects.

The StudyOID and MetaDataVersionOID attributes select a particular metadata version. All metadata references (OIDs) occurring within this ClinicalData element refer to definitions within the selected metadata version.

Body:

(AuditRecord?, Signature?, InvestigatorRef?, SiteRef?, Annotation*, StudyEventData*)

Attributes:

	SubjectKey	subjectKey
	TransactionType	(Insert | Update | Remove | Upsert | Context)	(optional)	The TransactionType attribute need not be present in a Snapshot document.

Contained in:

ClinicalData

Clinical data for a single subject.

The SubjectKey is used to name a specific subject. This key is unique within the parent study. If a subject has data for two or more metadata versions, the subject key must be the same in each.

Example:

<ClinicalData StudyOID="P2006-101" MetadataVersionOID="101.01">
   <SubjectData SubjectKey="1000" TransactionType="Insert">
      <StudyEventData StudyEventOID="101.Screen">
         <FormData FormOID="101.DEMOG">
            <ItemGroupData ItemGroupOID="101.DM">
                <ItemDataString ItemOID="101.USUBJID">101-001-001</ItemDataString>
                <ItemDataString ItemOID="101.SEX">F</ItemDataString>
            </ItemGroupData>
        </FormData>
        <FormData FormOID="101.LABDATA">
            <ItemGroupData ItemGroupOID="LB.101">
                <ItemDataDateTime ItemOID="101.LBDTC">2006-07-14T14:48</ItemDataDate>
                <ItemDataString ItemOID="101.LBTESTCD">ALT</ItemDataString>
                <ItemDataString ItemOID="101.LBORRES">245</ItemDataString>
            </ItemGroupData>
        </FormData>
      </StudyEventData>
  </SubjectData>
</ClinicalData>
<ClinicalData StudyOID="P2006-101" MetadataVersionOID="101.02">
  <SubjectData SubjectKey="1000" TransactionType="Insert">
      <StudyEventData>
        <FormData FormOID="101.AENONSER">
            <ItemGroupData ItemGroupOID="AE.101">
                <ItemDataString ItemOID="101.AETERM">Fever</ItemDataString>
                <ItemDataDate ItemOID="101.AESTDTC">2006-08-21</ItemDataDate>
            </ItemGroupData>
        </FormData>
        <FormData FormOID="101.LABDATA">
            <ItemGroupData ItemGroupOID="LB.101">
                <ItemDataDateTime ItemOID="101.LBDTC">2006-07-14T14:48</ItemDataDateTime>
                <ItemDataString ItemOID="101.LBTESTCD">ALT</ItemDataString>
                <ItemDataString ItemOID="101.LBORRES">300</ItemDataString>
            </ItemGroupData>
        </FormData>
      </StudyEventData>
  </SubjectData>
</ClinicalData>

Body:

(AuditRecord?, Signature?, Annotation*, FormData* )

Attributes:

	StudyEventOID	oidref		Reference to the StudyEventDef.
	StudyEventRepeatKey	repeatKey	(optional)	A key used to distinguish between repeats of the same type of study event for a single subject.
	TransactionType	(Insert | Update | Remove | Upsert | Context)	(optional)	The TransactionType attribute need not be present in a Snapshot document.

Contained in:

SubjectData

Clinical data for a study event (visit). The model supports repeating study events (for example, when the same set of information is collected for a series of patient visits).

The StudyEventOID and StudyEventRepeatKey are used together to name a particular study event. This pair of values is unique within the parent subject. The StudyEventRepeatKey is present if and only if the StudyEventDef is repeating.

Body:

(AuditRecord?, Signature?, ArchiveLayoutRef?, Annotation*, ItemGroupData* )

Attributes:

	FormOID	oidref		Reference to the FormDef.
	FormRepeatKey	repeatKey	(optional)	A key used to distinguish between repeats of the same type of form within a single study event.
	TransactionType	(Insert | Update | Remove | Upsert | Context)	(optional)	The TransactionType attribute need not be present in a Snapshot document.

Contained in:

StudyEventData

Clinical data for a form (page). The model supports repeating forms in a single study event (for example, when several adverse events are recorded in a single patient visit).

The FormOID and FormRepeatKey are used together to name a particular form. This pair of values is unique within the parent study event. The FormRepeatKey is present if and only if the FormDef is repeating.

Body:

(AuditRecord?, Signature?, Annotation*, ItemData* , ItemDataTYPE*)

Attributes:

	ItemGroupOID	oidref		Reference to the ItemGroupDef.
	ItemGroupRepeatKey	repeatKey	(optional)	A key used to distinguish between repeats of the same type of item group within a single form.
	TransactionType	(Insert | Update | Remove | Upsert | Context)	(optional)	The TransactionType attribute need not be present in a Snapshot document.

Contained in:

FormData, ReferenceData

Clinical data for an item group (record). The model supports repeating item groups in a single form (for example, when several previous hospitalizations are reported in one history), or within reference data.

The ItemGroupOID and ItemGroupRepeatKey are used together to name a particular item group. This pair of values is unique within the parent form. The ItemGroupRepeatKey is present if and only if the ItemGroupDef is repeating.

ItemGroupData can also occur as reference data. In that case, the ItemGroupOID and ItemGroupRepeatKey pair must be unique within the reference data.

Body:

(AuditRecord?, Signature?, MeasurementUnitRef?, Annotation* )

Attributes:

	ItemOID	oidref		Reference to the ItemDef.
	TransactionType	(Insert | Update | Remove | Upsert | Context)	(optional)	The TransactionType attribute need not be present in a Snapshot document.
	Value	text	(optional)	The data collected for an item. This data is represented according to DataType attribute of the ItemDef.
	IsNull	(Yes | No)	(optional)	IsNull is a flag to signify that an item's value is to be set to null. IsNull is used only under these conditions: Transaction type is Insert or Update or Upsert; the Value attribute is not supplied. In these conditions, if IsNull is "Yes", then this is an instruction to set the item's value to Null. If Value is specified, use it. If the Value is not set and IsNull is No, do not change the item's value. In the interest of creating non-verbose XML instances, one should not use ItemData elements with IsNull set to "Yes" to indicate uncollected data. The better practice is to transmit only collected data.

Contained in:

ItemGroupData

The ItemData element may be used for un-typed transmission of the clinical data for an item. The model does not support repeating items within a single item group.

The ItemOID is used to name a particular item definition. This value is unique within the parent item group (no repeats).

Body:

(PCDATA)

Attributes:

	ItemOID	oidref		Reference to the ItemDef.
	TransactionType	(Insert | Update | Remove | Upsert | Context)	(optional)	The TransactionType attribute need not be present in a Snapshot document.
	AuditRecordID	idref		Reference to AuditRecord.
	SignatureID	idref		Reference to Signature.
	AnnotationID	idref		Reference to Annotation.
	MeasurementUnitOID	oidref		Reference to the MeasurementUnit definition.

Contained in:

ItemGroupData

Body:

EMPTY

Attributes:

ArchiveLayoutOID

oidref

Reference to the ArchiveLayout.

Contained in:

FormData

A reference to the archive layout used to collect the form's data.

On Update, a NULL ArchiveLayoutOID is permitted.

Body:

(UserRef, LocationRef, DateTimeStamp, ReasonForChange?, SourceID?)

Attributes:

	EditPoint	(Monitoring | DataManagement | DBAudit)	(optional)
	UsedImputationMethod	(Yes | No)	(optional)
	ID	ID	(optional*)

Contained in:

FormData, ItemData, ItemGroupData , StudyEventData, SubjectData, AuditRecords

An AuditRecord carries information pertaining to the creation, deletion, or modification of clinical data. This information includes who performed that action, and where, when, and why that action was performed.

The EditPoint attribute identifies the phase of data processing in which action occurred, and the UsedImputationMethod attribute indicates whether the action involved the use of a Method. (Note: In ODM 1.3, the new element Method was introduced and the ImplementationMethod element was deprecated.

*If an AuditRecord is contained within an AuditRecords element, the ID attribute must be provided.

Note: The monitoring phase includes any data collection and correction involving the clinician, study-site personnel, or study monitor. The data management phase includes any changes made for internal data processing reasons (for example, coding or updating derived data) and before database lock. The DB audit phase occurs after database lock.

AuditRecord information describes a change to clinical data, but is not itself clinical data. The value of some clinical data can always be changed by a subsequent transaction, but history cannot be changed -- only added to.

Whenever an element has an TransactionType (either explicit or inherited), an AuditRecord must be provided. However, an AuditRecord has no meaning in a Snapshot transfer.

As with the TransactionType attribute, an AuditRecord is inherited by any subelement that is allowed to have an AuditRecord and does not already have one attached.

Body:

EMPTY

Attributes:

UserOID

oidref

Reference to the User definition.

Contained in:

AuditRecord, Signature

Body:

datetime

Attributes:

NONE

Contained in:

AuditRecord, Signature

The date/time that the data entry, modification, or signature was performed. This applies to the initial occurrence of the action, not to subsequent transfers between computer systems.

The DateTimeStamp datatype is datetime. A value conforming to the ISO 8601 Complete Representation must be provided. Partial or incomplete forms are not valid.

Body:

text

Attributes:

NONE

Contained in:

AuditRecord

A user-supplied reason for a data change.

Body:

text

Attributes:

NONE

Contained in:

AuditRecord

Information that identifies the source of the data within an originating system. It is only meaningful within the context of that system.

Example: A SourceID attached to an ItemGroup could be used to carry the originating system's internal record OID for that data.

Body:

(UserRef, LocationRef, SignatureRef, DateTimeStamp, CryptoBindingManifest? Deprecated)

Attributes:

ID

ID

(optional*)

Contained in:

FormData, ItemData, ItemGroupData , StudyEventData, SubjectData, Signatures

A general note about clinical data. If an annotation has both a comment and flags, the flags should be related to the comment.

The SeqNum attribute (a small positive integer) uniquely identifies the annotation within its parent entity.

An empty Annotation (one with no comment and no flags) is not allowed unless the TransactionType is Remove. On Update, the entire value of the annotation is replaced.

*Note:If an Annotation is contained with an Annotations element, the ID attribute is required.

Body:

text

Attributes:

SponsorOrSite

(Sponsor | Site)

(optional)

Source of the comment.

Contained in:

Annotation

A free-text (uninterpreted) comment about clinical data. The comment may have come from the Sponsor or the clinical Site.

Body:

(FlagValue, FlagType?)

Attributes:

NONE

Contained in:

Annotation

A machine-processable annotation on clinical data.

Body:

text

Attributes:

CodeListOID

oidref

Reference to the CodeList definition.

Contained in:

Flag

The value of the flag. The meaning of this value is typically dependent on the associated FlagType. The actual value must be a member of the referenced CodeList.

Body:

name

Attributes:

CodeListOID

oidref

Reference to the CodeList definition.

Contained in:

Flag

The type of flag. This determines the purpose and semantics of the flag. Different applications are expected to be interested in different types of flags. The actual value must be a member of the referenced CodeList.

Body:

EMPTY

Attributes:

UserOID

oidref

Reference to a User definition.

Contained in:

SubjectData

On Update, a NULL UserOID is permitted.

Body:

EMPTY

Attributes:

LocationOID

oidref

Reference to a Location definition.

Contained in:

SubjectData

On Update, a NULL LocationOID is permitted.

Body:

(AuditRecord*)

Attributes:

none

Contained in:

ClinicalData

Groups AuditRecord elements referenced by ItemDataTYPE elements.

Body:

(Signature*)

Attributes:

none

Contained in:

ClinicalData

Groups Signature elements referenced by ItemDataType elements.

Body:

(Annotation*)

Attributes:

none

Contained in:

ClinicalData

Groups Annotation elements referenced by ItemDataType elements.

Body:

(KeySet, KeySet, Annotation)

Attributes:

	StudyOID	oidref
	MetaDataVersionOID	oidref

Contained in:

ODM

An association permits an annotation to be placed on an ordered pair of entities rather than on just one. The first and second KeySets identify the start and end of the annotated "link".

The StudyOID and MetaDataVersionOID provide a context for interpreting CodeList references within the Annotation. They do not effect the meaning of the KeySets.

Body:

EMPTY

Attributes:

	StudyOID	oidref
	SubjectKey	subjectKey	(optional)
	StudyEventOID	oidref	(optional)
	StudyEventRepeatKey	repeatKey	(optional)
	FormOID	oidref	(optional)
	FormRepeatKey	repeatKey	(optional)
	ItemGroupOID	oidref	(optional)
	ItemGroupRepeatKey	repeatKey	(optional)
	ItemOID	oidref	(optional)

Contained in:

Association

Body:

(SignedInfo, SignatureValue, KeyInfo?, Object*)

Attributes:

	xmlns	CDATA
	Id	ID	(optional)

Contained in:

ODM

This index lists all the attributes used, along with the elements that use them.

	Archival	ODM
	ArchiveLayoutOID	ArchiveLayoutRef
	AnnotationID	ItemData[TYPE]
	AuditRecordID	ItemData[TYPE]
	AsOfDateTime	ODM
	Category	StudyEventDef
	Code	ExternalQuestion
	CodeListOID	CodeListRef, FlagType, FlagValue
	CodedValue	CodeListItem
	CollectionExceptionConditionOID	StudyEventRef, FormRef, ItemGroupRef, ItemRef
	Comment	ItemDef, ItemGroupDef
	Comparator	RangeCheck
	Context	Alias,FormalExpression
	CreationDateTime	ODM
	DataType	CodeList, ItemDef
	Description	MetaDataVersion, ODM
	Dictionary	ExternalCodeList, ExternalQuestion
	Domain	ItemGroupDef
	EditPoint	AuditRecord
	EffectiveDate	MetaDataVersionRef
	FileOID	ODM
	FileType	ODM
	FormOID	FormData, FormRef, KeySet
	FormRepeatKey	FormData, KeySet
	Granularity	ODM
	Href	ExternalCodelist
	ID	ODM, AuditRecord, Signature, Annotation
	Id	ds:Signature
	ImageType	Picture
	ImputationMethodOID	deprecated 1.3
	IsNull	ItemData
	IsReferenceData	ItemGroupDef
	ItemGroupOID	ItemGroupData, ItemGroupRef, KeySet
	ItemGroupRepeatKey	ItemGroupData, KeySet
	ItemOID	ItemData, ItemRef, KeySet
	KeySequence	ItemRef
	Length	ItemDef
	LocationOID	LocationRef, SiteRef
	LocationType	Location
	Mandatory	FormRef, ItemGroupRef, ItemRef, StudyEventRef
	MeasurementUnitOID	MeasurementUnitRef,ItemDataTYPE
	MetaDataVersionOID	Association, ClinicalData, Include, MetaDataVersionRef, ReferenceData
	MethodOID	ItemRef
	Methodology	SignatureDef
	Name	Alias, CodeList, FormDef, ItemDef, ItemGroupDef, Location, MeasurementUnit, MetaDataVersion, StudyEventDef
	ODMVersion	ODM
	OID	ArchiveLayout, CodeList, FormDef, ItemDef, ItemGroupDef, Location, MeasurementUnit, MetaDataVersion, Presentation, SignatureDef, Study, StudyEventDef, User
	OrderNumber	FormRef, ItemGroupRef, ItemRef, StudyEventRef
	Origin	ItemDef, ItemGroupDef
	Originator	ODM
	PdfFileName	ArchiveLayout
	PictureFileName	Picture
	PresentationOID	ArchiveLayout
	PriorFileOID	ODM
	Purpose	ItemGroupDef
	Rank	CodeListItem, EnumeratedItem
	Ref	ExternalCodelist
	Repeating	FormDef, ItemGroupDef, StudyEventDef
	Role	ItemGroupDef, ItemRef
	RoleCodeListOID	ItemRef
	SASDatasetName	ItemGroupDef
	SASFieldName	ItemDef
	SASFormatName	CodeList
	SDSVarName	ItemDef
	SeqNum	Annotation
	SignatureID	ItemData[TYPE]
	SignatureOID	SignatureRef
	SignificantDigits	ItemDef
	SoftHard	RangeCheck
	SourceSystem	ODM
	SourceSystemVersion	ODM
	SponsorOrSite	Comment
	StudyEventOID	KeySet, StudyEventData, StudyEventRef
	StudyEventRepeatKey	KeySet, StudyEventData
	StudyOID	AdminData, Association, ClinicalData, Include, KeySet, MetaDataVersionRef, ReferenceData
	SubjectKey	KeySet, SubjectData
	TransactionType	Annotation, FormData, ItemData, ItemGroupData, StudyEventData, SubjectData
	Type	StudyEventDef, MethodDef
	UsedImputationMethod	AuditRecord
	UserOID	InvestigatorRef, UserRef
	UserType	User
	Value	ItemData
	Version	ExternalCodeList, ExternalQuestion
	xml:lang	Presentation, TranslatedText
	xmlns	ds:Signature