# Client Context Cardiology departments face a structural problem: patient volumes have outpaced the time doctors can spend per consultation. With only 2–3 minutes available per patient, critical information goes uncollected, early warning signs go unnoticed, and medical staff operate without systematic intake protocols. This project — the AI-enabled Clinical Decision Support System — exists to close that gap. Divami is building an AI-guided intake and decision support platform that enables medical staff to conduct structured 5-minute patient evaluations and provides cardiologists with a comprehensive patient picture before they walk into the room. The MVP targets a single cardiology department at a hospital facility, with a delivery timeline of 4–6 months. --- ## Product Summary The system has three interlocking functions: - **AI-guided intake:** Medical staff conduct structured 5-minute patient evaluations on handheld devices, guided by AI-driven cardiology-specific questioning that adapts based on patient responses. Audio input is transcribed from regional languages to English in real time. - **Senior consultation alerting:** The system identifies concerning symptom patterns during intake and alerts medical staff to consult senior staff — without providing diagnosis or emergency classification. - **Doctor intelligence interface:** Cardiologists review a 1–2 minute AI-generated patient summary before consultation and can query the AI for deeper symptom analysis and pattern matching. Supporting this are session resumption (intake resumes exactly where it stopped after any interruption), role-based access control, audit logging with 48-hour retention, and administrative and doctor configuration modules. --- ## User Types **Medical Staff** (junior doctors, medical assistants, registered nurses) Primary pain: spend consultation time re-collecting basic information that should already be structured; no standardized intake protocol; no early-warning system to flag when a case needs senior eyes. **Cardiologists** (consultant doctors) Primary pain: walk into consultations without a complete patient picture; must re-ask questions already asked by medical staff; no tool to query patient data quickly during the 2–3 minute window. **Hospital Administrators** Primary pain: no unified system for onboarding medical staff, managing system configuration, or setting up language support; configuration changes require IT involvement. --- ## Constraints **Scope** - Single hospital, cardiology department only (MVP) - No EMR/EHR integration - No permanent patient data storage — session data retained for 48 hours only - No offline or poor-connectivity operation - No diagnosis, treatment recommendations, or emergency classification **Technical** - Network: requires 5G or equivalent bandwidth; connectivity is a hard dependency - Concurrency: maximum 5 simultaneous medical staff users - Session timeout: 30 minutes of inactivity - Authentication: simple login (specific method TBD during implementation) - [Daily Patient ID](glossary.md#daily-patient-id) tracking only — no integration with hospital patient systems **Delivery** - Timeline: 4–6 months to MVP, with potential expansion to other specialties thereafter - Team: PTL Vara Kumar Jagarapu, TL Gundam Sree Sahithi --- ## Unvalidated Assumptions These are the beliefs the project rests on that have not yet been confirmed. Each one is a potential failure point if wrong. Stage 10 must revisit which of these are validated before the vision is locked. 1. **Network reliability at point of care** — The target hospital has stable 5G or equivalent connectivity at the locations where intake sessions occur. *Not validated.* If coverage is inconsistent across wards, the system cannot function. 2. **Medical staff adoption without resistance** — Staff will adapt from manual, informal intake to a structured AI-guided workflow with minimal friction and no formal training. *Not validated.* The vision assumes zero-training onboarding; this depends on interface design quality that has not been prototyped or tested. 3. **Cardiologist protocol investment** — Cardiologists will actively configure questioning protocols, alert patterns, and AI agent sequences. *Not validated.* Doctor-customizable AI is a core differentiator, but it requires sustained cardiologist engagement that depends on buy-in not yet confirmed. 4. **AI training data quality for local cardiology** — Cardiology-specific AI models can be trained or sourced with sufficient accuracy for the symptom patterns common in the target hospital's patient population. *Not validated.* Generic cardiology datasets may not reflect local disease patterns or terminology. 5. **Regional language audio accuracy** — Speech-to-text transcription achieves ≥90% accuracy for medical terminology in the regional languages spoken by patients at this facility. *Not validated.* Language model availability and quality varies significantly by language and domain. 6. **Senior staff availability during operating hours** — Senior medical staff are reliably reachable for consultation when the system suggests escalation. *Not validated.* If senior staff are routinely unavailable, the alerting feature provides false assurance. --- ## Open Questions These must be resolved before or during stage 20 (Business Requirements). 1. **Client organisation name** — The hospital or healthcare organisation that is the client for this engagement has not been named. Required for formal documentation. 2. **Regional language priority** — Which 5 regional languages should be implemented first? The answer is facility-specific and affects AI model sourcing. 3. **Healthcare compliance standard** — What data encryption and regulatory compliance requirements apply (e.g., India's DPDP Act, hospital IT security policy)? Currently undefined. 4. **Senior staff notification method** — How are senior staff notified when the system suggests consultation? This is explicitly out of scope for the system but the external mechanism must be confirmed to avoid a workflow gap. 5. **Prior tooling in use** — Are there any existing digital intake tools, workarounds, or competing systems currently in use at the target facility? None were mentioned in available documents. 6. **Protocol validation process** — What clinical review is required before a cardiologist-defined protocol can be activated? The clinical governance process has not been defined. 7. **Default configuration at deployment** — What initial system parameters, protocols, and language settings will be pre-configured before go-live? --- ## Approval This document requires 2 sign-offs before Stage 10 (Vision) can proceed. ``` Approved by: Role: Date: Approved by: Role: Date: ```