Skip to main content

Push notifications and deep links

References: SPEC.md NFR-PORT-004, NFR-PORT-005, SOLUTION_DESIGN.md BR-PORT-003, TECHNICAL_REQUIREMENTS.md §4.

1. Push (FCM / APNs)​

  • Register device token after successful login; associate token with portal account + tenant on the backend (exact API defined by platform).
  • BR-PORT-003: Payloads MUST NOT contain PHI unless policy explicitly allows (SOLUTION_DESIGN.md). Prefer:
    • Title/body: generic (“You have a new message”, “Appointment reminder”).
    • Opaque notificationId or deep link path only; fetch detail after app opens with valid session.

2. User preferences (NFR-PORT-004)​

  • Support per-category toggles (appointments, messages, results) when backend exposes them.
  • Respect OS-level notification permission denial; degrade to in-app-only reminders.
  • Use universal links (iOS) and App Links (Android) with HTTPS host controlled by the organization, or a verified custom scheme in dev.
  • Flow: Open link → if no session, login → then navigate to authorized route with server-side authorization for resource IDs embedded in path (never trust IDs alone).
  • Do not put sensitive identifiers in URLs visible to other apps; prefer opaque tokens or short-lived link tokens if product supports them.

Implementation: expo-linking or React Navigation linking config.

4. Telehealth join (FR-PORT-009)​

  • “Join visit” may open in-app WebView or external browser per policy; ensure URL is time-limited and opened only after auth check.

5. QA alignment​

See patient-portal-requirements-doc.md §7.9–7.11 (AC-Mobile-1..4).