A family head subscribes to a doctor's plan through Stripe Checkout, with payment confirmation converging idempotently and the doctor gating activation.

1. 1Family head calls POST /subscriptions/create/; a guard chain validates the plan, profile completeness and the three-doctor cap, then prices the plan server-side in the caller's detected currency
2. 2Backend opens a Stripe Checkout session with the subscription id bound as client_reference_id and metadata at session and payment-intent level, returning the checkout URL
3. 3Payment confirms through three converging paths — signed webhook, authenticated status poll, and unauthenticated confirm — all funnelling into one idempotent activator guarded by a global ProcessedStripeEvent ledger
4. 4A new subscription lands PENDING (payment held, refundable) and notifies the doctor to accept or reject
5. 5On accept, per-member message and video-call quota trackers are created and the subscription goes ACTIVE; on reject, Stripe issues an automatic refund

Instant and scheduled video calls run on a shared Jitsi/WebRTC room with WebSocket signalling and strict quota enforcement.

1. 1A caller starts an instant 'ring' (POST /start-now/) or books a scheduled slot (POST /book/), which checks and decrements call quota under a row lock
2. 2A fresh Jitsi room is created and an INCOMING_CALL / CALL_BOOKED push is sent; the receiver polls /incoming/ and answers or rejects
3. 3Both participants open the shared Jitsi room; a VideoCallConsumer WebSocket validates participants and relays WebRTC offer/answer/ICE
4. 4The call ends idempotently to COMPLETED, while a 60-second no-answer ring auto-expires to MISSED and refunds the quota
5. 5Doctors may also run quota-exempt clinical assessment calls, recording structured per-body-area findings against the session

A doctor builds reusable templates, assigns them as immutable snapshots, and follows patient adherence over time.

1. 1A doctor builds a reusable DietPlanTemplate from the admin-managed food database, requiring at least one item
2. 2Assigning a template snapshots its items into a new plan so later template edits never leak into assigned plans, and any prior active plan is deactivated first
3. 3The patient logs daily meal tracking, hydration and wellness — skipped or partial meals require a reason — upserted per day
4. 4The backend computes adherence (completion rate, hydration goals, last activity) and raises exception flags such as LOW_MEAL_ADHERENCE or MEAL_LOG_STALE
5. 5A Celery beat task sends a daily diet-reminder FCM push to every patient with an active plan

Accepted subscriptions credit a doctor's wallet ledger, hold the funds, then settle to their bank via admin-driven payouts.

1. 1On subscription acceptance or renewal auto-activation, the doctor's DoctorWallet is credited their configurable share (default 75%) of the gross charge via an idempotent ledger write, normalised to PKR
2. 2Each earning is held (default 72 hours) as PENDING; a Celery task matures held earnings to AVAILABLE
3. 3An admin reserves a doctor's available balance into a Payout, snapshotting the doctor's bank details
4. 4The admin marks the payout paid with a bank reference, or cancels it to return funds to the wallet, through a pluggable provider (manual Stripe now, local bank API stubbed for later)