Awell Health Developer Hub
Dev Hub

To use the data from the Awell platform, it's essential to understand some Awell terminology first.

Below, we explain the terminology that you'll find back in the data schema. If you have any further questions about this, please contact your Awell Customer Success Manager.

Terminology

Care flow definition vs care flow

In the Awell domain, a care flow definition is a care flow template designed in the Awell Studio, representing the general structure and components of a care plan without being tied to any specific patient.

A care flow on the other hand is a patient-specific instance derived from a care flow definition that tracks and manages an individual patient's care journey. For example, if you created the care flow definition "post-operative follow-up" in Awell Studio, all your patients that get included in this care flow definition will have an individual care flow.

Data point definition vs data point

Similar to care flow definitions and care flows, a data point definition is a care flow component as designed in Awell Studio while a data point is the patient-specific instance of that data point definition. For example, if you collect the weight of a patient in a care flow, the data point for a specific patient could be 80 kg (or 176lbs).

Data point keys

To avoid having to work with randomly generated IDs for data point definitions, we allow users to define a human-readable identifier in Awell Studio for all data point definitions. In the data repository, we combine this human-readable identifier with the source to form a 'key'. Let's imagine that you are building a patient form to collect the patient's weight and height, with the intent of calculating a BMI score. You set the form key to bmi, and set the question keys to height and weight respectively. This will result in data point definitions with the following keys:

  • bmi.height contains the answer to the height question in the bmi form
  • bmi.weight contains the answer to the weight question in the bmi form

Release vs. version

In Awell Studio you can see the list of published versions for a given care flow definition with an auto incremented version number. This version number is only used for display purposes. Behind the scenes we assign a unique release identifier to each published version, which you can retrieve through the Get published pathway definitions query.

The release identifier is guaranteed to be globally unique so it can be safely used as input to build analytics query on the data set.

Schema

The data repository contains three different types of data: data points, orchestration data and patient data.

Data points refers to any atomic piece of data collected from a user or system in care flows (e.g. form responses, calculation results, etc.). These are the datapoints that you can find in the data catalog in Awell Studio and that you can use to build care flows.

Orchestration data refers to data generated by the orchestration of the care flow itself, i.e. data about which actions were orchestrated when in care flows.

Patient data refers to the data you explicitly provide on the patients you enroll in your care flows. When using anonymous patients this only contains identifiers.

Big Query - Schema diagram

Big Query - Schema diagram

Data points

The data points are stored in two tables: data_points and data_point_definitions. The data_points table uses a normalized structure to handle the fact that atomic data can have different value types (string, boolean, numeric, date etc), and can come from many different sources (forms, calculations, Extensions, etc.).

Data Points

Table name: data_points.

ColumnTypeDescription
idSTRINGUnique identifier.
definition_idSTRINGVersion agnostic identifier linking to the `definition_id` column in the `data_point_definitions` table, acting as a foreign key to this table, together with `release_id`.
release_idSTRINGAn internal identifier for the published version_number of the care flow definition. Refers to the `release_id` in the `published_careflows` table, serving as a foreign key, together with `definition_id` for connecting to the proper care flow definition.
care_flow_idSTRINGIdentifier of the care flow in which the data point was collected. Refers to the `id` column in the `care_flows` table, serving as a foreign key to the `care_flows` table.
care_flow_definition_idSTRINGIdentifier of the care flow definition (designed care flow template) from which the care flow was instantiated. Refers to the `definition_id` in the `published_careflows` table, serving as a foreign key, together with `release_id` for connecting to the proper care flow definition.
activity_idSTRINGIdentifier of the activity in which the data point was collected. Refers to the `id` column in the `activities` table, acting as a foreign key to the `activities` table.
value_rawSTRINGSerialised value of the data point. Better to use type dedicated columns.
value_booleanBOOLEANTyped value of the data point. This column is only populated for rows with a value type of `boolean`.
value_numericNUMERICTyped value of the data point. This column is only populated for rows with a value type of `number`.
value_dateTIMESTAMPTyped value of the data point. This column is only populated for rows with a value type of `date`.
value_typeSTRINGPrimitive type of the value before serialisation (boolean, date, number, string).
labelSTRINGDescriptive label associated with the value, providing a human-readable description. Example: for value_numeric 0, the label might be "Female" or "Ocassionally". Especially useful for data points collected in a form.
value_typeSTRINGPrimitive type of the value before serialisation (boolean, date, number, string, numbers_array).
dateTIMESTAMPData point collection time (UTC Timestamp).
last_synced_atTIMESTAMP[IRRELEVANT FOR ANALYSIS] Recorded timestamp of importing data to BigQuery.
statusSTRING[IRRELEVANT FOR ANALYSIS] It will always be `created` indicating collection of a data point.

Data Point Definitions

Table name: data_point_definitions.

ColumnTypeDescription
idSTRINGUnique identifier. Not to be used as foreign key when joining with other tables.
definition_idSTRINGVersion agnostic identifier of designed data point.
release_idSTRINGAn internal identifier for the published version_number of the care flow definition. Refers to the `release_id` in the `published_careflows` table.
source_definition_idSTRING
categorySTRINGIdentifies how/where the data point is collected. Examples: `form`, `calculation`, `step`.
keySTRINGHuman readable qualified key which defines the meaning of the collected data. It is usually formed with a dot notation of category name and data point name. The naming convention may vary (e.g., snake_case, camelCase, ...). Example: Email.CompletionDate
optionsRECORDNested field with an array of objects, each representing a valid option with value and label. Example: "value": "1", "label": "Yes", "value": "0", "label": "No" .
value_typeSTRINGThe expected primitive type for the collected data (boolean, date, number, string, numbers_array).
last_synced_atTIMESTAMP[IRRELEVANT FOR ANALYSIS] Recorded timestamp of importing data to BigQuery.

Orchestration data

Care flows

Table name: care_flows.

ColumnTypeDescription
idSTRINGUnique identifier.
patient_idSTRINGIdentifier of the patient enrolled in the care flow. Refers to the `id` column in the `patients` table, serving as a foreign key to the `patients` table.
definition_idSTRINGIdentifier of the care flow definition (designed care flow template) from which the care flow was instantiated. Refers to the `definition_id` in the `published_careflows` table, serving as a foreign key, together with `release_id` for connecting to the proper care flow definition.
titleSTRINGTitle (Name) of the care flow definition.
release_idSTRINGAn internal identifier for the published version_number of the care flow definition. Refers to the `release_id` in the `published_careflows` table, serving as a foreign key, together with `definition_id` for connecting to the proper care flow definition.
statusSTRINGCurrent care flow status. Possible values: `active`, `stopped`, `completed`, `missing_baseline_info`
start_dateTIMESTAMPRecorded start date of the care flow (UTC). It is always available.
stop_dateTIMESTAMPRecorded stop date of the care flow (UTC). Populated only for stopped flows, otherwise NULL.
complete_dateTIMESTAMPRecorded completion date of the care flow (UTC). Populated only for completed flows, otherwise NULL.
last_synced_atTIMESTAMP[IRRELEVANT FOR ANALYSIS] Recorded timestamp of importing data to BigQuery.

Activities

Table name: activities.

Activities use a generic structure to be able to describe any action that needs to be performed by a human or system.

Go to the Domain Model reference to find more information about how activities are structured, including examples.

ColumnTypeDescription
idSTRINGUnique identifier.
care_flow_idSTRINGIdentifier of the care flow associated with the activity. Refers to the `id` column in the `care_flows` table, serving as a foreign key to the `care_flows` table.
care_flow_definition_idSTRINGIdentifier of the care flow definition (designed care flow template) from which the care flow was instantiated. Refers to the `definition_id` in the `care_flows` table.
statusSTRINGThe current activity status. One of: `active`, `done`, `failed`, `canceled`, `expired`. Status done indicates complete resolution of the activity, such as a sent message being read or a form being fully completed. Done refers to completed activity.
resolutionSTRINGAn internal system status reflecting the outcome of executing the activity, indicating `success`, `failure` (e.g., if a plugin call fails), or `NULL` for activities yet to be resolved or not applicable.
dateTIMESTAMPThe creation date of the activity (UTC). Usually refers to start date.
scheduled_dateTIMESTAMPThe date when the scheduled activity is set to start (UTC). Relevant only for scheduled activities.
completion_dateTIMESTAMPCompletion date of `done` activities.
actionSTRING
action_component_nameSTRINGThe name of the action component holding the primary object, such as a message, form, api_call, calculation. In care flow design, this is typically referred to simply as an action.
object_typeSTRINGType of primary object this activity relates to. Example values: action, api_call, calculation, form, message, pathway, plugin_action, reminder, step, track.
object_nameSTRINGThe name of the primary object the activity is associated with. For messages, this is the subject; for forms the form name.
object_idSTRINGId of the primary object.
indirect_object_typeSTRINGType of indirect/secondary object this activity relates to. Examples: `patient`, `stakeholder`, `plugin`.
indirect_object_nameSTRINGThe name of the related indirect/secondary object the activity relates to. It points to who should engage with or is targeted by the activity. It could be a system (for example plugin name) or a human (for example care provider name).
step_nameSTRINGName of the step the activity belongs to. [IMPORTANT NOTE] Relevant only for activities within steps. If the `object_type` is step, this value will be NULL and step name will be in `object_name` field.
track_nameSTRINGName of the track the activity belongs to. [IMPORTANT NOTE] Relevant only for activities within track. If the `object_type` is track, this value will be NULL and track name will be in `object_name` field.
track_idSTRINGIdentifier of the track the activity belongs to. [IMPORTANT NOTE] Relevant only for activities within track. If the `object_type` is track, this value will be NULL.
last_synced_atTIMESTAMP[IRRELEVANT FOR ANALYSIS] Recorded timestamp of importing data to BigQuery.

Patient data

Patients

Table name: patients

ColumnTypeDescription
idSTRINGUnique identifier.
profile_idSTRINGUnique identifier of the associated patient profile. Acts as a foreign key referring to the id property in the patient_profiles table
statusSTRINGIndicates patient status within the system. Currently, `active_record` is the only available value, indicating that patient is present/not deleted.
last_synced_atTIMESTAMP[IRRELEVANT FOR ANALYSIS] Recorded timestamp of importing data to BigQuery.

Patient profiles

Table name: patient_profiles

ColumnTypeDescription
idSTRINGUnique identifier.
nameSTRINGConcatenation of the first name and last name.
first_nameSTRINGFirst name of the patient.
last_nameSTRINGLast name of the patient.
emailSTRINGEmail address of the patient.
birth_dateDATEBirth date of the patient.
sexSTRINGSex of the patient in ISO_IEC-5218 standard. One of `0` (Not known), `1` (Male), `2` (Female).
national_registry_numberSTRINGNational registry number of the patient.
patient_codeSTRINGArbitrary identifier associated to the patient. You can use this to facilitate the reconciliation of patient records between Awell and your domain.
phoneSTRINGPhone number in the E164 format.
mobile_phoneSTRINGPhone number in the E164 format.
address_streetSTRING
address_citySTRING
address_zipSTRING
address_stateSTRING
address_countrySTRING
last_synced_atTIMESTAMP[IRRELEVANT FOR ANALYSIS] Recorded timestamp of importing data to BigQuery.
statusSTRINGIndicates patient status within the system. Currently, `active_record` is the only available value, indicating that patient is present/not deleted.