| Table of Contents |
|---|
...
Here is how the Clinical Data Interchange Standards Consortium describes the ODM in the introduction of the specification:
The Operational Data Model (ODM) is a vendor neutral, platform independent format for interchange and archive of clinical study data. The model includes the clinical data along with its associated metadata, administrative data, reference data and audit information. All of the information that needs to be shared among different software systems during the setup, operation, analysis, submission or for long term retention as part of an archive is included in the model.
Clinical data management systems vary significantly in the information they store and the rules they enforce. The ODM model has been designed to represent a wide range of study information so as to be compatible with most existing clinical data management systems. Systems that do not have all of the features represented by the ODM model may still be ODM compatible as long as they comply with the conformity rules provided in the section on System Conformity.
The ODM has been designed to be compliant with guidance and regulations published by the FDA for computer systems used in clinical studies. This document is intended to be both the formal specification of the ODM and a user guide for those involved in transferring or archiving of clinical data using the model.
To the maximum extent possible, the ClinSpark data model is based on the CDISC Operational Data Model (ODM) standard. In fact, a significant portion of the database schema for ClinSpark was generated directly from the ODM XML schema. ODM scope is limited to the core entities of clinical study data. The ClinSpark data model includes this but goes far beyond this scope. As such the CDISC ODM and it's related documentation are excellent sources of information to understand the subset of the ClinSpark data model which overlaps.
...
An activity plan is a schedule of events for a given cohort. Activity Plans do not appear in CDSIC. In ODM, there is the notion of a FormRef. However, this design doesn't fit well with ph1 trials where forms are commonly repeated for a given study event (ie many PKs in a given day). As such, FormRef is implicitly available by way of Scheduled Activities that are a part of a Segment / Activity Plan.
...
Key | Table | From CDISC? | Notes |
|---|---|---|---|
1 | Study | Yes | This element collects static structural information about an individual study. A study is related to a given clinical trial protocol. |
2 | Activity Plan | No | A schedule of events for a given cohort. Plans can be assigned to multiple cohorts. A timed plan must have a reference time in order to properly provide UI feedback as segments and scheduled activities are set.
Timed Activity Plan:
Activity Plan fills the role of the FormRef in the ODM. |
3 | Segment | Partially | Holds a group of scheduled activities in an activity plan. The segment's offset seconds is essentially the time of the reference event. All scheduled activities are relative to this. Modeled somewhat off of CDISC SDM: "Segments are often seen as the basic building blocks of study design. A segment usually specifies a combination of planned observations and interventions, which may or may not involve treatment, during a period of time." |
4 | Scheduled Activity | No | Wraps a form, but adds metadata including timing. |
5 | Form | Yes | A form is basically a container for item groups. |
6 | Study Event | Yes | A study event represents a given 'visit'. In phase 1 trials this will commonly simply refer to a 'day'. When scheduling forms for a given schedule, the builder must associate the study event. Note: there are common study events that are typically reserved for special events: unscheduled, common (AE, CM), etc |
...
With this in mind, below is a view of how these elements relate to each other.
...
Note that form_data can have linkage to forms through scheduled activities or unscheduled.
ItemGroupData has an item_group_repeat_key which is used to track repeats.
Key | Table | From CDISC? | Notes |
|---|---|---|---|
1 | form | Yes | Basically a container for item groups. |
2 | form_data | Yes | Form data represents data collected for a given subject. Instead of storing the scheduled time on this domain, we leverage the relationship to the encapsulated scheduledActivity domain and thus its relationship to the segment. We purposely don't set formRepeatKey in the domain. It is calculated later on when building ODM. |
3 | item_group | Yes | A collection of related items in a given form |
4 | item_group_ref | Yes | A given item group within a form definition. |
5 | item_group_data | Yes | Aggregates item data |
6 | item | Yes | Represents the definition of a piece of data collected. |
7 | item_ref | Yes | A given item within an item group definition. |
8 | item_data | Yes | A piece of collected data |
9 | study_event | Yes | A study event represents a given 'visit'. In phase 1 trials this will commonly simply refer to a 'day'. When scheduling forms for a given schedule, the builder must associate the study event. Note: there are common study events that are typically reserved for special events: unscheduled, common (AE, CM), etc |
10 | study_event_data | Yes | Clinical data for a study event (visit) for a given subject |
...