Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: added context

...

Info
iconfalse

An ODM document (file) can be viewed as a set of instructions telling describing 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.

...

Info
iconfalse

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,
  • just domain data (SDTM),
  • 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 by specifying the date/time at which the source database was queried to create the ODM document. 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 When the Context attribute is set to Archive it allows the sender to assert that the contents of the document meet a specific set of criteria that qualifies it as an electronic record defined in the FDA 21 CFR 11 regulation. 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.

...

An ODM 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. The TransactionType attribute need not be present in a Snapshot document. When processing a Transactional document, the rules for ordering a set of transactions for a single data point are those described in the Clinical Data Element Ordering Section.

Anchor
GranularitySection
GranularitySection

...

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

...

Context
Info
iconfalse

The Archival Context attribute is optional and indicates the intended usage of the ODM document. Context may be set to Archive, Submission, or Exchange.Archival

Context=

Yes states

Archive indicates that

this file (or collection of files) is intended

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

FileType must be Transactional when Context is Archive.

Context=Submission indciates that the file is intended to be used as part of a regulatory submission.

Context=DataExchange indicates that the file was generated to be imported into an ODM compliant system.


Context=Archive 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 Context=Archive 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.

...