Docs / Product Documentation

6. Edge Cases and Exception Handling

Cross-border care fails at the seams between parties, and a distributed platform fails at the seams between systems. This catalogue documents the major exception scenarios — functional and operational — and the defined response for each. It is the authoritative source for support playbooks, QA test cases, and the observability and alerting backlog. Many of the systems that automate these responses are Planned; where that is so it is marked, and the policy and operating procedure apply now.

6.0 How to read this section

Every entry follows the same seven-field shape so it can be reviewed, tested and implemented consistently:

Scenario — what the case is, in one line.
Trigger / condition — what causes it and how it is detected.
Expected system behaviour — the deterministic behaviour the platform must exhibit (Built or Planned).
User experience & messaging — what the patient or clinic sees, and the intent of the message.
Recovery & mitigation — the steps to resolve, the accountable owner, and how the case is prevented.
Logging, monitoring & alerting — the audit events, metrics and alerts the scenario must emit.
Severity / impact — the priority tier and the impact dimensions at stake.

Severity tiers align with the engineering severities in Operations:

P1 Critical (SEV1): patient safety, significant money, or a data / security breach at risk. Paged, 24/7 response.
P2 High (SEV2): journey-blocking. Same-day response within the stage SLA.
P3 Moderate (SEV3): recoverable with a clear path. Next-business-day response.

Impact dimensions referenced below: patient-safety, financial, regulatory, data-security, operational and reputational. A quick index of every scenario, its severity and its owner is in the coverage and severity matrix at the end.

6.1 Clinical and medical safety

Treatment complication after travel (P1)

Scenario: A complication arises during recovery or after the patient has returned home.
Trigger / condition: Patient or family reports via Messages or the 24/7 line; the clinic flags it during recovery; or a follow-up tele-consult surfaces it.
Expected system behaviour: The case exposes a one-tap route to the 24/7 clinical escalation path; no automated content is presented that could read as clinical advice; the complication and every escalation action are recorded on the case (Planned tooling; policy in force).
User experience & messaging: A direct line to the care team, a recorded escalation, and clear next steps — never an automated diagnosis.
Recovery & mitigation: Invoke the 24/7 escalation to the treating hospital and Medical Director; for a returned patient, coordinate with the home physician and treating surgeon, share records, and arrange a tele-consult or, if needed, readmission or local care. Owner: Medical Director (clinical), Care Coordinator (logistics). Prevention: structured follow-up at 7, 30 and 90 days; documented discharge summary and medicines; continuity with the home GP.
Logging, monitoring & alerting: Log the escalation event (actor, timestamp, case) to the audit trail; page the on-call clinical escalation; track time-to-acknowledge against the 24/7 SLA; feed the hospital scorecard.
Severity / impact: P1 Critical — patient-safety, reputational. Maps to SEV1.

Acute or life-threatening emergency (P1)

Scenario: An acute, life-threatening event occurs at any point in the journey.
Trigger / condition: Patient or family reports an emergency; the product is explicit that it is not for emergencies.
Expected system behaviour: Every relevant surface prominently instructs the patient to contact local emergency services first; the care plan and arrival materials surface the corridor emergency number from the Country Pack; no automated clinical triage is attempted.
User experience & messaging: A prominent "call local emergency services" instruction, the corridor emergency contact, and the separate escalation path for non-emergency complications.
Recovery & mitigation: The patient or family contacts local emergency services; the coordinator then mobilises the in-country team and hospital. Owner: Care Coordinator; in-country team. Prevention: emergency guidance surfaced on arrival and in the care plan; corridor numbers in the Country Pack.
Logging, monitoring & alerting: Record the reported emergency and coordinator mobilisation on the case; alert the in-country team.
Severity / impact: P1 Critical — patient-safety. Maps to SEV1.

Accident or injury to a patient or attendant (P1)

Scenario: A patient or an accompanying attendant suffers an accident or injury unrelated to the treatment (a fall, a road accident, an injury at the hotel) while in the destination country.
Trigger / condition: The patient, attendant, hospital or in-country team reports an accident or injury that is distinct from a treatment complication.
Expected system behaviour: The case surfaces the emergency guidance (local emergency services first) and the in-country contact; the event is recorded; any cost arising is treated as separate from the treatment escrow and clarified as travel-insurance or self-pay, not facilitation scope.
User experience & messaging: Immediate emergency instructions, the in-country team's number, and clear, honest guidance that injury care is separate from the planned treatment and how it is paid for.
Recovery & mitigation: The in-country team coordinates urgent care for the patient or attendant, liaises with the hospital, and supports any insurance claim; reschedule the treatment if the patient's fitness is affected. Owner: In-country team; Care Coordinator; Medical Director if it affects fitness for the procedure. Prevention: pre-travel travel-insurance guidance covering the patient and attendants; safe, attendant-friendly accommodation near the hospital.
Logging, monitoring & alerting: Record the incident and the care provided; alert the coordinator and, if fitness is affected, the Medical Director; track the impact on the surgery date.
Severity / impact: P1 Critical — patient-safety, operational. Maps to SEV1 (SEV2 if minor and the treatment is unaffected).

Intercurrent illness or unfitness for treatment (P2)

Scenario: The patient (or an attendant) becomes ill during the journey — for example an infection, fever or an uncontrolled comorbidity — affecting fitness for the planned procedure.
Trigger / condition: Pre-operative assessment or the care team finds the patient unfit for surgery, or the patient or attendant reports illness; an infectious illness may require isolation.
Expected system behaviour: The procedure is held rather than performed on an unfit patient; the surgery date moves; visa validity, travel and escrow milestones are flagged for realignment; an infectious case triggers isolation and any public-health obligations.
User experience & messaging: A clear, clinically-led explanation that the procedure is postponed for safety, the revised plan, and reassurance that dates, visa and travel will be kept in sync.
Recovery & mitigation: Treat or stabilise the intercurrent illness; reschedule the procedure when the patient is fit; realign visa (an extension if needed), travel and escrow; isolate and report a notifiable infection. Owner: Hospital and Medical Director (clinical); Care Coordinator (logistics). Prevention: pre-travel fitness screening; honest pre-op expectation-setting; a buffer between arrival and admission.
Logging, monitoring & alerting: Record the fitness decision and reschedule; alert the coordinator; monitor postponement reasons; flag any notifiable disease to the responsible function.
Severity / impact: P2 High — patient-safety, operational. Maps to SEV2.

Patient death or critical deterioration abroad (P1)

Scenario: A patient dies or critically deteriorates before, during or after the procedure in the destination country.
Trigger / condition: The hospital or in-country team reports the event, or a family member contacts the care team.
Expected system behaviour: The case enters a sensitive hold that suppresses routine automation — pending notifications, marketing, review requests and milestone prompts are stopped; escrow movement is halted and placed on hold pending review; the event is recorded under the highest audit and access controls.
User experience & messaging: No automated journey messaging reaches the family; all contact is human, through the Medical Director and a designated coordinator, handled with sensitivity and in the family's language.
Recovery & mitigation: Engage the Medical Director, the hospital and, where relevant, the consulate or embassy for documentation and repatriation of remains; coordinate death certification, records release to the family, and any insurer; hold all escrow and apply the disclosed policy with discretion. Owner: Medical Director; Care Coordinator; Finance. Prevention: pre-travel fitness assessment and honest risk disclosure; clear next-of-kin and emergency-contact capture at intake.
Logging, monitoring & alerting: Open a SEV1 incident; set the case "sensitive hold" flag that gates automated comms; preserve a full audit trail; restrict case access to the handling team; notify leadership and compliance.
Severity / impact: P1 Critical — patient-safety, reputational, regulatory. Maps to SEV1.

Scenario: The patient is a minor or a legally dependent adult, so a parent or guardian must consent and accompany care.
Trigger / condition: Intake captures a date of birth under the age of consent, or a guardianship / dependency flag.
Expected system behaviour: Verified guardian identity and a recorded guardian consent are required before clinical review, record sharing or tele-consults proceed; guardian consent is captured in the consent ledger and bound to the patient's case (Planned).
User experience & messaging: A clear explanation that a parent or guardian must consent and attend, guardian-specific document and consent prompts, and stricter handling of the minor's data.
Recovery & mitigation: If guardian identity or consent is missing, pause the relevant processing and request the specific proof; route ambiguous guardianship to compliance. Owner: Care Coordinator; Compliance. Prevention: age and guardianship checks at intake; guardian attendance required for tele-consults.
Logging, monitoring & alerting: Record guardian identity verification and each guardian consent grant or withdrawal; alert if a clinical step is attempted on a minor's case without a valid guardian consent.
Severity / impact: P2 High — regulatory, patient-safety. Maps to SEV2.

Treatment refused or withdrawn — by patient or provider (P2)

Scenario: The patient refuses or withdraws consent for the planned treatment, or the provider declines to perform it (clinically contraindicated, unacceptable conditions, or an inability to give informed consent).
Trigger / condition: The patient declines or withdraws consent at any point before the procedure, or the surgeon or hospital refuses on medical or ethical grounds.
Expected system behaviour: The platform records the decision without applying clinical pressure (facilitator, not provider); a patient refusal opens the cancellation and refund path per the disclosed schedule; a provider refusal opens a second opinion, an alternative empanelled provider, or a refund.
User experience & messaging: Respect for the patient's autonomy and an honest explanation of the options and the financial impact; for a provider refusal, a transparent reason and clear next steps — never coercion.
Recovery & mitigation: For a patient refusal, process cancellation and the applicable refund and unwind visa and travel; for a provider refusal, arrange a re-opinion or an alternative provider, or refund. Owner: Care Coordinator; Medical Director; Finance for refunds. Prevention: thorough informed-consent and expectation-setting before travel; confirm provider acceptance and fitness criteria at quote acceptance.
Logging, monitoring & alerting: Record the refusal or withdrawal with reason and consent state; log any refund; monitor refusal rates by provider as a quality signal.
Severity / impact: P2 High — patient-safety, financial, regulatory (consent). Maps to SEV2.

Scenario: The patient becomes unable to give informed consent (unconscious, sedated, or otherwise incapacitated) and a decision is needed.
Trigger / condition: The clinical team determines the patient lacks capacity and no valid consent covers the needed decision.
Expected system behaviour: Decisions defer to the recorded surrogate or next of kin and the treating clinicians under local law; emergency clinical access uses the audited break-glass path; the platform records, but does not make, the clinical decision.
User experience & messaging: The surrogate or next of kin is engaged by the care team, in their language, with clear information; no automated decisioning.
Recovery & mitigation: Engage the surrogate or next of kin and the Medical Director; act under the hospital's emergency and consent protocols; document the basis. Owner: Medical Director; Care Coordinator. Prevention: capture the next of kin, a surrogate, and an emergency-consent preference at intake.
Logging, monitoring & alerting: Record capacity determinations and surrogate decisions; alarm and audit any break-glass access; restrict and log case access.
Severity / impact: P1 Critical — patient-safety, regulatory. Maps to SEV1.

Missing or inadequate medical records (P2)

Scenario: Records needed for triage, opinion or the quote are missing, unreadable or incomplete.
Trigger / condition: The consultation workflow flags specific gaps during specialist review.
Expected system behaviour: The opinion clock pauses; the case lists the specific missing items with an upload action; the linked checklist stays pending until valid records exist (Planned OCR-assisted completeness checks).
User experience & messaging: A precise list of what is missing and why, with examples and a direct upload action — never a generic "resubmit everything".
Recovery & mitigation: Request the specific missing records and resume the clock on receipt. Owner: Care Coordinator; Specialist. Prevention: a records checklist by condition captured at intake.
Logging, monitoring & alerting: Log records requested and received; track opinion-clock pause duration against the triage SLA; alert on cases stalled beyond a threshold.
Severity / impact: P2 High — operational (journey-blocking). Maps to SEV2.

Cross-border tele-follow-up — licensing and prescribing limits (P3)

Scenario: A 7 / 30 / 90-day tele-consult crosses medical-licensing jurisdictions, limiting diagnosis or prescribing into the patient's home country.
Trigger / condition: A scheduled tele-follow-up where the treating clinician is not licensed in the patient's country of residence, or a prescription would cross borders.
Expected system behaviour: The follow-up is framed as continuity coordination, not new home-country diagnosis; prescriptions route through the home physician; the platform records the opinion as the specialist's, consistent with the facilitator-not-provider posture.
User experience & messaging: Honest framing that the tele-consult supports continuity and that new prescriptions or diagnoses are handled by the home physician; no implied home-country treatment.
Recovery & mitigation: Coordinate with the home physician for prescriptions and onward care; involve a locally licensed clinician where required. Owner: Care Coordinator; Medical Director. Prevention: capture the home physician at discharge; note corridor licensing constraints in the Country Pack.
Logging, monitoring & alerting: Record each tele-consult and any home-physician hand-off; monitor follow-up completion rates at 7, 30 and 90 days.
Severity / impact: P3 Moderate — regulatory, patient-safety. Maps to SEV3.

Adverse-outcome dispute or malpractice claim (P2)

Scenario: A patient is dissatisfied with the clinical outcome and disputes it, alleges negligence, or seeks compensation.
Trigger / condition: A complaint, an adverse-outcome report, or a legal or compensation demand following treatment.
Expected system behaviour: The complaint is logged with a time-bound resolution and fed to the hospital scorecard; the facilitator-not-provider boundary holds — clinical liability rests with the treating provider; relevant escrow may be held pending review; records and the audit trail are preserved.
User experience & messaging: Honest acknowledgement, a clear complaints process, and signposting that clinical responsibility sits with the treating hospital and surgeon, with the platform coordinating.
Recovery & mitigation: The Medical Director reviews; coordinate between the patient and the provider; preserve records; involve counsel and insurers where a claim is made. Owner: Medical Director; Legal / Compliance; Care Coordinator. Prevention: clear consent and outcome disclaimers (no guaranteed outcomes); verified accreditation and credentialing; structured follow-up.
Logging, monitoring & alerting: Log the dispute and resolution; preserve clinical records and the audit trail; monitor complaint and outcome-dispute rates per provider.
Severity / impact: P2 High — reputational, regulatory, financial (P1 if patient-safety or a serious claim is involved). Maps to SEV2.

6.2 Visa and immigration

Visa rejection (P2, journey-critical)

Scenario: The government authority rejects the medical or attendant visa.
Trigger / condition: A rejection status from the government channel or operations.
Expected system behaviour: The application moves to a rejected state with the reason where available; the visa exception playbook is offered; if the trip cannot proceed, the full pre-arrival escrow refund is triggered.
User experience & messaging: An honest status with the reason, the remediation plan, and — if applicable — confirmation that funds are protected and refundable.
Recovery & mitigation: The visa desk reviews the reason, corrects and resubmits where possible, or routes to an alternative visa type or corridor; failing that, refund. Owner: Visa operations; Finance for refunds. Prevention: the Country Pack encodes the correct document set and validation up front, reducing avoidable rejections.
Logging, monitoring & alerting: Log submission and rejection with reason codes; track rejection rate per corridor; alert on a corridor rejection-rate spike (an avoidable-error signal).
Severity / impact: P2 High — financial, operational, reputational; journey-critical. Maps to SEV2.

Visa processing delay (P2)

Scenario: Processing exceeds the corridor's expected window.
Trigger / condition: Elapsed processing time passes the Country Pack's expected window without a decision.
Expected system behaviour: The timeline shows the in-progress step and a realistic revised estimate; travel holds are flagged so flights and stay can be realigned; the surgery date can be rescheduled with the hospital.
User experience & messaging: The timeline's current step, a realistic revised estimate, and reassurance that travel is being kept in sync.
Recovery & mitigation: The visa desk expedites where a channel exists; the Travel Desk holds or adjusts flights and stay; reschedule surgery if needed. Owner: Visa operations; Travel Desk. Prevention: start the visa workflow as soon as escrow is funded; run visa and logistics in parallel.
Logging, monitoring & alerting: Track processing time per corridor against the SLA; alert on SLA breach; record expedite actions.
Severity / impact: P2 High — operational. Maps to SEV2.

Invitation-letter or identity data mismatch (P2)

Scenario: The hospital invitation letter or application carries a missing passport number or a name / date-of-birth mismatch across documents — a leading avoidable rejection cause.
Trigger / condition: Validation finds the invitation or application fields do not match the verified passport and records, or a required field such as the passport number is blank.
Expected system behaviour: Submission is blocked until fields reconcile; the Country Pack validation cross-checks invitation, passport and application data before packaging (Planned rules engine; manual check today).
User experience & messaging: A specific prompt naming the mismatched field (for example "passport number missing on the invitation letter") and how to correct it — not a generic error.
Recovery & mitigation: Regenerate the invitation letter or correct the field, then re-validate before submission. Owner: Visa operations; Hospital for the letter. Prevention: auto-populate the invitation from verified identity data; field-level validation at packaging.
Logging, monitoring & alerting: Log validation failures by field; monitor mismatch frequency as a data-quality metric; alert if a submission bypasses validation.
Severity / impact: P2 High — operational; financial if it causes a rejection. Maps to SEV2.

FRRO registration lapse after arrival (P2)

Scenario: A foreign patient on a medical visa does not register with the Foreigners Regional Registration Office within the required window after arrival in India (14 days), risking penalties and treatment disruption.
Trigger / condition: Arrival is recorded but FRRO registration is not confirmed within the corridor's deadline.
Expected system behaviour: On arrival the system schedules and tracks the FRRO registration task with a countdown; reminders fire ahead of the deadline; the task is part of the arrival checklist (Planned).
User experience & messaging: A clear post-arrival task with the deadline, an explanation of what FRRO registration is, the documents needed, and coordinator support to complete it.
Recovery & mitigation: The in-country team assists with e-FRRO registration; if the window is missed, support the patient through the penalty or clearance process. Owner: In-country team; Visa operations. Prevention: an arrival checklist item with a 14-day countdown and reminders; the corridor rule encoded in the Country Pack.
Logging, monitoring & alerting: Track FRRO registration status per case; alert as the deadline approaches and on lapse; report registration completion rate.
Severity / impact: P2 High — regulatory, operational. Maps to SEV2.

Visa overstay from extended treatment or complications (P1)

Scenario: Treatment or recovery runs longer than the visa validity, so the patient risks overstaying — with consequences ranging from fines to deactivated SIMs, frozen accounts, deportation and blacklisting.
Trigger / condition: The projected discharge or return date approaches or exceeds visa validity, or a complication extends the stay.
Expected system behaviour: The system flags the visa-validity-versus-stay gap, surfaces the extension path (an e-FRRO medical extension), and keeps travel re-booking and escrow milestones aligned to the new dates.
User experience & messaging: An early, honest alert that the stay may exceed the visa, with the extension steps, the medical certificate needed, and reassurance that the team will manage it.
Recovery & mitigation: The visa desk files a medical extension with a fresh hospital certificate before expiry; realign flights and stay; if denied, arrange a compliant departure. Owner: Visa operations; In-country team; Medical Director for the certificate. Prevention: monitor projected stay against validity from admission; buffer visa validity at application.
Logging, monitoring & alerting: Monitor visa-validity-minus-projected-stay per active case; alert when the buffer falls below a threshold and on any overstay; log extension submissions and outcomes.
Severity / impact: P1 Critical — regulatory (patient legal jeopardy), reputational. Maps to SEV1.

Patient or attendant does not return home (P1)

Scenario: After treatment, the patient or an attendant does not leave the country and is unreachable — a non-medical overstay or absconding, which can amount to immigration-rule misuse and creates exposure for the invitation sponsor.
Trigger / condition: The expected departure passes with no exit recorded, the visa lapses without a medical-extension basis, and contact is lost — distinct from a medical-necessity overstay.
Expected system behaviour: The case flags a non-medical overstay; automated journey messaging stops; the platform documents its contact attempts and cooperates with the FRRO and authorities as required; it does not conceal or facilitate an unlawful stay.
User experience & messaging: Repeated, multi-channel outreach with clear, factual warnings about overstay consequences (fines, deportation, blacklisting, and the Exit Permit requirement) and an offer to help with a lawful extension or departure.
Recovery & mitigation: The in-country team and visa ops attempt contact and offer a lawful path (a medical extension if justified, or assisted departure with an FRRO Exit Permit); escalate to compliance; report to authorities where legally required; cooperate with the FRRO as the invitation sponsor. Owner: Visa operations; In-country team; Compliance. Prevention: clear pre-travel terms on return obligations; corridor riskTier and enhanced KYC; realistic return-date capture.
Logging, monitoring & alerting: Track expected-versus-actual departure per case; alert on a lapse with lost contact; log every outreach and any authority notification; feed corridor risk monitoring.
Severity / impact: P1 Critical — regulatory (immigration, sponsor exposure), reputational. Maps to SEV1.

Lost or stolen passport or travel documents abroad (P2)

Scenario: The patient or an attendant loses their passport, or it is stolen, while in the destination country, blocking their return.
Trigger / condition: A reported loss or theft of a passport or essential travel document in-country.
Expected system behaviour: The case surfaces the recovery steps (a police FIR, an embassy replacement, then an FRRO exit permit) and tracks them; travel and escrow are realigned to the new departure date.
User experience & messaging: A clear, step-by-step recovery path — file a police report, obtain a replacement from the embassy, then apply for the FRRO exit permit (which takes several business days) — with coordinator support throughout.
Recovery & mitigation: The in-country team helps file the FIR, reach the relevant embassy or consulate, and complete the FRRO exit-permit application; rebook travel and adjust the stay. Owner: In-country team; Travel Desk. Prevention: advise patients to keep copies and store documents securely; on-campus or partner accommodation.
Logging, monitoring & alerting: Record the incident and the recovery steps; monitor time-to-resolution; alert the Travel Desk to realign the departure.
Severity / impact: P2 High — operational; journey-blocking for the return. Maps to SEV2.

Attendant visa exceeds the two-relative limit (P3)

Scenario: A patient needs more accompanying people than the e-Medical Attendant visa allows (up to two blood relatives).
Trigger / condition: The traveller list for the attendant visa exceeds two, or includes a non-blood relative.
Expected system behaviour: The attendant-visa flow caps eligible attendants at two blood relatives and explains the limit; additional or ineligible companions are routed to an alternative visa category.
User experience & messaging: A clear explanation of the two-relative limit and the alternative routes for additional companions — no silent failure at submission.
Recovery & mitigation: Advise additional companions to apply under a separate appropriate visa; confirm relationship evidence for the two attendants. Owner: Visa operations. Prevention: encode the attendant limit and eligibility in the Country Pack and the visa form.
Logging, monitoring & alerting: Validate attendant count and eligibility at submission; log rejections of over-limit attempts.
Severity / impact: P3 Moderate — operational. Maps to SEV3.

6.3 Travel and logistics

Flight cancellation or travel disruption (P2)

Scenario: A carrier cancels or significantly changes a flight, or weather or strikes disrupt travel.
Trigger / condition: A flight.changed or flight.cancelled webhook from the travel provider, or an operations report.
Expected system behaviour: The itinerary updates on the Journey concierge card; the system flags the admission-timing impact; escrow and the surgery date are adjusted as needed; on provider failure the manual Travel Desk fallback drives the rebooking.
User experience & messaging: The updated itinerary, a notification, and a coordinator message — never a dead end.
Recovery & mitigation: The Travel Desk rebooks the nearest suitable option, realigns airport pickup, and notifies the hospital if admission timing shifts. Owner: Travel Desk. Prevention: flexible medical fares; a buffer between arrival and admission.
Logging, monitoring & alerting: Ingest travel webhooks idempotently; log rebooking actions; monitor booking success rate; alert the Travel Desk on disruptions affecting imminent admissions.
Severity / impact: P2 High — operational; patient-safety if admission timing is affected. Maps to SEV2.

Accommodation unavailable or unsuitable (P3)

Scenario: The selected stay is unavailable, overbooked or unsuitable (for example, no attendant bed).
Trigger / condition: A stay.unavailable webhook, or a re-check at confirmation finds the option gone or non-conforming.
Expected system behaviour: Availability is re-checked before confirmation; an equivalent attendant-friendly alternative near the hospital is proposed; the selection stays editable.
User experience & messaging: An editable selection and a clear alternative — no dead end.
Recovery & mitigation: The Travel Desk proposes and rebooks an equivalent property. Owner: Travel Desk. Prevention: confirm availability against trip dates before presenting options; prefer on-campus or partner properties.
Logging, monitoring & alerting: Log availability checks and rebookings; monitor availability hit rate.
Severity / impact: P3 Moderate — operational. Maps to SEV3.

Fare or rate change between selection and ticketing (P3)

Scenario: A flight fare or hotel rate changes between the patient's selection and the Travel Desk's ticketing or confirmation.
Trigger / condition: Re-pricing at booking returns a different fare or rate than the indicative price shown.
Expected system behaviour: All travel prices are indicative; the fare is revalidated before ticketing; a material change is surfaced for confirmation rather than silently charged.
User experience & messaging: The price was indicative; here is the current price; confirm to proceed or choose an alternative.
Recovery & mitigation: Re-present the option at the current price or offer alternatives; the Travel Desk confirms within the agreed budget. Owner: Travel Desk. Prevention: label all fares indicative; re-validate fares at booking; keep selection-to-ticketing windows short.
Logging, monitoring & alerting: Log fare deltas; monitor fare-change frequency; alert on large deltas.
Severity / impact: P3 Moderate — financial (minor), operational. Maps to SEV3.

Force majeure — disaster, unrest or border closure stranding a patient (P1)

Scenario: A natural disaster, civil unrest, pandemic measure or sudden border or airport closure disrupts an in-flight journey or strands a patient or attendants in the destination.
Trigger / condition: A travel advisory, an airspace or border closure, or a major disruptive event affects the corridor or destination while a case is in progress.
Expected system behaviour: The system flags affected in-flight cases; travel rebooking, extended stay and escrow timelines realign; safety guidance is surfaced; funds remain protected; new-case intake on the corridor may pause (see corridor restriction).
User experience & messaging: Timely safety guidance, the in-country contact, and an honest status on travel, treatment and money, in the patient's language.
Recovery & mitigation: The in-country team prioritises patient and attendant safety and shelter; the Travel Desk rebooks when routes reopen and extends the stay; coordinate with the embassy and local authorities; hold and protect escrow. Owner: In-country team; Travel Desk; Administrator. Prevention: corridor diversification; flexible fares; contingency guidance in the Country Pack.
Logging, monitoring & alerting: Monitor travel advisories and corridor disruption; alert on events affecting active cases; log realignments and safety outreach.
Severity / impact: P1 Critical — patient-safety, operational, financial. Maps to SEV1.

6.4 Provider and scheduling

Clinic cancellation or rescheduling (P2)

Scenario: The hospital must move or cancel the procedure date (surgeon unavailability, capacity, clinical reasons).
Trigger / condition: The clinic updates the case date or notifies operations.
Expected system behaviour: The case reflects the new or at-risk date; visa validity and travel are flagged for realignment; escrow milestones adjust; if no acceptable option exists, the cancellation and refund path opens.
User experience & messaging: A transparent reason, options, and the impact on travel, visa and money.
Recovery & mitigation: The coordinator secures the earliest acceptable alternative date or an alternative empanelled clinic and realigns everything; otherwise the patient may cancel with the applicable refund. Owner: Care Coordinator; Provider. Prevention: confirm surgeon and date at quote acceptance; hold provisional dates during the funnel.
Logging, monitoring & alerting: Log the change with reason against the hospital scorecard; alert the coordinator; monitor reschedule rate per clinic.
Severity / impact: P2 High — operational, reputational. Maps to SEV2.

Provider no-show or unresponsiveness (P2)

Scenario: The clinic fails to confirm, respond within SLA, or appear for a scheduled step.
Trigger / condition: An SLA timer expires without clinic response, or a scheduled step is missed.
Expected system behaviour: The coordinator console raises the breach (Planned SLA timers); the case can be re-routed to an alternative empanelled clinic; the lapse is recorded on the scorecard.
User experience & messaging: The patient experiences continuity — the coordinator steps in and, if needed, moves the case — without being exposed to the provider failure.
Recovery & mitigation: Escalate within the clinic, then to the Medical Director; re-route to an alternative empanelled clinic if unresolved. Owner: Care Coordinator; Medical Director. Prevention: SLA timers in the coordinator console (Planned); empanelment standards and scorecards.
Logging, monitoring & alerting: Log SLA breaches; alert on breach; feed the hospital scorecard; monitor responsiveness per clinic.
Severity / impact: P2 High — operational, reputational. Maps to SEV2.

Patient no-show (P3)

Scenario: The patient misses a scheduled consultation, admission or follow-up.
Trigger / condition: A scheduled step elapses without patient attendance.
Expected system behaviour: Reminders fire across channels ahead of the appointment; an easy reschedule path is offered; escrow and dates are held within policy.
User experience & messaging: Reminders before the appointment and a one-tap reschedule.
Recovery & mitigation: The coordinator attempts multi-channel contact (Messages, WhatsApp, phone), reschedules and documents. Owner: Care Coordinator. Prevention: confirmations and reminders across channels; the named-coordinator relationship.
Logging, monitoring & alerting: Log no-shows and contact attempts; monitor no-show rate; alert the coordinator.
Severity / impact: P3 Moderate — operational. Maps to SEV3.

Clinic accreditation lapse or empanelment suspension (P1)

Scenario: An empanelled hospital's JCI or NABH accreditation expires or is suspended, or a quality concern triggers suspension — potentially with active cases in flight.
Trigger / condition: An accreditation expiry date passes, or a quality or complaint signal crosses the scorecard threshold; admin or Medical Director review.
Expected system behaviour: The clinic's status drops from verified, removing it from public listing and new-inquiry routing; in-flight cases are flagged for Medical Director review; new bookings to the clinic are blocked.
User experience & messaging: New patients no longer see the clinic; affected in-flight patients receive honest communication and options (continue under review, or transfer) — no alarm, clear protection.
Recovery & mitigation: Pause new cases; the Medical Director assesses in-flight cases for safety; offer transfer to an alternative empanelled clinic with travel, visa and escrow realignment; refund where appropriate. Owner: Administrator; Medical Director. Prevention: track accreditation expiry dates with advance alerts; continuous scorecard monitoring.
Logging, monitoring & alerting: Alert ahead of accreditation expiry; log status changes; monitor scorecard thresholds; report affected active cases.
Severity / impact: P1 Critical — patient-safety, regulatory, reputational. Maps to SEV1.

6.5 Payments, refunds and escrow

Payment failure at funding (P2)

Scenario: A card or transfer fails during escrow funding.
Trigger / condition: A payment.failed response from the payment provider.
Expected system behaviour: No funds are partially captured; the case stays at the Deposit stage; the patient is offered retry or a corridor-appropriate alternative method; the operation is idempotent so retries never double-charge.
User experience & messaging: "Payment did not go through" with safe retry options and no ambiguity about whether they were charged.
Recovery & mitigation: Retry or switch method (bank transfer, mobile money); escalate to Finance if the outcome is ambiguous. Owner: Finance; Care Coordinator. Prevention: validate method and currency for the corridor before charging; idempotent payment operations.
Logging, monitoring & alerting: Log the failure with mapped error code; monitor fund success rate; alert Finance on repeated or ambiguous failures.
Severity / impact: P2 High — financial, operational. Maps to SEV2.

Duplicate or double-charged payment (P2)

Scenario: A retry, double submit, or duplicate webhook risks charging the patient twice or posting a duplicate ledger entry.
Trigger / condition: The same payment intent is submitted or retried, or a payment.succeeded webhook is delivered more than once.
Expected system behaviour: Every money operation carries an idempotency key; duplicate intents and replayed webhooks are recognised and collapse to a single exactly-once ledger entry; no second charge occurs.
User experience & messaging: The patient sees a single charge; if a duplicate was attempted, the UI confirms only one payment was taken.
Recovery & mitigation: If a duplicate did post, reverse it with a compensating ledger entry and refund the duplicate. Owner: Finance. Prevention: idempotency keys; client double-submit guards; idempotent webhook handlers.
Logging, monitoring & alerting: Log idempotency-key hits and de-duplicated webhooks; monitor duplicate-attempt rate; alert on any double-capture detected in reconciliation.
Severity / impact: P2 High — financial. Maps to SEV2.

Milestone verified but escrow release fails (P1)

Scenario: A milestone (admission, procedure, discharge) is verified, but the escrow release to the provider fails or is interrupted.
Trigger / condition: The release call errors, times out, or the partner returns an indeterminate result.
Expected system behaviour: The release is idempotent and retried with backoff; the ledger reflects released, held and scheduled tranches exactly; on persistent failure the breaker trips to the manual finance fallback; no partial or double release occurs.
User experience & messaging: The patient's milestone status is accurate; the clinic sees the release as pending until confirmed; no contradictory states.
Recovery & mitigation: Finance reconciles against the partner and completes the release manually if needed; never improvise a release. Owner: Finance. Prevention: idempotent, exactly-once releases; reconciliation; circuit-breaker fallback.
Logging, monitoring & alerting: Log release attempts and outcomes; monitor release latency; page Finance on money-path failure and on any reconciliation mismatch.
Severity / impact: P1 Critical — financial. Maps to SEV1.

Refund request and dispute (P2)

Scenario: The patient cancels or disputes a charge or service.
Trigger / condition: A cancellation request or a dispute notice.
Expected system behaviour: The disclosed refund schedule applies (full pre-arrival; partial after defined milestones); the relevant escrow tranche is placed on hold during review; resolution is time-bound and recorded.
User experience & messaging: The refund policy that applied, the amount, and the status — transparent throughout.
Recovery & mitigation: Finance applies the schedule and resolves within the window. Owner: Finance; Care Coordinator. Prevention: disclose the refund schedule before any payment; itemised, transparent pricing.
Logging, monitoring & alerting: Log the hold, decision and refund; monitor refund SLA; alert on aged disputes.
Severity / impact: P2 High — financial, reputational. Maps to SEV2.

Patient-initiated cancellation mid-journey (P2)

Scenario: The patient decides to cancel after the process has started — after funding escrow, after the visa is issued, or after travel is booked but before or around treatment.
Trigger / condition: The patient requests cancellation at any stage of the journey.
Expected system behaviour: The disclosed refund schedule applies by stage (full pre-arrival; partial after defined milestones); the platform unwinds the dependent commitments — withdraws or closes the visa invitation, cancels travel bookings, and releases the provider slot — and places escrow on hold pending the refund calculation.
User experience & messaging: A transparent statement of the refund that applies at the current stage, what is unwound, and the timeline — no penalty surprises and no dead end.
Recovery & mitigation: Finance applies the stage-appropriate refund; the coordinator unwinds the visa, travel and provider commitments and documents the closure. Owner: Finance; Care Coordinator; Visa operations and Travel Desk for unwinding. Prevention: disclose the stage-by-stage refund schedule before any payment; keep commitments reversible as late as possible.
Logging, monitoring & alerting: Log the cancellation, the refund calculation and each unwound commitment; monitor mid-journey cancellation rate and reasons; alert Finance and the desks.
Severity / impact: P2 High — financial, operational. Maps to SEV2.

Chargeback after escrow release (P2)

Scenario: A patient files a card chargeback after funds have already been released on a verified milestone; cross-border chargebacks add jurisdictional complexity.
Trigger / condition: A chargeback or dispute webhook from the payment partner on an already-released tranche.
Expected system behaviour: The dispute is recorded against the case and ledger; remaining tranches are placed on hold; the milestone evidence (verification, audit trail, itemised invoice in both currencies) is assembled for representment.
User experience & messaging: The patient is contacted to understand and resolve the dispute; clinic-side funds already paid are handled per the partner agreement, not clawed back without process.
Recovery & mitigation: Finance submits representment evidence; engage the provider on recovery if the chargeback stands. Owner: Finance. Prevention: retain milestone evidence and dual-currency records; clear disclosures reduce disputes.
Logging, monitoring & alerting: Log the dispute lifecycle; monitor chargeback rate per corridor; alert Finance on any post-release chargeback.
Severity / impact: P2 High — financial, regulatory. Maps to SEV2.

Currency fluctuation between payment and refund (P3)

Scenario: Exchange-rate movement means a refund in the patient's currency differs from the amount originally paid.
Trigger / condition: A refund is processed in a different exchange-rate environment than the original multi-currency payment.
Expected system behaviour: The ledger records amounts in both corridor and settlement currency; the refund policy defines whether the original-currency amount or the reconverted amount is returned; the difference is transparent.
User experience & messaging: A clear statement of the refund amount, the currency, and why it may differ from the original due to exchange rates.
Recovery & mitigation: Apply the disclosed exchange-rate-handling rule consistently; Finance resolves disputes about the delta. Owner: Finance. Prevention: disclose exchange-rate handling in the terms; record both currencies on every entry.
Logging, monitoring & alerting: Log the rates applied to charge and refund; monitor exchange-rate-delta complaints; reconcile both-currency ledgers.
Severity / impact: P3 Moderate — financial. Maps to SEV3.

Ledger reconciliation break (P1)

Scenario: The internal append-only ledger disagrees with the payment or escrow partner's records (a reconciliation mismatch).
Trigger / condition: Scheduled reconciliation against the partner file or API finds an unmatched or divergent entry.
Expected system behaviour: The break is quarantined and flagged; affected tranches are held; no automated release proceeds against a disputed balance; corrections are made only by compensating entries.
User experience & messaging: Patient-facing balances remain consistent and conservative; no contradictory or speculative figures are shown while a break is open.
Recovery & mitigation: Finance investigates and reconciles against the partner, posts compensating entries, and documents the root cause. Owner: Finance. Prevention: daily reconciliation; idempotent, exactly-once money operations; an immutable ledger.
Logging, monitoring & alerting: Page on any reconciliation mismatch; log the break and its resolution; monitor reconciliation-break count and age.
Severity / impact: P1 Critical — financial, regulatory. Maps to SEV1.

Insurance pre-authorisation or reimbursement shortfall (P3)

Scenario: Expected insurance coverage, pre-authorisation or reimbursement does not materialise; most cases are self-pay, and many home policies exclude treatment abroad.
Trigger / condition: An insurer or employer declines pre-authorisation or a reimbursement claim, or none was ever in place.
Expected system behaviour: The platform sets self-pay as the default; it provides itemised, claim-ready documentation; pre-authorisation is coordinated only where a partnership exists.
User experience & messaging: Honest expectation-setting (no implied coverage) and claim-ready invoices the patient can submit.
Recovery & mitigation: Provide documentation for the patient's own claim; coordinate with the insurer or employer where a partnership exists; fall back to self-pay. Owner: Care Coordinator; Finance. Prevention: set self-pay expectations at intake; develop employer and insurer partnerships (Planned).
Logging, monitoring & alerting: Log pre-authorisation requests and outcomes; monitor pre-authorisation turnaround where applicable.
Severity / impact: P3 Moderate — financial. Maps to SEV3.

Cost overrun or additional treatment needed mid-care (P2)

Scenario: The actual cost exceeds the accepted quote — a complication, a longer stay, or an additional procedure is required — and the patient must fund the gap or cannot.
Trigger / condition: The clinical team identifies additional treatment or an extended stay beyond the itemised quote.
Expected system behaviour: A transparent, itemised revised quote is produced; an escrow top-up is requested before non-emergency additional work proceeds; no hidden markup is applied; clinically urgent care is never gated on payment.
User experience & messaging: An honest, itemised explanation of the additional cost and why, with the updated escrow and options — never a surprise bill.
Recovery & mitigation: Re-quote and request the escrow top-up; if the patient cannot fund non-urgent additions, the coordinator and Medical Director agree a safe, affordable plan; clinically urgent care proceeds and is reconciled afterwards. Owner: Care Coordinator and Hospital (quote); Finance (escrow); Medical Director (clinical urgency). Prevention: realistic quotes with contingency guidance; clear terms on how overruns are handled.
Logging, monitoring & alerting: Log revised quotes and top-ups; monitor quote-to-actual variance per provider and procedure; alert Finance on funding gaps.
Severity / impact: P2 High — financial; patient-safety if care is contingent on funds. Maps to SEV2.

6.6 Authentication, session and access control

Scenario: Repeated failed logins from a user, or an automated credential-stuffing attack.
Trigger / condition: Failed-auth attempts exceed the threshold for an account or IP.
Expected system behaviour: Rate limiting with lockout and backoff; uniform responses that do not reveal whether an account exists (no enumeration); MFA enforced for staff; stricter limits on auth endpoints behind a WAF.
User experience & messaging: A neutral "those details don't match" message, guidance to reset, and a clear lockout or cooldown notice — never "no such account".
Recovery & mitigation: Legitimate users reset via single-use, time-boxed tokens; Security reviews attack spikes and may block IPs. Owner: Security; platform. Prevention: rate limits, lockout and backoff, no enumeration, MFA, WAF.
Logging, monitoring & alerting: Log failed-auth events with IP and request id; alert on failed-auth spikes and anomaly patterns; feed security monitoring.
Severity / impact: P2 High — data-security, operational. Maps to SEV2 (SEV1 if a breach is suspected).

Session expiry or token loss mid-action (P3)

Scenario: An access token expires or is lost while the user is part-way through an action such as an upload or a payment.
Trigger / condition: Token expiry or refresh failure during an in-flight request.
Expected system behaviour: Refresh-token rotation renews silently where possible; otherwise the user is re-authenticated and returned to context; idempotent operations ensure no duplicate side effects on resume.
User experience & messaging: A graceful "please sign in again to continue" that preserves in-progress work where possible — not a lost form or an ambiguous payment.
Recovery & mitigation: Re-authenticate and resume; rely on idempotency for money and document steps. Owner: platform. Prevention: silent refresh; idle and absolute lifetimes; client-side state preservation.
Logging, monitoring & alerting: Log session renewals and forced re-auths; monitor refresh-failure rate.
Severity / impact: P3 Moderate — operational. Maps to SEV3.

Staff MFA failure or lost authenticator (P2)

Scenario: A staff member cannot complete MFA (lost device or authenticator), blocking case-critical work.
Trigger / condition: A failed MFA challenge or a help request from a staff user.
Expected system behaviour: Sensitive staff actions require step-up MFA and cannot proceed without it; recovery runs through a verified, audited re-enrolment, never a bypass.
User experience & messaging: Clear MFA recovery steps for staff; sensitive actions remain blocked until re-enrolled.
Recovery & mitigation: Identity-proofed MFA re-enrolment via an authorised admin; temporary case reassignment to keep the patient moving. Owner: Admin / IT; Security. Prevention: WebAuthn or TOTP enrolment with backup factors; a documented recovery path.
Logging, monitoring & alerting: Log MFA failures and re-enrolments; alert on repeated failures or unusual recovery requests.
Severity / impact: P2 High — data-security, operational. Maps to SEV2.

Refresh-token reuse or session hijack detected (P1)

Scenario: A rotated refresh token is replayed, indicating theft or session hijacking.
Trigger / condition: Refresh-token reuse detection fires.
Expected system behaviour: The session family is revoked server-side immediately; active tokens are invalidated; the account is flagged for review; sensitive actions require fresh step-up auth.
User experience & messaging: The user is signed out and prompted to re-authenticate and reset credentials; a security notice is sent.
Recovery & mitigation: Security investigates, forces a credential reset, and reviews recent actions on the account. Owner: Security. Prevention: refresh-token rotation with reuse detection; device and session listing; short token lifetimes.
Logging, monitoring & alerting: Log the reuse event; page Security on detection; correlate with the audit trail for affected case data.
Severity / impact: P1 Critical — data-security. Maps to SEV1.

Cross-tenant or cross-case access attempt (P1)

Scenario: A request tries to read or act on a case, clinic or referral outside the caller's tenant or case scope.
Trigger / condition: Authorisation evaluates the target as outside the caller's tenant or assigned case ids.
Expected system behaviour: Deny by default returns 403; PostgreSQL row-level security ensures even a flawed query cannot cross tenants; no data leaks in the response.
User experience & messaging: A generic "not found or not permitted" with no information about the other tenant's data.
Recovery & mitigation: Security reviews intentional attempts; legitimate access needs proper assignment or consent. Owner: Security. Prevention: server-side deny-by-default, scoped tokens, row-level security, field-level checks.
Logging, monitoring & alerting: Log every denied cross-tenant or cross-case attempt with actor; alert on spikes as a potential breach indicator.
Severity / impact: P1 Critical — data-security, regulatory. Maps to SEV1.

6.7 Concurrency, idempotency and data integrity

Concurrent edits or optimistic-lock conflict (P3)

Scenario: Two actors (for example two coordinators, or a webhook and a user) update the same case or record at once.
Trigger / condition: A write targets a record version that has since changed.
Expected system behaviour: Optimistic concurrency rejects the stale write; the loser is asked to reload and re-apply; no silent overwrite of the other change.
User experience & messaging: "This record changed while you were editing — review and reapply", rather than a lost update.
Recovery & mitigation: Reload the latest and re-submit; for events, last-writer-with-audit where defined. Owner: platform. Prevention: version or etag checks; clear ownership of case fields.
Logging, monitoring & alerting: Log conflict rejections; monitor conflict rate on hot records.
Severity / impact: P3 Moderate — operational, data-integrity. Maps to SEV3.

Duplicate, replayed or out-of-order webhook (P2)

Scenario: A provider delivers a webhook more than once, replays an old one, or delivers events out of order.
Trigger / condition: An inbound webhook with a seen idempotency key, an old timestamp, or a state regression.
Expected system behaviour: HMAC-verified, idempotent handlers de-duplicate replays and ignore stale or out-of-order transitions; processing is async on the event bus; acknowledgements are fast.
User experience & messaging: No user-visible effect — status never flickers backwards or double-applies.
Recovery & mitigation: Reconcile against the provider's state of record if ordering is ambiguous. Owner: platform. Prevention: idempotency keys, signature checks, monotonic state machines, at-least-once-safe consumers.
Logging, monitoring & alerting: Log de-duplicated and ignored webhooks; monitor webhook error and duplicate rates; alert on signature failures.
Severity / impact: P2 High — operational; financial on money webhooks. Maps to SEV2.

Document upload corruption or failed virus scan (P3)

Scenario: An upload fails type or size validation, is corrupt, or fails the malware scan.
Trigger / condition: Upload validation or the virus scanner rejects the file (Planned scanning).
Expected system behaviour: The file is rejected before storage; the linked visa or consultation checklist item stays pending until a valid, verified file exists; nothing unscanned is stored or shared.
User experience & messaging: Inline validation explaining the requirement (type, size) and a clear re-upload action.
Recovery & mitigation: The patient re-uploads a valid file. Owner: patient, with coordinator support. Prevention: clear file requirements; type and size checks and virus scanning at upload (Planned); encrypted storage.
Logging, monitoring & alerting: Log rejections with reason; alert Security on malware detections; monitor rejection rate.
Severity / impact: P3 Moderate — operational; data-security on a malware hit. Maps to SEV3 (SEV2 on confirmed malware).

Stale data after provider or webhook lag (P3)

Scenario: A delayed webhook or sync leaves the platform showing an out-of-date status (for example visa or booking).
Trigger / condition: A provider state changes but the event is late, lost, or the read is cached.
Expected system behaviour: Status is reconciled by polling or scheduled sync as a backstop to webhooks; caches have bounded staleness; the single status shown is conservative.
User experience & messaging: One coherent status; if pending confirmation, it reads "updating" rather than a wrong definite state.
Recovery & mitigation: Scheduled reconciliation catches missed events; the coordinator can force a refresh. Owner: platform; Ops. Prevention: webhook-plus-poll redundancy; idempotent reconciliation.
Logging, monitoring & alerting: Monitor event lag and missed-webhook counts; alert on sync staleness beyond a threshold.
Severity / impact: P3 Moderate — operational. Maps to SEV3.

6.8 Integration and provider outages

Payment or escrow partner outage (P1)

Scenario: The payment or escrow partner is unavailable during funding, release or refund.
Trigger / condition: Repeated errors or timeouts trip the partner's circuit breaker.
Expected system behaviour: The breaker opens and routes to the manual finance fallback; money operations remain idempotent and are queued for exactly-once completion; no partial state is shown.
User experience & messaging: A safe, non-alarming "we're completing your payment securely — no action needed" or "please try again shortly", with no ambiguity about charges.
Recovery & mitigation: Finance completes queued operations on recovery and reconciles; never improvise a release. Owner: Finance; platform. Prevention: circuit breaker plus manual fallback; idempotency; reconciliation.
Logging, monitoring & alerting: Page on money-path provider failure and breaker trips; monitor success rate and latency; log fallback usage.
Severity / impact: P1 Critical — financial, operational. Maps to SEV1.

Visa government channel or API outage (P2)

Scenario: The government or intermediary visa channel is unavailable for submission or status.
Trigger / condition: Submission or status calls fail, or no API exists for the corridor.
Expected system behaviour: A structured manual operations process drives the application; the patient still sees a single status and timeline; submission is idempotent.
User experience & messaging: One coherent status and timeline regardless of the backing channel — the outage is invisible to the patient.
Recovery & mitigation: Visa ops submit and track manually until the channel returns. Owner: Visa operations. Prevention: manual fallback by design; status polling and webhooks.
Logging, monitoring & alerting: Monitor submission success and processing time per corridor; alert on channel failure and SLA breach.
Severity / impact: P2 High — operational. Maps to SEV2.

Travel, airline or hotel provider outage (P2)

Scenario: A travel aggregator or GDS, airline or hotel provider is unavailable for search or booking.
Trigger / condition: Provider errors or timeouts trip the breaker.
Expected system behaviour: The breaker routes to the manual Travel Desk path; bookings are guarded by idempotency keys to avoid double-booking; the patient is never left without a next step.
User experience & messaging: Selections are received and the Travel Desk confirms — the patient sees progress, not an error wall.
Recovery & mitigation: The Travel Desk books via alternate channels and reconciles when the provider returns. Owner: Travel Desk. Prevention: breaker plus manual fallback; idempotent bookings.
Logging, monitoring & alerting: Monitor booking success rate and provider error rate; alert on booking failures.
Severity / impact: P2 High — operational. Maps to SEV2.

Communication-provider delivery collapse (P2)

Scenario: A notification or messaging channel (WhatsApp, SMS, email) stops delivering.
Trigger / condition: Delivery and read rates collapse, or the provider returns failures.
Expected system behaviour: Sends retry with backoff and fall back across channels (for example WhatsApp, then SMS, then email); opt-outs are respected; critical journey updates are not silently dropped.
User experience & messaging: The patient still receives critical updates via an alternate channel; no sensitive clinical detail goes over unencrypted channels.
Recovery & mitigation: Switch channel or provider and re-send critical messages. Owner: platform; Ops. Prevention: multi-channel fallback; verified senders.
Logging, monitoring & alerting: Monitor delivery and read rates per channel and corridor; alert on delivery collapse.
Severity / impact: P2 High — operational (P1 if it blocks a safety-critical message). Maps to SEV2.

6.9 Platform, infrastructure and deployment

CDN or static-site outage (P2)

Scenario: The marketing site, portal or /docs is unreachable due to a CDN or S3 issue.
Trigger / condition: CloudFront or S3 5xx or origin errors; synthetic checks fail.
Expected system behaviour: Static-first delivery and CDN caching absorb origin blips; the site is reproducible from next build and recoverable by redeploy; the bucket is disposable.
User experience & messaging: Cached content continues to serve where possible; a status or maintenance message if not.
Recovery & mitigation: Redeploy from source and CDK; invalidate the CDN; the repository and CDK are the source of truth. Owner: platform / Infra. Prevention: static-first architecture; synthetic monitoring; reproducible builds.
Logging, monitoring & alerting: CloudFront and S3 4xx / 5xx, cache-hit ratio, origin latency; synthetic checks; alert on availability drop.
Severity / impact: P2 High — operational, reputational. Maps to SEV2.

Backend service or database failover (P1, Planned)

Scenario: A domain service or the primary database fails and must fail over.
Trigger / condition: Health checks fail; golden-signal saturation or error alarms fire.
Expected system behaviour: Services degrade gracefully behind breakers; the database fails over with point-in-time recovery available; money and clinical data carry the strictest RPO and RTO; the append-only ledger preserves integrity across restores.
User experience & messaging: Read-only or "temporarily unavailable" states rather than data corruption; in-flight money and document operations resume idempotently.
Recovery & mitigation: Execute the documented runbook, fail over, verify integrity, and reconcile money operations. Owner: platform / Infra; Finance for money. Prevention: backups with point-in-time recovery, restore drills, cross-region copies, defined RPO and RTO.
Logging, monitoring & alerting: Golden signals per service; page on failover and saturation; verify backups via restore drills.
Severity / impact: P1 Critical — operational, financial, data-integrity. Maps to SEV1.

Bad release or failed deployment (P2)

Scenario: A deployment introduces a regression or fails partway.
Trigger / condition: Post-deploy errors spike; a migration or build step fails; the generated docs fall out of lock-step.
Expected system behaviour: Forward-only reversible migrations and blue-green or canary cutover allow rollback; the static front-end can be re-pinned to the last good build; generated docs must be rebuilt in order (gen:docs, then build:docs, then next build).
User experience & messaging: Minimal disruption via canary or rollback; no half-migrated data exposed.
Recovery & mitigation: Roll back to the last good release or build; fix forward; re-run the docs build order. Owner: platform / Infra. Prevention: CI/CD with automated tests, canary, reversible migrations; commit regenerated docs artefacts together.
Logging, monitoring & alerting: Deploy markers on dashboards; error-rate alerts post-deploy; verify:help and build checks in CI.
Severity / impact: P2 High — operational. Maps to SEV2.

Data-loss event and restore (P1, Planned)

Scenario: Data is lost or corrupted and must be restored from backup.
Trigger / condition: Corruption, accidental deletion, or a failed migration is detected.
Expected system behaviour: Encrypted backups with point-in-time recovery restore to a known-good point; object-storage versioning and soft, audited deletes allow document recovery; the ledger's immutability is preserved.
User experience & messaging: Transparent communication if any data is affected; conservative handling of money and clinical data.
Recovery & mitigation: Restore per the runbook to meet RPO and RTO; reconcile and verify; root-cause. Owner: platform / Infra. Prevention: automated encrypted backups, restore drills, cross-region replication, soft deletes.
Logging, monitoring & alerting: Backup-success monitoring; periodic restore drills; alert on backup failure or restore need.
Severity / impact: P1 Critical — data-integrity, financial, regulatory. Maps to SEV1.

Data-residency or region-routing violation (P1, Planned)

Scenario: Patient data is processed or stored outside the region required by the corridor's dataRegime.
Trigger / condition: A residency check finds data routed to a non-permitted region, or a Country Pack residency rule is breached.
Expected system behaviour: Per-corridor residency, driven by Country Packs, constrains storage and processing; a violation is blocked or quarantined and flagged to compliance.
User experience & messaging: No user-facing change; the obligation is honoured silently, or processing pauses rather than violating residency.
Recovery & mitigation: Compliance assesses; relocate or delete misplaced data; document and, if needed, notify. Owner: Compliance; platform. Prevention: residency enforced in code from Country Packs; region-pinned storage.
Logging, monitoring & alerting: Log residency decisions; alert on any violation; audit cross-border transfers.
Severity / impact: P1 Critical — regulatory, data-security. Maps to SEV1.

6.10 Security and data incidents

Suspected data breach or PII exposure (P1)

Scenario: Sensitive PII (health, identity, financial) is suspected exposed or exfiltrated.
Trigger / condition: An anomaly, a report, or an audit signal indicates unauthorised access or disclosure.
Expected system behaviour: The breach workflow opens; evidence and audit logs are preserved (not destroyed); the affected scope is determined; regulatory notification timelines start (for example GDPR's 72-hour rule).
User experience & messaging: Affected individuals are notified per the applicable regime, honestly and with guidance — no premature or misleading statements.
Recovery & mitigation: Contain, eradicate, recover; notify regulators and affected parties within the timelines; run a blameless postmortem. Owner: Security; Compliance; Incident Commander. Prevention: encryption, least privilege, row-level security, field-level encryption, monitoring.
Logging, monitoring & alerting: Preserve immutable audit logs; page Security on a suspected breach; monitor security signals (cross-tenant attempts, anomalies).
Severity / impact: P1 Critical — data-security, regulatory, reputational. Maps to SEV1.

Malicious, oversized or mistyped file upload (P2)

Scenario: A user or attacker uploads malware, an oversized file, or a wrong or unsupported type.
Trigger / condition: Upload validation or the virus scanner flags the file (Planned scanning).
Expected system behaviour: Files are validated (type, size) and scanned before storage; rejects never reach storage or sharing; documents are served only via short-lived, audited pre-signed URLs, never from a public bucket.
User experience & messaging: A clear rejection with the requirement; for malware, a neutral failure without technical detail.
Recovery & mitigation: The user re-uploads a valid file; Security handles confirmed malware. Owner: platform; Security. Prevention: type and size validation, virus scanning, encrypted storage, pre-signed URLs.
Logging, monitoring & alerting: Log rejections; alert Security on malware; monitor rejection and scan-failure rates.
Severity / impact: P2 High — data-security, operational. Maps to SEV2 (SEV1 on confirmed malware spread).

Account or credential compromise (P1)

Scenario: A patient, clinic or staff account is taken over via stolen credentials or phishing.
Trigger / condition: An anomalous login (new geography or device), reuse detection, or a user report.
Expected system behaviour: Step-up auth and MFA challenges; suspicious sessions are revoked; sensitive actions (escrow release, role changes, Country-Pack publish) require step-up; the account is flagged.
User experience & messaging: Forced re-authentication and credential reset; a security notice; affected actions paused.
Recovery & mitigation: Revoke sessions, reset credentials, review recent actions and the audit trail, and restore any unauthorised changes. Owner: Security. Prevention: MFA (mandatory for staff), reuse detection, anomaly alerting, least privilege.
Logging, monitoring & alerting: Log auth anomalies; page on staff-account compromise; correlate with the audit trail.
Severity / impact: P1 Critical — data-security, financial. Maps to SEV1.

Break-glass emergency clinical access (P2)

Scenario: An authorised role needs emergency access to a case (for example a complication) beyond normal scope.
Trigger / condition: A break-glass access is invoked for a clinical emergency.
Expected system behaviour: Access is granted but alarmed, time-boxed, and audited after the fact; it is the documented exception, not a routine path.
User experience & messaging: Not patient-facing; the acting staff see that the access is emergency, logged and reviewable.
Recovery & mitigation: Post-hoc review confirms justification; revoke on expiry; flag misuse. Owner: Security; Medical Director. Prevention: narrowly scoped break-glass; mandatory review.
Logging, monitoring & alerting: Alarm on every break-glass use; immutable audit; mandatory after-action review.
Severity / impact: P2 High — data-security, patient-safety. Maps to SEV2.

Scenario: A patient withdraws a previously granted consent (for example clinical review, hospital sharing, or marketing) while the case is active.
Trigger / condition: A consent withdrawal is recorded in the consent ledger (Planned).
Expected system behaviour: The relevant processing stops prospectively; dependent steps that require that consent pause; marketing withdrawal never affects service; the withdrawal is timestamped in the ledger.
User experience & messaging: Confirmation of what stops and what it means for the journey, with an honest explanation if a withdrawn consent blocks a clinical step.
Recovery & mitigation: The coordinator explains the impact and options; re-consent if the patient chooses to proceed. Owner: Care Coordinator; Compliance. Prevention: granular, purpose-bound consents; a clear withdrawal experience.
Logging, monitoring & alerting: Log every grant and withdrawal with actor, purpose and scope; alert if processing continues against a withdrawn consent.
Severity / impact: P2 High — regulatory, operational. Maps to SEV2.

Deletion or DSAR request conflicting with a legal hold (P2)

Scenario: A patient exercises deletion or erasure, but retention law or a legal hold requires keeping some data (for example financial / AML or medical records).
Trigger / condition: A DSAR deletion request lands on data under a retention obligation or hold.
Expected system behaviour: The DSAR workflow honours erasable data, but legal holds and statutory retention override deletion for the constrained categories; the response explains what was deleted and what is lawfully retained (Planned).
User experience & messaging: A clear, tracked response stating what is deleted, what is retained, the legal basis, and for how long.
Recovery & mitigation: Compliance adjudicates the conflict; delete the permissible data and retain the rest under hold. Owner: Compliance / DPO. Prevention: a retention schedule with legal-hold flags; classified data.
Logging, monitoring & alerting: Log the DSAR, decision and basis; track the DSAR SLA; alert on overdue requests.
Severity / impact: P2 High — regulatory. Maps to SEV2.

DSAR identity-verification failure (P3)

Scenario: A data-subject request cannot be fulfilled because the requester's identity cannot be verified, or a fraudulent request is attempted.
Trigger / condition: Identity verification for a DSAR fails or is inconsistent.
Expected system behaviour: The request is not fulfilled until identity is verified; suspected fraudulent DSARs are escalated; no data is released to an unverified requester.
User experience & messaging: A clear explanation of the verification needed and how to complete it.
Recovery & mitigation: Re-verify via the defined method; escalate suspected impersonation to Security and Compliance. Owner: Compliance; Security. Prevention: identity verification built into the DSAR workflow.
Logging, monitoring & alerting: Log DSAR verification attempts and outcomes; alert on suspected fraudulent requests.
Severity / impact: P3 Moderate — regulatory, data-security. Maps to SEV3.

Scenario: A support agent needs to view a patient case but no active consent grant exists.
Trigger / condition: A support access attempt on a case lacking a current consent grant.
Expected system behaviour: Support access is consent-gated and denied without an active grant; when granted it is fully audited and time-bound.
User experience & messaging: The patient is asked to grant consent for support to view their case; support sees access only after consent.
Recovery & mitigation: Obtain consent then proceed; without it, assist only with non-case-scoped guidance. Owner: Support; Compliance. Prevention: consent-gated, audited support access by design.
Logging, monitoring & alerting: Log every support access and the consent that authorised it; alert on any access without a grant.
Severity / impact: P2 High — regulatory, data-security. Maps to SEV2.

6.12 Language, accessibility and communication

Language and interpretation barriers (P2)

Scenario: The patient or family does not read the product's language or needs an interpreter for clinical communication.
Trigger / condition: The corridor language differs from the product's, or a clinical conversation needs interpretation.
Expected system behaviour: Corridor language (from the Country Pack) drives coordinator assignment; key documents are provided in the corridor language; clinical conversations use a human interpreter, never machine-only; internationalisation (locale tables, right-to-left layout, localised fonts) is Planned.
User experience & messaging: Communication in the patient's language from a coordinator who speaks it, with interpreter support at the hospital.
Recovery & mitigation: Assign a multilingual coordinator and an on-call interpreter; translate key documents. Owner: Care Coordinator; Ops. Prevention: corridor language in the Country Pack; internationalisation (Planned).
Logging, monitoring & alerting: Monitor interpreter turnaround; track translation coverage; log interpreter use on clinical conversations.
Severity / impact: P2 High — patient-safety (clinical comprehension), operational. Maps to SEV2.

Notification undeliverable, opted-out or wrong channel (P3)

Scenario: A patient has opted out, has an undeliverable address or number, or set a channel that fails for a critical update.
Trigger / condition: A delivery failure, a bounce, or an opt-out flag on a needed message.
Expected system behaviour: Opt-outs are respected; undeliverable addresses are flagged; channel fallback delivers critical journey updates; service-critical messages are separated from marketing.
User experience & messaging: Critical updates still reach the patient via an available channel; marketing respects the opt-out.
Recovery & mitigation: Switch channel; confirm contact details with the patient; the coordinator reaches out directly for critical items. Owner: platform; Care Coordinator. Prevention: verified contact capture; channel fallback; opt-out scoping that never blocks safety-critical messages.
Logging, monitoring & alerting: Monitor delivery and read rates; flag undeliverable contacts; alert when a critical message cannot be delivered on any channel.
Severity / impact: P3 Moderate — operational. Maps to SEV3.

Accessibility failure for assistive technology (P3)

Scenario: A user relying on assistive technology cannot complete a task (for example an unlabelled control or a keyboard trap).
Trigger / condition: An audit or a user report finds a WCAG 2.2 AA failure on a flow.
Expected system behaviour: Surfaces meet WCAG 2.2 AA — semantic landmarks, labelled controls, decorative SVGs hidden from assistive tech, visible focus, AA contrast; regressions are caught before release.
User experience & messaging: Equivalent access via assistive technology, and an accessible path to support if blocked.
Recovery & mitigation: Fix the specific violation; provide an assisted path meanwhile. Owner: Product; Engineering. Prevention: accessibility in the definition of done; audits; the design system's accessible components.
Logging, monitoring & alerting: Track accessibility issues; include accessibility checks in CI and review; monitor reported barriers.
Severity / impact: P3 Moderate — operational, reputational, inclusion. Maps to SEV3.

6.13 Regulatory and corridor

Corridor restriction or closure (P1 to P2)

Scenario: A corridor becomes restricted (visa curbs, sanctions, a corridor closure, or a destination policy change).
Trigger / condition: The Country Pack and ops monitoring flag the change; the corridor riskTier may shift to enhanced.
Expected system behaviour: New cases on the affected corridor pause; enhanced KYC, AML and source-of-funds checks apply where required; affected in-flight cases are re-routed or refunded; messaging and disclosures update via the versioned, feature-flagged Country Pack (Planned).
User experience & messaging: Honest, timely communication and protection of funds.
Recovery & mitigation: Pause, apply enhanced diligence, and re-route or refund in-flight cases. Owner: Administrator; Compliance; Medical Director for clinical impact. Prevention: corridor diversification; versioned Country Packs; riskTier modelling.
Logging, monitoring & alerting: Alert on corridor status or risk changes; log case re-routing and refunds; monitor affected in-flight cases.
Severity / impact: P1 to P2 — regulatory, financial, reputational. Maps to SEV1 or SEV2 by exposure.

Sanctions or AML screening hit (P1)

Scenario: A screening match on a party, or a source-of-funds concern, arises.
Trigger / condition: A sanctions or AML screening match (on a payment or an enhanced-risk corridor), or a source-of-funds flag.
Expected system behaviour: The transaction and case hold; escrow is not released while a match is open; the case escalates to compliance and proceeds only after clearance.
User experience & messaging: Neutral "additional verification is required" messaging; no tipping-off; honest about a hold without alleging wrongdoing.
Recovery & mitigation: Compliance reviews and clears or escalates per obligation. Owner: Compliance; Finance. Prevention: screening on payments and enhanced-risk corridors (Planned); documented escalation; enhanced KYC.
Logging, monitoring & alerting: Log screening results and decisions; page Compliance on a hit; block release while open.
Severity / impact: P1 Critical — regulatory, financial. Maps to SEV1.

Country Pack misconfiguration or bad publish (P2)

Scenario: A Country Pack is published with incorrect rules (wrong document set, fee, currency, residency, or risk tier).
Trigger / condition: A bad config publish, or validation or QA catches a regression in corridor behaviour.
Expected system behaviour: Country Packs are versioned and feature-flagged so a corridor's rules change without a code release and can be rolled back instantly; publishes are validated and previewable; step-up MFA gates a publish (Planned).
User experience & messaging: Patients see correct corridor rules; on rollback, no inconsistent or wrong requirements persist.
Recovery & mitigation: Roll back to the last good Pack version; correct and re-publish after validation. Owner: Administrator; Compliance. Prevention: versioning, validation, preview, staged rollout, step-up auth on publish.
Logging, monitoring & alerting: Audit every publish (actor, version, diff); alert on anomaly spikes after a publish; monitor corridor error and rejection rates after a change.
Severity / impact: P2 High — operational, regulatory. Maps to SEV2.

Restricted or prohibited procedure request (P1)

Scenario: A patient requests a procedure that is restricted or prohibited for foreign nationals or by law — for example commercial surrogacy (banned, and not available to foreigners or OCI holders) or any commercial organ transplant (illegal under the Transplantation of Human Organs Act).
Trigger / condition: Intake or triage identifies a requested procedure on the prohibited or restricted list, or one needing special statutory authorisation (for example an unrelated-donor transplant authorisation committee).
Expected system behaviour: Intake screens requests against a per-corridor prohibited-and-restricted procedure list (Planned); prohibited requests are declined and not facilitated; restricted procedures proceed only with the required legal authorisation and documentation, escalated to compliance and the Medical Director.
User experience & messaging: An honest, respectful decline for prohibited procedures with the legal basis, and clear requirements for any lawfully permitted, authorisation-gated procedure — never a workaround.
Recovery & mitigation: Decline and document prohibited requests; for restricted-but-permitted procedures, route through the statutory authorisation and legal review before any commitment. Owner: Compliance; Medical Director. Prevention: maintain a prohibited-and-restricted procedure list in each Country Pack; train intake; medical-ethics and advertising-compliance review.
Logging, monitoring & alerting: Log screened and declined requests with the basis; alert compliance on restricted-procedure requests; audit any authorisation-gated case.
Severity / impact: P1 Critical — regulatory, reputational. Maps to SEV1.

6.14 Exception-handling principles (summary)

These principles govern every entry above and any new scenario added later:

Protect the patient and the money first. When in doubt, place escrow on hold and escalate; never improvise a clinical or financial action.
Single source of truth. Every exception is logged on the case with owner, timestamp and resolution, and feeds the relevant scorecard and the immutable audit trail.
Always a fallback. Every external dependency (visa, travel, payment, messaging) sits behind a circuit breaker with a manual operations fallback, so a provider outage never becomes a patient dead end.
Idempotent and reconciled. Money, booking and document operations carry idempotency keys and are reconciled, so retries, duplicate webhooks and replays never double-charge, double-book or corrupt state.
Observable by design. Each scenario emits the audit events, metrics and alerts needed to detect it, page the right owner, and measure it against an SLA or SLO.
Honest, timely communication. The patient is told what happened, what it means, and what is being done, in their language — and sensitive scenarios are handled by a human, never by automation.
Prevention over cure. Country Packs, SLAs, validation, screening, accreditation and empanelment standards are designed to make these exceptions rare.

6.15 Coverage and severity matrix

A quick index of every scenario for review, test planning and on-call routing. Severity follows the tiers above; the owner is the primary accountable role.

#	Scenario	Category	Severity	Primary owner	Related requirement / integration
1	Treatment complication after travel	Clinical	P1	Medical Director	24/7 escalation; follow-up workflow
2	Acute or life-threatening emergency	Clinical	P1	Care Coordinator	Care plan; Country Pack
3	Accident or injury to a patient or attendant	Clinical	P1	In-country team / Coordinator	Emergency guidance; travel insurance
4	Intercurrent illness or unfitness for treatment	Clinical	P2	Hospital / Medical Director	Pre-op assessment; scheduling
5	Patient death or critical deterioration abroad	Clinical	P1	Medical Director	Incident response; escrow hold
6	Treatment refused or withdrawn (patient or provider)	Clinical	P2	Medical Director / Finance	Informed consent; refunds
7	Patient loses decision-making capacity — surrogate consent	Clinical	P1	Medical Director	Break-glass; next of kin
8	Minor or dependent patient — guardian consent	Clinical	P2	Compliance	Consent ledger
9	Missing or inadequate medical records	Clinical	P2	Coordinator / Specialist	FR-D; consultation workflow
10	Cross-border tele-follow-up licensing limits	Clinical	P3	Care Coordinator	Follow-up workflow
11	Adverse-outcome dispute or malpractice claim	Clinical	P2	Medical Director / Legal	Complaints; scorecard
12	Visa rejection	Visa	P2	Visa ops / Finance	FR-E; visa channel; refunds
13	Visa processing delay	Visa	P2	Visa ops / Travel Desk	FR-E; Country Pack
14	Invitation-letter or identity data mismatch	Visa	P2	Visa ops	FR-E; Country Pack validation
15	FRRO registration lapse after arrival	Visa	P2	In-country team	Country Pack; arrival checklist
16	Visa overstay from extended treatment	Visa	P1	Visa ops	e-FRRO extension
17	Patient or attendant does not return home (absconding)	Visa	P1	Visa ops / Compliance	FRRO; `riskTier`; KYC
18	Lost or stolen passport or documents abroad	Visa	P2	In-country team / Travel Desk	FRRO exit permit; embassy
19	Attendant visa exceeds two-relative limit	Visa	P3	Visa ops	Country Pack
20	Flight cancellation or travel disruption	Travel	P2	Travel Desk	FR-F; travel webhooks
21	Accommodation unavailable or unsuitable	Travel	P3	Travel Desk	FR-F; hotel webhooks
22	Fare or rate change before ticketing	Travel	P3	Travel Desk	FR-F; airline / hotel providers
23	Force majeure stranding a patient	Travel	P1	In-country team / Travel Desk	Advisories; Country Pack
24	Clinic cancellation or rescheduling	Provider	P2	Coordinator / Provider	FR-C; scorecard
25	Provider no-show or unresponsiveness	Provider	P2	Coordinator / Medical Director	SLA timers; scorecard
26	Patient no-show	Provider	P3	Care Coordinator	Notifications
27	Clinic accreditation lapse or suspension	Provider	P1	Admin / Medical Director	Empanelment; scorecard
28	Payment failure at funding	Payments	P2	Finance	FR-G; payment gateway
29	Duplicate or double-charged payment	Payments	P2	Finance	Idempotency; payments webhook
30	Milestone verified but escrow release fails	Payments	P1	Finance	FR-G; escrow partner
31	Refund request and dispute	Payments	P2	Finance	FR-G; refund schedule
32	Patient-initiated cancellation mid-journey	Payments	P2	Finance / Coordinator	Refund schedule; unwinding
33	Chargeback after escrow release	Payments	P2	Finance	Payments webhook; ledger
34	Currency fluctuation between payment and refund	Payments	P3	Finance	Multi-currency ledger
35	Ledger reconciliation break	Payments	P1	Finance	Reconciliation
36	Cost overrun or additional treatment mid-care	Payments	P2	Coordinator / Finance	Re-quote; escrow top-up
37	Insurance pre-authorisation or reimbursement shortfall	Payments	P3	Coordinator / Finance	Insurance integration
38	Failed login, lockout and credential stuffing	Auth	P2	Security	FR-B; security
39	Session expiry or token loss mid-action	Auth	P3	Platform	FR-B; idempotency
40	Staff MFA failure or lost authenticator	Auth	P2	Admin / IT; Security	FR-B; MFA
41	Refresh-token reuse or session hijack	Auth	P1	Security	Session security
42	Cross-tenant or cross-case access attempt	Auth	P1	Security	RBAC; row-level security
43	Concurrent edits or optimistic-lock conflict	Data integrity	P3	Platform	Data model
44	Duplicate, replayed or out-of-order webhook	Data integrity	P2	Platform	Webhooks; idempotency
45	Document upload corruption or failed scan	Data integrity	P3	Platform	FR-D; documents
46	Stale data after provider or webhook lag	Data integrity	P3	Platform / Ops	Events; reconciliation
47	Payment or escrow partner outage	Integration	P1	Finance	Escrow partner; circuit breaker
48	Visa government channel or API outage	Integration	P2	Visa ops	Visa channel; manual fallback
49	Travel, airline or hotel provider outage	Integration	P2	Travel Desk	Travel providers; circuit breaker
50	Communication-provider delivery collapse	Integration	P2	Platform / Ops	Comms providers
51	CDN or static-site outage	Infrastructure	P2	Platform / Infra	CloudFront / S3
52	Backend service or database failover	Infrastructure	P1	Platform / Infra	Database; backups
53	Bad release or failed deployment	Infrastructure	P2	Platform / Infra	CI/CD; docs build
54	Data-loss event and restore	Infrastructure	P1	Platform / Infra	Backups; PITR
55	Data-residency or region-routing violation	Infrastructure	P1	Compliance / Platform	Country Pack residency
56	Suspected data breach or PII exposure	Security	P1	Security / Compliance	Breach workflow
57	Malicious, oversized or mistyped file upload	Security	P2	Platform / Security	Documents; scanning
58	Account or credential compromise	Security	P1	Security	Auth; MFA
59	Break-glass emergency clinical access	Security	P2	Security / Medical Director	RBAC break-glass
60	Consent withdrawal mid-journey	Privacy	P2	Coordinator / Compliance	Consent ledger
61	Deletion or DSAR request vs legal hold	Privacy	P2	Compliance / DPO	DSAR; retention schedule
62	DSAR identity-verification failure	Privacy	P3	Compliance / Security	DSAR workflow
63	Support access without active consent	Privacy	P2	Support / Compliance	Consent-gated access
64	Language and interpretation barriers	Communication	P2	Coordinator / Ops	Internationalisation; translation
65	Notification undeliverable, opt-out or wrong channel	Communication	P3	Platform / Coordinator	Comms providers
66	Accessibility failure for assistive technology	Communication	P3	Product / Engineering	WCAG 2.2 AA
67	Corridor restriction or closure	Regulatory	P1–P2	Admin / Compliance	Country Pack; `riskTier`
68	Sanctions or AML screening hit	Regulatory	P1	Compliance / Finance	Screening
69	Restricted or prohibited procedure request	Regulatory	P1	Compliance / Medical Director	Country Pack; THO Act; surrogacy law
70	Country Pack misconfiguration or bad publish	Regulatory	P2	Admin / Compliance	Country Pack versioning