| Info | ||
|---|---|---|
| ||
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.
| Info | ||
|---|---|---|
| ||
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 contains that data.
| 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 AttributesAs 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:
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. |
| Info | ||
|---|---|---|
| ||
Other File AttributesAs 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:
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. |
...