UDENTIVA nhúng chính sự trưởng thành quy trình được yêu cầu đối với phần mềm y tế vào bản thân kiến trúc. Trang này trình bày cùng với bằng chứng: vòng đời phát triển của chúng tôi, các cấp năng lực SPICE / ISO-IEC 15504, các cơ chế ghi nhật ký lỗi và kiểm soát liên tục, các tiêu chí phiên bản và bảo mật, cùng lịch sử phát triển.
Căn cứ: Quy định về Hệ thống Quản lý Thông tin Y tế (Số Văn bản 39682) điều 6 và điều 20 — yêu cầu chứng nhận chất lượng phần mềm (CMMI/SPICE).
Định nghĩa quy trình, việc thực thi và các sản phẩm công việc có thể truy vết đã được cấu trúc hóa; các cơ chế đo lường định lượng, phòng ngừa lỗi và cải tiến liên tục đang được vận hành trong sản xuất. Việc công bố mức năng lực chính thức phải thuộc phạm vi đánh giá độc lập (appraisal).
SPICE đánh giá các quy trình theo mức năng lực từ 0 đến 5. UDENTIVA được cấu trúc để đáp ứng kỳ vọng của Mức 1-3 ở tầng định nghĩa quy trình/thực thi/sản phẩm công việc có thể truy vết; đối với Mức 4-5, các cơ chế đo lường định lượng và cải tiến liên tục đang được vận hành. Việc công bố mức chính thức phụ thuộc vào đánh giá độc lập.
Các cơ chế kiểm soát định lượng và cải tiến liên tục thuộc Mức 4-5 được vận hành cùng bằng chứng đi kèm (đo lường trực tiếp, sổ ghi lỗi/CAPA, nhật ký triển khai).
Mỗi lĩnh vực quy trình tương ứng với một triển khai cụ thể trong UDENTIVA và một bằng chứng có thể kiểm toán. Quy trình không phải là một tài liệu, mà là mã đang chạy.
| Vùng Quy trình | Ứng dụng UDENTIVA | Bằng chứng |
|---|---|---|
| ENG.1 Thu thập yêu cầu | Định nghĩa yêu cầu theo bản đồ giai đoạn + vertical slice; UDENTIVA.md khóa các yêu cầu của hợp đồng dự án. | UDENTIVA.md (QUY TẮC VÀNG), đặc tả kỹ thuật 02_tech_spec/, bản đồ giai đoạn/mô-đun |
| ENG.4 Thiết kế phần mềm | Monolith mô-đun hóa; các gói ngữ cảnh (context) không chia sẻ bảng của nhau; giao tiếp qua interface; dịch vụ bên ngoài = adapter. | quy tắc biên internal/{identity,patient,billing,export,...}; ADR-001..008 |
| ENG.5 Xây dựng phần mềm | SQL tường minh (sqlc, không ORM); context là tham số đầu tiên trong mọi hàm; bọc lỗi %w; tiền = numeric. | ghi đè kiểu trong sqlc.yaml (numeric→string), db/queries/*.sql, gofmt/golangci-lint |
| ENG.6 Tích hợp phần mềm | Chuỗi loopback PHP(BFF) ↔ Go ↔ PostgreSQL ↔ Redis; bề mặt public duy nhất. | web/core/ApiClient, tình trạng thành phần /healthz (db+redis) |
| ENG.7 Kiểm thử phần mềm | Kiểm thử cô lập cross-tenant (quan trọng nhất), idempotency, xung đột lịch hẹn, độ chính xác tiền tệ, 2FA/OTP, vector TOTP RFC6238, QR (xác minh OpenCV+ISO). | internal/integration/*_test.go, platform/totp/totp_test.go, go test ./... |
| SUP.1 Đảm bảo chất lượng | Mỗi PR bắt buộc phải tuân theo QUY TẮC VÀNG; lint sạch; nếu kiểm thử cô lập bị đỏ trên CI thì không merge. | golangci-lint, Definition of Done kontrol listesi |
| SUP.8 Quản lý cấu hình | Kiểm soát phiên bản Git (branch core); phiên bản hóa lược đồ tuần tự bằng goose; các artefact build được sao lưu. | git, goose_db_version tablosu, .tools/deploy yedekleri |
| SUP.9 Giải quyết vấn đề | Bản ghi kiểm toán chỉ bổ sung (append-only) + outbox e-mail/SMS (mỗi lần gửi được ghi lại) + kỷ luật sao lưu/rollback triển khai. | audit_log, email_outbox/sms_outbox, bin/server.exe.bak-* rollback |
| SUP.10 Quản lý yêu cầu thay đổi | Mỗi thay đổi lược đồ là một migration đánh số mới; có thể hoàn tác (goose Down); phê duyệt của classifier khi triển khai. | db/migrations/0001..0027, +goose Up/Down |
| MAN.3 Quản lý dự án | Bàn giao theo vertical slice (mỗi lát cắt chạy đầu-cuối); ghi chú bàn giao phiên làm việc. | super-devam.md, faz tablosu (DoD per dilim) |
| MAN.6 Đo lường | Kiểm tra tình trạng, đo lường công suất, số liệu gửi e-mail/SMS, khối lượng audit, telemetry sự kiện trực tiếp. | /healthz, bảng điều khiển Giám sát quy trình & Chất lượng (sự kiện/lỗi/triển khai/KPI) |
Trách nhiệm được phân tách theo tầng; quyền lực domain nằm ở một điểm duy nhất và được cô lập bằng loopback. Trình duyệt chỉ nhìn thấy BFF mỏng, không bao giờ truy cập trực tiếp được vào tầng domain và tầng dữ liệu.
| Tầng | Trách nhiệm & Bảo mật | Vị trí |
|---|---|---|
| Sunum (BFF) | PHP 8.4 — BFF mỏng: phiên, render, CSRF, định tuyến. KHÔNG có quy tắc nghiệp vụ/DB. Bề mặt public duy nhất (IIS:443). | web/ |
| Uygulama / Domain | Monolith mô-đun hóa bằng Go — thẩm quyền DUY NHẤT của domain. RBAC, quy tắc nghiệp vụ, transaction. Chỉ lắng nghe 127.0.0.1. | api/internal/ |
| Veri | PostgreSQL — mỗi bảng có tenant_id + RLS FORCE; SQL tường minh (sqlc), có tham số. Tiền là numeric. | api/db/ |
| Bộ nhớ đệm / Hàng đợi | Redis — phiên, idempotency, khóa phân tán, hàng đợi asynq (SMS/e-fatura). | platform/redisx |
| Nesne Depolama | Tương thích S3 — tệp lớn (X-quang) presigned/stream; blob không bao giờ nằm trong DB. | platform/storage |
| Dịch vụ bên ngoài (adapter) | e-Fatura, SMS(NetGSM), e-mail(SMTP), (sau này e-Nabız/MEDULA/DICOM) — trừu tượng hóa phía sau interface. | internal/notify |
Đo lường không phải là một tuyên bố, mà là một hệ thống đang chạy. Mọi thao tác được đếm trực tiếp (thành công/thất bại), các lỗi phát sinh được ghi vào sổ lưu vĩnh viễn, và khung KPI dưới đây được gắn với các hành động định kỳ. Các nguồn dữ liệu là bảng thật: event_counter (bộ đếm thao tác trực tiếp), error_log (sổ lưu lỗi vĩnh viễn), deploy_log (sổ lưu triển khai).
| Vùng Đo lường | KPI | Mục tiêu | Nguồn Dữ liệu | Kỳ | Hành động |
|---|---|---|---|---|---|
| Bảo mật cô lập tenant | cross-tenant test fail | 0 | CI / izolasyon testi | her PR | Chặn merge |
| Lỗi sản xuất | lỗi hiển thị (5xx/panic) | 0 | error_log (lâu dài) | liên tục/trực tiếp | RCA + CAPA zorunlu |
| Tỷ lệ giao dịch thành công | success / toplam event | ≥ 99% | event_counter (trực tiếp) | liên tục/trực tiếp | Nguyên nhân gốc khi sụt giảm |
| Thời gian giải quyết | MTTR (thời gian giải quyết trung bình) | ↓ xu hướng giảm | error_log (resolved) | hàng tháng | Trend incelemesi |
| Độ tin cậy triển khai | tỷ lệ rollback | < %5 | deploy_log | 30 ngày | Rollback review |
| Bảo mật danh tính | 2FA/OTP kritik olay | 0 | audit + event_counter | hàng tháng | Gia cố (hardening) |
| Độ tin cậy nhắn tin | SMS/e-posta failure | ↓ thấp | *_outbox | theo ngày | review nhà cung cấp |
| Sẵn sàng khôi phục | tỷ lệ thành công của kiểm thử restore | %100 | DR test (hedef) | hàng quý | Cập nhật Runbook |
Mỗi lỗi phát sinh đều đi qua một chu trình phân tích nguyên nhân gốc (RCA) và hành động khắc phục/phòng ngừa (CAPA) tiêu chuẩn; việc lặp lại cùng một lỗi được ngăn chặn bằng kiểm soát hồi quy và theo dõi xu hướng.
Lỗi sản xuất (5xx/panic) được tự động bắt giữ → error_log lâu dài (khi cùng một chữ ký lặp lại thì count++, xu hướng lỗi).
Xác định mức độ (error/panic), tác động và số lần lặp lại; đo lường mức độ phổ biến bằng các bộ đếm sự kiện thất bại.
Phân tích nguyên nhân gốc được thực hiện và ghi lại trên bảng điều khiển Giám sát quy trình.
Hành động khắc phục + hành động phòng ngừa (mã, kiểm thử, quy tắc migration, kiểm soát bảo mật) được xác định và ghi lại.
Thêm kiểm thử/quy tắc ngăn chặn cùng một lỗi tái diễn; được giám sát bằng telemetry liên tục.
Xu hướng KPI (MTTR, tỷ lệ lỗi, rollback) được đánh giá định kỳ; đối với lỗi tái diễn, một hành động cấp quy trình được mở ra.
Cốt lõi của SPICE Mức 5: liên tục ghi log lỗi, giữ chúng trong tầm kiểm soát, phòng ngừa khuyết tật và cải tiến liên tục. UDENTIVA vận hành các cơ chế này trong môi trường sản xuất.
audit_log không thể thay đổi (append-only) ghi lại mọi thao tác quan trọng; email_outbox/sms_outbox ghi lại lâu dài mọi lần gửi (status, attempts, error). Không có sự kiện nào bị mất một cách âm thầm.
Phong bì lỗi nhất quán {error:{code,message}}; lỗi nội bộ/stack không bao giờ bị rò rỉ. Sao lưu binary + web trước mỗi lần triển khai; khi có outage, rollback trong vài giây bằng bin/server.exe.bak-*.
Kiến trúc fail-closed: không có ngữ cảnh RLS thì 0 dòng; idempotency ngăn thao tác trùng lặp; tiền numeric khiến lỗi float là bất khả thi; whitelist (export dataset) ngăn chặn SQL injection. Lỗi được ngăn chặn ngay từ đầu bằng thiết kế.
Các thành phần quan trọng được xác minh bằng hai phương pháp độc lập: vector kiểm thử TOTP RFC6238, giải mã OpenCV cv2 + codeword tham chiếu ISO/IEC 18004 cho QR, kiểm thử cô lập cross-tenant.
Ở mỗi phiên làm việc, kiểm toán bảo mật → phát hiện → gia cố (ví dụ đã thêm RBAC faz2/faz3, 2FA, Export API). Bộ nhớ tổ chức được bảo tồn qua ghi chú quy trình (super-devam.md).
Yêu cầu quy định mới (VEM Görüntüsü) được chuyển trực tiếp thành tính năng sản phẩm và bằng chứng; các thay đổi pháp lý được giám sát liên tục và được ghi vào bản đồ tuân thủ.
Một mã nguồn duy nhất, thu hẹp bằng cờ (flag) — không fork.
Phiên bản có thể truy vết ở tầng lược đồ, mã nguồn, triển khai và API.
Toàn bộ quy trình phát triển nằm trong kiểm soát phiên bản; mỗi lần triển khai đều có thể hoàn tác (rewind/rollback).
Bảo mật không phải là một tính năng, mà là chính kiến trúc. Những quy tắc mà vi phạm sẽ khiến PR bị từ chối, không thương lượng:
Hệ thống được xây dựng bằng các lát cắt dọc, mỗi lát chạy từ đầu đến cuối. Bên dưới là các giai đoạn (phase) và trình tự thời gian của các công tác bảo mật/quy định gần đây.
pgx+sqlc, goose, kiểm thử RLS fail-closed, WithTenantTx, middleware phiên, đăng nhập+RBAC, audit, loopback PHP↔Go, nền tảng asynq, health.
CRUD bệnh nhân + kiểm thử cô lập cross-tenant → Lịch hẹn (exclusion constraint + Redis lock) → Odontogram/Kế hoạch điều trị (FDI, append-only) → Thu tiền/Công nợ/Két → e-Fatura adapter (fast-follow) → Kho → X-quang (S3) → Nhắc nhở SMS (asynq backoff).
Tier vận hành nền tảng (siêu quản trị) (X-Platform-Key, mặt phẳng danh tính riêng); quản lý tenant, mô hình đăng ký/lập hóa đơn, đo lường công suất, trình chỉnh sửa phiên bản pháp lý, reCAPTCHA, cài đặt NetGSM.
i18n (20 dil, key-based, RTL); 20 tema + klinik public site (/s/{slug}) + lead-booking; demo klinik siteleri.
Primitive OTP dùng chung; đặt lại mật khẩu + magic-link + kích hoạt tài khoản (SMTP thật); SMS lõi NetGSM; xác thực public đa tenant; quản lý người dùng phòng khám.
TOTP (RFC6238) + mã dự phòng; QR BẮT BUỘC (độc lập bên ngoài, qr.js sạch CSP; được xác minh độc lập bằng OpenCV+ISO); xác minh số điện thoại qua SMS (đồng ý KVKK).
VEM Görüntüsü (Mô hình dữ liệu tối thiểu) 12 export view + Export API (do SuperUser định nghĩa, khóa theo tenant, fail-closed); bản đồ Pháp lý & Tuân thủ; sửa đổi hợp đồng pháp lý hướng đến 100% tuân thủ quy định.
Trung tâm hỗ trợ có theo dõi ticket; tài liệu quy trình SPICE (trang này); kiểm toán bảo mật liên tục + gia cố.
Để biết thông tin chi tiết về kiến trúc, bảo mật và tuân thủ quy định, hãy liên hệ với đội ngũ của chúng tôi.
We use cookies necessary for core functionality; analytics and marketing cookies are enabled only with your consent. Chính sách Cookie