Before you trigger a care flow

Whichever way a care flow starts, every trigger needs a patient and the data the flow's logic depends on.

Several triggers can start a care flow, and nothing restricts a care flow to one of them. Each suits different situations, so running more than one is normal.

Whichever trigger starts it, a care flow needs a patient and whatever data its logic reads.

Create a patient first

Every care flow is linked to a patient, so the patient has to exist before the flow can start.

Anonymous patients are supported, with no protected health information at all, which suits a public intake form where the person filling it in isn't known yet.

Populate patient_code. It holds the calling system's own internal ID for the patient, and it's what matches a patient in Awell to the same person elsewhere. Skipping it makes the two records harder to match up later. See Patient identifiers.

Decide what data the flow needs at start

At start, a care flow needs:

Data about the patient, as above.
Data the care flow's logic needs. Anything a condition, a calculation or a timing reference reads. These arrive as baseline data points.

If the flow's logic reads a baseline value that never arrived, the flow reaches that logic and stops without raising an error. Work out what the logic needs before wiring the trigger, not after.

Triggers, ordered by engineering effort

Trigger	Engineering effort	Best when
Awell Care	None	A person starts flows, or a flow needs testing
Hosted Pages link	Very low	Patients self-enroll from a link or QR code
File upload	Very low	Batches, on a schedule
Incoming webhook	Low	Another system emits an event
ADT feeds	Medium, plus a hospital	Hospital admission and discharge should drive care
The API	Highest	The integration needs full control

Next steps

Next: Enrollment triggers, the place in the app where all of this is managed.