HEALTH BRIDGE UGANDA Stakeholder executive discussion brief Prepared for Dr. Ibrahim's stakeholder discussion SANDBOX / DEMONSTRATION ONLY — under active development No real patient information, payments, enrollment or external messages. 01 · THE OPPORTUNITY A shared journey, not disconnected handoffs. For insurance companies, hospital administrators, healthcare providers and brokers: coverage questions, fragmented documentation, tariff disagreements and unclear claim status are the workflow challenges this foundation is designed to address. These are discussion hypotheses, not measured findings about any Ugandan institution. Dr. Ibrahim’s vision places innovation leadership in the coordination of healthcare, insurance and people: one accountable journey, with distinct responsibilities and explainable evidence. No company affiliation, credentials, endorsement or partnership is implied. 01B · NEUTRAL COORDINATION PLATFORM Connects the parties. Decides for none of them. Health Bridge Uganda is proposed as a neutral, multi-sided coordination and interoperability platform connecting patients/policyholders, licensed insurers, brokers, hospitals and providers. It routes requests, tracks status, preserves audit records and exposes role- and consent-bounded information. It is not an insurer, provider, broker, payment processor or merchant of record, and it never accepts premiums or settles money. Decision authority stays with each party. Insurers own policies, underwriting, premium collection through their own approved external payment gateway, claim decisions and insurer settlement. Providers own clinical care and claim submission. Brokers assist clients only within authorised scopes. Patients/policyholders view only their own authorised data. Coordination flow: Patient ⇄ Health Bridge (routing, status, audit, consent) ⇄ Insurer · Broker · Hospital/Provider. Payment flow: Patient → insurer’s own payment site (outside Health Bridge). An external redirect is never evidence of payment; verified payment status may be shown only from trusted insurer confirmation, otherwise “Payment status pending confirmation from insurer”. 01C · HANDOFFS, RESPONSIBILITY AND DEPENDENCIES Implemented today versus proposed interfaces. Implemented in the sandbox: membership-scoped eligibility checks, encounters and itemized claims, private evidence uploads, deterministic readiness checks, recommendations and human insurer decisions, appeals, in-app status updates, simulated provider settlement status and a hash-chained audit trail. The offline demo adds a simulated insurer-payment handoff with sample insurers, balance and receipt. Proposed, not built: authenticated insurer APIs for policy status, eligibility and payment-status queries; signed insurer webhooks; provider system (HMIS/EMR) claim exchange; broker-of-record authorisation feeds; member enrolment applications routed to insurers for acceptance; consent records for household/dependant access. Each needs a partner agreement, interface specification, test environment and security review. Responsibility for disputes and errors: clinical disputes rest with the provider; coverage, underwriting, payment and claim-decision disputes with the insurer (through its appeal process); broker advice with the broker; Health Bridge is responsible for accurate routing, availability, access control and audit evidence of what was exchanged and when. Data sharing requires a documented legal basis, consent where applicable and per-party data-sharing agreements, subject to Uganda-specific legal and data-protection review. 02 · CURRENT FOUNDATION Connected records. Human decisions. The authenticated sandbox has saved plans, coverage, dated policies and members, provider contracts and tariffs; eligibility, encounters and itemized claims; reviewer recommendations, configurable insurer decision authority, private supporting documents, rejected-claim appeals, in-app status updates and a simulated settlement ledger. Deterministic readiness checks and idempotent orchestration consolidate source data, check timestamps, reasons, unknowns and exceptions. These are rules-based support, not a deployed AI agent, clinical diagnosis or fraud finding. No system independently approves, rejects or releases funds. Prior authorization is interactive in the separate offline demo. A connected authenticated prior-authorization request/decision experience is not meeting-ready. Member registration in the sandbox is institution-controlled configuration, not public enrollment. 03 · CAPABILITIES VERSUS SIMULATIONS Two environments. No ambiguity. Authenticated workspace: real sign-in, persisted synthetic records, membership-scoped access and audited transactions. Seven roles include platform operations without blanket clinical-record access. Invitations require the matching confirmed email; public role selection grants nothing. Offline guided demo: six fictional role views, seeded Sarah Nakato scenario, UGX 85,000 laboratory tariff, browser-local state and reset. It demonstrates the earlier assessor-plus-insurer-oversight path; it does not demonstrate private uploads, live single-decision orchestration, appeals or server authorization. All settlement and reconciliation views are status simulations. No bank or mobile-money rail, actual payout, external notification, real patient information or live enrollment is connected. Member premiums: Health Bridge is never merchant of record and never holds funds or payment credentials; members are handed off to their chosen insurer’s own verified payment site. The offline demo shows only a simulated handoff with sample insurers, balances and receipt; a redirect is not proof of payment, status shows “pending confirmation from insurer” until an authenticated insurer status connection exists, and cover activation stays insurer-controlled. No regulator approval or institutional adoption is claimed. 04 · ARCHITECTURE AND SECURITY Separation by responsibility. The authenticated application uses Lovable Cloud authentication and a relational database. Institution memberships determine roles; row-level access boundaries and membership-checked transaction routines protect tenant operations. The offline demo remains separate and its browser permissions are only simulations. Decision, recommendation and appeal histories are protected from edits. Audit records are hash-chained; access-controlled exports contain metadata rather than clinical payloads. Optional authenticator-app verification is enforced for enrolled privileged users; audit export requires the stronger session when a verified factor exists. Not pilot clearance: mandatory privileged MFA, login/sensitive-action rate limits, malware scanning, independent security testing, backup/recovery verification, incident procedures and local privacy/legal review remain gaps. No compliance certification is asserted. 05 · PROPOSED ADOPTION ROADMAP Prove the workflow before expanding it. Phase A — stakeholder alignment: select a willing insurer and provider team, define the approved service subset, responsibilities, escalation authority and success measures. Participation, dates and scope require agreement; no partner is signed or named. Phase B — synthetic acceptance: provision invited role accounts; rehearse configuration → eligibility → encounter and claim/document submission → recommendation → designated independent insurer decision → notifications → simulated settlement. Exercise corrections, rejected-claim appeal, tenant denials and recovery. Phase C — controlled pilot gate: proceed only after Uganda-specific counsel and data-protection review, Insurance Regulatory Authority engagement where appropriate, clinical coding validation, independent security review and operational readiness. Payment-partner work is a separately approved later phase. 06 · COMMERCIAL DISCUSSION ONLY Options, not a quotation. Option A: a fixed-scope, synthetic evaluation engagement covering setup, facilitation and acceptance evidence. Option B: an institution subscription with an agreed user/service allowance and support tier. Option C: a phased implementation engagement with integration work priced separately. Pricing assumptions to agree: institution count, authorised users, claim volume, document storage/retention, onboarding effort, support hours, training and any future integration scope. No UGX price, discount, ROI, tax treatment, contract term or delivery date is committed here. A proposal, budget and signed statement of work must follow scope and security review. Today’s demo is not an offer of live insurance coverage, payment processing or certified compliance. 07 · PILOT ACCEPTANCE CRITERIA Agree what “ready” means. Proposed gates: successful save-and-read-back with real permitted insurer, provider, assessor and patient accounts; invitation/email matching and cross-tenant denial checks; required-document and decision-reason validation; separation of duties and high-value escalation; repeat/idempotency and retry cases. Demonstrate that an independent appeal preserves the original decision, settled claims cannot silently reopen, notifications reveal only permitted status, simulated settlement is clearly labeled, and exported audit metadata verifies its chain. Review desktop/mobile accessibility, recovery and incident ownership. Before any real enrollment: approved privacy notice, retention/consent responsibilities, legal basis, security findings resolution, verified backups, operational ownership and an explicit go/no-go decision. Stakeholders must agree measurable targets; no performance or savings target is invented. STAKEHOLDER QUESTIONS Workflow ownership: Where do eligibility, evidence and tariff handoffs break down today, and who owns each exception? Decision authority: Who should make the final insurer decision, and which cases require independent escalation? Evidence and privacy: Which documents are necessary, who may view them, and what retention and consent responsibilities apply? Adoption and evaluation: What synthetic pilot scope, training, support and measurable acceptance gates would justify the next stage? EVIDENCE AND LIMITATIONS Acceptance evidence is reported separately in the meeting-readiness record. Rolled-back synthetic database checks are not real-account browser acceptance, regulatory approval or independent security assurance. Pricing and pilot scope above are nonbinding discussion options. FOUR-STAKEHOLDER VALUE MATRIX Discussion hypotheses and expected benefits, not measured outcomes. INSURANCE COMPANIES Pain: Eligibility uncertainty, evidence gaps, inconsistent adjudication, suspected anomalies and limited cost oversight. Benefit: Expected: clearer coverage checks, explainable exceptions, tariff comparison and accountable human decisions; no proven savings or fraud detection claim. Required decision: Nominate decision authority, required evidence, escalation thresholds and cost oversight owners. Likely objection: Will flags cause false accusations or replace our adjudicators? Evidence needed: Agreed synthetic edge cases, cited rule sources, false-positive review, reasoned decisions, tenant-denial tests and reconciled simulated totals. HOSPITAL ADMINISTRATORS Pain: Uncertain eligibility, authorization delays, rejected claims, disputed receivables and fragmented insurer handoffs. Benefit: Expected: earlier confirmation, clearer evidence/rejection follow-up and receivable status visibility. Settlement is simulated, not a collection guarantee. Required decision: Name front-desk, billing and rejection owners; agree insurer contracts/tariffs and authorization escalation. Likely objection: Will this add work or duplicate our hospital system? Evidence needed: Walk through one front-desk-to-billing case, missing evidence and rejection correction; map current systems and measure agreed handoff times. Connected authorization is not meeting-ready. HEALTHCARE PROVIDERS Pain: Incomplete encounter documentation, unclear billable evidence, unclean claims and missing status feedback. Benefit: Expected: more consistent encounter/item documentation, evidence checklists and visible claim status; no promised denial reduction or clinical diagnosis. Required decision: Agree documentation/coding responsibilities, service subset, clinical review boundaries and training owner. Likely objection: Will clinicians face extra data entry or automated medical judgments? Evidence needed: Clinician-reviewed synthetic encounter/item list, required-document cases, coding validation and status read-back. Hospital administration and clinical providers share the existing provider demo role, not new permissions. INSURANCE BROKERS Pain: Member enrollment handoffs, policy-status uncertainty, renewal tracking and disconnected service coordination. Benefit: Expected: authorized client portfolio, insurer-directed applications/renewals and service requests. Enrollment remains insurer-controlled; no public live enrollment. Required decision: Agree represented-client permissions, insurer underwriting handoff, renewal/service owners and minimum necessary fields. Likely objection: Can brokers see medical claims, decide coverage or move money? Evidence needed: Portfolio/application status examples, scope-denial checks and insurer acceptance path. Brokers cannot view claim files, adjudicate or pay; the traced member is not automatically a broker client. PATIENTS / POLICYHOLDERS Pain: Unclear cover, premium and claim status spread across insurer, broker and hospital. Benefit: Expected: one place to see own authorised policy, eligibility and claim status, and a safe handoff to the chosen insurer’s own payment site. Required decision: Which insurer data may be shown, under what consent, and how dependants are handled. Likely objection: Is Health Bridge taking my money or my medical data? Evidence needed: Premiums go only to the insurer’s own gateway; status shows pending until insurer confirmation; own-record isolation tests. Health Bridge Uganda · Stakeholder discovery ONE ATTENDEE · COMPLETE LOCALLY · No patient identifiers, credentials or confidential records. No app intake. ATTENDEE CONTEXT Role [ ] Insurer [ ] Hospital administrator [ ] Healthcare provider [ ] Broker. Institution (optional, consented): [________]. Responsibility: [________]. CURRENT SYSTEMS AND PROCESS Policy/eligibility system: [________]. Hospital/clinical/billing system: [________]. Broker/renewal tools: [________]. Current handoffs / manual work: [________]. PAIN AND BASELINE Top three pains and affected steps: 1 [________] 2 [________] 3 [________]. Current turnaround / rejection causes / follow-up effort (approximate, non-identifying): [________]. APPROXIMATE VOLUMES — OPTIONAL Period [________]. Members / applications [________]. Encounters / claims [________]. Rejections / renewals / service requests [________]. Estimates only; no records or claim identifiers. INTEGRATION AND EVIDENCE NEEDS Systems/interfaces available or unknown: [________]. Required data fields and permitted exchanges: [________]. Coding/tariff sources: [________]. Evidence needed before evaluation: [________]. OWNERSHIP AND OPERATING CONSTRAINTS Eligibility / evidence / decisions / rejection / renewal owners (roles): [________]. Support hours, downtime/manual fallback, staffing and training constraints: [________]. PRIVACY, COMPLIANCE AND ACCESS Legal/privacy review owner (role): [________]. Consent/legal basis, retention, storage-location or access constraints to validate: [________]. Independent reviews required: [________]. No regulatory clearance assumed. PILOT WILLINGNESS — NO COMMITMENT [ ] Interested in discussion [ ] Need evidence [ ] Not now. Possible synthetic scope: [________]. Success measures to agree: [________]. Key blockers: [________]. Permission for agreed follow-up: [ ] Yes [ ] No. Health Bridge Uganda · Decision & next steps COMPLETE LOCALLY WITH CONSENT · Discussion record, not a contract, enrollment or launch authorization. DISCUSSION OUTCOME [ ] Explore synthetic evaluation [ ] Revise scope [ ] Request evidence [ ] Defer. Rationale / open concerns: [________________________________]. PROPOSED SPONSOR AND INSTITUTIONS — CONFIRM WILLINGNESS Named sponsor: [________________]. Institution / role: [________________]. Proposed pilot institution(s): [________________]. Confirmed willing? [ ] Yes [ ] Not yet. No participation is assumed. REQUIREMENTS AND ACCOUNTABILITY Named requirements owner: [________________]. Joint pilot owner, if agreed: [________________]. Insurer decision / hospital billing / provider documentation / broker coordination leads: [________________]. SCOPE AND REQUIREMENTS TO AGREE Synthetic service subset / cases: [________________]. Existing system mapping / integration questions: [________________]. Acceptance measures and evidence: [________________]. Exclusions and dependencies: [________________]. FOLLOW-UP MEETING — SUBJECT TO AGREEMENT Proposed date/time: [________________]. Participants: [________________]. Agenda: [________________]. Scheduling owner: [________________]. Confirmation pending? [ ] Yes [ ] No. ACTIONS AND EVIDENCE OWNERS Action 1 / owner / target review: [________________]. Action 2 / owner / target review: [________________]. Privacy/security/legal requirements owner: [________________]. COMMERCIAL AND APPROVAL BOUNDARY Budget owner: [________________]. Budget: [uncommitted / estimate requested]. Written scope/quotation and institutional authorization needed. Illustrative 60–90 day evaluation is not a delivery promise. No real patient data, actual payments or production claims. LOCAL RECORD AND CONSENT Recorded by (consented): [________________]. Date: [________________]. Follow-up permission [ ] Yes [ ] No. Store through your agreed institutional process; Health Bridge does not submit or save this sheet. Do not add patient data, credentials or confidential records.