# Implementation Roadmap — Milestone 1
## AI-Guided Cardio Thoracic Surgery Patient Intake System

**Version:** 2.0
**Date:** 2026-05-12
**Status:** Draft

This roadmap translates the PRD, DB Architecture, Technical Architecture, and TRD into a sequenced delivery plan for interns. It defines the module split, four 1-week sprints, and acceptance criteria for each sprint. The build sequence puts the highest-risk items (Claude API integration, session concurrency) into dedicated sprints where they can fail fast.

**Team:** PTL + TL + 3 interns. TL guides and reviews — does not write code. Interns own all implementation.

---

## Architecture at a Glance

Four services, one backend:

```
React PWA (frontend)
  ↕ REST / HTTPS
FastAPI (single backend — auth, sessions, DB, Claude)
  ↕ SQLAlchemy          ↕ aioredis
PostgreSQL             Redis
```

Web Speech API runs in the browser — no audio ever sent to backend. Claude API is called as internal Python functions inside FastAPI — not a separate service.

---

## Scope

### In this delivery (MVP — June 6, 2026)

| # | Capability |
|---|---|
| 1 | CTS-specific AI-guided questionnaire |
| 2 | Browser-native audio transcription (Web Speech API — English, Hindi, Telugu) |
| 3 | Dynamic question adaptation based on patient responses |
| 4 | Session auto-save on every response submission |
| 5 | Session resumption from exact stopping point |
| 6 | One session per patient per retention window — handoff continuity |
| 7 | Up to 5 concurrent staff sessions enforced |
| 8 | Patient summary generated ≤30s after completion |
| 9 | Flagged answers shown on completion screen |
| 10 | Ask More — re-open a completed session for continued Q&A |
| 11 | Staff accounts: name, role, department, email + PIN |
| 12 | Daily patient ID — data wiped after DATA_RETENTION_HOURS (default 48h) |

### Explicitly deferred (post-June 6)

| Capability | Deferral rationale |
|---|---|
| Senior consultation alerts | M2 |
| Full RBAC enforcement | Role stored in M1; restrictions enforced in M2 |
| Audit logging | M2 |
| Admin management UI | Pre-seeded accounts for MVP; UI in M3 |
| Doctor protocol configuration | Default protocol pre-loaded; config UI in M3 |
| Multi-department onboarding | Schema ready in M1; second department in M4 |

---

## Team Map

| Name | Role | Ownership |
|---|---|---|
| Vara Kumar Jagarapu | PTL | External API procurement, go/no-go decisions |
| Gundam Sree Sahithi | TL | Guides, reviews PRs, unblocks interns — does not write code |
| Intern 1 | Dev | FastAPI — auth, session CRUD, DB models, Redis, APScheduler |
| Intern 2 | Dev | React PWA — intake UI, Web Speech API, summary view, account management |
| Intern 3 | Dev | Claude integration — `get_next_question()`, `generate_summary()`, HTTPS setup, CI/CD |

---

## Dependency Graph

The build order is not arbitrary. Each arrow below encodes a blocking dependency: the downstream module cannot be usefully developed until the upstream module produces its output contract. External API access (STT and AI/LLM) gates two separate modules and must be resolved on Day 1.

```items
---
title: Module Dependency Graph
default_open_depth: -1
color_by:
  sprint:
    Sprint 1: "#d66d6b"
    Sprint 2: "#ff9900"
    Sprint 3: "#99ff00"
    Sprint 4: "#00e1ff"
  external:
    true: "#e53935"
    false: "#9e9e9e"
  critical_path:
    "true": "#e53935"
    "false": "#9e9e9e"
---

External APIs (procure Day 1) | color: "#b77100":
  - EXT1 :: STT API | external: true | critical_path: true
  - EXT2 :: AI/LLM API | external: true | critical_path: true

Foundation | color: "#6b8fd6":
  Auth:
    - AUTH :: Authentication & Authorization | sprint: Sprint 1 | critical_path: true
  Data Models:
    Patient:
      - DM_PAT_ID :: Daily Patient ID | sprint: Sprint 1 | critical_path: true
      - DM_PAT_PROF :: Patient Profile | sprint: Sprint 1 | critical_path: false
    Session:
      - DM_SES_CHK :: Session Checkpoint | sprint: Sprint 1 | critical_path: true
      - DM_SES_ST :: Session State | sprint: Sprint 1 | critical_path: true
    Clinical:
      - DM_CLIN_QS :: Questionnaire Schema | sprint: Sprint 1 | critical_path: true
      - DM_CLIN_RR :: Response Records | sprint: Sprint 1 | critical_path: true
      - DM_CLIN_AR :: Alert Records | sprint: Sprint 1 | critical_path: false
  CI/CD:
    - CICD :: Pipeline & Deployment Config | sprint: Sprint 1 | critical_path: false

Session Management | color: "#5aa469":
  - SES_SAVE :: Auto-save (30s interval) | sprint: Sprint 2 | critical_path: true
  - SES_RES :: Session Resume | sprint: Sprint 2 | critical_path: true
  - SES_CONC :: Concurrency Control | sprint: Sprint 2 | critical_path: false

Intake | color: "#4c8eda":
  - INT_QE :: Questionnaire Engine | sprint: Sprint 2 | critical_path: true
  - INT_PE :: Protocol Engine | sprint: Sprint 2 | critical_path: true
  - INT_UI :: Device UI | sprint: Sprint 2 | critical_path: false

Transcription | color: "#8b6fcf":
  - TRX_AC :: Audio Capture | sprint: Sprint 2 | critical_path: false
  - TRX_STT :: STT Integration | sprint: Sprint 2 | critical_path: true

AI Engine | color: "#c4688c":
  - AIE_PA :: Pattern Analysis | sprint: Sprint 3 | critical_path: true
  - AIE_ALT :: Alert System | sprint: Sprint 3 | critical_path: true
  - AIE_SUM :: Summary Generator | sprint: Sprint 3 | critical_path: true
  - AIE_DQ :: Doctor Query Interface | sprint: Sprint 3 | critical_path: false

Go-Live | color: "#52df5e":
  - GLV :: Integration + Go-Live (Sprint 4) | sprint: Sprint 4 | type: Go-Live | critical_path: true

EXT1 ->|gates STT access| TRX_STT
EXT2 ->|gates LLM access| AIE_PA
AUTH ->|user identity| INT_QE
AUTH ->|user identity| SES_SAVE
AUTH ->|user identity| TRX_AC
AUTH ->|user identity| AIE_PA
DM_PAT_ID ->|patient lookup| INT_QE
DM_PAT_ID ->|patient lookup| SES_SAVE
DM_SES_CHK ->|last checkpoint| SES_RES
DM_SES_ST ->|slot state| SES_CONC
DM_CLIN_QS ->|question schema| INT_QE
DM_CLIN_RR ->|response history| AIE_PA
DM_CLIN_AR ->|alert records| AIE_ALT
CICD ->|deployment| GLV
SES_SAVE ->|active session| INT_QE
SES_RES ->|restored session| INT_QE
SES_CONC ->|slot allocation| INT_QE
SES_SAVE ->|session state| GLV
INT_QE ->|audio trigger| TRX_AC
INT_PE ->|branching rules| INT_QE
INT_UI ->|staff input| INT_QE
INT_QE ->|response stream| AIE_PA
INT_QE ->|completed intake| GLV
TRX_AC ->|raw audio| TRX_STT
TRX_STT ->|transcribed text| AIE_PA
AIE_PA ->|detected patterns| AIE_ALT
AIE_PA ->|session analysis| AIE_SUM
AIE_PA ->|patient context| AIE_DQ
AIE_ALT ->|alert output| GLV
AIE_SUM ->|patient summary| GLV
AIE_DQ ->|query interface| GLV
```

**Critical path**: FOUNDATION → SESSION-MGMT → AI-INTEGRATION → Go-Live. Claude API access must be confirmed Day 1 — if delayed past Day 3, Sprint 2 AI work uses mocks.

---

## Milestone Plan

| Milestone | Date | Submodules complete | What it delivers | Success criteria |
|---|---|---|---|---|
| **M0: APIs Procured** | May 11 (Day 1) | STT API · AI/LLM API | External API access confirmed | PTL has working API keys for both services |
| **M1: Foundation Complete** | May 17 | Auth · Daily Patient ID · Patient Profile · Session Checkpoint · Session State · Questionnaire Schema · Response Records · Alert Records · CI/CD | Login works; data models seeded; CI/CD pipeline green | Medical staff can authenticate; patient daily ID can be created and queried |
| **M2: Intake + Session Live** | May 24 | Questionnaire Engine · Protocol Engine · Device UI · Audio Capture · STT Integration · Auto-save · Session Resume · Concurrency Control | Medical staff can conduct an end-to-end intake: audio captured, transcribed, questions adapt, session auto-saves and resumes after interruption | FR-001–FR-005, FR-010–FR-012, FR-014 acceptance criteria met |
| **M3: AI Engine Live** | May 31 | Pattern Analysis · Alert System · Summary Generator · Doctor Query Interface | Alerts fire during intake when concerning patterns are detected; doctor can query AI about a patient; summary generated within 30 seconds of session end | FR-006–FR-009 acceptance criteria met; NFR latency targets hit (≤30s alerts, ≤30s summary, ≤5s transcription) |
| **M4: Go-Live** | June 6 | All MVP submodules | Full MVP deployed to hospital environment; all FR-001–FR-014 acceptance criteria validated | End-to-end UAT sign-off; NFRs validated under concurrent load (5 users); zero P0 defects |

---

## Sprint Plan

| Sprint | Intern 1 (FastAPI) | Intern 2 (React PWA) | Intern 3 (Claude + Integration) |
|---|---|---|---|
| **Sprint 1** (May 11–17) | FastAPI skeleton, Docker Compose, DB models (SQLAlchemy), auth endpoints (login/logout), staff CRUD, bcrypt PIN | Project scaffold, React Router, login screen, intake list screen (static data), account management form | Claude API setup, system prompt draft for CT Surgery, test `get_next_question` with mock history |
| **Sprint 2** (May 18–24) | Session CRUD (POST /sessions, GET /sessions, GET /sessions/{id}/respond), Redis integration (patient lock, staff session, concurrency), APScheduler data wipe | Web Speech API integration (English/Hindi/Telugu), patient info form, Q&A screen with mic button + text fallback, transcription display + edit | Wire `get_next_question` into POST /sessions/{id}/respond; INTAKE_COMPLETE signal; is_flagged scan |
| **Sprint 3** (May 25–31) | POST /sessions/{id}/complete (summary write), POST /sessions/{id}/ask-more, GET /sessions/{id}/summary | Completion screen (flagged answers list), summary view, Ask More button, intake history panel on Q&A screen | `generate_summary` function; Ask More full conversation history pass-through; latency tuning |
| **Sprint 4** (Jun 1–6) | Load testing (5 concurrent users), bug fixes, security review | End-to-end integration polish, UAT fixes | Integration fixes, prompt tuning, latency validation |

### Contract 1 — Auth → All Modules
**Producer**: FOUNDATION → Auth
**Consumers**: Questionnaire Engine, Device UI, Auto-save, Audio Capture, Pattern Analysis

## Frontend–Backend API Contract

These are the interfaces Intern 1 and Intern 2 must agree on before Sprint 2 begins. Full specs are in [trd-milestone-1.md](trd-milestone-1.md).

### Session start response (POST /sessions → 201)
```json
{
  "sessionId": "uuid",
  "status": "CREATED",
  "patient": { "dailyId": "P001", "name": "Rajan Kumar", "age": 54, "gender": "Male" },
  "intakeHistory": [],
  "firstQuestion": { "id": "q_chief_complaint", "text": "What brings the patient in today?" }
}
```

### Contract 2 — Session-Mgmt → Intake
**Producer**: SESSION-MGMT → Auto-save · Session Resume · Concurrency Control
**Consumer**: INTAKE → Questionnaire Engine

Questionnaire Engine requests active session and restored session from SESSION-MGMT before any questionnaire state is written.

```
SessionHandle {
  sessionId:      string (UUID)
  patientDailyId: string
  status:         "ACTIVE" | "PAUSED" | "COMPLETED"
  lastCheckpoint: ISO8601 timestamp
  resumePoint:    { questionId: string, responsesSoFar: QuestionResponse[] }
}
```

### Contract 3 — Intake → Transcription
**Producer**: INTAKE → Questionnaire Engine (audio trigger)
**Consumer**: TRANSCRIPTION → Audio Capture → STT Integration

Questionnaire Engine triggers Audio Capture per response slot; STT Integration returns transcribed text. Latency SLA: ≤5 seconds per chunk.

```
AudioChunk {
  sessionId:   string
  sequenceNo:  int
  audioData:   base64-encoded PCM / provider format
  languageHint: ISO 639-1 language code | null
}

TranscribedText {
  sessionId:      string
  sequenceNo:     int
  text:           string (English)
  sourceLanguage: ISO 639-1 code
  confidence:     float (0–1)
  latencyMs:      int
}
```

### Contract 4 — Intake → AI-Engine (response stream)
**Producer**: INTAKE → Questionnaire Engine
**Consumer**: AI-ENGINE → Pattern Analysis

After each transcribed text is received, Questionnaire Engine pushes a `ResponsePayload` (response stream) to Pattern Analysis.

```
ResponsePayload {
  sessionId:   string
  questionId:  string
  responseText: string
  timestamp:   ISO8601
  protocolId:  string  // which CTS protocol is active
}
```

### Contract 5 — AI-Engine → Intake (next question + alert)
**Producer**: AI-ENGINE → Pattern Analysis · Alert System
**Consumer**: INTAKE → Questionnaire Engine · Device UI

Pattern Analysis returns a `GuidanceResponse` after each `ResponsePayload`. Questionnaire Engine advances to the next question; Device UI surfaces any alert.

```
GuidanceResponse {
  sessionId:     string
  nextQuestion:  { questionId: string, text: string } | null
  alert:         AlertEvent | null
  sessionComplete: boolean
}

AlertEvent {
  alertId:    string
  patternId:  string
  rationale:  string  // no diagnostic language — describes pattern only
  severity:   "LOW" | "MEDIUM" | "HIGH"
}
```

### Contract 6 — AI-Engine → Doctor Interface (summary)
**Producer**: AI-ENGINE → Summary Generator · Doctor Query Interface
**Consumer**: INTAKE → Device UI (doctor-facing summary view)

Triggered on session completion. Summary Generator delivers `PatientSummary` within 30 seconds. Doctor Query Interface remains available for follow-up queries.

```
PatientSummary {
  summaryId:            string
  sessionId:            string
  keySymptoms:          string[]
  significantFindings:  string[]
  alertHistory:         AlertEvent[]
  generatedAt:          ISO8601
  generationLatencyMs:  int
}
```

---

## Parallel Work Plan

The 26-day window requires disciplined parallelism. The table below shows what each squad does each sprint and where sequencing forces serialization.

| Sprint | FOUNDATION | INTAKE | TRANSCRIPTION | SESSION-MGMT | AI-ENGINE |
|---|---|---|---|---|---|
| **Sprint 1** (May 11–17) | **Auth** (login, token validation) · **Data Models** — Patient (Daily ID, Profile), Session (Checkpoint, State), Clinical (Questionnaire Schema, Response Records, Alert Records) · **CI/CD** pipeline | **Questionnaire Engine** (static CTS protocol, text input) · **Device UI** (handheld shell) | **Audio Capture** (device detection, mock STT) | **Session State** · **Session Checkpoint** · patient daily ID CRUD | API contract definitions; AI/LLM provider setup |
| **Sprint 2** (May 18–24) | Done | **Protocol Engine** (dynamic branching, FR-004) · **Device UI** polish (audio indicator, fallback prompt, FR-005) | **STT Integration** — real STT API, regional language → English (FR-002, FR-003) | **Auto-save** (FR-011) · **Session Resume** (FR-012) · **Concurrency Control** — 5-slot queue (FR-010) | **Pattern Analysis** engine — runs against mock response stream |
| **Sprint 3** (May 25–31) | Done | Wire **GuidanceResponse** from AI-ENGINE into Questionnaire Engine · surface alerts in Device UI | Done | Done | **Alert System** (FR-007) · **Doctor Query Interface** (FR-008) · **Summary Generator** (FR-009) |
| **Sprint 4** (Jun 1–6) | Done | End-to-end integration, Device UI polish, UAT fixes | End-to-end integration with live STT | Load testing (5 concurrent users via Concurrency Control) | Latency tuning (≤30s alerts, ≤30s summary, ≤5s transcription); integration fixes |

**What must be sequential**: Session State and Session Checkpoint (CONTRACT-2: `active session` + `restored session`) must be stable before Questionnaire Engine writes any session state. Target: end of Sprint 1, Day 3. Pattern Analysis cannot consume real response stream until Questionnaire Engine implements Contract 4 (`response stream`) — Sprint 2, Day 3 target.

**What can truly run in parallel**: Audio Capture and Session State/Checkpoint have no dependency on each other and can proceed concurrently from Sprint 1. Pattern Analysis can build against mocked `response stream` data from Sprint 1 onward; it does not need live Questionnaire Engine data until Sprint 3 wiring.

---

### Epic 1 — FOUNDATION

The following structure is the Jira ticket scaffold. PTL creates epics and stories from this. Every story traces to an FR and through it to a Use Case.

---

### Epic 1 — FOUNDATION: Platform Infrastructure

**Submodules**:
- **Auth** — Authentication & Authorization (login, session timeout, token validation)
- **Data Models**
  - *Patient*: Daily Patient ID, Patient Profile
  - *Session*: Session Checkpoint, Session State
  - *Clinical*: Questionnaire Schema, Response Records, Alert Records
- **CI/CD** — Pipeline & Deployment Config

**Sprint 1 goal**: A logged-in medical staff member can reach an empty session screen.

```
Story: Docker Compose runs all 4 services locally
  Acceptance: docker compose up brings frontend, fastapi, postgres, redis online
  Acceptance: FastAPI health check at /health returns 200
  Acceptance: PostgreSQL schema matches db-architecture.md tables

Story: Admin can create a staff account  (Staff accounts)
  Acceptance: POST /staff creates account with name, role, department, email, bcrypt PIN
  Acceptance: PIN shown once at creation; stored as bcrypt hash (rounds: 12)
  Acceptance: Duplicate email returns 409 EMAIL_ALREADY_EXISTS

Story: Admin can update/deactivate/unlock a staff account
  Acceptance: PATCH /staff/{id} updates name, resets PIN, deactivates, or unlocks
  Acceptance: Deactivation releases any active Redis session lock held by that staff

Story: Staff login works and session is JWT-secured
  Acceptance: POST /auth/login succeeds with valid email + PIN
  Acceptance: JWT issued (HS256, 30-min expiry); stored in React memory only
  Acceptance: 5 consecutive failed PIN attempts sets locked_at; unlocked via PATCH /staff/{id} with unlock: true
  Acceptance: Inactive JWT auto-expires; staff must re-login

Story: Claude API key is active
  Acceptance: Test call to Claude API returns a valid completion
  Acceptance: ANTHROPIC_API_KEY configured in FastAPI .env
```

---

### Epic 2 — SESSION-MGMT

**Submodules**:
- **Questionnaire Engine** — CTS question flow, response capture, branching logic execution
- **Protocol Engine** — Dynamic adaptation rules, CTS-specific condition coverage
- **Device UI** — Handheld-optimized interface, audio quality indicator, session controls

**Sprint 1 goal**: Medical staff can navigate a static CTS questionnaire on a handheld device.

```
Story: Staff can start or resume an intake session
  Acceptance: POST /sessions checks Redis for existing session
  Acceptance: New patient → creates patient + session rows; sets Redis TTL keys
  Acceptance: Existing patient with no lock → acquires lock, returns existing responses
  Acceptance: Existing patient with lock held by another → 409 SESSION_IN_USE

Story: Session auto-saves on every response
  Acceptance: Every POST /sessions/{id}/respond writes to question_responses immediately

Story: Session lock TTL refreshes on every response
  Acceptance: patient_lock and staff:{staffId}:session TTL both reset to 30min on /respond

Story: Up to 5 staff sessions enforced at login
  Acceptance: count of staff:*:session Redis keys checked at POST /auth/login
  Acceptance: 6th login attempt returns 503 MAX_SESSIONS_REACHED
  Acceptance: Slot freed on logout or JWT expiry

Story: Patient data wiped after DATA_RETENTION_HOURS
  Acceptance: FastAPI APScheduler runs hourly: DELETE FROM patients WHERE expires_at < NOW()
  Acceptance: CASCADE deletes all child rows (sessions, responses, summaries)
  Acceptance: Redis keys self-expire via TTL — no extra cleanup needed
```

---

### Epic 2b — TRANSCRIPTION: Audio Capture & STT Integration

**Submodules**:
- **Audio Capture** — Multi-source detection (built-in, Bluetooth, wired), quality indicator, fallback on failure
- **STT Integration** — Regional language → English transcription via STT API (≤5s latency, ≥90% accuracy)

**Sprint 2 goal**: Staff speech in any regional language is transcribed and fed into the questionnaire engine.

---

### Epic 3 — SESSION-MGMT: Resilient Session Handling

**Submodules**:
- **Auto-save** — 30s interval saves, section-change triggers, non-blocking writes
- **Session Resume** — Checkpoint retrieval, partial response restoration, fresh-start option
- **Concurrency Control** — Slot management for up to 5 concurrent users, queue + notify

**Sprint 2 goal**: Sessions survive interruptions and support 5 concurrent users.

```
Story: Staff can view the intake list
  Acceptance: GET /sessions shows all sessions for the department
  Acceptance: Each row shows patient daily ID, name, status, last updated
  Acceptance: ACTIVE and COMPLETED sessions visible; tapping any row opens session

Story: Staff can complete patient info form and start intake
  Acceptance: Form collects daily patient ID, name, age, gender
  Acceptance: Submit calls POST /sessions
  Acceptance: Error shown if lock is held by another staff (409 SESSION_IN_USE)

Story: Staff can conduct Q&A with mic input or text input
  Acceptance: One question visible at a time
  Acceptance: Mic button activates Web Speech API; transcribed text appears in editable field
  Acceptance: Staff can correct transcription before submitting
  Acceptance: Language selector: English, Hindi, Telugu — changes recognition.lang
  Acceptance: If Web Speech API unavailable, text input appears automatically
  Acceptance: Staff can type or speak whatever they know ("NA", "patient doesn't recall") and submit normally — no separate skip action

Story: Completion screen shows flagged answers
  Acceptance: intakeComplete: true triggers completion screen
  Acceptance: Flagged questions listed with question text and sequence number
  Acceptance: Submit button calls POST /sessions/{id}/complete

Story: Summary view renders structured output
  Acceptance: Summary text displayed in labelled sections
  Acceptance: Ask More button calls POST /sessions/{id}/ask-more and returns to Q&A screen
  Acceptance: GET /sessions/{id}/summary retrieves already-generated summary

Story: Account management form (Admin only)
  Acceptance: Admin can create staff account via POST /staff
  Acceptance: Admin can update/deactivate/unlock via PATCH /staff/{id}
  Acceptance: PIN shown once at creation/reset; not retrievable after save
```

---

### Epic 4 — AI-INTEGRATION

**Submodules**:
- **Pattern Analysis** — Continuous CTS-specific symptom pattern detection against live session responses
- **Alert System** — Senior consultation alert generation (≤30s), severity prioritization, staff acknowledgement
- **Summary Generator** — Post-session patient summary (≤30s), symptom highlights + alert history
- **Doctor Query Interface** — Free-text doctor queries against intake data, follow-up query chaining

**Sprint 3 goal**: The system detects concerning patterns, alerts staff, and generates summaries for doctors.

```
Story: Claude returns the first question overview + question 1
  Acceptance: POST /sessions (new) calls get_next_question with empty conversation_history
  Acceptance: Claude returns an overview of standard questions + first question text
  Acceptance: Response arrives in ≤2s

Story: Claude returns next question after each response
  Acceptance: POST /sessions/{id}/respond calls get_next_question with full history
  Acceptance: Next question arrives in ≤2s
  Acceptance: Claude handles Hindi and Telugu input — always responds in English

Story: Claude signals INTAKE_COMPLETE when all required questions are covered
  Acceptance: intakeComplete: true only after all required question_bank entries are covered
  Acceptance: Backend scans question_responses and sets is_flagged = true for non-substantive answers
  Acceptance: Non-substantive = "no", "i don't know", "na", empty/null, or equivalent short dismissals

Story: Summary generated within 30 seconds of session completion
  Acceptance: POST /sessions/{id}/complete calls generate_summary
  Acceptance: Summary text returned ≤30s
  Acceptance: Summary stored in patient_summaries; latencyMs recorded
  Acceptance: If Ask More leads to re-completion, patient_summaries is UPDATEd (not inserted)

Story: Ask More re-opens session and passes full history to Claude
  Acceptance: POST /sessions/{id}/ask-more checks concurrency (≤5); returns 503 if full
  Acceptance: intake_sessions.status → ACTIVE, completed_at → NULL
  Acceptance: Full conversation history passed to Claude; Claude continues from where it left off
  Acceptance: New session_contributors row inserted if different staff
```

---

## Open Questions

All previous open questions (OQ-01 through OQ-06) are resolved. No blocking open questions remain.

| Question | Resolution |
|---|---|
| Which regional languages? | English, Hindi, Telugu — hardcoded in M1 |
| Which STT provider? | Web Speech API (browser-native, free) — no external STT service |
| Which AI/LLM model? | Claude API — `claude-sonnet-4-6` |
| Daily patient ID in scope? | Yes — MVP foundational |
| RBAC for M1? | Role stored, not enforced — all authenticated staff have full access in M1 |
| Encryption standard? | bcrypt rounds 12 for PIN; HS256 for JWT; HTTPS (TLS) for all traffic |
| Data retention window | Configurable via DATA_RETENTION_HOURS env var (default 48h) |
| Doctor AI query interface | Removed from M1 — deferred to M2 or later |

---

## Approval

Approved by:
Role:
Date:

Approved by:
Role:
Date: