> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mymeddical.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Camp health plan notifications

> How MyMeddical notifies guardians when their child is added to a camp, and what each call-to-action button does.

## Overview

When a student is enrolled in a camp, MyMeddical automatically identifies their guardian and sends a targeted in-app notification requesting that a health plan be created or reviewed for the camp's duration.

The notification adapts its call-to-action based on whether an active plan already exists for the student over the camp dates.

***

## How it works

<Steps>
  <Step title="Student added to a camp">
    An administrator adds a student to a camp in the school portal.
  </Step>

  <Step title="Notification sent to guardian">
    The system looks up the student's guardian, generates a secure token scoped to that guardian and student, and creates a **Health Plan Request** notification.
  </Step>

  <Step title="Guardian opens the notification">
    The notification expands in the **Messages** screen of the mobile app. The system checks whether an active health plan already covers the camp dates.
  </Step>

  <Step title="Guardian acts">
    One or two action buttons appear depending on the plan detection result. The guardian taps their choice and is taken directly into the relevant flow.
  </Step>
</Steps>

***

## Guardian experience

The expanded notification renders different CTAs depending on whether a qualifying plan is found.

<CardGroup cols={2}>
  <Card title="Scenario A — Existing plan found">
    An active, upcoming, or in-progress plan already overlaps the camp dates.

    **Buttons shown:**

    * **Update existing plan** — opens the existing plan for editing
    * **Create Plan** — opens a new plan pre-filled with camp context
  </Card>

  <Card title="Scenario B — No plan found">
    No active, upcoming, or in-progress plan covers the camp date range.

    **Button shown:**

    * **Create Plan** — opens a new plan pre-filled with camp context
  </Card>
</CardGroup>

<Note>
  When a guardian taps **Create Plan**, the plan name is automatically pre-filled as `[Camp Name] - [Child's first name]` (e.g. `Alice Springs Camp - Henry`) and the start/end dates are set to match the camp.
</Note>

***

## Plan detection rules

The system fetches all plans for the student and applies the following rules.

### Plans that qualify as "existing"

* Computed status is **upcoming** — starts in the future, not cancelled or completed
* Computed status is **in\_progress** — currently active (start date has passed, end date has not)
* The plan date range **overlaps** the camp dates — plan start is on or before camp end, **and** plan end is on or after camp start

<Info>
  A plan does not need to span the entire camp to qualify. A plan that starts before the camp and ends mid-camp, or starts mid-camp and extends past it, still counts as an existing plan.
</Info>

### Plans that are excluded

* `pending_approval` — created by a guardian, waiting for school admin to approve. Not yet a live plan.
* `completed` — plan has ended or was manually closed
* `canceled` — plan was explicitly cancelled

***

## Plan status reference

| Computed status    | Stored status | Description                                      | Counts as existing? |
| ------------------ | ------------- | ------------------------------------------------ | :-----------------: |
| `upcoming`         | `0`           | Future start date, not cancelled or pending      |          ✓          |
| `in_progress`      | `0`           | Start date has passed, end date has not          |          ✓          |
| `pending_approval` | `3`           | Guardian-created, awaiting school admin approval |          ✗          |
| `completed`        | `1`           | Plan has ended or was closed                     |          ✗          |
| `canceled`         | `2`           | Plan was explicitly cancelled                    |          ✗          |

***

## Plan approval on creation

The approval workflow depends on who creates the plan.

| Creator role               | Plan status on creation       | Appears in approval queue?      |
| -------------------------- | ----------------------------- | ------------------------------- |
| Guardian / Parent          | `pending_approval` (status 3) | Yes — school admin must approve |
| School admin / Super admin | `upcoming` (status 0)         | No — goes live immediately      |

<Warning>
  If a guardian submits a plan that is awaiting approval, the next notification they receive will still show only **Create Plan**. Once a school admin approves the plan (moving it to `upcoming`), subsequent notifications will detect it and show **Update existing plan**.
</Warning>

***

## Security

The camp plan prompt endpoint is authenticated and ownership-validated on every request.

* Requires a valid guardian JWT — the endpoint is not publicly accessible
* Each token is scoped to a single guardian–student–camp combination
* On every request the server verifies that the authenticated guardian's ID matches the token owner — a mismatch returns `403 Forbidden`
* Sending a second notification upserts the token rather than creating a duplicate