Objects

Data Structure
The Cortex data structure is comprised by a series of objects and those object’s properties. Objects and properties are considered either standard or custom. Standard objects and properties are created and populated solely by the Medable application; standard objects and properties cannot be edited. Custom objects and properties begin with the prefix c_* and can be edited. New custom objects and properties can be created when the existing data structure does not meet the needs of a study.
Common Data Object Definitions
Below is a list and short description for common data objects which can be found in most studies.
Object Label
Object Name
Object Description
Account
account
Account objects are created for every user with a login. Account records are created for participants after enrollment and for administrators through Researcher Portal. Account records do include PHI, most commonly name, date of birth and sex.
Branch
c_branch
Branching is a way to skip over questions depending on previous answers. Branching logic is used to create non-linear if/then logic within a task. Branch objects hold a reference to the associated c_step objects and the logic to skip between c_steps.
Connections
connection
Connections allow users to share documents with another user who inherently does not have access to said document. More details on connections can be found here.
EDI Message
c_edi_message
The EDI Message object is only populated in organizations that have EDI integrations. The object contains references to associated objects, a record of what messages were sent, statuses and time stamps.
Participant Group
c_group
The Participant Group determines a study participant’s task assignments and can be used to enforce a specific study workflow.  Tasks are assigned to these groups and you can configure Flow Rules to create scenarios where certain task responses unlock other tasks for completion.
Participant Group Task
c_group_task
The Group Task defines the availability of tasks within a c_group. Details about the task’s schedule (e.g. always available, one time, or other schedule) and task reminders/notifications are detailed here.
Health Datum
c_health_datum
Wearable device data is stored in the Health Datum object.
HK Sample
c_hksample
HK Sample objects contain data collected by Apple HealthKit or Google Fit in Health Data Permissions steps.
Organization
org
An org object can contain multiple Studies. The Organization contains information about the sponsor. For example, the name and logo are stored on the org.
Public User
c_public_user
Every participant in a study will have a Public User object, which is created. when a patient is invited to the study. Public User records are anonymized and only contain the subject’s ID (c_public_user.c_number). If the participant logs in to Medable using Patient App, their user will link to an account object. Many other dynamic data objects link back to the c_public_user object.
Query
c_query
Query objects are created when data managers find and review unexpected or inaccurate data. Query objects can be automatically or manually created. Queries are associated with c_step_response and c_task_response objects.
Query Note
c_query_note
Data managers are able to add Query Notes during query resolution workflows. These are the messages that get created when a system query is triggered.
Query Rule
c_query_rule
Query rules are a static data set which define the conditions under which an automatic query is created.
Research Data
c_research_datum
The Research Data object contains aggregated statistics for key events in the system. For example, the object contains the number of user who requested to leave the study each day.
Site
c_site
Site objects correspond to each of the sites in the study. The objects contain information about the PI, address, site alias and more. Note that this will only be applicable if a study uses the site app.
Site User
c_site_user
Site User objects are created for each non-participant user in Medable. Access permissions and roles are assigned here. There are five standard site user roles: Site User, Site Investigator, Data Reviewer, Data Manager, and Site Monitor. The level of system access and responsibilities for each of these roles varies.
Step
c_step
Steps correspond to questions within a questionnaire (c_task). The step’s type (c_type) property defines its functionality and appearance.
Step Response
c_step_response
When a participant answers a question (c_step) in a survey, a Step Response object is created. The Step Response references the Step, associated user (c_public_user), and questionnaire (c_task). Step responses comprise a majority of the dynamic study data.
Study
c_study
Study objects hold general information about your study: the protocol number, projected enrollment numbers, dates, etc. Items that can be configured for a site include: whether the study is available to the general public or requires an invite (enrollment type) and subject ID formats.
Study Export
c_study_export
Individuals with access to the Researcher Portal are able to export study data. When a user runs an export, a c_study_export object is created.
Task
c_task
Tasks correspond to questionnaires (or forms) in a study. A task is a grouper for c_steps.
Task Response
c_task_response
Task Response objects are dynamically created when a user completes a task in Medable. Task Responses correspond to a c_task object but also contain contextual information about the user’s response; Task Responses act as a grouper for c_step_responses.
Visit
c_visit
Visits provide a way to group and present tasks on Site App, in accordance with a study’s site visit schedule.
Visit Schedule
c_visit_schedule
The Visit Schedule allows you to configure a specific study workflow in the Site App. Visits are configured within the Visit Schedule and tasks get assigned to Visits. The Visit Schedule is built in accordance with a study’s workflow.

Last modified 2yr ago

Object Label	Object Name	Object Description
Account	`account`	Account objects are created for every user with a login. Account records are created for participants after enrollment and for administrators through Researcher Portal. Account records do include PHI, most commonly name, date of birth and sex.
Branch	`c_branch`	Branching is a way to skip over questions depending on previous answers. Branching logic is used to create non-linear if/then logic within a task. Branch objects hold a reference to the associated c_step objects and the logic to skip between `c_steps`.
Connections	`connection`	Connections allow users to share documents with another user who inherently does not have access to said document. More details on connections can be found here.
EDI Message	`c_edi_message`	The EDI Message object is only populated in organizations that have EDI integrations. The object contains references to associated objects, a record of what messages were sent, statuses and time stamps.
Participant Group	`c_group`	The Participant Group determines a study participant’s task assignments and can be used to enforce a specific study workflow. Tasks are assigned to these groups and you can configure Flow Rules to create scenarios where certain task responses unlock other tasks for completion.
Participant Group Task	`c_group_task`	The Group Task defines the availability of tasks within a `c_group`. Details about the task’s schedule (e.g. always available, one time, or other schedule) and task reminders/notifications are detailed here.
Health Datum	`c_health_datum`	Wearable device data is stored in the Health Datum object.
HK Sample	`c_hksample`	HK Sample objects contain data collected by Apple HealthKit or Google Fit in Health Data Permissions steps.
Organization	`org`	An org object can contain multiple Studies. The Organization contains information about the sponsor. For example, the name and logo are stored on the org.
Public User	`c_public_user`	Every participant in a study will have a Public User object, which is created. when a patient is invited to the study. Public User records are anonymized and only contain the subject’s ID (`c_public_user.c_number`). If the participant logs in to Medable using Patient App, their user will link to an account object. Many other dynamic data objects link back to the `c_public_user` object.
Query	`c_query`	Query objects are created when data managers find and review unexpected or inaccurate data. Query objects can be automatically or manually created. Queries are associated with `c_step_response` and `c_task_response` objects.
Query Note	`c_query_note`	Data managers are able to add Query Notes during query resolution workflows. These are the messages that get created when a system query is triggered.
Query Rule	`c_query_rule`	Query rules are a static data set which define the conditions under which an automatic query is created.
Research Data	`c_research_datum`	The Research Data object contains aggregated statistics for key events in the system. For example, the object contains the number of user who requested to leave the study each day.
Site	`c_site`	Site objects correspond to each of the sites in the study. The objects contain information about the PI, address, site alias and more. Note that this will only be applicable if a study uses the site app.
Site User	`c_site_user`	Site User objects are created for each non-participant user in Medable. Access permissions and roles are assigned here. There are five standard site user roles: Site User, Site Investigator, Data Reviewer, Data Manager, and Site Monitor. The level of system access and responsibilities for each of these roles varies.
Step	`c_step`	Steps correspond to questions within a questionnaire (`c_task`). The step’s type (`c_type`) property defines its functionality and appearance.
Step Response	`c_step_response`	When a participant answers a question (`c_step`) in a survey, a Step Response object is created. The Step Response references the Step, associated user (`c_public_user`), and questionnaire (`c_task`). Step responses comprise a majority of the dynamic study data.
Study	`c_study`	Study objects hold general information about your study: the protocol number, projected enrollment numbers, dates, etc. Items that can be configured for a site include: whether the study is available to the general public or requires an invite (enrollment type) and subject ID formats.
Study Export	`c_study_export`	Individuals with access to the Researcher Portal are able to export study data. When a user runs an export, a `c_study_export` object is created.
Task	`c_task`	Tasks correspond to questionnaires (or forms) in a study. A task is a grouper for `c_steps`.
Task Response	`c_task_response`	Task Response objects are dynamically created when a user completes a task in Medable. Task Responses correspond to a `c_task` object but also contain contextual information about the user’s response; Task Responses act as a grouper for `c_step_responses`.
Visit	`c_visit`	Visits provide a way to group and present tasks on Site App, in accordance with a study’s site visit schedule.
Visit Schedule	`c_visit_schedule`	The Visit Schedule allows you to configure a specific study workflow in the Site App. Visits are configured within the Visit Schedule and tasks get assigned to Visits. The Visit Schedule is built in accordance with a study’s workflow.