Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...


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

...

Info

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,
  • 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. 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 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 Element Ordering Section.

Granularity

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

...