Domain model

All of the interactions with Awell Orchestration are accessible through our API. For full detail, see our API Reference.

Below is a typical, although very basic, lifecycle of interacting with our API.

1. Create a Patient in Awell
2. Start a Pathway for this patient
3. Get the pending activities for this Pathway
4. Request the details of the next activity, e.g. get form details
5. Complete the next activity, e.g. submit form response
6. Request the details of the next activity, e.g. get message details
7. Complete the next activity (e.g. mark the message as read
8. ... and so on until the pathway is completed, at which point you can receive a pathway completed webhook

Core concepts

The core concepts of our API domain model are the following:

• Patient and other stakeholders
• Pathway
• Activity
• Data Point

Patient and other stakeholders

A patient refers to a user that can be enrolled in a care flow. Activities in those care flows can be assigned to that patient but also other stakeholders: physician, nurse, care coordinator, therapist, coach, you name it.

Awell Orchestration does not need to know anything about a patient when orchestrating pathways. Any information saved in a patient profile can be used inside pathway definitions (to customise message content, or enrich api calls / webhook payloads for example), but none of it is required. This means there is no requirement to store PII in Awell.

01

The only recommended property to set when creating patients is the patient_code, which can be used as a unique identifier to match data in Awell with your own patient records.

Awell does not enforce the uniqueness of the patient_code amongst your patients. If you use unique identifiers, you can use the searchPatientsByPatientCode query before creating patients to enforce the uniqueness constraint on your end.

See the API Reference for more information about the user type.

Pathway

A pathway definition is what's automatically created by the Awell Platform when publishing a care flow. A pathway refers to an instance of a pathway definition in which a patient has been enrolled.

01

See the API Reference for more information about the pathway type.

Activities

Activities are the atomic build blocks in an orchestrated pathway. Each activity describes a specific task that needs to be performed by a specific stakeholder at a given point in time.

Awell Orchestration uses the pathway definition to automatically create and schedule activities and assign them to the right stakeholder. Your responsibility is therefore not to schedule individual activities, but to dispatch activities we create to your own users or use them as triggers for additional logic in your system.

Awell Orchestration currently supports the following activity types:

• API Call
• Calculation
• Checklist
• Form
• Message
• Reminder

Generic structure

Activities use a generic structure (subject + action + object + indirect object) to describe any action that needs to be performed by a human or system.

01

When an activity is explicitly assigned to a patient or clinical stakeholder, the indirect_object property has the following data:

01

See the API Reference for more information about the activity type.

Example: API Call activity

01

Example: Calculation activity

01

Example: Form activity

01

Example: Reminder activity

01

Data point definition

Data point definitions describes and qualify each and every atomic piece of data that can be captured in the lifecycle of a pathway.

01

See the API Reference for more information about the data point definition type.