An ODM document (file) can be viewed as a set of instructions 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 is not always convenient to create such a large document. So we allow a series of ODM files to incrementally provide this information.

An ODM document 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.)

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

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

Note: 

1. The FileOID identifies the document content. It does not change just because the document is copied.
2. 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 forward slash, "/"). 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.
3. Similarly, StudyOIDs should be universally unique if at all possible. For example, StudyOID="BestPharmaceuticals.com/Study5894".
4. 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 (e.g., particular subjects, particular forms),
• 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 indicates 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. 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 regulations (https://www.fda.gov/regulatory-information/). 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.

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

Context=Archive indicates that the file is intended to meet the requirements of an electronic record as defined in 21 CFR 11.

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

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