CapApp — Scope Document

Health Capitol patient mobile application — Phase 1 (“Ten Ten”, 10.10.2026), Phase 2 (2027) & Phase 3 (2028)
DRAFT v0.1 — for review & sign-off
Contents
  1. Document control
  2. Purpose & background
  3. Phasing & terminology
  4. Phase 1 scope — 10.10.2026
  5. Out of scope (Phase 1)
  6. Dependencies & blockers
  7. Assumptions & constraints
  8. Non-functional requirements
  9. Open items / decisions required
  10. Phase 2 scope — 2027
  11. Phase 3 scope — 2028
  12. Risks
  13. Sign-off

1. Document control

Document titleCapApp Scope Document
Version0.1 (Draft for review)
Date18 June 2026
Author / ownerDr Joseph Lim — Patient Programme Advisor
Development vendor8DGE
Distribution8DGE; HC project stakeholders (HM, Chu S Tan, Joey Ch’ng, Sunny, Wongks)
StatusDraft — not yet approved
Published locationpanax.pcsilly.com/capappscope.html (pending approval)

Change log to be maintained from v0.2 onward (date, version, author, summary of change).

2. Purpose & background

CapApp is the patient-facing mobile application for Health Capitol (HC). It is the patient’s entry point to registration, appointments, invoicing, loyalty points and partner integrations, and connects to the HC Clinical Information System (CIS) and selected third parties.

This document defines what CapApp must deliver for the 10.10.2026 soft opening (Phase 1), and records the intended direction for Phase 2 (2027) and Phase 3 (2028) so that Phase 1 work is built on an extensible foundation. Its specific aim is to make the 10.10 deliverables concrete, owned, dependency-mapped and testable.

3. Phasing & terminology

CapApp PhaseTargetTheme
Phase 1 (“Ten Ten”)10.10.2026 — soft openingCore patient journey: identity, appointments, invoices, loyalty, initial AA Pharmacy QR.
Phase 22027 — date TBC; likely multiple launch points (2A, 2B, 2C…)Deeper integrations: pharmacy tracking, results viewing, partner rewards, 1 Utama nutrition.
Phase 32028Complex scope: AI agent for patient health management.

4. Phase 1 scope — 10.10.2026

Owner key: 8DGE vendor build   JL Joseph Lim   OPEN owner unassigned   TBC not confirmed for Phase 1. Acceptance criteria below are proposed and to be confirmed.

IDCapabilityOwnerStatus
CA-P1-01CapApp app name & iconJLDue
CA-P1-02Loyalty points naming & 2-tier schemeJLDue
CA-P1-03Patient registration & account linking8DGEIn scope
CA-P1-04Appointments — registered patients8DGEIn scope
CA-P1-05Appointments — non-registered patients8DGEIn scope
CA-P1-06Invoices & LHDN e-invoice request8DGEIn scope
CA-P1-07View 2-tier loyalty points8DGEIn scope
CA-P1-08Link 1 Utama App account8DGEIn scope
CA-P1-09Exchange external points → 1Points8DGEIn scope
CA-P1-10QMS integration8DGETBC
CA-P1-11AA Pharmacy e-prescription (QR) — Phase 1JLIn scope

Detailed Phase 1 requirements

CA-P1-01 — CapApp app name & icon

Owner: JL · Due: Due now · Depends on: none (blocks store listing & branding)

Finalise the published name of the CapApp mobile app and its app icon, for use on the iOS App Store and Google Play, and across in-app branding.

Acceptance criteria
  • Approved app name confirmed in writing.
  • Icon supplied to 8DGE in all required store/platform sizes (iOS & Android).
  • Name reserved/available on both app stores.

CA-P1-02 — Loyalty points naming & 2-tier scheme

Owner: JL · Due: Due now · Blocks: CA-P1-07, CA-P1-09

Define the name of the Health Capitol loyalty points and the two tiers — internal and external points — including how they are earned, their relationship, and the “1Points” conversion target referenced in CA-P1-09.

Acceptance criteria
  • Final names for the loyalty programme and each of the two tiers confirmed.
  • Definition of what “internal” vs “external” points represent and how each is accrued.
  • Conversion relationship between external points and 1Points specified (rates/rules).

Until confirmed, points display (CA-P1-07) and exchange (CA-P1-09) cannot be finalised by 8DGE.

CA-P1-03 — Patient registration & account linking

Owner: 8DGE · Depends on: CIS patient API

Pull patient information from the CIS to populate the app, and link the app to that patient record so that on every launch the app loads for that specific account (persistent authenticated session). Passkey login to be evaluated — see open item OI-3.

Acceptance criteria
  • App retrieves patient demographic data from CIS and pre-fills the patient profile.
  • App account is durably linked to a single CIS patient record; relaunch resumes the correct account without re-entry.
  • Authentication flow defined (first-time registration + returning login); session persistence behaves consistently across iOS & Android.
  • Passkey: in or out of Phase 1 confirmed (OI-3). If in, biometric/passkey login works on both platforms.

Blocked by: outstanding CIS Mobile App API list (see §6).

CA-P1-04 — Appointments: registered patients

Owner: 8DGE · Depends on: CIS appointment API

For already-registered patients: view existing appointments, request new appointments, and request modification of appointments, all reflected in the CIS.

Acceptance criteria
  • Registered patient can view their current/upcoming appointments sourced from CIS.
  • Patient can submit a new appointment request and an appointment-modification request.
  • Request status is reflected back to the patient (e.g. requested / confirmed / declined) — workflow to be confirmed.

Confirm whether requests are real-time bookings or request-and-confirm.

CA-P1-05 — Appointments: non-registered patients

Owner: 8DGE · Depends on: doctor availability data

For patients who are not registered: view available doctors and call up to request an appointment.

Acceptance criteria
  • Non-registered user can browse available doctors and availability.
  • A “call to book” / contact action is available (confirm whether call-only or also request form).
  • Clear path to register is presented.

CA-P1-06 — Invoices & LHDN e-invoice request

Owner: 8DGE · Depends on: CIS billing API + LHDN/MyInvois integration

Patients can view their invoices and request an LHDN e-invoice.

Acceptance criteria
  • Patient can view a list of their invoices with detail.
  • Patient can request an LHDN e-invoice; the request reaches the billing/e-invoicing system.
  • Compliance with LHDN MyInvois requirements confirmed (whether app generates, requests, or only displays the e-invoice — to be defined).

Confirm the e-invoicing mechanism and which system is system-of-record for MyInvois submission.

CA-P1-07 — View 2-tier loyalty points

Owner: 8DGE · Depends on: CA-P1-02 (naming/rules), points data source

Display the patient’s balance across both loyalty tiers (internal and external).

Acceptance criteria
  • Both point tiers are displayed with correct, current balances.
  • Source of truth for point balances identified and connected.

CA-P1-08 — Link 1 Utama App account

Owner: 8DGE · Depends on: 1 Utama App API/partnership

Allow a patient to link their 1 Utama App account to their current CapApp user.

Acceptance criteria
  • User can initiate and complete linking of a 1 Utama App account.
  • Linked status is stored and visible; unlink path defined.

Requires confirmed API/credentials and partnership agreement with 1 Utama.

CA-P1-09 — Exchange external loyalty points → 1Points

Owner: 8DGE · Depends on: CA-P1-02, CA-P1-08

Allow patients to exchange external loyalty points into 1Points.

Acceptance criteria
  • Defined conversion rate/rules applied (from CA-P1-02).
  • Exchange transaction completes and updates both balances correctly.
  • Transaction record/history available to the patient.

CA-P1-10 — QMS integration TBC

Owner: 8DGE · Depends on: QMS vendor/API; scope decision

Queue Management System integration. Scope and inclusion for Phase 1 not yet confirmed.

To confirm before this can be specified
  • Is QMS in or out for 10.10? (decision OI-1)
  • What is the intended patient-facing function (e.g. live queue number, wait time, check-in)?
  • Which QMS product/API is in use?

CA-P1-11 — AA Pharmacy e-prescription (QR), Phase 1

Owner: JL · Depends on: prescription data from CIS; AA Pharmacy acceptance

Initial capability: show a QR code in the app that a pharmacist at an AA Pharmacy outside HC can scan to access the patient’s prescription.

Acceptance criteria
  • App displays a prescription QR code for the patient.
  • An AA Pharmacy pharmacist can scan it and retrieve the prescription (mechanism & data scope to be defined).
  • Security/expiry of the QR defined (e.g. single-use, time-limited) to protect prescription data.

Confirm AA Pharmacy side can read the QR and what data standard is used.

5. Out of scope (Phase 1)

The following are explicitly not part of the 10.10.2026 release and must not be assumed by the vendor or stakeholders. They are Phase 2/3 items unless promoted by written change request.

6. Dependencies & blockers

⚠ Primary blocker: CIS Mobile App API list outstanding

Most 8DGE Phase 1 items (registration CA-P1-03, appointments CA-P1-04, invoices CA-P1-06, points CA-P1-07) depend on APIs exposed by the CIS/HIS. The Mobile App API list from the CIS side is still outstanding. Until this is delivered and agreed, these items cannot be fully specified, estimated, or built. This is the single biggest risk to the 10.10 date and should be escalated.

DependencyNeeded forOwner / source
CIS Mobile App API list & specsCA-P1-03, 04, 06, 07CIS vendor (via Wongks) — outstanding
LHDN / MyInvois e-invoicing mechanismCA-P1-06HC billing + CIS
1 Utama App API & partnership termsCA-P1-08, 091 Utama / HC partnerships
1Points conversion rulesCA-P1-02, 09JL / loyalty programme
QMS product & APICA-P1-10TBC
AA Pharmacy prescription read capabilityCA-P1-11AA Pharmacy + HC
App store accounts (Apple / Google)PublishingHC / 8DGE

7. Assumptions & constraints

8. Non-functional requirements

Proposed minimum bar for Phase 1 — to be confirmed.

9. Open items / decisions required

RefDecision neededOwner
OI-1Is QMS integration (CA-P1-10) in or out for 10.10?JL / project lead
OI-2Resolved — owners assigned: CA-P1-04 → 8DGE, CA-P1-11 → JL.JL
OI-3Is passkey login in Phase 1 scope or deferred?JL / 8DGE
OI-4Finalise app name + icon (CA-P1-01) and loyalty naming/tiers + 1Points rules (CA-P1-02).JL
OI-5Deliver CIS Mobile App API list — critical path.CIS vendor / Wongks
OI-6Confirm appointment workflow: real-time booking vs request-and-confirm.HC operations
OI-7Confirm LHDN e-invoice mechanism & system of record.HC billing
OI-8Set per-item target dates working back from 10.10 (build / integration / UAT / go-live).JL / 8DGE

10. Phase 2 scope — 2027 (placeholders; date TBC, likely multiple launch points)

Deeper AA Pharmacy integration

Tracking of prescription volumes and timings, building on the Phase 1 QR capability.

Reports & results viewing

In-app viewing of radiology, lab, pathology and other results.

1 Utama integration

Nutrition tracking and other offers via the 1 Utama App.

Additional partner rewards

Third-party reward points such as BonusLink and similar programmes.

11. Phase 3 scope — 2028 (placeholder)

AI agent for patient health management

An AI agent integrated into CapApp to help manage patient health. Scope to be defined closer to the time; the more complex integrations are intentionally deferred here.

12. Risks

RiskImpactMitigation
CIS Mobile App API list not delivered in timeHigh — blocks most 8DGE items; threatens 10.10Escalate now; agree delivery date; identify a reduced fallback scope.
Owner clarity on assigned itemsLow — owners now assigned (CA-P1-04 → 8DGE, CA-P1-11 → JL)Confirm capacity with assigned owners; track delivery (OI-2 resolved).
JL naming items (app/loyalty) delayedMedium — blocks branding & points featuresTreat as “due now”; set hard internal deadline.
Third-party readiness (1 Utama, AA Pharmacy, LHDN)Medium/HighConfirm agreements & APIs early; descope to placeholder if not ready.
No per-item dates / no UAT windowMediumBuild backward schedule from 10.10 incl. UAT (OI-8).

13. Sign-off

RoleNameApprovalDate
Patient Programme AdvisorDr Joseph Lim
Vendor (8DGE)
HC stakeholder