# Checklist sẵn sàng thí điểm theo vai trò - Bộ Hướng dẫn Triển khai Core FHIR cho Việt Nam v0.5.0

## Checklist sẵn sàng thí điểm theo vai trò

# Checklist sẵn sàng thí điểm theo vai trò — Pilot Readiness Checklists

Bộ checklist ngắn để từng vai trò triển khai tự đánh giá mức sẵn sàng trước thí điểm: chọn đúng vai trò tại [Tuân thủ theo vai trò triển khai](conformance-by-actor.md), đánh dấu từng mục theo `Đạt/Chưa đạt/Không áp dụng`, và gắn bằng chứng cụ thể như `CapabilityStatement`, log script, test case hoặc báo cáo triển khai.

-------

## Bằng chứng nên chuẩn bị trước khi tự đánh giá

| | |
| :--- | :--- |
| Tài liệu phạm vi | ma trận vai trò triển khai, package boundary, use case đã chốt |
| Bằng chứng kỹ thuật | `CapabilityStatement`, endpoint thử nghiệm, example bundle/resource |
| Bằng chứng kiểm tra | `./scripts/validate.sh`,`./scripts/validate-tier2.sh`,`./scripts/validate-bhyt-submission.sh`,`./scripts/validate-bhyt-roundtrip.sh` |
| Bằng chứng quản trị | policy`hiện hành / lịch sử / ngừng dùng`, change log, release gate |
| Bằng chứng vận hành | ma trận quyền, audit log, nhật ký lỗi, runbook tối thiểu |

-------

## Vai trò 1: Kiến trúc tiêu chuẩn, quản trị dữ liệu và điều phối triển khai

| | | |
| :--- | :--- | :--- |
| Ma trận vai trò triển khai | Đã chốt rõ vai trò triển khai nào trong phạm vi thí điểm | sơ đồ vai trò hoặc bảng phân vai |
| Package boundary | Đã xác định hệ thống nào dùng`core.base`,`bhyt.submission`, terminology | quyết định kiến trúc, danh sách package |
| Canonical discipline | Đã thống nhất URL,`system URI`, quy tắc đổi phiên bản và ngừng dùng | policy canonical, naming conventions |
| Identifier governance | Đã tách định danh công dân, payer, tổ chức và cục bộ | [Danh mục định danh](identifier-registry.md), quyết định mapping |
| Terminology governance | Đã chốt bộ mã quốc tế nào dùng trực tiếp, bộ mã nào localize | [Hướng dẫn thuật ngữ](terminology-guidance.md), provenance |
| Release gate | Đã có tiêu chí phát hành hoặc chấp nhận thí điểm | checklist nội bộ, release gate |

-------

## Vai trò 2: HIS, EMR và FHIR server nội bộ

| | | |
| :--- | :--- | :--- |
| Gói triển khai | Đã cài và kiểm tra được`hl7.fhir.vn.core.base` | log cài đặt, validator config |
| Resource ưu tiên | Đã chốt tập resource thực sự dùng trong giai đoạn thí điểm | scope matrix, use case map |
| Must Support | Đã diễn giải rõ nghĩa vụ đọc/ghi cho từng nhóm tích hợp | mapping sheet, design note |
| Search behavior | Đã hỗ trợ đúng các search`token`,`string`,`date`,`reference`đã cam kết | test case hoặc API evidence |
| Validation | Đã pass`./scripts/validate.sh`với ví dụ đại diện | log chạy script |
| Tier 2 | Đã pass hoặc có cơ chế tương đương cho các kiểm tra rủi ro cao | log`validate-tier2.sh`, bằng chứng kiểm tra tương đương |
| CapabilityStatement | Đã đối chiếu hoặc công bố`VNCoreServer`/`VNCoreEMRServer` | URL hoặc artifact nội bộ |
| Security baseline | Nếu mở dữ liệu ra ngoài hệ thống nguồn, đã chốt audit và quyền tối thiểu | ma trận quyền, audit policy |

-------

## Vai trò 3: Client gửi hồ sơ thanh toán BHYT

| | | |
| :--- | :--- | :--- |
| Package boundary | Đã dùng đúng`core.base`và`bhyt.submission` | cấu hình validator hoặc build |
| Bundle generation | Sinh đúng`VNCoreBHYTSubmissionBundle`cho ca dùng thật | example bundle của đơn vị |
| Operation contract | Đã rõ đầu vào, đầu ra và lỗi của`$validate-bhyt-claim`,`$submit-bhyt-claim`,`$reverse-bhyt-claim` | test API hoặc mock contract |
| Identifier rules | `MA_LK`,`MA_LUOT_KCB`,`SO_CCCD`,`subscriberId`,`identifier[BHYT]`nhất quán | bộ dữ liệu kiểm thử âm tính/dương tính |
| Export rules | Định dạng`yyyyMMddHHmm`và các trường gateway được kiểm tra trước khi gửi | validation logs |
| Submission validation | Đã pass`./scripts/validate-bhyt-submission.sh` | log script |
| Round-trip | Đã pass`./scripts/validate-bhyt-roundtrip.sh`cho phạm vi bảng đã cam kết | báo cáo round-trip |

-------

## Vai trò 4: Server tiếp nhận hồ sơ thanh toán BHYT hoặc facade tích hợp

| | | |
| :--- | :--- | :--- |
| CapabilityStatement | Đã đối chiếu`VNBHYTGatewayServer` | artifact hoặc bảng đối chiếu |
| Validation contract | Phân biệt được lỗi cú pháp, lỗi ngữ nghĩa và lỗi nghiệp vụ cổng | mẫu`OperationOutcome`, mã lỗi |
| Operation readiness | Ba operation chính đã có hành vi phản hồi nhất quán | API spec, test cases |
| Audit và provenance | Có ghi nhận kiểm toán cho gửi, nhận, kiểm tra, phản hồi, thu hồi | log mẫu, policy audit |
| Tách quyền dịch vụ | Đã tách service account của gateway khỏi tài khoản lâm sàng nội bộ | IAM matrix, credential policy |
| Giới hạn trách nhiệm | Đã công bố rõ gateway xử lý gì và không xử lý gì | interface contract, runbook |
| Bảo mật cơ sở | Đã rà soát quyền, logging, lưu giữ lỗi và chống lặp gửi | security checklist nội bộ |

-------

## Vai trò 5: Ứng dụng người dân, cổng bệnh nhân và tích hợp VNeID

| | | |
| :--- | :--- | :--- |
| Phạm vi dữ liệu | Đã chốt rõ resource nào được mở ở giai đoạn đầu | resource matrix |
| Consent và audit | Có luồng kiểm tra`Consent`,`AuditEvent`,`Provenance` | ví dụ hoặc test flow |
| Quyền truy cập | Tách rõ người dùng cuối, tài khoản dịch vụ và proxy/người giám hộ | access matrix |
| Data minimization | Chỉ hiển thị dữ liệu đúng mục đích, không mở quá rộng vì tiện lợi kỹ thuật | UX/legal note, policy |
| Search và disclosure | Công bố rõ ứng dụng cho phép tìm gì và hiển thị gì | API doc, help text |
| Security baseline | Đã có kiểm soát tối thiểu cho xác thực, ghi log và break-glass nếu áp dụng | security test, policy |

-------

## Vai trò 6: Terminology, định danh và dữ liệu chủ

| | | |
| :--- | :--- | :--- |
| NamingSystem registry | Mọi hệ định danh đã có trạng thái`hiện hành / lịch sử / ngừng dùng`rõ | registry snapshot |
| URI/OID bridge | Các hệ cũ đã có chính sách ánh xạ sang canonical URI | [Ánh xạ URI/OID](identifier-registry.md#ánh-xạ-uri-và-oid) |
| International-first | Đã rõ khi nào dùng`LOINC`,`SNOMED CT`,`ICD`trước khi localize | terminology policy |
| Provenance | Bộ mã và tập giá trị đều có căn cứ và provenance nhất quán | CodeSystem/ValueSet narrative |
| Change control | Mọi thay đổi mã đều có diff, review và quyết định công bố | diff report, governance log |
| Package publishing | Đã chốt gói nào mang thuật ngữ nào và vòng đời cập nhật của từng gói | package plan |

-------

## Vai trò 7: QA, reviewer cộng đồng và nhóm đánh giá maturity

| | | |
| :--- | :--- | :--- |
| Phạm vi theo vai trò triển khai | Đã biết đang đánh giá vai trò triển khai nào, không review mơ hồ toàn hệ thống | scope note |
| Script baseline | Đã chạy các script tương ứng với vai trò triển khai | validation logs |
| Evidence review | Đã xem`CapabilityStatement`, example, search behavior và package liên quan | review worksheet |
| Deviations | Mọi điểm lệch đều được ghi thành deviation rõ ràng, không để ở mức nhận xét miệng | issue list |
| Implementation report | Có yêu cầu hoặc bản nháp báo cáo triển khai nếu vai trò đó đã vào giai đoạn thí điểm | report draft |
| Kết luận mức sẵn sàng | Kết luận rõ vai trò triển khai đã`sẵn sàng thí điểm`,`sẵn sàng có điều kiện`hay`chưa sẵn sàng` | review summary |

-------

## Mẫu ghi nhận ngắn

Các đơn vị có thể dùng mẫu ngắn sau trước khi viết implementation report đầy đủ:

```
# Checklist sẵn sàng thí điểm — {VaiTro}

- Date:
- Owner:
- Scope:
- Package(s):
- CapabilityStatement baseline:

## Status
- Kết quả checklist theo vai trò triển khai:
- Blocking gaps:
- Accepted conditions:
- Evidence links:

```

-------

## Liên hệ với các trang khác

| | |
| :--- | :--- |
| Chọn đúng vai trò triển khai trước khi tự đánh giá | [Tuân thủ theo vai trò triển khai](conformance-by-actor.md) |
| Chạy các kiểm tra kỹ thuật | [Hướng dẫn kiểm tra hợp lệ](validation-guidance.md) |
| Quyết định có đủ điều kiện phát hành hay chưa | [Phát hành và quản trị](release-governance.md) |

-------

## English Summary

This page provides short, actor-based pilot-readiness checklists for VN Core. It does not replace profiles, CapabilityStatements, validation scripts, or implementation reports. Instead, it gives implementers and reviewers a compact way to decide whether a given actor is ready for pilot, what minimum evidence should exist, and where to look next when gaps remain.

