| Table of Contents |
|---|
...
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.
| 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. Untimed 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.
| 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 |
...
| Table | From CDISC? | Notes | |
|---|---|---|---|
| 1 | item_data | Yes | A piece of collected data |
| 2 | item_group_data | Yes | Aggregates item data |
| 3 | 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. |
| 4 | study_event_data | Yes | Clinical data for a study event (visit) for a given subject |
| 5 | 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 |
| 6 | subject | Yes | Someone participating in clinical research within the context of a given study. |
Lab Data
...
Queries
Queries and Annotations can be reached via ItemData. 
seen on ItemData entities like this:
| Table | From CDISC? | Notes | |||
|---|---|---|---|---|---|
| 1 | item_data_query | YesNo | A query related to a piece of collected data. Note that lab orders and all results are associated to a given Item Data. You will need to join through Item Data when working with lab data.item data | ||
| 2 | base_specimen | Yes (CDISC LAB) | Modeled off of CDISC Lab. A specimen is collected from a subject and assigned to a given item data instance. There can be multiple batteries (test groups) associated to a given specimen. Combines Accession Level and Base Specimen from spec. | ||
| 3 | base_battery | Yes (CDISC LAB) | A panel related to a specimen - typically this is just a 1 to 1 relationship, meaning there is often 1 base_battery for a single specimen. | ||
| 4 | base_test_result | Yes (CDISC LAB) | Combines CDISC Lab BaseTest and BaseResult. These are the results from the lab. | ||
| 5 | lab_order | No | item_data_query_comment | No | A given comment related to a given query |
| 3 | item_data_sample_annotation | No | Comments added directly on the item |
Lab Data
Lab data can be reached via ItemData.
| Table | From CDISC? | Notes | |
|---|---|---|---|
| 1 | item_data | Yes | A piece of collected data. Note that lab orders and all results are associated to a given Item Data. You will need to join through Item Data when working with lab data. |
| 2 | base_specimen | Yes (CDISC LAB) | Modeled off of CDISC Lab. A specimen is collected from a subject and assigned to a given item data instance. There can be multiple batteries (test groups) associated to a given specimen. Combines Accession Level and Base Specimen from spec. |
| 3 | base_battery | Yes (CDISC LAB) | A panel related to a specimen - typically this is just a 1 to 1 relationship, meaning there is often 1 base_battery for a single specimen. |
| 4 | base_test_result | Yes (CDISC LAB) | Combines CDISC Lab BaseTest and BaseResult. These are the results from the lab. |
| 5 | lab_order | No | When specimens are collected, this domain represents that an order is generated. It causes a manifest file to be created (PDF) and potentially a file order to be dumped on to the file system and made available to web services. |
| 6 | lab_interface | No | Encapsulates how to send and receive orders and results from a particular safety lab. Sites may have multiple labs, and if so each of these will have their own lab interface instance. |
| 7 | study_lab_panel | No | Something that can be ordered from item level |
| 8 | specimen_container | No | When setting up samples or labs, users can optionally choose a container. |
| 9 | lab_repeat | No | A domain that allows for the management of lab repeat workflows |
...
| Table | From CDISC? | Notes | |||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | sample_path_step | A step in the path to fulfill a given sample | |||||||||||||||||||
| 2 | sample_task | Coarse grained description of what needs to be done for a given sample path step; this could be an enum on the class, but having it here gives a bit more flexibility and can encode some further instructions. | 3 | sample_path | Container for the sample path steps | 4 | specimen_container | When setting up samples or labs, users can optionally choose a container | 5 | sample_transfer | A given step may require a transfer of sample material; this domain captures that | 6 | sample_shipment | Signifies a sample container being removed | 7 | sample_container | Something that we place sample path step data into | 8 | sample_container_item | An individual sample that is placed into a container | |
| 9 | sample_batch_data | No | Allows for doing a step with a group of samples. Furthermore, it allows the steps for the relevant sample path step data objects to span a period of time. Non-ODM. | ||||||||||||||||||
| 10 | sample_path_step_data | No | For forms that require sample data to be collected, this domain tracks accordingly. Non-ODM. | ||||||||||||||||||
| 11 | item_data | Yes | All sample data can be joined through item_data_id |
Queries
Queries and Annotations can be seen on ItemData entities like this:
| Table | From CDISC? | Notes | |
|---|---|---|---|
| 1 | item_data_query | No | A query related to a piece of item data |
| 2 | item_data_query_comment | No | A given comment related to a given query |
| 3 | item_data_sample_annotation | No | Comments added directly on the item. |
| 3 | sample_path | Container for the sample path steps | |
| 4 | specimen_container | When setting up samples or labs, users can optionally choose a container | |
| 5 | sample_transfer | A given step may require a transfer of sample material; this domain captures that | |
| 6 | sample_shipment | Signifies a sample container being removed | |
| 7 | sample_container | Something that we place sample path step data into | |
| 8 | sample_container_item | An individual sample that is placed into a container | |
| 9 | sample_batch_data | No | Allows for doing a step with a group of samples. Furthermore, it allows the steps for the relevant sample path step data objects to span a period of time. Non-ODM. |
| 10 | sample_path_step_data | No | For forms that require sample data to be collected, this domain tracks accordingly. Non-ODM. |
| 11 | item_data | Yes | All sample data can be joined through item_data_id |
Volunteers
Volunteers are not a part of CDISC.
...