Clinical Data Interchange Standards Consortium

Specification for the Operational Data Model (ODM)

Version 1.2
Source File: ODM-1.2.5.adtd
Last Update: 19 Dec 2003 10:10 AM




Copyright © CDISC 2003 This document is the property of CDISC Inc. This document can be freely used and reproduced without limitation as long as (1) it is not modified, and (2) the entire copyright statement is included in the copy. Modifications to this document can only be made with written consent of CDISC Inc.

An official copy of this document is available at http://www.cdisc.org/models/odm/v1.2/ODM1-2-0.html.



Table of Contents

1   Introduction (non-normative)
2   General Issues
      2.1   Content of the Standard
      2.2   File Conformity
      2.3   System Conformity
      2.4   Vendor Extensions
      2.5   Changes from Previous Versions (non-normative)
      2.6   Entities and Elements
      2.7   Clinical Data Keys
      2.8   Single Files and Collections
      2.9   Transactions
      2.10   Element Ordering
      2.11   Element Identifiers and References
      2.12   Syntax Notation
      2.13   Data Formats
3   General Elements
      3.1   ODM
      3.2   Study
      3.3   GlobalVariables
      3.4   StudyName
      3.5   StudyDescription
      3.6   ProtocolName
      3.7   BasicDefinitions
      3.8   MeasurementUnit
      3.9   Symbol
      3.10   TranslatedText
4   Metadata Elements
      4.1   MetaDataVersion
      4.2   Include
      4.3   Protocol
      4.4   StudyEventRef
      4.5   StudyEventDef
      4.6   FormRef
      4.7   FormDef
      4.8   ItemGroupRef
      4.9   ItemGroupDef
      4.10   ItemRef
      4.11   ItemDef
      4.12   Question
      4.13   ExternalQuestion
      4.14   MeasurementUnitRef
      4.15   RangeCheck
      4.16   CheckValue
      4.17   ErrorMessage
      4.18   CodeListRef
      4.19   Role
      4.20   Alias
      4.21   CodeList
      4.22   CodeListItem
      4.23   Decode
      4.24   ExternalCodeList
      4.25   ArchiveLayout
      4.26   ImputationMethod
      4.27   Presentation
5   Administrative Elements
      5.1   AdminData
      5.2   User
      5.3   LoginName
      5.4   DisplayName
      5.5   FullName
      5.6   FirstName
      5.7   LastName
      5.8   Organization
      5.9   Address
      5.10   StreetName
      5.11   City
      5.12   StateProv
      5.13   Country
      5.14   PostalCode
      5.15   OtherText
      5.16   Email
      5.17   Picture
      5.18   Pager
      5.19   Fax
      5.20   Phone
      5.21   LocationRef
      5.22   Certificate
      5.23   Location
      5.24   MetaDataVersionRef
      5.25   SignatureDef
      5.26   Meaning
      5.27   LegalReason
6   Reference Data Elements
      6.1   ReferenceData
7   Clinical Data Elements
      7.1   ClinicalData
      7.2   SubjectData
      7.3   StudyEventData
      7.4   FormData
      7.5   ArchiveLayoutRef
      7.6   ItemGroupData
      7.7   ItemData
      7.8   Annotation
      7.9   Comment
      7.10   Flag
      7.11   FlagValue
      7.12   FlagType
      7.13   Signature
      7.14   UserRef
      7.15   SignatureRef
      7.16   DateTimeStamp
      7.17   CryptoBindingManifest
      7.18   AuditRecord
      7.19   ReasonForChange
      7.20   SourceID
      7.21   InvestigatorRef
      7.22   SiteRef
      7.23   Association
      7.24   KeySet
8   Digital Signatures
      8.1   ds:Signature
9   Element Index (non-normative)
10   Attribute Index (non-normative)

1   Introduction (non-normative)

The Operational Data Model (ODM) is a vendor neutral, platform independent format for interchange and archive of data collected in clinical trials. The model represents study metadata, data and administrative data associated with a clinical trial. Only the information that needs to be shared among different software systems during a trial, or archived after a trial is included in the model.

This is version 1.2 of the ODM. Version 1.2 contains a number of new features that improve the functionality, security and convenience of the model. Descriptions of the new features have been incorporated into the text of this document. A separate document Version 1.2 New Features provides a summary of the new features for users of earlier versions of the model.

Beginning with version 1.2, both an XML Schema and a DTD are provided with the ODM model. The XML schema should be considered definitive. The DTD is informational and is provided for backward compatibility.

Clinical data management systems vary significantly in the information they store and the rules they enforce. The ODM model has been designed to represent a wide range of study information so as to be compatible with most existing clinical data management systems. Systems that do not have all of the features represented by the ODM model may still be ODM compatible as long as they comply with the conformity rules provided in the section on System Conformity.

The ODM has been designed to be compliant with guidance and regulations published by the FDA for computer systems used in clinical trials. This document is intended to be both the formal specification of the ODM and a user guide for those involved in transferring or archiving of clinical data using the model.

2   General Issues

2.1   Content of the Standard

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

2.2   File Conformity

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

  1. The ODM file must be a well-formed XML file. See the XML standard for details.
  2. The ODM file must conform to the XML Namespace standard. See the XML Namespace standard for details.
  3. The ODM file must contain only elements and attributes defined in this standard, and satisfy the rules about element nesting and the formats of attribute values and element bodies.
  4. The ODM file must contain a prolog and a single (top-level) ODM element.
  5. The XML system identifier for the version 1.2 ODM file format is "http://www.cdisc.org/dtd/ODM-1.2.dtd".

Example:

 

<?xml version="1.0" encoding="ISO-8859-1"?>
<ODM ...>
...
</ODM>

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

Accompanying this standard is an automatically generated XML Schema file and an automatically generated DTD file, both of which express certain of the syntactic constraints. These files can be used (along with a validating XML parser) to test that an ODM file is syntactically valid. However, syntactic validity is only part of total correctness.

The XML Schema should be considered definitive, and the DTD informational. This is because the Schema captures more of the syntactic constraints, and because it is compatible with XML namespaces.

2.3   System Conformity

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. Information included in generated ODM files must be accurate according to the rules of this standard.
  4. A receiving system must interpret information read from an ODM file accurately according to the rules of this standard.
  5. Generated ODM files need not include information that is not normally handled or stored by the generating system.
  6. 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.
  7. A receiving system may constrain the range of data values, keys, names, and so on, that it is capable of handling or storing.
  8. All system limitations (rules 5 thru 7) must be documented.
  9. If conformity is dependent on certain modes or settings, this must also be documented.

2.4   Vendor Extensions

Clinical data systems frequently store more information than can be expressed in the ODM model. The exact nature of such additional information will vary from system to system. Thus, there will be pressure for proprietary extensions to the model.

Vendor extensions to the ODM model are acceptable as long as

  1. The vendor supplies a XML Schema or DTD specification fully describing their extended ODM format.
  2. Extended ODM files reference the proper extension Schema or DTD.
  3. The extension adds new XML elements and attributes, but does not render any standard ODM file obsolete. That is, all ODM files that are correct under this standard are acceptable as extended ODM files.
  4. All new element and attribute names use distinct XML namespaces to insure that there are no naming conflicts with other vendor extensions.
  5. The file obtained (from an extended ODM file) by removing all vendor extensions must be a meaningful and accurate standard ODM file.
  6. ODM files free of any vendor extensions can be generated upon request.

Vendor extensions should never be used for information that can be expressed using other ODM elements.

Note: Vendor extensions that carry generally useful information should be brought to CDISC's attention for possible future standardization.

Note: It is easy to write a filter that removes all non-standard attributes and elements from an extended XML file, either as a stand-alone program or as part of normal input processing. Receiving systems are encouraged to be forgiving when encountering extended ODM files.

2.5   Changes from Previous Versions (non-normative)

ODM 1.2 is a pure extension of ODM 1.1. Elements and attributes have been added, but none have been removed. Elements and attributes that are present in both versions have the same interpretations. However, there are two ways in which an ODM 1.1 file will fail to be a perfect ODM 1.2 file:

  1. An ODM 1.1 file will reference the ODM 1.1 DTD, while an ODM 1.2 file will reference the ODM 1.2 Schema (or DTD).
  2. ODM 1.1 files can contain date/time values that violate the ISO 8601 and XML Schema standards. Date/time values in ODM 1.2 files must conform to these standards. (Applications that read ODM files are urged to be forgiving on this point.)

Note: An XSL preprocessor can be used to fix any non-standard dates that might occur in an ODM 1.1 file, producing a fully correct ODM 1.2 file.

The elements that have been added to ODM 1.2 are

The attributes that have been added to ODM 1.2 are

  • ODMVersion, Originator, SourceSystem, SourceSystemVersion (in ODM)
  • Description (in MetaDataVersion)
  • Purpose (in ItemGroupDef)
  • KeySequence, ImputationMethodOID, Role, RoleCodeListOID (in ItemRef)
  • EditPoint, UsedImputationMethod (in AuditRecord)

The BasicDefinitions element in Study is now optional. The values of the sasName format have been expanded and augmented with a sasFormatName format.

In ODM 1.2, a small number of elements and attributes are labeled as deprecated. This means that that element or attribute is still legal, but that its use is discouraged. Deprecated features may be removed in some future version of this standard.

The deprecated elements and attributes are the Role element, the CryptoBindingManifest element, and the Role attribute (in ItemGroupDef).

2.6   Entities and Elements

The ODM model assumes that a study's clinical data will consist of several kinds of entities. These include subjects, study events, forms, item groups, items, and annotations.

An item is an individual clinical data item, such as a single systolic blood pressure reading. Items are collected together into item groups.

An item group is a closely related set of items that are generally analyzed together. (Item groups are sometimes referred to as "records" and are associated with "panels" or "tables".) Item groups are aggregated into forms.

A form is analogous to a page in a paper CRF book or electronic CRF screen. A form generally collects a set of logically and temporally related information. A series of forms is collected as part of a study event.

A study event is a patient visit or some other data-collection event. Each study event belongs to some patient in the study.

A subject is a patient participating in the study.

An annotation is a comment applied to a subject, study event, form, item group, or item. Annotations can also be applied to pairs of entities.

The metadata of a study describes the types of study events, forms, item groups, and items that are allowed in the study. The metadata entities include StudyEventDefs, FormDefs, ItemGroupDefs, and ItemDefs.

A StudyEventDef describes a particular type of study event (mostly by listing the types of forms it can contain).

A FormDef describes a particular type of form.

An ItemGroupDef describes a particular type of item group.

An ItemDef describes a particular type of item.

The clinical data of a study will typically have many actual study events corresponding to each StudyEventDef, many actual forms corresponding to each FormDef, and so on.

An ODM file (like any XML file) consists of a tree of elements. The clinical data elements in an ODM file represent either the state of a clinical entity or a change to the state of that entity. These elements include the SubjectData, StudyEventData, FormData, ItemGroupData, ItemData, and Annotation elements.

Each such element contains key attributes that identify the data entity that it provides information for. Frequently, many data elements will correspond to a single data entity. This can occur when a series of updates are being applied to a single entity, or when an audit trail is being represented.

Similarly, there are XML elements corresponding to metadata entities.

Note: Not all clinical studies organize their data into visits or forms. For such a study, it is appropriate to have a single common study event per subject, and/or a single common form per study event.

2.7   Clinical Data Keys

There are two kinds of keys in the ODM model: internal and external. Internal keys are used to designate entities within the model, and to allow cross-references between entities within (and between) ODM files. Internal keys are not for human use, and are assumed to be unchanging. Internal keys include subject keys, element OIDs, and repeat keys.

To fully identify a clinical data entity, the following internal keys are needed:

 

Kind of Entity

Identifying Keys

 

 

study

StudyOID

 

 

subject

above plus SubjectKey

 

 

study event

above plus StudyEventOID and StudyEventRepeatKey

 

 

form

above plus FormOID and FormRepeatKey

 

 

item group

above plus ItemGroupOID and ItemGroupRepeatKey

 

 

item

above plus ItemOID

 

 

annotation

keys for the annotated entity plus SeqNum

 

A StudyOID uniquely identifies a study. A SubjectKey uniquely identifies a subject within a study. SubjectKeys cannot be used to identify a subject across studies.

A StudyEventOID uniquely identifies a StudyEventDef within a study. However there may be several study events of a particular type for a given subject. Thus, to fully identify a particular study event, we need the StudyOID, the SubjectKey, the StudyEventOID, and a StudyEventRepeatKey.

Each form belongs to a study event, and can be identified (within that study event) by a FormOID (which gives its type) and a FormRepeatKey.

Each item group in clinical data belongs to a form, and can be identified (within that form) by an ItemGroupOID (which gives its type) and an ItemGroupRepeatKey.

Other items groups are reference data, and can be identified solely by an ItemGroupOID and an ItemGroupRepeatKey.

Each item belongs to an item group. However items of a given type are not allowed to repeat within the item group. Thus, only the ItemOID is needed to uniquely identify an item within its item group.

External keys are any keys used by clinical personnel. These include subject randomization codes, site codes, and so on. In the ODM model, external keys are represented as if they were clinical data. Thus external keys can be changed as needed, and are subject to normal auditing processes.

2.8   Single Files and Collections

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.

Each ODM document has a FileOID attribute (see the ODM element). The FileOID should uniquely identify the document.

An ODM document can also have a PriorFileOID attribute. This attribute gives the FileOID of the immediately preceding file in a series. Thus, a collection of files linked by PriorFileOID can be used to incrementally describe a source database. (Of course, the first document in the series has no PriorFileOID attribute.)

Data in one file of a series is allowed to depend on definitions contained in an earlier file in the series. If a file contains either ReferenceData or ClinicalData then that file must either contain the necessary metadata definitions to interpret that data directly, or there must be a previous file in the series that contains these definitions. Similarly, if a file contains ClinicalData, the file must either contain the administrative data referenced in the audit and signature records, or there must be a previous file in the series that contain that data.

A tree-structured collection of ODM files (where more than one file references the same prior file) is also allowed.

An ODM document (or collection) can contain information on more than one study. To simplify the discussion, we will occasionally write as if only one study was present. If a file (or collection of files) contains multiple studies, the rules described below should be applied to each of the studies independently.

Note: The FileOID identifies the document content. It does not change just because the document is copied.

Note: FileOIDs should be universally unique if at all possible. One way to ensure this is to prefix every FileOID with an Internet domain name owned by the creator of the ODM file or database (followed by a /). For example, FileOID="BestPharmaceuticals.com/Study5894/1" might be a good way to denote the first file in a series for study 5894 from Best Pharmaceuticals.

Note: Similarly, StudyOIDs should be universally unique if at all possible. For example, StudyOID="BestPharmaceuticals.com/Study5894".

Note: Applications may need to store ODM documents that they receive and later retrieve them based on their FileOID. In particular, interpreting a new file in a series will require locating the prior file by its FileOID. One easy way to do this is to use the (possibly transformed) FileOID as part of the file name itself. For example, the ODM document mentioned above could be stored in ...\BestPharmaceuticals.com\Study5894\1.xml.

Other File Attributes

As implied above, most ODM documents will contain only part of the total information (current and historical) held in the source database.

The information that is sent in a given document can vary along several dimensions. Some examples of the contents of a document are:

  • just metadata,
  • just clinical data,
  • a series of updates of a single value for a single subject,
  • the current state of the entire study,
  • the current state of a subset of a study (particular subjects, particular forms, etc),
  • the changes to the study since the last communication, or
  • a full history of all changes ever made to the study.

Because of this variability, it is also important that each document describe itself, so that the consumer of the document knows what to expect of it. To address these needs, the ODM element has several attributes for describing the current document.

The CreationDateTime attribute tells when the ODM document was created. In contrast, the AsOfDateTime attribute tells when the document content was accurate. This is of particular importance when a series of files is used to give an evolving view of a changing database.

The FileType and Granularity attributes allow the document sender to define the scope, across time and data, that a particular document spans. The Archive attribute allows the sender to assert that the contents of the document meet a specific set of criteria that qualifies it as an electronic record as defined in the FDA 21 CFR 11 Guidance. Finally, the Description attribute provides the sender a text string in which to give details, as elaborately as necessary, to supplement the other attributes in describing the document. This section details the values these attributes can take, and discusses the use of the values in a single document and in a series of documents.

FileType

A document's FileType must be either Snapshot or Transactional. A Snapshot document shows how to re-create the current state of the source database with respect to the included data, but does not show how it got to be in that state over time. A Transactional document shows, for each included entity, both the latest state of the source database, and (optionally) some prior states of that entity in the source database. A Snapshot document contains only Insert transactions for clinical data, and must contain exactly one Insert instruction per data point, while a Transactional document may contain more that one TransactionType instruction, of any type, per clinical data element. When you process an Transactional document, the rules for ordering a set of transactions for a single data point are those described in the section on Element Ordering.

Granularity

A 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. If set, its value must be "Yes".

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

  • The current file must be Transactional.
  • If the current file is one of a collection, all other files in the collection must be both Archival and Transactional.
  • The set of transactions must be both complete and non-redundant within the file or collection of files. In particular each file must contain:
    • no transactions that have an audit date of prior to the AsOfDateTime of its PriorFile (if any),
    • all transactions up to its AsOfDateTime. (For Granularity=All, this means all transactions in the study. See Granularity for the meaning of "all" for other Granularity settings),
    • all AuditRecord and Signature information available in the source database, and
    • no Upsert transactions.

2.9   Transactions

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 for Archive and Incremental transfers.

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.

2.10   Element Ordering

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.

2.11   Element Identifiers and References

In the ODM model, 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. Here are the uniqueness rules:

  • 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, ImputationMethod, or Presentation 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.

We explicitly allow two metadata elements (StudyEventDef, FormDef, ItemGroupDef, ItemDef, CodeList, ImputationMethod, or Presentation) to have the same OID if these elements are of the same kind and are in different MetaDataVersions. The meaning is that these elements represent two versions of the same metadata entity. The later one is an update of the earlier. (See Metadata Elements for more details.)

Whenever an element uses an OID to reference another element, the referenced element must occur within the same document as the reference or within a prior document in a linked series. Thus, the referenced element can always be found by tracing back the PriorFileOID links.

Note: The fact that OID references need to cross files prevents the use of standard XML ID values (which are solely within file references). This is highlighted in our element definitions by using the types oid and oidref instead of ID and IDREF.

Note: The above reference rules imply the following.

  • You cannot send a reference to an OID value unless that OID value has been defined, either in the current document, or in a prior document within the series.
  • If a definition identified by an OID has changed, the change in its definition must be transmitted before or in the document in which the changed definition is referenced.
  • A document that initiates a series must contain all definitions that it references.
  • A Transactional document must include any supporting definitions that are new or changed relative to its prior document. For example, suppose that document B3207 includes references to item definition X, and that a codelist constraint has been added to X since B3207's predecessor document. In that case, B3207 must also include a MetaDataVersion element (with an new OID) containing an updated definition of item X.

2.12   Syntax Notation

The syntax of each XML element is defined in two ways. First, it is defined informally 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 occurrances), or a + (meaning one or more occurrances).

Attributes are listed in tabular form, one attribute per row, including the attribute's name, its data format, its optionality, and possibly some semantic details. All attributes are required unless the optionality column contains "(optional)".

Second, the element's syntax is defined formally using XML Schema. The complete XML Schema for ODM consists of the following header plus all the individual element definition.

XML Schema:

 
<xs:schema
  targetNamespace="http://www.cdisc.org/ns/odm/v1.2"
  xmlns="http://www.cdisc.org/ns/odm/v1.2"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
  elementFormDefault="qualified"
  attributeFormDefault="unqualified"
  >
  <xs:import namespace="http://www.w3.org/XML/1998/namespace"
             schemaLocation="http://www.w3.org/2001/03/xml.xsd"/>
  <xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
             schemaLocation="http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd"/>

2.13   Data Formats

All 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 ODM data formats are

 

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

 

value

xs:string

any of the above

 

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)

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 sequence of Unicode characters. When embedded in ODM files, text strings must be represented using the XML quoting 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".

Note: The above formats for dates, times, and datetimes are compatible with ISO 8601.

Note: Dates and times are complete, not partial. Partial date and time types may be added in the future.

Note: ODM 1.1 allowed a timezone specification of -99:99 to designate "no timezone information." This is no longer allowed in ODM 1.2. However, applications that process both versions of ODM should be forgiving.

An oid (OID) is a string that uniquely identifies an element (see Element Identifiers and References for details). An oidref is the use of an OID to reference an element (as opposed to the defining occurrence of that OID). OIDs and oidrefs are non-empty strings.

The value format is simply the union of all the preceding formats: integer, float, date, time, datetime, text, oid, oidref. The value format is used when the specific value type is determined by metadata rather than by the immediately containing element.

A subjectKey or repeatKey helps designate a clinical data entity (see Clinical Data Keys). They are non-empty strings.

A name is intended to be a human readable name for some entity. Names are non-empty strings.

A sasName (or sasFormat) is any valid SAS Version 5 Transport Format name (or format). These are limited to 8 characters in length.

A fileName designates a file. File names are system dependent, and expressed relative to the directory that contains the ODM file being processed. FileNames are non-empty strings.

A languageTag represents a natural language or a country-specific variant of a natural language. The allowed values are specified in IETF RFC 3066: Tags for the Identification of Languages.

Example: "fr-CA" denotes the French language, Canadian variant. See TranslatedText for a discussion of how languageTags are used.

In general, if you want to represent a NULL attribute value for any of these formats, use an empty string (e.g., attribute-name=""). To represent a NULL for data transmitted in an element body, send the element as empty (e.g. <element-name/>). There is a special IsNull indicator for clinical data, to differentiate between the case where there is no known value, and the case where you want to replace a value with NULL. See the IsNull attribute of the ItemData element.

In the DTD for this standard, all formats are expressed as CDATA or %PCDATA. In the Schema, the definitions can be made more precise as follows.

XML Schema:

 
  <xs:simpleType name="text">
    <xs:restriction base="xs:string"/>
  </xs:simpleType>
 
  <xs:simpleType name="integer">
    <xs:restriction base="xs:integer">
      <xs:pattern value="-?[0-9]+"/>
    </xs:restriction>
  </xs:simpleType>
 
  <xs:simpleType name="float">
    <xs:restriction base="xs:decimal">
      <xs:pattern value="-?[0-9]+(\.[0-9]+)?"/>
    </xs:restriction>
  </xs:simpleType>
 
  <xs:simpleType name="date">
    <xs:restriction base="xs:date">
      <xs:pattern value="[0-9][0-9][0-9][0-9]-[0-1][0-9]-[0-3][0-9]"/>
    </xs:restriction>
  </xs:simpleType>
 
  <xs:simpleType name="time">
    <xs:restriction base="xs:time">
      <xs:pattern value="[0-2][0-9]:[0-5][0-9]:[0-5][0-9](\.[0-9]+)?((\+|-)[0-2][0-9]:[0-5][0-9])?"/>
    </xs:restriction>
  </xs:simpleType>
 
  <xs:simpleType name="datetime">
    <xs:restriction base="xs:dateTime">
      <xs:pattern value="[0-9][0-9][0-9][0-9]-[0-1][0-9]-[0-3][0-9]T[0-2][0-9]:[0-5][0-9]:[0-5][0-9](\.[0-9]+)?((\+|-)[0-2][0-9]:[0-5][0-9])?"/>
    </xs:restriction>
  </xs:simpleType>
 
  <xs:simpleType name="oid">
    <xs:restriction base="xs:string">
      <xs:minLength value="1"/>
    </xs:restriction>
  </xs:simpleType>
 
  <xs:simpleType name="oidref">
    <xs:restriction base="xs:string">
      <xs:minLength value="1"/>
    </xs:restriction>
  </xs:simpleType>
 
  <xs:simpleType name="value">
    <xs:restriction base="xs:string"/>
  </xs:simpleType>
 
  <xs:simpleType name="subjectKey">
    <xs:restriction base="xs:string">
      <xs:minLength value="1"/>
    </xs:restriction>
  </xs:simpleType>
 
  <xs:simpleType name="repeatKey">
    <xs:restriction base="xs:string">
      <xs:minLength value="1"/>
    </xs:restriction>
  </xs:simpleType>
 
  <xs:simpleType name="name">
    <xs:restriction base="xs:string">
      <xs:minLength value="1"/>
    </xs:restriction>
  </xs:simpleType>
 
  <xs:simpleType name="sasName">
    <xs:restriction base="xs:string">
      <xs:pattern value="[A-Za-z_][A-Za-z0-9_]*"/>
      <xs:maxLength value="8"/>
    </xs:restriction>
  </xs:simpleType>
 
  <xs:simpleType name="sasFormat">
    <xs:restriction base="xs:string">
      <xs:pattern value="[A-Za-z_$][A-Za-z0-9_.]*"/>
      <xs:maxLength value="8"/>
    </xs:restriction>
  </xs:simpleType>
 
  <xs:simpleType name="fileName">
    <xs:restriction base="xs:string">
      <xs:pattern value="[A-Za-z0-9_.]+"/>
    </xs:restriction>
  </xs:simpleType>

The following Schema definitions define the enumeration types used in various ODM elements.

XML Schema:

 
  <xs:simpleType name="FileType">
    <xs:restriction base="xs:string">
      <xs:enumeration value="Snapshot"/>
      <xs:enumeration value="Transactional"/>
      <xs:maxLength value="13"/>
    </xs:restriction>
  </xs:simpleType>
 
  <xs:simpleType name="Granularity">
    <xs:restriction base="xs:string">
      <xs:enumeration value="All"/>
      <xs:enumeration value="Metadata"/>
      <xs:enumeration value="AdminData"/>
      <xs:enumeration value="ReferenceData"/>
      <xs:enumeration value="AllClinicalData"/>
      <xs:enumeration value="SingleSite"/>
      <xs:enumeration value="SingleSubject"/>
      <xs:maxLength value="15"/>
    </xs:restriction>
  </xs:simpleType>
 
  <xs:simpleType name="EventType">
    <xs:restriction base="xs:string">
      <xs:enumeration value="Scheduled"/>
      <xs:enumeration value="Unscheduled"/>
      <xs:enumeration value="Common"/>
      <xs:maxLength value="11"/>
    </xs:restriction>
  </xs:simpleType>
 
  <xs:simpleType name="DataType">
    <xs:restriction base="xs:string">
      <xs:enumeration value="integer"/>
      <xs:enumeration value="float"/>
      <xs:enumeration value="date"/>
      <xs:enumeration value="datetime"/>
      <xs:enumeration value="time"/>
      <xs:enumeration value="text"/>
      <xs:maxLength value="8"/>
    </xs:restriction>
  </xs:simpleType>
 
  <xs:simpleType name="CLDataType">
    <xs:restriction base="xs:string">
      <xs:enumeration value="integer"/>
      <xs:enumeration value="float"/>
      <xs:enumeration value="text"/>
      <xs:maxLength value="7"/>
    </xs:restriction>
  </xs:simpleType>
 
  <xs:simpleType name="Comparator">
    <xs:restriction base="xs:string">
      <xs:enumeration value="LT"/>
      <xs:enumeration value="LE"/>
      <xs:enumeration value="GT"/>
      <xs:enumeration value="GE"/>
      <xs:enumeration value="EQ"/>
      <xs:enumeration value="NE"/>
      <xs:enumeration value="IN"/>
      <xs:enumeration value="NOTIN"/>
      <xs:maxLength value="5"/>
    </xs:restriction>
  </xs:simpleType>
 
  <xs:simpleType name="SoftOrHard">
    <xs:restriction base="xs:string">
      <xs:enumeration value="Soft"/>
      <xs:enumeration value="Hard"/>
      <xs:maxLength value="4"/>
    </xs:restriction>
  </xs:simpleType>
 
  <xs:simpleType name="TransactionType">
    <xs:restriction base="xs:string">
      <xs:enumeration value="Insert"/>
      <xs:enumeration value="Update"/>
      <xs:enumeration value="Remove"/>
      <xs:enumeration value="Upsert"/>
      <xs:enumeration value="Context"/>
      <xs:maxLength value="7"/>
    </xs:restriction>
  </xs:simpleType>
 
  <xs:simpleType name="UserType">
    <xs:restriction base="xs:string">
      <xs:enumeration value="Sponsor"/>
      <xs:enumeration value="Investigator"/>
      <xs:enumeration value="Lab"/>
      <xs:enumeration value="Other"/>
      <xs:maxLength value="12"/>
    </xs:restriction>
  </xs:simpleType>
 
  <xs:simpleType name="LocationType">
    <xs:restriction base="xs:string">
      <xs:enumeration value="Sponsor"/>
      <xs:enumeration value="Site"/>
      <xs:enumeration value="CRO"/>
      <xs:enumeration value="Lab"/>
      <xs:enumeration value="Other"/>
      <xs:maxLength value="7"/>
    </xs:restriction>
  </xs:simpleType>
 
  <xs:simpleType name="CommentType">
    <xs:restriction base="xs:string">
      <xs:enumeration value="Sponsor"/>
      <xs:enumeration value="Site"/>
      <xs:maxLength value="7"/>
    </xs:restriction>
  </xs:simpleType>
 
  <xs:simpleType name="SignMethod">
    <xs:restriction base="xs:string">
      <xs:enumeration value="Digital"/>
      <xs:enumeration value="Electronic"/>
      <xs:maxLength value="10"/>
    </xs:restriction>
  </xs:simpleType>
 
  <xs:simpleType name="EditPointType">
    <xs:restriction base="xs:string">
      <xs:enumeration value="Monitoring"/>
      <xs:enumeration value="DataManagement"/>
      <xs:enumeration value="DBAudit"/>
      <xs:maxLength value="14"/>
    </xs:restriction>
  </xs:simpleType>
 
  <xs:simpleType name="YesOrNo">
    <xs:restriction base="xs:string">
      <xs:enumeration value="Yes"/>
      <xs:enumeration value="No"/>
      <xs:maxLength value="3"/>
    </xs:restriction>
  </xs:simpleType>
 
  <xs:simpleType name="YesOnly">
    <xs:restriction base="xs:string">
      <xs:enumeration value="Yes"/>
      <xs:maxLength value="3"/>
    </xs:restriction>
  </xs:simpleType>

3   General Elements

3.1   ODM

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 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)

(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.2 should have ODMVersion="1.2".

There is an extended discussion of these attributes in the section titled Single Files and Collections.

XML Schema:

 
  <xs:element name="ODM">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="Study" minOccurs="0" maxOccurs="unbounded"/>
        <xs:element ref="AdminData" minOccurs="0" maxOccurs="unbounded"/>
        <xs:element ref="ReferenceData" minOccurs="0" maxOccurs="unbounded"/>
        <xs:element ref="ClinicalData" minOccurs="0" maxOccurs="unbounded"/>
        <xs:element ref="Association" minOccurs="0" maxOccurs="unbounded"/>
        <xs:element ref="ds:Signature" minOccurs="0" maxOccurs="unbounded"/>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="Description" type="text"/>
      <xs:attribute name="FileType" type="FileType" use="required"/>
      <xs:attribute name="Granularity" type="Granularity"/>
      <xs:attribute name="Archival" type="YesOnly"/>
      <xs:attribute name="FileOID" type="oid" use="required"/>
      <xs:attribute name="CreationDateTime" type="datetime" use="required"/>
      <xs:attribute name="PriorFileOID" type="oidref"/>
      <xs:attribute name="AsOfDateTime" type="datetime"/>
      <xs:attribute name="ODMVersion" type="text"/>
      <xs:attribute name="Originator" type="text"/>
      <xs:attribute name="SourceSystem" type="text"/>
      <xs:attribute name="SourceSystemVersion" type="text"/>
      <xs:attribute name="Id" type="xs:ID"/>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
    <xs:unique name="UC-O-1">
      <xs:selector xpath="Study"/>
      <xs:field xpath="@OID"/>
    </xs:unique>
  </xs:element>

3.2   Study

Body:

 

(GlobalVariables, BasicDefinitions?, MetaDataVersion*)

Attributes:

 

OID

oid

 

 

Contained in:

 

ODM

This element collects static structural information about an individual study.

XML Schema:

 
  <xs:element name="Study">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="GlobalVariables"/>
        <xs:element ref="BasicDefinitions" minOccurs="0" />
        <xs:element ref="MetaDataVersion" minOccurs="0" maxOccurs="unbounded"/>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="OID" type="oid" use="required"/>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
    <xs:unique name="UC-S-1">
      <xs:selector xpath="BasicDefinitions/MeasurementUnit"/>
      <xs:field xpath="@OID"/>
    </xs:unique>
    <xs:unique name="UC-S-2">
      <xs:selector xpath="MetaDataVersion"/>
      <xs:field xpath="@OID"/>
    </xs:unique>
  </xs:element>

3.3   GlobalVariables

Body:

 

(StudyName, StudyDescription, ProtocolName)

Attributes:

 

NONE

Contained in:

 

Study

GlobalVariables includes general summary information about the Study.

XML Schema:

 
  <xs:element name="GlobalVariables">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="StudyName"/>
        <xs:element ref="StudyDescription"/>
        <xs:element ref="ProtocolName"/>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
  </xs:element>

3.4   StudyName

Body:

 

name

Attributes:

 

NONE

Contained in:

 

GlobalVariables

This is a short external name for the study.

XML Schema:

 
  <xs:element name="StudyName">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="name">
          <xs:anyAttribute namespace="##other"/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

3.5   StudyDescription

Body:

 

text

Attributes:

 

NONE

Contained in:

 

GlobalVariables

This is a free-text description of the study.

XML Schema:

 
  <xs:element name="StudyDescription">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="text">
          <xs:anyAttribute namespace="##other"/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

3.6   ProtocolName

Body:

 

name

Attributes:

 

NONE

Contained in:

 

GlobalVariables

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

XML Schema:

 
  <xs:element name="ProtocolName">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="name">
          <xs:anyAttribute namespace="##other"/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

3.7   BasicDefinitions

Body:

 

(MeasurementUnit*)

Attributes:

 

NONE

Contained in:

 

Study

XML Schema:

 
  <xs:element name="BasicDefinitions">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="MeasurementUnit" minOccurs="0" maxOccurs="unbounded"/>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
  </xs:element>

3.8   MeasurementUnit

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 ODM V1.2.

XML Schema:

 
  <xs:element name="MeasurementUnit">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="Symbol"/>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="OID" type="oid" use="required"/>
      <xs:attribute name="Name" type="text" use="required"/>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
  </xs:element>

3.9   Symbol

Body:

 

(TranslatedText+)

Attributes:

 

NONE

Contained in:

 

MeasurementUnit

A human-readable name for a measurement unit.

XML Schema:

 
  <xs:element name="Symbol">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="TranslatedText" maxOccurs="unbounded"/>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
  </xs:element>

3.10   TranslatedText

Body:

 

text

Attributes:

 

xml:lang

languageTag

(optional)

 

Contained in:

 

Decode, ErrorMessage, Question, Symbol

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 (or missing tag) should not occur more than once in a series of TranslatedText elements.

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

XML Schema:

 
  <xs:element name="TranslatedText">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="text">
          <xs:attribute ref="xml:lang"/>
          <xs:anyAttribute namespace="##other"/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

4   Metadata Elements

The metadata for a study is defined in a series of MetaDataVersion elements. Through this mechanism (multiple MetaDataVersion elements), the model supports the incremental deployment of "mid-study changes", and thus can handle a situation where multiple versions of the metadata are being used simultaneously (perhaps due to delays in IRB approval at various sites).

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.

4.1   MetaDataVersion

Body:

 

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

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.

XML Schema:

 
  <xs:element name="MetaDataVersion">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="Include" minOccurs="0"/>
        <xs:element ref="Protocol" minOccurs="0"/>
        <xs:element ref="StudyEventDef" minOccurs="0" maxOccurs="unbounded"/>
        <xs:element ref="FormDef" minOccurs="0" maxOccurs="unbounded"/>
        <xs:element ref="ItemGroupDef" minOccurs="0" maxOccurs="unbounded"/>
        <xs:element ref="ItemDef" minOccurs="0" maxOccurs="unbounded"/>
        <xs:element ref="CodeList" minOccurs="0" maxOccurs="unbounded"/>
        <xs:element ref="ImputationMethod" minOccurs="0" maxOccurs="unbounded"/>
        <xs:element ref="Presentation" minOccurs="0" maxOccurs="unbounded"/>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="OID" type="oid" use="required"/>
      <xs:attribute name="Name" type="name" use="required"/>
      <xs:attribute name="Description" type="text"/>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
    <xs:unique name="UC-MDV-1">
      <xs:selector xpath="StudyEventDef"/>
      <xs:field xpath="@OID"/>
    </xs:unique>
    <xs:unique name="UC-MDV-2">
      <xs:selector xpath="FormDef"/>
      <xs:field xpath="@OID"/>
    </xs:unique>
    <xs:unique name="UC-MDV-3">
      <xs:selector xpath="ItemGroupDef"/>
      <xs:field xpath="@OID"/>
    </xs:unique>
    <xs:unique name="UC-MDV-4">
      <xs:selector xpath="ItemDef"/>
      <xs:field xpath="@OID"/>
    </xs:unique>
    <xs:unique name="UC-MDV-5">
      <xs:selector xpath="CodeList"/>
      <xs:field xpath="@OID"/>
    </xs:unique>
    <xs:unique name="UC-MDV-6">
      <xs:selector xpath="ImputationMethod"/>
      <xs:field xpath="@OID"/>
    </xs:unique>
    <xs:unique name="UC-MDV-7">
      <xs:selector xpath="Presentation"/>
      <xs:field xpath="@OID"/>
    </xs:unique>
  </xs:element>

4.2   Include

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

A reference to a prior metadata version. This version must be present earlier in the same ODM file or in a previous file in the series. See the PriorFileOID attribute of the ODM element.

Note: The StudyOID attribute allows an Include element to reference a metadata version in another study. Thus, it it possible for many studies to share a set of common metadata definitions. In fact, a study that contains nothing but metadata can serve as a metadata library.

Note: By placing this information in a subelement of MetaDataVersion (rather than in attributes) we allow for future evolution of this capability. For example, it might be useful to allow inclusion of two common metadata dictionaries, or to add new common metadata into a previous study-specific metadata version.

XML Schema:

 
  <xs:element name="Include">
    <xs:complexType>
      <xs:sequence>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="StudyOID" type="oidref" use="required"/>
      <xs:attribute name="MetaDataVersionOID" type="oidref" use="required"/>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
  </xs:element>

4.3   Protocol

Body:

 

(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.

XML Schema:

 
  <xs:element name="Protocol">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="StudyEventRef" maxOccurs="unbounded"/>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
    <xs:unique name="UC-P-1">
      <xs:selector xpath="StudyEventRef"/>
      <xs:field xpath="@StudyEventOID"/>
    </xs:unique>
    <xs:unique name="UC-P-2">
      <xs:selector xpath="StudyEventRef"/>
      <xs:field xpath="@OrderNumber"/>
    </xs:unique>
  </xs:element>

4.4   StudyEventRef

Body:

 

EMPTY

Attributes:

 

StudyEventOID

oidref

 

Reference to the StudyEventDef.

 

OrderNumber

integer

(optional)

 

 

Mandatory

(Yes | No)

 

 

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 files that are incomplete in this sense are perfectly legal -- just not sufficient for clinical analysis.

XML Schema:

 
  <xs:element name="StudyEventRef">
    <xs:complexType>
      <xs:sequence>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="StudyEventOID" type="oidref" use="required"/>
      <xs:attribute name="OrderNumber" type="integer"/>
      <xs:attribute name="Mandatory" type="YesOrNo" use="required"/>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
  </xs:element>

4.5   StudyEventDef

Body:

 

(FormRef+)

Attributes:

 

OID

oid

 

 

 

Name

name

 

 

 

Repeating

(Yes | No)

 

 

 

Type

(Scheduled | Unscheduled | Common)

 

 

 

Category

text

(optional)

 

Contained in:

 

MetaDataVersion

A StudyEventDef describes a type of study event that takes place during a study. A scheduled event is one that is expected to occur for each subject as part of the ordinary progress of the study. An unscheduled event is not expected to occur, but may occur as circumstance dictates. Scheduled and unscheduled events typically occur at some particular time. A common event collects data forms, but is not expected to be associated with a particular time.

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.

XML Schema:

 
  <xs:element name="StudyEventDef">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="FormRef" maxOccurs="unbounded"/>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="OID" type="oid" use="required"/>
      <xs:attribute name="Name" type="name" use="required"/>
      <xs:attribute name="Repeating" type="YesOrNo" use="required"/>
      <xs:attribute name="Type" type="EventType" use="required"/>
      <xs:attribute name="Category" type="text"/>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
    <xs:unique name="UC-SED-1">
      <xs:selector xpath="FormRef"/>
      <xs:field xpath="@FormOID"/>
    </xs:unique>
    <xs:unique name="UC-SED-2">
      <xs:selector xpath="FormRef"/>
      <xs:field xpath="@OrderNumber"/>
    </xs:unique>
  </xs:element>

4.6   FormRef

Body:

 

EMPTY

Attributes:

 

FormOID

oidref

 

Reference to the FormDef.

 

OrderNumber

integer

(optional)

 

 

Mandatory

(Yes | No)

 

 

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.

XML Schema:

 
  <xs:element name="FormRef">
    <xs:complexType>
      <xs:sequence>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="FormOID" type="oidref" use="required"/>
      <xs:attribute name="OrderNumber" type="integer"/>
      <xs:attribute name="Mandatory" type="YesOrNo" use="required"/>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
  </xs:element>

4.7   FormDef

Body:

 

(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.

XML Schema:

 
  <xs:element name="FormDef">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="ItemGroupRef" maxOccurs="unbounded"/>
        <xs:element ref="ArchiveLayout" minOccurs="0" maxOccurs="unbounded"/>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="OID" type="oid" use="required"/>
      <xs:attribute name="Name" type="name" use="required"/>
      <xs:attribute name="Repeating" type="YesOrNo" use="required"/>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
    <xs:unique name="UC-FD-1">
      <xs:selector xpath="ItemGroupRef"/>
      <xs:field xpath="@ItemGroupOID"/>
    </xs:unique>
    <xs:unique name="UC-FD-2">
      <xs:selector xpath="ItemGroupRef"/>
      <xs:field xpath="@OrderNumber"/>
    </xs:unique>
    <xs:unique name="UC-FD-3">
      <xs:selector xpath="ArchiveLayout"/>
      <xs:field xpath="@OID"/>
    </xs:unique>
  </xs:element>

4.8   ItemGroupRef

Body:

 

EMPTY

Attributes:

 

ItemGroupOID

oidref

 

Reference to the ItemGroupDef.

 

OrderNumber

integer

(optional)

 

 

Mandatory

(Yes | No)

 

 

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 files that are incomplete in this sense are perfectly legal -- just not sufficient for clinical analysis.

XML Schema:

 
  <xs:element name="ItemGroupRef">
    <xs:complexType>
      <xs:sequence>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="ItemGroupOID" type="oidref" use="required"/>
      <xs:attribute name="OrderNumber" type="integer"/>
      <xs:attribute name="Mandatory" type="YesOrNo" use="required"/>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
  </xs:element>

4.9   ItemGroupDef

Body:

 

(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.

The Domain, Origin, Purpose, and Comment attributes carry submission information as described in the CDISC Submission Metadata Model.

Note: The Role attribute can be considered a synonym for Purpose. New application should use Purpose rather than Role.

XML Schema:

 
  <xs:element name="ItemGroupDef">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="ItemRef" maxOccurs="unbounded"/>
        <xs:element ref="Alias" minOccurs="0" maxOccurs="unbounded"/>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="OID" type="oid" use="required"/>
      <xs:attribute name="Name" type="name" use="required"/>
      <xs:attribute name="Repeating" type="YesOrNo" use="required"/>
      <xs:attribute name="IsReferenceData" type="YesOrNo"/>
      <xs:attribute name="SASDatasetName" type="sasName"/>
      <xs:attribute name="Domain" type="text"/>
      <xs:attribute name="Origin" type="text"/>
      <xs:attribute name="Role" type="name"/>
      <xs:attribute name="Purpose" type="text"/>
      <xs:attribute name="Comment" type="text"/>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
    <xs:unique name="UC-IGD-1">
      <xs:selector xpath="ItemRef"/>
      <xs:field xpath="@ItemOID"/>
    </xs:unique>
    <xs:unique name="UC-IGD-2">
      <xs:selector xpath="ItemRef"/>
      <xs:field xpath="@OrderNumber"/>
    </xs:unique>
  </xs:element>

4.10   ItemRef

Body:

 

EMPTY

Attributes:

 

ItemOID

oidref

 

Reference to the ItemDef.

 

OrderNumber

integer

(optional)

 

 

Mandatory

(Yes | No)

 

 

 

KeySequence

integer

(optional)

 

 

ImputationMethodOID

oidref

(optional)

 

 

Role

NMTOKENS

(optional)

 

 

RoleCodeListOID

oidref

(optional)

 

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 files that are incomplete in this sense are perfectly legal -- just not sufficient for clinical analysis.

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 ImputationMethodOID references an ImputationMethod used to derive the value of this item.

The Role attribute provides a set of role names describing the use of this data item. (NMTOKENS is a list of XML names separated by spaces.)

The RoleCodeListOID references a CodeList of roles from which the Role attribute values are to be taken. This attribute should be present if and only if the Role attribute is.

XML Schema:

 
  <xs:element name="ItemRef">
    <xs:complexType>
      <xs:sequence>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="ItemOID" type="oidref" use="required"/>
      <xs:attribute name="OrderNumber" type="integer"/>
      <xs:attribute name="Mandatory" type="YesOrNo" use="required"/>
      <xs:attribute name="KeySequence" type="integer"/>
      <xs:attribute name="ImputationMethodOID" type="oidref"/>
      <xs:attribute name="Role" type="xs:NMTOKENS"/>
      <xs:attribute name="RoleCodeListOID" type="oidref"/>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
  </xs:element>

4.11   ItemDef

Body:

 

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

Attributes:

 

OID

oid

 

 

 

Name

name

 

 

 

DataType

(integer | float | date | datetime | time | text)

 

 

 

Length

integer

(optional)

 

 

SignificantDigits

integer

(optional)

 

 

SASFieldName

sasName

(optional)

 

 

SDSVarName

sasName

(optional)

 

 

Origin

text

(optional)

 

 

Comment

text

(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 integer, float, or text (and can be ignored for the other datatypes). The SignificantDigits attribute is required when DataType is float (and can be ignored for the other datatypes).

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 10N. 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 10N-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 Unicode characters are allowed in text string values.

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;".

The SDSVarName, Origin, and Comment attributes carry submission information as described in the CDISC Submission Metadata Model.

 

Note: In the ODM model, all internal keys are assumed to be unchangeable. This was done to make the audit trail issues work: if the SubjectKey in the model were the actual external subject identifier (or randomization ID) of a patient, and that value is sent incorrectly in one ODM file, there would be no way to correct the mistake in a followup file. In doing this, we intend that the external subject keys (and other externally visible key variables) should be defined as Items in the metadata. Thus they can be modified through normal modify/audit mechnaism. While this solves the problem of supporting modification of study keys, it leaves the user without a way to identify which ItemDefs have special meaning or what the meaning is. The most obvious place where this is a problem is in matching up patients when loading data from an external source. If you can't find the patient id how do you do the matching?

The answer is to use the SDSVarName attribute of ItemDef. SDSVarName is an optional attribute which can be used to tag the Item with a business meaning. Rather than try to enumerate all possible meanings in the ODM model, the ODM working group thought it best to rely on the set of variable names defined in the Submissions Data Model, since this list covers most core variables used in managing clinical data. Software that is processing an ODM-compliant XML instance can therefore use specific values of the SDSVarName attribute to identify standard, frequently used variables. The use of this attribute is restricted to variables defined in the SDS model. In tagging a variable, you are identifying it as being properly defined by the SDS definition for that variable. A partial list of commonly used values includes:

  • SITEID (Center or Site ID),
  • SUBJID (Subject ID, usually the Randomization ID),
  • SCSUBJID (Screening SubjectID)
  • SEX (Sex or Gender, coded value),
  • VISIT (visit name),
  • DMACTDT (actual date of visit)
  • DMREFDT (subject reference date)
  • BIRTHDT (date of birth),
  • SUBJINIT (subject initials)

See the SDS definition for definitions and additional choices.

The Question element describes the purpose of the item for a human user. The ExternalQuestion element does the same but refers to an externally defined question. If both are present, they should be consistent.

The MeasurementUnitRefs list the acceptable measurement units for this type of item. Only numeric (integer or float) items should have measurement units. If only one MeasurementUnitRef is present, all items of this type carry this measurement unit by default. If no MeasurementUnitRef is present, the item's value is scalar (i.e., a pure number).

The RangeChecks constrain the acceptable values for items of this type.

The CodeListRef (if present) constrains the acceptable values for items of this type to be members of the referenced codelist.

Note: Items do not repeat within an item group.

XML Schema:

 
  <xs:element name="ItemDef">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="Question" minOccurs="0"/>
        <xs:element ref="ExternalQuestion" minOccurs="0"/>
        <xs:element ref="MeasurementUnitRef" minOccurs="0" maxOccurs="unbounded"/>
        <xs:element ref="RangeCheck" minOccurs="0" maxOccurs="unbounded"/>
        <xs:element ref="CodeListRef" minOccurs="0"/>
        <xs:element ref="Role" minOccurs="0" maxOccurs="unbounded"/>
        <xs:element ref="Alias" minOccurs="0" maxOccurs="unbounded"/>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="OID" type="oid" use="required"/>
      <xs:attribute name="Name" type="name" use="required"/>
      <xs:attribute name="DataType" type="DataType" use="required"/>
      <xs:attribute name="Length" type="integer"/>
      <xs:attribute name="SignificantDigits" type="integer"/>
      <xs:attribute name="SASFieldName" type="sasName"/>
      <xs:attribute name="SDSVarName" type="sasName"/>
      <xs:attribute name="Origin" type="text"/>
      <xs:attribute name="Comment" type="text"/>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
  </xs:element>

4.12   Question

Body:

 

(TranslatedText+)

Attributes:

 

NONE

Contained in:

 

ItemDef

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

XML Schema:

 
  <xs:element name="Question">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="TranslatedText" maxOccurs="unbounded"/>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
  </xs:element>

4.13   ExternalQuestion

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.

XML Schema:

 
  <xs:element name="ExternalQuestion">
    <xs:complexType>
      <xs:sequence>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="Dictionary" type="text"/>
      <xs:attribute name="Version" type="text"/>
      <xs:attribute name="Code" type="text"/>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
  </xs:element>

4.14   MeasurementUnitRef

Body:

 

EMPTY

Attributes:

 

MeasurementUnitOID

oidref

 

Reference to the MeasurementUnit definition.

Contained in:

 

ItemData, ItemDef, RangeCheck

A reference to a measurement unit definition.

XML Schema:

 
  <xs:element name="MeasurementUnitRef">
    <xs:complexType>
      <xs:sequence>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="MeasurementUnitOID" type="oidref" use="required"/>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
  </xs:element>

4.15   RangeCheck

Body:

 

(CheckValue+, MeasurementUnitRef?, ErrorMessage?)

Attributes:

 

Comparator

(LT | LE | GT | GE | EQ | NE | IN | NOTIN)

 

Comparison operator used to compare the item and value(s).

 

SoftHard

(Soft | Hard)

 

 

Contained in:

 

ItemDef

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).

The comparators LT, LE, GT, GE, EQ, and NE take exactly one CheckValue. However, the comparators IN and NOTIN take a set of CheckValues.

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.

Example: 2 pounds is less than 1 kilogram.

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

XML Schema:

 
  <xs:element name="RangeCheck">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="CheckValue" maxOccurs="unbounded"/>
        <xs:element ref="MeasurementUnitRef" minOccurs="0"/>
        <xs:element ref="ErrorMessage" minOccurs="0"/>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="Comparator" type="Comparator" use="required"/>
      <xs:attribute name="SoftHard" type="SoftOrHard" use="required"/>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
  </xs:element>

4.16   CheckValue

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.

XML Schema:

 
  <xs:element name="CheckValue">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="value">
          <xs:anyAttribute namespace="##other"/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

4.17   ErrorMessage

Body:

 

(TranslatedText+)

Attributes:

 

NONE

Contained in:

 

RangeCheck

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

XML Schema:

 
  <xs:element name="ErrorMessage">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="TranslatedText" maxOccurs="unbounded"/>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
  </xs:element>

4.18   CodeListRef

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.

XML Schema:

 
  <xs:element name="CodeListRef">
    <xs:complexType>
      <xs:sequence>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="CodeListOID" type="oidref" use="required"/>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
  </xs:element>

4.19   Role

Body:

 

text

Note: This element is deprecated in favor of the Role attribute on the ItemRef element.

XML Schema:

 
  <xs:element name="Role">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="text">
          <xs:anyAttribute namespace="##other"/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

4.20   Alias

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.

XML Schema:

 
  <xs:element name="Alias">
    <xs:complexType>
      <xs:sequence>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="Context" type="text" use="required"/>
      <xs:attribute name="Name" type="text" use="required"/>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
  </xs:element>

4.21   CodeList

Body:

 

(CodeListItem* | ExternalCodeList)

Attributes:

 

OID

oid

 

 

 

Name

name

 

 

 

DataType

(integer | float | text)

 

 

 

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*) 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.

XML Schema:

 
  <xs:element name="CodeList">
    <xs:complexType>
      <xs:sequence>
        <xs:choice>
          <xs:element ref="CodeListItem" minOccurs="0" maxOccurs="unbounded"/>
          <xs:element ref="ExternalCodeList"/>
        </xs:choice>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="OID" type="oid" use="required"/>
      <xs:attribute name="Name" type="name" use="required"/>
      <xs:attribute name="DataType" type="CLDataType" use="required"/>
      <xs:attribute name="SASFormatName" type="sasFormat"/>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
    <xs:unique name="UC-CL-1">
      <xs:selector xpath="CodeListItem"/>
      <xs:field xpath="@CodedValue"/>
    </xs:unique>
  </xs:element>

4.22   CodeListItem

Body:

 

(Decode)

Attributes:

 

CodedValue

value

 

Value of the codelist item (as it would occur in a Value element).

Contained in:

 

CodeList

Defines an individual member value of a codelist. The actual value is given, along with a set of print-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).

XML Schema:

 
  <xs:element name="CodeListItem">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="Decode"/>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="CodedValue" type="value" use="required"/>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
  </xs:element>

4.23   Decode

Body:

 

(TranslatedText+)

Attributes:

 

NONE

Contained in:

 

CodeListItem

The set of print-forms for a codelist value.

XML Schema:

 
  <xs:element name="Decode">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="TranslatedText" maxOccurs="unbounded"/>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
  </xs:element>

4.24   ExternalCodeList

Body:

 

EMPTY

Attributes:

 

Dictionary

text

(optional)

The name of the external codelist.

 

Version

text

(optional)

The version designator of the external codelist.

Contained in:

 

CodeList

A reference to an externally defined codelist.

XML Schema:

 
  <xs:element name="ExternalCodeList">
    <xs:complexType>
      <xs:sequence>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="Dictionary" type="text"/>
      <xs:attribute name="Version" type="text"/>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
  </xs:element>

4.25   ArchiveLayout

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.

XML Schema:

 
  <xs:element name="ArchiveLayout">
    <xs:complexType>
      <xs:sequence>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="OID" type="oid" use="required"/>
      <xs:attribute name="PdfFileName" type="fileName" use="required"/>
      <xs:attribute name="PresentationOID" type="oidref"/>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
  </xs:element>

4.26   ImputationMethod

Body:

 

text

Attributes:

 

OID

oid

 

 

Contained in:

 

MetaDataVersion

An ImputationMethod describes how a data value can be derived from a collection of other data values. It is primarily a comment.

The body of the ImputationMethod expresses this rule in natural language, a formal notation (such as a SQL script), or by other means. The details are up to the creator of the ODM document. ODM 1.2 does not define this further.

XML Schema:

 
  <xs:element name="ImputationMethod">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="text">
          <xs:attribute name="OID" type="oid" use="required"/>
          <xs:anyAttribute namespace="##other"/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

4.27   Presentation

Body:

 

text

Attributes:

 

OID

oid

 

 

 

xml:lang

languageTag

(optional)

 

Contained in:

 

MetaDataVersion

A Presentation defines how information about the study is presented to the user of a system. The xml:lang attribute helps select the appropriate presentation. See TranslatedText.

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

XML Schema:

 
  <xs:element name="Presentation">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="text">
          <xs:attribute name="OID" type="oid" use="required"/>
          <xs:attribute ref="xml:lang"/>
          <xs:anyAttribute namespace="##other"/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

5   Administrative Elements

5.1   AdminData

Body:

 

(User*, Location*, SignatureDef*)

Attributes:

 

StudyOID

oidref

(optional)

Reference to a StudyDef.

Contained in:

 

ODM

Administrative information about users, locations, and electronic signatures.

XML Schema:

 
  <xs:element name="AdminData">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="User" minOccurs="0" maxOccurs="unbounded"/>
        <xs:element ref="Location" minOccurs="0" maxOccurs="unbounded"/>
        <xs:element ref="SignatureDef" minOccurs="0" maxOccurs="unbounded"/>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="StudyOID" type="oidref"/>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
    <xs:unique name="UC-AD-1">
      <xs:selector xpath="User"/>
      <xs:field xpath="@OID"/>
    </xs:unique>
    <xs:unique name="UC-AD-2">
      <xs:selector xpath="Location"/>
      <xs:field xpath="@OID"/>
    </xs:unique>
    <xs:unique name="UC-AD-3">
      <xs:selector xpath="SignatureDef"/>
      <xs:field xpath="@OID"/>
    </xs:unique>
  </xs:element>

5.2   User

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.

XML Schema:

 
  <xs:element name="User">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="LoginName" minOccurs="0"/>
        <xs:element ref="DisplayName" minOccurs="0"/>
        <xs:element ref="FullName" minOccurs="0"/>
        <xs:element ref="FirstName" minOccurs="0"/>
        <xs:element ref="LastName" minOccurs="0"/>
        <xs:element ref="Organization" minOccurs="0"/>
        <xs:element ref="Address" minOccurs="0" maxOccurs="unbounded"/>
        <xs:element ref="Email" minOccurs="0" maxOccurs="unbounded"/>
        <xs:element ref="Picture" minOccurs="0"/>
        <xs:element ref="Pager" minOccurs="0"/>
        <xs:element ref="Fax" minOccurs="0" maxOccurs="unbounded"/>
        <xs:element ref="Phone" minOccurs="0" maxOccurs="unbounded"/>
        <xs:element ref="LocationRef" minOccurs="0" maxOccurs="unbounded"/>
        <xs:element ref="Certificate" minOccurs="0" maxOccurs="unbounded"/>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="OID" type="oid" use="required"/>
      <xs:attribute name="UserType" type="UserType"/>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
  </xs:element>

5.3   LoginName

Body:

 

text

Attributes:

 

NONE

Contained in:

 

User

The user's login identification.

XML Schema:

 
  <xs:element name="LoginName">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="text">
          <xs:anyAttribute namespace="##other"/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

5.4   DisplayName

Body:

 

text

Attributes:

 

NONE

Contained in:

 

User

A short displayable name for the user.

XML Schema:

 
  <xs:element name="DisplayName">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="text">
          <xs:anyAttribute namespace="##other"/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

5.5   FullName

Body:

 

text

Attributes:

 

NONE

Contained in:

 

User

The user's full formal name.

XML Schema:

 
  <xs:element name="FullName">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="text">
          <xs:anyAttribute namespace="##other"/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

5.6   FirstName

Body:

 

text

Attributes:

 

NONE

Contained in:

 

User

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

XML Schema:

 
  <xs:element name="FirstName">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="text">
          <xs:anyAttribute namespace="##other"/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

5.7   LastName

Body:

 

text

Attributes:

 

NONE

Contained in:

 

User

The user's surname (family name).

XML Schema:

 
  <xs:element name="LastName">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="text">
          <xs:anyAttribute namespace="##other"/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

5.8   Organization

Body:

 

text

Attributes:

 

NONE

Contained in:

 

User

The user's organization.

XML Schema:

 
  <xs:element name="Organization">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="text">
          <xs:anyAttribute namespace="##other"/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

5.9   Address

Body:

 

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

Attributes:

 

NONE

Contained in:

 

User

The user's postal address.

XML Schema:

 
  <xs:element name="Address">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="StreetName" minOccurs="0" maxOccurs="unbounded"/>
        <xs:element ref="City" minOccurs="0"/>
        <xs:element ref="StateProv" minOccurs="0"/>
        <xs:element ref="Country" minOccurs="0"/>
        <xs:element ref="PostalCode" minOccurs="0"/>
        <xs:element ref="OtherText" minOccurs="0"/>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
  </xs:element>

5.10   StreetName

Body:

 

text

Attributes:

 

NONE

Contained in:

 

Address

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

XML Schema:

 
  <xs:element name="StreetName">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="text">
          <xs:anyAttribute namespace="##other"/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

5.11   City

Body:

 

text

Attributes:

 

NONE

Contained in:

 

Address

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

XML Schema:

 
  <xs:element name="City">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="text">
          <xs:anyAttribute namespace="##other"/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

5.12   StateProv

Body:

 

text

Attributes:

 

NONE

Contained in:

 

Address

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

XML Schema:

 
  <xs:element name="StateProv">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="text">
          <xs:anyAttribute namespace="##other"/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

5.13   Country

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.

XML Schema:

 
  <xs:element name="Country">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="text">
          <xs:anyAttribute namespace="##other"/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

5.14   PostalCode

Body:

 

text

Attributes:

 

NONE

Contained in:

 

Address

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

XML Schema:

 
  <xs:element name="PostalCode">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="text">
          <xs:anyAttribute namespace="##other"/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

5.15   OtherText

Body:

 

text

Attributes:

 

NONE

Contained in:

 

Address

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

XML Schema:

 
  <xs:element name="OtherText">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="text">
          <xs:anyAttribute namespace="##other"/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

5.16   Email

Body:

 

text

Attributes:

 

NONE

Contained in:

 

User

The user's email address.

XML Schema:

 
  <xs:element name="Email">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="text">
          <xs:anyAttribute namespace="##other"/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

5.17   Picture

Body:

 

EMPTY

Attributes:

 

PictureFileName

fileName

 

 

 

ImageType

name

(optional)

 

Contained in:

 

User

A visual depiction of the user.

XML Schema:

 
  <xs:element name="Picture">
    <xs:complexType>
      <xs:sequence>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="PictureFileName" type="fileName" use="required"/>
      <xs:attribute name="ImageType" type="name"/>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
  </xs:element>

5.18   Pager

Body:

 

text

Attributes:

 

NONE

Contained in:

 

User

The phone number of the user's pager.

XML Schema:

 
  <xs:element name="Pager">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="text">
          <xs:anyAttribute namespace="##other"/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

5.19   Fax

Body:

 

text

Attributes:

 

NONE

Contained in:

 

User

The phone number of the user's facsimile machine.

XML Schema:

 
  <xs:element name="Fax">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="text">
          <xs:anyAttribute namespace="##other"/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

5.20   Phone

Body:

 

text

Attributes:

 

NONE

Contained in:

 

User

The user's voice phone number.

XML Schema:

 
  <xs:element name="Phone">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="text">
          <xs:anyAttribute namespace="##other"/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

5.21   LocationRef

Body:

 

EMPTY

Attributes:

 

LocationOID

oidref

 

Reference to a Location definition.

Contained in:

 

AuditRecord, Signature, User

A reference to the user's physical location.

XML Schema:

 
  <xs:element name="LocationRef">
    <xs:complexType>
      <xs:sequence>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="LocationOID" type="oidref" use="required"/>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
  </xs:element>

5.22   Certificate

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.2. It is a placeholder for future development.

XML Schema:

 
  <xs:element name="Certificate">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="text">
          <xs:anyAttribute namespace="##other"/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

5.23   Location

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.

XML Schema:

 
  <xs:element name="Location">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="MetaDataVersionRef" maxOccurs="unbounded"/>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="OID" type="oid" use="required"/>
      <xs:attribute name="Name" type="name" use="required"/>
      <xs:attribute name="LocationType" type="LocationType"/>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
  </xs:element>

5.24   MetaDataVersionRef

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.

XML Schema:

 
  <xs:element name="MetaDataVersionRef">
    <xs:complexType>
      <xs:sequence>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="StudyOID" type="oidref" use="required"/>
      <xs:attribute name="MetaDataVersionOID" type="oidref" use="required"/>
      <xs:attribute name="EffectiveDate" type="date" use="required"/>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
  </xs:element>

5.25   SignatureDef

Body:

 

(Meaning, LegalReason)

Attributes:

 

OID

oid

 

 

 

Methodology

(Digital | Electronic)

(optional)

 

Contained in:

 

AdminData

Defines a kind of electronic signature, including the meaning as required by 21 CFR Part 11. If the signature is Digital, it is based on cryptography. Otherwise the signature is Electronic.

Note: Tracking of data edits is done using AuditRecords not signatures.

XML Schema:

 
  <xs:element name="SignatureDef">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="Meaning"/>
        <xs:element ref="LegalReason"/>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="OID" type="oid" use="required"/>
      <xs:attribute name="Methodology" type="SignMethod"/>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
  </xs:element>

5.26   Meaning

Body:

 

text

Attributes:

 

NONE

Contained in:

 

SignatureDef

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

XML Schema:

 
  <xs:element name="Meaning">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="text">
          <xs:anyAttribute namespace="##other"/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

5.27   LegalReason

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.").

XML Schema:

 
  <xs:element name="LegalReason">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="text">
          <xs:anyAttribute namespace="##other"/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

6   Reference Data Elements

6.1   ReferenceData

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) occuring 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.

XML Schema:

 
  <xs:element name="ReferenceData">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="ItemGroupData" minOccurs="0" maxOccurs="unbounded"/>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="StudyOID" type="oidref" use="required"/>
      <xs:attribute name="MetaDataVersionOID" type="oidref" use="required"/>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
  </xs:element>

7   Clinical Data Elements

7.1   ClinicalData

Body:

 

(SubjectData*)

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) occuring within this ClinicalData element refer to definitions within the selected metadata version.

XML Schema:

 
  <xs:element name="ClinicalData">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="SubjectData" minOccurs="0" maxOccurs="unbounded"/>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="StudyOID" type="oidref" use="required"/>
      <xs:attribute name="MetaDataVersionOID" type="oidref" use="required"/>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
  </xs:element>

7.2   SubjectData

Body:

 

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

Attributes:

 

SubjectKey

subjectKey

 

 

 

TransactionType

(Insert | Update | Remove | Upsert | Context)

(optional)

 

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.

Note: Subject attributes (such as date of birth, sex, responsible investigator, and so on) should be treated as if they were clinical data. Thus they can be changed as needed, and are subject to normal auditing processes.

XML Schema:

 
  <xs:element name="SubjectData">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="AuditRecord" minOccurs="0"/>
        <xs:element ref="Signature" minOccurs="0"/>
        <xs:element ref="InvestigatorRef" minOccurs="0"/>
        <xs:element ref="SiteRef" minOccurs="0"/>
        <xs:element ref="Annotation" minOccurs="0" maxOccurs="unbounded"/>
        <xs:element ref="StudyEventData" minOccurs="0" maxOccurs="unbounded"/>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="SubjectKey" type="subjectKey" use="required"/>
      <xs:attribute name="TransactionType" type="TransactionType"/>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
  </xs:element>

7.3   StudyEventData

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)

 

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.

XML Schema:

 
  <xs:element name="StudyEventData">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="AuditRecord" minOccurs="0"/>
        <xs:element ref="Signature" minOccurs="0"/>
        <xs:element ref="Annotation" minOccurs="0" maxOccurs="unbounded"/>
        <xs:element ref="FormData" minOccurs="0" maxOccurs="unbounded"/>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="StudyEventOID" type="oidref" use="required"/>
      <xs:attribute name="StudyEventRepeatKey" type="repeatKey"/>
      <xs:attribute name="TransactionType" type="TransactionType"/>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
  </xs:element>

7.4   FormData

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)

 

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.

XML Schema:

 
  <xs:element name="FormData">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="AuditRecord" minOccurs="0"/>
        <xs:element ref="Signature" minOccurs="0"/>
        <xs:element ref="ArchiveLayoutRef" minOccurs="0"/>
        <xs:element ref="Annotation" minOccurs="0" maxOccurs="unbounded"/>
        <xs:element ref="ItemGroupData" minOccurs="0" maxOccurs="unbounded"/>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="FormOID" type="oidref" use="required"/>
      <xs:attribute name="FormRepeatKey" type="repeatKey"/>
      <xs:attribute name="TransactionType" type="TransactionType"/>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
  </xs:element>

7.5   ArchiveLayoutRef

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.

XML Schema:

 
  <xs:element name="ArchiveLayoutRef">
    <xs:complexType>
      <xs:sequence>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="ArchiveLayoutOID" type="oidref" use="required"/>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
  </xs:element>

7.6   ItemGroupData

Body:

 

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

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)

 

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.

XML Schema:

 
  <xs:element name="ItemGroupData">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="AuditRecord" minOccurs="0"/>
        <xs:element ref="Signature" minOccurs="0"/>
        <xs:element ref="Annotation" minOccurs="0" maxOccurs="unbounded"/>
        <xs:element ref="ItemData" minOccurs="0" maxOccurs="unbounded"/>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="ItemGroupOID" type="oidref" use="required"/>
      <xs:attribute name="ItemGroupRepeatKey" type="repeatKey"/>
      <xs:attribute name="TransactionType" type="TransactionType"/>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
  </xs:element>

7.7   ItemData

Body:

 

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

Attributes:

 

ItemOID

oidref

 

Reference to the ItemDef.

 

TransactionType

(Insert | Update | Remove | Upsert | Context)

(optional)

 

 

Value

text

(optional)

The data collected for an item. This data is represented according to DataType attribute of the ItemDef.

 

IsNull

(Yes)

(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 neither Value nor IsNull is set, 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

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).

The referenced ItemDef defines the DataType of this item (integer, float, date, datetime, time, or text). The Value attribute string must obey the rules for that format of data listed in the Data Formats section. For the integer, float, and text datatypes, the item value must be storable within the Length and SignificantDigits constraints defined in the ItemDef. (Rounding is permitted for float values.)

XML Schema:

 
  <xs:element name="ItemData">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="AuditRecord" minOccurs="0"/>
        <xs:element ref="Signature" minOccurs="0"/>
        <xs:element ref="MeasurementUnitRef" minOccurs="0"/>
        <xs:element ref="Annotation" minOccurs="0" maxOccurs="unbounded"/>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="ItemOID" type="oidref" use="required"/>
      <xs:attribute name="TransactionType" type="TransactionType"/>
      <xs:attribute name="Value" type="value"/>
      <xs:attribute name="IsNull" type="YesOnly"/>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
  </xs:element>

7.8   Annotation

Body:

 

(Comment?, Flag*)

Attributes:

 

SeqNum

integer

 

 

 

TransactionType

(Insert | Update | Remove | Upsert | Context)

(optional)

 

Contained in:

 

Association, FormData, ItemData, ItemGroupData, StudyEventData, SubjectData

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.

XML Schema:

 
  <xs:element name="Annotation">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="Comment" minOccurs="0"/>
        <xs:element ref="Flag" minOccurs="0" maxOccurs="unbounded"/>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="SeqNum" type="integer" use="required"/>
      <xs:attribute name="TransactionType" type="TransactionType"/>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
  </xs:element>

7.9   Comment

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.

XML Schema:

 
  <xs:element name="Comment">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="text">
          <xs:attribute name="SponsorOrSite" type="CommentType"/>
          <xs:anyAttribute namespace="##other"/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

7.10   Flag

Body:

 

(FlagValue, FlagType?)

Attributes:

 

NONE

Contained in:

 

Annotation

A machine-processable annotation on clinical data.

XML Schema:

 
  <xs:element name="Flag">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="FlagValue"/>
        <xs:element ref="FlagType" minOccurs="0"/>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
  </xs:element>

7.11   FlagValue

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.

XML Schema:

 
  <xs:element name="FlagValue">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="text">
          <xs:attribute name="CodeListOID" type="oidref" use="required"/>
          <xs:anyAttribute namespace="##other"/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

7.12   FlagType

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.

XML Schema:

 
  <xs:element name="FlagType">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="name">
          <xs:attribute name="CodeListOID" type="oidref" use="required"/>
          <xs:anyAttribute namespace="##other"/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

7.13   Signature

Body:

 

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

Attributes:

 

NONE

Contained in:

 

FormData, ItemData, ItemGroupData, StudyEventData, SubjectData

An electronic signature applies to a collection of clinical data. This indicates that some user accepts legal responsibility for that data. See 21 CRF Part 11. The signature identifies the person signing, the location of signing, the signature meaning (via the referenced SignatureDef), the date and time of signing, and (in the case of a digital signature) an encrypted hash of the included data.

An electronic signature applies to the entity to which it is attached (typically a form). The signature covers all clinical data in that entity at the time of the signing, including all clinical data in any subentities. Thus, a signature on a form includes all clinical data at the form, item group, and item levels.

For the purpose of this definition, clinical data includes all attributes and element content except for TransactionType attributes, Signature elements, and AuditRecord elements.

Note: Signatures apply to data at a particular point in time. Signatures cannot be modified. However, new signatures can be applied when clinical data changes.

Note: Signatures apply to the entire content of the entity, not just the content that is mentioned in the current ODM element. Signatures apply to (static) content, not to a change in content.

Note: The practice of initialing and dating changes on paper forms is a way of maintaining an audit trail. It should not be confused with 21 CFR Part 11 electronic signatures (Signature elements).

Note: Contrast with AuditRecord, and ds:Signature.

XML Schema:

 
  <xs:element name="Signature">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="UserRef"/>
        <xs:element ref="LocationRef"/>
        <xs:element ref="SignatureRef"/>
        <xs:element ref="DateTimeStamp"/>
        <xs:element ref="CryptoBindingManifest" minOccurs="0"/>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
  </xs:element>

7.14   UserRef

Body:

 

EMPTY

Attributes:

 

UserOID

oidref

 

Reference to the User definition.

Contained in:

 

AuditRecord, Signature

XML Schema:

 
  <xs:element name="UserRef">
    <xs:complexType>
      <xs:sequence>
        <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="UserOID" type="oidref" use="required"/>
      <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
  </xs:element>

7.15   SignatureRef

Body:

 

EMPTY

Attributes:

 

SignatureOID

oidref

 

Reference to the SignatureDef.

Contained in: