@xdev-asia/xdev-knowledge-mcp 1.0.36 → 1.0.38

package/content/series/{devsecops/bao-mat-du-lieu-y-te-cho-microservices/chapters/01-phan-1-nen-tang-bao-mat-du-lieu-y-te/lessons/01-bai-1-tong-quan-bao-mat-du-lieu-y-te-hipaa-hl7-fhir.md → architecture/xay-dung-he-thong-y-te-microservices/chapters/01-phan-1-kien-truc-nen-tang/lessons/01-bai-1-tong-quan-he-thong-y-te-yeu-cau-bao-mat.md}

@@ -1,7 +1,7 @@
 ---
 id: 019e1a40-a101-7001-d001-f0a1b2c30101
-title: 'Bài 1: Tổng quan Bảo mật Dữ liệu Y Tế - HIPAA, HL7 FHIR & Luật Việt Nam'
-slug: bai-1-tong-quan-bao-mat-du-lieu-y-te-hipaa-hl7-fhir
+title: 'Bài 1: Tổng quan Hệ thống Y tế & Yêu cầu Bảo mật — HIPAA, HL7 FHIR'
+slug: bai-1-tong-quan-he-thong-y-te-yeu-cau-bao-mat
 description: >-
   Tìm hiểu tổng quan bảo mật dữ liệu y tế: khái niệm PHI/ePHI, các tiêu chuẩn
   quốc tế HIPAA (Privacy Rule, Security Rule, Breach Notification), HL7 FHIR
@@ -12,15 +12,17 @@ duration_minutes: 120
 is_free: true
 video_url: null
 sort_order: 1
-section_title: "Phần 1: Nền tảng Bảo mật Dữ liệu Y Tế"
+section_title: "Phần 1: Kiến trúc & Nền tảng"
 course:
   id: 019e1a40-a100-7001-d001-f0a1b2c30001
-  title: Bảo mật Dữ liệu Y Tế cho Hệ thống Microservices
-  slug: bao-mat-du-lieu-y-te-cho-microservices
+  title: Xây dựng Hệ thống Y tế Microservices — Quarkus, PostgreSQL, Keycloak chuẩn HIPAA
+  slug: xay-dung-he-thong-y-te-microservices
 ---
 
 ## 1. Tại sao Bảo mật Dữ liệu Y Tế quan trọng?
 
+![Tổng quan HIPAA Technical Safeguards — 5 danh mục kiểm soát bảo mật kỹ thuật](/storage/uploads/2026/04/healthcare-hipaa-safeguards-overview.png)
+
 Dữ liệu y tế là một trong những loại dữ liệu nhạy cảm nhất. Một bản ghi y tế (medical record) chứa thông tin cá nhân, lịch sử bệnh án, kết quả xét nghiệm, đơn thuốc, và thông tin bảo hiểm — tất cả đều có giá trị cao trên thị trường đen.
 
 ### Thống kê đáng lo ngại
@@ -126,29 +128,13 @@ Security Rule đặt ra yêu cầu bảo mật cho ePHI, chia thành 3 loại sa
 
 #### Technical Safeguards (focus chính của series này)
 
-```
-┌─────────────────────────────────────────────────────────────┐
-│                  HIPAA Technical Safeguards                   │
-├─────────────────┬───────────────────────────────────────────┤
-│ Access Control  │ • Unique User Identification (Required)   │
-│                 │ • Emergency Access Procedure (Required)    │
-│                 │ • Automatic Logoff (Addressable)          │
-│                 │ • Encryption & Decryption (Addressable)   │
-├─────────────────┼───────────────────────────────────────────┤
-│ Audit Controls  │ • Hardware, software, procedural          │
-│                 │   mechanisms to record and examine        │
-│                 │   access to ePHI (Required)               │
-├─────────────────┼───────────────────────────────────────────┤
-│ Integrity       │ • Mechanism to authenticate ePHI          │
-│                 │   (Addressable)                           │
-├─────────────────┼───────────────────────────────────────────┤
-│ Authentication  │ • Person or Entity Authentication         │
-│                 │   (Required)                              │
-├─────────────────┼───────────────────────────────────────────┤
-│ Transmission    │ • Integrity Controls (Addressable)        │
-│ Security        │ • Encryption (Addressable)                │
-└─────────────────┴───────────────────────────────────────────┘
-```
+| Danh mục | Controls |
+|----------|----------|
+| **Access Control** | Unique User Identification (Required), Emergency Access Procedure (Required), Automatic Logoff (Addressable), Encryption & Decryption (Addressable) |
+| **Audit Controls** | Hardware, software, procedural mechanisms to record and examine access to ePHI (Required) |
+| **Integrity** | Mechanism to authenticate ePHI (Addressable) |
+| **Authentication** | Person or Entity Authentication (Required) |
+| **Transmission Security** | Integrity Controls (Addressable), Encryption (Addressable) |
 
 > **Lưu ý**: "Required" = bắt buộc triển khai. "Addressable" = phải đánh giá và triển khai nếu hợp lý, hoặc document lý do không triển khai.
 
@@ -171,23 +157,14 @@ Khi xảy ra data breach liên quan đến PHI:
 
 FHIR định nghĩa các security components:
 
-```
-┌──────────────────────────────────────────┐
-│           FHIR Security Layers           │
-├──────────────────────────────────────────┤
-│  Communication Security (HTTPS/TLS)      │
-├──────────────────────────────────────────┤
-│  Authentication (OAuth2, SMART on FHIR)  │
-├──────────────────────────────────────────┤
-│  Authorization (Scopes, Consent)         │
-├──────────────────────────────────────────┤
-│  Audit (AuditEvent resource)             │
-├──────────────────────────────────────────┤
-│  Digital Signatures (Provenance)         │
-├──────────────────────────────────────────┤
-│  Consent Management (Consent resource)   │
-└──────────────────────────────────────────┘
-```
+![Các lớp bảo mật trong kiến trúc FHIR — từ Communication Security đến Consent Management](/storage/uploads/2026/04/healthcare-fhir-security-layers.png)
+
+- **Communication Security**: HTTPS/TLS
+- **Authentication**: OAuth2, SMART on FHIR
+- **Authorization**: Scopes, Consent
+- **Audit**: AuditEvent resource
+- **Digital Signatures**: Provenance
+- **Consent Management**: Consent resource
 
 ### 4.3. SMART on FHIR
 
@@ -237,27 +214,13 @@ Quy định về hồ sơ bệnh án điện tử:
 
 ### 6.1. NIST Cybersecurity Framework
 
-```
-       ┌──────────┐
-       │ IDENTIFY  │ → Asset Management, Risk Assessment
-       └────┬─────┘
-            ↓
-       ┌──────────┐
-       │ PROTECT   │ → Access Control, Data Security, Training
-       └────┬─────┘
-            ↓
-       ┌──────────┐
-       │ DETECT    │ → Anomalies, Monitoring, Detection Processes
-       └────┬─────┘
-            ↓
-       ┌──────────┐
-       │ RESPOND   │ → Response Planning, Communications, Mitigation
-       └────┬─────┘
-            ↓
-       ┌──────────┐
-       │ RECOVER   │ → Recovery Planning, Improvements, Communications
-       └──────────┘
-```
+![Vòng đời NIST Cybersecurity Framework — 5 chức năng: Identify, Protect, Detect, Respond, Recover](/storage/uploads/2026/04/healthcare-nist-csf-framework.png)
+
+- **IDENTIFY**: Asset Management, Risk Assessment
+- **PROTECT**: Access Control, Data Security, Training
+- **DETECT**: Anomalies, Monitoring, Detection Processes
+- **RESPOND**: Response Planning, Communications, Mitigation
+- **RECOVER**: Recovery Planning, Improvements, Communications
 
 ### 6.2. ISO 27799 - Health Informatics Security
 

package/content/series/{devsecops/bao-mat-du-lieu-y-te-cho-microservices/chapters/01-phan-1-nen-tang-bao-mat-du-lieu-y-te/lessons/02-bai-2-kien-truc-microservices-an-toan-cho-y-te.md → architecture/xay-dung-he-thong-y-te-microservices/chapters/01-phan-1-kien-truc-nen-tang/lessons/02-bai-2-thiet-ke-kien-truc-microservices-y-te.md}

@@ -1,7 +1,7 @@
 ---
 id: 019e1a40-a102-7001-d001-f0a1b2c30102
-title: 'Bài 2: Kiến trúc Microservices An toàn cho Y Tế với Quarkus Stack'
-slug: bai-2-kien-truc-microservices-an-toan-cho-y-te
+title: 'Bài 2: Thiết kế Kiến trúc Microservices cho Y tế — Quarkus Stack Blueprint'
+slug: bai-2-thiet-ke-kien-truc-microservices-y-te
 description: >-
   Thiết kế kiến trúc microservices bảo mật cho hệ thống y tế sử dụng
   Quarkus, PostgreSQL, Keycloak. Bao gồm API Gateway pattern, service mesh,
@@ -11,15 +11,17 @@ duration_minutes: 150
 is_free: true
 video_url: null
 sort_order: 2
-section_title: "Phần 1: Nền tảng Bảo mật Dữ liệu Y Tế"
+section_title: "Phần 1: Kiến trúc & Nền tảng"
 course:
   id: 019e1a40-a100-7001-d001-f0a1b2c30001
-  title: Bảo mật Dữ liệu Y Tế cho Hệ thống Microservices
-  slug: bao-mat-du-lieu-y-te-cho-microservices
+  title: Xây dựng Hệ thống Y tế Microservices — Quarkus, PostgreSQL, Keycloak chuẩn HIPAA
+  slug: xay-dung-he-thong-y-te-microservices
 ---
 
 ## 1. Tổng quan Kiến trúc Healthcare Microservices
 
+![Kiến trúc tổng thể Healthcare Microservices — Quarkus, PostgreSQL, Keycloak, Kafka, Istio](/storage/uploads/2026/04/healthcare-ms-architecture-blueprint.png)
+
 ### 1.1. Tại sao Microservices cho Y Tế?
 
 Hệ thống y tế truyền thống (monolithic) gặp nhiều thách thức:
@@ -38,113 +40,37 @@ Microservices giải quyết bằng cách:
 
 ### 1.2. Healthcare Domain Services
 
-```
-┌─────────────────────────────────────────────────────────────────┐
-│                    Healthcare Microservices                       │
-├────────────┬────────────┬────────────┬────────────┬─────────────┤
-│  Patient   │ Clinical   │    Lab     │  Pharmacy  │  Billing    │
-│  Service   │ Service    │  Service   │  Service   │  Service    │
-│            │  (EMR)     │  (LIS)     │            │             │
-├────────────┼────────────┼────────────┼────────────┼─────────────┤
-│ • Patient  │ • Encounter│ • Orders   │ • Prescr.  │ • Invoices  │
-│   Registry │ • Diagnosis│ • Results  │ • Dispense │ • Insurance │
-│ • Demo-    │ • Notes    │ • Specimens│ • Drug DB  │ • Claims    │
-│   graphics │ • Vitals   │ • Reports  │ • Interact │ • Payments  │
-└────────────┴────────────┴────────────┴────────────┴─────────────┘
-                              │
-              ┌───────────────┼───────────────┐
-              │               │               │
-        ┌─────┴─────┐  ┌─────┴─────┐  ┌──────┴──────┐
-        │ Scheduling │  │  Imaging  │  │ Notification│
-        │  Service   │  │  Service  │  │   Service   │
-        │            │  │  (RIS/    │  │             │
-        │ • Appoint. │  │   PACS)   │  │ • SMS/Email │
-        │ • Calendar │  │ • Studies │  │ • Push      │
-        │ • Waitlist │  │ • Reports │  │ • Alerts    │
-        └────────────┘  └───────────┘  └─────────────┘
-```
+![Tổng quan các Healthcare Microservices — 8 domain services chính trong hệ thống y tế](/storage/uploads/2026/04/healthcare-domain-services-grid.png)
+
+**Core Services:**
+
+| Service | Chức năng chính |
+|---------|----------------|
+| **Patient Service** | Patient Registry, Demographics |
+| **Clinical Service (EMR)** | Encounters, Diagnosis, Notes, Vitals |
+| **Lab Service (LIS)** | Orders, Results, Specimens, Reports |
+| **Pharmacy Service** | Prescriptions, Dispensing, Drug DB |
+| **Billing Service** | Invoices, Insurance, Claims, Payments |
+| **Scheduling Service** | Appointments, Calendar, Waitlist |
+| **Imaging Service (RIS/PACS)** | Studies, Reports |
+| **Notification Service** | SMS/Email, Push, Alerts |
 
 ## 2. Reference Architecture: Secure Healthcare Platform
 
 ### 2.1. High-Level Architecture
 
-```
-                    ┌─────────────────────────┐
-                    │      Internet/WAN        │
-                    └───────────┬──────────────┘
-                                │
-                    ┌───────────▼──────────────┐
-                    │         WAF/CDN          │
-                    │    (Cloudflare/AWS WAF)   │
-                    └───────────┬──────────────┘
-                                │
-                    ┌───────────▼──────────────┐
-                    │      DMZ Network         │
-                    │  ┌─────────────────────┐ │
-                    │  │    API Gateway       │ │
-                    │  │  (Kong / APISIX)     │ │
-                    │  └─────────┬───────────┘ │
-                    └────────────┼──────────────┘
-                                 │
-        ┌────────────────────────┼────────────────────────┐
-        │               Internal Network                   │
-        │                                                  │
-        │    ┌──────────────┐  ┌──────────────┐           │
-        │    │   Keycloak   │  │   Service    │           │
-        │    │   Cluster    │  │    Mesh      │           │
-        │    │  (IAM/SSO)   │  │  (Istio)     │           │
-        │    └──────┬───────┘  └──────┬───────┘           │
-        │           │                  │                    │
-        │    ┌──────▼──────────────────▼───────┐           │
-        │    │      Quarkus Microservices       │           │
-        │    │  ┌─────┐ ┌─────┐ ┌─────┐       │           │
-        │    │  │Pati.│ │Clin.│ │Lab  │ ...    │           │
-        │    │  └──┬──┘ └──┬──┘ └──┬──┘        │           │
-        │    └─────┼───────┼───────┼───────────┘           │
-        │          │       │       │                        │
-        │    ┌─────▼───────▼───────▼───────────┐           │
-        │    │        Data Layer                │           │
-        │    │  ┌──────┐  ┌────┐  ┌─────┐      │           │
-        │    │  │Postgr│  │Kafka│ │Redis │      │           │
-        │    │  │ SQL  │  │    │  │Cache │      │           │
-        │    │  └──────┘  └────┘  └─────┘      │           │
-        │    └─────────────────────────────────┘           │
-        │                                                  │
-        │    ┌─────────────────────────────────┐           │
-        │    │     Observability Stack          │           │
-        │    │  ┌─────┐ ┌──────┐ ┌──────┐      │           │
-        │    │  │ELK  │ │Prome.│ │Jaeger│      │           │
-        │    │  │Stack│ │+Graf.│ │/Tempo│      │           │
-        │    │  └─────┘ └──────┘ └──────┘      │           │
-        │    └─────────────────────────────────┘           │
-        └──────────────────────────────────────────────────┘
-```
+![Kiến trúc tổng quan Healthcare Platform — từ Internet qua WAF, DMZ, API Gateway đến Internal Network](/storage/uploads/2026/04/healthcare-high-level-architecture.png)
 
 ### 2.2. Network Segmentation (Defense-in-Depth)
 
-```
-Zone 1: DMZ (Demilitarized Zone)
-├── API Gateway
-├── Static content / CDN origin
-└── Reverse Proxy
-
-Zone 2: Application Zone
-├── Quarkus Microservices
-├── Keycloak
-└── Message Queue (Kafka)
-
-Zone 3: Data Zone (Most restricted)
-├── PostgreSQL Clusters
-├── Redis Cache
-├── Backup Storage
-└── Key Management (Vault)
-
-Zone 4: Management Zone
-├── Monitoring (Prometheus, Grafana)
-├── Logging (ELK Stack)
-├── CI/CD Pipeline
-└── Admin Access
-```
+![Mô hình Defense-in-Depth với 4 vùng mạng — DMZ, Application, Data, Management](/storage/uploads/2026/04/healthcare-network-segmentation.png)
+
+| Zone | Thành phần |
+|------|------------|
+| **Zone 1: DMZ** | API Gateway, Static content / CDN origin, Reverse Proxy |
+| **Zone 2: Application** | Quarkus Microservices, Keycloak, Message Queue (Kafka) |
+| **Zone 3: Data** (Most restricted) | PostgreSQL Clusters, Redis Cache, Backup Storage, Key Management (Vault) |
+| **Zone 4: Management** | Monitoring (Prometheus, Grafana), Logging (ELK Stack), CI/CD Pipeline, Admin Access |
 
 **Firewall Rules giữa các zones:**
 
@@ -292,53 +218,19 @@ public class PatientResource {
 
 ### 4.1. Data Isolation Strategy
 
-```
-Patient Service ──→ patient_db (PostgreSQL)
-    ├── patients (demographics, contacts)
-    ├── patient_consents
-    └── patient_identifiers
-
-Clinical Service ──→ clinical_db (PostgreSQL)
-    ├── encounters
-    ├── diagnoses
-    ├── clinical_notes (encrypted)
-    └── vital_signs
-
-Lab Service ──→ lab_db (PostgreSQL)
-    ├── lab_orders
-    ├── lab_results (encrypted)
-    ├── specimens
-    └── reference_ranges
-
-Pharmacy Service ──→ pharmacy_db (PostgreSQL)
-    ├── prescriptions
-    ├── dispensing_records
-    └── drug_interactions
-
-Audit Service ──→ audit_db (PostgreSQL - append-only)
-    ├── audit_events (immutable)
-    ├── access_logs
-    └── security_incidents
-```
+![Database-per-Service pattern — mỗi microservice có database riêng biệt với data isolation](/storage/uploads/2026/04/healthcare-database-per-service.png)
+
+| Service | Database | Tables |
+|---------|----------|--------|
+| **Patient Service** | patient_db | patients (demographics, contacts), patient_consents, patient_identifiers |
+| **Clinical Service** | clinical_db | encounters, diagnoses, clinical_notes (encrypted), vital_signs |
+| **Lab Service** | lab_db | lab_orders, lab_results (encrypted), specimens, reference_ranges |
+| **Pharmacy Service** | pharmacy_db | prescriptions, dispensing_records, drug_interactions |
+| **Audit Service** | audit_db (append-only) | audit_events (immutable), access_logs, security_incidents |
 
 ### 4.2. Shared Data via Events (Event Sourcing)
 
-```
-┌──────────┐     ┌─────────┐     ┌──────────┐
-│ Patient  │────▶│  Kafka  │────▶│ Clinical │
-│ Service  │     │ Topics  │     │ Service  │
-└──────────┘     │         │     └──────────┘
-                 │ patient.│
-                 │ created │────▶┌──────────┐
-                 │ patient.│     │   Lab    │
-                 │ updated │     │ Service  │
-                 │ patient.│     └──────────┘
-                 │ consent.│
-                 │ changed │────▶┌──────────┐
-                 └─────────┘     │ Pharmacy │
-                                 │ Service  │
-                                 └──────────┘
-```
+![Event-driven architecture — Patient Service publish events qua Kafka đến các consuming services](/storage/uploads/2026/04/healthcare-event-sourcing-kafka.png)
 
 > **Quan trọng**: Kafka messages chứa PHI phải được mã hóa. Sử dụng Kafka encryption at-rest và application-level encryption cho sensitive fields.
 

package/content/series/architecture/xay-dung-he-thong-y-te-microservices/chapters/01-phan-1-kien-truc-nen-tang/lessons/03-bai-3-phan-loai-du-lieu-y-te-danh-gia-rui-ro.md

@@ -0,0 +1,258 @@
+---
+id: 019e1a40-a103-7001-d001-f0a1b2c30103
+title: 'Bài 3: Phân loại Dữ liệu Y tế (PHI/ePHI) & Đánh giá Rủi ro'
+slug: bai-3-phan-loai-du-lieu-y-te-danh-gia-rui-ro
+description: >-
+  Phân loại dữ liệu y tế theo mức độ nhạy cảm: PHI, ePHI, PII, dữ liệu
+  lâm sàng, dữ liệu hành chính. Xây dựng Data Classification Policy,
+  Data Flow Mapping, Risk Assessment theo NIST SP 800-30, và thiết lập
+  Risk Register cho hệ thống microservices y tế.
+duration_minutes: 120
+is_free: true
+video_url: null
+sort_order: 3
+section_title: "Phần 1: Kiến trúc & Nền tảng"
+course:
+  id: 019e1a40-a100-7001-d001-f0a1b2c30001
+  title: Xây dựng Hệ thống Y tế Microservices — Quarkus, PostgreSQL, Keycloak chuẩn HIPAA
+  slug: xay-dung-he-thong-y-te-microservices
+---
+
+## 1. Data Classification Framework cho Y Tế
+
+![Kim tự tháp phân loại dữ liệu y tế — 4 cấp độ từ Public đến Restricted](/storage/uploads/2026/04/healthcare-data-classification-pyramid.png)
+
+### 1.1. Tại sao cần phân loại dữ liệu?
+
+Không phải tất cả dữ liệu đều cần cùng mức độ bảo vệ. Phân loại dữ liệu giúp:
+
+- **Tối ưu chi phí bảo mật**: Tập trung resources vào dữ liệu quan trọng nhất
+- **Tuân thủ pháp luật**: Áp dụng đúng controls theo yêu cầu quy định
+- **Giảm attack surface**: Hạn chế phạm vi dữ liệu nhạy cảm
+- **Incident response**: Ưu tiên xử lý khi xảy ra breach
+
+### 1.2. Healthcare Data Classification Levels
+
+![Kim tự tháp phân loại dữ liệu y tế — 4 mức từ Public đến Restricted](/storage/uploads/2026/04/healthcare-data-classification-levels.png)
+
+| Level | Tên | Ví dụ | Encryption | Access | Audit |
+|-------|-----|--------|------------|--------|-------|
+| **4 - RESTRICTED** | Hạn chế tối đa | HIV/AIDS, sức khỏe tâm thần, di truyền, điều trị nghiện, sức khỏe sinh sản | Required (AES-256) | Named individuals only | Full logging, real-time alerts |
+| **3 - CONFIDENTIAL** | Bảo mật | Hồ sơ bệnh án, xét nghiệm, đơn thuốc, chẩn đoán hình ảnh, BHYT | Required (AES-256) | Role-based (treating clinicians) | Full logging |
+| **2 - INTERNAL** | Nội bộ | Lịch hẹn, thống kê (ẩn danh), nhân viên y tế, cấu hình | Recommended | Department-based | Standard logging |
+| **1 - PUBLIC** | Công khai | Danh mục dịch vụ, giờ làm việc, liên hệ bệnh viện, hướng dẫn SK | Not required | Public | Basic logging |
+
+### 1.3. Data Classification trong PostgreSQL Schema
+
+```sql
+-- Data classification metadata table
+CREATE TABLE data_classification (
+    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+    schema_name VARCHAR(100) NOT NULL,
+    table_name VARCHAR(100) NOT NULL,
+    column_name VARCHAR(100) NOT NULL,
+    classification_level INTEGER NOT NULL CHECK (classification_level BETWEEN 1 AND 4),
+    classification_label VARCHAR(50) NOT NULL,
+    contains_phi BOOLEAN DEFAULT false,
+    encryption_required BOOLEAN DEFAULT false,
+    masking_rule VARCHAR(100),
+    retention_days INTEGER,
+    legal_basis TEXT,
+    created_at TIMESTAMPTZ DEFAULT NOW(),
+    updated_at TIMESTAMPTZ DEFAULT NOW()
+);
+
+-- Ví dụ classification cho patient table
+INSERT INTO data_classification (schema_name, table_name, column_name,
+    classification_level, classification_label, contains_phi, encryption_required, masking_rule)
+VALUES
+    ('public', 'patients', 'id', 2, 'INTERNAL', false, false, NULL),
+    ('public', 'patients', 'full_name', 3, 'CONFIDENTIAL', true, true, 'PARTIAL_MASK'),
+    ('public', 'patients', 'date_of_birth', 3, 'CONFIDENTIAL', true, false, 'YEAR_ONLY'),
+    ('public', 'patients', 'cccd_number', 3, 'CONFIDENTIAL', true, true, 'FULL_MASK'),
+    ('public', 'patients', 'phone', 3, 'CONFIDENTIAL', true, true, 'PARTIAL_MASK'),
+    ('public', 'patients', 'email', 3, 'CONFIDENTIAL', true, true, 'PARTIAL_MASK'),
+    ('public', 'patients', 'address', 3, 'CONFIDENTIAL', true, true, 'CITY_ONLY'),
+    ('public', 'patients', 'blood_type', 2, 'INTERNAL', false, false, NULL),
+    ('public', 'patients', 'hiv_status', 4, 'RESTRICTED', true, true, 'FULL_MASK'),
+    ('public', 'patients', 'insurance_number', 3, 'CONFIDENTIAL', true, true, 'PARTIAL_MASK');
+```
+
+## 2. Data Flow Mapping
+
+### 2.1. PHI Data Flow trong Microservices
+
+![Luồng dữ liệu PHI qua các microservices — từ Patient Portal qua API Gateway, Keycloak đến các services và databases](/storage/uploads/2026/04/healthcare-phi-data-flow.png)
+
+### 2.2. Data Flow Documentation Template
+
+| # | Data Element | Source | Destination | Transport | Encryption | Classification |
+|---|-------------|--------|-------------|-----------|------------|----------------|
+| 1 | Patient Name | Portal | Patient Service | HTTPS/TLS 1.3 | In-transit + At-rest | L3 |
+| 2 | Lab Results | Lab Instrument | Lab Service | HL7v2/MLLP over TLS | In-transit + At-rest | L3 |
+| 3 | Diagnosis Code | Clinical Service | Billing Service | Kafka (SSL) | Application-level | L3 |
+| 4 | HIV Status | Clinical Service | Clinical DB | JDBC/SSL | Column encryption | L4 |
+| 5 | Audit Event | All Services | Audit Service | Kafka (SSL) | Event encryption | L2 |
+| 6 | Appointment | Scheduling Service | Notification Service | Kafka (SSL) | In-transit | L2 |
+
+## 3. Risk Assessment theo NIST SP 800-30
+
+### 3.1. Risk Assessment Methodology
+
+![6 bước đánh giá rủi ro theo NIST SP 800-30 — từ xác định Threats đến Risk Response](/storage/uploads/2026/04/healthcare-risk-assessment-steps.png)
+
+### 3.2. Threat Identification cho Healthcare Microservices
+
+| Threat Category | Threat | Threat Source |
+|----------------|--------|---------------|
+| **External** | SQL Injection vào Patient Service | Attacker |
+| **External** | Ransomware mã hóa database | Cybercriminal |
+| **External** | MITM attack trên API calls | Network attacker |
+| **External** | Credential stuffing vào Patient Portal | Bot network |
+| **Internal** | Nhân viên truy cập PHI trái phép | Insider |
+| **Internal** | Database admin export toàn bộ patient data | Privileged user |
+| **Internal** | Developer hardcode credentials | Negligent employee |
+| **Environmental** | Database corruption do hardware failure | Infrastructure |
+| **Environmental** | Mất dữ liệu do thiên tai | Natural disaster |
+| **Supply Chain** | Vulnerability trong Quarkus dependency | Third-party |
+
+### 3.3. Vulnerability Assessment
+
+```java
+// Ví dụ: Checklist kiểm tra vulnerabilities trong Quarkus service
+public class SecurityVulnerabilityChecklist {
+
+    // V1: SQL Injection - Sử dụng parameterized queries
+    // ❌ VULNERABLE
+    String badQuery = "SELECT * FROM patients WHERE name = '" + userInput + "'";
+
+    // ✅ SECURE
+    @NamedQuery(name = "Patient.findByName",
+                query = "SELECT p FROM Patient p WHERE p.name = :name")
+    List<Patient> findByName(@Param("name") String name);
+
+    // V2: Broken Authentication - Token validation
+    // ❌ VULNERABLE: Không verify token
+    String userId = jwt.getClaim("sub"); // Không verify expiration, issuer
+
+    // ✅ SECURE: Quarkus OIDC tự động verify
+    @Authenticated
+    @RolesAllowed("doctor")
+    public Response getPatient(UUID id) { ... }
+
+    // V3: Sensitive Data Exposure in Logs
+    // ❌ VULNERABLE
+    log.info("Patient created: " + patient.toString()); // Logs PHI!
+
+    // ✅ SECURE
+    log.info("Patient created: id={}", patient.getId()); // Only log ID
+}
+```
+
+### 3.4. Risk Matrix
+
+![Ma trận đánh giá rủi ro 5x5 — Likelihood x Impact từ LOW đến CRITICAL](/storage/uploads/2026/04/healthcare-risk-matrix-heatmap.png)
+
+| | Negligible (1) | Low (2) | Medium (3) | High (4) | Critical (5) |
+|-|----------------|---------|------------|----------|-------------|
+| **Very High (5)** | LOW | MEDIUM | HIGH | CRITICAL | CRITICAL |
+| **High (4)** | LOW | MEDIUM | HIGH | HIGH | CRITICAL |
+| **Medium (3)** | LOW | LOW | MEDIUM | HIGH | HIGH |
+| **Low (2)** | LOW | LOW | LOW | MEDIUM | MEDIUM |
+| **Very Low (1)** | LOW | LOW | LOW | LOW | MEDIUM |
+
+## 4. Risk Register cho Healthcare Microservices
+
+### 4.1. Risk Register Template
+
+| ID | Risk Description | Likelihood | Impact | Risk Level | Mitigation | Owner | Status |
+|----|-----------------|------------|--------|------------|------------|-------|--------|
+| R001 | SQL Injection vào Patient API | Medium (3) | Critical (5) | HIGH | Parameterized queries, input validation, WAF | Dev Team | Mitigated |
+| R002 | Insider access PHI không authorized | High (4) | High (4) | HIGH | RBAC, RLS, Audit logging, DLP | Security Team | In Progress |
+| R003 | Ransomware mã hóa patient_db | Medium (3) | Critical (5) | HIGH | Immutable backups, network segmentation, EDR | Ops Team | Mitigated |
+| R004 | Keycloak token theft | Medium (3) | High (4) | HIGH | Short-lived tokens, mTLS, DPoP | Dev Team | In Progress |
+| R005 | PHI exposure in logs | High (4) | High (4) | HIGH | Log sanitization, PHI detection in CI/CD | Dev Team | Open |
+| R006 | Unencrypted PHI in Kafka | Medium (3) | High (4) | HIGH | Application-level encryption, Kafka SSL | Dev Team | Open |
+| R007 | Database backup theft | Low (2) | Critical (5) | MEDIUM | Encrypted backups, key management | Ops Team | Mitigated |
+| R008 | API key/credential exposure | Medium (3) | High (4) | HIGH | Vault secrets management, no hardcoded secrets | All Teams | In Progress |
+| R009 | DDoS on patient portal | Medium (3) | Medium (3) | MEDIUM | Rate limiting, WAF, CDN | Ops Team | Mitigated |
+| R010 | Third-party dependency CVE | High (4) | Medium (3) | HIGH | Automated scanning, Dependabot, SBOM | Dev Team | Ongoing |
+
+### 4.2. Risk Treatment Plan
+
+![4 chiến lược xử lý rủi ro — Mitigate, Transfer, Accept, Avoid](/storage/uploads/2026/04/healthcare-risk-response-strategies.png)
+
+- **MITIGATE** (Giảm thiểu) ← Preferred cho HIGH risks: Implement controls, giảm likelihood/impact
+- **TRANSFER** (Chuyển giao): Cyber insurance, outsource cho specialist provider
+- **ACCEPT** (Chấp nhận) ← Chỉ cho LOW risks: Document risk acceptance, monitor
+- **AVOID** (Tránh): Loại bỏ nguồn rủi ro, thay đổi architecture
+
+## 5. Data Retention Policy
+
+### 5.1. Retention Requirements cho Y Tế Việt Nam
+
+| Loại dữ liệu | Thời gian lưu trữ | Cơ sở pháp lý |
+|---------------|-------------------|----------------|
+| Hồ sơ bệnh án ngoại trú | 10 năm | Thông tư 46/2018/TT-BYT |
+| Hồ sơ bệnh án nội trú | 20 năm | Thông tư 46/2018/TT-BYT |
+| Hồ sơ bệnh án tử vong | 20 năm | Thông tư 46/2018/TT-BYT |
+| Kết quả xét nghiệm | 10 năm | Quy định bệnh viện |
+| Chẩn đoán hình ảnh | 10 năm | Quy định bệnh viện |
+| Audit logs | 6 năm (HIPAA) | HIPAA §164.530(j) |
+| Đơn thuốc | 5 năm | Luật Dược |
+| Consent records | Lifetime + 6 years | HIPAA / NĐ 13/2023 |
+
+### 5.2. Automated Retention trong PostgreSQL
+
+```sql
+-- Partition strategy for data retention
+CREATE TABLE audit_events (
+    id UUID DEFAULT gen_random_uuid(),
+    event_time TIMESTAMPTZ NOT NULL DEFAULT NOW(),
+    event_type VARCHAR(50) NOT NULL,
+    actor_id UUID NOT NULL,
+    resource_type VARCHAR(100) NOT NULL,
+    resource_id UUID,
+    action VARCHAR(20) NOT NULL,
+    outcome VARCHAR(20) NOT NULL,
+    details JSONB
+) PARTITION BY RANGE (event_time);
+
+-- Create monthly partitions
+CREATE TABLE audit_events_2026_01 PARTITION OF audit_events
+    FOR VALUES FROM ('2026-01-01') TO ('2026-02-01');
+
+CREATE TABLE audit_events_2026_02 PARTITION OF audit_events
+    FOR VALUES FROM ('2026-02-01') TO ('2026-03-01');
+
+-- Automated partition management
+-- Drop partitions older than retention period (6 years for HIPAA)
+-- Archive to cold storage before dropping
+```
+
+## 6. Tổng kết
+
+Trong bài học này, chúng ta đã:
+
+- Xây dựng **Data Classification Framework** 4 cấp cho dữ liệu y tế
+- Tạo **Data Flow Mapping** cho PHI qua microservices architecture
+- Thực hiện **Risk Assessment** theo NIST SP 800-30 methodology
+- Thiết lập **Risk Register** với risk treatment plans
+- Định nghĩa **Data Retention Policy** theo quy định Việt Nam và HIPAA
+
+## Bài tập
+
+1. Phân loại tất cả tables/columns trong database hệ thống y tế của bạn theo 4 cấp
+2. Vẽ Data Flow Diagram cho 3 use cases chính: đăng ký khám, ghi nhận kết quả xét nghiệm, kê đơn thuốc
+3. Thực hiện Risk Assessment và tạo Risk Register cho ít nhất 15 risks
+4. Xây dựng Data Retention Policy phù hợp với tổ chức
+
+---
+
+---
+
+<!-- SERIES-NAV:START -->
+| ◀ Bài trước | Bài tiếp theo ▶ |
+|:---|---:|
+| [Bài 2: Kiến trúc Microservices An toàn cho Y Tế với Quarkus Stack](/series/bao-mat-du-lieu-y-te-cho-microservices/bai-2-kien-truc-microservices-an-toan-cho-y-te) | [Bài 4: Threat Modeling STRIDE/DREAD cho Health Information System](/series/bao-mat-du-lieu-y-te-cho-microservices/bai-4-threat-modeling-stride-dread-cho-his) |
+<!-- SERIES-NAV:END -->