# HAD Digital — Full Project Execution Plan
Document status: Draft v0.1 Date: 5 September 2026 Prepared under: AI Project Governance Standard v3.9 Specification precedence: HAD_Digital_Specifications.docx governs all decisions
Table of Contents
- Project Capabilities (What the MVP Delivers)
- Full Build Steps (Every Action from Start to Finish)
- Dependencies (Internal and External)
- Risks (Comprehensive Register)
- Assumptions and What Breaks If Wrong
- Success Criteria
1. PROJECT CAPABILITIES — What the MVP Delivers
1.1 Clinical Capabilities
| # | Capability | Description | Spec Reference |
|---|
| CAP-01 | Patient Toxicity Self-Reporting | Patients and caregivers complete structured questionnaires mapped to CTCAE v5.0 domains (GI, hematologic, dermatologic, neurologic, constitutional). Mobile-friendly, large touch targets, minimal text. | FR-1, S7.2 |
| CAP-02 | Clinician Observation Entry | Home nurses and clinicians enter structured clinical findings: vital signs, skin/wound observations, directly observed toxicity signs. | FR-2 |
| CAP-03 | Automated CTCAE Grading | Rule engine maps structured inputs to CTCAE v5.0 grades 1-5 per adverse event term. Combines patient-reported and clinician-reported data. Grades >=2 flagged provisional until clinician confirmed. | FR-3, S7.3 |
| CAP-04 | Tiered Clinical Alerting | Automatic routing: Routine (timeline only), Urgent (notification to HAD nurse within defined delay), Emergency (immediate notification to on-call oncologist). Triggered by grade + AE type + physician-defined protocol. | FR-4, S7.4 |
| CAP-05 | Patient Guidance | Context-aware guidance shown after symptom report: self-care advice vs contact the team now vs go to emergency. Physician-validated content. | FR-10 |
1.2 Coordination Capabilities
| # | Capability | Description | Spec Reference |
|---|
| CAP-06 | Shared Care Timeline | Chronological, role-filtered feed of all events per patient episode: reports, observations, alerts, decisions, messages. | FR-5 |
| CAP-07 | Secure Messaging | Direct messaging between care-team members, attachable to specific alerts or timeline events. Audit trail maintained. | FR-6 |
| CAP-08 | Treatment Plan View | Read-facing display of current systemic therapy protocol, supportive-care prescriptions, home-visit/infusion schedule. | FR-7 |
| CAP-09 | Role-Based Access Control | Each actor sees only information appropriate to their role and relationship to the patient episode. 8 roles: oncologist, HAD coordinating nurse, community nurse, GP, pharmacist, patient, caregiver, admin. | FR-9 |
1.3 Documentation Capabilities
| # | Capability | Description | Spec Reference |
|---|
| CAP-10 | Toxicity Summary Export | On-demand generation of structured toxicity summary for insertion into hospital record and follow-up letters. Includes per-symptom grades, timeline, alert history. | FR-8 |
| CAP-11 | Audit Trail | Immutable log of who entered, viewed, modified or acted on each data point, with timestamps. Every clinically relevant action recorded. | FR-11 |
1.4 Technical Capabilities
| # | Capability | Description |
|---|
| CAP-12 | Standalone .exe | Single Windows executable; no installation; no external runtime; double-click to launch |
| CAP-13 | Zero Dependencies | No Python, no Docker, no pip, no npm, no external services required on end-user machine |
| CAP-14 | Portable Deployment | Copy to USB or network share; run from any Windows 10/11 machine |
| CAP-15 | Simple Patching | Drop-in file overwrite; database and config preserved; schema migrations automatic |
| CAP-16 | Local-First | Core functions work without internet; AI engine connector requires network |
| CAP-17 | AI Engine Connector | Pluggable adapter for GLM, Kimi, Gemini, Claude, GPT (per GOV-B7). Stub adapter for offline demo. |
| CAP-18 | Named-User Login | Password-hashed at scrypt; 5-fail lockout; session cookies (per GOV-B7.1) |
| CAP-19 | SQLite Database | Zero-config; file-based; portable; schema designed for PostgreSQL migration |
| CAP-20 | Demo Data | Auto-seeded on first run: 3 sample patients, pre-loaded CTCAE terms, sample reports and alerts |
1.5 User Experience Capabilities
| # | Capability | Description |
|---|
| CAP-21 | Mobile-First Patient UI | Responsive design; large touch targets; minimal text; works on phones and tablets |
| CAP-22 | Desktop Clinician Dashboard | Full-featured dashboard with timeline, alerts, entry forms, export functions |
| CAP-23 | Multi-Role Landing | Each role sees a customized home screen with relevant actions and data |
| CAP-24 | Guidance After Report | Patient receives immediate, actionable guidance based on reported symptoms |
2. FULL BUILD STEPS — Every Action from Start to Finish
Phase 0: Project Setup and Framing
| Step | Action | Deliverable | Owner | Estimated Effort |
|---|
| 0.1 | Ratify this execution plan with Dr Kais Aldabbagh and Zaid Al Dabbag | Signed-off plan | Master Brain | 1 day |
| 0.2 | Classify project as STANDARD per GOV-A1.8 | Classification record | Master Brain | 30 min |
| 0.3 | Create project folder structure per GOV-F3 | 00_Governance, 01_System, 02_Requirements, 03_Architecture, 04_Build, 05_Test, 06_Archive, 07_Deliverables | Registrar | 1 hour |
| 0.4 | Initialize all registers | Requirements Register, Interface Register, Risk Register, Defect Register, Change Log, Decision Log, Assumptions Register | Registrar | 2 hours |
| 0.5 | Register all requirements from MVP plan (REQ-SYS-01 through REQ-SYS-19, REQ-CON-01 through REQ-CON-08) with all 11 mandatory fields | Populated Requirements Register | Registrar | 3 hours |
| 0.6 | Register all interfaces (IF-01 through IF-12) | Populated Interface Register | Registrar | 1 hour |
| 0.7 | Register all risks (RSK-01 through RSK-15) | Populated Risk Register | Risk Agent | 1 hour |
| 0.8 | Create the Master Brain state file | Master_Brain_State.md with purpose, objectives, plan baseline, live status | Master Brain | 1 hour |
| 0.9 | Run GOV-B2.1 framing check | Framing artefact verified against all 10 items | Verifier | 30 min |
Phase 0 Exit Gate: All registers populated; framing artefact complete; project classified; Master Brain state initialized.
Phase 1: Discovery and Requirements Refinement
| Step | Action | Deliverable | Owner | Estimated Effort |
|---|
| 1.1 | Identify and prioritize CTCAE v5.0 terms for MVP | CTCAE_Term_Subset.md — list of prioritized terms per domain (GI, hematologic, dermatologic, neurologic, constitutional) | Clinical Advisor + Architect | 2 days |
| 1.2 | Define escalation protocol defaults | Escalation_Protocol.md — grade-based routing rules (grade 1 = routine, grade 2 = urgent, grade 3+ = emergency) with overrides | Clinical Advisor | 1 day |
| 1.3 | Decompose requirements into user stories | User_Stories.md — each REQ broken into testable user stories with acceptance criteria | Architect | 2 days |
| 1.4 | Design UI wireframes for all screens | Wireframes/ folder — patient self-report flow, clinician dashboard, timeline view, alert management, treatment plan, export | UX Lead | 3 days |
| 1.5 | Define role-permission matrix | Role_Permissions.md — which roles can access which screens, data, and actions | Architect + Clinical Advisor | 1 day |
| 1.6 | Define data entities and relationships | Data_Model_Draft.md — Patient, Episode, Treatment Plan, Toxicity Report, Grade, Alert, Message, Timeline Event, User | Architect | 1 day |
| 1.7 | Review wireframes and user stories with stakeholders | Sign-off on wireframes and stories | Master Brain | 1 day |
Phase 1 Exit Gate: CTCAE terms prioritized; escalation protocol defined; user stories complete; wireframes approved; data model drafted.
Phase 2: Architecture and Design
| Step | Action | Deliverable | Owner | Estimated Effort |
|---|
| 2.1 | Finalize database schema (SQLite) | schema.sql — all tables, columns, constraints, indexes, foreign keys | Architect | 2 days |
| 2.2 | Design API contract (all endpoints) | API_Contract.md — every HTTP endpoint with method, path, request/response schema, auth requirements | Architect | 2 days |
| 2.3 | Design CTCAE grading rule format | ctcae_rules_schema.json — JSON schema for rule definitions; sample rules for 3 terms | Architect + Clinical Advisor | 1 day |
| 2.4 | Design alert routing logic | Alert_Routing.md — how grades map to alert tiers; notification targets per tier; escalation delays | Architect + Clinical Advisor | 1 day |
| 2.5 | Design config.json schema | config_schema.json — all configurable parameters with defaults and descriptions | Architect | 0.5 day |
| 2.6 | Design schema migration system | Migration_Runner.md — how migrations are stored, ordered, executed, and rolled back | Architect | 0.5 day |
| 2.7 | Design build and packaging script | Build_Script.md — PyInstaller configuration, build modes (A/B/C), version stamping, smoke test | Architect | 0.5 day |
| 2.8 | Design AI adapter interface | AI_Adapter.md — base adapter class, required methods, error handling, credential management | Architect | 0.5 day |
| 2.9 | Create system breakdown (N-squared matrix) | SYSTEM_BREAKDOWN.md — all 20 components with dependencies mapped | Architect | 1 day |
| 2.10 | Baseline all architecture artifacts | Baselined architecture set | Change Controller | 0.5 day |
Phase 2 Exit Gate: Database schema finalized; API contract complete; all interfaces defined; system breakdown created; artifacts baselined.
Phase 3: Change Control Setup
| Step | Action | Deliverable | Owner | Estimated Effort |
|---|
| 3.1 | Establish change control process | Change_Control_Process.md — how CRs are raised, classified, approved, implemented, verified | Change Controller | 0.5 day |
| 3.2 | Initialize change log | Change_Log.md with empty template | Change Controller | 30 min |
| 3.3 | Create archive-before-change procedure | Archive_Procedure.md — how snapshots are taken before any change | Change Controller | 30 min |
| 3.4 | Baseline all planning artifacts | Baselined planning set | Change Controller | 0.5 day |
Phase 3 Exit Gate: Change control process established; all artifacts baselined; ready to build.
Phase 4: Implementation (Build)
| Step | Action | Deliverable | Owner | Estimated Effort |
|---|
| 4A: Backend Core | | | | |
| 4A.1 | Implement config manager (C19) | config_manager.py — reads/writes config.json; defaults; key documentation | Builder | 0.5 day |
| 4A.2 | Implement database manager and schema creation (C14) | database.py — SQLite connection; schema creation; migration runner (C18) | Builder | 1 day |
| 4A.3 | Implement audit logger (C13) | audit_logger.py — immutable log; timestamps; attribution | Builder | 0.5 day |
| 4A.4 | Implement user store and authentication (C3) | user_store.py — scrypt hashing; session management; 5-fail lockout | Builder | 1 day |
| 4A.5 | Implement role-based access control (C3) | rbac.py — permission checks per role; episode-scoped access | Builder | 0.5 day |
| 4B: Clinical Engine | | | | |
| 4B.1 | Implement CTCAE grading engine (C4) | ctcae_engine.py — loads rules from JSON; maps inputs to grades; provisional flagging | Builder | 2 days |
| 4B.2 | Implement alert engine (C5) | alert_engine.py — grade-to-tier mapping; notification routing; escalation delays | Builder | 1 day |
| 4B.3 | Implement guidance engine (C12) | guidance_engine.py — symptom-to-guidance mapping; content loading | Builder | 1 day |
| 4B.4 | Create CTCAE rules data (sample set) | ctcae_rules.json — rules for prioritized terms; proprietary; not in public artifacts | Builder + Clinical Advisor | 2 days |
| 4B.5 | Create guidance content | guidance/ folder — per-symptom guidance text (self-care vs contact team vs emergency) | Clinical Advisor | 1 day |
| 4C: Backend API | | | | |
| 4C.1 | Implement HTTP server and routing (C2) | server.py — request handling; static file serving; CSP headers; containment checks | Builder | 1 day |
| 4C.2 | Implement auth API endpoints | /api/login, /api/logout, /api/whoami | Builder | 0.5 day |
| 4C.3 | Implement patient API endpoints | /api/patients (CRUD), /api/episodes, /api/treatment-plans | Builder | 1 day |
| 4C.4 | Implement toxicity report API endpoints | /api/reports (submit, list, get), /api/grades | Builder | 1 day |
| 4C.5 | Implement alert API endpoints | /api/alerts (list, acknowledge, escalate) | Builder | 0.5 day |
| 4C.6 | Implement timeline API endpoint | /api/timeline (chronological events per episode, role-filtered) | Builder | 0.5 day |
| 4C.7 | Implement messaging API endpoints | /api/messages (send, list, link to event) | Builder | 0.5 day |
| 4C.8 | Implement export API endpoint | /api/export/summary (structured toxicity summary) | Builder | 0.5 day |
| 4C.9 | Implement AI adapter interface (C15) | adapters/base.py, adapters/stub.py, adapters/glm.py | Builder | 1 day |
| 4C.10 | Implement chat API endpoint | /api/chat (requires auth; routes to adapter) | Builder | 0.5 day |
| 4D: Frontend — Patient | | | | | | 4D.1 | Build login page | login.html — responsive; role selection; password field | Builder | 0.5 day | | 4D.2 | Build patient self-report form (C6) | report.html — structured questionnaire; CTCAE domains; large touch targets | Builder | 2 days | | 4D.3 | Build patient guidance display | guidance.html — context-aware guidance after report; clear action items | Builder | 1 day | | 4D.4 | Build patient home screen | patient_home.html — recent reports, upcoming schedules, quick report button | Builder | 0.5 day | | 4E: Frontend — Clinician | | | | | | 4E.1 | Build clinician dashboard | dashboard.html — summary cards, recent alerts, pending actions | Builder | 1 day | | 4E.2 | Build clinician observation entry form (C7) | observation.html — vital signs, clinical findings, toxicity signs | Builder | 1.5 days | | 4E.3 | Build care coordination timeline (C8) | timeline.html — chronological feed; event types; role filtering; detail view | Builder | 2 days | | 4E.4 | Build alert management view | alerts.html — list of alerts; acknowledge; escalate; filter by tier | Builder | 1 day | | 4E.5 | Build treatment plan view (C10) | treatment_plan.html — regimen, cycle schedule, supportive care | Builder | 1 day | | 4E.6 | Build messaging interface (C9) | messages.html — thread view; attach to event; send/receive | Builder | 1 day | | 4E.7 | Build export view (C11) | export.html — select date range; generate summary; download | Builder | 0.5 day | | 4E.8 | Build admin/user management view | admin.html — user CRUD; role assignment; password reset | Builder | 1 day | | 4F: Styling and Polish | | | | | | 4F.1 | Implement responsive CSS framework | app.css — mobile-first; breakpoints; role-based color coding | Builder | 1 day | | 4F.2 | Implement client-side JavaScript | app.js — API calls; form handling; dynamic content; error states | Builder | 2 days | | 4F.3 | Implement empty/loading/error states for all views | All views handle: no data, loading, error, permission denied | Builder | 1 day | | 4G: Demo Data and Testing | | | | | | 4G.1 | Create demo data seed script | seed_demo.py — 3 patients, treatment plans, sample reports, alerts | Builder | 1 day | | 4G.2 | Write unit tests for CTCAE engine | test_ctcae.py — test grading logic for each sample term | Builder | 1 day | | 4G.3 | Write unit tests for auth and RBAC | test_auth.py — login, lockout, permission checks | Builder | 0.5 day | | 4G.4 | Write unit tests for API endpoints | test_api.py — all endpoints; happy path + error cases | Builder | 1 day | | 4G.5 | Write integration tests | test_integration.py — full flow: login -> report -> grade -> alert -> timeline | Builder | 1 day |
Phase 4 Exit Gate: All components implemented; all unit tests passing; demo data seeds correctly; application runs locally.
Phase 5: Integration
| Step | Action | Deliverable | Owner | Estimated Effort |
|---|
| 5.1 | Integrate frontend with backend API | All API calls working from browser; error handling complete | Integrator | 1 day |
| 5.2 | Integrate CTCAE engine with report submission | Report submission -> grading -> alert -> timeline flow working end-to-end | Integrator | 0.5 day |
| 5.3 | Integrate alert engine with messaging and timeline | Alerts appear on timeline; notifications sent; messaging linked | Integrator | 0.5 day |
| 5.4 | Integrate export with timeline and grading data | Summary export pulls correct data; format is clinically useful | Integrator | 0.5 day |
| 5.5 | Integration testing — full patient journey | Complete flow: patient reports -> grading -> alert -> clinician reviews -> export | Integrator | 1 day |
| 5.6 | Integration testing — all roles | Each role logs in; performs their primary actions; sees correct data | Integrator | 1 day |
| 5.7 | Record integration test results | Integration_Test_Results.md — pass/fail per interface, per role | Integrator | 0.5 day |
Phase 5 Exit Gate: All interfaces tested; full patient journey works; all roles functional; integration defects logged.
Phase 6: Verification and Validation
| Step | Action | Deliverable | Owner | Estimated Effort |
|---|
| 6.1 | Independent verification against all REQs | V&V_Report.md — every REQ checked against acceptance criteria; evidence cited | Independent Verifier | 2 days |
| 6.2 | Security review | Security_Review.md — password hashing, session management, RBAC, CSP, containment, audit trail | Risk Agent | 1 day |
| 6.3 | Usability review | Usability_Review.md — patient forms tested for readability; clinician dashboard tested for workflow | Validator | 1 day |
| 6.4 | Performance check | Performance_Check.md — grading response time; page load times; database query times | Verifier | 0.5 day |
| 6.5 | Run Part I compliance audit (all 55 checks) | Compliance_Audit.md — every line pass/fail with evidence | Verifier | 1 day |
| 6.6 | Fix any FAIL items | Defect fixes; re-verify | Builder | 1-3 days |
| 6.7 | Clinical validation of grading logic | Clinical_Validation.md — clinical advisor reviews grading rules and sample outputs | Clinical Advisor | 1 day |
| 6.8 | Stakeholder demo and feedback | Feedback_Log.md — recorded feedback from Dr Kais and Zaid | Master Brain | 1 day |
Phase 6 Exit Gate: All REQs verified; security passed; Part I audit passed (or FAILs documented with waivers); clinical validation complete; stakeholder feedback incorporated.
Phase 7: Packaging and Delivery
| Step | Action | Deliverable | Owner | Estimated Effort |
|---|
| 7.1 | Create build script (C20) | build.py — PyInstaller configuration; Mode A/B/C; version stamping | Builder | 1 day |
| 7.2 | Build Mode A (single .exe) | dist/HAD Digital.exe — single file, all embedded | Builder | 0.5 day |
| 7.3 | Build Mode B (folder bundle) | dist/HAD_Digital/ — .exe + data + static + config | Builder | 0.5 day |
| 7.4 | Smoke test Mode A on clean Windows VM | Launch .exe; open browser; login; submit report; verify grading | Verifier | 0.5 day |
| 7.5 | Smoke test Mode B on clean Windows VM | Same as 7.4; also test patching (overwrite .exe, preserve DB) | Verifier | 0.5 day |
| 7.6 | Smoke test USB portability | Copy Mode B to USB; run from USB on different machine | Verifier | 0.5 day |
| 7.7 | Create README.txt | Quick-start: how to run, how to patch, how to configure, demo credentials | Builder | 0.5 day |
| 7.8 | Create VERSION.txt | Version number, build date, git hash, component versions | Builder | 30 min |
| 7.9 | Create CHANGELOG.txt | What changed since last version | Builder | 30 min |
| 7.10 | Create Help Hub (GOV-G1) | Help_Hub/ folder — troubleshooting, glossary, deliverables map, FAQ | Builder | 1 day |
| 7.11 | Create deliverables map (GOV-G4) | Deliverables_Map.md — every file, its purpose, its location | Builder | 0.5 day |
| 7.12 | Archive all build artifacts | 06_Archive/ — dated snapshots of all deliverables | Change Controller | 0.5 day |
| 7.13 | Final Part I audit | Re-run all 55 checks on final deliverables | Verifier | 0.5 day |
Phase 7 Exit Gate: .exe builds successfully; smoke tests pass; USB portability confirmed; documentation complete; final audit passed.
Phase 8: Handover and Close-Out
| Step | Action | Deliverable | Owner | Estimated Effort |
|---|
| 8.1 | Create handover file (GOV-F9.9) | Handover.md — purpose, governance, requirements, tools, registers, live state | Master Brain | 0.5 day |
| 8.2 | Create cold-start test | Cold_Start_Test.md — an operator with only the folder can state purpose, baseline, open items, next action | Verifier | 0.5 day |
| 8.3 | Run cold-start test | Verifier uses only the folder to answer all cold-start questions | Verifier | 0.5 day |
| 8.4 | Harvest reusable lessons | Lessons_Learned.md — what worked, what didn't, what to improve | Improvement Agent | 0.5 day |
| 8.5 | Close-out report | Closeout_Report.md — every request logged with % complete; every phase reconciled; zero Open items | Master Brain | 1 day |
| 8.6 | Transfer pack creation (GOV-F9.11) | Transfer_Pack/ folder — everything needed to hand the project to another team | Master Brain | 1 day |
| 8.7 | Final stakeholder sign-off | Signed acceptance from Dr Kais and Zaid | Master Brain | 1 day |
Phase 8 Exit Gate: Handover complete; cold-start test passed; lessons harvested; close-out report delivered; stakeholder sign-off received.
Summary: Total Estimated Effort
| Phase | Days |
|---|
| Phase 0: Project Setup | 2 |
| Phase 1: Discovery | 8 |
| Phase 2: Architecture | 7 |
| Phase 3: Change Control | 1 |
| Phase 4: Implementation | 25-30 |
| Phase 5: Integration | 5 |
| Phase 6: Verification | 7-10 |
| Phase 7: Packaging | 6 |
| Phase 8: Handover | 5 |
| Total | 66-74 working days |
This is approximately 3-4 months of focused work, assuming a single builder. With parallel agents (per GOV-C3.1), phases can overlap and the timeline compresses to approximately 2-2.5 months.
3. DEPENDENCIES — What the Project Needs to Succeed
3.1 External Dependencies (Outside the Project Team)
| # | Dependency | Why Needed | Risk If Missing | Owner |
|---|
| DEP-01 | Dr Kais Aldabbagh — clinical input | CTCAE term prioritization; escalation protocol validation; grading rule review; clinical validation | No clinically valid grading logic; cannot pass validation | Dr Kais |
| DEP-02 | Zaid Al Dabbag — project owner decisions | Plan ratification; change approvals; requirement clarifications; sign-off | No authority to proceed; decisions blocked | Zaid |
| DEP-03 | Windows 10/11 test machines (clean VMs) | Smoke testing .exe portability; antivirus testing; clean-environment verification | Cannot verify zero-dependency claim | Builder |
| DEP-04 | PyInstaller (build-time) | Packaging Python into .exe | Cannot build .exe | Builder |
| DEP-05 | Python 3.11+ (developer machine) | Development runtime | Cannot develop | Builder |
| DEP-06 | Git (version control) | Version tracking; build stamping; rollback | No version history; no traceability | Builder |
| DEP-07 | CTCAE v5.0 reference document | Grading rules must be based on the official CTCAE standard | Grading logic not clinically grounded | Dr Kais / NCI |
| DEP-08 | Sample patient data (anonymized) | Demo data for testing and demonstration | Cannot demonstrate the system | Dr Kais |
| DEP-09 | Regulatory counsel (post-MVP) | SaMD qualification assessment before clinical pilot | Cannot deploy beyond demo | Project Owner |
| DEP-10 | HDS-certified hosting (production) | Health data hosting compliance for production | Cannot go live with real patient data | Project Owner |
3.2 Internal Dependencies (Between Components)
| # | Dependency | From | To | Nature |
|---|
| DEP-11 | Database schema must be finalized before any backend code | Phase 2 (Architecture) | Phase 4A (Backend Core) | Blocking |
| DEP-12 | CTCAE rules must be defined before grading engine implementation | Phase 1 (Discovery) + Clinical Input | Phase 4B.1 (CTCAE Engine) | Blocking |
| DEP-13 | Escalation protocol must be defined before alert engine | Phase 1 (Discovery) + Clinical Input | Phase 4B.2 (Alert Engine) | Blocking |
| DEP-14 | Auth system must work before any protected endpoint | Phase 4A.4 (User Store) | Phase 4C.2-4C.10 (All API Endpoints) | Blocking |
| DEP-15 | API contract must be defined before frontend development | Phase 2 (Architecture) | Phase 4D + 4E (Frontend) | Blocking |
| DEP-16 | CTCAE engine must work before alert engine | Phase 4B.1 (CTCAE Engine) | Phase 4B.2 (Alert Engine) | Blocking |
| DEP-17 | Backend API must work before frontend integration | Phase 4C (Backend API) | Phase 5 (Integration) | Blocking |
| DEP-18 | All components must pass unit tests before integration | Phase 4G (Testing) | Phase 5 (Integration) | Blocking |
| DEP-19 | Integration must pass before verification | Phase 5 (Integration) | Phase 6 (Verification) | Blocking |
| DEP-20 | Verification must pass before packaging | Phase 6 (Verification) | Phase 7 (Packaging) | Blocking |
3.3 Knowledge Dependencies
| # | Dependency | Why Needed | How Addressed |
|---|
| DEP-21 | Understanding of CTCAE v5.0 grading system | Grading rules must be clinically accurate | Dr Kais input; CTCAE reference document |
| DEP-22 | Understanding of French HAD model | Workflow must match real clinical practice | Spec document; Dr Kais input |
| DEP-23 | Understanding of governance standard v3.9 | Every decision must comply | This plan; governance document |
| DEP-24 | Python packaging knowledge | PyInstaller configuration; bundling; troubleshooting | Builder expertise; PyInstaller docs |
| DEP-25 | Health data regulations (GDPR, CNIL, HDS) | Data handling must comply | Spec document; regulatory counsel (post-MVP) |
3.4 Infrastructure Dependencies
| # | Dependency | Purpose | MVP Approach | Production Approach |
|---|
| DEP-26 | Database | Persistent storage | SQLite (file-based, zero config) | PostgreSQL (HDS-certified host) |
| DEP-27 | Web server | Serve application | Bundled in .exe (stdlib http.server) | Dedicated server/container |
| DEP-28 | File storage | Static assets, config, logs | Local filesystem (relative paths) | Cloud storage |
| DEP-29 | AI engine | Chat/assistant feature | Stub adapter (offline) or GLM (with API key) | Production adapter with real key |
| DEP-30 | Network | Client-server communication | localhost (no network needed) | HTTPS with valid certificate |
4. RISKS — Comprehensive Register
4.1 Clinical Risks
| RSK | Risk | Likelihood | Impact | Mitigation | Contingency | Owner |
|---|
| RSK-01 | CTCAE grading logic produces incorrect grades | High (MVP without full clinical validation) | High — patient safety | Conservative defaults; all grades >=2 provisional; clinician review mandatory; use official CTCAE reference | Revert to manual grading; flag system as decision-support only | Clinical Advisor |
| RSK-02 | Escalation protocol defaults are inappropriate | Medium | High — missed emergencies | Use widely-accepted oncology triage defaults; clinical advisor review; make rules configurable | Allow physician override per patient | Clinical Advisor |
| RSK-03 | Patient self-report data is incomplete or inaccurate | High | Medium — grading quality affected | Structured questionnaire reduces free-text variability; clinician confirmation for grades >=2; guidance prompts honest reporting | Cross-reference with clinician observations | UX Lead |
| RSK-04 | Guidance content leads to wrong patient action | Low | High — patient safety | Physician-validated content; conservative advice (err on side of contact team); clear disclaimers | Immediate content update via patch | Clinical Advisor |
4.2 Technical Risks
| RSK | Risk | Likelihood | Impact | Mitigation | Contingency | Owner |
|---|
| RSK-05 | PyInstaller .exe flagged by antivirus as suspicious | Medium | Medium — blocks deployment | Test on clean VMs; code signing certificate; whitelist instructions for IT departments | Provide folder bundle (Mode B) as alternative; submit to AV vendors for whitelisting | Builder |
| RSK-06 | .exe file size is too large (>200MB) | Low | Low — distribution delay | Optimize PyInstaller excludes; use --onefile for single exe; compress | Accept larger size; use folder bundle mode | Builder |
| RSK-07 | SQLite concurrent access issues | Low (single-site demo) | Medium — data corruption | WAL mode; single-writer design; connection pooling | Migrate to PostgreSQL for multi-user | Architect |
| RSK-08 | Database schema migration fails on patch | Low | High — data loss | Additive-only migrations; test migrations on copy before applying; backup before patch | Restore from backup; manual schema fix | Builder |
| RSK-09 | Browser compatibility issues | Low | Medium — UI broken | Vanilla HTML/CSS/JS; test on Chrome, Edge, Firefox; no framework dependencies | Provide browser-specific CSS fixes | Builder |
| RSK-10 | PyWebView adds unexpected complexity | Medium | Medium — delays | Prefer browser mode for MVP; PyWebView as optional enhancement | Drop PyWebView; use browser mode only | Builder |
| RSK-11 | AI adapter integration fails | Medium | Low — non-core feature | Stub adapter for offline demo; AI connector is optional for MVP core functions | Ship without AI chat; add in V2 | Builder |
| RSK-12 | Portability issues on different Windows versions | Low | Medium — deployment blocked | Test on Windows 10 (1903+) and Windows 11; document minimum version | Provide version-specific workarounds | Builder |
4.3 Regulatory and Compliance Risks
| RSK | Risk | Likelihood | Impact | Mitigation | Contingency | Owner |
|---|
| RSK-13 | SaMD qualification required before any clinical use | High | High — timeline impact | MVP is demo/pilot only; engage regulatory counsel early; document intended use carefully | Limit to demonstration; no real patient data until qualification | Project Owner |
| RSK-14 | GDPR non-compliance in demo environment | Low (demo only) | High — legal exposure | No real patient data in demo; anonymized sample data only; clear demo disclaimers | Remove all data; restart with fresh demo data | Risk Agent |
| RSK-15 | Governance standard non-compliance | Medium | Medium — project rejection | Follow GOV-C1.5 stage cycle; run Part I audit; document all deviations | Waiver process (GOV-A1.3) for documented exceptions | Master Brain |
4.4 Project and Resource Risks
| RSK | Risk | Likelihood | Impact | Mitigation | Contingency | Owner |
|---|
| RSK-16 | Clinical advisor unavailable for input | Medium | High — blocks grading logic and validation | Schedule regular input sessions; prepare questions in advance; document assumptions for later validation | Use conservative defaults; flag for later clinical review | Master Brain |
| RSK-17 | Scope creep beyond MVP | High | High — timeline blowout | Strict adherence to Spec S4.1 scope; every new request goes through change control; out-of-scope list enforced | Defer to V2; log as improvement proposal | Change Controller |
| RSK-18 | Single builder is a bottleneck | High | Medium — timeline impact | Modular architecture allows parallel work; use sub-agents per GOV-C3.1; prioritize critical path | Extend timeline; add builder resource | Master Brain |
| RSK-19 | Requirements misunderstanding | Medium | High — rework | Requirements register with acceptance criteria; stakeholder review at every gate; wireframes approved before build | Change request process; re-baseline | Architect |
| RSK-20 | Demo environment not convincing | Medium | Medium — stakeholder confidence | Realistic demo data; complete patient journey; all roles functional; pre-seeded scenarios | Prepare scripted demo flow; backup static screenshots | Builder |
4.5 Operational Risks (Post-Delivery)
| RSK | Risk | Likelihood | Impact | Mitigation | Contingency | Owner |
|---|
| RSK-21 | Users cannot apply patches | Low | Medium — cannot update | Simple drop-in process; README with screenshots; patch notes clear | Provide remote support; create video walkthrough | Builder |
| RSK-22 | Data loss during patching | Low | High — clinical data lost | Database never overwritten by patch; backup instructions in README; schema migration tested | Restore from backup; manual data recovery | Builder |
| RSK-23 | Application crashes on startup after patch | Low | Medium — cannot use | Smoke test before release; version rollback procedure documented; previous version archived | Revert to previous .exe; report defect | Builder |
| RSK-24 | Users exceed intended scope (real patients in demo) | Medium | High — safety/legal | Clear disclaimers in application; demo mode label; no HDS certification for demo | Immediate stop; data purge; legal review | Project Owner |
5. ASSUMPTIONS AND WHAT BREAKS IF WRONG
| # | Assumption | Confidence | What Breaks If Wrong |
|---|
| ASM-01 | Python 3.11+ runs on all target Windows machines when bundled by PyInstaller | High | Cannot build .exe; need alternative packaging (Nuitka, cx_Freeze) |
| ASM-02 | SQLite handles the concurrent load of a single-site pilot | High | Need PostgreSQL earlier than planned; adds complexity |
| ASM-03 | CTCAE v5.0 terms can be mapped to structured questionnaire questions | High | Need different input approach; may affect grading accuracy |
| ASM-04 | Vanilla HTML/CSS/JS is sufficient for the UI | High | Need framework (Vue/React); adds build step and complexity |
| ASM-05 | Clinician users have modern browsers (Chrome/Edge/Firefox) | High | Need to support IE11 or older browsers; significant effort |
| ASM-06 | PyInstaller produces a .exe that passes Windows Defender | Medium | Need code signing certificate; additional cost and process |
| ASM-07 | The governance standard's stage cycle is achievable within the timeline | Medium | Need to compress stages; document waivers for skipped steps |
| ASM-08 | Dr Kais can provide clinical input within the discovery phase timeline | Medium | Blocks grading engine and escalation protocol; delays build |
| ASM-09 | The MVP will be used for demonstration only, not with real patients | High | Need HDS hosting, GDPR compliance, regulatory qualification earlier |
| ASM-10 | Drop-in patching is sufficient for the pilot phase | High | Need installer-based update mechanism; adds complexity |
| ASM-11 | The CTCAE grading rules are deterministic (no ML/AI needed for MVP) | High | Need different approach; may affect grading accuracy |
| ASM-12 | Users will read the README.txt for patching instructions | Medium | Need in-app update mechanism; adds V2 feature |
| ASM-13 | The application runs entirely on localhost for MVP demo | High | Need hosting infrastructure; adds deployment complexity |
| ASM-14 | Role-based access control can be implemented with simple session tokens | High | Need OAuth/SAML; adds authentication complexity |
| ASM-15 | The governance standard allows STANDARD-class merging of roles | High | Need full 9-agent staffing; increases overhead |
6. SUCCESS CRITERIA
6.1 MVP Delivery Success Criteria
| # | Criterion | How Verified |
|---|
| SC-01 | .exe launches on clean Windows 10/11 with no Python installed | Smoke test on clean VM |
| SC-02 | All 12 core features (F1-F12) functional | Feature checklist; demo walkthrough |
| SC-03 | CTCAE grading produces correct grades for sample inputs | Unit tests; clinical validation |
| SC-04 | Alert routing works for all three tiers (routine/urgent/emergency) | Integration test; demo scenario |
| SC-05 | All 8 user roles can log in and perform their primary actions | Role-based test matrix |
| SC-06 | Database survives patching (overwrite .exe, preserve data) | Patch test on copy |
| SC-07 | Application runs from USB stick on different machine | Portability test |
| SC-08 | Zero pip dependencies at runtime | Dependency scan of bundled .exe |
| SC-09 | Part I compliance audit passes (or FAILs documented with waivers) | Audit table |
| SC-10 | Stakeholder demo received positive feedback | Feedback log |
6.2 Clinical Validation Success Criteria
| # | Criterion | How Verified |
|---|
| SC-11 | Grading rules cover prioritized CTCAE terms | Clinical advisor sign-off |
| SC-12 | Escalation protocol matches clinical best practice | Clinical advisor sign-off |
| SC-13 | Patient guidance content is clinically appropriate | Clinical advisor sign-off |
| SC-14 | Export summary is suitable for clinical record insertion | Clinical advisor review |
6.3 Governance Success Criteria
| # | Criterion | How Verified |
|---|
| SC-15 | All requirements traced bidirectionally | RTM orphan counts = 0 |
| SC-16 | All changes classified before implementation | CR log review |
| SC-17 | Builder != Verifier on every artifact | RACI matrix |
| SC-18 | All registers maintained and current | Register completeness check |
| SC-19 | Handover file enables cold-start by new operator | Cold-start test |
| SC-20 | Lessons harvested and documented | Knowledge folder |
END OF EXECUTION PLAN