Awell Health Developer Hub
Dev Hub

Understanding the data schema

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.

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.
care_flow_idSTRINGIdentifier of the care flow in which the data point was collected. Refers to the `id` column in the `care_flows` table.
care_flow_definition_idSTRINGIdentifier of the care flow definition the related care flow was instantiated from.
release_idSTRINGIdentifier of the published version of the care flow definition.
activity_idSTRINGIdentifier of the activity in which the data point was collected. Refers to the `id` column in the `activities` table.
definition_idSTRINGVersion agnostic identifier of the underlying data point definition component. Refers to the `definition_id` column in the `data_point_definitions` table.
value_rawSTRINGSerialised value of the data point.
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).
dateTIMESTAMPCollection date (UTC).

Data Point Definitions

Table name: data_point_definitions.

ColumnTypeDescription
idSTRINGUnique identifier.
definition_idSTRINGVersion agnostic identifier.
release_idSTRINGIdentifier of the published version of the care flow definition.
categorySTRINGIdentifies how the data point is collected. Examples: `form`, `calculation`.
keySTRINGHuman readable qualified key which defines the meaning of the collected data.
value_typeSTRINGExpected primitive type for the collected data (boolean, date, number, string).

Orchestration data

Care flows

Table name: care_flows.

ColumnTypeDescription
idSTRINGUnique identifier.
patient_idSTRINGIdentifier of the patient enrolled in that care flow. Refers to the `id` column in the `patients` table.
definition_idSTRINGIdentifier of the care flow definition the related care flow was instantiated from.
release_idSTRINGIdentifier of the published version of the care flow definition.
titleSTRINGTitle of the care fow definition.
statusSTRINGStatus of the care flow. One of `starting`, `active`, `stopped`, `completed`.
start_dateTIMESTAMPRecorded start date of the care flow (UTC).
stop_dateTIMESTAMPRecorded stop date of the care flow (UTC). Only populated for stopped care flows.
complete_dateTIMESTAMPRecorded completion date of the care flow (UTC). Only populated for completed care flows.

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 in which the data point was collected. Refers to the `id` column in the `care_flows` table.
care_flow_definition_idSTRINGIdentifier of the care flow definition the related care flow was instantiated from.
statusSTRINGActivity status. One of: `active`, `done`, `failed`, `canceled`, `expired`.
dateTIMESTAMPCreation date of the activity (UTC).
scheduled_dateTIMESTAMPScheduled activation date of the activity (UTC).
object_typeSTRINGType of object this activity relates to. Examples: `action`, `form`, `step`.
object_nameSTRINGName of the related object.
indirect_object_typeSTRINGType of indirect object this activity relates to. Examples: `patient`, `stakeholder`.
indirect_object_nameSTRINGName of the related indirect object.
step_nameSTRINGName of the step this activity belongs to.

Patient data

Patients

Table name: patients

ColumnTypeDescription
idSTRINGUnique identifier.
profile_idSTRINGUnique identifier of the associated profile. Refers to the `id` property in the `patient_profiles` table.

Patient profiles

Table name: patient_profiles

ColumnTypeDescription
idSTRINGUnique identifier.
first_nameSTRINGFirst name of the patient.
last_nameSTRINGLast name of the patient.
nameSTRINGConcatenation of the first name and last name.
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

Getting access to your dataset

You need a service account to access your Big Query dataset. Please contact your Awell Customer Success Manager to receive your account details.