You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

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'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 Section 3.2, ODM). The FileOID should uniquely identify the document.

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.

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 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 regulation. 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.


FileType

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 Section 2.12, Clinical Data Element Ordering.

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:

CategoryDocument contains
AllAny and all types of data and metadata
MetadataMetadata only
AdminDataAdmin data only
ReferenceDataReference data only
AllClinicalDataClinical data only
SingleSiteClinical data for a single site only
SingleSubjectClinical data for a single subject only


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

Context

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.


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

  • No labels