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.
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
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.
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.
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.
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.
Wearable device data is stored in the Health Datum object.
HK Sample objects contain data collected by Apple HealthKit or Google Fit in Health Data Permissions steps.
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.
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
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
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 rules are a static data set which define the conditions under which an automatic query is created.
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 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 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.
Steps correspond to questions within a questionnaire (
c_task). The step’s type (
c_type) property defines its functionality and appearance.
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 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.
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.
Tasks correspond to questionnaires (or forms) in a study. A task is a grouper for
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
Visits provide a way to group and present tasks on Site App, in accordance with a study’s site 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.