Three-Track PrEP Care Plans

The PrEP Cycle

Every PrEP patient on our telehealth platform repeats three things, roughly every 90 days:

When all three are current, the patient is up-to-date. When any of them lapses, we need to get them back on track.

These three activities have independent timelines. A patient might finish intake on day 1, get labs back on day 20, and receive their prescription on day 35. By the time intake is due again at day 90, labs are only on day 70 and the prescription on day 55.

What Went Wrong

We modeled PrEP renewal as a single linear stream: intake, then labs, then prescription, wait 90 days, repeat. Everything hung on the "ideal renewal date," a field called prep_renewal_date on the Visit model. It's calculated by determine_ideal_renewal_date_from_meds(): earliest_fill_date + (quantity × (1 + refills)).

The assumption was that these events would happen in order, close together. Every automated reminder radiated from that single prescription-based anchor. A Celery beat task (send_prep_renewal_reminders) runs daily at 17:00 UTC, counts days until prep_renewal_date, and fires a drip sequence at 29, 19, 15, 7, and 1 days before.

This model fell apart when it hit reality:

PrEP Status Indicators

To address the visibility gap, we built PrEP Status Indicators: three badges rendered in the provider's patient header via PrepStatusIndicators.jsx. The backend method get_prep_status_indicators() returns days_since_last_intake, days_since_last_hiv_result, and days_since_last_prep_prescription for each telehealth patient.

getStatusClass() turns badges yellow at 60 days and red at 90. Intake measures days since the last telehealth visit (checkin_datetime), labs since the last released HIV result (result_datetime), and Rx since the last PrEP medication fill (earliest_fill_date). Drag the slider above to see them drift apart.

The Three-Track Model

The solution: three parallel care plans, one per track, each with its own cycle and reset trigger. Each track counts days since its last completion and sends escalating messages as the patient approaches and passes the 90-day mark.

When the corresponding event happens (a new visit, a new lab result, a new prescription), that track's cycle resets to day 1. The other tracks keep ticking, unaffected.

Notice how pressing one trigger button resets only that track. The other tracks keep counting independently. Messages (the small markers on each bar) only appear on the track that needs attention, and only after day 60.

Transactional vs. Drip

This system draws a clear line between two categories of patient communication:

How Suppression Works

The proposed LabKitAwareHandler checks the patient's AshLabKit status before sending. If a kit is in an active state (in_transit_to_lab, samples_received, accessioned), the care plan message is suppressed. The patient is already in motion. Here's a scenario: the patient returns their kit on day 65, but the lab reports "needs new sample" on day 75.

Day 60's reminder fires normally. AshLabKit status is still delivered_to_patient, so the patient needs to act. On day 65 the patient returns the kit, moving it to in_transit_to_lab. The day 70 reminder is suppressed because the LabKitAwareHandler sees the kit is in an active state. On day 75 the lab reports rejected (needs new sample), so the handler sees no active kit and day 80's reminder goes out. The patient needs to act again.

How It Maps to the Engine

We already have a production care plan system, and it supports almost everything we need out of the box.

The Model

For each patient, we create instances:

The 5-Line Reset

Resetting a track is dead simple. This pattern already exists in lib/build_care_plan.py and registration/dreg/form_actions.py:

cycle = CarePlanCycle.objects.get(slug=cycle_slug)
pc = PatientCycle.objects.create(
    patient=patient,
    patient_care_plan=patient_care_plan,
    cycle=cycle,
    start_datetime=now(),
    coordinator=patient_care_plan.coordinator,
)
pc.make_active()  # deactivates old cycle, sets this one as active

Create a new PatientCycle, call make_active(). The existing care_plan_action_trigger Celery task (runs every 5 minutes) picks it up and starts counting cycle_day from the new start_datetime. No new methods needed.

Rollout Phases