Global Clinic Docsv1.0
Back to app
Docs / User Journeys

Cross-cutting journeys

These journeys either run parallel to the core medical journey (a different vertical or funding model), span every lifecycle phase, or belong to staff personas who operate the platform rather than travel through it.

Clinic: onboard to managing cases [Live]

The clinic-side master flow, covering how an accredited hospital joins the network and then runs its day-to-day work. The clinic completes the onboarding wizard (profile, procedures and pricing, team and surgeons), and once verified it lands on its dashboard, where it quotes or declines inbound inquiries, advances active cases stage by stage, and collects verified reviews.

flowchart LR
  ON[Onboarding wizard] --> PROF[Profile]
  PROF --> PRICE[Procedures & Pricing]
  PRICE --> TEAM[Team & Surgeons]
  TEAM --> DASH[Dashboard]
  DASH --> INQ[Inquiries: quote / decline]
  INQ --> CASE[Cases: advance by stage]
  CASE --> REV[Reviews]

The onboarding eligibility policy (JCI or NABH accreditation, credentialed surgeon details, the draft / pending / verified states) and the inquiry and case lifecycle states are operational rules. They are documented in Clinic onboarding and management workflows.

WF-1 Wellness / AYUSH journey [Planned]

Status: Planned (implementation workstream WS1). A parallel, non-surgical vertical for AYUSH and preventive wellness that runs alongside the medical journey with a shorter, program-based shape. Screen references (N1, N3, N4, N5, N7, N17, U4, U5) point to docs/implementation/01-screen-specs.md.

Personas. Wellness traveller (often self-funded, not ill), Wellness coordinator, Certified centre, Travel Desk.

Primary path.

  1. Visitor lands on /wellness (N1), explores systems and programs, opens the certified-centre directory (N3) and a centre profile (N4).
  2. "Plan a wellness journey" creates a case with journeyType = wellness.
  3. Intake captures concern, dates, preferences (language/dietary, N17) and a chosen program/centre.
  4. Wellness coordinator confirms the program; /portal/wellness (N5) shows the program plan (phases, daily therapies, diet regime, practitioner).
  5. e-AYUSH visa flow (U4) issues the visa; Travel & Stay (U5) books flights/stay/airport; guidance pack (N7) prepares the traveller.
  6. Program runs; integration and follow-up phases close the case; review captured at close-out.
flowchart LR
  W[/wellness N1/] --> C[Centre directory N3]
  C --> P[Centre profile N4]
  P --> I[Intake · journeyType=wellness]
  I --> PL[Program plan N5]
  PL --> V[e-AYUSH visa U4]
  V --> T[Travel & guidance U5/N7]
  T --> R[Program → integration → follow-up]

Alternate paths. Enter from the medical funnel and add a wellness add-on (post-treatment recovery program); choose a program with no fixed centre (coordinator proposes 2 to 3 centres); domestic or short program with no visa needed (skip U4).

Exception paths. No vetted centre for the concern or city, coordinator proposes alternatives or nearby cities; AYUSH visa not available for the corridor, fall back to a medical or tourist visa per Country Pack with guidance; medical contraindication surfaced at intake, route to a medical opinion (WF-7) before proceeding.

Impact on existing flows. The Journey dashboard (U11) must render the wellness stage set when journeyType = wellness; nav (U12) shows Wellness; Quality (U10) adds Green/Olive Leaf.

WF-2 Insurance-funded treatment [Planned]

Status: Planned (implementation workstream WS2). Serves the payer-funded patient alongside the self-pay escrow model, spanning from pre-authorisation in Plan through claim reconciliation at close-out. Screen references (N6, N13, N15, U7, U8) point to docs/implementation/01-screen-specs.md.

Personas. Payer-funded patient, Finance/claims ops, Clinic cashless desk, Insurer (external), Admin (empanelment).

Primary path.

  1. Admin empanels the insurer (N15), a prerequisite.
  2. Patient opens /portal/insurance (N6), adds a policy (insurer, number, sum insured, uploads card to wallet U8).
  3. "Check cashless eligibility" returns eligible if the clinic is in the insurer's network and the specialty is covered.
  4. Patient submits pre-authorisation (gated on a verified policy plus a signed estimate). Insurer reviews; a payment guarantee is issued (guaranteeRef).
  5. Funding splits: the guaranteed amount is cashless; the remainder goes to escrow self-pay on /portal/pay (U7).
  6. After treatment, the clinic or patient files a claim; Finance reconciles claim vs guarantee vs ledger in the finance console (N13).
sequenceDiagram
  participant A as Admin
  participant P as Patient
  participant I as Insurer
  participant F as Finance ops
  A->>A: Empanel insurer (N15)
  P->>P: Add policy + upload card (N6/U8)
  P->>I: Submit pre-authorisation
  I-->>P: Payment guarantee (or partial / reject)
  P->>F: Remainder to escrow (U7)
  P->>F: File claim post-treatment
  F->>F: Reconcile claim vs guarantee (N13)

Alternate paths. Partial approval, split-funding explainer; patient tops up the gap via escrow. Reimbursement (non-cashless), patient self-pays via escrow and files a claim for reimbursement afterward. AYUSH-covered policy, claim allowed against a wellness program (R29).

Exception paths. Pre-auth rejected, guidance plus a "switch to self-pay" CTA (the escrow path is unaffected). Insurer not empanelled, patient sees "self-pay recommended" and ops can request empanelment. Guarantee expires before admission, re-request pre-auth (idempotent).

Impact on existing flows. Payments (U7) gains a funding split and guarantee status; Documents (U8) gains insurance types; Journey (U11) shows an Insurance tile for payer-funded cases.

WF-3 Language and cultural onboarding [Planned]

Status: Planned (implementation workstream WS3). A cross-cutting layer that localises the product and surfaces interpreter and cultural accommodation for every corridor. Screen references (N17, U9, U12) point to docs/implementation/01-screen-specs.md.

Personas. International patient/attendant, Coordinator, Clinic.

Primary path.

  1. Patient sets language, interpreter, dietary, religious and accessibility preferences (N17).
  2. The UI switches locale (RTL for Arabic) app-wide.
  3. Preferences become a structured brief delivered to the coordinator and clinic.
  4. An interpreter need creates a concierge line (Care/Travel) and a coordinator task.
  5. Messages (U9) exposes the interpreter toggle.

Alternate paths. Change language from the global switcher (U12) without opening Preferences; an attendant with different language needs gets a separate brief.

Exception paths. Unsupported locale requested, fall back to English with the interpreter flagged; RTL rendering issue on a screen, list or stacked fallback; a dietary or religious need the clinic cannot meet, coordinator proposes alternatives.

Impact on existing flows. Cross-cutting: every screen reads strings from the locale bundle; PortalProvider regains lang/rtl; the public site and clinic console also localise.

WF-8 Operations, governance and compliance [Planned]

Status: Planned (implementation workstream WS8). These are the staff journeys that operate the platform. The personas here run consoles that are specified but not yet built; the patient and clinic surfaces already expose the data those consoles will act on (stage owners and SLAs, escrow milestones, the visa checklist, inquiries and cases). Screen references (N11, N13, N14, N16) point to docs/implementation/01-screen-specs.md.

Personas. Care Coordinator, Visa-ops, Finance/Escrow, Administrator, Compliance, Medical Director.

Primary paths.

  • Coordinator (N11): claim a case from the queue, work the stage, create tasks, advance the stage, escalate on SLA risk, message the patient. SLA timers derive from Stage.slaTarget; breaches emit reporting events.
  • Admin Country Pack (N14): draft a corridor version, simulate against a test case, publish with an effective date (this activates the corridor and visa type without a release).
  • Finance (N13): release a milestone on a verified trigger, reconcile claims vs guarantees, issue refunds; the ledger is immutable.
  • Compliance (N16): review the audit log, manage consent records, intake and track DSAR and breach, raise sanctions/AML flags by corridor risk tier.

Alternate paths. Medical Director governance review (read-all); a support agent acts with patient consent (consent-gated, audited).

Exception paths. SLA breach, auto-escalation; Country-Pack simulation fails validation, publish blocked; milestone release attempted without a verified trigger, 409; DSAR erase conflicts with a legal-hold, routed to Medical Director/Legal.

Impact on existing flows. These surfaces operationalise the stage owners and SLAs already in the data model; they read existing case, payment and visa data and the new WS1 to WS7 entities. The operational rules they enforce (payments and refunds, escalation) are documented in Business Processes and Workflows.