Docs / Product Documentation
2. Features and Functional Requirements
This section catalogues every product feature, states the functional and non-functional requirements, documents the business rules and validation logic, and defines role-based access. Screen-level detail lives in User Experience and in the per-screen Screen Reference; the end-to-end per-persona journeys live in User Journeys. Role-based access is defined in section 2.7.
2.1 Feature catalogue: public marketing site
| Feature | Route | What it does | Status |
|---|---|---|---|
| Home / landing | / | Value proposition, trust bar, 14-stage journey, visa-engine spotlight, corridor cards, conversion CTAs | Built |
| Find Care (marketplace) | /clinics | Browse, filter and compare vetted clinics by specialty, country, price and rating | Built |
| Treatments catalogue | /treatments | Browse procedures by specialty with indicative pricing and savings | Built |
| Pricing and savings | /pricing | Transparent, itemised cost breakdowns and side-by-side home-market savings | Built |
| Verified reviews | /reviews | Blended, independently-sourced reviews with verified-transaction emphasis | Built |
| Quality and accreditation | /quality | JCI / NABH explainer, the clinic vetting process, external ratings | Built |
| Destinations | /destinations | Network coverage by destination plus honest considerations | Built |
2.2 Feature catalogue: patient portal
| Feature | Route | What it does | Status |
|---|---|---|---|
| Patient Journey | /portal | Home dashboard: next step, coordinator, status tiles, 14-stage strip, activity, concierge | Built (mock) |
| Find Care | /portal/clinics | The in-portal marketplace and match wizard for choosing a clinic | Built (mock) |
| Care Plan | /portal/care | Treatment plan phases, treating hospital and surgeon, vitals, accommodation tags | Built (mock) |
| Visa and Immigration | /portal/visa | The flagship visa engine: hero, document checklist, submit gate, timeline, corridor rules | Built (mock) |
| Travel and Stay | /portal/travel | Select flights, accommodation, transfers and add-ons; Travel Desk confirms | Built (mock) |
| Documents wallet | /portal/docs | Upload, store and verify documents; drives the visa checklist | Built (mock) |
| Payments and Escrow | /portal/pay | Milestone schedule, escrow held, ledger | Built (mock) |
| Messages | /portal/messages | Secure-style threads with the care team | Built (mock) |
| Account | /portal/account | Profile and case details | Built (mock) |
| Settings | /portal/settings | Preferences and security | Built (mock) |
| Notifications | /portal/notifications | Journey updates | Built (mock) |
2.3 Feature catalogue: clinic console
| Feature | Route | What it does | Status |
|---|---|---|---|
| Clinic Dashboard | /clinic | Overview of inquiries, cases, reviews and performance | Built (mock) |
| Patient Inquiries | /clinic/inquiries | Inbound leads and quote requests with status | Built (mock) |
| Active Cases | /clinic/cases | Patients the clinic is delivering, by case stage | Built (mock) |
| Public Profile | /clinic/profile | How patients see the clinic on the marketplace | Built (mock) |
| Procedures and Pricing | /clinic/pricing | Manage indicative procedure prices | Built (mock) |
| Reviews | /clinic/reviews | Verified patient feedback | Built (mock) |
| Team and Surgeons | /clinic/team | Clinical staff and credentials | Built (mock) |
| Settings | /clinic/settings | Account, payouts and preferences | Built (mock) |
| Onboarding | /clinic/onboarding | The wizard a new clinic completes to join the network | Built (mock) |
2.4 Functional requirements
Functional requirements are grouped by capability. Each is tagged Built or Planned. Identifiers (FR-x) are used by QA and the Developer API guide.
FR-A Discovery and marketplace
- FR-A1 (Built): Patients can browse clinics and filter by specialty, destination country, indicative price and rating.
- FR-A2 (Built): Patients can compare up to several clinics side by side on price, accreditation, reviews and capabilities.
- FR-A3 (Built): Patients can browse a treatment catalogue with indicative "from" pricing, reference home-market price, and typical savings.
- FR-A4 (Built): A match wizard guides a patient from condition and corridor to a shortlist of suitable clinics.
- FR-A5 (Built): Every indicative price is labelled as an estimate and never presented as a guaranteed quote.
FR-B Accounts and access
- FR-B1 (Built, mock): A user can sign in as a patient or a clinic using credential validation.
- FR-B2 (Built, mock): A user can register, verify an email by code, and reset a forgotten password.
- FR-B3 (Planned): Real authentication with email or OTP, SSO, session management, and MFA for staff roles.
- FR-B4 (Planned): Role-based access control across all personas with tenant isolation per case and corridor.
FR-C The 14-stage case lifecycle
- FR-C1 (Built, mock): A patient sees their case represented as 14 ordered stages, grouped Discover, Plan, Treat and Return, with the current stage highlighted and overall progress.
- FR-C2 (Built, mock): Tapping a stage opens a detail drawer describing that stage.
- FR-C3 (Planned): Each stage carries an accountable owner and an SLA target that the operations console tracks and escalates against. The owner and SLA fields already exist in the data model.
FR-D Medical records and consultation
- FR-D1 (Built, mock): A patient maintains a documents wallet holding identity, medical, visa, financial and travel documents, each with a verification status.
- FR-D2 (Planned): A specialist reviews submitted records and issues a written medical opinion, recorded against the case.
- FR-D3 (Planned): A transparent, itemised treatment quote is generated and shared with the patient.
- FR-D4 (Built, mock): A care plan shows pre-op, procedure, post-op and recovery phases with item status.
FR-E Visa and immigration engine
- FR-E1 (Built, mock): A patient sees a corridor-specific document checklist, a status hero (in review or granted), a reference number, fee, processing window and validity.
- FR-E2 (Built, mock): Checklist items linked to a document derive completion from that document's verified status.
- FR-E3 (Built, mock): The Submit application action is disabled until every checklist item is verified, and labels how many items remain.
- FR-E4 (Built, mock): Submitting advances the hero and the application timeline to granted.
- FR-E5 (Planned): A corridor-aware rules engine, driven by Country-Pack config, determines required documents, validation, fees, processing times and paper vs e-Visa routing.
- FR-E6 (Planned): Automatic invitation-letter generation and application packaging, with government-portal integration where available and a manual operations fallback otherwise.
FR-F Travel and logistics
- FR-F1 (Built, mock): A patient selects a preferred flight, accommodation, transfer and optional add-ons for their corridor and trip dates.
- FR-F2 (Built, mock): The Travel Desk's recommended option is highlighted in each list; the patient does not transact directly.
- FR-F3 (Planned): Selections are submitted to the Travel Desk and confirmed through airline, hotel and ground-transport integrations.
FR-G Payments and escrow
- FR-G1 (Built, mock): A patient sees the total, the amount held in escrow, the corridor currency, a milestone schedule (released, held, scheduled) and a ledger of entries.
- FR-G2 (Planned): Funds enter escrow on confirmation and release only as milestones are verified, with full pre-arrival refunds and reconciliation.
- FR-G3 (Planned): Multi-currency support per corridor, an auditable ledger, and finance-operations controls.
FR-H Messaging and notifications
- FR-H1 (Built, mock): A patient exchanges messages in threads with named care-team members; the composer appends a message and a canned reply.
- FR-H2 (Built, mock): Notifications and toasts surface journey updates; an unread badge appears in navigation.
- FR-H3 (Planned): Real-time secure messaging with attachments and audit trail, and omnichannel delivery prioritising WhatsApp, plus email, SMS and push, with interpreter support.
FR-I Reviews and reputation
- FR-I1 (Built): Reviews are aggregated from multiple sources with a verified-transaction percentage and a star distribution.
- FR-I2 (Built): A clinic can view its verified reviews in the console.
- FR-I3 (Planned): Verified reviews are captured at close-out from completed, attributed cases only.
FR-J Clinic management
- FR-J1 (Built, mock): A clinic manages its public profile, procedures and indicative pricing, team and surgeons, and settings.
- FR-J2 (Built, mock): A clinic triages inbound inquiries (new, quoted, accepted, declined) and tracks active cases by stage.
- FR-J3 (Built, mock): A new clinic completes an onboarding wizard before going live.
- FR-J4 (Planned): A clinic authors quotes and confirms milestones that trigger escrow release.
FR-K Administration and configuration (Planned)
- FR-K1 (Planned): An administrator configures Country Packs, versioned and feature-flagged, that drive the visa, payment, language and risk behaviour of each corridor.
- FR-K2 (Planned): An administrator manages the hospital panel, empanelment, and platform configuration.
FR-L Reporting and analytics (Planned)
- FR-L1 (Planned): Funnel analytics by corridor and channel, SLA and conversion dashboards, affiliate attribution, and outcome reporting.
2.5 Non-functional requirements
| Area | Requirement |
|---|---|
| Accessibility | Target WCAG 2.2 AA: semantic landmarks, labels on icon-only controls, decorative SVGs hidden from assistive tech, visible keyboard focus, AA-contrast text. |
| Responsiveness | Mobile-first. The portal and clinic sidebars collapse to an overlay below 880px; stat grids stack below 560px. The product must be fast and usable on a mid-range phone, the dominant device in target corridors. |
| Performance | Static-first delivery via CDN; self-hosted fonts with no runtime CDN fetch; no layout shift on load. Target sub-second first contentful paint on the marketing site. |
| Internationalisation (Planned) | Locale string tables, a language switcher, right-to-left layout and localised fonts for Arabic, Russian, French and Swahili corridors. The current build is English-only by design. |
| Security | Encryption in transit and at rest, least-privilege access, secrets never in source, and a full audit trail for clinical and financial actions. See Security. |
| Privacy and data residency | Per-corridor data-regime handling, consent capture, and DSAR support. See Legal and Compliance. |
| Reliability | Idempotent money and document operations, a manual operations fallback for every external integration, and graceful degradation when a provider is unavailable. |
| Auditability | Every escrow movement, document verification, consent change and visa submission is recorded immutably with actor, timestamp and before / after state. |
| Maintainability | A single typed data contract (lib/schema.ts) and a single data-access seam (lib/data.ts); one source of truth for screen documentation. |
| Observability (Planned) | Structured logs, metrics and traces; funnel, SLA and integration-health dashboards; alerting on milestone, visa and payment failures. |
2.6 Business rules and validation logic
These are the rules the product enforces or must enforce. They are the authoritative source for QA test cases and for support when explaining behaviour.
Pricing and quoting
- Every price shown before a formal quote is indicative and must be labelled as an estimate. It is never a guarantee.
- A formal quote is itemised: treatment, hospital, logistics and stay, and the facilitation fee are shown separately. Hidden markups are prohibited.
- Savings percentages are computed against a named home-market reference price and the reference country is always shown.
Escrow and payments
- Funds are held in escrow and release only on verified milestones (for example admission, procedure, discharge).
- Pre-arrival refunds are full. Refund rules tighten only after defined milestones are reached and must be disclosed up front.
- The facilitation fee is a B2B fee from the hospital, and affiliate payouts are marketing fees from Global Clinic's own margin. Neither is ever a clinical referral kickback or fee-split. This is a hard compliance boundary (see Legal and Compliance).
- Every ledger entry is immutable once posted; corrections are made by compensating entries, never by edits.
Visa engine
- Submit application is disabled until every checklist item is verified; the control states how many items remain.
- A checklist item linked to a document derives its completion from that document being verified, not from a manual toggle.
- Required documents, fees, processing windows and paper-vs-e-Visa routing are determined by the corridor's Country Pack, not hard-coded per patient (Planned for the rules engine; illustrative today).
- The e-Medical Attendant visa supports up to two accompanying blood relatives.
Documents
- A document has a type (Identity, Medical, Visa, Financial, Travel) and a status (pending or verified).
- Verification is performed by an authorised reviewer (Planned); a patient cannot self-verify.
- Uploads must pass file-type and size validation and virus scanning before storage (Planned), and are encrypted at rest.
Clinic and provider
- Only JCI or NABH-accredited hospitals with credentialed surgeons may be empanelled. Empanelment criteria are owned by the Medical Director.
- A clinic's public profile, pricing and reviews are visible only after it reaches verified status; pending and draft clinics are not publicly listed.
- An inquiry moves new to quoted to accepted or declined; a case moves Inquiry to Quoted to Treatment planned to In treatment to Recovery to Closed.
Reviews
- Reviews emphasise verified transactions. A verified review must be tied to a completed, attributed case.
- The platform displays a blended rating, a verified-transaction percentage, and the star distribution; it does not suppress negative verified reviews.
Quality and safety
- A 24/7 clinical escalation path exists for complications, with the Medical Director as backstop (Planned tooling; policy in force).
- Complaints and incidents are logged with time-bound resolution and fed back into hospital scorecards.
2.7 User permissions and role-based access control
The current build has two mock roles (patient and clinic). The production model defines the following roles and the surfaces each can reach. Access is deny by default; a role sees only what is listed.
| Role | Patient portal | Clinic console | Coordinator console (Planned) | Admin console (Planned) | Agent portal (Planned) |
|---|---|---|---|---|---|
| Patient | Full, own case only | None | None | None | None |
| Care Coordinator | Read and act on assigned cases | Read assigned cases | Full, assigned queue | None | None |
| Specialist / Medical | Read assigned case records | Read | Read and add opinions | None | None |
| Provider / Clinic | None | Full, own clinic only | Read shared case data | None | None |
| Visa operations | Read assigned case visa data | None | Read | None | None |
| Travel Desk | Read assigned case travel data | None | Read | None | None |
| Finance / Escrow | None | Read payout status | Read | Read ledgers | Read payouts |
| Administrator | None | Read all | Read all | Full | Read all |
| Agent / Affiliate | None | None | None | None | Full, own referrals only |
| Medical Director | Read | Read | Read all | Read governance config | None |
| Support agent | Read with consent | Read | Read | None | None |
Access-control principles:
- Tenant isolation. A patient sees only their own case; a clinic sees only its own clinic, inquiries, cases and team; an agent sees only its own attributed referrals.
- Case-scoped access. Coordinator, specialist, visa, travel and finance roles see only the cases assigned to them, not the whole population.
- Least privilege. Each role is granted the minimum surfaces and fields needed to do its job. Sensitive fields (financial account details, full medical records) are restricted within a role.
- Consent-gated support. Support access to a patient's case requires patient consent and is fully audited.
- Staff MFA. All staff roles (coordinator, specialist, visa, travel, finance, admin, medical director, support) require multi-factor authentication.
See the Developer security model for the technical enforcement of these rules.