| Table of Contents |
|---|
...
Note that ClinSpark has made significant extensions to the ODM in a number of areas. Two examples are device connectivity and importation from the volunteer record. There is no provision within ODM for either of these features. To support this, extensions have been made to data within the ItemGroup and ItemRef domains. This allows noting fields which will have their values populated from direct capture from medical devices, or from a volunteer record within the database. Other such extensions exist throughout the ClinSpark data model. As such, domains which originate in the CDISC standard often contain a superset of the data described by CDISC and also additions created by Foundry Health.
Org, Volunteer, Study, Sites, StudySites
...
and Subjects
| Table | From CDISC? | Notes | |
|---|---|---|---|
| 1 | org | No | An org represents an entity performing clinical research (CRO / CRU). Orgs can have multiple sites that execute studies. |
| 2 | study | Yes | This element collects static structural information about an individual study. A study is related to a given clinical trial protocol. |
| 3 | site | No | A site is a physical place belonging to an organization. An organization having multiple physical clinical sites will have multiple site rows. |
| 4 | study_site | No | An association between a physical site and a study. A study site is different than a physical location. Often, pharma sponsors will specify sites with arbitrary codes and those codes must pass through during data export time. In addition, this domain encapsulates recruitment efforts for a given study / site. |
| 5 | volunteer | No | A volunteer is someone who indicates that they are interested in participating in clinical research for the given org. |
| 6 | subject | Yes | Someone participating in clinical research within the context of a given study. Creates glue between the volunteer and the participation. |
...
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 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 of off 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 |
...