# NCV DCIMS 0.2.30 - Hướng dẫn sử dụng Quản trị viên (ADMIN)

**NCV DCIMS — NCV Dental Clinical Image Management System**

Phiên bản tài liệu: 30/09/2026. Dành riêng cho Quản trị viên (ADMIN). Có thể đọc độc lập, không cần đọc tài liệu vai trò khác.

Cách đọc: xem phần bắt đầu nhanh, thao tác chung, chương của vai trò và phần xử lý lỗi. Phụ lục ảnh có số hình, đường đi trên giao diện và hướng dẫn đọc ảnh. Ảnh được nhúng để có thể phóng to trong trình đọc PDF.

Ảnh minh họa: giao diện production 0.2.30 chạy cục bộ, API mô phỏng với dữ liệu giả. Tên “Bệnh nhân giả”, “Cơ sở minh họa” và số 0000000000 không đại diện người thật. Tài khoản minh họa không phải tài khoản đăng nhập NAS. Các ô trống dùng để chỉ rõ nơi cần thao tác, không phải ví dụ ca đã hoàn tất.

## Những điểm cần biết trong 0.2.30-r2

Ứng dụng là **0.2.30**; **r2** là revision bộ cài sửa quyền đọc mã chương trình trong image NAS. Tài liệu chốt ngày **30/09/2026**. NAS hiện tại đã cập nhật và đăng nhập bình thường; nhận tài liệu này không cần chạy cập nhật lại.

- Danh sách bệnh nhân lấy dữ liệu từ server, **25 hồ sơ mỗi trang**. Xem tổng số hồ sơ, dùng nút trang trước/trang sau; không kết luận bệnh nhân không tồn tại chỉ vì chưa thấy ở trang hiện tại. Tìm kiếm, lọc và sắp xếp áp dụng trên toàn bộ phạm vi được phép. Các số ca/cần bổ sung trong trang phản ánh trang hiện tại; tổng hồ sơ phản ánh kết quả tìm/lọc.
- Khi chọn đồng thời Bác sĩ và Dịch vụ, kết quả phải có **cùng một ca điều trị** thỏa cả hai điều kiện. Muốn tìm ca khác, điều chỉnh bộ lọc thay vì mở rộng quyền tài khoản.
- Back/Forward khôi phục hồ sơ đã mở kể cả khi hồ sơ không ở trang danh sách hiện tại; quyền truy cập vẫn được kiểm lại.
- Xóa ca điều trị sẽ thu hồi các link chia sẻ của ca. **Khôi phục ca không phục hồi link cũ**; người có quyền phải tạo link mới và gửi lại cho người nhận được phép.
- Nếu đăng nhập báo quá nhiều yêu cầu, chờ rồi thử lại; không bấm liên tục hoặc mở nhiều phiên đăng nhập cùng lúc.
- Trong Cài đặt, tiêu đề các khối không còn icon đứng trước. Icon trên menu và các nút vẫn được giữ. Các quyền nghiệp vụ của ADMIN, DOCTOR, LABO không đổi.

Ảnh trong PDF được chụp lại từ frontend build 0.2.30 ngày 30/09/2026, API mô phỏng và dữ liệu giả. Ảnh minh họa cách thao tác; không chứng nhận ghi dữ liệu, authorization hay UAT trên NAS.

## Bắt đầu nhanh

1. Đăng nhập và đổi mật khẩu tạm.
2. Kiểm tra **Cài đặt → Cơ sở → Tài khoản**.
3. Tạo từng tài khoản đúng vai trò; DOCTOR có cơ sở chính.
4. Kiểm tra hồ sơ, thùng rác và cấu hình tích hợp theo quyền.
5. Bàn giao từng PDF cho đúng người; công việc NAS dùng tài liệu vận hành riêng.

Quyền thực tế phụ thuộc permission, phạm vi dữ liệu, quan hệ ca/lần khám và trạng thái hồ sơ. Nếu không có nút, đọc hướng dẫn lỗi hoặc liên hệ quản trị; không mượn tài khoản khác.

## Thao tác chung

Tên tab trình duyệt của bản 0.2.30 là **DCIMS - Nụ Cười Việt**. Mỗi người dùng tài khoản riêng. Ảnh trong tài liệu chụp từ giao diện 0.2.30 với API mô phỏng và dữ liệu giả, không phải dữ liệu bệnh nhân hay bằng chứng nghiệm thu NAS.


### 2.1 Đăng nhập và phiên làm việc

1. Mở đúng địa chỉ HTTPS do quản trị viên cung cấp.
2. Nhập username và mật khẩu; không dùng tài khoản của người khác.
3. Có thể nhấn biểu tượng mắt để kiểm tra nội dung vừa nhập; nhấn lại để che mật khẩu trước khi người khác nhìn màn hình.
4. Nếu hệ thống yêu cầu đổi mật khẩu, đặt mật khẩu mới trước khi tiếp tục.
5. Khi rời máy, dùng menu tài khoản để đăng xuất; không chỉ đóng tab trình duyệt.
6. Nếu tài khoản bị khóa, đổi vai trò/cơ sở hoặc bị xóa, các phiên đang mở có thể bị thu hồi và trở về màn hình đăng nhập.

Không lưu mật khẩu vào tài liệu, ảnh chụp hoặc trình nhắn tin. Không gửi cookie, token, secret API hoặc URL chia sẻ còn hiệu lực cho người không được phép.

### 2.2 Điều hướng và responsive

- Desktop/tablet ngang dùng menu trái; tablet dọc/điện thoại dùng menu mở từ nút hamburger.
- Điện thoại ngang có vùng cuộn menu riêng; cuộn trong menu để thấy đủ mục.
- Dùng **Tổng quan** cho công việc gần đây, **Bệnh nhân** cho hồ sơ/ca, **Hồ sơ đã xóa gần đây** cho dữ liệu có thể khôi phục và **Cài đặt** cho chức năng quản trị.
- Có thể dùng Back/Forward hoặc vuốt lùi/tiến của trình duyệt để trở lại lần lượt menu, hồ sơ, ca/lần khám hoặc tab Cài đặt đã mở trước đó; mỗi thao tác chỉ lùi hoặc tiến một bước trong lịch sử nội bộ.
- Khi quay về entry trước, sidebar, menu tài khoản hoặc popup tạm đang mở sẽ đóng để tránh che màn hình đích.
- Popup đóng bằng X, phím Esc hoặc click vùng nền. Nếu popup lồng nhau, mỗi lần chỉ đóng lớp trên cùng.
- Khi upload/ghi dữ liệu đang chạy, không refresh hoặc đóng popup bằng cách cưỡng ép; chờ kết quả hoặc dùng nút hủy nếu có.

### 2.3 Tìm kiếm bệnh nhân an toàn

1. Tìm bằng họ tên trước khi tạo hồ sơ mới.
2. ADMIN/DOCTOR có quyền cập nhật có thể tìm bằng số điện thoại; tài khoản chỉ có quyền xem không được dùng số điện thoại để dò hồ sơ.
3. Kiểm tra ngày sinh/cơ sở và cảnh báo ứng viên trùng.
4. Không tự gộp hai hồ sơ chỉ vì trùng tên hoặc số điện thoại; chuyển ADMIN xử lý nếu chưa chắc chắn.
5. Kết quả ngoài data scope sẽ không xuất hiện; việc không tìm thấy không chứng minh hồ sơ không tồn tại trong toàn hệ thống.

### 2.4 Upload ảnh, phim và hợp đồng

1. Mở đúng bệnh nhân, ca và lần khám.
2. Chọn đúng ô checklist trước khi chọn file.
3. Ảnh/avatar chỉ dùng JPEG hoặc PNG tối đa 10 MiB.
4. Hợp đồng dùng JPEG/PNG tối đa 10 MiB hoặc PDF tối đa 5 MiB.
5. Kiểm tra tên nhóm và số thứ tự trước khi tải lên; không đưa PII vào tên file vật lý.
6. Chờ trạng thái chuyển sang hợp lệ. Response upload thành công ban đầu chỉ có nghĩa file đã vào vùng kiểm tra, chưa có nghĩa đã VALID.
7. Nếu bị từ chối, xem thông báo, sửa file nguồn và tải lại. Không đổi phần mở rộng để giả định dạng.

Runtime production không có malware scanner. Việc file vượt MIME/signature/decode không phải chứng nhận file sạch mã độc; chỉ nhận file từ nguồn công việc được kiểm soát.

### 2.5 Báo sự cố

Ghi thời điểm, tài khoản/vai trò, màn hình, bước tái hiện, request ID và thông báo lỗi. Không đính kèm full hợp đồng, original bệnh nhân, secret hoặc storage path vào kênh hỗ trợ không được duyệt.

## 3. Hướng dẫn chi tiết cho ADMIN

### 3.1 Phạm vi và trách nhiệm

ADMIN quản trị cơ sở, tài khoản, API Client và có thể thực hiện nghiệp vụ lâm sàng khi permission/scope cho phép. ADMIN không mặc nhiên vượt data scope; tài khoản thiếu `ALL_BRANCHES` vẫn bị giới hạn. ADMIN chịu trách nhiệm bảo vệ tài khoản hệ thống, secret, backup và cấu hình tích hợp.

### 3.2 Thiết lập lần đầu

1. Đăng nhập bằng tài khoản bootstrap và đổi mật khẩu tạm ngay.
2. Vào **Cài đặt → Cơ sở**, tạo hoặc kiểm tra từng cơ sở theo tên, mã và địa chỉ.
3. Vào **Cài đặt → Tài khoản**, tạo tài khoản ADMIN/DOCTOR/LABO bằng dữ liệu thật của nhân viên nhưng không đưa mật khẩu vào file bàn giao.
4. DOCTOR bắt buộc có một cơ sở chính đang hoạt động; ADMIN và LABO dùng phạm vi toàn hệ thống và không chọn cơ sở chính.
5. Cấp mật khẩu tạm; bàn giao qua kênh an toàn và yêu cầu đổi ở lần đăng nhập đầu.
6. Kiểm tra **Mẫu checklist** để xác nhận đúng loại dịch vụ/version đang hoạt động; không sửa template cũ đã có ca sử dụng.
7. Giữ External API tắt cho tới khi hoàn thành TEST/UAT, IP allowlist, quyền hợp đồng và bàn giao credential.

### 3.3 Quản lý cơ sở

1. Mở **Cài đặt → Cơ sở**.
2. Tìm theo tên, mã hoặc địa chỉ để tránh tạo trùng.
3. Tạo cơ sở mới và kiểm tra trạng thái hoạt động.
4. Dùng **Chỉnh sửa** để cập nhật thông tin cho phép.
5. Dùng **Ngừng hoạt động** khi cơ sở không còn nhận hồ sơ mới; không xóa dữ liệu lịch sử của cơ sở.
6. Trước khi ngừng hoạt động, kiểm tra tài khoản DOCTOR, bệnh nhân và ca đang gắn với cơ sở để có kế hoạch chuyển giao.
7. Đọc số liệu trên thẻ cơ sở theo quy tắc: bệnh nhân chỉ tính hồ sơ ACTIVE chưa xóa; ca loại ca đã xóa/lưu trữ và ca của bệnh nhân không còn hoạt động. Ca COMPLETED chưa lưu trữ vẫn được tính.

Nếu nút Ngừng hoạt động không xuất hiện, kiểm tra quyền `branch.manage`, trạng thái cơ sở và kích thước màn hình; backend vẫn quyết định cuối cùng.

### 3.4 Tạo và quản lý tài khoản

1. Mở **Cài đặt → Tài khoản** và tìm username/họ tên trước khi tạo.
2. Chọn đúng vai trò; với DOCTOR chọn cơ sở chính đang hoạt động.
3. Sau khi tạo, ghi nhận username và trạng thái buộc đổi mật khẩu; không lưu mật khẩu tạm trong tài liệu.
4. **Chỉnh sửa tài khoản** cập nhật họ tên, vai trò và cơ sở trong một thao tác. Đổi vai trò/cơ sở sẽ thu hồi session cũ; chỉ đổi họ tên không nhất thiết làm gián đoạn phiên.
5. **Cấp mật khẩu** tạo mật khẩu tạm mới, hiển thị một lần; đóng popup sẽ không xem lại được.
6. **Khóa** dùng khi cần dừng truy cập nhưng vẫn giữ tài khoản và lịch sử. Các session bị thu hồi.
7. **Mở khóa** chỉ thực hiện sau khi xác minh người dùng và nguyên nhân khóa.
8. **Xóa** là thao tác không có thùng rác tài khoản; tài khoản bị vô danh hóa và không thể đăng nhập/khôi phục từ UI.

Hệ thống chặn tự sửa quyền nhạy cảm, tự khóa/xóa, xóa ADMIN hoạt động cuối cùng và khóa/xóa username chuẩn hóa `admin`. Không cố vượt các guard này bằng thao tác database thủ công.

### 3.5 Kiểm soát tài khoản định kỳ

- Hằng tuần kiểm tra tài khoản bị khóa, chờ đổi mật khẩu và nhân viên đã nghỉ/chuyển cơ sở.
- Xác minh mỗi DOCTOR có đúng cơ sở chính; ADMIN/LABO không mang branch ID sai.
- Không dùng một tài khoản chung cho nhiều người.
- Khi nhân viên nghỉ ngay lập tức, khóa trước; sau khi hoàn tất đối soát/audit mới cân nhắc xóa.
- Kiểm tra ít nhất một ADMIN dự phòng hợp lệ nhưng không tạo dư tài khoản toàn quyền.

### 3.6 Quản lý bệnh nhân và ca

ADMIN có thể thực hiện quy trình của DOCTOR nếu có quyền/scope. Khi tạo ca, ADMIN chọn bác sĩ đang hoạt động thuộc cơ sở bệnh nhân; không chọn nhân viên khác cơ sở chỉ để vượt data scope. Dùng lưu trữ/xóa mềm và khôi phục theo quy trình, không hard-delete dữ liệu lâm sàng.

### 3.7 Quản lý API Client

1. Mở **Cài đặt → Tích hợp API** khi có `api_client.manage`.
2. Tạo client với tên rõ ràng, IP allowlist tối thiểu và quyền cần thiết.
3. Quyền hợp đồng mặc định tắt; chỉ bật khi hệ thống ngoài thực sự cần danh sách/tải hợp đồng.
4. Sao chép Client ID và secret riêng từng trường. Secret chỉ hiển thị một lần.
5. Chuyển credential qua kênh bí mật; không chụp màn hình hoặc dán vào ticket.
6. Đổi IP hoặc quyền nhạy cảm sẽ thu hồi token cũ; thông báo cho đơn vị tích hợp.
7. Xem thống kê sử dụng, xoay secret hoặc thu hồi client khi có dấu hiệu bất thường.

IP allowlist có thể để trống theo giao diện hiện hành; khi trống, client không bị hạn chế bởi danh sách IP. Nếu backend tích hợp có IP cố định, nhập đúng IP để thu hẹp truy cập. External API chỉ trả preview ảnh theo quyền; original ảnh lâm sàng không public. Hợp đồng chỉ được tải khi client đã được bật quyền tương ứng và vượt đầy đủ relationship/scope check.

### 3.8 Khôi phục dữ liệu đã xóa

- Mở **Hồ sơ đã xóa gần đây** hoặc khu vực **Đã xóa gần đây** trong đúng ca/lần khám.
- Kiểm tra loại dữ liệu: hồ sơ, ca, avatar, ảnh lâm sàng hay hợp đồng.
- Xác minh đúng bệnh nhân/slot, ngày hết hạn và không có file current xung đột.
- Khôi phục chỉ trong 30 ngày và sau kiểm tra integrity; hết 30 ngày thì UI/backend từ chối kể cả purge chưa chạy.
- Không khôi phục chỉ để “xem thử”; thao tác phải có lý do nghiệp vụ rõ ràng.

### 3.9 Trách nhiệm vận hành và backup

- Snapshot/RAID không thay thế backup.
- Không bật purge khi offsite, backup policy, recovery key test, receipt và restore drill chưa đạt.
- Không public PostgreSQL, API nội bộ, original media, hợp đồng, backup hoặc đường dẫn NAS.
- Khi storage mount guard báo lỗi, không tạo thư mục giả để ép app chạy; kiểm tra shared folder mã hóa và mount thực.
- Cập nhật hệ thống bằng updater được cung cấp; không dùng `docker compose down -v`, **Clean** hoặc **Delete** project production.

### 3.10 Tình huống lỗi thường gặp của ADMIN

- **Không tạo được DOCTOR**: cơ sở chưa hoạt động, ngoài scope hoặc thiếu đủ `user.manage`/`role.manage`/`branch.manage`.
- **Không sửa/xóa được tài khoản**: đó là chính tài khoản đang đăng nhập, username `admin`, ADMIN cuối cùng hoặc target ngoài scope.
- **Session người dùng vẫn mở**: yêu cầu người dùng focus lại tab/chờ heartbeat; kiểm tra API health nếu quá thời gian.
- **Không thấy hồ sơ cần khôi phục**: đã quá 30 ngày, ngoài scope, patient cha đang archived hoặc dữ liệu đã purge.
- **API Client không kết nối**: feature flag tắt, IP không nằm allowlist đã cấu hình, credential/token hết hiệu lực hoặc quyền client không đủ.

### 3.11 Checklist bàn giao ADMIN

- Đổi mật khẩu bootstrap và bảo vệ tài khoản `admin`.
- Kiểm tra cơ sở, tài khoản và scope bằng dữ liệu thử.
- Test khóa/mở khóa, mật khẩu tạm và thu hồi session.
- Test chéo một hồ sơ khác cơ sở để xác nhận không rò dữ liệu.
- Kiểm tra backup/restore drill và người giữ recovery key.
- External API để tắt hoặc có hồ sơ UAT/allowlist/credential handover đầy đủ.
- Biết cách lấy request ID và báo sự cố mà không gửi dữ liệu nhạy cảm.

## Quy trình lâm sàng dành cho ADMIN có đủ quyền

Các bước sau áp dụng trong scope của tài khoản ADMIN.

### Tạo hồ sơ bệnh nhân

1. Tìm bằng tên và số điện thoại theo quyền để tránh trùng.
2. Chọn **Thêm bệnh nhân**.
3. Nhập họ tên, số điện thoại, ngày sinh, địa chỉ và cơ sở tiếp nhận.
4. Kiểm tra cảnh báo ứng viên trùng; nếu chưa chắc, hủy tạo và đối soát với ADMIN.
5. Lưu hồ sơ, sau đó tải ảnh nhận diện bằng bước riêng.
6. Nếu hồ sơ lưu thành công nhưng avatar lỗi, không tạo hồ sơ thứ hai; sửa/tải lại avatar trên hồ sơ đã có.

Số điện thoại không phải khóa duy nhất. Hai bệnh nhân có thể trùng số điện thoại; người dùng phải đối soát bằng nhiều trường.

### 4.4 Cập nhật hồ sơ và avatar

1. Mở hồ sơ và chọn **Sửa thông tin**.
2. Cập nhật các trường được phép, kiểm tra cơ sở và lưu.
3. Nếu hệ thống báo xung đột dữ liệu, tải lại hồ sơ rồi thực hiện lại; không ghi đè mù.
4. Avatar chỉ nhận JPEG/PNG tối đa 10 MiB. Khi thay avatar, ảnh cũ vẫn current cho tới khi ảnh mới VALID.
5. Xóa avatar là xóa mềm; có thể khôi phục trong 30 ngày khi chưa có avatar current/upload đang chạy.

### 4.5 Tạo ca điều trị

1. Trong hồ sơ bệnh nhân, chọn tạo lần điều trị mới.
2. Chọn Implant, Răng sứ, Chỉnh nha mắc cài hoặc Chỉnh nha Invisalign.
3. Nhập ngày bắt đầu không ở tương lai.
4. DOCTOR tự phụ trách ca mình tạo; ADMIN mới có thể chọn một bác sĩ active khác thuộc cơ sở bệnh nhân.
5. Kiểm tra checklist snapshot được tạo đúng loại trước khi upload.

Implant/Răng sứ tạo một session điều trị đầy đủ. Chỉnh nha có session đầu và các lần tái khám riêng; hợp đồng Chỉnh nha chỉ thuộc session đầu.

### 4.6 Thứ tự checklist theo dịch vụ

**Implant v6:** Hợp đồng → Kết quả xét nghiệm → Ảnh trước điều trị 01–12 → Phim trước → Phim phân tích → Ảnh trụ sử dụng → Phim sau cắm trụ → Ảnh phục hình tạm 01–12 → Ảnh thiết kế răng phục hình → Ảnh phôi sứ → Phim sau phục hình → Ảnh sau điều trị 01–12 → Bảo hành Implant → Bảo hành răng sứ.

**Răng sứ v4:** Hợp đồng → Ảnh trước điều trị 01–12 → Ảnh thiết kế DSD → Ảnh thiết kế răng phục hình → Ảnh phôi sứ → Ảnh sau điều trị 01–12 → Bảo hành răng sứ.

**Chỉnh nha:** giữ checklist ảnh lần khám và phim pano/cephalo theo session. Mỗi lần tái khám phải được chọn đúng trước khi upload để không đưa file vào session khác.

### 4.7 Upload và kiểm tra bộ ảnh

1. Chọn đúng lần khám ở phần **Các lần khám**.
2. Chọn đúng ô ảnh/phim/hợp đồng; kiểm tra nhãn và số thứ tự.
3. Tải file và chờ VALID.
4. Mở **Xem tổng quan bộ ảnh** để kiểm tra thumbnail, hướng ảnh và nhóm.
5. Nếu có quyền, tải original/ZIP phục vụ nghiệp vụ nội bộ. ZIP ảnh lâm sàng không tự chứa hợp đồng, avatar hoặc version lịch sử.
6. Với PDF hợp đồng, dùng trình xem trong website; không suy diễn rằng PDF có trường chữ ký `/Sig` đã được xác thực pháp lý.

### 4.8 Thay thế, lịch sử và xóa mềm

1. Chỉ thay file current trong session DRAFT/REOPENED.
2. Nhập lý do thay thế rõ ràng; bản cũ được giữ trong lịch sử version.
3. Bản mới phải vượt kiểm tra rồi mới thành current; không xóa bản cũ để “dọn chỗ”.
4. Xóa mềm ảnh/hợp đồng chỉ khi đúng bệnh nhân/slot và có reason code phù hợp.
5. Khi xóa nhầm, mở **Đã xóa gần đây** và khôi phục trước 30 ngày nếu có quyền/không xung đột.

### 4.9 Xác nhận bộ ảnh

1. Đợi mọi upload đang chạy kết thúc; không xác nhận khi còn pending/rejected/recovery.
2. Kiểm tra tổng quan, hợp đồng và dữ liệu bảo hành bắt buộc.
3. Chọn **Xác nhận bộ ảnh**.
4. Hệ thống cho phép xác nhận khi thiếu vị trí ảnh ở các dịch vụ đã áp cơ chế 0.2.17, nhưng vẫn chặn sai quyền/scope, tệp chưa hợp lệ và thiếu bảo hành bắt buộc.
5. Sau xác nhận, session bị khóa chỉnh sửa; phiên TREATMENT có thể đồng thời hoàn tất ca.

Không dùng khả năng xác nhận thiếu ảnh như cách bỏ qua kiểm soát chất lượng. Bác sĩ vẫn chịu trách nhiệm chuyên môn về bộ ảnh được xác nhận.

### 4.10 Mở lại bộ ảnh

1. Chỉ mở lại session đang CONFIRMED.
2. Chọn lý do: thiếu ảnh, ảnh sai, cập nhật lâm sàng hoặc lý do khác.
3. Nếu chọn lý do khác, nhập ghi chú đủ rõ.
4. Bổ sung/thay file rồi xác nhận lại để tạo manifest mới.
5. Manifest và lịch sử cũ vẫn được giữ; không yêu cầu ADMIN xóa lịch sử xác nhận.

### 4.11 Chia sẻ với khách hàng

1. Mở **Xem tổng quan bộ ảnh** trong đúng ca/lần khám rồi chọn chức năng chia sẻ.
2. Chọn đúng ảnh, preview hợp đồng và/hoặc thông tin bảo hành cần gửi trong danh sách hệ thống cho phép. Kiểm tra lại bệnh nhân, lần khám và từng mục trước khi tạo link; không chọn tất cả theo thói quen.
3. Link tồn tại tối đa 72 giờ, không có passcode và người có link có thể xem preview đã chọn.
4. Sao chép link qua kênh được duyệt. Link chỉ cho xem nội dung đã chọn; preview hợp đồng không phải tệp original/PDF đầy đủ. Không đưa original lên nơi công khai.
5. Kiểm tra preview có watermark.
6. Thu hồi link khi gửi nhầm, hoàn tất mục đích hoặc nghi ngờ lộ link.

### 4.12 Lưu trữ/xóa và khôi phục ca

- **Lưu trữ ca** đưa ca ra khỏi danh sách làm việc nhưng giữ dữ liệu con/lịch sử.
- **Xóa ca** là xóa mềm có cửa sổ khôi phục 30 ngày; không phải purge ngay.
- Không lưu trữ khi còn upload chưa kết thúc.
- Khôi phục yêu cầu patient đang active và đúng scope; ca Chỉnh nha khác không chặn khôi phục.
- Không tạo ca mới để thay thế ca bị xóa nếu ca cũ vẫn còn khôi phục được.


## 6. Phối hợp giữa các vai trò

### 6.1 Ca Implant/Răng sứ thông thường

1. DOCTOR tạo bệnh nhân/ca và upload dữ liệu lâm sàng/hợp đồng.
2. LABO upload DSD/thiết kế phục hình/phôi sứ và nhập bảo hành được giao.
3. DOCTOR kiểm tổng quan, bổ sung dữ liệu còn thiếu và xác nhận.
4. ADMIN chỉ can thiệp khi có lỗi scope, tài khoản, khôi phục hoặc vận hành.

### 6.2 File bị từ chối

1. Người upload xem lý do và giữ nguyên hồ sơ/slot.
2. Sửa hoặc xuất lại file nguồn đúng định dạng.
3. Tải lại vào đúng slot; không tạo bệnh nhân/ca mới.
4. Nếu lặp lại hoặc RECOVERY_REQUIRED, gửi request ID cho ADMIN; không gửi original qua chat.

### 6.3 Gửi nhầm link chia sẻ

1. DOCTOR/ADMIN thu hồi link ngay.
2. Kiểm tra selection và tạo link mới nếu cần.
3. Báo ADMIN khi nghi ngờ truy cập trái phép để kiểm audit.
4. Không thay link bằng cách public original hoặc tải file lên dịch vụ ngoài chưa duyệt.

### 6.4 Nhân viên chuyển cơ sở hoặc nghỉ việc

1. ADMIN khóa tài khoản để thu hồi session.
2. Đối soát ca/assignment và chuyển giao hợp lệ.
3. Chỉnh vai trò/cơ sở hoặc xóa tài khoản sau khi hoàn tất audit.
4. Không xóa hồ sơ bệnh nhân/media để xử lý thay đổi nhân sự.

## 7. Bảng xử lý lỗi nhanh

| Hiện tượng | Người xử lý đầu tiên | Cách xử lý an toàn |
|---|---|---|
| Không đăng nhập được | Người dùng/ADMIN | Kiểm tra trạng thái khóa, mật khẩu tạm, thời gian hệ thống; không chia sẻ mật khẩu |
| Số liệu cơ sở không như dự kiến | ADMIN | Tải lại trang; đối chiếu trạng thái ACTIVE, deletedAt và ca ARCHIVED; không sửa trực tiếp database |
| Không thấy bệnh nhân/ca | Người dùng/ADMIN | Kiểm scope, branch, assignment, trạng thái archived; không mở quyền toàn hệ thống tùy tiện |
| Upload pending quá lâu | Người upload/ADMIN | Ghi request ID, kiểm health/storage; không upload lặp nhiều lần |
| File REJECTED | Người upload | Sửa file nguồn rồi tải lại; không đổi đuôi giả định dạng |
| Lỗi 409 | Người dùng | Tải lại dữ liệu mới nhất rồi thao tác lại |
| Không xác nhận được | DOCTOR/ADMIN | Kiểm pending/rejected, warranty, version, permission và trạng thái session |
| Không khôi phục được | ADMIN/DOCTOR có quyền | Kiểm 30 ngày, integrity, xung đột slot/avatar và trạng thái patient/session |
| API Client 401/403 | ADMIN/đơn vị tích hợp | Kiểm feature flag, IP, secret/token, scope; xoay secret nếu nghi lộ |
| Storage/NAS lỗi | ADMIN vận hành | Dừng thay đổi, kiểm mount guard/shared folder; không tạo marker giả |

## 8. Tiêu chí đào tạo hoàn tất

Một tài khoản chỉ nên được bàn giao vận hành sau khi người dùng:

- hiểu role không thay thế permission/scope/relationship;
- đăng nhập, đổi mật khẩu và đăng xuất đúng cách;
- thực hiện thành công quy trình mẫu của vai trò bằng dữ liệu giả;
- nhận biết DRAFT, VALID, REJECTED, CONFIRMED, REOPENED và dữ liệu đã xóa;
- biết các hành động không được phép của vai trò;
- biết cách báo request ID mà không làm lộ PII, original, hợp đồng, token hoặc secret;
- hoàn thành checklist riêng ở cuối chương ADMIN, DOCTOR hoặc LABO.