Add README with file type guidelines and snake_case naming rule; update .gitignore typo

proj_level_reading/PLAN/CONTEXT_VISION_SCOPE.md

@@ -0,0 +1,311 @@
+# VISION_SCOPE.md
+
+*VKIST Musculoskeletal Pilot Project Specification & Strategic Context The Project Vision*
+
+---
+
+## 1. Project Identity, Motivation & Problem Statement
+
+### 1.1 Project Identity
+
+* **Project Name:** VKIST MSK Pilot Workspace.
+
+
+* **Pitch Matrix Date:** June 9, 2026.
+
+
+* **Active Cycle:** June 2, 2026 to September 2, 2026 (Strict 3-Month Window).
+
+
+* **Engineering Paradigm:** **Hybrid Architecture Execution**—Macro-Planning driven via Structured Waterfall Phases coupled with Micro-Managed tactical execution loops via Agile Scrum Sprints.
+
+
+
+### 1.2 Core Motivations
+
+* **The Academic Migration:** Intentionally transitioning isolated, static machine learning model checkpoints from academic research codebases into an active, functional, and referenceable medical software ecosystem. This is critical to establishing the engineering team's operational value within the local healthcare community.
+
+
+* **Technological Convergence:** Infusing VKIST’s foundational Computer Vision models with modern advancements in Natural Language Processing (NLP) and robust web systems engineering architectures.
+
+
+* **Mitigating Clinical Exhaustion:** Systematically solving the crippling clinical time constraints endemic to Vietnamese public referral facilities (e.g., Bach Mai, Viet Duc) where outpatient counts regularly exceed 100 individual evaluations per single daily shift.
+* **Countering Dangerous Folk Interventions:** Offering a high-trust, data-backed clinical education mechanism to explicitly displace hazardous alternative practices (e.g., direct herbal leaf-wrapping or violent manual adjustment of unstable structures) that cause tissue infections or permanent anatomical failure.
+
+---
+
+## 2. Global System Boundary Layout
+
+```plantuml
+@startuml
+skinparam handwritten false
+skinparam monochrome true
+skinparam packageStyle rect
+skinparam shadowing false
+
+title VKIST MSK Pilot System - High-Level Boundary Topology
+
+package "Local Client Subsystem (Progressive Web App)" {
+    [PWA Frontend Core] as PWA
+    [TensorFlow.js Engine] as TFJS
+    [Local Storage / WebCrypto] as Crypto
+}
+
+package "Regional Edge Cloud Infrastructure (Vietnam Local Hub)" {
+    [FastAPI Processing Server] as API
+    [PyTorch Inference Pipe] as PyTorch
+    [ReportLab Generator] as PDF
+}
+
+package "External Operational Systems" {
+    [Clinical DICOM Source] as DICOM
+}
+
+DICOM --> API : Over 4G Network (pydicom Stream)
+PWA <--> API : HTTPS REST / Multi-modal IPC
+TFJS <--> PWA : Client-Side Text Segmentation
+Crypto <--> PWA : Decentralized AES-256 Storage
+PyTorch <--> API : DeepLabv3/UNet Context Serialization
+PDF <--> API : Automated PDF Export Generation
+@endum
+
+```
+
+---
+
+## 3. Comprehensive End-User Persona Matrices
+
+### 3.1 The Diagnostic Radiologist
+
+* **Identity Context:** Highly specialized medical doctors responsible for translating high-fidelity image structures into explicit text matrices to dictate treatment tracks.
+* **Demographics:** Ranges from tech-fluent, digitally native attendings to senior department directors (Ages 28–55).
+* **Operational Environment:** Low-ambient-light reading environments within high-pressure public hospitals; processing massive daily DICOM streams with tight turnaround times.
+* **Domain Mastery:** Exceptional structural pattern recognition across diverse modalities (X-Ray, CT, MRI).
+* **Critical Technical Knowledge Deficit:** Unfamiliar with machine learning edge-case behavioral profiles, model optimization constraints, or internal weight tuning.
+* **Attitude Towards AI Integration:** Receptive to deterministic systems that eliminate administrative overhead, calculate structural lines accurately, and prevent alert fatigue. Highly resistant to unproven, black-box demos that disrupt fast-paced screen setups.
+* **Product Team Architectural Mandate:** Implement **invisible workflow preservation**. The system must serve as an background validation layer that shields them from diagnostic liability without introducing extraneous clicks or system lag.
+
+### 3.2 The Rheumatologist & Orthopedic Surgeon
+
+* **Identity Context:** The definitive treatment architects who consume diagnostic data to orchestrate downstream pharmaceutical, mechanical, or invasive surgical paths.
+* **Demographics:** Clustered between ages 30 and 60. Senior members wield substantial institutional control over hospital procurement choices.
+* **Operational Environment:** Divided among sterile surgical suites, chaotic inpatient rounds, and heavily overcrowded outpatient clinics.
+* **Domain Mastery:** Advanced biomechanics, complex clinical diagnosis, and high-stakes legal/ethical responsibility for long-term recovery curves.
+* **Critical Technical Knowledge Deficit:** Lacks granular pixel-level physics understanding regarding raw ultrasound or MRI artifacts, and possesses no visibility into the patient's behaviors outside the clinical environment.
+* **Attitude Towards AI Integration:** Disinterested in shallow AI models identifying obvious fractures. Highly motivated by deep predictive algorithms (e.g., forecasting specific cartilage degeneration trajectories or hardware mechanical failure risks).
+* **Product Team Architectural Mandate:** Deliver an **intelligent clinical force multiplier**. The interface must feature rapid-consumption dashboards that synthesize fragmented data silos and automate visual patient translation layers to protect precious consultation minutes.
+
+### 3.3 The Physical Therapist / Physiotherapist
+
+* **Identity Context:** Downstream clinical executors tasked with translating high-level medical scripts into long-term physical, mechanical, and kinetic rehabilitation programs.
+* **Demographics:** Younger, highly active professionals (Ages 20–39).
+* **Operational Environment:** Highly demanding outpatient therapy units with extreme caseload rates (11 to 20+ patients per daily shift), causing severe time constraints and a high prevalence of work-related musculoskeletal disorders (WMSDs).
+* **Domain Mastery:** Functional kinetic rehabilitation, manual tissue therapies, and precision configuration of electro-physical modalities (TENS, NMES, Diathermy).
+* **Critical Technical Knowledge Deficit:** Limited radiological image processing literacy and minimal training in advanced clinical statistics.
+* **Attitude Towards AI Integration:** Cautious regarding professional devaluation, but highly responsive to objective tracking interfaces that validate client progression metrics across multiple touchpoints.
+* **Product Team Architectural Mandate:** Treat them as **kinetic movement athletes**. The PWA must serve as a lightweight digital exoskeleton, leveraging zero-GPU mobile rendering profiles to completely automate manual charting, expose tissue-depth calculations, and bridge cross-domain language gaps.
+
+### 3.4 The MSK Patient & Caregiver Proxy
+
+* **Identity Context:** The ultimate consumers of care, balancing chronic physical discomfort with severe medical information deficits.
+* **Demographics:** Elderly populations (Ages 45–80+) exhibiting low digital literacy, heavily supported by younger family caregivers (Ages 20–45) who act as their technology proxy.
+* **Operational Environment:** Home-based rehabilitation contexts and busy public waiting areas; highly susceptible to engaging video-based community medical misinformation.
+* **Domain Mastery:** Expert experiential awareness of their unique chronic pain boundaries; zero formal anatomical proficiency.
+* **Critical Technical Knowledge Deficit:** Incapable of parsing raw medical terminology or grayscale imaging slices, and unaware of the permanent physiological risks associated with non-standard folk medicine tracks.
+* **Attitude Towards AI Integration:** Highly receptive if the system transforms abstract scans into simple, intuitive 3D architectural representations that reduce clinical anxiety.
+* **Product Team Architectural Mandate:** Focus on **profound empathy and strict interface accessibility**. The application must run on legacy consumer smartphones, utilizing high-contrast views, large fonts, and dual-profile family data synchronization models.
+
+---
+
+## 4. Key Constraints & Regulatory Boundaries
+
+| Dimension | Constraint Parameter | Engineering Strategy |
+| --- | --- | --- |
+| **Statutory Data Governance** | Strict compliance with **Vietnam's Decree 13/2023/ND-CP** regarding sensitive personal health data protection. | Deploy client-side cryptographic scrubbing using the WebCrypto API. Ensure all production cloud infrastructure, file caches, and backend databases reside locally within sovereign Vietnamese data centers (e.g., Viettel IDC, VNPT). |
+| **Hardware Heterogeneity** | The patient/caregiver fleet consists largely of legacy, low-cost consumer smartphones with weak WebGL/GPU rendering capabilities. | Implement a **Hybrid Dual-Engine Subsystem** inside the PWA. If browser checks flag outdated GPUs, hot-swap Three.js out for a zero-GPU CPU-bound 36-frame flat image sequence turntable switcher to generate the interactive rotation effect. |
+| **Physical Context Barriers** | Physical therapists operate with hands continually covered in conductive gels, therapeutic oils, or sweat. | Design macro-scale UI target regions supporting knuckle-taps, simple touch vectors, and minimal textual input requirements during active sessions. |
+| **Operational Gating** | Vietnamese clinicians fear an unmanageable, uncompensated influx of open communication requests from patients. | **Strictly exclude open-ended chat loops** (e.g., Zalo/Messenger approximations). All data interfaces must use highly structured, asynchronous, one-way or tightly gated programmatic summaries. |
+
+---
+
+## 5. System Execution Milestones (3-Month Cycle)
+
+```plantuml
+@startgantt
+title VKIST MSK Pilot Project - Gantt Lifecycle View
+theme classic
+
+[Sprint 0: Pitch & Architecture Spike] lasts 11 days and starts 2026-06-02
+[Sprint 1: The Fast PoC Baseline] lasts 12 days and starts 2026-06-15
+[Sprint 2: Multi-Modal & NLP Integration] lasts 12 days and starts 2026-06-29
+[Sprint 3: The Collaborative Workspace] lasts 12 days and starts 2026-07-13
+[Sprint 4: The Patient-Facing PWA] lasts 12 days and starts 2026-07-27
+[Sprint 5: Feedback Pipeline & Hardening] lasts 12 days and starts 2026-08-10
+[Sprint 6: Beta Release & Evolution] lasts 10 days and starts 2026-08-24
+
+[Sprint 0: Pitch & Architecture Spike] is colored after Red
+[Sprint 1: The Fast PoC Baseline] is colored after Orange
+[Sprint 3: The Collaborative Workspace] is colored after Green
+[Sprint 6: Beta Release & Evolution] is colored after Blue
+@endgantt
+
+```
+
+### 5.1 Sprint-by-Sprint Implementation Scope
+
+* Sprint 0 | June 2 – June 12 | "Pitch & Architecture Spike" 
+
+    * *Deliverables:* Technical architecture clearance; validation audit of the VKIST machine learning stack (DeepLabv3/UNet models). Establish deployment paths for on-device and local edge server infrastructure.
+    - **Sprint Goal:** Secure administrative clearance and map research code constraints before system initialization.
+    - **Key Epic / Backlog Items:**
+        - 🎯 **Milestone:** Lock pitching presentation deck and win official project pitch on **June 9**.
+        - 🔍 **User & Market Discovery:** Complete identification parameters for the 4 primary user groups (Radiologists, Orthopedic Surgeons, Physiotherapists, Patients).
+        - 📋 **Requirements Engineering:** Finalize Functional Requirements (FR) and capture initial Non-Functional Requirements (NFR) regarding localized data governance.
+        - 🛠️ **Technical Spike:** Audit existing VKIST ML/NLP models (ConvNeXt, MedViT, and UNet architectures) to map web-deployment pathway boundaries.
+        - 🏗️ **Infrastructure Baseline:** Set up the base CI/CD pipelines to support rapid incremental code compilation.
+
+
+
+* Sprint 1 | June 15 – June 26 | "The Fast PoC Baseline" 
+
+
+    * *Deliverables:* Rapid UI prototype generation via high-fidelity mockups. Configure initial server pipelines (FastAPI `app.py`) to process raw array matrices, saving output metrics securely to internal storage.
+
+    - **Sprint Goal:** Establish an interactive end-to-end processing pipeline to lock early stakeholder buy-in.
+    - **Key Epic / Backlog Items:**
+        - 🎨 **Product Design:** Conduct UI/UX wireframing loops and publish interactive Figma prototype mockups.
+        - ⚡ **API Foundation:** Instantiate the FastAPI backend server topology to handle secure local asset transfers.
+        - 🩺 **ML Ingestion:** Connect file ingest pathways to load raw ultrasound images and wire them directly into the underlying classification pipeline.
+        - 🖼️ **Early Visual Layer:** Output early inference mask previews onto a basic browser-based preview window canvas.
+
+
+
+* Sprint 2 | June 29 – July 10 | "Multi-Modal & NLP Integration" 
+
+
+    * *Deliverables:* Embed localized NLP translation modules. Implement client-side privacy scrubbing masks to satisfy Decree 13 anonymization requirements before transferring assets over network boundaries.
+
+    - **Sprint Goal:** Build the multi-modal interaction engine while anchoring core statutory data security guardrails.
+    - **Key Epic / Backlog Items:**
+        - 🛡️ **Sovereign Privacy Architecture:** Implement automated client-side metadata scrubbing to ensure full compliance with **Vietnam's Decree 13/2023/ND-CP**.
+        - 💬 **Zero-Friction NLP Conduit:** Deploy the multi-modal diagnostic chat system using language interfaces to clean up fragmented clinical abbreviations.
+        - ⚙️ **Local Anonymization:** Configure on-device string parsers to sanitize personal identification tokens before indexing transactions to the server log.
+
+
+
+* Sprint 3 | July 13 – July 24 | "The Collaborative Workspace" 
+
+
+    * *Deliverables:* Deploy the asynchronous collaborative canvas allowing clinical annotation mapping. Isolate role-based permissions (e.g., read-only diagnostic configurations for downstream therapists).
+
+    - **Sprint Goal:** Release the shared cross-department canvas to safely link distinct clinical domains without record mutation.
+    - **Key Epic / Backlog Items:**
+        - 🤝 **Multidisciplinary Sync:** Standardize multi-user workspace access protocols, granting Physical Therapists read-only clinical analytics layers.
+        - ✏️ **Asynchronous Collaboration:** Build layers for asynchronous clinical annotations, drawing tools, and structured safety-check verification matrices.
+        - 🔬 **Frontline Verification:** Run target usability test rounds with professional clinical partners to isolate interface anomalies under high shift volumes.
+
+
+* Sprint 4 | July 27 – Aug 7 | "The Patient-Facing PWA" 
+
+    * *Deliverables:* Package the platform as an installable Progressive Web Application. Activate the hybrid graphic rendering pipelines to handle legacy consumer smartphones smoothly.
+
+    - **Sprint Goal:** Deliver an installable, empathetic patient portal optimized for lower-spec consumer hardware architectures.
+    - **Key Epic / Backlog Items:**
+        - 👵 **Empathetic UI Refactoring:** Build a jargon-free, high-contrast dashboard panel utilizing massive text scaling properties for elderly populations.
+        - 📱 **PWA Compilation:** Package the frontend application instance as a Progressive Web Application supporting cross-platform mobile browser configurations.
+        - 📉 **Zero-GPU Fallback System:** Deploy the dual-rendering branch infrastructure, automatically swapping intensive WebGL layers for flat image-sequence turntables on legacy smartphones.
+
+
+* Sprint 5 | Aug 10 – Aug 21 | "Feedback Pipeline & Hardening" 
+
+    * *Deliverables:* Establish public feedback channels and system optimization metrics. Optimize image transfer compression layers and configure automated cleanup scripts to prune data directories.
+
+    - **Sprint Goal:** Optimize backend asset processing throughput and activate structured community signal logging.
+    - **Key Epic / Backlog Items:**
+        - 📊 **Feedback Instrumentation:** Embed standard data-collection portals, project presentation hubs, and simplified error reporting dialogs.
+        - 🚀 **Performance Optimization:** Optimize image file loading routines, introduce multi-level asset caching, and compress backend array transfers.
+        - 🧹 **System Pruning:** Deploy background cleanup tasks to automatically purge unmanaged temporary file storage pools.
+
+
+* Sprint 6 | Aug 24 – Sept 2 | "Beta Release & Evolution" 
+
+    * *Deliverables:* Push the hardened workspace deployment to the target Vietnamese MSK cohort. Evaluate incoming system feedback metrics to construct the downstream long-term product backlog.
+
+    - **Sprint Goal:** Launch the verified pilot ecosystem to the target Vietnamese user fleet and chart long-term architecture steps.
+    - **Key Epic / Backlog Items:**
+        - 🚀 **Pilot Launch:** Deploy the application bundle onto local cloud data centers and open system channels to the target Vietnamese MSK medical cohort.
+        - 📈 **Telemetry Aggregation:** Analyze performance signatures, user friction patterns, and real-world system adoption logs.
+        - 🗺️ **Product Backlog Maturation:** Evaluate initial feedback metrics to build out a robust, prioritized downstream product feature backlog.
+
+```mermaid
+gantt
+    title VKIST Pilot Project - 3-Month Scrum Timeline Roadmap
+    dateFormat  YYYY-MM-DD
+    axisFormat  %b %d
+    todayMarker stroke-width:2px,stroke:#ff5555,stroke-dasharray:5
+
+    section June 2026
+    Sprint 0 : active, sp0, 2026-06-02, 2026-06-12
+    User & Market Discovery         :crit, active, 2026-06-02, 2026-06-12
+    Requirement Engineering         :active, 2026-06-02, 2026-06-12
+    Win pitch on June 9             :milestone, 2026-06-09, 1d
+    Audit VKIST ML/NLP models       :2026-06-02, 2026-06-12
+    Setup base CI/CD pipeline       :2026-06-02, 2026-06-12
+    
+    Sprint 1 : sp1, 2026-06-15, 2026-06-26
+    The 'Fast PoC' Baseline         :crit, 2026-06-15, 2026-06-26
+    System design & Figma mockups   :2026-06-15, 2026-06-26
+    Load Ultrasound & wire to ML    :2026-06-15, 2026-06-26
+    
+    Sprint 2 : sp2, 2026-06-29, 2026-07-10
+    Multi-Modal & NLP Integration   :crit, 2026-06-29, 2026-07-10
+    Decree 13 Data Privacy & Scrub  :2026-06-29, 2026-07-10
+    Integrate NLP advancements      :2026-06-29, 2026-07-10
+
+    section July 2026
+    Sprint 3 : sp3, 2026-07-13, 2026-07-24
+    The Collaborative Workspace     :crit, 2026-07-13, 2026-07-24
+    Real-time annotations & checks  :2026-07-13, 2026-07-24
+    Usability testing with allies   :2026-07-13, 2026-07-24
+    
+    Sprint 4 : sp4, 2026-07-27, 2026-08-07
+    The Patient-Facing PWA          :crit, 2026-07-27, 2026-08-07
+    Build simplified patient view   :2026-07-27, 2026-08-07
+    Zero-GPU Fallback PWA layer     :2026-07-27, 2026-08-07
+
+    section Aug - Sept 2026
+    Sprint 5 : sp5, 2026-08-10, 2026-08-21
+    Feedback Pipeline & Hardening   :crit, 2026-08-10, 2026-08-21
+    Setup portal & project page     :2026-08-10, 2026-08-21
+    Optimize asset loading speeds   :2026-08-10, 2026-08-21
+    
+    Sprint 6 : sp6, 2026-08-24, 2026-09-02
+    Beta Release & Evolution        :crit, 2026-08-24, 2026-09-02
+    Analyze incoming feedback logs  :2026-08-24, 2026-09-02
+    Draft future product backlog    :2026-08-24, 2026-09-02
+    Project Cycle Complete          :milestone, 2026-09-02, 1d
+
+```
+
+Below is the minimal timeline of the project
+
+| Sprint | Date Range | Focus Block & Core Objectives |
+| --- | --- | --- |
+| **Sprint 0** | June 02 – June 12 | Pitch & Arch Spike (User/Market Discovery & Requirement Engineering) |
+| **Sprint 1** | June 15 – June 26 | The Fast PoC Baseline (Fast & Proof-of-Concept System Validation) |
+| **Sprint 2** | June 29 – July 10 | Multi-Modal & NLP Integration (Natural, Zero-Friction Workflows) |
+| **Sprint 3** | July 13 – July 24 | The Collaborative Workspace (Multidisciplinary Coordination Layer) |
+| **Sprint 4** | July 27 – Aug 07 | The Patient-Facing PWA (Ready & Mobile-Optimized Platform) |
+| **Sprint 5** | Aug 10 – Aug 21 | Feedback Pipeline & Hardening (Optimizations & Community Review Loops) |
+| **Sprint 6** | Aug 24 – Sept 02 | Beta Launch & Evolution (Deployment to MSK Cohort & Backlog Drafting) |
+
+
+---
+
+## 6. Project Success Criteria ("Done a Good Job")
+
+1. **Zero Workflow Friction Impact:** Frontline medical specialists can access automated model insights and verify clinical states without adding extra configuration steps or time penalties to their existing routines.
+2. **Deterministic Cross-Device Stability:** The user interface achieves smooth performance across the user fleet, successfully scaling down to CPU-bound rendering modes on legacy mobile chipsets without crashing.
+3. **Flawless Statutory Compliance Verification:** Zero unencrypted patient data leaks or data non-compliance events recorded during data exchanges, fully satisfying Decree 13 protection protocols.
+4. **Sustained User Cohort Retention:** Targeted physical therapists and clinicians actively utilize the structured workspace instead of bypassing the ecosystem in favor of unsecured external messaging networks.
+5. **Successful Academic-to-Production Migration:** Smoothly packaging VKIST's core image segmentation and classification files into an optimized, installable, high-efficiency web production application.

proj_level_reading/Requirement_Analysis/FRs-Database/FR-Engineer-DB .csv

@@ -0,0 +1,21 @@
+ComponentName,ReqID,ReqName,IsOptional,UserProfileCode,Sys/Act,PreCondition,PostCondition,VerboseDescription,Engineer
+Prescription Parser / WebML Module,ULTS-Prescription Parser / WebML Module-FR-4,PARSE clinical text on-device,No,UP6,System,[The physical therapist opens the camera scanner within the PWA and captures the text-based prescription],"[The targeted joint zone, therapy modality, and frequency are extracted locally, and any structural contraindication warnings are displayed]","ULTS-Prescription Parser / WebML Module-FR-4: As an [Physical Therapist], provide that [The physical therapist opens the camera scanner within the PWA and captures the text-based prescription], the [System] shall PARSE clinical text on-device, ensuring that [The targeted joint zone, therapy modality, and frequency are extracted locally, and any structural contraindication warnings are displayed]",Đạt Trần Tiến (Daves Tran)
+3D Mapping / Visualization Engine,ULTS-3D Mapping / Visualization Engine-FR-5,MAP spatial coordinates to visual models,No,UP6,System,[Abstract text tokens are successfully parsed from the prescription.],[A dynamic visual guide—rendered via WebGL or a zero-GPU CPU-bound 2D image sequence based on device capabilities—with an SVG vector highlight over the target tissue area is displayed.],"ULTS-3D Mapping / Visualization Engine-FR-5: As an [Physical Therapist], provide that [Abstract text tokens are successfully parsed from the prescription.], the [System] shall MAP spatial coordinates to visual models, ensuring that [A dynamic visual guide—rendered via WebGL or a zero-GPU CPU-bound 2D image sequence based on device capabilities—with an SVG vector highlight over the target tissue area is displayed.]",Đạt Trần Tiến (Daves Tran)
+Kinetic Overlay Module,ULTS-Kinetic Overlay Module-FR-6,RENDER muscle depth cross-sections,No,UP6,System,[The physical therapist activates the Kinetic Overlay Toggle within the canvas view],[Lightweight HTML SVG paths detailing muscle cross-sections and 1 cm to 5 cm depth color-coding are dynamically appended over the target treatment viewport],"ULTS-Kinetic Overlay Module-FR-6: As an [Physical Therapist], provide that [The physical therapist activates the Kinetic Overlay Toggle within the canvas view], the [System] shall RENDER muscle depth cross-sections, ensuring that [Lightweight HTML SVG paths detailing muscle cross-sections and 1 cm to 5 cm depth color-coding are dynamically appended over the target treatment viewport]",Đạt Trần Tiến (Daves Tran)
+Progress Tracking Module,ULTS-Progress Tracking Module-FR-7,LOG kinetic progress pins,No,UP6,System,[The physical therapist taps the screen workspace layer within the distinct Kinetic Tracking Channel.],"[Localized metrics including Range of Motion, 1-10 pain indices, and tissue behavior are serialized and pushed to the physician's tracking panel without mutating the primary medical file.]","ULTS-Progress Tracking Module-FR-7: As an [Physical Therapist], provide that [The physical therapist taps the screen workspace layer within the distinct Kinetic Tracking Channel.], the [System] shall LOG kinetic progress pins, ensuring that [Localized metrics including Range of Motion, 1-10 pain indices, and tissue behavior are serialized and pushed to the physician's tracking panel without mutating the primary medical file.]",Đạt Trần Tiến (Daves Tran)
+Patient Education Module,ULTS-Patient Education Module-FR-8,DEMONSTRATE joint mechanics dynamically,No,UP6,System,[The physical therapist moves the HTML Range-of-Motion slider within the Patient Demonstration Mode split layout.],"[A cached array of 2D illustrations seamlessly cycles using 0% GPU power to visually indicate joint flexion, extension, and soft-tissue impingement.]","ULTS-Patient Education Module-FR-8: As an [Physical Therapist], provide that [The physical therapist moves the HTML Range-of-Motion slider within the Patient Demonstration Mode split layout.], the [System] shall DEMONSTRATE joint mechanics dynamically, ensuring that [A cached array of 2D illustrations seamlessly cycles using 0% GPU power to visually indicate joint flexion, extension, and soft-tissue impingement.]",Đạt Trần Tiến (Daves Tran)
+DICOM Viewer / Annotation Module,ULTS-DICOM Viewer / Annotation Module-FR-9,RENDER haptic-assisted edge-snapping magnifier,No,UP7,System,[The clinician activates the annotation tool and drags the crosshairs near a high-contrast bone boundary on the multi-touch viewport.],"[A high-magnification lens appears 150px vertically above the touch point, the crosshairs automatically snap to the nearest boundary, and a localized native haptic pulse is triggered.]","ULTS-DICOM Viewer / Annotation Module-FR-9: As an [Rheumatologist & Orthopedic Surgeon], provide that [The clinician activates the annotation tool and drags the crosshairs near a high-contrast bone boundary on the multi-touch viewport.], the [System] shall RENDER haptic-assisted edge-snapping magnifier, ensuring that [A high-magnification lens appears 150px vertically above the touch point, the crosshairs automatically snap to the nearest boundary, and a localized native haptic pulse is triggered.]",Đạt Trần Tiến (Daves Tran)
+Asynchronous Communication Engine,ULTS-Asynchronous Communication Engine-FR-10,RECORD asynchronous voice and canvas telemetry (Session Recording & Replay),No,UP7,System,[The sending clinician records audio while navigating the viewport and drawing vectors on the case file workspace.],"[The microphone input and viewport coordinate state changes (X, Y positions, zoom, panning) are compiled into a serialized JSON timeline file for synchronized, threaded playback.]","ULTS-Asynchronous Communication Engine-FR-10: As an [Rheumatologist & Orthopedic Surgeon], provide that [The sending clinician records audio while navigating the viewport and drawing vectors on the case file workspace.], the [System] shall RECORD asynchronous voice and canvas telemetry (Session Recording & Replay), ensuring that [The microphone input and viewport coordinate state changes (X, Y positions, zoom, panning) are compiled into a serialized JSON timeline file for synchronized, threaded playback.]",Đạt Trần Tiến (Daves Tran)
+User Interface / Push Notifications,ULTS-User Interface / Push Notifications-FR-11,DISPLAY progressive disclosure sheets and native alerts,No,UP7,System,[A case update occurs or the clinician interacts with the clinical data layout over the active DICOM canvas.],"[A deep-linked native OS push alert is sent, and clinical telemetry is confined within a 3-state (25%, 60%, 100%) expandable native Bottom-Sheet component.]","ULTS-User Interface / Push Notifications-FR-11: As an [Rheumatologist & Orthopedic Surgeon], provide that [A case update occurs or the clinician interacts with the clinical data layout over the active DICOM canvas.], the [System] shall DISPLAY progressive disclosure sheets and native alerts, ensuring that [A deep-linked native OS push alert is sent, and clinical telemetry is confined within a 3-state (25%, 60%, 100%) expandable native Bottom-Sheet component.]",Đạt Trần Tiến (Daves Tran)
+Gửi dữ liệu tự kiểm tra mức độ viêm tại nhà về hệ thống của bệnh viện.,ULTS-Gửi dữ liệu tự kiểm tra mức độ viêm tại nhà về hệ thống của bệnh viện.-FR-20,KẾT NỐI và GỬI Báo cáo Tự kiểm tra cho Bác sĩ Điều trị,No,UP8,System,Bệnh nhân vừa hoàn thành bài tự kiểm tra mức độ viêm (REQ-PAT-03) và phát hiện có dấu hiệu bất thường (đau tăng lên).,"Hệ thống đóng gói lịch sử triệu chứng kèm biểu đồ xu hướng gần nhất, gửi an toàn qua kênh mã hóa tới bác sĩ quản lý ca bệnh để bác sĩ có thể chủ động hẹn lịch tái khám sớm.","ULTS-Gửi dữ liệu tự kiểm tra mức độ viêm tại nhà về hệ thống của bệnh viện.-FR-20: As an [MSK Patient & Family Caregiver], provide that Bệnh nhân vừa hoàn thành bài tự kiểm tra mức độ viêm (REQ-PAT-03) và phát hiện có dấu hiệu bất thường (đau tăng lên)., the [System] shall KẾT NỐI và GỬI Báo cáo Tự kiểm tra cho Bác sĩ Điều trị, ensuring that Hệ thống đóng gói lịch sử triệu chứng kèm biểu đồ xu hướng gần nhất, gửi an toàn qua kênh mã hóa tới bác sĩ quản lý ca bệnh để bác sĩ có thể chủ động hẹn lịch tái khám sớm.",tahuykl
+Nhắc nhở uống thuốc và thực hiện phác đồ điều trị tại nhà.,ULTS-Nhắc nhở uống thuốc và thực hiện phác đồ điều trị tại nhà.-FR-19,GIÁM SÁT việc bệnh nhân tuân thủ Đơn thuốc và Nhắc nhở Lịch Điều trị,No,UP8,System,Bác sĩ đã kê đơn thuốc (REQ-RAD-05) và phác đồ điều trị được đồng bộ sang tài khoản của bệnh nhân.,"Ứng dụng tự động phát thông báo nhắc nhở giờ uống thuốc, giờ tập vật lý trị liệu cho Bệnh nhân và Người chăm sóc, đồng thời cho phép tích chọn ""Đã uống"" để lưu lại lịch sử tuân thủ điều trị.","ULTS-Nhắc nhở uống thuốc và thực hiện phác đồ điều trị tại nhà.-FR-19: As an [MSK Patient & Family Caregiver], provide that Bác sĩ đã kê đơn thuốc (REQ-RAD-05) và phác đồ điều trị được đồng bộ sang tài khoản của bệnh nhân., the [System] shall GIÁM SÁT việc bệnh nhân tuân thủ Đơn thuốc và Nhắc nhở Lịch Điều trị, ensuring that Ứng dụng tự động phát thông báo nhắc nhở giờ uống thuốc, giờ tập vật lý trị liệu cho Bệnh nhân và Người chăm sóc, đồng thời cho phép tích chọn ""Đã uống"" để lưu lại lịch sử tuân thủ điều trị.",tahuykl
+Đánh giá nhanh nguy cơ viêm tái phát qua bảng câu hỏi triệu chứng,ULTS-Đánh giá nhanh nguy cơ viêm tái phát qua bảng câu hỏi triệu chứng-FR-18,SÀNG LỌC và TỰ KIỂM TRA dấu hiệu Viêm tại nhà,No,UP8,System,"Bệnh nhân đang ở nhà (ngoài bệnh viện) và truy cập vào mục ""Kiểm tra sức khỏe định kỳ"" trên ứng dụng.","Hệ thống hiển thị bảng khảo sát tương tác (độ sưng, độ nóng, mức độ đau khi co duỗi); dựa trên câu trả lời, hệ thống tính điểm và đưa ra cảnh báo mức độ viêm lâm sàng hiện tại (Ổn định / Cần theo dõi / Cần đi khám ngay).","ULTS-Đánh giá nhanh nguy cơ viêm tái phát qua bảng câu hỏi triệu chứng-FR-18: As an [MSK Patient & Family Caregiver], provide that Bệnh nhân đang ở nhà (ngoài bệnh viện) và truy cập vào mục ""Kiểm tra sức khỏe định kỳ"" trên ứng dụng., the [System] shall SÀNG LỌC và TỰ KIỂM TRA dấu hiệu Viêm tại nhà, ensuring that Hệ thống hiển thị bảng khảo sát tương tác (độ sưng, độ nóng, mức độ đau khi co duỗi); dựa trên câu trả lời, hệ thống tính điểm và đưa ra cảnh báo mức độ viêm lâm sàng hiện tại (Ổn định / Cần theo dõi / Cần đi khám ngay).",tahuykl
+Theo dõi và kiểm tra biến thiên mức độ viêm khớp gối qua các thời kỳ.,ULTS-Theo dõi và kiểm tra biến thiên mức độ viêm khớp gối qua các thời kỳ.-FR-17,KIỂM TRA mức độ viêm trực quan qua Biểu đồ Xu hướng,No,UP8,System,Hệ thống có dữ liệu lịch sử từ ít nhất một lần khám (REQ-PAT-01) trở lên.,"Hệ thống hiển thị một biểu đồ đường (Line chart) trực quan hóa mức độ viêm (từ Nhẹ đến Nặng) và độ dày màng hoạt dịch qua các lần khám, giúp người bệnh biết tình trạng viêm của mình đang thuyên giảm hay tăng lên.","ULTS-Theo dõi và kiểm tra biến thiên mức độ viêm khớp gối qua các thời kỳ.-FR-17: As an [MSK Patient & Family Caregiver], provide that Hệ thống có dữ liệu lịch sử từ ít nhất một lần khám (REQ-PAT-01) trở lên., the [System] shall KIỂM TRA mức độ viêm trực quan qua Biểu đồ Xu hướng, ensuring that Hệ thống hiển thị một biểu đồ đường (Line chart) trực quan hóa mức độ viêm (từ Nhẹ đến Nặng) và độ dày màng hoạt dịch qua các lần khám, giúp người bệnh biết tình trạng viêm của mình đang thuyên giảm hay tăng lên.",tahuykl
+Xem và tải về lịch sử các lần siêu âm và khám khớp gối,ULTS-Xem và tải về lịch sử các lần siêu âm và khám khớp gối-FR-16,TRA CỨU lịch sử khám bệnh và Siêu âm Toàn diện,No,UP8,System,Bệnh nhân hoặc Người chăm sóc đăng nhập thành công vào hệ thống bằng tài khoản định danh hợp lệ.,"Hệ thống hiển thị danh sách toàn bộ các mốc thời gian đã khám, cho phép người dùng bấm vào từng ngày để xem lại ảnh siêu âm, đơn thuốc, và các chỉ số đo đạc cũ.","ULTS-Xem và tải về lịch sử các lần siêu âm và khám khớp gối-FR-16: As an [MSK Patient & Family Caregiver], provide that Bệnh nhân hoặc Người chăm sóc đăng nhập thành công vào hệ thống bằng tài khoản định danh hợp lệ., the [System] shall TRA CỨU lịch sử khám bệnh và Siêu âm Toàn diện, ensuring that Hệ thống hiển thị danh sách toàn bộ các mốc thời gian đã khám, cho phép người dùng bấm vào từng ngày để xem lại ảnh siêu âm, đơn thuốc, và các chỉ số đo đạc cũ.",tahuykl
+Patient Education Module / 3D Visualization Engine,ULTS-Patient Education Module / 3D Visualization Engine-FR-12,SYNCHRONIZE hardware-adaptive musculoskeletal models,No,UP8,System,[The patient opens the 3D visualization view and the client-side feature detection script evaluates local GPU capabilities.],[Abstract 2D pathologies map to either a real-time WebGL 3D skeletal mesh (High-Spec) or a CPU-bound 36-frame 2D sprite-sheet turntable rendering at 10° increments (Low-Spec).],"ULTS-Patient Education Module / 3D Visualization Engine-FR-12: As an [MSK Patient & Family Caregiver], provide that [The patient opens the 3D visualization view and the client-side feature detection script evaluates local GPU capabilities.], the [System] shall SYNCHRONIZE hardware-adaptive musculoskeletal models, ensuring that [Abstract 2D pathologies map to either a real-time WebGL 3D skeletal mesh (High-Spec) or a CPU-bound 36-frame 2D sprite-sheet turntable rendering at 10° increments (Low-Spec).]",Đạt Trần Tiến (Daves Tran)
+Patient Portal / Security Module,ULTS-Patient Portal / Security Module-FR-13,ENCRYPT and deliver sanitized patient payloads,No,UP8,System,"[The patient provides explicit, native opt-in consent and scans the unique 14-day tokenized QR code or deep link.]","[The locally AES-256 encrypted, sanitized, and flattened locomotive health summary loads into an adaptive dashboard in ≤ 2.0 seconds.]","ULTS-Patient Portal / Security Module-FR-13: As an [MSK Patient & Family Caregiver], provide that [The patient provides explicit, native opt-in consent and scans the unique 14-day tokenized QR code or deep link.], the [System] shall ENCRYPT and deliver sanitized patient payloads, ensuring that [The locally AES-256 encrypted, sanitized, and flattened locomotive health summary loads into an adaptive dashboard in ≤ 2.0 seconds.]",Đạt Trần Tiến (Daves Tran)
+Đề xuất danh mục thuốc kháng viêm và giảm đau theo ca bệnh,ULTS-Đề xuất danh mục thuốc kháng viêm và giảm đau theo ca bệnh-FR-27,ĐỀ XUẤT Đơn thuốc Hỗ trợ (Clinical Decision Support),No,UP5,System,"Chẩn đoán mức độ viêm đã có và bác sĩ lựa chọn phương án ""Điều trị nội khoa bằng thuốc"" (REQ-RAD-04)","Hệ thống đưa ra danh sách các loại thuốc phù hợp (ví dụ: NSAIDs, Thuốc chống bôi trơn khớp) kèm liều lượng khuyến cáo dựa trên mức độ viêm, kiểm tra tương tác thuốc/chống chỉ định, hỗ trợ bác sĩ xuất đơn thuốc nhanh chóng","ULTS-Đề xuất danh mục thuốc kháng viêm và giảm đau theo ca bệnh-FR-27: As an [Diagnostic Radiologist], provide that Chẩn đoán mức độ viêm đã có và bác sĩ lựa chọn phương án ""Điều trị nội khoa bằng thuốc"" (REQ-RAD-04), the [System] shall ĐỀ XUẤT Đơn thuốc Hỗ trợ (Clinical Decision Support), ensuring that Hệ thống đưa ra danh sách các loại thuốc phù hợp (ví dụ: NSAIDs, Thuốc chống bôi trơn khớp) kèm liều lượng khuyến cáo dựa trên mức độ viêm, kiểm tra tương tác thuốc/chống chỉ định, hỗ trợ bác sĩ xuất đơn thuốc nhanh chóng",tahuykl
+Gợi ý phương án điều trị dựa trên mức độ viêm khớp gối,ULTS-Gợi ý phương án điều trị dựa trên mức độ viêm khớp gối-FR-26,ĐỀ XUẤT Phác đồ Điều trị và Kế hoạch Can thiệp,No,UP5,System,Bác sĩ đã phê duyệt và khóa kết quả chẩn đoán mức độ viêm,"Hệ thống hiển thị các gợi ý điều trị tương ứng (ví dụ: Viêm nhẹ, tiến hành Vật lý trị liệu/Nghỉ ngơi; Viêm nặng tiến hành Chọc hút dịch khớp dưới hướng dẫn siêu âm/Tiêm corticoid nội khớp) để bác sĩ lựa chọn và đưa vào báo cáo.","ULTS-Gợi ý phương án điều trị dựa trên mức độ viêm khớp gối-FR-26: As an [Diagnostic Radiologist], provide that Bác sĩ đã phê duyệt và khóa kết quả chẩn đoán mức độ viêm, the [System] shall ĐỀ XUẤT Phác đồ Điều trị và Kế hoạch Can thiệp, ensuring that Hệ thống hiển thị các gợi ý điều trị tương ứng (ví dụ: Viêm nhẹ, tiến hành Vật lý trị liệu/Nghỉ ngơi; Viêm nặng tiến hành Chọc hút dịch khớp dưới hướng dẫn siêu âm/Tiêm corticoid nội khớp) để bác sĩ lựa chọn và đưa vào báo cáo.",tahuykl
+Đánh giá và phân cấp mức độ viêm màng hoạt dịch (Synovitis Grading),ULTS-Đánh giá và phân cấp mức độ viêm màng hoạt dịch (Synovitis Grading)-FR-25,CHUẨN ĐOÁN Phân loại Mức độ Viêm Khớp gối,No,UP5,System,Hệ thống đã ghi nhận độ dày màng hoạt dịch (REQ-RAD-02) và kết quả quét Doppler dòng máu (Hypervascularity),"Hệ thống đưa ra gợi ý chẩn đoán mức độ viêm theo thang chuẩn y khoa (ví dụ: Không viêm, Viêm nhẹ - Độ 1, Viêm vừa - Độ 2, Viêm nặng - Độ 3) để bác sĩ xác nhận hoặc điều chỉnh","ULTS-Đánh giá và phân cấp mức độ viêm màng hoạt dịch (Synovitis Grading)-FR-25: As an [Diagnostic Radiologist], provide that Hệ thống đã ghi nhận độ dày màng hoạt dịch (REQ-RAD-02) và kết quả quét Doppler dòng máu (Hypervascularity), the [System] shall CHUẨN ĐOÁN Phân loại Mức độ Viêm Khớp gối, ensuring that Hệ thống đưa ra gợi ý chẩn đoán mức độ viêm theo thang chuẩn y khoa (ví dụ: Không viêm, Viêm nhẹ - Độ 1, Viêm vừa - Độ 2, Viêm nặng - Độ 3) để bác sĩ xác nhận hoặc điều chỉnh",tahuykl
+Đo độ dày màng hoạt dịch tại ngách trên xương bánh chè,ULTS-Đo độ dày màng hoạt dịch tại ngách trên xương bánh chè-FR-24,ĐO Độ dày Màng hoạt dịch Tự động,No,UP5,System,Tính năng phân vùng (REQ-RAD-01) đã xác định được lớp màng hoạt dịch (Synovium) trên hình ảnh siêu âm,"Hệ thống tự động hiển thị thước đo (bằng milimet) tại điểm dày nhất của màng hoạt dịch, cho phép bác sĩ kéo thả điều chỉnh thủ công và lưu thông số này vào hồ sơ đo đạc của ca bệnh","ULTS-Đo độ dày màng hoạt dịch tại ngách trên xương bánh chè-FR-24: As an [Diagnostic Radiologist], provide that Tính năng phân vùng (REQ-RAD-01) đã xác định được lớp màng hoạt dịch (Synovium) trên hình ảnh siêu âm, the [System] shall ĐO Độ dày Màng hoạt dịch Tự động, ensuring that Hệ thống tự động hiển thị thước đo (bằng milimet) tại điểm dày nhất của màng hoạt dịch, cho phép bác sĩ kéo thả điều chỉnh thủ công và lưu thông số này vào hồ sơ đo đạc của ca bệnh",tahuykl
+Phân vùng hình ảnh cấu trúc giải phẫu khớp gối bằng AI,ULTS-Phân vùng hình ảnh cấu trúc giải phẫu khớp gối bằng AI-FR-23,PHÂN VÙNG Tự động các Bộ phận Khớp gối (Image Segmentation),No,UP5,System,Bác sĩ đã tải lên hoặc chụp thành công hình ảnh cắt dọc/cắt ngang của khớp gối trên hệ thống,"Hệ thống tự động nhận diện, phân vùng và tô màu phân biệt các bộ phận (gân bánh chè, sụn chêm, xương đùi, xương chày, màng hoạt dịch) trên màn hình mà không làm mờ ảnh gốc.","ULTS-Phân vùng hình ảnh cấu trúc giải phẫu khớp gối bằng AI-FR-23: As an [Diagnostic Radiologist], provide that Bác sĩ đã tải lên hoặc chụp thành công hình ảnh cắt dọc/cắt ngang của khớp gối trên hệ thống, the [System] shall PHÂN VÙNG Tự động các Bộ phận Khớp gối (Image Segmentation), ensuring that Hệ thống tự động nhận diện, phân vùng và tô màu phân biệt các bộ phận (gân bánh chè, sụn chêm, xương đùi, xương chày, màng hoạt dịch) trên màn hình mà không làm mờ ảnh gốc.",tahuykl

proj_level_reading/Requirement_Analysis/FRs-Database/FR_Engineer_DB_Mobile.csv

@@ -0,0 +1,15 @@
+ComponentName,Device,ReqID,ReqName,Priority,IsOptional,Drop,LinkUseCases,EngineerDesignUC,UserProfileCode,Sys/Act,PreCondition,PostCondition,VerboseDescription,Engineer
+Progress Tracking Module,Mobile Web,ULTS-Progress Tracking Module-FR-7,RECORD Asynchronous PT Progress Metrics,,No,No,,,UP6,System,[The physical therapist taps the screen workspace layer within the distinct Kinetic Tracking Channel.],"[Localized metrics including Range of Motion, 1-10 pain indices, and tissue behavior are serialized and pushed to the physician's tracking panel without mutating the primary medical file.]","ULTS-Progress Tracking Module-FR-7: As an [Physical Therapist], provide that [The physical therapist taps the screen workspace layer within the distinct Kinetic Tracking Channel.], the [System] shall RECORD Asynchronous PT Progress Metrics, ensuring that [Localized metrics including Range of Motion, 1-10 pain indices, and tissue behavior are serialized and pushed to the physician's tracking panel without mutating the primary medical file.]",Đạt Trần Tiến (Daves Tran)
+Patient Education Module,Mobile Web,ULTS-Patient Education Module-FR-8,DEMONSTRATE joint mechanics dynamically during physical therapy section,-1,No,No,,,UP6,System,[The physical therapist moves the HTML Range-of-Motion slider within the Patient Demonstration Mode split layout.],"[A cached array of 2D illustrations seamlessly cycles using 0% GPU power to visually indicate joint flexion, extension, and soft-tissue impingement.]","ULTS-Patient Education Module-FR-8: As an [Physical Therapist], provide that [The physical therapist moves the HTML Range-of-Motion slider within the Patient Demonstration Mode split layout.], the [System] shall DEMONSTRATE joint mechanics dynamically during physical therapy section, ensuring that [A cached array of 2D illustrations seamlessly cycles using 0% GPU power to visually indicate joint flexion, extension, and soft-tissue impingement.]",Đạt Trần Tiến (Daves Tran)
+Patient Education / Care Logic Module,Mobile Web,ULTS-Patient Education / Care Logic Module-FR-19,NHẮC NHỞ việc bệnh nhân tuân thủ Đơn thuốc và lịch Điều trị,,No,No,,tahuykl,UP8,System,Bác sĩ đã kê đơn thuốc (REQ-RAD-05) và phác đồ điều trị được đồng bộ sang tài khoản của bệnh nhân.,"Ứng dụng tự động phát thông báo nhắc nhở giờ uống thuốc, giờ tập vật lý trị liệu cho Bệnh nhân và Người chăm sóc, đồng thời cho phép tích chọn ""Đã uống"" để lưu lại lịch sử tuân thủ điều trị.","ULTS-Patient Education / Care Logic Module-FR-19: As an [MSK Patient & Family Caregiver], provide that Bác sĩ đã kê đơn thuốc (REQ-RAD-05) và phác đồ điều trị được đồng bộ sang tài khoản của bệnh nhân., the [System] shall NHẮC NHỞ việc bệnh nhân tuân thủ Đơn thuốc và lịch Điều trị, ensuring that Ứng dụng tự động phát thông báo nhắc nhở giờ uống thuốc, giờ tập vật lý trị liệu cho Bệnh nhân và Người chăm sóc, đồng thời cho phép tích chọn ""Đã uống"" để lưu lại lịch sử tuân thủ điều trị.",tahuykl
+Xem và tải về lịch sử các lần siêu âm và khám khớp gối,Mobile Web,ULTS-Xem và tải về lịch sử các lần siêu âm và khám khớp gối-FR-16,TRA CỨU lịch sử khám bệnh và Siêu âm Toàn diện,,No,No,,tahuykl,UP8,System,Bệnh nhân hoặc Người chăm sóc đăng nhập thành công vào hệ thống bằng tài khoản định danh hợp lệ.,"Hệ thống hiển thị danh sách toàn bộ các mốc thời gian đã khám, cho phép người dùng bấm vào từng ngày để xem lại ảnh siêu âm, đơn thuốc, và các chỉ số đo đạc cũ.","ULTS-Xem và tải về lịch sử các lần siêu âm và khám khớp gối-FR-16: As an [MSK Patient & Family Caregiver], provide that Bệnh nhân hoặc Người chăm sóc đăng nhập thành công vào hệ thống bằng tài khoản định danh hợp lệ., the [System] shall TRA CỨU lịch sử khám bệnh và Siêu âm Toàn diện, ensuring that Hệ thống hiển thị danh sách toàn bộ các mốc thời gian đã khám, cho phép người dùng bấm vào từng ngày để xem lại ảnh siêu âm, đơn thuốc, và các chỉ số đo đạc cũ.",tahuykl
+Tạo mới nhật ký chữa bệnh khớp gối cho bệnh nhân,Mobile Web,ULTS-Tạo mới nhật ký chữa bệnh khớp gối cho bệnh nhân-FR-28,CREATE patient treatment journal,,No,No,,tahuykl,UP8,System,Bệnh nhân hoặc Người chăm sóc đã đăng nhập thành công vào tài khoản hệ thống (ứng dụng di động hoặc cổng thông tin bệnh nhân) và hồ sơ bệnh án siêu âm khớp gối hiện tại đang ở trạng thái kích hoạt.,"Hệ thống khởi tạo thành công một biểu mẫu nhật ký mới gắn liền với đợt điều trị hiện tại, thiết lập sẵn các trường thông tin cần theo dõi (như mức độ đau, độ sưng gối, các triệu chứng bất thường, trạng thái dùng thuốc) và sẵn sàng cho lượt nhập liệu đầu tiên.","ULTS-Tạo mới nhật ký chữa bệnh khớp gối cho bệnh nhân-FR-28: As an [MSK Patient & Family Caregiver], provide that Bệnh nhân hoặc Người chăm sóc đã đăng nhập thành công vào tài khoản hệ thống (ứng dụng di động hoặc cổng thông tin bệnh nhân) và hồ sơ bệnh án siêu âm khớp gối hiện tại đang ở trạng thái kích hoạt., the [System] shall CREATE patient treatment journal, ensuring that Hệ thống khởi tạo thành công một biểu mẫu nhật ký mới gắn liền với đợt điều trị hiện tại, thiết lập sẵn các trường thông tin cần theo dõi (như mức độ đau, độ sưng gối, các triệu chứng bất thường, trạng thái dùng thuốc) và sẵn sàng cho lượt nhập liệu đầu tiên.",Đạt Trần Tiến (Daves Tran)
+Cập nhật diễn biến triệu chứng và tiến trình điều trị vào nhật ký,Mobile Web,ULTS-Cập nhật diễn biến triệu chứng và tiến trình điều trị vào nhật ký-FR-29,UPDATE patient treatment journal,,No,No,,tahuykl,UP8,System,Nhật ký chữa bệnh đã được khởi tạo thành công và đang trong thời gian theo dõi điều trị,"Hệ thống ghi nhận và lưu trữ dòng thời gian các dữ liệu mới do người dùng nhập (ví dụ: mức độ đau giảm từ 7 xuống 4, gối bớt sưng sau khi chườm đá, đã uống thuốc đúng giờ); đồng thời tự động cập nhật các số liệu này lên biểu đồ xu hướng tiến triển của khớp gối","ULTS-Cập nhật diễn biến triệu chứng và tiến trình điều trị vào nhật ký-FR-29: As an [MSK Patient & Family Caregiver], provide that Nhật ký chữa bệnh đã được khởi tạo thành công và đang trong thời gian theo dõi điều trị, the [System] shall UPDATE patient treatment journal, ensuring that Hệ thống ghi nhận và lưu trữ dòng thời gian các dữ liệu mới do người dùng nhập (ví dụ: mức độ đau giảm từ 7 xuống 4, gối bớt sưng sau khi chườm đá, đã uống thuốc đúng giờ); đồng thời tự động cập nhật các số liệu này lên biểu đồ xu hướng tiến triển của khớp gối",Đạt Trần Tiến (Daves Tran)
+Gửi báo cáo nhật ký chữa bệnh khớp gối cho Bác sĩ Chẩn đoán Hình ảnh hoặc Bác sĩ Điều trị,Mobile Web,ULTS-Gửi báo cáo nhật ký chữa bệnh khớp gối cho Bác sĩ Chẩn đoán Hình ảnh hoặc Bác sĩ Điều trị-FR-30,SEND patient treatment journal toward Clinicians & PT,,No,No,Send Treatment Journal (https://app.notion.com/p/Send-Treatment-Journal-376f910aea75808492a9ff771d46d442?pvs=21),tahuykl,UP8,System,Nhật ký chữa bệnh đã có dữ liệu được cập nhật và hệ thống đã xác định được danh tính bác sĩ phụ trách ca bệnh của bệnh nhân,"Hệ thống đóng gói toàn bộ lịch sử dữ liệu nhật ký (dưới dạng biểu đồ và bảng tóm tắt triệu chứng), mã hóa bảo mật dữ liệu y tế và chuyển trực tiếp tới màn hình làm việc (Dashboard) của bác sĩ phụ trách, đồng thời phát thông báo xác nhận ""Gửi thành công"" cho bệnh nhân/người chăm sóc","ULTS-Gửi báo cáo nhật ký chữa bệnh khớp gối cho Bác sĩ Chẩn đoán Hình ảnh hoặc Bác sĩ Điều trị-FR-30: As an [MSK Patient & Family Caregiver], provide that Nhật ký chữa bệnh đã có dữ liệu được cập nhật và hệ thống đã xác định được danh tính bác sĩ phụ trách ca bệnh của bệnh nhân, the [System] shall SEND patient treatment journal toward Clinicians & PT, ensuring that Hệ thống đóng gói toàn bộ lịch sử dữ liệu nhật ký (dưới dạng biểu đồ và bảng tóm tắt triệu chứng), mã hóa bảo mật dữ liệu y tế và chuyển trực tiếp tới màn hình làm việc (Dashboard) của bác sĩ phụ trách, đồng thời phát thông báo xác nhận ""Gửi thành công"" cho bệnh nhân/người chăm sóc",Đạt Trần Tiến (Daves Tran)
+Gửi dữ liệu tự kiểm tra mức độ viêm tại nhà về hệ thống của bệnh viện,Mobile Web,ULTS-Gửi dữ liệu tự kiểm tra mức độ viêm tại nhà về hệ thống của bệnh viện-FR-20,KẾT NỐI và GỬI Báo cáo Nhật Ký Bệnh Lý cho Bác sĩ Điều trị & Physiotherpist,-1,No,No,,,UP8,System,Bệnh nhân vừa hoàn thành bài tự kiểm tra mức độ viêm (REQ-PAT-03) và phát hiện có dấu hiệu bất thường (đau tăng lên).,"Hệ thống đóng gói lịch sử triệu chứng kèm biểu đồ xu hướng gần nhất, gửi an toàn qua kênh mã hóa tới bác sĩ quản lý ca bệnh để bác sĩ có thể chủ động hẹn lịch tái khám sớm.","ULTS-Gửi dữ liệu tự kiểm tra mức độ viêm tại nhà về hệ thống của bệnh viện-FR-20: As an [MSK Patient & Family Caregiver], provide that Bệnh nhân vừa hoàn thành bài tự kiểm tra mức độ viêm (REQ-PAT-03) và phát hiện có dấu hiệu bất thường (đau tăng lên)., the [System] shall KẾT NỐI và GỬI Báo cáo Nhật Ký Bệnh Lý cho Bác sĩ Điều trị & Physiotherpist, ensuring that Hệ thống đóng gói lịch sử triệu chứng kèm biểu đồ xu hướng gần nhất, gửi an toàn qua kênh mã hóa tới bác sĩ quản lý ca bệnh để bác sĩ có thể chủ động hẹn lịch tái khám sớm.",tahuykl
+Patient Education Module / 3D Visualization Engine,Mobile Web,ULTS-Patient Education Module / 3D Visualization Engine-FR-12,SYNCHRONIZE hardware-adaptive musculoskeletal models for visualizing MSK-condition after each visiting,-1,No,No,,,UP8,System,[The patient opens the 3D visualization view and the client-side feature detection script evaluates local GPU capabilities.],[Abstract 2D pathologies map to either a real-time WebGL 3D skeletal mesh (High-Spec) or a CPU-bound 36-frame 2D sprite-sheet turntable rendering at 10° increments (Low-Spec).],"ULTS-Patient Education Module / 3D Visualization Engine-FR-12: As an [MSK Patient & Family Caregiver], provide that [The patient opens the 3D visualization view and the client-side feature detection script evaluates local GPU capabilities.], the [System] shall SYNCHRONIZE hardware-adaptive musculoskeletal models for visualizing MSK-condition after each visiting, ensuring that [Abstract 2D pathologies map to either a real-time WebGL 3D skeletal mesh (High-Spec) or a CPU-bound 36-frame 2D sprite-sheet turntable rendering at 10° increments (Low-Spec).]",Đạt Trần Tiến (Daves Tran)
+Patient Portal / Security Module,Mobile Web,ULTS-Patient Portal / Security Module-FR-13,ENCRYPT and deliver sanitized patient payloads,-1,No,No,,,UP8,System,"[The patient provides explicit, native opt-in consent and scans the unique 14-day tokenized QR code or deep link.]","[The locally AES-256 encrypted, sanitized, and flattened locomotive health summary loads into an adaptive dashboard in ≤ 2.0 seconds.]","ULTS-Patient Portal / Security Module-FR-13: As an [MSK Patient & Family Caregiver], provide that [The patient provides explicit, native opt-in consent and scans the unique 14-day tokenized QR code or deep link.], the [System] shall ENCRYPT and deliver sanitized patient payloads, ensuring that [The locally AES-256 encrypted, sanitized, and flattened locomotive health summary loads into an adaptive dashboard in ≤ 2.0 seconds.]",Đạt Trần Tiến (Daves Tran)
+Patient Education Module / Personalized - Controlled Q&A,Mobile Web,ULTS-Patient Education Module / Personalized - Controlled Q&A-FR-31,INTERPRET diagnostic report profile from Clinic to Patient,,No,No,,,UP8,System,[Clinician has set the diagnostic report status to FINALIZED and a diagnosis code exists],"[A plain-language summary explaining the diagnosis (include terminology, why the patient should care and concern, the impact-to-patient analysis) is available on the patient's dashboard]","ULTS-Patient Education Module / Personalized - Controlled Q&A-FR-31: As an [MSK Patient & Family Caregiver], provide that [Clinician has set the diagnostic report status to FINALIZED and a diagnosis code exists], the [System] shall INTERPRET diagnostic report profile from Clinic to Patient, ensuring that [A plain-language summary explaining the diagnosis (include terminology, why the patient should care and concern, the impact-to-patient analysis) is available on the patient's dashboard]",Đạt Trần Tiến (Daves Tran)
+Patient Education / Care Logic Module,Mobile Web,ULTS-Patient Education / Care Logic Module-FR-32,GUIDE lifestyle via personalized recovery tasks,,No,No,,,UP8,System,[Clinician has finalized the daily grade (0-3) in the medical record],"[The patient receives an updated, conversational, and actionable daily checklist]","ULTS-Patient Education / Care Logic Module-FR-32: As an [MSK Patient & Family Caregiver], provide that [Clinician has finalized the daily grade (0-3) in the medical record], the [System] shall GUIDE lifestyle via personalized recovery tasks, ensuring that [The patient receives an updated, conversational, and actionable daily checklist]",Đạt Trần Tiến (Daves Tran)
+Patient Education Module / Personalized - Controlled Q&A,Mobile Web,ULTS-Patient Education Module / Personalized - Controlled Q&A-FR-33,TRIAGE patient-input queries against clinical status,,No,No,,,UP8,System,[Patient submits a health-related query via the Q&A interface while a clinical record exists],"[The query is tagged as Verified, Neutral, or Cautionary based on its relevance to the specific medical record]","ULTS-Patient Education Module / Personalized - Controlled Q&A-FR-33: As an [MSK Patient & Family Caregiver], provide that [Patient submits a health-related query via the Q&A interface while a clinical record exists], the [System] shall TRIAGE patient-input queries against clinical status, ensuring that [The query is tagged as Verified, Neutral, or Cautionary based on its relevance to the specific medical record]",Đạt Trần Tiến (Daves Tran)
+Đánh giá và phân cấp mức độ viêm màng hoạt dịch (Synovitis Grading),Mobile Web,ULTS-Đánh giá và phân cấp mức độ viêm màng hoạt dịch (Synovitis Grading)-FR-25,CHUẨN ĐOÁN Phân loại Mức độ Viêm Khớp gối,,Yes,No,"Load Patient Scan Session (https://app.notion.com/p/Load-Patient-Scan-Session-376f910aea75807586e9e64a7883c7b6?pvs=21), Review Suggested Synovitis Grade (0-3) (https://app.notion.com/p/Review-Suggested-Synovitis-Grade-0-3-378f910aea75802492c7d60b707b988e?pvs=21), Finalize & Sign Electronic Record (https://app.notion.com/p/Finalize-Sign-Electronic-Record-378f910aea758088b010f6f1c52c006d?pvs=21), Generate GradCAM & CoT Explanation Panel (https://app.notion.com/p/Generate-GradCAM-CoT-Explanation-Panel-378f910aea7580cdb530f06312577e6f?pvs=21), Log High-Trust Concur Block (https://app.notion.com/p/Log-High-Trust-Concur-Block-378f910aea7580baa4aace53fe624e23?pvs=21), Trigger Conversational Circuit Breaker (https://app.notion.com/p/Trigger-Conversational-Circuit-Breaker-378f910aea7580b2949be22396e2e159?pvs=21), Facilitate Socratic Reasoning Dialogue (https://app.notion.com/p/Facilitate-Socratic-Reasoning-Dialogue-378f910aea7580ee9d93d1988a1e5146?pvs=21), Monitor Context Drift via BERT Sub-Layer (https://app.notion.com/p/Monitor-Context-Drift-via-BERT-Sub-Layer-378f910aea7580c5b69bcad54c8fe21c?pvs=21), Arbitrate Evidence via RAG-Referee (https://app.notion.com/p/Arbitrate-Evidence-via-RAG-Referee-378f910aea75805b83dadeb609585473?pvs=21), Expose Pixel-Level Activation Logic (https://app.notion.com/p/Expose-Pixel-Level-Activation-Logic-378f910aea7580a49250ee97e865637c?pvs=21), Isolate Visual Noise/Artifacts (https://app.notion.com/p/Isolate-Visual-Noise-Artifacts-378f910aea7580898125d5a2d073c9db?pvs=21), Commit Validated Ground-Truth Record (https://app.notion.com/p/Commit-Validated-Ground-Truth-Record-378f910aea7580f6853bc7427402864f?pvs=21), Activate Clinical Investigation Mode (https://app.notion.com/p/Activate-Clinical-Investigation-Mode-378f910aea758059ab78df2595b9f5f6?pvs=21), Execute Structured Morphology Annotation (https://app.notion.com/p/Execute-Structured-Morphology-Annotation-378f910aea758013b687d8272c7be796?pvs=21), Serialize Session to Telemetry Queue (https://app.notion.com/p/Serialize-Session-to-Telemetry-Queue-378f910aea75808dbeeddaaa8ae1580f?pvs=21)",Đạt Trần Tiến (Daves Tran),UP5,System,Hệ thống đã ghi nhận độ dày màng hoạt dịch (REQ-RAD-02) và kết quả quét Doppler dòng máu (Hypervascularity),"Hệ thống đưa ra gợi ý chẩn đoán mức độ viêm theo thang chuẩn y khoa (ví dụ: Không viêm, Viêm nhẹ - Độ 1, Viêm vừa - Độ 2, Viêm nặng - Độ 3) để bác sĩ xác nhận hoặc điều chỉnh","ULTS-Đánh giá và phân cấp mức độ viêm màng hoạt dịch (Synovitis Grading)-FR-25: As an [Diagnostic Radiologist], provide that Hệ thống đã ghi nhận độ dày màng hoạt dịch (REQ-RAD-02) và kết quả quét Doppler dòng máu (Hypervascularity), the [System] should CHUẨN ĐOÁN Phân loại Mức độ Viêm Khớp gối, ensuring that Hệ thống đưa ra gợi ý chẩn đoán mức độ viêm theo thang chuẩn y khoa (ví dụ: Không viêm, Viêm nhẹ - Độ 1, Viêm vừa - Độ 2, Viêm nặng - Độ 3) để bác sĩ xác nhận hoặc điều chỉnh",tahuykl

proj_level_reading/Requirement_Analysis/Non-FRS-DB/Non-Functional (NFR) List Result/Non-FR Engineering Result 376f910aea7580c3ae9afed6937701fd_all.csv

@@ -0,0 +1,184 @@
+ReqName,ComponentName,Created time,Engineer,ID,NotViloate,Project Prefix,Rationale,ReqCategory,ReqID,TargetSpec,UserProfileCode,Validation,VerboseDescription
+DICOM Collaborative Rendering Speed,PR,"June 5, 2026 10:41 AM",Đạt Trần Tiến (Daves Tran),NFR-1,The user/event response time for transforming a standard DICOM X-ray into a shared collaborative canvas with ML diagnostic overlays SHALL NOT exceed 3.0 seconds.,ULTS,prevention losing the trust and adoption of fast-paced Professional Clinicians (UP2) operating under intense multitasking and heavy ward volumes.,Efficiency (Speed & Space),ULTS-PR-NFR-1,"Optimize the interactive workspace canvas performance during the ingestion and
+rendering of medical image assets.",UP2,"Deploy network throttling profiles (clamped at exactly 10 Mbps) on a test client terminal. Trigger 100 consecutive DICOM collaborative canvas initializations.
+Measure end-to-end latency via automated browser performance scripts.
+SUCCESS CRITERIA: 100% of test runs must clock an event duration ≤ 3000ms.","📌 As a result of prevention losing the trust and adoption of fast-paced Professional Clinicians (UP2) operating under intense multitasking and heavy ward volumes., 
+⚙️ The system must satisfy: Optimize the interactive workspace canvas performance during the ingestion and
+rendering of medical image assets., 
+🛑 And it shall not violate: The user/event response time for transforming a standard DICOM X-ray into a shared collaborative canvas with ML diagnostic overlays SHALL NOT exceed 3.0 seconds.."
+Client Memory Footprint & Constraints,PR,"June 5, 2026 11:13 AM",Đạt Trần Tiến (Daves Tran),NFR-4,The active client application memory allocation SHALL NOT exceed 150 Mbytes of RAM during an ongoing multi-user collaborative review session. Additionally the program have to run on client hardware devices with baseline configurations down to 3GB total RAM.,ULTS,"Practitioners (UP3) operate in resource-constrained provincial and commune
+clinics using legacy mobile and tablet form-factors with limited system memory.",Efficiency (Speed & Space),ULTS-PR-NFR-4,Constrain the runtime store occupancy of the active browser application workspace.,UP3,"Connect a low-end test tablet to Chrome DevTools Memory Profiler. Initialize a 4-user
+shared collaborative workshop session. Simulate continuous annotation changes for
+30 minutes.
+SUCCESS CRITERIA: Peak heap memory allocation logged in heap snapshots must stay strictly below 150MB, with 0 instances of OS-level browser crashes.","📌 As a result of Practitioners (UP3) operate in resource-constrained provincial and commune
+clinics using legacy mobile and tablet form-factors with limited system memory., 
+⚙️ The system must satisfy: Constrain the runtime store occupancy of the active browser application workspace., 
+🛑 And it shall not violate: The active client application memory allocation SHALL NOT exceed 150 Mbytes of RAM during an ongoing multi-user collaborative review session. Additionally the program have to run on client hardware devices with baseline configurations down to 3GB total RAM.."
+Core Vision Inference Latency Limit,PR,"June 5, 2026 11:16 AM",Đạt Trần Tiến (Daves Tran),NFR-5,The processing time for raw DICOM matrix parsing and diagnostic bounding-box generation SHALL NOT exceed 1.5 seconds. Additionally the computation must be calculated locally on the designated on-premise local server configuration node.,ULTS,"prevention local compute bottlenecks from pushing the overall collaborative
+workspace sync execution beyond the critical user threshold.",Efficiency (Speed & Space),ULTS-PR-NFR-5,The local computer vision model must complete image processing rapidly on the edge tier.,UP2,"Inject a test batch of 500 un-analyzed musculoskeletal DICOM files into the
+local image processing queue. Read backend server performance tracing timestamps.
+SUCCESS CRITERIA: Arithmetic mean of inference execution time must be ≤ 1500ms,
+with a maximum upper bound outlier limit of 1800ms.","📌 As a result of prevention local compute bottlenecks from pushing the overall collaborative
+workspace sync execution beyond the critical user threshold., 
+⚙️ The system must satisfy: The local computer vision model must complete image processing rapidly on the edge tier., 
+🛑 And it shall not violate: The processing time for raw DICOM matrix parsing and diagnostic bounding-box generation SHALL NOT exceed 1.5 seconds. Additionally the computation must be calculated locally on the designated on-premise local server configuration node.."
+Server-Side Edge Model Quantization,PR,"June 5, 2026 11:20 AM",Đạt Trần Tiến (Daves Tran),NFR-6,"The active memory allocation of the deployed models SHALL NOT require more than
+2 GB of VRAM on the target server nodes, and the system shall have to execute on local server nodes or specialized on-premise clinical workstations.",ULTS,"prevention hardware resource exhaustion on local public hospital servers and keep
+deployment costs sustainable for district clinics.",Efficiency (Speed & Space),ULTS-PR-NFR-6,Apply optimization protocols to the deployed musculoskeletal computer vision models.,UP2,"Boot up the localized AI model server container cluster. Query GPU hardware parameters via
+system telemetry CLI commands (e.g., nvidia-smi) during peak load tasks.
+SUCCESS CRITERIA: System-reported dedicated VRAM consumption per inference runner
+must remain under 2.0 GB.","📌 As a result of prevention hardware resource exhaustion on local public hospital servers and keep
+deployment costs sustainable for district clinics., 
+⚙️ The system must satisfy: Apply optimization protocols to the deployed musculoskeletal computer vision models., 
+🛑 And it shall not violate: The active memory allocation of the deployed models SHALL NOT require more than
+2 GB of VRAM on the target server nodes, and the system shall have to execute on local server nodes or specialized on-premise clinical workstations.."
+Real-Time UI Screen Refresh (Token Streaming),PR,"June 5, 2026 11:24 AM",Đạt Trần Tiến (Daves Tran),NFR-7,The initial UI screen refresh response time for text generation SHALL NOT be greater than 200 milliseconds from the moment inference begins. Also the system SHALL be able to rendered within standard browsers on legacy field-deployed budget tablets.,ULTS,"the acomodation of low-performance client screens and prevent UI freezing while
+Practitioners (UP3) manage heavy, fast-moving clinical queues.",Efficiency (Speed & Space),ULTS-PR-NFR-7,Utilize a server-side processing architecture that pushes model text outputs as an asynchronous data stream.,UP3,"Trigger 50 distinct patient summary generation prompts on a legacy tablet.
+Capture screen-to-render timelines using programmatic UI tracing (Time to First Token).
+SUCCESS CRITERIA: The duration between user request submit and the rendering of
+the first character on-screen must be ≤ 200ms in 100% of test cycles.","📌 As a result of the acomodation of low-performance client screens and prevent UI freezing while
+Practitioners (UP3) manage heavy, fast-moving clinical queues., 
+⚙️ The system must satisfy: Utilize a server-side processing architecture that pushes model text outputs as an asynchronous data stream., 
+🛑 And it shall not violate: The initial UI screen refresh response time for text generation SHALL NOT be greater than 200 milliseconds from the moment inference begins. Also the system SHALL be able to rendered within standard browsers on legacy field-deployed budget tablets.."
+Local Network Fault Tolerance (Robustness),PR,"June 5, 2026 11:27 AM",Đạt Trần Tiến (Daves Tran),NFR-8,"The objective probability of data corruption upon unexpected local connection failure
+SHALL BE EXACTLY 0%, additional the system shall be able to Active / Remember the user-request during unexpected mid-session Wi-Fi disconnections or data link failures.",ULTS,"Rural district and commune-level healthcare nodes suffer from highly unstable
+local network connectivity and frequent local Wi-Fi dropouts.",Dependability & Robustness,ULTS-PR-NFR-8,Integrate automated client-side data caching layers and silent background sync pipelines.,UNK,"Open an active collaborative review session on a client device. While drawing
+canvas annotations, disconnect the clinic's local network router. Continue drawing 5 additions.
+Restore router power after 60 seconds. Inspect the central database state.
+SUCCESS CRITERIA: 0% data structural loss or canvas layer corruption. All offline edits
+must synchronize seamlessly to the local server within 2.0 seconds of reconnection.","📌 As a result of Rural district and commune-level healthcare nodes suffer from highly unstable
+local network connectivity and frequent local Wi-Fi dropouts., 
+⚙️ The system must satisfy: Integrate automated client-side data caching layers and silent background sync pipelines., 
+🛑 And it shall not violate: The objective probability of data corruption upon unexpected local connection failure
+SHALL BE EXACTLY 0%, additional the system shall be able to Active / Remember the user-request during unexpected mid-session Wi-Fi disconnections or data link failures.."
+Localized System Availability Matrix,PR,"June 5, 2026 11:30 AM",Đạt Trần Tiến (Daves Tran),NFR-9,"Local system availability SHALL NOT fall below a rate of 99.9% during official public
+sector operating windows. Unexpected system downtime SHALL NOT exceed 45 seconds in any single day. Given the context that Mon–Fri, 07:00–16:30 (including lunch service from 11:30–13:30); selected evening windows
+(17:00–20:00); continuous 24/7 coverage for emergency room department instances.",ULTS,"the condition that system must remain constantly online during standard and extended operating blocks
+to prevent administrative blockages in crowded public patient queues.",Dependability & Robustness,ULTS-PR-NFR-9,"Ensure reliable, continuous local cluster operations without service interruptions.",UNK,"Review availability tracking logs generated by automated site reliability tools
+(e.g., Prometheus/Grafana) continuously across a 30-day monitoring trial.
+SUCCESS CRITERIA: Uptime logs must confirm ≤ 99.9% availability across all
+designated operational shift blocks, with no un-escalated crashes exceeding 45 seconds.","📌 As a result of the condition that system must remain constantly online during standard and extended operating blocks
+to prevent administrative blockages in crowded public patient queues., 
+⚙️ The system must satisfy: Ensure reliable, continuous local cluster operations without service interruptions., 
+🛑 And it shall not violate: Local system availability SHALL NOT fall below a rate of 99.9% during official public
+sector operating windows. Unexpected system downtime SHALL NOT exceed 45 seconds in any single day. Given the context that Mon–Fri, 07:00–16:30 (including lunch service from 11:30–13:30); selected evening windows
+(17:00–20:00); continuous 24/7 coverage for emergency room department instances.."
+Automated Generative Safety Guardrails,PR,"June 5, 2026 11:33 AM",Đạt Trần Tiến (Daves Tran),NFR-10,"Less than 90% verification processing is prohibited (on these metric: Faithfulness / Groundedness Score, Policy Compliance Rate, Jailbreak/Toxicity Detection Rate, and Latency & Token Usage) ; 100% of LLM-generated patient text
+explanations SHALL pass verification before rendering on the client interface.",ULTS,"the constrain that system have to safely insulate Support Staff & Patients (UP4) from unverified text outputs,
+translation errors, or inappropriate medical claims.",Dependability & Robustness,ULTS-PR-NFR-10,"Intercept raw model generation streams with an automated verification layer
+(e.g., NVIDIA NeMo Guardrails or Llama Guard).  This constrain have to apply to all outward-facing user communications and text interfaces. ",UP4,"Inject a test suite containing 200 adversarial prompts designed to trigger unsafe medical
+claims or guideline deviations. Analyze the resulting UI delivery logs.
+SUCCESS CRITERIA: The system must successfully catch, block, or rewrite 100% of the
+violating outputs, displaying a safe fallback notification instead.","📌 As a result of the constrain that system have to safely insulate Support Staff & Patients (UP4) from unverified text outputs,
+translation errors, or inappropriate medical claims., 
+⚙️ The system must satisfy: Intercept raw model generation streams with an automated verification layer
+(e.g., NVIDIA NeMo Guardrails or Llama Guard).  This constrain have to apply to all outward-facing user communications and text interfaces. , 
+🛑 And it shall not violate: Less than 90% verification processing is prohibited (on these metric: Faithfulness / Groundedness Score, Policy Compliance Rate, Jailbreak/Toxicity Detection Rate, and Latency & Token Usage) ; 100% of LLM-generated patient text
+explanations SHALL pass verification before rendering on the client interface.."
+Frontline Usability & Training Curve,PR,"June 5, 2026 11:42 AM",Đạt Trần Tiến (Daves Tran),NFR-11,"The required onboarding training window to achieve independent user proficiency SHALL NOT
+exceed 45 minutes. The subsequent average error rate SHALL NOT exceed 1 configuration slip per week.",ULTS,"Frontline Practitioners and Support Staff, and Patient exhibit low digital confidence and face severe
+daily time constraints, making them resistant to tools that require complex setups.",Usability (Ease of Use),ULTS-PR-NFR-11,"Simplify user interaction flows for core workflows (patient registration, queue routing,
+and media casting).","UP2, UP3, UP4","Run a validation test with 30 target users (Profiles 3 & 4). Provide a standard 45-minute
+instructional session. Task users with processing a mock 10-patient throughput queue. Log
+operational missteps over their first week of live work. Also ones have to run the evaluation on frontline staff with typical vocational/basic/ entry-level healthcare backgrounds.
+SUCCESS CRITERIA: 90% or more of participants must pass the initial throughput test
+independently, with a tracked post-onboarding error rate ≤ 1 configuration slip per week.  - ","📌 As a result of Frontline Practitioners and Support Staff, and Patient exhibit low digital confidence and face severe
+daily time constraints, making them resistant to tools that require complex setups., 
+⚙️ The system must satisfy: Simplify user interaction flows for core workflows (patient registration, queue routing,
+and media casting)., 
+🛑 And it shall not violate: The required onboarding training window to achieve independent user proficiency SHALL NOT
+exceed 45 minutes. The subsequent average error rate SHALL NOT exceed 1 configuration slip per week.."
+Zero-Friction Explainability Integration,ORG,"June 5, 2026 11:58 AM",Đạt Trần Tiến (Daves Tran),NFR-12,"Accessing baseline model confidence intervals or guideline justifications SHALL require
+EXACTLY 0 extra user clicks or separate modal pop-up windows. - and the model’s result have to displayed inside the primary medical viewport layout used during image interpretation.",ULTS,"Senior Experts (UP1) & professional-clinicians have an exceptionally low tolerance for workflow friction and
+remain highly skeptical of opaque, un-verifiable ""black-box"" systems.",Operational Process,ULTS-ORG-NFR-12,"Display automated safety checks, objective alerts, and validation states cleanly within
+the specialist's primary visual focus field.","UP1, UP2","Open a clinical record entry as a UP1 user. Use a UI click-tracking extension to log
+the step count required to read the model's confidence scores.
+SUCCESS CRITERIA: Information must render automatically alongside the image asset.
+The recorded click count to reveal basic explanation data must be exactly zero.","📌 As a result of Senior Experts (UP1) & professional-clinicians have an exceptionally low tolerance for workflow friction and
+remain highly skeptical of opaque, un-verifiable ""black-box"" systems., 
+⚙️ The system must satisfy: Display automated safety checks, objective alerts, and validation states cleanly within
+the specialist's primary visual focus field., 
+🛑 And it shall not violate: Accessing baseline model confidence intervals or guideline justifications SHALL require
+EXACTLY 0 extra user clicks or separate modal pop-up windows. - and the model’s result have to displayed inside the primary medical viewport layout used during image interpretation.."
+Spatial Layer-Activation Mapping (The Anti-Black-Box Mandate),ORG,"June 5, 2026 12:16 PM",Đạt Trần Tiến (Daves Tran),NFR-13,"The vision stack SHALL natively output spatial layer-activation maps (such as Grad-CAM overlays).
+Displaying these anatomical heatmaps upon selecting an identified finding SHALL require zero extra clicks, during all automated musculoskeletal pathology screening tasks.",ULTS,"establishing the immediate clinical trust and give Senior Experts & Professional Expert (UP2, UP1) clear, objective
+evidence to justify diagnosis choices and manage legal liabilities.","The ""Anti-Black-Box"" Mandate",ULTS-ORG-NFR-13,Expose the exact spatial foundations of the machine learning model's diagnostic conclusions.,"UP1, UP2","Process a standard diagnostic session. Select an automated finding label on the interface.
+Observe viewport updates.
+SUCCESS CRITERIA: The corresponding region of interest on the X-ray must instantly
+highlight its Grad-CAM layer activation overlay with zero intermediate user input.","📌 As a result of establishing the immediate clinical trust and give Senior Experts & Professional Expert (UP2, UP1) clear, objective
+evidence to justify diagnosis choices and manage legal liabilities., 
+⚙️ The system must satisfy: Expose the exact spatial foundations of the machine learning model's diagnostic conclusions., 
+🛑 And it shall not violate: The vision stack SHALL natively output spatial layer-activation maps (such as Grad-CAM overlays).
+Displaying these anatomical heatmaps upon selecting an identified finding SHALL require zero extra clicks, during all automated musculoskeletal pathology screening tasks.."
+Legacy Local Hardware Compatibility,ORG,"June 5, 2026 12:30 PM",Đạt Trần Tiến (Daves Tran),NFR-14,"The user interface modules SHALL NOT require a dedicated external client-side GPU or hardware
+neural accelerator. The system must operate seamlessly on tablet form-factors running
+Android 10+ with as little as 3GB of RAM. Also, the system shall be applicable to all field-deployed operational and patient-facing user portals.",ULTS,"Severe hardware shortages and legacy systems are common across rural district and commune clinics.
+",Environmental,ULTS-ORG-NFR-14,Ensure the user applications run smoothly on existing low-end client hardware assets.,UNK,"Install the client web application on an entry-level Android 10 test tablet (equipped with exactly
+3GB RAM and an integrated low-tier mobile processor). Run a complete end-to-end patient flow.
+SUCCESS CRITERIA: Frame rendering rates must stay ≤ 30 frames per second, with
+zero hardware-induced memory crashes or system hangs.","📌 As a result of Severe hardware shortages and legacy systems are common across rural district and commune clinics.
+, 
+⚙️ The system must satisfy: Ensure the user applications run smoothly on existing low-end client hardware assets., 
+🛑 And it shall not violate: The user interface modules SHALL NOT require a dedicated external client-side GPU or hardware
+neural accelerator. The system must operate seamlessly on tablet form-factors running
+Android 10+ with as little as 3GB of RAM. Also, the system shall be applicable to all field-deployed operational and patient-facing user portals.."
+National EMR Compliance (Circular 46/2018/TT-BYT),ER,"June 5, 2026 12:32 PM",Đạt Trần Tiến (Daves Tran),NFR-15,"Any data processing architecture that breaks the provisions of the Vietnamese Ministry
+of Health’s Circular 46/2018/TT-BYT governing electronic medical records is strictly prohibited. Additionally, the system have to governs all patient medical histories, clinical records, and diagnostic storage pipelines, and the hospital & the user shall own this.",ULTS,"addressing intense legal liability concerns raised by Senior Experts (UP1) and Clinical
+Directors regarding health data processing.",Legislative & Regulatory,ULTS-ER-NFR-15,"Build data security & data-minimization models, anonymization logic, and electronic transfer handoffs that conform to national laws.",UP1,"Submit the complete application architectural specification, encryption protocols, and data data
+handling designs to a certified medical compliance auditor or legal team.
+SUCCESS CRITERIA: Obtain a formal compliance sign-off confirming 100% alignment with
+Circular 46/2018/TT-BYT.","📌 As a result of addressing intense legal liability concerns raised by Senior Experts (UP1) and Clinical
+Directors regarding health data processing., 
+⚙️ The system must satisfy: Build data security & data-minimization models, anonymization logic, and electronic transfer handoffs that conform to national laws., 
+🛑 And it shall not violate: Any data processing architecture that breaks the provisions of the Vietnamese Ministry
+of Health’s Circular 46/2018/TT-BYT governing electronic medical records is strictly prohibited. Additionally, the system have to governs all patient medical histories, clinical records, and diagnostic storage pipelines, and the hospital & the user shall own this.."
+Local Intranet Cloud & Air-Gapped Data Isolation,ER,"June 5, 2026 12:35 PM",Đạt Trần Tiến (Daves Tran),NFR-16,"The platform tech stack (Llama-3, PhoGPT, or MedGemma) SHALL NOT transmit any diagnostic or
+identifiable clinical information across the public internet. External cloud processing (that outside Vietnam) is prohibited. Only execute & deployed on on-premise servers, local intranet infrastructures, or isolated specialist machines.",ULTS,"the Public health laws protection on medical data sovereignty, making it illegal to use public,
+commercial cloud AI APIs where patient data leaves the national borders.",Ethical & Safety,ULTS-ER-NFR-16,"Restrict the platform's execution, storage, and model evaluation environments to internal networks.",UNK,"Boot up the full platform cascade. Trigger active DICOM analysis and text generation tasks on a
+client machine. Run a network packet analyzer (e.g., Wireshark) on the outward-facing router port.
+SUCCESS CRITERIA: 100% of packets containing health or analysis records must resolve inside local
+IP ranges (LAN). Outbound public internet traffic matching these profiles must remain exactly zero.","📌 As a result of the Public health laws protection on medical data sovereignty, making it illegal to use public,
+commercial cloud AI APIs where patient data leaves the national borders., 
+⚙️ The system must satisfy: Restrict the platform's execution, storage, and model evaluation environments to internal networks., 
+🛑 And it shall not violate: The platform tech stack (Llama-3, PhoGPT, or MedGemma) SHALL NOT transmit any diagnostic or
+identifiable clinical information across the public internet. External cloud processing (that outside Vietnam) is prohibited. Only execute & deployed on on-premise servers, local intranet infrastructures, or isolated specialist machines.."
+Cryptographic Accountability Logging,ER,"June 5, 2026 12:37 PM",Đạt Trần Tiến (Daves Tran),NFR-17,"The application layer SHALL NOT allow any user, including database administrators, to alter or delete the logs. Every action where an AI recommendation is accepted or overridden must be saved immutably. - This constrain have to apply to all active clinical screening and diagnostic check workflows.",ULTS,"the need oreliable audit trails that help Professional Clinicians (UP2) justify their
+treatment paths upward and satisfy institutional safety standards.",Ethical & Safety,ULTS-ER-NFR-17,Maintain a highly secure ledger recording every clinical decision point that interacts with AI insights.,UP2,"Log into the system back-end using full database administrator (DBA) root privileges. Attempt to execute
+SQL UPDATE or DELETE commands directly on the clinical_decision_ledger table.
+SUCCESS CRITERIA: The database kernel must block the transaction with a fatal database permission
+error, proving Row-Level Security and append-only constraints are working.","📌 As a result of the need oreliable audit trails that help Professional Clinicians (UP2) justify their
+treatment paths upward and satisfy institutional safety standards., 
+⚙️ The system must satisfy: Maintain a highly secure ledger recording every clinical decision point that interacts with AI insights., 
+🛑 And it shall not violate: The application layer SHALL NOT allow any user, including database administrators, to alter or delete the logs. Every action where an AI recommendation is accepted or overridden must be saved immutably. - This constrain have to apply to all active clinical screening and diagnostic check workflows.."
+MOH Guideline-Anchored RAG Pipeline,ER,"June 5, 2026 12:39 PM",Đạt Trần Tiến (Daves Tran),NFR-18,"The system SHALL NOT render open-ended clinical text summaries that do not append a clear, traceable
+footnote citation referencing official Ministry of Health (MOH) medical protocols. - This constrain have to active across all patient education modules and text summary generators.",ULTS,"Large Language Models hallucination on factual errors, which could present dangerous or misleading
+medical claims to patients.",Ethical & Safety,ULTS-ER-NFR-18,"Restrict the model's educational text generation by using Retrieval-Augmented Generation (RAG)
+tied to official health guidelines.",UNK,"Run a suite of 100 patient information queries through the generation pipeline. Use semantic
+evaluation scripts to compare the output text strings against your verified guideline database.
+SUCCESS CRITERIA: 100% of the generated outputs must include a verifiable source footnote ID,
+showing an objective mathematical semantic alignment match (≤ 0.85 cosine similarity)
+with official MOH protocols.","📌 As a result of Large Language Models hallucination on factual errors, which could present dangerous or misleading
+medical claims to patients., 
+⚙️ The system must satisfy: Restrict the model's educational text generation by using Retrieval-Augmented Generation (RAG)
+tied to official health guidelines., 
+🛑 And it shall not violate: The system SHALL NOT render open-ended clinical text summaries that do not append a clear, traceable
+footnote citation referencing official Ministry of Health (MOH) medical protocols. - This constrain have to active across all patient education modules and text summary generators.."
+Human-in-the-Loop (HITL) Clinical Gatekeeping,ER,"June 5, 2026 12:40 PM",Đạt Trần Tiến (Daves Tran),NFR-19,"The database layer SHALL NOT allow any automated ML/LLM diagnosis asset or report
+to transition to a 'FINALIZED', 'ARCHIVED', or 'PATIENT_ACCESSIBLE' status code without an authenticating digital signature from a licensed human clinician.  The constrain shall apply to 100% of diagnostic sessions, triage check-sheets, and generated
+musculoskeletal patient-education outputs before saving.",ULTS,"the need of mitigating the medical liability, prevention the downstream propagation of AI
+hallucinations or edge-case diagnostic errors, and ensure that final clinical
+accountability rests solely with a licensed human medical practitioner.",Ethical & Safety,ULTS-ER-NFR-19,"Implement an architectural air-gap gatekeeper where no automated ML insights or
+generative patient summaries can be committed to the official Electronic Medical
+Record (EMR) or finalized for patient distribution without explicit human sign-off.",UNK,"Attempt to programmatically bypass the UI and send a raw API transaction to commit
+an automated MedGemma diagnostic report directly to the patient's EMR table with
+the licensed_clinician_id column left blank or null.
+SUCCESS CRITERIA: The local server database kernel must instantly abort the transaction,
+triggering a foreign key or check constraint failure that rolls back the write operation.","📌 As a result of the need of mitigating the medical liability, prevention the downstream propagation of AI
+hallucinations or edge-case diagnostic errors, and ensure that final clinical
+accountability rests solely with a licensed human medical practitioner., 
+⚙️ The system must satisfy: Implement an architectural air-gap gatekeeper where no automated ML insights or
+generative patient summaries can be committed to the official Electronic Medical
+Record (EMR) or finalized for patient distribution without explicit human sign-off., 
+🛑 And it shall not violate: The database layer SHALL NOT allow any automated ML/LLM diagnosis asset or report
+to transition to a 'FINALIZED', 'ARCHIVED', or 'PATIENT_ACCESSIBLE' status code without an authenticating digital signature from a licensed human clinician.  The constrain shall apply to 100% of diagnostic sessions, triage check-sheets, and generated
+musculoskeletal patient-education outputs before saving.."

proj_level_reading/Requirement_Analysis/UC_Design/FR_25_UC_DESIGN/4 scenarios can consider.csv

@@ -0,0 +1,9 @@
+Scene (Quadrant),Layered Three-Tier ML Stack Performance Impact (Your Proposed Design)
+"Q1: True Agreement
+(AI Correct / Doctor Correct)","Explainable Baseline Sync: The VKIST Grader computes the numerical matrices & the GradCAM. The LLM Explainer parses the raw segmentation parameters  + GradCAM and automatically generates an interactive diagnostic draft chat panel & LLM based on the GradCAM + RAG-knowledge  + the raw-ultrasound to explain the VKIST-grader. The RAG-Referee confirms zero clinical guidelines variance, and logs a high-trust concur structural block.  <note both LLM have to record back the Chain-of-Though for explain why the LLM’s agree & allow the result)"
+"Q2: Automation Override Risk
+(AI Correct / Doctor Oversights / Confuse)","The Conversational Circuit Breaker triggers when a clinician disagrees / confuse / uncertain with the system's diagnostic grade, halting the workflow to launch an interactive Socratic dialogue that bridges the gap between human intuition and machine inference. In this mode, the system (LLM-explainer) shall synthesize raw VKIST-ML vision tensors, GradCAM activation heatmaps, and evidence retrieved via RAG into a collaborative analysis session, forcing the clinician to articulate their reasoning against the machine's spatial and vascular observations. To ensure diagnostic integrity, a BERT-based hallucination detector continuously monitors the chat for semantic drift or illogical premises; if the conversation reaches an impasse or the system detects potential contextual hallucination, the RAG-Referee intervenes as an unbiased arbiter. This referee bypasses the conversational history to provide definitive, evidence-based source material from clinical guidelines (such as ESSR) directly tied to the raw imaging metrics, resolving the ambiguity through objective, verifiable medical evidence rather than subjective negotiation."
+"Q3: Clinician Subservience Risk
+(AI Hallucinates / Doctor Correct)","The Objective Critic Loop initiates when a clinician contests an automated diagnostic grade, triggering an interactive Socratic consultation that bridges human intuition with machine inference via the VKIST-ML vision stack. During this loop, the LLM Explainer renders a GradCAM-anchored reasoning draft that visualizes the specific pixel-level feature activation logic, enabling the clinician to identify and isolate artifacts—such as motion tremors—that may have induced a system hallucination. To ensure diagnostic integrity, a BERT-based detector continuously monitors the dialogue for semantic drift, and if the interaction reaches an impasse or context hallucination is detected, the RAG-Referee intervenes as an unbiased, independent arbiter. By cross-verifying the clinician’s assertion and the model’s reasoning against raw imaging tensors and immutable, source-cited clinical guidelines (e.g., ESSR/OMERACT standards), the Referee resolves diagnostic ambiguity with objective evidence, ultimately committing the validated session as an annotated ground-truth record for targeted system reinforcement."
+"Q4: Double Blind Failure dues to edge-case
+(AI Faulty / Doctor Biased)","Anomaly Escalation Protocol: In instances where both the diagnostic system and the clinician encounter an edge-case—or ""unknown-unknown""—that lacks precedent in the current RAG knowledge base, the system initiates the Anomaly Escalation Protocol. The LLM Explainer detects this ""epistemic uncertainty"" (via low vision-stack confidence and empty RAG retrieval results) and shifts the interface from ""Diagnostic Support"" to ""Clinical Investigation Mode."" Instead of attempting to force a Grade-based diagnosis, the Internal Consultor guides the clinician to document the unique morphological features through a structured annotation protocol, facilitating a Socratic investigation into the anomaly. The system transparently acknowledges the limitation, explicitly stating that current clinical guidelines do not cover this specific presentation, and prompts the clinician to manually document findings. With the clinician’s consent, the workspace commits this session as a ""Novel Research Case,"" automatically serializing the raw imaging tensors, clinician observations, and artifact logs to a secure telemetry queue, flagging the data for system maintainers to perform targeted model retraining and protocol refinement."

proj_level_reading/Requirement_Analysis/UC_Design/FR_25_UC_DESIGN/CONTEXT_FR_25_UC_ELIT.md

@@ -0,0 +1,187 @@
+BELOW is the consolidated structural baseline engineering reference document tracking all architectural constraints, system interactions, and discovered sub-components for the **FR-25 Synovitis Grading Engine**.
+
+---
+
+# Context_FR_25_UC.md
+
+## 1. Context, Mission Boundary & Core Rationale
+
+### 1.1 Scope Identification
+
+* **Target Core Functional Requirement:** `FR-25` (ULTS-Đánh giá và phân cấp mức độ viêm màng hoạt dịch / Synovitis Grading Engine).
+* **Primary System Boundary:** The workspace acts as a strict secure diagnostic execution wrapper. In order to manage systemic liability and avoid black-box compliance failures, the advanced multi-agent checking modules (**LLM Explainer**, **BERT Hallucination Detector**, and **RAG-Referee**) are restricted from handling generic application operations. They are encapsulated entirely as **Internal Layered Workspace Subsystems** dedicated exclusively to validating human-AI coordination logs for `FR-25`.
+
+### 1.2 Engineering Value Optimization
+
+* **The Clinical Chasm:** In high-volume Vietnamese public clinics, specialists face intensive shift demands often exceeding 100 scans daily. Basic AI setups risk inducing automated checklist fatigue or introducing catastrophic blindness loops if human clinicians simply blind-concur with machine estimations.
+* **The System Solution:** By engineering clear internal state boundaries separating standard CRUD processing from multi-tier validation agents, the system systematically handles four concurrent behavioral quadrants. It forces explicit human verification loops during disagreements, cross-references findings against un-biased clinical knowledge nodes, and maintains diagnostic speed metrics without degrading data correctness limits.
+
+---
+
+## 2. Structural Actor Profile Mapping
+
+| Actor Name | Canonical Identifier | Role Scope & Operational Profile within FR-25 Boundary |
+| --- | --- | --- |
+| **Diagnostic Radiologist** | `Rad (UP5)` | **Primary Human Actor:** National-level clinical expert (Specialist II / Professor, age 40–60+). Holds ultimate medical accountability; validates and signs off pixel segmentations, metrics, and grading summaries. |
+| **Hospital EMR System** | `EMR` | **External System Actor:** Recipient database server. Receives finalized JSON structures and signed clinical data logs over localized network pipes post human validation. |
+| **VKIST Vision Grader Engine** | `Grader` | **External System Actor:** Foundation deep-learning array (ConvNeXt/MedSAM). Ingests raw frame parameters and produces pixel segmentations, thickness markers (mm), and classification tensors. |
+
+---
+
+## 3. Discovered Use Cases (4-Quadrant Framework)
+
+### 3.1 Core Image Data Intake & Workflow Baselines
+
+* **`UC-48376` (Load Patient Scan Session):** Ingests incoming image frames, maps spatial structures, and activates local session states.
+* **`UC-47988` (Review Suggested Synovitis Grade):** Renders the initial classification summary panel (Grades 0-3) alongside color-coded segmentation overlaps.
+* **`UC-92006` (Finalize & Sign Electronic Record):** Seals the session data via localized human cryptographic signing steps before dispatching payload JSON logs to the hospital storage sinks.
+
+### 3.2 Quadrant 1: True Agreement Flow (AI Correct / Doctor Correct)
+
+* **`UC-25776` (Generate GradCAM & CoT Explanation Panel):** The internal LLM Explainer checks raw pixel masks and maps multi-modal prompt matrices to output clear, human-scannable rationales.
+* **`UC-02423` (Log High-Trust Concur Block):** Encapsulates the corresponding Chain-of-Thought logs confirming human-machine consensus into a structured block to verify system state traceability.
+
+### 3.3 Quadrant 2: Automation Override Risk Loop (AI Correct / Doctor Oversight)
+
+* **`UC-22159` (Trigger Conversational Circuit Breaker):** Intercepts standard workspace finalization pathways if high mouse click adjustments or text conflict markers indicate user friction or ambiguity.
+* **`UC-55146` (Facilitate Socratic Reasoning Dialogue):** Initiates an inline workspace chat panel, prompting the specialist to evaluate spatial discrepancies or vascular metrics versus the machine's model inputs.
+* **`UC-74821` (Monitor Drift via BERT Sub-Layer):** Scans active conversation tokens continuously to detect illogical claims or contextual drift during active discussion.
+* **`UC-65473` (Arbitrate Evidence via RAG-Referee):** Intervenes if human-machine disputes reach an impasse, bypassing active chat logs to pull verified medical guidelines directly from fixed reference sources.
+
+### 3.4 Quadrant 3: Clinician Subservience Risk Loop (AI Hallucinates / Doctor Correct)
+
+* **`UC-25637` (Expose Pixel-Level Activation Logic):** Displays granular layer activations and weight scores when a clinician actively contests a machine grade suggestion.
+* **`UC-60739` (Isolate Visual Noise/Artifacts):** Provides on-screen cursor brushes for the specialist to isolate and mask out clutter variables like acoustic shadowing or bone scattering.
+* **`UC-62864` (Commit Validated Ground-Truth Record):** Re-runs data logs through the verification referee, updating final reports to show human superiority while saving the masked framework for subsequent model training runs.
+
+### 3.5 Quadrant 4: Double Blind Failure Loop (AI Faulty / Doctor Biased)
+
+* **`UC-35956` (Activate Clinical Investigation Mode):** Transitions the user interface environment instantly to a strict manual tracking orientation when low vision confidence values align with zero-match RAG search responses.
+* **`UC-47796` (Execute Structured Morphology Annotation):** Displays a standardized template forcing manual plotting of novel structural modifications or unrecognized lesion variations.
+* **`UC-01580` (Serialize Session to Telemetry Queue):** Packages unencrypted image tensors, coordinate indices, and clinical commentary blocks into localized storage pipelines, bypassing standard EMR charts to flag data directly for software engineering team review.
+
+---
+
+## 4. Master PlantUML System Compilation
+
+```plantuml
+@startuml
+' Settings & Aesthetic Optimization
+left to right direction
+skin rose
+
+' External Actors
+actor "Diagnostic Radiologist (UP5)" as Rad
+actor "Hospital EMR System" as EMR << System >>
+actor "VKIST Vision Grader Engine" as Grader << System >>
+
+' System Boundary
+rectangle "VKIST MSK Workspace (FR-25: Synovitis Grading Scope)" {
+    
+    ' Core Viewing & Data Intake Pipelines
+    usecase "Load Patient Scan Session" as UC-48376
+    usecase "Review Suggested Synovitis Grade (0-3)" as UC-47988
+    usecase "Finalize & Sign Electronic Record" as UC-92006
+    
+    ' Sub-Boundary for the Internal Cognitive/Multi-Agent Subsystems
+    rectangle "Internal Cognitive & Validation Stack" {
+        
+        ' Q1: True Agreement Use Cases
+        usecase "Generate GradCAM & CoT Explanation Panel" as UC-25776
+        usecase "Log High-Trust Concur Block" as UC-02423
+        
+        ' Q2: Automation Override Risk Use Cases
+        usecase "Trigger Conversational Circuit Breaker" as UC-22159
+        usecase "Facilitate Socratic Reasoning Dialogue" as UC-55146
+        usecase "Monitor Drift via BERT Sub-Layer" as UC-74821
+        usecase "Arbitrate Evidence via RAG-Referee" as UC-65473
+        
+        ' Q3: Clinician Subservience Risk Use Cases
+        usecase "Expose Pixel-Level Activation Logic" as UC-25637
+        usecase "Isolate Visual Noise/Artifacts" as UC-60739
+        usecase "Commit Validated Ground-Truth Record" as UC-62864
+        
+        ' Q4: Double Blind Failure Use Cases
+        usecase "Activate Clinical Investigation Mode" as UC-35956
+        usecase "Execute Structured Morphology Annotation" as UC-47796
+        usecase "Serialize Session to Telemetry Queue" as UC-01580
+    }
+}
+
+' Human-System Interactions
+Rad --> UC-48376
+Rad --> UC-47988
+Rad --> UC-92006
+
+' Q2, Q3 & Q4 Interaction Entrypoints
+Rad --> UC-55146 : Argue observations
+Rad --> UC-60739 : Tag artifacts
+Rad --> UC-47796 : Document manual findings
+
+' Machine-to-Machine Pipelines
+Grader --> UC-48376 : Feeds vision tensors & initial scores
+
+' Internal Use Case Associations & Extends
+UC-48376 ..> UC-25776 : <<include>>
+UC-25776 ..> UC-02423 : <<include>>
+
+' Q2 Loop Connections
+UC-47988 <.. UC-22159 : <<extend>> (If clinician friction detected)
+UC-22159 ..> UC-55146 : <<include>>
+UC-55146 ..> UC-74821 : <<include>>
+UC-74821 ..> UC-65473 : <<extend>> (If impasse or semantic drift caught)
+
+' Q3 Loop Connections
+UC-47988 <.. UC-25637 : <<extend>> (If clinician contests AI score)
+UC-25637 ..> UC-60739 : <<include>>
+UC-60739 ..> UC-62864 : <<include>>
+
+' Q4 Loop Connections
+UC-47988 <.. UC-35956 : <<extend>> (If low confidence & empty RAG)
+UC-35956 ..> UC-47796 : <<include>>
+UC-47796 ..> UC-01580 : <<include>>
+
+' Final Hand-off Synchronization
+UC-92006 ..> EMR : Sync standardized structural JSON data
+@enduml
+
+```
+
+---
+
+## 5. Blueprint Cross-Traceability Matrices
+
+### 5.1 Scenario-to-Agent Mapping Tracking Matrix
+
+This structural trace links the user behavior scenarios directly back to the active internal validation elements processing the loop.
+
+```
++---------------------------+-----------------------+-------------------------+-------------------------+
+| Interaction Scenario      | Core Vision Component | Dialogue Safety Layer   | Arbitration Safety Node |
++---------------------------+-----------------------+-------------------------+-------------------------+
+| Q1: True Agreement        | VKIST Vision Grader   | LLM Explainer (CoT Log) | RAG-Referee (Clear)     |
+| Q2: Automation Override   | VKIST Vision Grader   | Socratic Circuit Breaker| RAG-Referee (Active)    |
+| Q3: Clinician Subservience| Feature Map Vis       | Objective Critic Dialog | RAG-Referee (Active)    |
+| Q4: Double Blind Edge Case| Anomaly State Ingest  | Exploratory Morphology  | Telemetry Retrain Queue |
++---------------------------+-----------------------+-------------------------+-------------------------+
+
+```
+
+### 5.2 Functional Requirements Validation Trace
+
+* **ULTS-FR-25 Criteria Trace 01:** The system must process initial classifications using pixel-percentage markers. Checked by: `UC-48376` $\rightarrow$ `UC-47988`.
+* **ULTS-FR-25 Criteria Trace 02:** System designs must enforce a circuit breaker step if user actions indicate diagnostic mismatch or context drift. Checked by: `UC-22159` $\rightarrow$ `UC-74821`.
+* **ULTS-FR-25 Criteria Trace 03:** Sessions documenting unmapped anatomical variants must bypass standard hospital charts and stream records directly to optimization sinks. Checked by: `UC-35956` $\rightarrow$ `UC-01580`.
+
+---
+
+## 6. Downstream UIX & Specification Target Anchors
+
+This baseline file establishes structural anchor configurations for subsequent product development phases:
+
+1. **Phase 4 (Workspace Dashboard Wireframing):** Wireframe templates must reserve split-screen display blocks: one side hosting the medical canvas with artifact isolation tools (`UC-60739`), and an inline section mapping socratic messaging interactions (`UC-55146`).
+2. **Use Case Specification Drafting:** Individual use case descriptions can reference this anchor block to maintain absolute consistency regarding precondition bounds, primary exception vectors, and hand-off synchronization parameters (`EMR`).
+
+---
+
+*This engineering reference document accurately captures the system boundaries finalized during the requirement discovery sprint.*

proj_level_reading/Requirement_Analysis/UC_Design/FR_25_UC_DESIGN/FR_25_UC_SPEC.md

@@ -0,0 +1,951 @@
+
+---
+
+# PART 1: Core Viewing & Data Intake Pipelines
+
+## 1. UC-48376: Load Patient Scan Session
+
+### Notion Properties Input Panel
+
+```text
+* Name [Verb + Noun]: Load Patient Scan Session
+* Actor: Diagnostic Radiologist (Rad), VKIST Vision Grader Engine (Grader)
+* Goal: Ingest raw ultrasound frame arrays and initialize the diagnostic session state.
+* Interaction: System-to-System / User-to-System
+* Stimulus: User opens an unreviewed patient file, or the workspace catches an active DICOM stream hook.
+* SysResponse: Confirmation that raw frame arrays are mapped, spatial calibrations are set, and the local session state is active.
+* VerboseForm (Formula Reference View): "The use case 'Load Patient Scan Session' defines a User-to-System / System-to-System interaction where the Diagnostic Radiologist (Rad) and VKIST Vision Grader Engine (Grader) aim to Ingest raw ultrasound frame arrays and initialize the diagnostic session state. This workflow is triggered when User opens an unreviewed patient file, or the workspace catches an active DICOM stream hook, causing the system to respond by providing Confirmation that raw frame arrays are mapped, spatial calibrations are set, and the local session state is active."
+
+```
+
+### Page Body Content (`SpecificationWithDiagram`)
+
+```markdown
+# Use Case Deep-Dive: Load Patient Scan Session
+
+## 1. Structural Preconditions & Postconditions
+* **Preconditions:**
+  * Local workspace application is authenticated and has secure socket access to the local image buffer.
+  * DICOM/raw frame data payload is uncorrupted and readable.
+* **Postconditions (Success State):**
+  * Core frame parameters are loaded into memory with spatial scale calibrations preserved.
+  * Background parsing pipeline registers the unique session hash and prepares the context matrix for downstream agents.
+
+---
+
+## 2. Interaction Scenarios (Step-by-Step Flow)
+
+### Main Success Scenario (Happy Path)
+1. **Diagnostic Radiologist** selects a patient case file from the workspace worklist interface.
+2. **VKIST Vision Grader Engine** feeds raw ultrasound image tensors, spatial calibrations, and foundational frame telemetry metadata into the workspace memory layer.
+3. **System** extracts pixel dimensions and constructs localized rendering viewports.
+4. **System** includes `UC-25776` in the background to spin up explanation prompt matrices.
+5. **System** displays the fully loaded image frame in the workspace canvas, preparing the viewport for immediate review.
+
+### Alternative & Exception Flows
+* **Exception Flow A: Corrupted Image Frame Payload**
+  * At step [2], if the payload data fails format validation or structural check headers, the system halts execution, logs a data corruption fault code, and alerts the user with an "Unable to Parse Scan Session" dialog box.
+* **Exception Flow B: Resolution / Calibration Mismatch**
+  * At step [3], if spatial aspect ratios or metadata pixel matrices lack the standardized calibration tags required by the vision engine, the workspace falls back to a safe default scale flag and displays a non-blocking diagnostic accuracy warning icon.
+
+---
+
+## 3. PlantUML Visual Model
+```plantuml
+@startuml
+left to right direction
+skin rose
+
+actor "Diagnostic Radiologist" as Rad
+actor "VKIST Vision Grader Engine" as Grader << System >>
+
+rectangle "VKIST MSK Workspace (FR-25)" {
+    usecase "Load Patient Scan Session" as UC-48376
+    usecase "Generate GradCAM & CoT Explanation Panel" as UC-25776
+}
+
+Rad --> UC-48376
+Grader --> UC-48376
+UC-48376 ..> UC-25776 : <<include>>
+@enduml
+```
+
+
+---
+
+## 2. UC-47988: Review Suggested Synovitis Grade (0-3)
+
+### Notion Properties Input Panel
+```text
+* Name [Verb + Noun]: Review Suggested Synovitis Grade (0-3)
+* Actor: Diagnostic Radiologist (Rad)
+* Goal: Evaluate the ML engine's proposed synovitis classification and structural overlays.
+* Interaction: User-to-System
+* Stimulus: The workspace completes localized UI construction and displays the diagnostic panel.
+* SysResponse: Display of classification metrics (Grades 0-3), color-coded overlays, and active risk-extension hooks.
+* VerboseForm (Formula Reference View): "The use case 'Review Suggested Synovitis Grade (0-3)' defines a User-to-System interaction where the Diagnostic Radiologist (Rad) aims to Evaluate the ML engine's proposed synovitis classification and structural overlays. This workflow is triggered when The workspace completes localized UI construction and displays the diagnostic panel, causing the system to respond by providing Display of classification metrics (Grades 0-3), color-coded overlays, and active risk-extension hooks."
+
+```
+
+### Page Body Content (`SpecificationWithDiagram`)
+
+```markdown
+# Use Case Deep-Dive: Review Suggested Synovitis Grade (0-3)
+
+## 1. Structural Preconditions & Postconditions
+* **Preconditions:**
+  * Image frames and raw ML prediction tensors (segmentation masks, classification weights) are fully loaded in memory via `UC-48376`.
+* **Postconditions (Success State):**
+  * System records human gaze/interaction initialization flags.
+  * System keeps exception-based extend vectors armed (`UC-22159`, `UC-25637`, `UC-35956`).
+
+---
+
+## 2. Interaction Scenarios (Step-by-Step Flow)
+
+### Main Success Scenario (Happy Path)
+1. **System** presents the active ultrasound canvas with interactive, toggleable, color-coded segmentation mask overlays.
+2. **System** displays the vision engine's suggested synovitis grading estimation (Grade 0, 1, 2, or 3) alongside structural pixel-percentage distribution metrics.
+3. **Diagnostic Radiologist** inspects the spatial distribution of the synovial hypertrophy markers and reads the inline text panels.
+4. **Diagnostic Radiologist** approves the visual data metrics without requesting alterations or triggering corrective dialogue paths.
+
+### Alternative & Exception Flows
+* **Extension Flow A: Clinician Friction / Disagreement Caught**
+  * At step [3], if mouse click frequencies suggest hesitation or manual adjustments cross a conflict delta threshold, the execution path triggers `UC-22159` to prevent blind override errors.
+* **Extension Flow B: Expert Contests Automated Grade**
+  * At step [3], if the clinician explicitly changes the classification dropdown away from the ML-proposed score, the workspace extends to `UC-25637` to display the machine activation weights.
+* **Extension Flow C: Anomaly / Confidence Failure Detected**
+  * At step [1], if the deep-learning array returned a classification confidence metric below safety bounds paired with blank knowledge base lookups, the interface branches into `UC-35956`.
+
+---
+
+## 3. PlantUML Visual Model
+```plantuml
+@startuml
+left to right direction
+skin rose
+
+actor "Diagnostic Radiologist" as Rad
+
+rectangle "VKIST MSK Workspace (FR-25)" {
+    usecase "Review Suggested Synovitis Grade (0-3)" as UC-47988
+    usecase "Trigger Conversational Circuit Breaker" as UC-22159
+    usecase "Expose Pixel-Level Activation Logic" as UC-25637
+    usecase "Activate Clinical Investigation Mode" as UC-35956
+}
+
+Rad --> UC-47988
+UC-47988 <.. UC-22159 : <<extend>>
+UC-47988 <.. UC-25637 : <<extend>>
+UC-47988 <.. UC-35956 : <<extend>>
+@enduml
+```
+
+
+
+---
+
+## 3. UC-92006: Finalize & Sign Electronic Record
+
+### Notion Properties Input Panel
+```text
+* Name [Verb + Noun]: Finalize & Sign Electronic Record
+* Actor: Diagnostic Radiologist (Rad), Hospital EMR System (EMR)
+* Goal: Authenticate, cryptographically seal, and sync verified diagnostic reports down to storage infrastructure.
+* Interaction: User-to-System / System-to-System
+* Stimulus: User executes the final confirmation/signature command button in the workspace utility ribbon.
+* SysResponse: Generation of a signed cryptographic log block and structured JSON transmission payload delivered to the EMR endpoint.
+* VerboseForm (Formula Reference View): "The use case 'Finalize & Sign Electronic Record' defines a User-to-System / System-to-System interaction where the Diagnostic Radiologist (Rad) and Hospital EMR System (EMR) aim to Authenticate, cryptographically seal, and sync verified diagnostic reports down to storage infrastructure. This workflow is triggered when User executes the final confirmation/signature command button in the workspace utility ribbon, causing the system to respond by providing Generation of a signed cryptographic log block and structured JSON transmission payload delivered to the EMR endpoint."
+
+```
+
+### Page Body Content (`SpecificationWithDiagram`)
+
+```markdown
+# Use Case Deep-Dive: Finalize & Sign Electronic Record
+
+## 1. Structural Preconditions & Postconditions
+* **Preconditions:**
+  * Active scan session evaluation has been resolved, and grading metrics are verified by the human specialist.
+  * Local localized network channel to the hospital server framework is functional.
+* **Postconditions (Success State):**
+  * Session record is transformed into a read-only state.
+  * Standardized structural JSON payload data is safely stored within the Hospital EMR System sink.
+
+---
+
+## 2. Interaction Scenarios (Step-by-Step Flow)
+
+### Main Success Scenario (Happy Path)
+1. **Diagnostic Radiologist** initiates the session finalization pipeline by interacting with the cryptographic signature command trigger.
+2. **System** prompts for the secure authentication credentials of the signing specialist.
+3. **System** generates a unified clinical log structure, packing structural thickness measurements (mm), final validated synovitis tier scores, and accompanying multi-agent trace logs.
+4. **System** calculates a secure cryptographic data hash, locking the session record into an immutable post-review profile.
+5. **System** delivers the structured data package across localized network pipes to the **Hospital EMR System**.
+6. **Hospital EMR System** confirms safe database commit storage updates and provides an acknowledgment packet back to the workspace.
+
+### Alternative & Exception Flows
+* **Exception Flow A: Network Pipeline Transmission Failure**
+  * At step [5], if network communications timeout or socket breaks occur, the workspace locks the finalized JSON package into a local encrypted offline buffer, changes the session status tag to "Pending Sync", and presents a clear connectivity warning alert.
+
+---
+
+## 3. PlantUML Visual Model
+```plantuml
+@startuml
+left to right direction
+skin rose
+
+actor "Diagnostic Radiologist" as Rad
+actor "Hospital EMR System" as EMR << System >>
+
+rectangle "VKIST MSK Workspace (FR-25)" {
+    usecase "Finalize & Sign Electronic Record" as UC-92006
+}
+
+Rad --> UC-92006
+UC-92006 ..> EMR : Sync standardized structural JSON data
+@enduml
+```
+---
+
+
+# PART 2: Quadrant 1 — True Agreement Flows (AI Correct / Doctor Correct)
+
+## 4. UC-25776: Generate GradCAM & CoT Explanation Panel
+
+### Notion Properties Input Panel
+```text
+* Name [Verb + Noun]: Generate GradCAM & CoT Explanation Panel
+* Actor: Diagnostic Radiologist (Rad)
+* Goal: Present clear, pixel-linked visuospatial explanations and multi-modal clinical reasoning for high-trust verification.
+* Interaction: User-to-System
+* Stimulus: Inclusion trigger initialized during session data intake (`Load Patient Scan Session`).
+* SysResponse: Renders heatmaps highlighting model focus zones alongside structured, clear reasoning steps.
+* VerboseForm (Formula Reference View): "The use case 'Generate GradCAM & CoT Explanation Panel' defines a User-to-System interaction where the Diagnostic Radiologist (Rad) aims to Present clear, pixel-linked visuospatial explanations and multi-modal clinical reasoning for high-trust verification. This workflow is triggered when Inclusion trigger initialized during session data intake (`Load Patient Scan Session`), causing the system to respond by providing Renders heatmaps highlighting model focus zones alongside structured, clear reasoning steps."
+
+```
+
+### Page Body Content (`SpecificationWithDiagram`)
+
+```markdown
+# Use Case Deep-Dive: Generate GradCAM & CoT Explanation Panel
+
+## 1. Structural Preconditions & Postconditions
+* **Preconditions:**
+  * Raw image frames and vision engine inference matrix weights have been imported via `Load Patient Scan Session`.
+* **Postconditions (Success State):**
+  * Split-screen layout displays visual explanation elements without adding visual noise to the core image frame workspace canvas.
+
+---
+
+## 2. Interaction Scenarios (Step-by-Step Flow)
+
+### Main Success Scenario (Happy Path)
+1. **System** evaluates the internal deep-learning model gradient parameters for the target ultrasound image slice.
+2. **System** generates a visual GradCAM heatmap layer mapping feature locations that dictated model classifications (e.g., hypervascularized synovial proliferation zones).
+3. **System** maps multi-modal prompt metrics through the internal LLM Explainer module to produce a concise, point-by-point clinical reasoning string.
+4. **System** populates the split-screen workspace sub-section block with this explanation data to guide human inspection efficiently.
+5. **System** includes `UC-02423` to serialize verification metadata.
+
+---
+
+## 3. PlantUML Visual Model
+```plantuml
+@startuml
+left to right direction
+skin rose
+
+actor "Diagnostic Radiologist" as Rad
+
+rectangle "VKIST MSK Workspace (FR-25)" {
+    usecase "Generate GradCAM & CoT Explanation Panel" as UC_Core
+    usecase "Log High-Trust Concur Block" as UC_Sub
+}
+
+Rad --> UC_Core
+UC_Core ..> UC_Sub : <<include>>
+@enduml
+
+```
+
+---
+
+## 5. UC-02423: Log High-Trust Concur Block
+
+### Notion Properties Input Panel
+```text
+* Name [Verb + Noun]: Log High-Trust Concur Block
+* Actor: Hospital EMR System (EMR)
+* Goal: Secure the human-AI alignment log trace within the final diagnostic report payload.
+* Interaction: System-to-System
+* Stimulus: Explanatory panel validation completes successfully without user override actions.
+* SysResponse: Appends a tamper-evident audit trace block verifying explicit human-AI agreement into the session log cache.
+* VerboseForm (Formula Reference View): "The use case 'Log High-Trust Concur Block' defines a System-to-System interaction where the Hospital EMR System (EMR) aims to Secure the human-AI alignment log trace within the final diagnostic report payload. This workflow is triggered when Explanatory panel validation completes successfully without user override actions, causing the system to respond by providing Appends a tamper-evident audit trace block verifying explicit human-AI agreement into the session log cache."
+
+```
+
+### Page Body Content (`SpecificationWithDiagram`)
+
+```markdown
+# Use Case Deep-Dive: Log High-Trust Concur Block
+
+## 1. Structural Preconditions & Postconditions
+* **Preconditions:**
+  * Multi-modal explanations were fully generated (`UC-25776`) and passed without human alteration marks.
+* **Postconditions (Success State):**
+  * Explicit audit string trace tracking high-trust convergence is formatted for downstream pipeline compilation.
+
+---
+
+## 2. Interaction Scenarios (Step-by-Step Flow)
+
+### Main Success Scenario (Happy Path)
+1. **System** detects a direct consensus condition where the human expert confirms the model data without text/grading edits.
+2. **System** serializes the multi-modal text breakdown and pixel attribution coordinates into an immutable log string block.
+3. **System** assigns an explicit alignment token header flag (`HIGH_TRUST_CONCURRENCE`).
+4. **System** caches this specialized tracking trace within the localized session state data, making it ready to be appended during final data hand-off routines (`UC-92006`).
+
+---
+
+## 3. PlantUML Visual Model
+```plantuml
+@startuml
+left to right direction
+skin rose
+
+actor "Hospital EMR System" as EMR << System >>
+
+rectangle "VKIST MSK Workspace (FR-25)" {
+    usecase "Log High-Trust Concur Block" as UC-02423
+}
+
+UC-02423 ..> EMR : (Prepares payload for final sync)
+@enduml
+
+```
+
+---
+
+# PART 3: Quadrant 2 — Automation Override Risk Loops (AI Correct / Doctor Oversight)
+
+## 6. UC-22159: Trigger Conversational Circuit Breaker
+
+### Notion Properties Input Panel
+```text
+* Name [Verb + Noun]: Trigger Conversational Circuit Breaker
+* Actor: Diagnostic Radiologist (Rad)
+* Goal: Intercept premature finalization workflows if interface telemetry reveals friction, hesitation, or cognitive blind-spots.
+* Interaction: User-to-System
+* Stimulus: Extended extension trace caught during review steps if user behavior markers diverge from smooth consensus paths.
+* SysResponse: Halts default workspace finalization routes and shifts the UI into a mandatory safety evaluation mode.
+* VerboseForm (Formula Reference View): "The use case 'Trigger Conversational Circuit Breaker' defines a User-to-System interaction where the Diagnostic Radiologist (Rad) aims to Intercept premature finalization workflows if interface telemetry reveals friction, hesitation, or cognitive blind-spots. This workflow is triggered when Extended extension trace caught during review steps if user behavior markers diverge from smooth consensus paths, causing the system to respond by providing Halts default workspace finalization routes and shifts the UI into a mandatory safety evaluation mode."
+
+```
+
+### Page Body Content (`SpecificationWithDiagram`)
+
+```markdown
+# Use Case Deep-Dive: Trigger Conversational Circuit Breaker
+
+## 1. Structural Preconditions & Postconditions
+* **Preconditions:**
+  * Active session is inside the `UC-47988` workflow phase.
+  * UI layer telemetry captures specific friction indicators (e.g., high-frequency cursor oscillation, repeatedly typing and deleting text, or conflicting grading inputs).
+* **Postconditions (Success State):**
+  * Direct finalization path is securely locked down.
+  * System-forced conversational validation interface is deployed into view.
+
+---
+
+## 2. Interaction Scenarios (Step-by-Step Flow)
+
+### Main Success Scenario (Happy Path)
+1. **System** evaluates live workspace telemetry tracking patterns during active case validation.
+2. **System** detects user behavior triggers signaling high diagnostic friction or potential automatic oversight trends.
+3. **System** blocks the immediate execution availability of the standard finalization command sequence (`UC-92006`).
+4. **System** transforms workspace panel focus areas to present an interactive confirmation overlay.
+5. **System** executes `UC-55146` to initialize direct safety check communications.
+
+---
+
+## 3. PlantUML Visual Model
+```plantuml
+@startuml
+left to right direction
+skin rose
+
+actor "Diagnostic Radiologist" as Rad
+
+rectangle "VKIST MSK Workspace (FR-25)" {
+    usecase "Review Suggested Synovitis Grade (0-3)" as UC-47988
+    usecase "Trigger Conversational Circuit Breaker" as UC_Core
+    usecase "Facilitate Socratic Reasoning Dialogue" as UC_Sub
+}
+
+Rad --> UC-47988
+UC-47988 <.. UC_Core : <<extend>> (If clinician friction detected)
+UC_Core ..> UC_Sub : <<include>>
+@enduml
+
+```
+
+
+
+---
+
+## 7. UC-55146: Facilitate Socratic Reasoning Dialogue
+
+### Notion Properties Input Panel
+```text
+* Name [Verb + Noun]: Facilitate Socratic Reasoning Dialogue
+* Actor: Diagnostic Radiologist (Rad)
+* Goal: Engage the specialist in a targeted, conversational double-check loop regarding controversial structural markers.
+* Interaction: User-to-System
+* Stimulus: Core execution request passed down by the active circuit breaker module (`UC-22159`).
+* SysResponse: Interactive conversational sub-panel displaying focused prompt choices that check specific diagnostic criteria.
+* VerboseForm (Formula Reference View): "The use case 'Facilitate Socratic Reasoning Dialogue' defines a User-to-System interaction where the Diagnostic Radiologist (Rad) aims to Engage the specialist in a targeted, conversational double-check loop regarding controversial structural markers. This workflow is triggered when Core execution request passed down by the active circuit breaker module (`UC-22159`), causing the system to respond by providing Interactive conversational sub-panel displaying focused prompt choices that check specific diagnostic criteria."
+
+```
+
+### Page Body Content (`SpecificationWithDiagram`)
+
+```markdown
+# Use Case Deep-Dive: Facilitate Socratic Reasoning Dialogue
+
+## 1. Structural Preconditions & Postconditions
+* **Preconditions:**
+  * Circuit breaker safety intercept sequence has completed successfully, freezing generic CRUD paths.
+* **Postconditions (Success State):**
+  * User inputs conversational defense arguments or confirms specific anatomical findings.
+  * Live conversation data tokens are actively streamed to automated safety monitors.
+
+---
+
+## 2. Interaction Scenarios (Step-by-Step Flow)
+
+### Main Success Scenario (Happy Path)
+1. **System** initializes a conversational chat element right next to the ultrasound display field.
+2. **System** presents a non-confrontational, clinically grounded question regarding the identified discrepancies (e.g., *"Note the echo-free thickening layer in the suprapatellar recess; please confirm if this modification represents minor effusion or structural pannus tissue"*).
+3. **Diagnostic Radiologist** enters text responses or selects structural tag tokens to clarify their assessment.
+4. **System** includes `UC-74821` in real time to process active conversation token patterns.
+
+---
+
+## 3. PlantUML Visual Model
+```plantuml
+@startuml
+left to right direction
+skin rose
+
+actor "Diagnostic Radiologist" as Rad
+
+rectangle "VKIST MSK Workspace (FR-25)" {
+    usecase "Facilitate Socratic Reasoning Dialogue" as UC_Core
+    usecase "Monitor Drift via BERT Sub-Layer" as UC_Sub
+}
+
+Rad --> UC_Core : Argue observations
+UC_Core ..> UC_Sub : <<include>>
+@enduml
+
+```
+
+
+
+---
+
+## 8. UC-74821: Monitor Drift via BERT Sub-Layer
+
+### Notion Properties Input Panel
+```text
+* Name [Verb + Noun]: Monitor Drift via BERT Sub-Layer
+* Actor: Diagnostic Radiologist (Rad)
+* Goal: Continuously parse communication tokens to identify logical contradictions or semantic drift during clinical debates.
+* Interaction: User-to-System
+* Stimulus: Streamed entry of communication tokens within the active dialogue loop.
+* SysResponse: Real-time semantic checking flags; extends out to the RAG referee if an impasse or severe drift is captured.
+* VerboseForm (Formula Reference View): "The use case 'Monitor Drift via BERT Sub-Layer' defines a User-to-System interaction where the Diagnostic Radiologist (Rad) aims to Continuously parse communication tokens to identify logical contradictions or semantic drift during clinical debates. This workflow is triggered when Streamed entry of communication tokens within the active dialogue loop, causing the system to respond by providing Real-time semantic checking flags; extends out to the RAG referee if an impasse or severe drift is captured."
+
+```
+
+### Page Body Content (`SpecificationWithDiagram`)
+
+```markdown
+# Use Case Deep-Dive: Monitor Drift via BERT Sub-Layer
+
+## 1. Structural Preconditions & Postconditions
+* **Preconditions:**
+  * Active conversational dialogue module is processing user data strings (`UC-55146`).
+* **Postconditions (Success State):**
+  * Log structures capture semantic alignment metrics.
+  * System successfully catches contradictions before data parameters flow to final storage.
+
+---
+
+## 2. Interaction Scenarios (Step-by-Step Flow)
+
+### Main Success Scenario (Happy Path)
+1. **System** continuously intercepts conversation tokens as the human expert types input strings.
+2. **System** runs token matrices through an embedded BERT checking model to calculate contextual semantic coherence scores.
+3. **System** verifies that user claims line up logically with the visual indicators under review.
+4. **System** approves the validated conversational step, allowing the specialist to complete the confirmation cycle smoothly.
+
+### Alternative & Exception Flows
+* **Extension Flow A: Impasse or Semantic Contradiction Detected**
+  * At step [3], if the specialist's input text contradicts objective structural metrics (e.g., claiming a region is "completely normal" while the visual layer registers massive synovial proliferation) or exhibits context drift, the process branches into `UC-65473` to request evidence evaluation.
+
+---
+
+## 3. PlantUML Visual Model
+```plantuml
+@startuml
+left to right direction
+skin rose
+
+actor "Diagnostic Radiologist" as Rad
+
+rectangle "VKIST MSK Workspace (FR-25)" {
+    usecase "Monitor Drift via BERT Sub-Layer" as UC_Core
+    usecase "Arbitrate Evidence via RAG-Referee" as UC_Ext
+}
+
+Rad --> UC_Core
+UC_Core <.. UC_Ext : <<extend>> (If impasse or semantic drift caught)
+@enduml
+
+```
+
+
+---
+
+## 9. UC-65473: Arbitrate Evidence via RAG-Referee
+
+### Notion Properties Input Panel
+```text
+* Name [Verb + Noun]: Arbitrate Evidence via RAG-Referee
+* Actor: Diagnostic Radiologist (Rad)
+* Goal: Query static, authoritative clinical knowledge bases to resolve human-machine disagreements with objective evidence.
+* Interaction: User-to-System
+* Stimulus: Triggered when communication tracking scores cross a severe semantic mismatch or impasse threshold.
+* SysResponse: Inline injection of un-biased diagnostic text extracts and guidelines matching the active frame conditions.
+* VerboseForm (Formula Reference View): "The use case 'Arbitrate Evidence via RAG-Referee' defines a User-to-System interaction where the Diagnostic Radiologist (Rad) aims to Query static, authoritative clinical knowledge bases to resolve human-machine disagreements with objective evidence. This workflow is triggered when Triggered when communication tracking scores cross a severe semantic mismatch or impasse threshold, causing the system to respond by providing Inline injection of un-biased diagnostic text extracts and guidelines matching the active frame conditions."
+
+```
+
+### Page Body Content (`SpecificationWithDiagram`)
+
+```markdown
+# Use Case Deep-Dive: Arbitrate Evidence via RAG-Referee
+
+## 1. Structural Preconditions & Postconditions
+* **Preconditions:**
+  * BERT analytics layers detect a diagnostic impasse or significant semantic drift.
+  * Authoritative local clinical knowledge base index (e.g., OMERACT synovitis grading reference manuals) is online and responsive.
+* **Postconditions (Success State):**
+  * Disagreement matrix is resolved via verified medical data injection.
+  * Final chosen path is linked directly to a standard medical guideline anchor.
+
+---
+
+## 2. Interaction Scenarios (Step-by-Step Flow)
+
+### Main Success Scenario (Happy Path)
+1. **System** halts active conversational dialogue inputs temporarily to execute a localized context search.
+2. **System** extracts spatial measurements and text tokens to construct a specialized RAG search string.
+3. **System** queries local, validated medical knowledge data banks to locate matching diagnostic criteria sections.
+4. **System** displays the verified guideline text extract right inside the workspace alert view block (e.g., *"OMERACT standardizes Grade 2 as hypoechoic synovial hypertrophy demonstrating fluid-filled distension up to structural boundary bounds"*).
+5. **Diagnostic Radiologist** reviews the authoritative reference framework and either adjusts their classification choice or submits a structured expert override justifying their deviation.
+
+---
+
+## 3. PlantUML Visual Model
+```plantuml
+@startuml
+left to right direction
+skin rose
+
+actor "Diagnostic Radiologist" as Rad
+
+rectangle "VKIST MSK Workspace (FR-25)" {
+    usecase "Arbitrate Evidence via RAG-Referee" as UC_Core
+}
+
+Rad --> UC_Core
+@enduml
+
+```
+
+
+
+---
+
+# PART 4: Quadrant 3 — Clinician Subservience Risk Loops (AI Hallucinates / Doctor Correct)
+
+## 10. UC-25637: Expose Pixel-Level Activation Logic
+
+### Notion Properties Input Panel
+```text
+* Name [Verb + Noun]: Expose Pixel-Level Activation Logic
+* Actor: Diagnostic Radiologist (Rad)
+* Goal: Reveal fine-grained layer weights and activation responses when the human specialist challenges an automated grade prediction.
+* Interaction: User-to-System
+* Stimulus: Clinician manually alters or rejects the ML-proposed classification score in the review pane.
+* SysResponse: Interactive visual mapping showing the exact high-frequency noise regions driving model prediction errors.
+* VerboseForm (Formula Reference View): "The use case 'Expose Pixel-Level Activation Logic' defines a User-to-System interaction where the Diagnostic Radiologist (Rad) aims to Reveal fine-grained layer weights and activation responses when the human specialist challenges an automated grade prediction. This workflow is triggered when Clinician manually alters or rejects the ML-proposed classification score in the review pane, causing the system to respond by providing Interactive visual mapping showing the exact high-frequency noise regions driving model prediction errors."
+
+```
+
+### Page Body Content (`SpecificationWithDiagram`)
+
+```markdown
+# Use Case Deep-Dive: Expose Pixel-Level Activation Logic
+
+## 1. Structural Preconditions & Postconditions
+* **Preconditions:**
+  * Active session is inside the `UC-47988` interface phase.
+  * Specialist chooses an option that breaks clean model agreement paths.
+* **Postconditions (Success State):**
+  * Internal neural layer weight vectors are visually mapped onto the primary medical viewport.
+  * Core manual artifact isolation tool sets become active on the canvas layout.
+
+---
+
+## 2. Interaction Scenarios (Step-by-Step Flow)
+
+### Main Success Scenario (Happy Path)
+1. **Diagnostic Radiologist** changes the system-suggested grade classification dropdown setting.
+2. **System** captures the modification step and branches away from the standard review pathway to reveal underlying model mechanics.
+3. **System** transforms image layers to display fine-grained activation weights, revealing exactly which pixel clusters (e.g., acoustic shadowing regions or bone interfaces) skewed the model's calculation.
+4. **System** includes `UC-60739` to let the specialist manually clean up the noise zones.
+
+---
+
+## 3. PlantUML Visual Model
+```plantuml
+@startuml
+left to right direction
+skin rose
+
+actor "Diagnostic Radiologist" as Rad
+
+rectangle "VKIST MSK Workspace (FR-25)" {
+    usecase "Review Suggested Synovitis Grade (0-3)" as UC-47988
+    usecase "Expose Pixel-Level Activation Logic" as UC_Core
+    usecase "Isolate Visual Noise/Artifacts" as UC_Sub
+}
+
+Rad --> UC-47988
+UC-47988 <.. UC_Core : <<extend>> (If clinician contests AI score)
+UC_Core ..> UC_Sub : <<include>>
+@enduml
+
+
+```
+
+---
+
+## 11. UC-60739: Isolate Visual Noise/Artifacts
+
+### Notion Properties Input Panel
+```text
+* Name [Verb + Noun]: Isolate Visual Noise/Artifacts
+* Actor: Diagnostic Radiologist (Rad)
+* Goal: Provide manual brush and selection overlays to mask out acoustic shadows, bone scattering, or artifacts causing model calculation errors.
+* Interaction: User-to-System
+* Stimulus: Human operator activates canvas cleanup tools within the exposed model layer layout.
+* SysResponse: Real-time visual updates to the pixel mask array, isolating clean anatomical structures from surrounding imaging noise.
+* VerboseForm (Formula Reference View): "The use case 'Isolate Visual Noise/Artifacts' defines a User-to-System interaction where the Diagnostic Radiologist (Rad) aims to Provide manual brush and selection overlays to mask out acoustic shadows, bone scattering, or artifacts causing model calculation errors. This workflow is triggered when Human operator activates canvas cleanup tools within the exposed model layer layout, causing the system to respond by providing Real-time visual updates to the pixel mask array, isolating clean anatomical structures from surrounding imaging noise."
+
+```
+
+### Page Body Content (`SpecificationWithDiagram`)
+
+```markdown
+# Use Case Deep-Dive: Isolate Visual Noise/Artifacts
+
+## 1. Structural Preconditions & Postconditions
+* **Preconditions:**
+  * System exposure arrays are visible across the image viewport layout (`UC-25637`).
+* **Postconditions (Success State):**
+  * Corrected ground-truth frame masks are calculated and locked into memory.
+  * System updates local diagnostic metrics using the isolated anatomical data.
+
+---
+
+## 2. Interaction Scenarios (Step-by-Step Flow)
+
+### Main Success Scenario (Happy Path)
+1. **System** activates a manual canvas tool overlay, giving the user access to high-precision brush, eraser, and selection vectors.
+2. **Diagnostic Radiologist** applies brush vectors directly over areas containing acoustic artifacts or non-synovial structures that skewed the automated classification score.
+3. **System** recalculates active region dimensions in real time, excluding the masked pixels from the active grading parameters.
+4. **System** updates diagnostic panel displays to confirm the human-corrected measurements.
+5. **System** includes `UC-62864` to lock the updated session state securely.
+
+---
+
+## 3. PlantUML Visual Model
+```plantuml
+@startuml
+left to right direction
+skin rose
+
+actor "Diagnostic Radiologist" as Rad
+
+rectangle "VKIST MSK Workspace (FR-25)" {
+    usecase "Isolate Visual Noise/Artifacts" as UC_Core
+    usecase "Commit Validated Ground-Truth Record" as UC_Sub
+}
+
+Rad --> UC_Core : Tag artifacts
+UC_Core ..> UC_Sub : <<include>>
+@enduml
+
+```
+
+
+
+---
+
+## 12. UC-62864: Commit Validated Ground-Truth Record
+
+### Notion Properties Input Panel
+```text
+* Name [Verb + Noun]: Commit Validated Ground-Truth Record
+* Actor: Hospital EMR System (EMR)
+* Goal: Secure the human-corrected ground-truth dataset variant while appending clean, expert-validated report payloads to the EMR.
+* Interaction: System-to-System
+* Stimulus: Completion of manual artifact masking operations and confirmation of corrected metrics.
+* SysResponse: Stores the corrected medical report in the EMR and saves the isolated image mask to an optimization cache for subsequent retraining.
+* VerboseForm (Formula Reference View): "The use case 'Commit Validated Ground-Truth Record' defines a System-to-System interaction where the Hospital EMR System (EMR) aims to Secure the human-corrected ground-truth dataset variant while appending clean, expert-validated report payloads to the EMR. This workflow is triggered when Completion of manual artifact masking operations and confirmation of corrected metrics, causing the system to respond by providing Stores the corrected medical report in the EMR and saves the isolated image mask to an optimization cache for subsequent retraining."
+
+```
+
+### Page Body Content (`SpecificationWithDiagram`)
+
+```markdown
+# Use Case Deep-Dive: Commit Validated Ground-Truth Record
+
+## 1. Structural Preconditions & Postconditions
+* **Preconditions:**
+  * Human-directed canvas modification steps are locked in place without remaining pixel parity errors (`UC-60739`).
+* **Postconditions (Success State):**
+  * EMR database updates receive the human expert's diagnostic findings.
+  * Isolated ground-truth tensor pairs are safely cached for AI training refinement runs.
+
+---
+
+## 2. Interaction Scenarios (Step-by-Step Flow)
+
+### Main Success Scenario (Happy Path)
+1. **System** packages the human expert's corrected diagnostic data metrics into the primary transmission bundle.
+2. **System** isolates the human-brushed image mask layers alongside the initial incorrect model classification output.
+3. **System** tags the data pair as a validated retraining asset (`GROUND_TRUTH_OVERRIDE`).
+4. **System** saves the optimization asset to a secure local retraining storage folder, while preparing the primary medical report for delivery to the **Hospital EMR System**.
+
+---
+
+## 3. PlantUML Visual Model
+```plantuml
+@startuml
+left to right direction
+skin rose
+
+actor "Hospital EMR System" as EMR << System >>
+
+rectangle "VKIST MSK Workspace (FR-25)" {
+    usecase "Commit Validated Ground-Truth Record" as UC_Core
+}
+
+UC_Core ..> EMR : (Prepares clean report for EMR sync)
+@enduml
+
+```
+
+---
+
+# PART 5: Quadrant 4 — Double Blind Failure Loops (AI Faulty / Doctor Biased)
+
+## 13. UC-35956: Activate Clinical Investigation Mode
+
+### Notion Properties Input Panel
+```text
+* Name [Verb + Noun]: Activate Clinical Investigation Mode
+* Actor: Diagnostic Radiologist (Rad)
+* Goal: Switch the system into a strict, template-driven manual examination mode when low vision confidence values align with a lack of reference data.
+* Interaction: User-to-System
+* Stimulus: The workspace detects a critical double-blind failure criteria match during the case evaluation phase.
+* SysResponse: Disables automated diagnostic suggestions entirely and forces a standardized manual morphology review.
+* VerboseForm (Formula Reference View): "The use case 'Activate Clinical Investigation Mode' defines a User-to-System interaction where the Diagnostic Radiologist (Rad) aims to Switch the system into a strict, template-driven manual examination mode when low vision confidence values align with a lack of reference data. This workflow is triggered when The workspace detects a critical double-blind failure criteria match during the case evaluation phase, causing the system to respond by providing Disables automated diagnostic suggestions entirely and forces a standardized manual morphology review."
+
+```
+
+### Page Body Content (`SpecificationWithDiagram`)
+
+```markdown
+# Use Case Deep-Dive: Activate Clinical Investigation Mode
+
+## 1. Structural Preconditions & Postconditions
+* **Preconditions:**
+  * System classification loops return low-confidence indices.
+  * Authoritative RAG reference lookups return no matches, indicating an unmapped anatomical variant or a severe image anomaly.
+* **Postconditions (Success State):**
+  * Automated suggestions are masked out to prevent cognitive bias.
+  * Mandatory manual template verification frameworks are deployed into active workspace view.
+
+---
+
+## 2. Interaction Scenarios (Step-by-Step Flow)
+
+### Main Success Scenario (Happy Path)
+1. **System** monitors deep-learning inference score bounds during case evaluation.
+2. **System** runs background reference data lookups and catches a dual failure state (Low confidence + Empty knowledge reference).
+3. **System** drops the standard review interface layout to prevent automated suggestion bias or human misinterpretation loops.
+4. **System** changes UI display focus markers to activate an explicit, template-driven investigation layout.
+5. **System** includes `UC-47796` to force manual measurement entries.
+
+---
+
+## 3. PlantUML Visual Model
+```plantuml
+@startuml
+left to right direction
+skin rose
+
+actor "Diagnostic Radiologist" as Rad
+
+rectangle "VKIST MSK Workspace (FR-25)" {
+    usecase "Review Suggested Synovitis Grade (0-3)" as UC-47988
+    usecase "Activate Clinical Investigation Mode" as UC_Core
+    usecase "Execute Structured Morphology Annotation" as UC_Sub
+}
+
+Rad --> UC-47988
+UC-47988 <.. UC_Core : <<extend>> (If low confidence & empty RAG)
+UC_Core ..> UC_Sub : <<include>>
+@enduml
+
+```
+
+
+---
+
+## 14. UC-47796: Execute Structured Morphology Annotation
+
+### Notion Properties Input Panel
+```text
+* Name [Verb + Noun]: Execute Structured Morphology Annotation
+* Actor: Diagnostic Radiologist (Rad)
+* Goal: Force the manual plotting of anatomical coordinates and morphological anomalies using a strict, un-biased framework.
+* Interaction: User-to-System
+* Stimulus: The workspace forces a manual review layout via the active escalation workflow step.
+* SysResponse: Interactive coordinate plotting arrays and mandatory clinical documentation input boxes.
+* VerboseForm (Formula Reference View): "The use case 'Execute Structured Morphology Annotation' defines a User-to-System interaction where the Diagnostic Radiologist (Rad) aims to Force the manual plotting of anatomical coordinates and morphological anomalies using a strict, un-biased framework. This workflow is triggered when The workspace forces a manual review layout via the active escalation workflow step, causing the system to respond by providing Interactive coordinate plotting arrays and mandatory clinical documentation input boxes."
+
+```
+
+### Page Body Content (`SpecificationWithDiagram`)
+
+```markdown
+# Use Case Deep-Dive: Execute Structured Morphology Annotation
+
+## 1. Structural Preconditions & Postconditions
+* **Preconditions:**
+  * System UI layer has transitioned to manual investigation mode parameters (`UC-35956`).
+* **Postconditions (Success State):**
+  * Specialist successfully plots manual structural bounds.
+  * Text verification parameters capture explicit clinical observations.
+
+---
+
+## 2. Interaction Scenarios (Step-by-Step Flow)
+
+### Main Success Scenario (Happy Path)
+1. **System** displays an empty, un-biased ultrasound canvas frame alongside a series of mandatory measurement fields.
+2. **Diagnostic Radiologist** plots coordinate points across the canvas layer to outline the boundaries of the anomalous tissue.
+3. **Diagnostic Radiologist** manually populates text fields describing structural observations (e.g., bone fragments or atypical lesion shapes).
+4. **System** compiles these manual coordinates and comments into a detailed case record.
+5. **System** includes `UC-01580` to route the data directly to optimization pipelines.
+
+---
+
+## 3. PlantUML Visual Model
+```plantuml
+@startuml
+left to right direction
+skin rose
+
+actor "Diagnostic Radiologist" as Rad
+
+rectangle "VKIST MSK Workspace (FR-25)" {
+    usecase "Execute Structured Morphology Annotation" as UC_Core
+    usecase "Serialize Session to Telemetry Queue" as UC_Sub
+}
+
+Rad --> UC_Core : Document manual findings
+UC_Core ..> UC_Sub : <<include>>
+@enduml
+
+```
+
+
+
+---
+
+## 15. UC-01580: Serialize Session to Telemetry Queue
+
+### Notion Properties Input Panel
+```text
+* Name [Verb + Noun]: Serialize Session to Telemetry Queue
+* Actor: Hospital EMR System (EMR)
+* Goal: Route anomalous case data directly to engineering telemetry streams while bypassing standard hospital records to protect clinical data pipes.
+* Interaction: System-to-System
+* Stimulus: Completion of manual morphology reporting arrays within the clinical investigation interface.
+* SysResponse: Packages unencrypted image tensors, coordinate arrays, and user text blocks directly into core product telemetry queues.
+* VerboseForm (Formula Reference View): "The use case 'Serialize Session to Telemetry Queue' defines a System-to-System interaction where the Hospital EMR System (EMR) aims to Route anomalous case data directly to engineering telemetry streams while bypassing standard hospital records to protect clinical data pipes. This workflow is triggered when Completion of manual morphology reporting arrays within the clinical investigation interface, causing the system to respond by providing Packages unencrypted image tensors, coordinate arrays, and user text blocks directly into core product telemetry queues."
+
+```
+
+### Page Body Content (`SpecificationWithDiagram`)
+
+```markdown
+# Use Case Deep-Dive: Serialize Session to Telemetry Queue
+
+## 1. Structural Preconditions & Postconditions
+* **Preconditions:**
+  * Manual morphology plotting and clinical documentation inputs are finalized (`UC-47796`).
+* **Postconditions (Success State):**
+  * Case files containing structural anomalies bypass standard EMR storage pathways.
+  * Raw image tensors are queued in engineering streams to expand future model capabilities.
+
+---
+
+## 2. Interaction Scenarios (Step-by-Step Flow)
+
+### Main Success Scenario (Happy Path)
+1. **System** identifies the active session as an anomalous anomaly case during final compilation.
+2. **System** aggregates raw frame tensors, manual coordinate indices, and user-entered clinical commentary blocks into a secure telemetry archive package.
+3. **System** bypasses standard EMR production database pipelines to protect standard hospital operational data.
+4. **System** routes the telemetry package directly to the product engineering data pipeline for system optimization and future model training runs.
+
+---
+
+## 3. PlantUML Visual Model
+```plantuml
+@startuml
+left to right direction
+skin rose
+
+actor "Hospital EMR System" as EMR << System >>
+
+rectangle "VKIST MSK Workspace (FR-25)" {
+    usecase "Serialize Session to Telemetry Queue" as UC_Core
+}
+
+UC_Core ..> EMR : (Bypasses standard production EMR sync)
+@enduml
+
+```
+
+---
+

proj_level_reading/Requirement_Analysis/UC_Design/FR_25_UC_DESIGN/Q1 True Agreement (AI Correct Doctor Correct) 378f910aea758007a841f20e57da0f0d.md

@@ -0,0 +1,59 @@
+# Q1: True Agreement
+(AI Correct / Doctor Correct)
+
+Layered Three-Tier ML Stack Performance Impact (Your Proposed Design): Explainable Baseline Sync: The VKIST Grader computes the numerical matrices & the GradCAM. The LLM Explainer parses the raw segmentation parameters  + GradCAM and automatically generates an interactive diagnostic draft chat panel & LLM based on the GradCAM + RAG-knowledge  + the raw-ultrasound to explain the VKIST-grader. The RAG-Referee confirms zero clinical guidelines variance, and logs a high-trust concur structural block.  <note both LLM have to record back the Chain-of-Though for explain why the LLM’s agree & allow the result)
+
+```jsx
+@startuml
+' Settings
+left to right direction
+skin rose
+
+' Actors
+actor "Diagnostic Radiologist (UP5)" as Rad
+actor "Hospital EMR System" as EMR << System >>
+
+' System Boundary
+rectangle "VKIST MSK Workspace - Q1: True Agreement Flow" {
+    
+    usecase "Ingest Diagnostic Ultrasound" as UC-48376
+    
+    rectangle "Pipeline: Vision & Reasoning" {
+        usecase "Compute Matrices & GradCAM (VKIST Grader)" as UC_Vision
+        usecase "Parse Features & Draft Explanation (LLM Explainer)" as UC_Explain
+        usecase "Log Chain-of-Thought (CoT)" as UC_CoT
+    }
+    
+    rectangle "Audit: RAG-Referee" {
+        usecase "Verify Clinical Guideline Alignment" as UC_Referee
+        usecase "Cache Concurrence Structural Block" as UC_Log
+    }
+    
+    rectangle "Clinical Finalization" {
+        usecase "Review & Confirm Diagnosis" as UC-47988
+        usecase "Sign & Commit Record" as UC-92006
+    }
+    
+    usecase "Synchronize EMR Ledger" as UC_Sync
+}
+
+' Interaction Paths
+Rad --> UC-48376
+UC-48376 ..> UC_Vision : <<include>>
+UC_Vision --> UC_Explain : Provide Tensors & GradCAM
+UC_Explain ..> UC_CoT : <<include>> (Persist Reasoning Path)
+
+' Independent Verification Gate
+UC_Explain ..> UC_Referee : <<include>>
+UC_Referee ..> UC_Log : <<include>> (High-Trust Block)
+
+' Final User Confirmation
+Rad --> UC-47988
+UC_Log --> UC-47988 : Show "High-Trust Concurrence"
+Rad --> UC-92006
+UC-92006 ..> UC_Sync : <<include>>
+UC_Sync --> EMR : POST Validated JSON Record
+@enduml
+```
+
+![image.png](Q1%20True%20Agreement%20(AI%20Correct%20Doctor%20Correct)/image.png)

proj_level_reading/Requirement_Analysis/UC_Design/FR_25_UC_DESIGN/Q2 Automation Override Risk (AI Correct Doctor Ove 378f910aea75808cb7e5eda9f0b0b89c.md

@@ -0,0 +1,67 @@
+# Q2: Automation Override Risk
+(AI Correct / Doctor Oversights / Confuse)
+
+Layered Three-Tier ML Stack Performance Impact (Your Proposed Design): The Conversational Circuit Breaker triggers when a clinician disagrees / confuse / uncertain with the system's diagnostic grade, halting the workflow to launch an interactive Socratic dialogue that bridges the gap between human intuition and machine inference. In this mode, the system (LLM-explainer) shall synthesize raw VKIST-ML vision tensors, GradCAM activation heatmaps, and evidence retrieved via RAG into a collaborative analysis session, forcing the clinician to articulate their reasoning against the machine's spatial and vascular observations. To ensure diagnostic integrity, a BERT-based hallucination detector continuously monitors the chat for semantic drift or illogical premises; if the conversation reaches an impasse or the system detects potential contextual hallucination, the RAG-Referee intervenes as an unbiased arbiter. This referee bypasses the conversational history to provide definitive, evidence-based source material from clinical guidelines (such as ESSR) directly tied to the raw imaging metrics, resolving the ambiguity through objective, verifiable medical evidence rather than subjective negotiation.
+
+```jsx
+@startuml
+skinparam linetype polyline
+skinparam packageStyle rectangle
+skinparam rectangle {
+    BackgroundColor #fefefe
+    BorderColor #555555
+}
+
+' Actors
+actor "Radiologist (UP5)" as Rad
+actor "Internal Consultor (LLM Chat)" as Cons <<System>>
+actor "Hospital EMR" as EMR <<System>>
+
+rectangle "VKIST MSK Workspace - Q2 Architecture" {
+    
+    usecase "Trigger Circuit Breaker Panel" as UC2_Trigger
+    
+    rectangle "Socratic Workspace UI Panel" {
+        usecase "Lock Main Diagnostic Flow" as UC2_Halt
+        usecase "Engage in Socratic Discussion" as UC2_Socratic
+        usecase "Display Visual GradCAM Overlay" as UC2_Synth
+    }
+    
+    rectangle "Verification & Arbitration Kernel" {
+        usecase "Audit Chat Token Drift (BERT)" as UC2_BERT
+        usecase "Execute RAG-Referee Check" as UC2_Referee
+        usecase "Query Immutable Guideline Base" as UC2_RAG_Fetch
+    }
+    
+    rectangle "Clinical Resolution Gate" {
+        usecase "Review Referee Verdict Card" as UC2_Review
+        usecase "Commit Signed Diagnosis" as UC2_Finalize
+    }
+    
+    usecase "EMR Ledger Sync" as UC2_Sync
+}
+
+' Core Interaction Flow
+Rad --> UC2_Trigger : Disagreement/Uncertainty
+UC2_Trigger ..> UC2_Halt : <<include>>
+UC2_Halt ..> UC2_Synth : <<include>>
+
+' Dynamic Chat Loop between Doctor and Internal Consultor LLM
+Rad --> UC2_Socratic
+Cons --> UC2_Socratic : Drive Pathologic Inquiry Dialogue
+
+' Asynchronous Automated Verification Channel
+UC2_Socratic ..> UC2_BERT : Stream Conversation Tokens
+UC2_BERT ..> UC2_Referee : <<extend>> (Triggered on Impasse / Chat Hallucination)
+UC2_Referee ..> UC2_RAG_Fetch : <<include>>
+UC2_RAG_Fetch ..> UC2_Review : Inject Ground-Truth Evidence
+
+' Finalization Steps
+Rad --> UC2_Review
+Rad --> UC2_Finalize
+UC2_Finalize ..> UC2_Sync : <<include>>
+UC2_Sync --> EMR : POST Validated JSON Payload
+@enduml
+```
+
+![image.png](Q2%20Automation%20Override%20Risk%20(AI%20Correct%20Doctor%20Ove/image.png)

proj_level_reading/Requirement_Analysis/UC_Design/FR_25_UC_DESIGN/Q3 Clinician Subservience Risk (AI Hallucinates Do 378f910aea7580f8afb1c708eaf53e15.md

@@ -0,0 +1,69 @@
+# Q3: Clinician Subservience Risk
+(AI Hallucinates / Doctor Correct)
+
+Layered Three-Tier ML Stack Performance Impact (Your Proposed Design): The Objective Critic Loop initiates when a clinician contests an automated diagnostic grade, triggering an interactive Socratic consultation that bridges human intuition with machine inference via the VKIST-ML vision stack. During this loop, the LLM Explainer renders a GradCAM-anchored reasoning draft that visualizes the specific pixel-level feature activation logic, enabling the clinician to identify and isolate artifacts—such as motion tremors—that may have induced a system hallucination. To ensure diagnostic integrity, a BERT-based detector continuously monitors the dialogue for semantic drift, and if the interaction reaches an impasse or context hallucination is detected, the RAG-Referee intervenes as an unbiased, independent arbiter. By cross-verifying the clinician’s assertion and the model’s reasoning against raw imaging tensors and immutable, source-cited clinical guidelines (e.g., ESSR/OMERACT standards), the Referee resolves diagnostic ambiguity with objective evidence, ultimately committing the validated session as an annotated ground-truth record for targeted system reinforcement.
+
+```jsx
+@startuml
+' Layout optimizations to secure compact rendering and prevent image fragmentation
+skinparam linetype polyline
+skinparam packageStyle rectangle
+skinparam rectangle {
+    BackgroundColor #fefefe
+    BorderColor #555555
+}
+
+' Actors strictly mapped to match your canonical architectural definitions
+actor "Radiologist (UP5)" as Rad
+actor "Internal Consultor (LLM Chat)" as Cons <<System>>
+actor "System Maintainer" as Maint <<System>>
+
+rectangle "VKIST MSK Workspace - Q4 Architecture" {
+    
+    usecase "Evaluate Epistemic Uncertainty Gate" as UC4_Trigger
+    
+    rectangle "Socratic Workspace UI Panel" {
+        usecase "Shift to Clinical Investigation Mode" as UC4_Halt
+        usecase "Engage in Socratic Discussion" as UC4_Socratic
+        usecase "Render Manual Checklist Canvas" as UC4_Synth
+    }
+    
+    rectangle "Verification & Arbitration Kernel" {
+        usecase "Audit Chat Token Drift (BERT)" as UC4_BERT
+        usecase "Execute RAG-Referee Check" as UC4_Referee
+        usecase "Return Null-Match Signal" as UC4_RAG_Fetch
+    }
+    
+    rectangle "Clinical Resolution Gate" {
+        usecase "Document Novel Morphological Features" as UC4_Review
+        usecase "Authorize Serialized Anomaly Package" as UC4_Finalize
+    }
+    
+    usecase "Asynchronous Telemetry Queue Sync" as UC4_Sync
+}
+
+' Initial Data Intake and Uncertainty Routing Paths
+Rad --> UC4_Trigger : Feed OOD Image Tensors
+UC4_Trigger ..> UC4_RAG_Fetch : <<include>> (Triggers Empty Vector Result)
+UC4_RAG_Fetch ..> UC4_Halt : <<extend>> (On Zero-Match Guidelines + Low Conf Tensors)
+UC4_Halt ..> UC4_Synth : <<include>>
+
+' Direct Socratic Analysis Run-time Workspace
+Rad --> UC4_Socratic
+Cons --> UC4_Socratic : Drive Exploratory Morphology Dialogue
+
+' Live Guardrail and Exception Evaluation Paths
+UC4_Socratic ..> UC4_BERT : Stream Conversation Tokens
+UC4_BERT ..> UC4_Referee : <<include>> (Validates Logical Framing Stability)
+
+' Manual Audit, Documenting Anomaly and Consent Finalization
+Rad --> UC4_Review : Acknowledge Guideline Limitation
+Rad --> UC4_Finalize : Provide Native Opt-In Telemetry Consent
+
+' Async Data Serialization Sink to System Maintainer Ledger
+UC4_Finalize ..> UC4_Sync : <<include>>
+UC4_Sync --> Maint : POST Encrypted Tensors & Logs for Model Retraining
+@enduml
+```
+
+![image.png](Q3%20Clinician%20Subservience%20Risk%20(AI%20Hallucinates%20Do/image.png)

proj_level_reading/Requirement_Analysis/UC_Design/FR_25_UC_DESIGN/Q4 Double Blind Failure dues to edge-case (AI Faul 378f910aea7580618972f1583ab0e96b.md

@@ -0,0 +1,69 @@
+# Q4: Double Blind Failure dues to edge-case
+(AI Faulty / Doctor Biased)
+
+Layered Three-Tier ML Stack Performance Impact (Your Proposed Design): Anomaly Escalation Protocol: In instances where both the diagnostic system and the clinician encounter an edge-case—or "unknown-unknown"—that lacks precedent in the current RAG knowledge base, the system initiates the Anomaly Escalation Protocol. The LLM Explainer detects this "epistemic uncertainty" (via low vision-stack confidence and empty RAG retrieval results) and shifts the interface from "Diagnostic Support" to "Clinical Investigation Mode." Instead of attempting to force a Grade-based diagnosis, the Internal Consultor guides the clinician to document the unique morphological features through a structured annotation protocol, facilitating a Socratic investigation into the anomaly. The system transparently acknowledges the limitation, explicitly stating that current clinical guidelines do not cover this specific presentation, and prompts the clinician to manually document findings. With the clinician’s consent, the workspace commits this session as a "Novel Research Case," automatically serializing the raw imaging tensors, clinician observations, and artifact logs to a secure telemetry queue, flagging the data for system maintainers to perform targeted model retraining and protocol refinement.
+
+```jsx
+@startuml
+' Layout optimizations to secure compact rendering and prevent image fragmentation
+skinparam linetype polyline
+skinparam packageStyle rectangle
+skinparam rectangle {
+    BackgroundColor #fefefe
+    BorderColor #555555
+}
+
+' Actors strictly mapped to match your canonical architectural definitions
+actor "Radiologist (UP5)" as Rad
+actor "Internal Consultor (LLM Chat)" as Cons <<System>>
+actor "System Maintainer" as Maint <<System>>
+
+rectangle "VKIST MSK Workspace - Q4 Architecture" {
+    
+    usecase "Evaluate Epistemic Uncertainty Gate" as UC4_Trigger
+    
+    rectangle "Socratic Workspace UI Panel" {
+        usecase "Shift to Clinical Investigation Mode" as UC4_Halt
+        usecase "Engage in Socratic Discussion" as UC4_Socratic
+        usecase "Render Manual Checklist Canvas" as UC4_Synth
+    }
+    
+    rectangle "Verification & Arbitration Kernel" {
+        usecase "Audit Chat Token Drift (BERT)" as UC4_BERT
+        usecase "Execute RAG-Referee Check" as UC4_Referee
+        usecase "Return Null-Match Signal" as UC4_RAG_Fetch
+    }
+    
+    rectangle "Clinical Resolution Gate" {
+        usecase "Document Novel Morphological Features" as UC4_Review
+        usecase "Authorize Serialized Anomaly Package" as UC4_Finalize
+    }
+    
+    usecase "Asynchronous Telemetry Queue Sync" as UC4_Sync
+}
+
+' Initial Data Intake and Uncertainty Routing Paths
+Rad --> UC4_Trigger : Feed OOD Image Tensors
+UC4_Trigger ..> UC4_RAG_Fetch : <<include>> (Triggers Empty Vector Result)
+UC4_RAG_Fetch ..> UC4_Halt : <<extend>> (On Zero-Match Guidelines + Low Conf Tensors)
+UC4_Halt ..> UC4_Synth : <<include>>
+
+' Direct Socratic Analysis Run-time Workspace
+Rad --> UC4_Socratic
+Cons --> UC4_Socratic : Drive Exploratory Morphology Dialogue
+
+' Live Guardrail and Exception Evaluation Paths
+UC4_Socratic ..> UC4_BERT : Stream Conversation Tokens
+UC4_BERT ..> UC4_Referee : <<include>> (Validates Logical Framing Stability)
+
+' Manual Audit, Documenting Anomaly and Consent Finalization
+Rad --> UC4_Review : Acknowledge Guideline Limitation
+Rad --> UC4_Finalize : Provide Native Opt-In Telemetry Consent
+
+' Async Data Serialization Sink to System Maintainer Ledger
+UC4_Finalize ..> UC4_Sync : <<include>>
+UC4_Sync --> Maint : POST Encrypted Tensors & Logs for Model Retraining
+@enduml
+```
+
+![image.png](Q4%20Double%20Blind%20Failure%20dues%20to%20edge-case%20(AI%20Faul/image.png)

proj_level_reading/Requirement_Analysis/UC_Design/FR_25_UC_DESIGN/UC_CONTEXT.md

@@ -0,0 +1,282 @@
+# CONTEXT.md for the Usecase Discovery : FR-25
+
+- The requirement: FR-25 == ULTS-Đánh giá và phân cấp mức độ viêm màng hoạt dịch (Synovitis Grading)
+
+- Explain why the se should care on this usecase in the design process
+    - **The Gap:** Lợi ích kỹ thuật & Giá trị cốt lõi của Use Case Phân cấp Viêm màng hoạt dịch đối với Kiến trúc Phần mềm (Missing Clinical rationale vs. Engineering value optimization for Synovitis Grading).
+    - **The Question:** Tại sao quy trình lâm sàng chuẩn hóa này lại đảm bảo tính chính xác khi phân cấp (`Synovitis Grading`) và tại sao một Kỹ sư Phần mềm (SE) phải đặc biệt quan tâm đến Use Case này khi thiết kế sản phẩm?
+    - **The Hint:** Để xây dựng một sản phẩm Y tế (Healthcare AI Product) thành công, chúng ta không được coi Use Case này chỉ là một tính năng CRUD hay hiển thị ảnh đơn thuần. Hiểu rõ bản chất toán học/vật lý của quy trình giúp SE thiết kế cơ chế lưu trữ dữ liệu (Data Schema), cấu hình Pipeline xử lý ảnh AI và tối ưu hóa trải nghiệm UIX không bị lỗi logic giải phẫu.
+    - **The Recommendations:** Dưới đây là câu trả lời phân tích sâu dưới góc nhìn của một Kỹ sư Hệ thống / Lập trình viên:
+    
+    ### PHẦN 1: Tại sao quy trình này đảm bảo việc phát hiện và phân cấp chính xác? (Góc nhìn Data Pipeline & Signal Processing)
+    
+    Nếu coi cơ thể người là một hệ thống phần cứng và máy siêu âm là một module quét dữ liệu ngoại vi (Hardware Scanner), quy trình 6 bước lâm sàng chính là các điều kiện tiền đề để **đảm bảo tính toàn vẹn của tín hiệu (Signal Integrity)** và ngăn chặn **nhiễu dữ liệu (Data Corruption)**:
+    
+    1. **Khử nhiễu biên (Eliminating Boundary Noise - Bước 1):** việc gập đầu gối 20°–30° tương đương với việc thực hiện lệnh `Format / Standardize` bề mặt quét. Nó triệt tiêu hiện tượng *Bất đẳng hướng âm học (Acoustic Anisotropy)* – vốn là một dạng nhiễu tín hiệu vật lý khiến mô khỏe mạnh bị biến đổi thành các pixel đen giả lập tổn thương.
+    2. **Cố định Hệ tọa độ (Fixing Coordinate System - Bước 2):** Đặt đầu dò dọc (`Longitudinal`) giúp mô hình AI thu được một contract dữ liệu ảnh tĩnh có cấu trúc giải phẫu phân tầng rõ ràng (`Multi-layered Frame`). Đỉnh xương bánh chè hoạt động như một điểm mốc $X, Y = (0,0)$ cố định để hệ thống chạy Edge Detection chuẩn xác.
+    3. **Phân tích Đa luồng song song (Multi-threading Analytics - Bước 3 & 4):**
+        - **Luồng B-Mode (Cấu trúc Hình học):** Trích xuất độ dày mô (`float thickness_mm`) $\rightarrow$ Phản ánh dung lượng thiệt hại vật lý tĩnh (Structural Damage).
+        - **Luồng Power Doppler (Lưu lượng Biến động):** Trích xuất mật độ màu của dòng máu (`float vascular_percentage`) $\rightarrow$ Phản ánh lưu lượng dữ liệu thời gian thực đang chạy (Active Inflammation).
+    4. **Tránh lỗi nén hệ thống (Avoiding Signal Throttling):** Việc lướt nhẹ tay đầu dò (minimal pressure) giữ cho luồng truyền dẫn tín hiệu mạch máu không bị bóp nghẹt (Throttling), tránh việc hệ thống tính toán sai lệch điểm số hoạt tử/viêm mạch dẫn đến kết quả âm tính giả.
+    
+    ### PHẦN 2: Tại sao Kỹ sư Phần mềm (SE) phải đặc biệt quan tâm đến Use Case này?
+    
+    Từ góc nhìn sản phẩm và kiến trúc hệ thống của dự án `VKIST_ULTRASOUND`, đây không phải là một tính năng bổ sung, mà chính là **Core Core Business Logic (Lõi nghiệp vụ quyết định)** vì các lý do sau:
+    
+    ### 1. Định hình Data Model (Schema) cho toàn bộ hệ thống
+    
+    Nếu không hiểu quy trình này, bạn sẽ thiết kế cơ sở dữ liệu bị thiếu trường dữ liệu nghiêm trọng. Điểm số `Synovitis Grade` không thể lưu dưới dạng một trường `int grade` đơn giản. Dữ liệu y khoa chuẩn hóa bắt buộc phải là một đối tượng phức hợp (Compound Object Model):
+    
+    JSON
+    
+    ```
+    {
+      "patient_id": "BN-10023",
+      "scan_metadata": {
+        "joint": "KNEE",
+        "side": "RIGHT",
+        "plane": "suprapat-long",
+        "patient_flexion_degree": 25
+      },
+      "extracted_metrics": {
+        "synovial_thickness_mm": 4.2,
+        "power_doppler_area_percentage": 34.5
+      },
+      "severity_classification": {
+        "suggested_grade": 2,
+        "confirmed_grade": 2,
+        "is_overridden_by_doctor": false
+      }
+    }
+    ```
+    
+    ### 2. Kích hoạt State Machine & Pipeline xử lý của AI (Mô tả trong tài liệu VKIST)
+    
+    Theo tài liệu kiến trúc của hệ thống, Use Case này là điểm kết thúc (`Final Destination`) của một Pipeline phân nhánh phức tạp. Khi ảnh DICOM/Siêu âm được đẩy lên hệ thống:
+    
+    - **Mô hình 1 (ConvNeXt):** Kiểm tra góc chụp. Nếu và chỉ nếu kết quả trả về đúng `sup_up_long`, hệ thống mới kích hoạt State tiếp theo.
+    - **Mô hình 2 (EfficientNet/MedViT):** Kiểm tra trạng thái phân loại nhị phân `Has Inflammation = True/False`.
+    - **Mô hình 3 (MedSAM/UNet):** Tiến hành phân đoạn vùng ảnh (Segmentation) tạo Mask đè màu để tính toán diện tích pixel bị tổn thương, từ đó tự động map ra điểm số Phân cấp từ 0 đến 3.
+        
+        Nếu Use Case này bị lỗi hoặc UIX thiết kế không khớp, toàn bộ Pipeline AI trị giá hàng nghìn giờ huấn luyện phía sau sẽ mất hoàn toàn giá trị sử dụng thực tế.
+        
+    
+    ### 3. Giải quyết bài toán Tải trọng hệ thống và Kiệt sức lâm sàng (Clinical Exhaustion)
+    
+    Tại các bệnh viện công tuyến trung ương của Việt Nam (Bạch Mai, Bệnh viện E), một bác sĩ (UP5) phải xử lý >100 ca/ca trực.
+    
+    - Nếu không có phần mềm: Bác sĩ phải đổi ghế, chuyển ứng dụng, gõ tay kết quả vào hệ thống EMR thủ công $\rightarrow$ Nút thắt cổ chai gây delay hệ thống (Latency).
+    - Khi có Use Case này được tự động hóa trên Dashboard: AI tính toán diện tích, trả về gợi ý bậc viêm ngay trên canvas xem ảnh, bác sĩ chỉ mất đúng 1 click chuột để xác nhận và Sync tự động sang Database tổng. Bạn đang giúp bệnh viện giảm thời gian xử lý một ca từ 5 phút xuống còn 30 giây, trực tiếp tối ưu hóa thông lượng (Throughput) cho toàn bộ hạ tầng y tế.
+    - **The Alignment Check:** Với góc nhìn bóc tách hệ thống và phân tích Pipeline tín hiệu/AI như trên, bạn đã thấy rõ được bài toán kiến trúc mình cần giải quyết ở Use Case này chưa, hay có điểm nào cần làm sáng tỏ thêm trước khi chúng ta vẽ sơ đồ Use Case bằng PlantUML?
+- Explain Why doctor are caring so much on this usecase
+    - **The Gap:** Hiểu rõ động lực lâm sàng và giá trị chẩn đoán thực tế của Bác sĩ (Missing Clinical Drivers and Real-World Diagnostic Insights for Synovitis Grading).
+    - **The Question:** Tại sao Bác sĩ Chẩn đoán hình ảnh (UP5) lại đặc biệt quan tâm đến Use Case Phân cấp Viêm màng hoạt dịch (`Synovitis Grading`), và chỉ số này tiết lộ điều gì cốt lõi trong hành trình chẩn đoán, điều trị của bệnh nhân?
+    - **The Hint:** Trong y khoa, bản thân hình ảnh siêu âm xám chỉ là dữ liệu thô (raw data). Kết quả phân cấp từ Use Case này chính là **thông tin có cấu trúc (structured insights)** giúp bác sĩ trả lời câu hỏi cốt lõi của lâm sàng: Bệnh nhân này đang bị tàn phá khớp ở mức độ nào, tổn thương này là mạn tính (sẹo mô) hay cấp tính (đang bùng phát), và phác đồ điều trị bằng thuốc hoặc can thiệp ngoại khoa nào là chính xác nhất.
+    - **The Recommendations:** Dưới đây là bóc tách chi tiết lý do vì sao bác sĩ cần Use Case này, được phân tích rõ ràng để một Kỹ sư Phần mềm nắm bắt trọn vẹn nghiệp vụ (Domain Knowledge):
+    
+    ### 1. Phân biệt Giữa "Tổn thương Cũ" (Mạn tính) và "Đợt Viêm Cấp" (Đang bùng phát)
+    
+    - **Ý nghĩa lâm sàng:** Khi nhìn vào ảnh siêu âm đen trắng (B-mode), bác sĩ thấy một vùng màng hoạt dịch dày lên (ví dụ: dày 4mm). Tuy nhiên, ảnh đen trắng đơn thuần **không thể** cho biết vùng phì đại đó là vết sẹo cũ từ 3 năm trước (mô xơ đã ổn định) hay là vùng mô đang liên tục sưng tấy, ăn mòn sụn khớp.
+    - **Use Case tiết lộ điều gì:** Bằng cách kết hợp luồng dữ liệu của **Power Doppler**, Use Case này bóc tách và định lượng chính xác mật độ mạch máu tăng sinh (`Hypervascularity`).
+        - *Dày mô + Không có tín hiệu Doppler (Grade 1):* Tổn thương cũ, chỉ cần theo dõi hoặc vật lý trị liệu.
+        - *Dày mô + Tín hiệu Doppler dày đặc (Grade 3):* Ổ viêm đang hoạt động cực kỳ dữ dội. Hệ thống miễn dịch của bệnh nhân đang tấn công nhầm vào chính các tế bào khớp gối, giải phóng hàng loạt enzyme ăn mòn sụn và xương. Bác sĩ cần phải can thiệp ngay lập tức bằng thuốc ức chế miễn dịch mạnh (như Corticoid hoặc DMARDs) để chặn đứng dòng thác phá hủy này.
+    
+    ### 2. Điểm Số Quyết Định Phác Đồ Điều Trị (Actionable Clinical Metric)
+    
+    Điểm số Phân cấp từ 0 đến 3 không phải là một cái tag hiển thị cho đẹp, nó hoạt động giống như một **luồng điều hướng logic (Decision Tree)** quyết định trực tiếp hành động lâm sàng của bác sĩ:
+    
+    - **Grade 0 (Bình thường):** Chuyển bệnh nhân sang chế độ phòng ngừa, xuất viện.
+    - **Grade 1 (Nhẹ):** Chỉ định điều trị nội khoa bảo tồn ở mức độ thấp (Dùng thuốc kháng viêm không Steroid - NSAIDs, thay đổi lối sống, tập vật lý trị liệu với bác sĩ PT - UP6).
+    - **Grade 2 (Vừa):** Cân nhắc tiêm thuốc nội khớp (tiêm Corticoid trực tiếp vào ngách khớp gối để dập dịch viêm tại chỗ) kết hợp điều trị thuốc đặc hiệu.
+    - **Grade 3 (Nặng/Nghiêm trọng):** Rút dịch khớp (Arthrocentesis) để giảm áp lực, chỉ định nhập viện điều trị tích cực, hoặc chuyển tuyến ngoại khoa để thực hiện phẫu thuật nội soi cắt màng hoạt dịch (Synovectomy) nhằm cứu lấy sụn khớp trước khi gối bị biến dạng hoàn toàn không thể phục hồi.
+    
+    ### 3. Thước Đo Khách Quan Để Đánh Giá Hiệu Quả Thuốc (Treatment Monitoring Dashboard)
+    
+    - **Nỗi đau của Bác sĩ:** Khi điều trị các bệnh tự miễn như Viêm khớp dạng thấp, bệnh nhân phải uống thuốc ròng rã nhiều tháng trời. Nếu bác sĩ chỉ hỏi bệnh nhân *"Bác có bớt đau không?"*, câu trả lời sẽ cực kỳ chủ quan và không chính xác (do ngưỡng chịu đau của mỗi người khác nhau và có hiệu ứng giả dược).
+    - **Use Case tiết lộ điều gì:** Use Case này cung cấp một **Standardized Baseline (Mốc chuẩn hóa)** để so sánh liên tục qua các mốc thời gian (Time-series Analysis).
+        - *Tháng 1:* Bệnh nhân đến khám $\rightarrow$ Hệ thống chấm **Grade 3** (Màng hoạt dịch dày 6mm, Doppler phủ 65% area).
+        - *Tháng 3 (Sau 2 tháng uống thuốc):* Bệnh nhân tái khám $\rightarrow$ Hệ thống chấm **Grade 1** (Màng hoạt dịch giảm còn 2.5mm, Doppler chỉ còn vài chấm cô lập).
+            
+            $\rightarrow$ Phần mềm tiết lộ cho bác sĩ một bằng chứng số liệu toán học tuyệt đối: **Phác đồ thuốc hiện tại đang hoạt động hiệu quả**, tiếp tục duy trì liều lượng. Ngược lại, nếu điểm số vẫn là Grade 3, hệ thống cảnh báo bác sĩ rằng bệnh nhân đang kháng thuốc, phải đổi sang loại thuốc sinh học đắt tiền hơn ngay lập tức.
+            
+    
+    ### 4. Triệt Tiêu Biến Thiên Giữa Các Bác Sĩ (Eradicating Inter-observer Variability)
+    
+    - **Thực trạng tại bệnh viện:** Việc phân cấp siêu âm thủ công phụ thuộc rất nhiều vào mắt nhìn chủ quan và kinh nghiệm của từng người. Bác sĩ A (15 năm kinh nghiệm) nhìn ảnh đoán là Grade 2, nhưng Bác sĩ B (mới ra trường 1 năm) lại chấm là Grade 3 vì thấy túi dịch có vẻ to. Sự lệch pha này gây nguy hiểm cho tính đồng nhất của phác đồ điều trị.
+    - **Use Case tiết lộ điều gì:** Khi có AI hỗ trợ trích xuất độ dày vùng ngách trên xương bánh chè (`suprapatellar recess`) và tính tỷ lệ pixel màu Doppler một cách tự động, hệ thống đóng vai trò như một **bộ kiểm tra điều kiện logic khách quan (Deterministic Gatekeeper)**. Nó đưa ra một mức điểm gợi ý dựa trên thuật toán tính toán diện tích chuẩn y khoa, giúp đồng bộ hóa chất lượng chẩn đoán tại bệnh viện. Bác sĩ dù già hay trẻ đều nhìn thấy một cơ sở số liệu minh bạch để đưa ra quyết định cuối cùng.
+    - **The Alignment Check:** Qua bóc tách dưới góc nhìn lâm sàng này, bạn đã hiểu vì sao kết quả đầu ra của Use Case này (`Grade 0-3`) lại đóng vai trò là "trái tim mạch máu" cho toàn bộ Dashboard điều trị phía sau chưa, hay bạn muốn chúng ta đào sâu thêm vào điểm nào trước khi thiết kế các tương tác UIX?
+- The System suggest what currently being missed from FR and need to define in the UC:
+    - **The Gap:** Ambiguous System & Actor Interaction Boundaries inside the Grading Workflow (Thiếu tường minh về ranh giới tương tác giữa Hệ thống và Bác sĩ).
+    - **The Question:** How exactly should the doctor **interact** with the system's automated AI calculation when adjusting or validating the suggested severity score (e.g., from Grade 2 to Grade 3)? - The answer of this
+        
+        The precise, clinically accurate baseline workflow executed by a Diagnostic Radiologist (UP5) consists of the following 6 sequential phases:
+        
+        - **Step 1 (Patient Posture Standardization):** The clinician places the patient in a supine position with the target knee supported by a bolster in **20°–30° of slight flexion**. This stretches the extensor mechanism (the **Quadriceps/Patellar Tendon)** and eliminates diagnostic tracking errors caused by acoustic anisotropy.
+            - Explain with simplification for Software Engineer
+                - **The Clinical Action:** The patient lies flat, knee bent exactly 20°–30° over a cushion.
+                - **The Software Engineer Analogy:** **Setting up consistent environment variables and running an initialization handshake.**
+                - **Deep Jargon Breakdown:**
+                    - **Extensor Mechanism - Quadriceps/Patellar Tendon:** Think of this as a mechanical rubber band system (quadriceps muscle → tendon →kneecap → shin bone). When the leg is completely straight, this system sags and wrinkles. Bending it 20°–30° stretches it taut, creating a flat, predictable surface line.
+                    - **Acoustic Anisotropy (The Crucial Hardware Bug):** This is a structural physical hardware limitation of ultrasound waves. If the sound beam hits a tendon at a perfect 90° right angle, it bounces back bright white (**Echoic**). If the probe tilts even 5° offline because the tendon is curved/sagging, the wave scatters sideways, and the tissue suddenly registers on-screen as pitch black (**Hypoechoic**), mimicking a fake fluid tear or inflammatory lesion.
+                - **Why this matters for your UI/Product Design:** This step is your raw input data sanity check. If the patient isn't positioned right, the ultrasound picture is filled with visual artifact bugs (garbage in, garbage out). Your system needs to know it is processing a standardized 20°–30° landscape view.
+        - **Step 2 (Longitudinal Probe Alignment):** The clinician positions a high-frequency linear transducer probe over the midline of the **suprapatellar recess** (sagittal plane), aligning the distal edge over the upper pole of the patella to capture the clear multi-layered layout of the quadriceps tendon.
+            - Explain with simplification for SE
+                - **The Clinical Action:** The linear probe is placed lengthwise right down the middle of the upper knee, overlapping the top edge of the kneecap.
+                - **The Software Engineer Analogy:** **Pointing your API client path to the exact parent database index to unpack a nested multi-layered object arrays.**
+                - **Deep Jargon Breakdown:**
+                    - **Suprapatellar Recess:** This is the precise target memory location—a pouch-like joint cavity hiding right above the kneecap (**Supra** = above, **Patella** = kneecap) underneath the deep tissue layers.
+                    - **Sagittal Plane:** A vertical front-to-back cross-section cut. If your application was a 3D video game engine, this is viewing the joint asset precisely from the orthogonal **Side View Viewport**, rather than looking from the front or top down.
+                - **Why this matters for your UI/Product Design:** This gives the system its coordinate system reference frame. In this view, your AI algorithm can run edge detection along standard anatomical landmarks, treating the top edge of the patella as a rock-solid structural zero-point anchor on a 2D canvas.
+        - **Step 3 (B-Mode Structural Metric Capture):** Using standard Grey Scale (B-mode), the radiologist identifies the hypoechoic tissue area resting between the *prefemoral fat pad* and the *suprapatellar fat pad*. They visually calculate the maximum vertical distance of joint capsule distension/thickening using the ultrasound console's physical calipers.
+            - Explain for SE
+                - **The Clinical Action:** The doctor switches to a black-and-white image, identifies the space between two fat patches, and hits two points on the console to calculate the space thickness.
+                - **The Software Engineer Analogy:** **Running a 2D Bounding Box Segmentation model to extract a quantitative `float` metric (distance in mm) between two fixed system nodes.**
+                - **Deep Jargon Breakdown:**
+                    - **B-Mode (Brightness Mode):** This is the baseline structural image format. It transforms reflected sound wave amplitudes into live pixel intensity map arrays (high reflection = white pixels; zero reflection/fluid fluid pools = dark black pixels).
+                    - **Hypoechoic Tissue Area:** Any region that absorbs or passes sound waves easily instead of reflecting them, rendering as a dark grey or black signal pool. Inflamed synovial tissue fluid sits in this category.
+                    - **Prefemoral & Suprapatellar Fat Pads:** These are your permanent upper and lower hardware guardrail markers. The suprapatellar pouch sits wedged right between them like an expandable buffer queue.
+                - **Why this matters for your UI/Product Design:** This is **REQ-RAD-02** in your requirement documentation. The doctor uses manual calipers to measure this space. Your product UI can introduce a digital bounding path box or automated point-to-point drawing tool overlay to automatically extract this distance variable, completely stripping away the manual console math step.
+        - **Step 4 (Power Doppler Vascularity Mapping):** The clinician activates the Power Doppler mode on the console, optimizing the wall filter and PRF settings. They carefully hover the probe with **minimal contact pressure** to avoid compressing low-velocity synovial capillaries, visually counting or calculating the percentage area occupied by active blood flow signals inside the suprapatellar landscape.
+            - Explain for SE
+                - **The Clinical Action:** The doctor switches on the color overlay feature, tweaks the sensitivity filters, and hovers the probe extremely lightly without pressing down into the skin.
+                - **The Software Engineer Analogy:** **Activating a live telemetry tracer module with a low-pass noise filter to map active server data traffic volume while avoiding an external physical choke/throttling event.**
+                - **Deep Jargon Breakdown:**
+                    - **Power Doppler Mode:** A specialized signal tracking sub-routine. Instead of mapping structural tissue borders, it tracks shifts in frequency caused by moving targets (red blood cells). It highlights these regions with bright, glowing color maps overlaid right on top of the black-and-white structural layer.
+                    - **Wall Filter & PRF (Pulse Repetition Frequency):** These are variable noise gates. If configured wrong, minor hand tremors will bleed into the visual feed as massive colored pixels (**Clutter Artifact Noise**).
+                    - synpvia Capillary Compression Edge Case: If the doctor applies heavy hand force, they manually flatten the tiny micro-blood vessels inside the knee. This physically blocks blood flow, wiping out the signal completely on screen and returning a false negative trace.
+                - **Why this matters for your UI/Product Design:** This maps directly to your **Hypervascularity parameter**. Your interface can assist by calculating the ratio of bright color pixels to the total area of the segmented pouch, converting a subjective visual guess into a precise numerical percentage readout.
+        - **Step 5 (Semi-Quantitative Grade Synthesis):** The clinician combines both structural metrics mentally against standard musculoskeletal classification tiers: - THE VKIST ML-Module current stop in here
+            - *Grade 0 (None):* Completely flat layers; no hypoechoic separation or vascular flow signals.
+            - *Grade 1 (Mild):* Thin hypoechoic line running parallel to the femoral bone path; single or minimal isolated vascular blood flow spots.
+            - *Grade 2 (Moderate):* Evident hypoechoic expansion pushing the fat pads apart, but lines remain flat; active vascular flow spots occupying less than 50% of the calculated synovial area.
+            - *Grade 3 (Severe):* Clear convex or distinct bulging capsule distortion extending outward; intense confluent flow signals covering more than 50% of the calculated synovial landscape.
+            - Explain for SE
+                - **The Clinical Action:** The doctor looks at both parameters (the pouch thickness + the active color blood flow maps) and maps them to a standard clinical severity tier level (0 to 3).
+                - **The Software Engineer Analogy:** **Evaluating raw aggregated metric values against a core business logic conditional switch block (`switch(severityGrade)`) to determine system status codes.**
+                - **Deep Tiers Demystified via Code Logic:**
+                    - **Grade 0 (Healthy Baseline):**
+                        
+                        ```jsx
+                        if (synovialThickness === 0 && hypervascularityScore === 0) return "Grade 0: Normal Space";
+                        ```
+                        
+                    - **Grade 1 (Mild Inflammation):** Space is filled with a thin, parallel line of tissue expansion; trace color dots show up.JavaScript
+                        
+                        ```
+                        if (synovialThickness > 0 && hypervascularityScore <= 0.10) return "Grade 1: Mild Distension";
+                        ```
+                        
+                    - **Grade 2 (Moderate Inflammation):** The tissue swells enough to visibly push the flanking fat pads apart, and the active blood flow color blocks cover up to half of the pouch container zone.JavaScript
+                        
+                        ```
+                        if (synoviumDistended === true && hypervascularityScore < 0.50) return "Grade 2: Moderate Pouch Deflection";
+                        ```
+                        
+                    - **Grade 3 (Severe Inflammation):** The pouch balloons into a curved, outward bulging geometric form; intense, connected color maps take over more than half of the space landscape.JavaScript
+                        
+                        ```
+                        if (capsuleShape === 'convex_bulge' || hypervascularityScore >= 0.50) return "Grade 3: Critical Structural Flare";
+                        ```
+                        
+        - **Step 6 (Manual Multi-Silo Transcription):** The clinician freezes the optimal reference frames on the hardware console, manually assigns a final severity index label, moves away from the ultrasound machine hardware screen to a desktop workstation PC, and types out the structural text variables into the hospital's Electronic Medical Record (EMR) text block.
+            - Explain for SE
+                - **The Clinical Action:** The doctor freezes the machine display screen, manually records a final tier index number, stands up, switches chairs to a secondary office computer, logs in, and re-types the exact observations by hand into a text window box.
+                - **The Software Engineer Analogy:** **A total lack of system database synchronization. Hand-copying raw log data variables from a separate terminal window and typing them line-by-line into a separate decoupled microservice application.**
+                - **Why this matters for your UI/Product Design:** This is the massive core workflow bottleneck. The goal of your upcoming workspace design is to build an interactive, unified web interface bridge. The AI processes the image data parameters natively, renders an automated classification tag proposal directly inside the primary viewing frame, and updates the shared patient record database with 0 manual transcript entries or physical context-switching loops.
+    - Additional - from the answer in the `Question` we can model the planUML code solution
+        
+        !image.png
+        
+        ```jsx
+        @startuml
+        ' Settings
+        left to right direction
+        skin rose
+        
+        ' Actors
+        actor "Diagnostic Radiologist (UP5)" as Rad
+        actor "Hospital EMR System" as EMR << System >>
+        actor "VKIST AI Pipeline" as AI << System >>
+        
+        ' System Boundary
+        rectangle "VKIST MSK Workspace - Synovitis Grading Engine" {
+            
+            ' Core Viewing & Extraction Use Cases
+            usecase "Load Patient Ultrasound Session" as UC-48376
+            usecase "Extract Joint Tissue Metrics" as UC_Extract
+            
+            ' AI Suggestion Processing
+            usecase "Compute Automated Severity Suggestion" as UC_AI_Compute
+            usecase "Display Suggestion Tag & Canvas Overlays" as UC_Display
+            
+            ' Clinician Interaction & Decision Loop
+            usecase "Review Suggested Synovitis Grade (0-3)" as UC-47988
+            usecase "Manually Override Severity Grade" as UC_Override
+            usecase "Sign & Finalize Diagnostic Conclusions" as UC-92006
+            
+            ' Data Sync Hand-off
+            usecase "Synchronize Patient Record" as UC_Sync
+        }
+        
+        ' Relationships & Flow Boundaries
+        Rad --> UC-48376
+        Rad --> UC-47988
+        Rad --> UC-92006
+        
+        ' AI Pipeline Interactions
+        UC-48376 ..> UC_Extract : <<include>>
+        UC_Extract --> AI : Transmit raw image streams
+        AI --> UC_AI_Compute : Process thickness & Doppler maps
+        UC_AI_Compute ..> UC_Display : <<include>>
+        
+        ' Review and Override Loop
+        UC_Display ..> UC-47988 : <<include>>
+        UC_Override .up.> UC-47988 : <<extend>> (If clinician disagrees with AI)
+        Rad --> UC_Override
+        
+        ' Finalization and Sync Hand-offs
+        UC-92006 ..> UC_Sync : <<include>>
+        UC_Sync --> EMR : Push standardized JSON structural data
+        @enduml
+        ```
+        
+    
+    → For the Synovist Grading the interaction between the clinician & system may occur 4 potential case: —> 4 possible interactions
+    
+    ```jsx
+    +-----------------------------------------------------------------------+
+    |                       HUMAN-AI CONCURRENT STATES                      |
+    +-----------------------------------+-----------------------------------+
+    |            QUADRANT 2             |            QUADRANT 1             |
+    |   Automation Override Risk        |          True Agreement           |
+    |                                   |                                   |
+    |   AI: Grade 3 (Accurate)          |   AI: Grade 2 (Accurate)          |
+    |   Human: Grade 1 (Oversight)      |   Human: Grade 2 (Confident)      |
+    |   Risk: Severe Disease Missed     |   Risk: None (Happy Path)         |
+    +-----------------------------------+-----------------------------------+
+    |            QUADRANT 4             |            QUADRANT 3             |
+    |       Double-Blind Failure        |    Clinician Subservience Risk    |
+    |                                   |                                   |
+    |   AI: Grade 2 (Boundary Error)    |   AI: Grade 3 (Hallucinated)      |
+    |   Human: Grade 1 (Biased Error)   |   Human: Grade 1 (Accurate)       |
+    |   Risk: Cascading System Error    |   Risk: Over-treatment Danger     |
+    +-----------------------------------+-----------------------------------+
+    ```
+    
+    THE ML-stack use in this scenarios: 
+    
+    - the grading ML-stack (VKIST-model) → always use (it’s the machine process on the raw-signal from device)
+    - the LLM Critic & Actor for acting as explainer on the results of the grading stack (de-blackbox) + conversation with the clinics for pathologic analysis <with RAG> + critic-suggestion  (this LLM shall have to loaded with SKILL / multi-agent system)
+    - the LLM-RAG-Referee for prevent bias & blindness of both-side (actor & grader & clinical)
+        
+        
+        | **Referee Role** | **Problem Solved** | **Mechanism** |
+        | --- | --- | --- |
+        | **1. Unbiased Arbiter** | **Conflict & Bias:** Prevents the LLM from hallucinating to match the clinician's incorrect bias (Confirmation Bias). | Operates as a **Session-State Arbiter**: It ignores conversation history and focuses purely on comparing the raw metrics (`GradCAM maps`, `Doppler indices`) against clinical definitions. |
+        | **2. Domain Guardian** | **Knowledge Obsolescence:**Prevents the system from using outdated medical standards (e.g., guidelines from 2020 instead of 2025). | Operates as a **Knowledge-Retrieval Guardian**: It triggers when the system detects high semantic entropy, fetching the *latest* approved academic guidelines to ensure all explanations remain clinically valid. |
+    
+    The Actor:
+    
+    - the UP-5 user working with the hardware
+    
+    4 scenarios can consider

proj_level_reading/Requirement_Analysis/UC_Design/FR_25_UC_DESIGN/update_uc_ids.py

@@ -0,0 +1,28 @@
+
+mapping = {
+    'UC_Load': 'UC-48376',
+    'UC_Review': 'UC-47988',
+    'UC_Finalize': 'UC-92006',
+    'UC_Q1_Explain': 'UC-25776',
+    'UC_Q1_Log': 'UC-02423',
+    'UC_Q2_Intercept': 'UC-22159',
+    'UC_Q2_Socratic': 'UC-55146',
+    'UC_Q2_BERT': 'UC-74821',
+    'UC_Q2_Arbiter': 'UC-65473',
+    'UC_Q3_Expose': 'UC-25637',
+    'UC_Q3_Isolate': 'UC-60739',
+    'UC_Q3_Commit': 'UC-62864',
+    'UC_Q4_Escalate': 'UC-35956',
+    'UC_Q4_Annotate': 'UC-47796',
+    'UC_Q4_Queue': 'UC-01580'
+}
+
+# file_path = '/Users/davestran/Downloads/vkist_internship/PILOT_PROJECT/Reading_docs/Requirement_Analysis/UC_Design/FR_25_UC_DESIGN/FR_25_UC_SPEC.md'
+# with open(file_path, 'r') as f:
+#     content = f.read()
+
+# for old, new in mapping.items():
+#     content = content.replace(old, new)
+
+# with open(file_path, 'w') as f:
+#     f.write(content)

proj_level_reading/User_Analysis/Policy_Analysis/how_to_commericalized_legalizing_healthcare_product/split.md

@@ -0,0 +1,510 @@
+<!-- image -->
+
+## Architectural design
+
+## Objectives
+
+The objective of this chapter is to introduce the concepts of software architecture and architectural design. When you have read the chapter, you will:
+
+- ■ understand why the architectural design of software is important;
+- ■ understand the decisions that have to be made about the system architecture during the architectural design process;
+- ■ have been introduced to the idea of architectural patterns, well-tried ways of organizing system architectures, which can be reused in system designs;
+- ■ know the architectural patterns that are often used in different types of application system, including transaction processing systems and language processing systems.
+
+## Contents
+
+- 6.1 Architectural design decisions
+- 6.2 Architectural views
+- 6.3 Architectural patterns
+- 6.4 Application architectures
+
+Architectural design is concerned with understanding how a system should be organized and designing the overall structure of that system. In the model of the software development process, as shown in Chapter 2, architectural design is the first stage in the software design process. It is the critical link between design and requirements engineering, as it identifies the main structural components in a system and the relationships between them. The output of the architectural design process is an architectural model that describes how the system is organized as a set of communicating components.
+
+In agile processes, it is generally accepted that an early stage of the development process  should  be  concerned  with  establishing  an  overall  system  architecture. Incremental development of architectures is not usually successful. While refactoring components in response to changes is usually relatively easy, refactoring a system architecture is likely to be expensive.
+
+To help you understand what I mean by system architecture, consider Figure 6.1. This shows an abstract model of the architecture for a packing robot system that shows the components that have to be developed. This robotic system can pack different kinds of object. It uses a vision component to pick out objects on a conveyor, identify the type of object, and select the right kind of packaging. The system then moves objects from the delivery conveyor to be packaged. It places packaged objects on another conveyor. The architectural model shows these components and the links between them.
+
+In practice, there is a significant overlap between the processes of requirements engineering and architectural design. Ideally, a system specification should not include any design information. This is unrealistic except for very small systems. Architectural decomposition is usually necessary to structure and organize the specification. Therefore, as part of the requirements engineering process, you might propose an abstract system architecture where you associate groups of system functions or features with large-scale components or sub-systems. You can then use this decomposition to discuss the requirements and features of the system with stakeholders.
+
+You can design software architectures at two levels of abstraction, which I call architecture in the small and architecture in the large :
+
+1. Architecture in the small is concerned with the architecture of individual programs. At this level, we are concerned with the way that an individual program is decomposed into components. This chapter is mostly concerned with program architectures.
+2. Architecture in the large is concerned with the architecture of complex enterprise systems that include other systems, programs, and program components. These enterprise systems are distributed over different computers, which may be owned and managed by different companies. I cover architecture in the large in Chapters 18 and 19, where I discuss distributed systems architectures.
+
+Figure 6.1 The architecture of a packing robot control system Software architecture is important because it affects the performance, robustness, distributability, and maintainability of a system (Bosch, 2000). As Bosch discusses, individual components implement the functional system requirements. The nonfunctional requirements depend on the system architecture-the way in which these components are organized and communicate. In many systems, non-functional requirements are also influenced by individual components, but there is no doubt that the architecture of the system is the dominant influence.
+
+<!-- image -->
+
+Bass et al. (2003) discuss three advantages of explicitly designing and documenting software architecture:
+
+1. Stakeholder communication The architecture is a high-level presentation of the system that may be used as a focus for discussion by a range of different stakeholders.
+2. System analysis Making the system architecture explicit at an early stage in the system development requires some analysis. Architectural design decisions have a profound effect on whether or not the system can meet critical requirements such as performance, reliability, and maintainability.
+3. Large-scale reuse A model of a system architecture is a compact, manageable description of how a system is organized and how the components interoperate. The system architecture is often the same for systems with similar requirements and so can support large-scale software reuse. As I explain in Chapter 16, it may be possible to develop product-line architectures where the same architecture is reused across a range of related systems.
+
+Hofmeister et al. (2000) propose that a software architecture can serve firstly as a design plan for the negotiation of system requirements, and secondly as a means of structuring discussions with clients, developers, and managers. They also suggest that it is an essential tool for complexity management. It hides details and allows the designers to focus on the key system abstractions.
+
+System architectures are often modeled using simple block diagrams, as in Figure 6.1. Each box in the diagram represents a component. Boxes within boxes indicate that the component has been decomposed to sub-components. Arrows mean that data and or control signals are passed from component to component in the direction of the arrows. Y ou can see many examples of this type of architectural model in Booch's software architecture catalog (Booch, 2009).
+
+Block diagrams present a high-level picture of the system structure, which people from different disciplines, who are involved in the system development process, can readily understand. However, in spite of their widespread use, Bass et al. (2003) dislike informal block diagrams for describing an architecture. They claim that these informal diagrams are poor architectural representations, as they show neither the type of the relationships among system components nor the components' externally visible properties.
+
+The apparent contradictions between practice and architectural theory arise because there are two ways in which an architectural model of a program is used:
+
+1. As  a  way  of  facilitating  discussion  about  the  system  design A  high-level architectural view of a system is useful for communication with system stakeholders and project planning because it is not cluttered with detail. Stakeholders can relate to it and understand an abstract view of the system. They can then discuss the system as a whole without being confused by detail. The architectural model identifies the key components that are to be developed so managers  can  start  assigning  people  to  plan  the  development  of  these systems.
+2. As a way of documenting an architecture that has been designed The aim here is to produce a complete system model that shows the different components in a system, their interfaces, and their connections. The argument for this is that such a detailed architectural description makes it easier to understand and evolve the system.
+
+Block diagrams are an appropriate way of describing the system architecture during the design process, as they are a good way of supporting communications between the people involved in the process. In many projects, these are often the only architectural documentation that exists. However, if the architecture of a system is to be thoroughly documented then it is better to use a notation with well-defined semantics for architectural description. However, as I discuss in Section 6.2, some people think that detailed documentation is neither useful, nor really worth the cost of its development.
+
+■
+
+## 6.1 Architectural design decisions
+
+Architectural design is a creative process where you design a system organization that will satisfy the functional and non-functional requirements of a system. Because it is a creative process, the activities within the process depend on the type of system being developed, the background and experience of the system architect, and the specific requirements for the system. It is therefore useful to think of architectural design as a series of decisions to be made rather than a sequence of activities.
+
+During the architectural design process, system architects have to make a number of  structural  decisions  that  profoundly  affect  the  system  and  its  development process. Based on their knowledge and experience, they have to consider the following fundamental questions about the system:
+
+1. Is there a generic application architecture that can act as a template for the system that is being designed?
+2. How will the system be distributed across a number of cores or processors?
+3. What architectural patterns or styles might be used?
+4. What will be the fundamental approach used to structure the system?
+5. How will the structural components in the system be decomposed into subcomponents?
+6. What strategy will be used to control the operation of the components in the system?
+7. What architectural organization is best for delivering the non-functional requirements of the system?
+8. How will the architectural design be evaluated?
+9. How should the architecture of the system be documented?
+
+Although  each  software  system  is  unique,  systems  in  the  same  application domain often have similar architectures that reflect the fundamental concepts of the domain. For example, application product lines are applications that are built around a core architecture with variants that satisfy specific customer requirements. When designing a system architecture, you have to decide what your system and broader application classes have in common, and decide how much knowledge from these application architectures you can reuse. I discuss generic application architectures in Section 6.4 and application product lines in Chapter 16.
+
+For embedded systems and systems designed for personal computers, there is usually only a single processor and you will not have to design a distributed architecture for the system. However, most large systems are now distributed systems in which the system software is distributed across many different computers. The choice of distribution architecture is a key decision that affects the performance and reliability of the system. This is a major topic in its own right and I cover it separately in Chapter 18.
+
+The architecture of a software system may be based on a particular architectural pattern or style. An architectural pattern is a description of a system organization (Garlan and Shaw, 1993), such as a client-server organization or a layered architecture. Architectural patterns capture the essence of an architecture that has been used in different software systems. You should be aware of common patterns, where they can be used, and their strengths and weaknesses when making decisions about the architecture of a system. I discuss a number of frequently used patterns in Section 6.3.
+
+Garlan and Shaw's notion of an architectural style (style and pattern have come to mean the same thing) covers questions 4 to 6 in the previous list. You have to choose the most appropriate structure, such as client-server or layered structuring, that will enable you to meet the system requirements. To decompose structural system units, you decide on the strategy for decomposing components into sub-components. The approaches that you can use allow different types of architecture to be implemented. Finally, in the control modeling process, you make decisions about how the execution of components is controlled. You develop a general model of the control relationships between the various parts of the system.
+
+Because of the close relationship between non-functional requirements and software architecture, the particular architectural style and structure that you choose for a system should depend on the non-functional system requirements:
+
+1. Performance If performance is a critical requirement, the architecture should be designed to localize critical operations within a small number of components, with these components all deployed on the same computer rather than distributed across the network. This may mean using a few relatively large components rather than small, fine-grain components, which reduces the number of component communications. You may also consider run-time system organizations that allow the system to be replicated and executed on different processors.
+2. Security If security is a critical requirement, a layered structure for the architecture should be used, with the most critical assets protected in the innermost layers, with a high level of security validation applied to these layers.
+3. Safety If safety is a critical requirement, the architecture should be designed so that safety-related operations are all located in either a single component or in a small number of components. This reduces the costs and problems of safety validation and makes it possible to provide related protection systems that can safely shut down the system in the event of failure.
+4. Availability If availability is a critical requirement, the architecture should be designed to include redundant components so that it is possible to replace and update components without stopping the system. I describe two fault-tolerant system architectures for high-availability systems in Chapter 13.
+5. Maintainability If maintainability is a critical requirement, the system architecture should be designed using fine-grain, self-contained components that may
+
+readily be changed. Producers of data should be separated from consumers and shared data structures should be avoided.
+
+Obviously there is potential conflict between some of these architectures. For example, using large components improves performance and using small, fine-grain components improves maintainability. If both performance and maintainability are important system requirements, then some compromise must be found. This can sometimes be achieved by using different architectural patterns or styles for different parts of the system.
+
+Evaluating an architectural design is difficult because the true test of an architecture is how well the system meets its functional and non-functional requirements when it is in use. However, you can do some evaluation by comparing your design against reference architectures or generic architectural patterns. Bosch's (2000) description of the non-functional characteristics of architectural patterns can also be used to help with architectural evaluation.
+
+## 6.2 Architectural views
+
+I explained in the introduction to this chapter that architectural models of a software system can be used to focus discussion about the software requirements or design. Alternatively, they may be used to document a design so that it can be used as a basis for more detailed design and implementation, and for the future evolution of the system. In this section, I discuss two issues that are relevant to both of these:
+
+1. What views or perspectives are useful when designing and documenting a system's architecture?
+2. What notations should be used for describing architectural models?
+
+It is impossible to represent all relevant information about a system's architecture in a single architectural model, as each model only shows one view or perspective of the system. It might show how a system is decomposed into modules, how the run-time processes interact, or the different ways in which system components are distributed across a network. All of these are useful at different times so, for both design and documentation, you usually need to present multiple views of the software architecture.
+
+There are different opinions as to what views are required. Krutchen (1995), in his well-known 4+1 view model of software architecture, suggests that there should be four fundamental architectural views, which are related using use cases or scenarios. The views that he suggests are:
+
+1. A logical view, which shows the key abstractions in the system as objects or object classes. It should be possible to relate the system requirements to entities in this logical view.
+
+2. A process view, which shows how, at run-time, the system is composed of interacting  processes.  This  view  is  useful  for  making  judgments  about  nonfunctional system characteristics such as performance and availability.
+3. A development view, which shows how the software is decomposed for development, that is, it shows the breakdown of the software into components that are implemented by a single developer or development team. This view is useful for software managers and programmers.
+4. A physical view, which shows the system hardware and how software components are distributed across the processors in the system. This view is useful for systems engineers planning a system deployment.
+
+Hofmeister et al. (2000) suggest the use of similar views but add to this the notion of a conceptual view. This view is an abstract view of the system that can be the basis for decomposing high-level requirements into more detailed specifications, help engineers make decisions about components that can be reused, and represent a product line (discussed in Chapter 16) rather than a single system. Figure 6.1, which describes the architecture of a packing robot, is an example of a conceptual system view.
+
+In practice, conceptual views are almost always developed during the design process and are used to support architectural decision making. They are a way of communicating the essence of a system to different stakeholders. During the design process, some of the other views may also be developed when different aspects of the system are discussed, but there is no need for a complete description from all perspectives. It may also be possible to associate architectural patterns, discussed in the next section, with the different views of a system.
+
+There are differing views about whether or not software architects should use the UML for architectural description (Clements, et al., 2002). A survey in 2006 (Lange et al., 2006) showed that, when the UML was used, it was mostly applied in a loose and informal way. The authors of that paper argued that this was a bad thing. I disagree with this view. The UML was designed for describing object-oriented systems and, at the architectural design stage, you often want to describe systems at a higher level of abstraction. Object classes are too close to the implementation to be useful for architectural description.
+
+I don't find the UML to be useful during the design process itself and prefer informal notations that are quicker to write and which can be easily drawn on a whiteboard. The UML is of most value when you are documenting an architecture in detail or using model-driven development, as discussed in Chapter 5.
+
+A number of researchers have proposed the use of more specialized architectural description languages (ADLs) (Bass et al., 2003) to describe system architectures. The basic elements of ADLs are components and connectors, and they include rules and guidelines for well-formed architectures. However, because of their specialized nature, domain and application specialists find it hard to understand and use ADLs. This makes it difficult to assess their usefulness for practical software engineering. ADLs designed for a particular domain (e.g., automobile systems) may be used as a
+
+■
+
+| Name          | MVC (Model-View-Controller)                                                                                                                                                                                                                                                                                                                                                                                                                                                             |
+|---------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Description   | Separates presentation and interaction from the system data. The system is structured into three logical components that interact with each other. The Model component manages the system data and associated operations on that data. The View component defines and manages how the data is presented to the user. The Controller component manages user interaction (e.g., key presses, mouse clicks, etc.) and passes these interactions to the View and the Model. See Figure 6.3. |
+| Example       | Figure 6.4 shows the architecture of a web-based application system organized using the MVC pattern.                                                                                                                                                                                                                                                                                                                                                                                    |
+| When used     | Used when there are multiple ways to view and interact with data. Also used when the future requirements for interaction and presentation of data are unknown.                                                                                                                                                                                                                                                                                                                          |
+| Advantages    | Allows the data to change independently of its representation and vice versa. Supports presentation of the same data in different ways with changes made in one representation shown in all of them.                                                                                                                                                                                                                                                                                    |
+| Disadvantages | Can involve additional code and code complexity when the data model and interactions are simple.                                                                                                                                                                                                                                                                                                                                                                                        |
+
+Figure 6.2 The modelview-controller (MVC) pattern basis for model-driven development. However, I believe that informal models and notations, such as the UML, will remain the most commonly used ways of documenting system architectures.
+
+Users of agile methods claim that detailed design documentation is mostly unused. It is, therefore, a waste of time and money to develop it. I largely agree with this view and I think that, for most systems, it is not worth developing a detailed architectural description from these four perspectives. You should develop the views that are useful for communication and not worry about whether or not your architectural documentation is complete. However, an exception to this is when you are developing critical systems, when you need to make a detailed dependability analysis of the system. You may need to convince external regulators that your system conforms to their regulations and so complete architectural documentation may be required.
+
+## 6.3 Architectural patterns
+
+The idea of patterns as a way of presenting, sharing, and reusing knowledge about software systems is now widely used. The trigger for this was the publication of a book on object-oriented design patterns (Gamma et al., 1995), which prompted the development of other types of pattern, such as patterns for organizational design (Coplien and Harrison, 2004), usability patterns (Usability Group, 1998), interaction (Martin  and  Sommerville,  2004),  configuration  management  (Berczuk  and Appleton, 2002), and so on. Architectural patterns were proposed in the 1990s under the name 'architectural styles' (Shaw and Garlan, 1996), with a five-volume series of handbooks on pattern-oriented software architecture published between 1996 and 2007 (Buschmann et al., 1996; Buschmann et al., 2007a; Buschmann et al., 2007b; Kircher and Jain, 2004; Schmidt et al., 2000).
+
+Figure 6.3 The organization of the MVC
+
+<!-- image -->
+
+In this section, I introduce architectural patterns and briefly describe a selection of architectural patterns that are commonly used in different types of systems. For more information about patterns and their use, you should refer to published pattern handbooks.
+
+You can think of an architectural pattern as a stylized, abstract description of good practice, which has been tried and tested in different systems and environments. So, an architectural pattern should describe a system organization that has been successful in previous systems. It should include information of when it is and is not appropriate to use that pattern, and the pattern's strengths and weaknesses.
+
+For example, Figure 6.2 describes the well-known Model-View-Controller pattern. This pattern is the basis of interaction management in many web-based systems. The stylized pattern description includes the pattern name, a brief description (with an associated graphical model), and an example of the type of system where the pattern is used (again, perhaps with a graphical model). You should also include information about  when  the  pattern  should  be  used  and  its  advantages  and  disadvantages. Graphical models of the architecture associated with the MVC pattern are shown in Figures 6.3 and 6.4. These present the architecture from different views-Figure 6.3 is a conceptual view and Figure 6.4 shows a possible run-time architecture when this pattern is used for interaction management in a web-based system.
+
+In a short section of a general chapter, it is impossible to describe all of the generic patterns that can be used in software development. Rather, I present some selected examples of patterns that are widely used and which capture good architectural design principles. I have included some further examples of generic architectural patterns on the book's web pages.
+
+Figure 6.4 Web application architecture using the MVC pattern
+
+<!-- image -->
+
+<!-- image -->
+
+## 6.3.1 Layered architecture
+
+The notions of separation and independence are fundamental to architectural design because they allow changes to be localized. The MVC pattern, shown in Figure 6.2, separates elements of a system, allowing them to change independently. For example, adding a new view or changing an existing view can be done without any changes to the underlying data in the model. The layered architecture pattern is another way of achieving separation and independence. This pattern is shown in Figure 6.5. Here, the system functionality is organized into separate layers, and each layer only relies on the facilities and services offered by the layer immediately beneath it.
+
+This layered approach supports the incremental development of systems. As a layer is developed, some of the services provided by that layer may be made available to users. The architecture is also changeable and portable. So long as its interface is unchanged, a layer can be replaced by another, equivalent layer. Furthermore, when layer interfaces change or new facilities are added to a layer, only the adjacent layer is affected. As layered systems localize machine dependencies in inner layers, this makes it easier to provide multi-platform implementations of an application system. Only the inner, machine-dependent layers need be re-implemented to take account of the facilities of a different operating system or database.
+
+Figure 6.6 is an example of a layered architecture with four layers. The lowest layer includes system support software-typically database and operating system support.  The  next  layer  is  the  application  layer  that  includes  the  components concerned with the application functionality and utility components that are used by other application components. The third layer is concerned with user interface
+
+| Name          | Layered architecture                                                                                                                                                                                                                                                                                                                          |
+|---------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Description   | Organizes the system into layers with related functionality associated with each layer. A layer provides services to the layer above it so the lowest-level layers represent core services that are likely to be used throughout the system. See Figure 6.6.                                                                                  |
+| Example       | A layered model of a system for sharing copyright documents held in different libraries, as shown in Figure 6.7.                                                                                                                                                                                                                              |
+| When used     | Used when building new facilities on top of existing systems; when the development is spread across several teams with each team responsibility for a layer of functionality; when there is a requirement for multi-level security.                                                                                                           |
+| Advantages    | Allows replacement of entire layers so long as the interface is maintained. Redundant facilities (e.g., authentication) can be provided in each layer to increase the dependability of the system.                                                                                                                                            |
+| Disadvantages | In practice, providing a clean separation between layers is often difficult and a high-level layer may have to interact directly with lower-level layers rather than through the layer immediately below it. Performance can be a problem because of multiple levels of interpretation of a service request as it is processed at each layer. |
+
+## Figure 6.5 The layered architecture pattern
+
+management and providing user authentication and authorization, with the top layer providing user interface facilities. Of course, the number of layers is arbitrary. Any of the layers in Figure 6.6 could be split into two or more layers.
+
+Figure 6.7 is an example of how this layered architecture pattern can be applied to a library system called LIBSYS, which allows controlled electronic access to copyright material from a group of university libraries. This has a five-layer architecture, with the bottom layer being the individual databases in each library.
+
+You can see another example of the layered architecture pattern in Figure 6.17 (found in Section 6.4). This shows the organization of the system for mental healthcare (MHC-PMS) that I have discussed in earlier chapters.
+
+<!-- image -->
+
+Figure 6.7 The architecture of the LIBSYS system
+
+■
+
+<!-- image -->
+
+## 6.3.2 Repository architecture
+
+The layered architecture and MVC patterns are examples of patterns where the view presented  is  the  conceptual  organization  of  a  system.  My  next  example,  the Repository pattern (Figure 6.8), describes how a set of interacting components can share data.
+
+Figure 6.8 The repository pattern The majority of systems that use large amounts of data are organized around a shared database or repository. This model is therefore suited to applications in which data is generated by one component and used by another. Examples of this type of system include command and control systems, management information systems, CAD systems, and interactive development environments for software.
+
+| Name          | Repository                                                                                                                                                                                                                                                            |
+|---------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Description   | All data in a system is managed in a central repository that is accessible to all system components. Components do not interact directly, only through the repository.                                                                                                |
+| Example       | Figure 6.9 is an example of an IDE where the components use a repository of system design information. Each software tool generates information which is then available for use by other tools.                                                                       |
+| When used     | You should use this pattern when you have a system in which large volumes of information are generated that has to be stored for a long time. You may also use it in data-driven systems where the inclusion of data in the repository triggers an action or tool.    |
+| Advantages    | Components can be independent-they do not need to know of the existence of other components. Changes made by one component can be propagated to all components. All data can be managed consistently (e.g., backups done at the same time) as it is all in one place. |
+| Disadvantages | The repository is a single point of failure so problems in the repository affect the whole system. May be inefficiencies in organizing all communication through the repository. Distributing the repository across several computers may be difficult.               |
+
+<!-- image -->
+
+Figure 6.9 is an illustration of a situation in which a repository might be used. This diagram shows an IDE that includes different tools to support model-driven development. The repository in this case might be a version-controlled environment (as discussed in Chapter 25) that keeps track of changes to software and allows rollback to earlier versions.
+
+Organizing tools around a repository is an efficient way to share large amounts of data. There is no need to transmit data explicitly from one component to another. However,  components  must  operate  around  an  agreed  repository  data  model. Inevitably, this is a compromise between the specific needs of each tool and it may be difficult or impossible to integrate new components if their data models do not fit the agreed schema. In practice, it may be difficult to distribute the repository over a number of machines. Although it is possible to distribute a logically centralized repository, there may be problems with data redundancy and inconsistency.
+
+In the example shown in Figure 6.9, the repository is passive and control is the responsibility of the components using the repository. An alternative approach, which has been derived for AI systems, uses a 'blackboard' model that triggers components when particular data become available. This is appropriate when the form of the repository data is less well structured. Decisions about which tool to activate can only be made when the data has been analyzed. This model is introduced by Nii (1986). Bosch (2000) includes a good discussion of how this style relates to system quality attributes.
+
+## 6.3.3 Client-server architecture
+
+The repository pattern is concerned with the static structure of a system and does not show its run-time organization. My next example illustrates a very commonly used run-time organization for distributed systems. The Client-server pattern is described in Figure 6.10.
+
+■
+
+| Name          | Client-server                                                                                                                                                                                                                                                                  |
+|---------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Description   | In a client-server architecture, the functionality of the system is organized into services, with each service delivered from a separate server. Clients are users of these services and access servers to make use of them.                                                   |
+| Example       | Figure 6.11 is an example of a film and video/DVD library organized as a client-server system.                                                                                                                                                                                 |
+| When used     | Used when data in a shared database has to be accessed from a range of locations. Because servers can be replicated, may also be used when the load on a system is variable.                                                                                                   |
+| Advantages    | The principal advantage of this model is that servers can be distributed across a network. General functionality (e.g., a printing service) can be available to all clients and does not need to be implemented by all services.                                               |
+| Disadvantages | Each service is a single point of failure so susceptible to denial of service attacks or server failure. Performance may be unpredictable because it depends on the network as well as the system. May be management problems if servers are owned by different organizations. |
+
+Figure 6.10 The client-server pattern A system that follows the client-server pattern is organized as a set of services and associated servers, and clients that access and use the services. The major components of this model are:
+
+1. A set of servers that offer services to other components. Examples of servers include print servers that offer printing services, file servers that offer file management services, and a compile server, which offers programming language compilation services.
+2. A set of clients that call on the services offered by servers. There will normally be several instances of a client program executing concurrently on different computers.
+3. A network that allows the clients to access these services. Most client-server systems  are  implemented  as  distributed  systems,  connected  using  Internet protocols.
+
+Client-server architectures are usually thought of as distributed systems architectures but the logical model of independent services running on separate servers can be implemented on a single computer. Again, an important benefit is separation and independence. Services and servers can be changed without affecting other parts of the system.
+
+Clients may have to know the names of the available servers and the services that they provide. However, servers do not need to know the identity of clients or how many clients are accessing their services. Clients access the services provided by a server through remote procedure calls using a request-reply protocol such as the http protocol used in the WWW. Essentially, a client makes a request to a server and waits until it receives a reply.
+
+Figure 6.11 A clientserver architecture for a film library
+
+Figure 6.12 The pipe and filter pattern
+
+<!-- image -->
+
+Figure 6.11 is an example of a system that is based on the client-server model. This is a multi-user, web-based system for providing a film and photograph library. In this system, several servers manage and display the different types of media. Video frames need to be transmitted quickly and in synchrony but at relatively low resolution. They may be compressed in a store, so the video server can handle video compression and decompression in different formats. Still pictures, however, must be maintained at a high resolution, so it is appropriate to maintain them on a separate server.
+
+The catalog must be able to deal with a variety of queries and provide links into the web information system that includes data about the film and video clips, and an e-commerce system that supports the sale of photographs, film, and video clips. The
+
+| Name          | Pipe and filter                                                                                                                                                                                                                                                                                                            |
+|---------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Description   | The processing of the data in a system is organized so that each processing component (filter) is discrete and carries out one type of data transformation. The data flows (as in a pipe) from one component to another for processing.                                                                                    |
+| Example       | Figure 6.13 is an example of a pipe and filter system used for processing invoices.                                                                                                                                                                                                                                        |
+| When used     | Commonly used in data processing applications (both batch- and transaction-based) where inputs are processed in separate stages to generate related outputs.                                                                                                                                                               |
+| Advantages    | Easy to understand and supports transformation reuse. Workflow style matches the structure of many business processes. Evolution by adding transformations is straightforward. Can be implemented as either a sequential or concurrent system.                                                                             |
+| Disadvantages | The format for data transfer has to be agreed upon between communicating transformations. Each transformation must parse its input and unparse its output to the agreed form. This increases system overhead and may mean that it is impossible to reuse functional transformations that use incompatible data structures. |
+
+■
+
+Figure 6.13 An example of the pipe and filter architecture
+
+<!-- image -->
+
+client program is simply an integrated user interface, constructed using a web browser, to access these services.
+
+The most important advantage of the client-server model is that it is a distributed architecture. Effective use can be made of networked systems with many distributed processors. It is easy to add a new server and integrate it with the rest of the system or to upgrade servers transparently without affecting other parts of the system. I discuss distributed architectures, including client-server architectures and distributed object architectures, in Chapter 18.
+
+## 6.3.4 Pipe and filter architecture
+
+My final example of an architectural pattern is the pipe and filter pattern. This is a model of the run-time organization of a system where functional transformations process their inputs and produce outputs. Data flows from one to another and is transformed as it moves through the sequence. Each processing step is implemented as a transform. Input data flows through these transforms until converted to output. The transformations may execute sequentially or in parallel. The data can be processed by each transform item by item or in a single batch.
+
+The name 'pipe and filter' comes from the original Unix system where it was possible to link processes using 'pipes'. These passed a text stream from one process to another. Systems that conform to this model can be implemented by combining Unix commands, using pipes and the control facilities of the Unix shell. The term 'filter' is used because a transformation 'filters out' the data it can process from its input data stream.
+
+Variants of this pattern have been in use since computers were first used for automatic data processing. When transformations are sequential with data processed in batches, this pipe and filter architectural model becomes a batch sequential model, a common architecture for data processing systems (e.g., a billing system). The architecture of an embedded system may also be organized as a process pipeline, with each process executing concurrently. I discuss the use of this pattern in embedded systems in Chapter 20.
+
+An example of this type of system architecture, used in a batch processing application, is shown in Figure 6.13. An organization has issued invoices to customers. Once a week, payments that have been made are reconciled with the invoices. For
+
+<!-- image -->
+
+## Architectural patterns for control
+
+There are specific architectural patterns that reflect commonly used ways of organizing control in a system. These include centralized control, based on one component calling other components, and event-based control, where the system reacts to external events.
+
+http://www.SoftwareEngineering-9.com/Web/Architecture/ArchPatterns/
+
+those invoices that have been paid, a receipt is issued. For those invoices that have not been paid within the allowed payment time, a reminder is issued.
+
+Interactive systems are difficult to write using the pipe and filter model because of the need for a stream of data to be processed. Although simple textual input and output can be modeled in this way, graphical user interfaces have more complex I/O formats and a control strategy that is based on events such as mouse clicks or menu selections. It is difficult to translate this into a form compatible with the pipelining model.
+
+## 6.4 Application architectures
+
+Application systems are intended to meet a business or organizational need. All businesses have much in common-they need to hire people, issue invoices, keep accounts, and so on. Businesses operating in the same sector use common sectorspecific applications. Therefore, as well as general business functions, all phone companies need systems to connect calls, manage their network, issue bills to customers, etc. Consequently, the application systems used by these businesses also have much in common.
+
+These commonalities have led to the development of software architectures that describe the structure and organization of particular types of software systems. Application architectures encapsulate the principal characteristics of a class of systems. For example, in real-time systems, there might be generic architectural models of different system types, such as data collection systems or monitoring systems. Although instances of these systems differ in detail, the common architectural structure can be reused when developing new systems of the same type.
+
+The  application  architecture  may  be  re-implemented  when  developing  new systems but, for many business systems, application reuse is possible without reimplementation. We see this in the growth of Enterprise Resource Planning (ERP) systems from companies such as SAP and Oracle, and vertical software packages (COTS) for specialized applications in different areas of business. In these systems, a generic system is configured and adapted to create a specific business application.
+
+<!-- image -->
+
+## Application architectures
+
+There are several examples of application architectures on the book's website. These include descriptions of batch data-processing systems, resource allocation systems, and event-based editing systems.
+
+http://www.SoftwareEngineering-9.com/Web/Architecture/AppArch/
+
+For example, a system for supply chain management can be adapted for different types of suppliers, goods, and contractual arrangements.
+
+As a software designer, you can use models of application architectures in a number of ways:
+
+1. As a starting point for the architectural design process If you are unfamiliar with the type of application that you are developing, you can base your initial design on a generic application architecture. Of course, this will have to be specialized for the specific system being developed, but it is a good starting point for design.
+2. As a design checklist If you have developed an architectural design for an application system, you can compare this with the generic application architecture. You can check that your design is consistent with the generic architecture.
+3. As a way of organizing the work of the development team The application architectures identify stable structural features of the system architectures and in many cases, it is possible to develop these in parallel. You can assign work to group members to implement different components within the architecture.
+4. As a means of assessing components for reuse If you have components you might be able to reuse, you can compare these with the generic structures to see whether there are comparable components in the application architecture.
+5. As a vocabulary for talking about types of applications If you are discussing a specific application or trying to compare applications of the same types, then you can use the concepts identified in the generic architecture to talk about the applications.
+
+There are many types of application system and, in some cases, they may seem to be very different. However, many of these superficially dissimilar applications actually have much in common, and thus can be represented by a single abstract application architecture. I illustrate this here by describing the following architectures of two types of application:
+
+1. Transaction processing applications Transaction processing applications are database-centered applications that process user requests for information and update the information in a database. These are the most common type of interactive business systems. They are organized in such a way that user actions can't interfere with each other and the integrity of the database is maintained. This
+
+<!-- image -->
+
+<!-- image -->
+
+- class of system includes interactive banking systems, e-commerce systems, information systems, and booking systems.
+2. Language processing systems Language processing systems are systems in which the user's intentions are expressed in a formal language (such as Java). The language processing system processes this language into an internal format and then interprets this internal representation. The best-known language processing systems are compilers, which translate high-level language programs into machine code. However, language processing systems are also used to interpret  command  languages  for  databases  and  information  systems,  and markup languages such as XML (Harold and Means, 2002; Hunter et al., 2007).
+
+I have chosen these particular types of system because a large number of webbased business systems are transaction-processing systems, and all software development relies on language processing systems.
+
+## 6.4.1 Transaction processing systems
+
+Transaction processing (TP) systems are designed to process user requests for information from a database, or requests to update a database (Lewis et al., 2003). Technically, a database transaction is sequence of operations that is treated as a single unit (an atomic unit). All of the operations in a transaction have to be completed before the database changes are made permanent. This ensures that failure of operations within the transaction does not lead to inconsistencies in the database.
+
+From a user perspective, a transaction is any coherent sequence of operations that satisfies a goal, such as 'find the times of flights from London to Paris'. If the user transaction does not require the database to be changed then it may not be necessary to package this as a technical database transaction.
+
+An example of a transaction is a customer request to withdraw money from a bank account using an ATM. This involves getting details of the customer's account, checking the balance, modifying the balance by the amount withdrawn, and sending commands to the ATM to deliver the cash. Until all of these steps have been completed, the transaction is incomplete and the customer accounts database is not changed.
+
+Transaction processing systems are usually interactive systems in which users make asynchronous requests for service. Figure 6.14 illustrates the conceptual architectural structure of TP applications. First a user makes a request to the system through an I/O processing component. The request is processed by some applicationspecific logic. A transaction is created and passed to a transaction manager, which is usually embedded in the database management system. After the transaction manager has ensured that the transaction is properly completed, it signals to the application that processing has finished.
+
+Figure 6.15 The software architecture of an ATM system
+
+<!-- image -->
+
+<!-- image -->
+
+Transaction processing systems may be organized as a 'pipe and filter' architecture with system components responsible for input, processing, and output. For example, consider a banking system that allows customers to query their accounts and withdraw cash from an ATM. The system is composed of two cooperating software components-the ATM software and the account processing software in the bank's database server. The input and output components are implemented as software in the ATM and the processing component is part of the bank's database server. Figure 6.15 shows the architecture of this system, illustrating the functions of the input, process, and output components.
+
+## 6.4.2 Information systems
+
+All systems that involve interaction with a shared database can be considered to be transaction-based information systems. An information system allows controlled access to a large base of information, such as a library catalog, a flight timetable, or the records of patients in a hospital. Increasingly, information systems are web-based systems that are accessed through a web browser.
+
+Figure 6.16 a very general model of an information system. The system is modeled using a layered approach (discussed in Section 6.3) where the top layer supports the user interface and the bottom layer is the system database. The user communications layer handles all input and output from the user interface, and the information retrieval layer includes application-specific logic for accessing and updating the database. As we shall see later, the layers in this model can map directly onto servers in an Internet-based system.
+
+As an example of an instantiation of this layered model, Figure 6.17 shows the architecture of the MHC-PMS. Recall that this system maintains and manages details of patients who are consulting specialist doctors about mental health problems. I have Figure 6.16 Layered information system architecture added detail to each layer in the model by identifying the components that support user communications and information retrieval and access:
+
+<!-- image -->
+
+1. The top layer is responsible for implementing the user interface. In this case, the UI has been implemented using a web browser.
+2. The second layer provides the user interface functionality that is delivered through the web browser. It includes components to allow users to log in to the system and checking components that ensure that the operations they use are allowed by their role. This layer includes form and menu management components that present information to users, and data validation components that check information consistency.
+3. The third layer implements the functionality of the system and provides components that implement system security, patient information creation and updating, import and export of patient data from other databases, and report generators that create management reports.
+
+<!-- image -->
+
+■
+
+4. Finally, the lowest layer, which is built using a commercial database management system, provides transaction management and persistent data storage.
+
+Information and resource management systems are now usually web-based systems where  the  user  interfaces  are  implemented  using  a  web  browser.  For  example, e-commerce systems are Internet-based resource management systems that accept electronic orders for goods or services and then arrange delivery of these goods or services to the customer. In an e-commerce system, the application-specific layer includes additional functionality supporting a 'shopping cart' in which users can place a number of items in separate transactions, then pay for them all together in a single transaction.
+
+The organization of servers in these systems usually reflects the four-layer generic model presented in Figure 6.16. These systems are often implemented as multi-tier client server/architectures, as discussed in Chapter 18:
+
+1. The web server is responsible for all user communications, with the user interface implemented using a web browser;
+2. The application server is responsible for implementing application-specific logic as well as information storage and retrieval requests;
+3. The database server moves information to and from the database and handles transaction management.
+
+Using multiple servers allows high throughput and makes it possible to handle hundreds of transactions per minute. As demand increases, servers can be added at each level to cope with the extra processing involved.
+
+## 6.4.3 Language processing systems
+
+Language processing systems translate a natural or artificial language into another representation of that language and, for programming languages, may also execute the resulting code. In software engineering, compilers translate an artificial programming language into machine code. Other language-processing systems may translate an XML data description into commands to query a database or to an alternative XML representation. Natural language processing systems may translate one natural language to another e.g., French to Norwegian.
+
+A possible architecture for a language processing system for a programming language is illustrated in Figure 6.18. The source language instructions define the program to be executed and a translator converts these into instructions for an abstract machine. These instructions are then interpreted by another component that fetches the instructions for execution and executes them using (if necessary) data from the environment. The output of the process is the result of interpreting the instructions on the input data.
+
+<!-- image -->
+
+Of course, for many compilers, the interpreter is a hardware unit that processes machine instructions and the abstract machine is a real processor. However, for dynamically typed languages, such as Python, the interpreter may be a software component.
+
+Programming language compilers that are part of a more general programming environment have a generic architecture (Figure 6.19) that includes the following components:
+
+1. A lexical analyzer, which takes input language tokens and converts them to an internal form.
+2. A symbol table, which holds information about the names of entities (variables, class names, object names, etc.) used in the text that is being translated.
+3. A syntax analyzer, which checks the syntax of the language being translated. It uses a defined grammar of the language and builds a syntax tree.
+4. A syntax tree, which is an internal structure representing the program being compiled.
+
+<!-- image -->
+
+Figure 6.19 A pipe and filter compiler architecture
+
+<!-- image -->
+
+## Reference architectures
+
+Reference architectures capture important features of system architectures in a domain. Essentially, they include everything that might be in an application architecture although, in reality, it is very unlikely that any individual application would include all the features shown in a reference architecture. The main purpose of reference architectures is to evaluate and compare design proposals, and to educate people about architectural characteristics in that domain.
+
+http://www.SoftwareEngineering-9.com/Web/Architecture/RefArch.html
+
+5. A semantic analyzer that uses information from the syntax tree and the symbol table to check the semantic correctness of the input language text.
+6. A code generator that 'walks' the syntax tree and generates abstract machine code.
+
+Other components might also be included which analyze and transform the syntax tree to improve efficiency and remove redundancy from the generated machine code. In other types of language processing system, such as a natural language translator, there will be additional components such as a dictionary, and the generated code is actually the input text translated into another language.
+
+There are alternative architectural patterns that may be used in a language processing system (Garlan and Shaw, 1993). Compilers can be implemented using a composite of a repository and a pipe and filter model. In a compiler architecture, the symbol table is a repository for shared data. The phases of lexical, syntactic, and semantic analysis are organized sequentially, as shown in Figure 6.19, and communicate through the shared symbol table.
+
+This pipe and filter model of language compilation is effective in batch environments where programs are compiled and executed without user interaction; for example, in the translation of one XML document to another. It is less effective when a compiler is integrated with other language processing tools such as a structured editing system, an interactive debugger or a program prettyprinter. In this situation, changes from one component need to be reflected immediately in other components. It is better, therefore, to organize the system around a repository, as shown in Figure 6.20.
+
+This figure illustrates how a language processing system can be part of an integrated set of programming support tools. In this example, the symbol table and syntax tree act as a central information repository. Tools or tool fragments communicate through it. Other information that is sometimes embedded in tools, such as the grammar definition and the definition of the output format for the program, have been taken out of the tools and put into the repository. Therefore, a syntax-directed editor can check that the syntax of a program is correct as it is being typed and a prettyprinter can create listings of the program in a format that is easy to read.
+
+<!-- image -->
+
+<!-- image -->
+
+## KEY POINTS
+
+- ■ A software architecture is a description of how a software system is organized. Properties of a system such as performance, security, and availability are influenced by the architecture used.
+- ■ Architectural design decisions include decisions on the type of application, the distribution of the system, the architectural styles to be used, and the ways in which the architecture should be documented and evaluated.
+- ■ Architectures may be documented from several different perspectives or views. Possible views include a conceptual view, a logical view, a process view, a development view, and a physical view.
+- ■ Architectural patterns are a means of reusing knowledge about generic system architectures. They describe the architecture, explain when it may be used, and discuss its advantages and disadvantages.
+- ■ Commonly used architectural patterns include Model-View-Controller, Layered Architecture, Repository, Client-server, and Pipe and Filter.
+- ■ Generic models of application systems architectures help us understand the operation of applications, compare applications of the same type, validate application system designs, and assess large-scale components for reuse.
+- ■ Transaction processing systems are interactive systems that allow information in a database to be remotely accessed and modified by a number of users. Information systems and resource management systems are examples of transaction processing systems.
+- ■ Language processing systems are used to translate texts from one language into another and to carry out the instructions specified in the input language. They include a translator and an abstract machine that executes the generated language.
+
+## FURTHER READING
+
+Software Architecture: Perspectives on an Emerging Discipline. This was the first book on software architecture and has a good discussion on different architectural styles. (M. Shaw and D. Garlan, Prentice-Hall, 1996.)
+
+Software Architecture in Practice, 2nd ed. This is a practical discussion of software architectures that does not oversell the benefits of architectural design. It provides a clear business rationale explaining why architectures are important. (L. Bass, P. Clements and R. Kazman, Addison-Wesley, 2003.)
+
+'The Golden Age of Software Architecture' This paper surveys the development of software architecture from its beginnings in the 1980s through to its current usage. There is little technical content but it is an interesting historical overview. (M. Shaw and P. Clements, IEEE Software, 21 (2), March-April 2006.) http://dx.doi.org/10.1109/MS.2006.58.
+
+Handbook of Software Architecture . This is a work in progress by Grady Booch, one of the early evangelists for software architecture. He has been documenting the architectures of a range of software systems so you can see reality rather than academic abstraction. Available on the Web and intended to appear as a book. http://www.handbookofsoftwarearchitecture.com/.
+
+## EXERCISES
+
+- 6.1. When describing a system, explain why you may have to design the system architecture before the requirements specification is complete.
+- 6.2. You have been asked to prepare and deliver a presentation to a non-technical manager to justify the hiring of a system architect for a new project. Write a list of bullet points setting out the key points in your presentation. Naturally, you have to explain what is meant by system architecture.
+- 6.3. Explain why design conflicts might arise when designing an architecture for which both availability and security requirements are the most important non-functional requirements.
+- 6.4. Draw diagrams showing a conceptual view and a process view of the architectures of the following systems:
+
+An automated ticket-issuing system used by passengers at a railway station.
+
+A computer-controlled video conferencing system that allows video, audio, and computer data to be visible to several participants at the same time.
+
+A robot floor cleaner that is intended to clean relatively clear spaces such as corridors. The cleaner must be able to sense walls and other obstructions.
+
+<!-- image -->
+
+- 6.5. Explain why you normally use several architectural patterns when designing the architecture of a large system. Apart from the information about patterns that I have discussed in this chapter, what additional information might be useful when designing large systems?
+- 6.6. Suggest an architecture for a system (such as iTunes) that is used to sell and distribute music on the Internet. What architectural patterns are the basis for this architecture?
+- 6.7. Explain how you would use the reference model of CASE environments (available on the book's web pages) to compare the IDEs offered by different vendors of a programming language such as Java.
+- 6.8. Using the generic model of a language processing system presented here, design the architecture of a system that accepts natural language commands and translates these into database queries in a language such as SQL.
+- 6.9. Using the basic model of an information system, as presented in Figure 6.16, suggest the components that might be part of an information system that allows users to view information about flights arriving and departing from a particular airport.
+- 6.10. Should there be a separate profession of 'software architect' whose role is to work independently with a customer to design the software system architecture? A separate software company would then implement the system. What might be the difficulties of establishing such a profession?
+
+## REFERENCES
+
+Bass, L., Clements, P. and Kazman, R. (2003). Software Architecture in Practice, 2nd ed. Boston: Addison-Wesley.
+
+Berczuk, S. P. and Appleton, B. (2002). Software Configuration Management Patterns: Effective Teamwork, Practical Integration. Boston: Addison-Wesley.
+
+Booch, G. (2009). 'Handbook of software architecture'. Web publication. http:/ /www.handbookofsoftwarearchitecture.com/.
+
+Bosch, J. (2000). Design and Use of Software Architectures. Harlow, UK: Addison-Wesley.
+
+Buschmann, F., Henney, K. and Schmidt, D. C. (2007a). Pattern-oriented Software Architecture Volume 4: A Pattern Language for Distributed Computing. New York: John Wiley &amp; Sons.
+
+Buschmann, F., Henney, K. and Schmidt, D. C. (2007b). Pattern-oriented Software Architecture Volume 5: On Patterns and Pattern Languages. New York: John Wiley &amp; Sons.
+
+Buschmann, F., Meunier, R., Rohnert, H. and Sommerlad, P. (1996). Pattern-oriented Software Architecture Volume 1: A System of Patterns. New York: John Wiley &amp; Sons.
+
+■
+
+Clements, P., Bachmann, F., Bass, L., Garlan, D., Ivers, J., Little, R., Nord, R. and Stafford, J. (2002). Documenting Software Architectures: Views and Beyond. Boston: Addison-Wesley.
+
+Coplien, J. H. and Harrison, N. B. (2004). Organizational Patterns of Agile Software Development. Englewood Cliffs, NJ: Prentice Hall.
+
+Gamma, E., Helm, R., Johnson, R. and Vlissides, J. (1995). Design Patterns: Elements of Reusable Object-Oriented Software. Reading, Mass.: Addison-Wesley.
+
+Garlan, D. and Shaw, M. (1993). 'An introduction to software architecture'. Advances in Software Engineering and Knowledge Engineering, 1 1-39.
+
+Harold, E. R. and Means, W. S. (2002). XML in a Nutshell. Sebastopol. Calif.: O'Reilly.
+
+Hofmeister, C., Nord, R. and Soni, D. (2000). Applied Software Architecture. Boston: AddisonWesley.
+
+Hunter, D., Rafter, J., Fawcett, J. and Van Der Vlist, E. (2007). Beginning XML, 4th ed. Indianapolis, Ind.: Wrox Press.
+
+Kircher, M. and Jain, P. (2004). Pattern-Oriented Software Architecture Volume 3: Patterns for Resource Management. New York: John Wiley &amp; Sons.
+
+Krutchen, P. (1995). 'The 4+1 view model of software architecture'. IEEE Software, 12 (6), 42-50.
+
+Lange, C. F. J., Chaudron, M. R. V. and Muskens, J. (2006). 'UML software description and architecture description'. IEEE Software, 23 (2), 40-6.
+
+Lewis, P. M., Bernstein, A. J. and Kifer, M. (2003). Databases and Transaction Processing: An Application-oriented Approach. Boston: Addison-Wesley.
+
+Martin, D. and Sommerville, I. (2004). 'Patterns of interaction: Linking ethnomethodology and design'. ACM Trans. on Computer-Human Interaction, 11 (1), 59-89.
+
+Nii, H. P . (1986). 'Blackboard systems, parts 1 and 2'. AI Magazine, 7 (3 and 4), 38-53 and 62-9.
+
+Schmidt, D., Stal, M., Rohnert, H. and Buschmann, F. (2000). Pattern-Oriented Software Architecture Volume 2: Patterns for Concurrent and Networked Objects. New York: John Wiley &amp; Sons.
+
+Shaw, M. and Garlan, D. (1996). Software Architecture: Perspectives on an Emerging Discipline. Englewood Cliffs, NJ: Prentice Hall.
+
+Usability group. (1998). 'Usability patterns'. Web publication. http://www.it.bton.ac.uk/cil/usability/patterns/.

proj_level_reading/User_Analysis/Policy_Analysis/how_to_commericalized_legalizing_healthcare_product/text_extract.py

@@ -0,0 +1,36 @@
+from pathlib import Path
+
+from docling.datamodel.base_models import InputFormat
+from docling.datamodel.pipeline_options import PdfPipelineOptions, AcceleratorOptions
+from docling.document_converter import DocumentConverter, PdfFormatOption
+
+def main():
+    input_doc_path = Path("se_arch.pdf")
+
+    pipeline_options = PdfPipelineOptions()
+    pipeline_options.do_ocr = True
+    pipeline_options.do_table_structure = True
+    accelerator_options = AcceleratorOptions(device="cpu")
+
+    converter = DocumentConverter(
+        format_options={
+            InputFormat.PDF: PdfFormatOption(
+                pipeline_options=pipeline_options,
+            )
+        }
+    )
+
+    conversion_result = converter.convert(input_doc_path)
+    doc = conversion_result.document
+
+    md = doc.export_to_markdown()
+
+    output_path = Path("se_arch.md")
+    output_path.write_text(md, encoding="utf-8")
+
+    # doc_conversion_secs = conversion_result.timings["pipeline_total"].times
+    print(f"Saved markdown to {output_path}")
+    # print(f"Conversion secs: {doc_conversion_secs}")
+
+if __name__ == "__main__":
+    main()