# HAD Digital — MVP Build Plan
Document status: Draft v0.1 — for review by Dr Kais Aldabbagh and Zaid Al Dabbag Date: 5 September 2026 Prepared under: AI Project Governance Standard v3.9 Specification precedence: HAD_Digital_Specifications.docx (Cahier des Charges) governs all decisions below
1. Problem Framing (GOV-B2)
1.1 Purpose
Home-hospitalization oncology patients and their care teams need a single, structured platform to detect treatment toxicity early, coordinate care in real time, and reduce avoidable emergency admissions — currently hindered by fragmented phone/PDF-based workflows.
1.2 Problem Statement
| Current State | Desired State | Gap |
|---|---|---|
| Toxicity monitoring via unstructured phone calls and paper forms | Structured CTCAE-based digital capture and auto-grading | No standardized digital tooling |
| Hospital oncologist, HAD nurse, community nurse, GP see different information at different times | Shared real-time care-coordination timeline | Fragmented information silos |
| Manual transcription of symptom reports into medical records | Auto-generated toxicity summaries and exports | Significant clinician admin burden |
| Delayed detection of grade 1-2 toxicity until escalation | Tiered alerts (routine/urgent/emergency) triggered automatically | Avoidable ED visits and re-hospitalizations |
1.3 Objectives
| # | Objective | MOE | MOP |
|---|---|---|---|
| O1 | Enable structured CTCAE-based toxicity capture | % of toxicity reports using structured input vs free-text | >=90% structured reports in pilot |
| O2 | Auto-grade and alert on toxicity severity | Median time from report to care-team acknowledgment | <=15 min for urgent; <=5 min for emergency |
| O3 | Provide shared care-coordination workspace | % of care-team members actively using the platform | >=80% weekly active users in pilot |
| O4 | Reduce avoidable ED visits / re-hospitalizations | Change in unplanned re-hospitalization rate vs baseline | >=20% reduction |
| O5 | Reduce clinician admin burden | Self-reported time saved on documentation | >=30% reduction in pilot |
1.4 Stakeholders
| Actor | Role | Decision Authority | Evidence They Accept |
|---|---|---|---|
| Dr Kais Aldabbagh | Concept originator, clinical authority | Final approval on clinical logic, escalation protocols | Clinical accuracy of grading, protocol adherence |
| Hospital oncologist | Prescribes treatment, defines toxicity thresholds | Clinical configuration, alert protocol validation | Grading accuracy, alert routing correctness |
| HAD coordinating nurse | Daily coordination, triage | Workflow validation | Timeline usability, alert response time |
| Community / HAD nurse | Home visits, clinical observations | Field usability feedback | Offline capability, form completion speed |
| General practitioner | Informed of patient status | Read-access validation | Visibility of relevant patient data |
| Hospital pharmacist | Medication review | Medication plan view validation | Treatment plan accuracy |
| Patient / Caregiver | Symptom reporting, guidance consumption | Usability acceptance | Form simplicity, guidance clarity |
| Zaid Al Dabbag | Project owner, governance authority | All project decisions per GOV-A1.5 | Full governance compliance |
1.5 Intended Use
- Who: Oncology patients under HAD, their caregivers, and the multi-disciplinary care team
- Where: Patient's home (mobile-first), hospital (desktop dashboard), community visits (tablet/offline)
- Inputs: Structured symptom questionnaires, clinician observations, vital signs, treatment context
- Frequency: Scheduled cadence (per treatment cycle/day) + on-demand reporting
- Failure mode: Offline data capture with deferred sync; escalation to phone if platform unavailable
1.6 Constraints
| Constraint | Source |
|---|---|
| Must run as standalone .exe (no external server dependency for MVP demo) | User instruction |
| Must comply with AI Project Governance Standard v3.9 | Governance framework |
| Health data hosting must use HDS-certified provider (post-MVP; MVP uses local/development storage) | French regulation |
| GDPR and CNIL compliance for health data | EU/French law |
| Pure Python stdlib preference for reference pattern (GOV-B7.4) | Governance standard |
| MVP scope limited to S4.1 of specification | Specification |
1.7 Out of Scope (per Spec S4.2)
- Connected medical device integration (V2)
- Mon Espace Sante / DMP bidirectional interoperability (post-V1)
- Predictive / ML risk-scoring models (deferred until approved research protocol)
- Billing / PMSI / invoicing workflows
1.8 Measures
- MOE-1: Proportion of toxicity reports using structured CTCAE input
- MOE-2: Time from toxicity report to care-team acknowledgment by alert tier
- MOE-3: Weekly active user rate across care-team roles
- MOE-4: Change in unplanned re-hospitalization rate vs historical baseline
- MOP-1: System uptime during care hours (target >=99.5%)
- MOP-2: Toxicity grading response time (target: near real-time, <3 seconds)
- MOP-3: Patient self-report completion rate on scheduled cadence
2. Requirements (GOV-B3)
Requirements will be registered in the Requirements Register (01_System/Requirements_Register.md at Stage 3). Below is the initial set derived from the specification.
System-Level Requirements
| ID | Statement | Rationale | Source | Acceptance Criteria | Verification | Priority |
|---|---|---|---|---|---|---|
| REQ-SYS-01 | The system shall provide structured patient/caregiver toxicity self-reporting via mobile-friendly questionnaires mapped to CTCAE v5.0 domains | Core clinical function per Spec FR-1 | Spec FR-1 | Patient can complete a structured toxicity report on mobile; report captures >=5 CTCAE domains | Test | Must |
| REQ-SYS-02 | The system shall provide structured clinician/home-nurse observation entry for clinical findings and vital signs | Core clinical function per Spec FR-2 | Spec FR-2 | Clinician can enter observations; form includes vital signs, clinical signs, skin/wound findings | Test | Must |
| REQ-SYS-03 | The system shall automatically grade reported symptoms to CTCAE v5.0 grades 1-5 using configurable rule logic | Clinical safety core per Spec FR-3 | Spec FR-3, S7.3 | Given structured inputs, engine returns correct CTCAE grade; all grades >=2 flagged provisional until clinician confirmed | Test | Must |
| REQ-SYS-04 | The system shall trigger tiered clinical alerts (routine/urgent/emergency) based on grade, AE type, and physician-defined escalation protocol | Patient safety per Spec FR-4 | Spec FR-4, S7.4 | Emergency alert triggers within 5 seconds; urgent notification within defined delay; routine visible on timeline | Test | Must |
| REQ-SYS-05 | The system shall provide a shared care-coordination timeline showing reports, observations, alerts, decisions, and messages for a patient episode | Care coordination per Spec FR-5 | Spec FR-5 | Timeline displays chronological events; role-filtered; all event types represented | Test | Must |
| REQ-SYS-06 | The system shall provide secure care-team messaging attachable to alerts or timeline events | Communication per Spec FR-6 | Spec FR-6 | Messages between any two care-team members; can link to alert/timeline event; audit trail | Test | Should |
| REQ-SYS-07 | The system shall display a read-facing treatment plan and medication schedule | Reference view per Spec FR-7 | Spec FR-7 | Treatment protocol, cycle schedule, supportive-care prescriptions visible to authorized roles | Test | Must |
| REQ-SYS-08 | The system shall generate structured toxicity summaries on demand for patient record insertion and follow-up letters | Documentation per Spec FR-8 | Spec FR-8 | Summary export includes per-symptom grades, timeline, alert history; format suitable for clinical record | Test | Should |
| REQ-SYS-09 | The system shall enforce role-based access control per Spec S5 stakeholder roles | Security per Spec FR-9 | Spec FR-9 | Each role sees only authorized data/functions; patient cannot see other patients; GP sees only assigned patients | Test | Must |
| REQ-SYS-10 | The system shall display context-aware patient/caregiver guidance based on reported symptoms | Patient support per Spec FR-10 | Spec FR-10 | After symptom report, patient sees guidance (self-care vs contact team); guidance is physician-validated | Test | Should |
| REQ-SYS-11 | The system shall maintain an immutable audit log of all clinically relevant actions | Compliance per Spec FR-11 | Spec FR-11 | Every report/grade/alert/acknowledgment/override is timestamped, attributed, and immutable | Test | Must |
| REQ-SYS-12 | The system shall run as a standalone Windows executable (.exe) with no external server dependency for MVP demonstration | User requirement | User instruction | Double-click .exe launches application; all functions accessible via local browser or native window | Test | Must |
| REQ-SYS-13 | The system shall include a deploy-anywhere web application with named-user login and pluggable AI-engine connector | Governance mandatory function (GOV-B7.1) | GOV-B7.1 | Login page served; passwords hashed at rest; adapter round-trip completes; no key in client files | Test | Must |
| REQ-SYS-14 | The system shall support role-based users: oncologist, HAD coordinating nurse, community nurse, GP, pharmacist, patient, caregiver | Stakeholder coverage per Spec S5 | Spec S5 | Each role type can log in; permissions match Spec S5 table | Test | Must |
| REQ-SYS-15 | The system shall encrypt health data at rest and in transit | Non-functional per Spec S8 | Spec S8 | HTTPS for transit; database encryption at rest; audit of access | Inspection | Must (MVP: transit only; at rest deferred to HDS deployment) |
| REQ-SYS-16 | The system shall run without requiring Python, pip, Docker, or any external runtime to be installed on the host machine | Zero-dependency deployment | User instruction | Double-click .exe on a clean Windows 10/11 machine with no Python installed; application starts successfully | Test | Must |
| REQ-SYS-17 | The system shall support drop-in patching by overwriting application files without losing user data or configuration | Simple maintenance for non-technical users | User instruction | Overwrite .exe and static/ files; restart application; database and config.json preserved; schema migrations run automatically | Test | Must |
| REQ-SYS-18 | The system shall be fully portable — copyable to a USB stick or network share and runnable from any location | Portable deployment | User instruction | Copy folder to USB; run .exe from USB on a different machine; application functions correctly | Test | Must |
| REQ-SYS-19 | The system shall write all persistent data (database, logs, config) to paths relative to the application folder, not to system directories | Portability and no-admin requirement | User instruction | Application folder can be moved; all data moves with it; no writes to Program Files or Windows directories | Test | Must |
Constraints
| ID | Statement | Source |
|---|---|---|
| REQ-CON-01 | MVP must be deliverable as a standalone .exe file | User instruction |
| REQ-CON-02 | Must comply with AI Project Governance Standard v3.9 | Governance framework |
| REQ-CON-03 | Health data hosting must be HDS-certified for production (MVP exempts for demo/dev) | French regulation |
| REQ-CON-04 | API keys must never appear in client-served files (GOV-B7.3, INV-5) | Governance SA3, B7.3 |
| REQ-CON-05 | CTCAE grading logic is proprietary; mapping rules not detailed in public artifacts | Spec S7.3, S17 |
| REQ-CON-06 | Zero runtime dependencies — no pip, no Docker, no external services; Python stdlib only | User instruction; GOV-B7.4 |
| REQ-CON-07 | All persistent data (DB, logs, config) must be relative to application folder | Portability requirement |
| REQ-CON-08 | Database schema migrations must be automatic and forward-only (additive) | Simple patching requirement |
3. Architecture (GOV-B4)
3.1 Component Decomposition
| Component | Responsibility | Key REQs |
|---|---|---|
| C1 — Desktop Shell | Standalone .exe wrapper; launches embedded web server; opens browser/native window | REQ-SYS-12 |
| C2 — Web Server | HTTP server serving the application; session management; API routing | REQ-SYS-12, 13 |
| C3 — Auth and Access Control | User authentication, session tokens, role-based authorization | REQ-SYS-09, 14 |
| C4 — Toxicity Reader Engine | CTCAE v5.0 grading logic; rule-based mapping from structured inputs to grades | REQ-SYS-03 |
| C5 — Alert Engine | Tiered alert routing (routine/urgent/emergency) based on grade + protocol | REQ-SYS-04 |
| C6 — Patient Self-Report Module | Structured questionnaire UI for patients/caregivers; CTCAE domain mapping | REQ-SYS-01 |
| C7 — Clinician Entry Module | Structured observation entry form for home-nurse/clinician | REQ-SYS-02 |
| C8 — Care Coordination Timeline | Shared chronological feed of all events per episode | REQ-SYS-05 |
| C9 — Messaging Service | Secure care-team messaging, linkable to alerts/events | REQ-SYS-06 |
| C10 — Treatment Plan View | Read-facing treatment protocol and schedule display | REQ-SYS-07 |
| C11 — Summary and Export | Toxicity summary generation and export | REQ-SYS-08 |
| C12 — Guidance Engine | Patient-facing symptom-based guidance content | REQ-SYS-10 |
| C13 — Audit Logger | Immutable action logging with timestamps and attribution | REQ-SYS-11 |
| C14 — Data Store | Persistent storage for all entities (SQLite for MVP; HDS-ready schema) | All |
| C15 — AI Engine Connector | Pluggable adapter for AI engines (GLM, Kimi, Gemini, Claude, GPT) | REQ-SYS-13, GOV-B7 |
| C16 — Frontend (Patient) | Mobile-first PWA for patient/caregiver self-reporting and guidance | REQ-SYS-01, 10 |
| C17 — Frontend (Clinician) | Desktop-oriented dashboard with timeline, alerts, entry forms | REQ-SYS-02, 05, 06, 07, 08 |
| C18 — Schema Migration Runner | Automatic database schema migration on startup; forward-only; additive changes | REQ-SYS-17, REQ-CON-08 |
| C19 — Config Manager | Reads/writes config.json; preserves user settings across patches; documents new keys | REQ-SYS-17, REQ-CON-07 |
| C20 — Build & Packaging Script | PyInstaller build script producing Mode A/B/C outputs; smoke test; version stamping | REQ-SYS-16, 18 |
3.2 Interface Register (IF)
| IF | From -> To | Direction | Item Exchanged | Format | Trigger | Owner |
|---|---|---|---|---|---|---|
| IF-01 | C1 -> C2 | Bidirectional | HTTP requests/responses | HTTP/JSON | User action | C1 |
| IF-02 | C2 -> C3 | Request/Response | Auth validation | JSON | Login/API call | C3 |
| IF-03 | C6/C7 -> C4 | Request/Response | Structured symptom data | JSON | Report submission | C4 |
| IF-04 | C4 -> C5 | Event | Toxicity grade + AE type | JSON | Grading complete | C5 |
| IF-05 | C5 -> C8 | Event | Alert record | JSON | Alert triggered | C8 |
| IF-06 | C5 -> C9 | Notification | Alert notification | JSON | Urgent/Emergency | C9 |
| IF-07 | C2 -> C14 | CRUD | All entities | SQL/ORM | Any write | C14 |
| IF-08 | C8 -> C16/C17 | Data | Timeline events | JSON | View load | C8 |
| IF-09 | C11 -> C17 | Data | Toxicity summary | JSON/PDF | Export request | C11 |
| IF-10 | C2 -> C15 | Request/Response | AI chat messages | HTTP/JSON | Chat action | C15 |
| IF-11 | C12 -> C16 | Data | Guidance content | JSON | Post-report | C12 |
| IF-12 | All -> C13 | Event | Audit entries | JSON | Any action | C13 |
3.3 Technology Choices (MVP)
| Layer | Choice | Rationale |
|---|---|---|
| Runtime | Python 3.11 (embedded by PyInstaller) | Zero external deps; stdlib only; follows GOV-B7.4 pattern |
| Web server | Python stdlib http.server | No pip install; matches governance reference exactly |
| Database | SQLite via stdlib sqlite3 | Zero-config; file-based; portable; schema migrates to PostgreSQL |
| Frontend | HTML5 + CSS3 + vanilla JavaScript | No build step; no npm; no framework; runs in any browser |
| CTCAE Engine | Pure Python + JSON rule definitions | No external libs; rules updatable by replacing JSON file |
| Auth | hashlib.scrypt (stdlib) | No bcrypt/passlib pip install needed |
| HTTP client | urllib.request (stdlib) | For AI adapter; no requests/httpx pip install |
| Packaging | PyInstaller 6.x (build-time only) | Single .exe or folder bundle; Python runtime embedded |
| Patching | Drop-in file overwrite + auto DB migration | No installer; no admin rights; non-technical user can do it |
4. MVP Scope — What Gets Built
4.1 Core Features (Must-Have for MVP Demo)
| # | Feature | Spec Reference | Description |
|---|---|---|---|
| F1 | Login and Role Selection | FR-9, S5 | Named-user login with role-based landing (oncologist, nurse, patient, etc.) |
| F2 | Patient Toxicity Self-Report | FR-1, S7.2 | Structured questionnaire covering GI, hematologic, dermatologic, neurologic, constitutional CTCAE domains |
| F3 | Clinician Observation Entry | FR-2 | Form for home-visit findings, vital signs, observed toxicity signs |
| F4 | CTCAE Grading Engine | FR-3, S7.3 | Rule-based mapping from structured inputs to CTCAE grade 1-5 per AE term |
| F5 | Tiered Alerting | FR-4, S7.4 | Routine/urgent/emergency alerts based on grade and protocol |
| F6 | Care Coordination Timeline | FR-5 | Chronological feed of reports, observations, alerts, messages per episode |
| F7 | Treatment Plan View | FR-7 | Display of current regimen, cycle schedule, supportive-care prescriptions |
| F8 | Toxicity Summary Export | FR-8 | On-demand structured summary for clinical record |
| F9 | Patient Guidance | FR-10 | Context-aware guidance after symptom report (self-care vs contact team) |
| F10 | Audit Trail | FR-11 | Immutable log of all actions |
| F11 | Standalone .exe | — | Single executable that launches the full application |
| F12 | Web App Function | GOV-B7 | Login, AI connector slot, deploy-anywhere pattern |
4.2 Deferred to V2 (per Spec S4.2)
- Connected device integration
- Mon Espace Sante / DMP interoperability
- Predictive/ML risk scoring
- Billing/PMSI workflows
- Full MFA (MVP uses password-only)
- Multi-language support (MVP: French + English)
5. Project Classification (GOV-A1.8)
Classification: STANDARD
| Criterion | Assessment |
|---|---|
| Multiple components | Yes — 17 components identified |
| Interfaces crossed | Yes — 12 interfaces defined |
| Deliverable someone else will use | Yes — clinical users, patients |
| Safety/regulatory exposure | Yes — health data, clinical decision support |
| Consequence | Medium — pilot scope, single site |
At STANDARD class: all rules apply; agent roles may be merged into 3 (Builder / Verifier / Master Brain) provided C3.2 separation holds.
6. Build Approach — Standalone .exe
6.1 Packaging Strategy
The MVP will be packaged as a single Windows executable using PyInstaller:
HAD Digital.exe +-- Embedded Python runtime +-- Flask/http.server web server +-- SQLite database (created on first run) +-- Static assets (HTML/CSS/JS) +-- CTCAE reference data +-- Demo data (sample patients, treatments) +-- AI engine adapter (GLM default; stub for demo)
Launch behavior:
- User double-clicks HAD Digital.exe
- Embedded web server starts on localhost:8080
- Default browser opens to the login page
- Application is fully functional locally
Alternative (if PyWebView is preferred):
- Native window wrapping the web UI
- No browser dependency
- More application-like feel
6.2 Development Stack
| Component | Implementation |
|---|---|
| Backend | Python 3.11+ with Flask (or stdlib http.server per governance pattern) |
| Database | SQLite via Python's built-in sqlite3 module |
| Frontend | HTML5 + CSS3 + vanilla JavaScript (mobile-first responsive) |
| CTCAE Engine | Python rule engine with JSON-based rule definitions |
| Auth | Password hashing with hashlib.scrypt (stdlib) |
| Packaging | PyInstaller 6.x |
6.3 Demo Data (for MVP demonstration)
- 3 sample patients with different treatment protocols
- Pre-loaded CTCAE term sets relevant to common oncology regimens
- Sample toxicity reports and graded outcomes
- Demo alert scenarios (routine, urgent, emergency)
7. Project Plan — Stages (GOV-C1.5)
| Stage | Gate | Key Activities | Deliverables |
|---|---|---|---|
| 0 — Intake | Entry: Project charter exists | Classify project; register all requirements; set up registers | Master Brain state; Requirements Register |
| 1 — Discovery | Entry: Stage 0 complete | CTCAE term prioritization with clinical input; user story decomposition; UI wireframes | User stories; wireframes; CTCAE term subset |
| 2 — Analysis | Entry: Stage 1 complete | Detailed design; database schema; API contract; interface definitions | System design document; DB schema; API spec |
| 3 — Change Control | Entry: Stage 2 baselined | Baseline all artifacts; establish change process | Baselined artifacts; CR log initialized |
| 4 — Build | Entry: Stage 3 complete | Implement all components; unit tests; integration tests | Working code; test results |
| 5 — Integration | Entry: Stage 4 components verified | Assemble components; interface testing; end-to-end testing | Integrated system; integration test results |
| 6 — Verification and Validation | Entry: Stage 5 integrated | Independent verification against all REQs; clinical validation; Part I audit | V&V report; audit results |
| 7 — Publish | Entry: Stage 6 passed | Package as .exe; documentation; Help Hub | HAD Digital.exe; docs; Help Hub |
| 8 — Improvements | Entry: Stage 7 delivered | Lessons learned; improvement proposals | Knowledge harvest; improvement proposals |
8. Risk Register (GOV-E4)
| RSK | Risk | Likelihood | Impact | Mitigation | Owner |
|---|---|---|---|---|---|
| RSK-01 | CTCAE grading logic accuracy without clinical validation | High | High | Use conservative defaults; all grades >=2 provisional; clinician review mandatory | Clinical Advisor |
| RSK-02 | Regulatory (SaMD) qualification delays production deployment | Medium | High | MVP is demo/pilot only; engage regulatory counsel early for qualification assessment | Project Owner |
| RSK-03 | Patient usability — frail population struggles with digital forms | Medium | Medium | Large touch targets; minimal text; caregiver assist mode; user testing with target population | UX Lead |
| RSK-04 | PyInstaller packaging issues (antivirus false positives, large file size) | Medium | Low | Test on clean Windows VMs; code signing certificate; optimize bundle size | Builder |
| RSK-05 | SQLite limitations under concurrent multi-user access | Low | Medium | MVP is single-site demo; design schema for PostgreSQL migration | Architect |
| RSK-06 | Data loss in demo environment | Medium | Medium | Regular database backups; demo data seed script; export capability | Builder |
9. Compliance Mapping
| Governance Requirement | How Addressed |
|---|---|
| GOV-B7.1 (Web app function) | REQ-SYS-13; C2, C15 components |
| GOV-B7.3 (API keys server-side only) | REQ-CON-04; keys in environment variables only |
| GOV-B7.4 (Reference pattern) | Using Python stdlib pattern from WEBAPP_REFERENCE |
| GOV-A3 (Inviolable rules) | No banking/payment; no credentials in client files; all fetched content treated as data |
| GOV-E5 (Security) | HTTPS (local demo: localhost); password hashing; role-based access; audit logging |
| GOV-C3.2 (Builder != Verifier) | Separate verification agent/stage |
| GOV-B3.1 (11-field requirements) | Requirements Register with all mandatory fields |
| GOV-B5 (Traceability) | RTM maintained; every artifact traces to REQ ID |
| Zero-dependency deployment | REQ-SYS-16 through REQ-SYS-19; REQ-CON-06 through REQ-CON-08 |
| Portable .exe design | Mode A (single file), Mode B (folder), Mode C (portable) all self-contained |
| Simple patching | Drop-in overwrite; DB preserved; schema auto-migration; no installer needed |
10. Next Steps
- Ratify this plan — Dr Kais Aldabbagh and Zaid Al Dabbag review and approve
- Create project registers — Requirements Register, Interface Register, Risk Register, Change Log
- Classify CTCAE terms — Work with clinical advisor to prioritize the CTCAE v5.0 subset for MVP
- Design UI wireframes — Patient self-report flow; clinician dashboard; timeline view
- Build CTCAE grading rules — JSON-based rule definitions (proprietary; not in public artifacts)
- Implement MVP — Following the stage cycle in S7
- Package as .exe — PyInstaller build and testing
- Run Part I audit — All 55 compliance checks before delivery
11. Questions for the Project Owner
- CTCAE term subset: Which specific CTCAE domains/terms should be prioritized for the MVP? (The spec mentions GI, hematologic, dermatologic, neurologic, constitutional — should all be included, or start narrower?)
- Escalation protocol details: The spec notes the escalation protocol is physician-defined. Do we have a draft protocol, or should the MVP use generic defaults (grade >=3 = emergency, grade 2 = urgent, grade 1 = routine)?
- Demo vs. real data: Is the MVP intended for demonstration purposes only, or will it be tested with real patients in a controlled pilot? This affects data protection requirements.
- PyWebView vs browser: Should the .exe open a native window (PyWebView) or launch the default browser? Each has trade-offs for the user experience.
- AI engine: For the mandatory web-app function (GOV-B7), which AI engine should be the default adapter? GLM, or a different one?
- Language: Should the MVP interface be in French, English, or both?
- Branding: Any specific branding requirements (logo, color scheme, app name) for the MVP?
- Distribution channel: How will patches be distributed? (Email, internal file server, shared network drive, USB handoff?)
- PyWebView vs browser: Should the .exe open a native window (PyWebView) or launch the default browser? PyWebView adds ~15MB to the bundle but gives a more application-like feel; browser mode is lighter and more familiar to clinical users.