Copyright © CDISC 2002. 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/odm1-1-0.html.
The Operational Data Model (ODM) provides a format for representing the study metadata, study data and administrative data associated with a clinical trial. It represents only the data that would be transferred among different software systems during a trial, or archived after a trial. It need not represent any information internal to a single system, for example, information about how the data would be stored in a particular database.
An attempt has been made to make the format system-neutral. We have therefore attempted to avoid terminology that might be perceived as associated with a single system. Some of the terms in the model might therefore seem unfamiliar, and will be explained as various parts of the model are presented.
Clinical data management systems vary significantly in the information they store and the rules they enforce. If the ODM model were restricted to only those features common to all clinical systems, the resulting model would be close to useless. The capabilities of the most primitive known Clinical Data Management System (CDMS) would limit all other systems. For example,
Version 1.1 of the ODM model explicitly does not address the following issues:
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 non-normative text is segregated into paragraphs or sections prominently marked as Commentary, a Note, or an Example.
An XML file conforms to this standard only if it satisfies all the criteria detailed in this standard. These criteria include both syntactic constraints and semantic ones.
The syntactic constraints are
Example:
|
<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE ODM SYSTEM "http://www.cdisc.org/dtd/odm1-1-0.dtd"> <ODM ...> ... </ODM> |
The semantic constraints are expressed throughout the rest of this document.
Accompanying this standard is an automatically generated DTD file which expresses certain of the syntactic constraints. This DTD 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.
A computing system that processes information in ODM format can claim conformance to this standard only if it obeys the following rules.
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
Vendor extensions should never be used for information that can be expressed using other ODM elements.
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.
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.
An annotation is a comment applied to a subject, study event, form, item group, or item.
The metadata of a study describes the types of study events, forms, item groups, and items that are allowed in the study. Each StudyEventDef describes a particular type of study event (mostly by listing the types of forms it can contain). Each FormDef describes a particular type of form, each ItemGroupDef describes a particular type of item group, and each 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.
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 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 occurs when a series of updates are being applied to a single entity, or when an audit trail is being represented.
Many ODM elements have OID attributes. OID attribute values are used (by other elements) to reference the original elements. This is particularly true of metadata elements.
All OID attribute values must be unique within some set of elements, either within a single ODM file, or within a series of ODM files. The following table describes these uniqueness requirements.
| Element with OID | Scope of Uniqueness | ||
| Study | within a series of files | ||
| User | within a series of files | ||
| Location | within a series of files | ||
| SignatureDef | within a series of files | ||
| MeasurementUnit | within the containing Study | ||
| MetaDataVersion | within the containing Study | ||
| StudyEventDef | within the containing MetaDataVersion | ||
| FormDef | within the containing MetaDataVersion | ||
| ItemGroupDef | within the containing MetaDataVersion | ||
| ItemDef | within the containing MetaDataVersion | ||
| CodeList | within the containing MetaDataVersion | ||
| Presentation | within the containing MetaDataVersion | ||
| ArchiveLayout | within the containing FormDef |
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 IDs, and repeat keys.
To fully identify a clinical data entity, the following internal keys are needed:
| Kind of Entity | Identifying Keys | ||
| study | StudyID | ||
| 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 ItemID | ||
| annotation | keys for the annotated entity plus SeqNum |
External keys are those 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.
Each ODM document is a set of instructions telling how to modify a target database so that it can be brought into alignment with a source database. Most individual ODM documents will contain only part of the total current plus historical information held in the source database.
The information that is sent in a given document can vary in several dimensions. Some examples of the contents of a document are:
The AsOfDateTime provide information that anchors the document in the source database's life history, and PriorFileOID gives a mechanism for ensuring that a sequence of documents that include dependencies is complete and in order (see FileOIDs and Filenames for a discussion of ways in which you can identify a file, given its FileOID). The attributes FileType and Granularity allow the document sender to define the scope, across time and data, respectively, 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 atttributes in describing the document. This section details the values these attribute can take, and discusses the use of the values in a single document and in a series of documents.
Note: Any ODM-compliant transmission can describe one or more studies. To simplify the discussion in this section, we will assume that the transmission only describes one study. If your transmission describes multiple studies, apply the rules discussed here in turn to each of the studies included in the transmission.
A stream of documents is a series of documents where the PriorFileOID links each document to its predecessor. A document with PriorFileOID set to the null string ("") is the initiator of a stream. Data sent in one file in a stream is allowed to depend on definitions, and earlier transactions about the data, that were send in an earlier file in the stream. 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 predecessor file in the stream that contains these definitions. Similarly, if a file contains ClinicalData (regardless of granularity), the file must either contain the admin data referenced in the audit/signature records, or there must be a predecessor in the stream that contain these definitions.
Filetype
A document's FileType must be either Snapshot or Transactional.
A Snapshot 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.
| All | Can contain any or all data & metadata types |
| MetadataOnly | Only metadata or metadata changes |
| AdminData | Contains admin data and may also contain metadata |
| ReferenceData | Contains reference data. Does not contain clinical data |
| ClinicalData | Contains clinical data. Does not contain reference data |
| ClinicalData_IndivSite | Contains clinical data for a single site.Does not contain reference data |
| ClinicalData_IndivSubj | Contains clinical data for an individual subject. Does not contain reference data |
Archival
The ODM attribute Archival is optional. If you set it for a document, its
value must be "Yes". Here is how Archival=Yes is interpreted.
The intent of this attribute is to indicate that the file is intended to meet
the requirements of an electronic record as defined in 21 CFR 11. More
generally, the file (or set of files) must clearly establish a complete and
non-redundant set of entries, updates or deletes (transactions) to data values,
where each transaction is associated with signature information and any changes
or deletions are marked with a reason for change.
Specifications (assertions) for the case when Archival=Yes.
Under ODM, the definition of an entity and an instance of its use are tied together by unique identification numbers. For instance, when you define an ItemDef in an ODM transmission, you are required to provide a value for its identifier attribute (OID) that is unique with respect to all other ItemDefs in the study . Then, when you send a transmission concerning a particular ItemData instance, you refer back to the item's definition by setting the ItemData's identifer reference attribute (ItemOID) value to that of the corresponding ItemDef. Definitions occur in the Admin and Study elements (these are the elements included in Metadata transmissions). References occur within all of the base elements of an ODM document: Admin, Study, ReferenceData, and ClinicalData.
ODM permits you to place the definition in one document within a stream, and a reference to the definition in a subsequent document. (This, incidentally, is why identifier and reference attributes have the XML attribute value of CDATA rather than ID and IDREF; XML supports ID and IDREF only within a single XML document. To highlight this, ODM identifier attributes use the string OID instead of ID). A benefit of this is that you do not have to include all of the metadata in each transmission of data. The cost is that you cannot depend on the XML parser to detect that an IDREF does not have a corresponding ID within a given transaction. Therefore the sender must follow (and recipient should check against) these rules:
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 stream.Here are some corollaries to these rules: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.
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" does not imply that all record of the data entity is expunged, just that the data entity is not visible through the ODM model.
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 the top level data element (SubjectData) 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.
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 occured 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.
Note: this section discusses a recommendation, rather than a normative requirement.
In a linked series of ODM files, each file identifies itself uniquely (in the root ODM element) with its FileOID attribute, and the file points to its predecessor through its PriorFileOID attribute, which names the FileOID of its predecessor. There is no necessary connection between the FileOID and filename. However, defining a mapping between them can make it easier to locate a file's predecessors. For example, suppose you have received two files, named a.xml and b.xml, and a.xml has FileOID=1, and b.xml has FileOID=2, and PriorFileOID=1. Knowing b.xml's PriorFileOID does not tell you what file to look in to access the predecessor document. If, on the other hand, you adopted a convention that filename is the same as FileOID, then looking up predecessors becomes easier.
Each XML element is defined as follows:
Element-NameBody:
Attributes:
|
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)".
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 datatype, and the intended use of the value. The ODM data formats are
| Format Name | XML Datatype | Allowed String Pattern | |
| integer | CDATA | -?digit+ | |
| float | CDATA | -?digit+(.digit+)? | |
| date | CDATA | YYYY-MM-DD | |
| time | CDATA | hh:mm:ss(.nnn)? | |
| datetime | CDATA | YYYY-MM-DD T hh:mm:ss(.nnn)? (+|-)hh:mm | |
| text | CDATA | any sequence of characters | |
| id | CDATA | any sequence of characters | |
| idref | CDATA | any sequence of characters | |
| oid | CDATA | any sequence of characters | |
| oidref | CDATA | any sequence of characters | |
| value | CDATA | any of the above | |
| subjectKey | CDATA | any sequence of characters | |
| repeatKey | CDATA | any sequence of characters | |
| name | CDATA | any sequence of characters | |
| sasName | CDATA | ( letter | digit | _ )+ | |
| fileName | CDATA | ( letter | digit | _ | . )+ | |
| languageTag | CDATA | LL (-CC)* (see below) |
Numbers (integer and float) are represented in base 10. Floats are allowed to have fractional parts.
A text value is any sequence of Unicode characters. When embedded in ODM files, text strings must be represented using 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.
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 milliseconds.
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 (or -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 special offset of -99:99 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 except for the use of the -99:99 offset.
An id or idref can be 1 to 100 characters long. An OID is a string that uniquely identifies an element within an ODM file. Metadata elements must have ids unique within their MetaDataVersion. The term "idref" denotes the use of an OID to reference an element (as opposed to the defining occurrence of that id).
The value format is simply the union of all the preceding formats: integer, float, date, time, datetime, text, id, idref. 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 can be 1 to 100 characters long.
A name is intended to be a human readable name for some entity. Names can be 1 to 100 characters long.
A sasName is any valid SAS Version 5 name. SAS names cannot start with a digit, and are 1 to 8 characters long.
A fileName can be 1 to 100 characters long. File names are system dependent, and expressed relative to the directory that contains the ODM file being processed.
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.
Body:
| (Study*, AdminData*, ReferenceData*, ClinicalData*) |
Attributes:
| Description | CDATA | (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
ODM Document Attributes 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. This is pointed to by the file's successor in a stream. | ||
| CreationDateTime | datetime | Time of creation of the file containing the document. | ||
| PriorFileOID | oidref | (optional) | Reference to the previous file in a stream. | |
| AsOfDateTime | datetime | (optional) | The date/time at which the source database was queried in order to create this document. |
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.
There is an extended discussion of these attributes in the section titled ODM Document Attributes.
Editor's note:The ODM team is considering candidate UID standards for TransferIDs (and possibly Study IDs).
Body:
| (GlobalVariables, BasicDefinitions, MetaDataVersion*) |
Attributes:
| OID | oid |
Contained in:
| ODM |
This element collects static structural information about an individual study.
Body:
| (StudyName, StudyDescription, ProtocolName) |
Attributes:
| NONE |
Contained in:
| Study |
GlobalVariables includes general summary information about the Study.
Body:
| name |
Attributes:
| NONE |
Contained in:
| GlobalVariables |
This is a short external name for the study.
Body:
| text |
Attributes:
| NONE |
Contained in:
| GlobalVariables |
This is a free-text description of the study.
Body:
| name |
Attributes:
| NONE |
Contained in:
| GlobalVariables |
This is the sponsor's internal name for the protocol.
Body:
| (MeasurementUnit*) |
Attributes:
| NONE |
Contained in:
| Study |
Body:
| (Symbol) |
Attributes:
| OID | oid | |||
| Name | text |
Contained in:
| BasicDefinitions |
The physical unit of measure for a data item or value. The meaning of a MeasurementUnit is determined by its Name attribute. Examples include kilograms, centimeters, cells/milliliter, etc.
Note: Standardizing the names of measurement units is beyond the scope of ODM V1.1.
Body:
| (TranslatedText+) |
Attributes:
| NONE |
Contained in:
| MeasurementUnit |
A human-readable name for a measurement unit.
Body:
| text |
Attributes:
| xml:lang | languageTag |
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. If even the tag "" does not match, no TranslatedText is available for the target language.
To avoid ambiguity, a particular language tag should not occur more than once in a series of TranslatedText elements.
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 a explicit reference. The same metadata elements in different versions will have the same ID. This approach is used to allow the older versions of the metadata to remain intact, while simultaneously providing a concise way to represent changes.
Body:
| (Include?, Protocol?, StudyEventDef*, FormDef*, ItemGroupDef*, ItemDef*, CodeList*, Presentation*) |
Attributes:
| OID | oid | |||
| Name | name |
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 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 ID) in the new metadata version. New definitions (with new IDs) can be added in the same way.
Note: The current metadata model does not include any scheduling information such as the time ordering of events, the spacing of events, conditional occurrence of events, and so on. The analogous information for forms is also not included. Future versions of this standard will probably provide such information.
Body:
| EMPTY |
Attributes:
| StudyOID | oidref | References the Study that provides a prior metadata version. | ||
| MetaDataVersionOID | oidref | References the prior MetaDataVersion (within the above Study). |
Contained in:
| MetaDataVersion |
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.
Editor's 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.
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.
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 StudyEventIDs 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.
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.
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 FormIDs 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.
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.
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 ItemGroupIDs 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.
Body:
| (ItemRef+) |
Attributes:
| OID | oid | |||
| Name | name | |||
| Repeating | (Yes | No) | |||
| IsReferenceData | (Yes | No) | (optional) | ||
| SASDatasetName | sasName | (optional) | ||
| Domain | text | (optional) | ||
| Origin | text | (optional) | ||
| Role | name | (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.
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, Role, and Comment attributes carry submission information as described in the CDISC Submission Metadata Model.
Body:
| EMPTY |
Attributes:
| ItemOID | oidref | Reference to the ItemDef. | ||
| OrderNumber | integer | (optional) | ||
| Mandatory | (Yes | No) |
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 ItemIDs 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.
Body:
| (Question?, ExternalQuestion?, MeasurementUnitRef*, RangeCheck*, CodeListRef?, Role*) |
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 "<".
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 "Æ".
The Origin, Role, and Comment attributes carry submission information as described in the CDISC Submission Metadata Model.
Note: SDSVarName attribute
In ODM 1.1 we define all OID values (such as SubjectID) as specifically being internal, unchangeable values. This was done to make the audit trail issues work: if the SubjectOID in the model were the actual external subject identifier (or randomization ID) of a patient and that value is sent incorrectly in one transmission, there would be no way to correct the mistake in a followup transition. In doing this we intend that the external subject keys (and other study key variables) should be defined as Items in the metadata and then can be modified through the ODM audit trail. While this solves the problem of supporting modifications of study keys, it left you 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 it?
The answer is to use the SDSVarname attribute of ItemDef. SDSVarName is an optional attribute of an Item Definition which you can use 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 (version 2.0), since this list covers most core variables used in managing clinical data. Software that is processing an ODM-compliant XML instance can therefore check for specific values of the SDSVarName variable to search for standard, frequently used variables. The use of this attribute is restricted to a variable defined in the SDS V2.0 model, and in tagging a variable, you are identifying it as being properly defined by the SDS V2.0 definition for that variable. A partial list of commonly used values includes:
See the SDS V2.0 definition for definitions and additional choices.
Note: 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.
Body:
| (TranslatedText+) |
Attributes:
| NONE |
Contained in:
| ItemDef |
A human-readable label used to name an item on paper or on a screen.
Body:
| EMPTY |
Attributes:
| Dictionary | text | (optional) | The name of the external question dictionary. | |
| Version | text | (optional) | The version designator of the external question dictionary. | |
| Code | text | (optional) | A code selecting the particular question within the external dictionary. |
Contained in:
| ItemDef |
A reference to an externally defined question.
Body:
| EMPTY |
Attributes:
| MeasurementUnitOID | oidref | Reference to the MeasurementUnit definition. |
Contained in:
| ItemData, ItemDef, RangeCheck |
A reference to a measurement unit definition.
Body:
| (CheckValue+, 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).
Body:
| value |
Attributes:
| NONE |
Contained in:
| RangeCheck |
A comparison value used in a range check.
Body:
| (TranslatedText+) |
Attributes:
| NONE |
Contained in:
| RangeCheck |
Error message to be used when a range check is violated.
Body:
| EMPTY |
Attributes:
| CodeListOID | oidref | Reference to the CodeList definition. |
Contained in:
| ItemDef |
A reference to a CodeList definition
Body:
| (#PCDATA) |
See above discussion of SDS roles. An ItemDef can be tagged with multiple roles (unlike an ItemGroupDef that can only be tagged with one).
Body:
| (CodeListItem* | ExternalCodeList) |
Attributes:
| OID | oid | |||
| Name | name | |||
| DataType | (integer | float | text) | |||
| SASFormatName | sasName | (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 SASFormatName must be a legal SAS Version 5 format name.
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).
Body:
| (TranslatedText+) |
Attributes:
| NONE |
Contained in:
| CodeListItem |
The set of print-forms for a codelist value.
Body:
| EMPTY |
Attributes:
| Dictionary | text | (optional) | The name of the external codelist. | |
| Version | text | (optional) | The version designator of the external codelist. |
Contained in:
| CodeList |
A reference to an externally defined codelist.
Body:
| EMPTY |
Attributes:
| OID | oid | |||
| PdfFileName | fileName | Name of a Adobe PDF file containing the screen layout. | ||
| PresentationOID | oidref | (optional) | Reference to a Presentation definition. |
Contained in:
| FormDef |
A visual image of the screen layout used to collect the data on a form. Useful in archiving a study.
Body:
| 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.1. It is a placeholder for future development.
Body:
| (User*, Location*, SignatureDef*) |
Attributes:
| StudyOID | oidref | (optional) | Reference to a StudyDef. |
Contained in:
| ODM |
Administrative information about users, locations, and electronic signatures.
Body:
| (LoginName?, DisplayName?, FullName?, FirstName?, LastName?, Organization?, Address*, Email*, Picture?, Pager?, Fax*, Phone*, LocationRef*, Certificate*) |
Attributes:
| OID | oid | |||
| UserType | (Sponsor | Investigator | Lab | Other) | (optional) |
Contained in:
| AdminData |
Information about a specific user of a clinical data collection system. This may be an investigator, a CRA, or data management staff. Study subjects are not users in this sense.
Body:
| text |
Attributes:
| NONE |
Contained in:
| User |
The user's login identification.
Body:
| text |
Attributes:
| NONE |
Contained in:
| User |
A short displayable name for the user.
Body:
| text |
Attributes:
| NONE |
Contained in:
| User |
The user's full formal name.
Body:
| text |
Attributes:
| NONE |
Contained in:
| User |
The user's initial given name or all given names.
Body:
| text |
Attributes:
| NONE |
Contained in:
| User |
The user's surname (family name).
Body:
| text |
Attributes:
| NONE |
Contained in:
| User |
The user's organization.
Body:
| (StreetName*, City?, StateProv?, Country?, PostalCode?, OtherText?) |
Attributes:
| NONE |
Contained in:
| User |
The user's postal address.
Body:
| text |
Attributes:
| NONE |
Contained in:
| Address |
The street address part of a user's postal address.
Body:
| text |
Attributes:
| NONE |
Contained in:
| Address |
The city name part of a user's postal address.
Body:
| text |
Attributes:
| NONE |
Contained in:
| Address |
The state or province name part of a user's postal address.
Body:
| text |
Attributes:
| NONE |
Contained in:
| Address |
The country name part of a user's postal address. This must be represented by an ISO 3166 two-letter country code.
Example: FR for France, JP for Japan.
Body:
| text |
Attributes:
| NONE |
Contained in:
| Address |
The postal code part of a user's postal address.
Body:
| text |
Attributes:
| NONE |
Contained in:
| Address |
Any other text needed as part of a user's postal address.
Body:
| text |
Attributes:
| NONE |
Contained in:
| User |
The user's email address.
Body:
| EMPTY |
Attributes:
| PictureFileName | fileName | |||
| ImageType | name | (optional) |
Contained in:
| User |
A visual depiction of the user.
Body:
| text |
Attributes:
| NONE |
Contained in:
| User |
The phone number of the user's pager.
Body:
| text |
Attributes:
| NONE |
Contained in:
| User |
The phone number of the user's facsimile machine.
Body:
| text |
Attributes:
| NONE |
Contained in:
| User |
The user's voice phone number.
Body:
| EMPTY |
Attributes:
| LocationOID | oidref | Reference to a Location definition. |
Contained in:
| AuditRecord, Signature, User |
A reference to the user's physical location.
Body:
| text |
Attributes:
| NONE |
Contained in:
| User |
The user's digital signing certificate.
Note: The Certificate element is not defined further in CDISC ODM V1.1. It is a placeholder for future development.
Body:
| (MetaDataVersionRef+) |
Attributes:
| OID | oid | |||
| Name | name | |||
| LocationType | (Sponsor | Site | CRO | Lab | Other) | (optional) |
Contained in:
| AdminData |
A physical location -- typically a clinical research site or a sponsor's office.
Body:
| EMPTY |
Attributes:
| StudyOID | oidref | References the Study that uses this metadata version. | ||
| MetaDataVersionOID | oidref | References the MetaDataVersion (within the above Study). | ||
| EffectiveDate | date |
Contained in:
| Location |
A reference to a MetaDataVersion used at the containing Location. The EffectiveDate expresses the fact that the metadata used at a location can vary over time.
Body:
| (Meaning, LegalReason) |
Attributes:
| OID | oid | |||
| Methodology | (Digital | Electronic) | (optional) |
Contained in:
| AdminData |
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.
Body:
| text |
Attributes:
| NONE |
Contained in:
| SignatureDef |
A short name for this kind of signature (e.g., authorship, approval).
Body:
| text |
Attributes:
| NONE |
Contained in:
| SignatureDef |
The responsibility statement associated with a signature (e.g., "The signer accepts responsibility for the accuracy of this data.").
Body:
| (ItemGroupData*) |
Attributes:
| StudyOID | oidref | References the Study that defines the metadata for this reference data. | ||
| MetaDataVersionOID | oidref | References the MetaDataVersion (within the above Study) for this reference data. |
Contained in:
| ODM |
Reference data provides information on how to interpret clinical data. For example, reference data might include lab normal ranges. Signature elements nested within ReferenceData have no meaning, and should be ignored.
The StudyOID and MetaDataVersionOID attributes select a particular metadata version. All metadata references (IDs) 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.
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 (IDs) occuring within this ClinicalData element refer to definitions within the selected metadata version.
Body:
| (AuditRecord?,Signature?, InvestigatorRef?, SiteRef?, Annotation*,StudyEventData*) |
Attributes:
| SubjectKey | subjectKey | |||
| TransactionType | (Insert | Update | Remove | Upsert | Context) | (optional) |
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.
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.
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.
Body:
| EMPTY |
Attributes:
| ArchiveLayoutOID | oidref | Reference to the ArchiveLayoutDef. |
Contained in:
| FormData |
A reference to the archive layout used to collect the form's data.
On Update, a NULL ArchiveLayoutOID is permitted.
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).
The ItemGroupOID and ItemGroupRepeatKey are used together to name a particular item group. This pair of values is unique within the parent form. The ItemGroupRepeatKey is present if and only if the ItemGroupDef is repeating.
ItemGroupData can also occur as reference data. In that case, the ItemGroupOID and ItemGroupRepeatKey pair must be unique within the reference data.
Body:
| (AuditRecord?,Signature?, MeasurementUnitRef?, Annotation* ) |
Attributes:
| ItemOID | oidref | Reference to the ItemDef. | ||
| TransactionType | (Insert | Update | Remove | Upsert | Context) | (optional) | ||
| Value | CDATA | (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. This value is unique within the parent item group.
Body:
| (Comment?, Flag*) |
Attributes:
| SeqNum | integer | |||
| TransactionType | (Insert | Update | Remove | Upsert | Context) | (optional) |
Contained in:
| 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.
Body:
| text |
Attributes:
| SponsorOrSite | (Sponsor | Site) | (optional) | Source of the comment. |
Contained in:
| Annotation |
A free-text (uninterpreted) comment about clinical data. The comment may have come from the Sponsor or the clinical Site.
Body:
| (FlagValue, FlagType?) |
Attributes:
| NONE |
Contained in:
| Annotation |
A machine-processable annotation on clinical data.
Body:
| text |
Attributes:
| CodeListOID | oidref | Reference to the CodeList definition. |
Contained in:
| Flag |
The value of the flag. The meaning of this value is typically dependent on the associated FlagType. The actual value must be a member of the referenced CodeList.
Body:
| name |
Attributes:
| CodeListOID | oidref | Reference to the CodeList definition. |
Contained in:
| Flag |
The type of flag. This determines the purpose and semantics of the flag. Different applications are expected to be interested in different types of flags. The actual value must be a member of the referenced CodeList.
Body:
| (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.
Body:
| EMPTY |
Attributes:
| UserOID | oidref | Reference to the User definition. |
Contained in:
| AuditRecord, Signature |
Body:
| EMPTY |
Attributes:
| SignatureOID | oidref | Reference to the SignatureDef. |
Contained in:
| Signature |
Body:
| datetime |
Attributes:
| NONE |
Contained in:
| AuditRecord, Signature |
The date/time that the data entry, modification, or signature was performed. This applies to the initial occurrence of the action, not to subsequent transfers between computer systems.
Body:
| text |
Attributes:
| NONE |
Contained in:
| Signature |
A cryptographic hash of the signed data. Part of digital (as opposed to electronic) signature. CryptoBindingManifest is not defined further in CDISC ODM V1.1.
Body:
| (UserRef, LocationRef, DateTimeStamp, ReasonForChange?, SourceID?) |
Attributes:
| NONE |
Contained in:
| FormData, ItemData, ItemGroupData, StudyEventData, SubjectData |
An AuditRecord carries information pertaining to the creation, deletion, or modification of clinical data. This information includes who performed that action, and where, when, and why that action was performed.
AuditRecord information describes a change to clinical data, but is not itself clinical data. The value of some clinical data can always be changed by a subsequent transaction, but history cannot be changed -- only added to.
AuditRecords are appropriate whenever an element has an TransactionType (either explicit or inherited). AuditRecords are not meaningful in Snapshot transfers.
Like the TransactionType attribute, AuditRecords are inherited by any subelement that is allowed to have an AuditRecord and does not already have an explicit one.
Note: Contrast with Signature.
Editor's note:The inheritance of AuditRecords, along with their placement at the end of element bodies, implies the need for substantial lookahead in processing ODM files. We may wish to change this.
Body:
| text |
Attributes:
| NONE |
Contained in:
| AuditRecord |
A user-supplied reason for a data change.
Body:
| text |
Attributes:
| NONE |
Contained in:
| AuditRecord |
Information that identifies the source of the data within an originating system. It is only meaningful within the context of that system.
Example: A SourceID attached to an ItemGroup could be used to carry the originating system's internal record OID for that data.
Body:
| EMPTY |
Attributes:
| UserOID | oidref | Reference to a User definition. |
Contained in:
| SubjectData |
On Update, a NULL UserOID is permitted.
Body:
| EMPTY |
Attributes:
| LocationOID | oidref | Reference to a Location definition. |
Contained in:
| SubjectData |
On Update, a NULL LocationOID is permitted.
This index lists all the attributes used, along with the elements that use them.