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
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.
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.
Guardian experience
The expanded notification renders different CTAs depending on whether a qualifying plan is found.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
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
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.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
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.
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 closedcanceled— 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 |
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