Hướng dẫn triển khai FHIR cốt lõi Việt Nam — VN Core FHIR Implementation Guide - Draft for Community Review (v0.10.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Playbook Chuyển tuyến

Playbook Chuyển tuyến — Chuyển người bệnh giữa cơ sở khám bệnh, chữa bệnh

Hướng dẫn tích hợp cho một lần chuyển người bệnh: phát hành giấy chuyển → gửi cơ sở dự kiến tiếp nhận → được nhận hoặc bị từ chối → người bệnh đến → hoàn thành → chuyển về. Trang này tập trung vào phần mà ba playbook kia không trả lời được: ai đang chịu trách nhiệm về người bệnh tại từng thời điểm.

Cùng bộ playbook: Ngoại trú · Nội trú · Cấp cứu · Dược.

Điểm khác biệt VN cốt lõi: một giấy chuyển có thể phải gửi tới nhiều cơ sở trước khi có nơi nhận, nhưng người bệnh chỉ có một lần chỉ định chuyển. Vì vậy giấy chuyển và việc điều phối là hai thứ khác nhau: ServiceRequest là giấy chuyển, mỗi lần gửi tới một cơ sở là một Task riêng.

Trường hợp cấp cứu thì cơ sở khám bệnh, chữa bệnh không được từ chối — Luật 15/2023/QH15 Điều 59 khoản 2 điểm a: quyền từ chối khi vượt quá khả năng chuyên môn không áp dụng cho "trường hợp cấp cứu quy định tại Điều 61 của Luật này".

1. Phạm vi & khi nào dùng

Dùng khi người bệnh được chuyển giữa hai cơ sở khám bệnh, chữa bệnh — cả chiều lên tuyến trên, chiều về tuyến dưới và cùng tuyến. KHÔNG dùng cho chuyển khoa trong cùng một cơ sở (đó là Encounter mới cùng Account, xem Nội trú).

2. Vai trò triển khai và hệ thống

3. Căn cứ pháp lý

Luật 15/2023/QH15 Điều 60 khoản 10 (nghĩa vụ giới thiệu, chuyển người bệnh), Điều 61 (cấp cứu) và Điều 59 khoản 2 điểm a (quyền từ chối KHÔNG áp dụng cho ca cấp cứu theo Điều 61); QĐ 3176/QĐ-BYT (trường MA_LYDO_CT — lý do chuyển cơ sở KCB; chuẩn dữ liệu đầu ra không có chỉ tiêu hình thức chuyển, xem đính chính 19/08/2026 tại VNReferralModeCS); TT 01/2025/TT-BYT (giấy chuyển tuyến theo năm dương lịch; giấy hết thời hạn khi người bệnh vẫn đang điều trị thì dùng đến hết đợt điều trị đó).

4. Điều kiện tiên quyết

5. Máy trạng thái — phần cốt lõi

Trạng thái nghiệp vụ nằm ở Task.businessStatus (VNTaskBusinessStatusCS), trạng thái kỹ thuật ở Task.status. Hai thứ phải khớp nhau, ràng buộc bằng invariant vn-task-referral-state-coherent.

                    ┌──────────────┐
                    │  REF-SENT    │  giấy chuyển đã gửi
                    └──────┬───────┘
              đồng ý ┌─────┴─────┐ từ chối
                     ▼           ▼
            ┌────────────────┐  ┌──────────────┐
            │ REF-ACCEPTED   │  │ REF-DECLINED │──▶ mở Task MỚI
            └───────┬────────┘  └──────────────┘    tới cơ sở khác
       người bệnh đến│                               (cùng ServiceRequest)
                     ▼
            ┌────────────────┐
            │  REF-ARRIVED   │  Encounter mở tại cơ sở nhận
            └───────┬────────┘
                     ▼
            ┌────────────────┐      ┌────────────────┐
            │ REF-COMPLETED  │─────▶│  REF-RETURNED  │  giấy chuyển về
            └────────────────┘      └────────────────┘  (ServiceRequest mới)

Hai invariant ép máy trạng thái này:

• vn-task-referral-state-coherent — trạng thái nghiệp vụ phải khớp trạng thái kỹ thuật.
• vn-task-referral-arrival-evidence — REF-ARRIVED/REF-COMPLETED phải có output trỏ Encounter. Khẳng định người bệnh đã đến mà không có lượt khám nào thì không kiểm được, và đối soát MA_LK giữa hai cơ sở sẽ hỏng về sau.

Ngoài validator, cổng scripts/validate-referral-state.py kiểm cùng bộ ràng buộc này trên build output, chạy trong vài giây ở pre-commit và CI.

6. Các bước gửi dữ liệu

Ví dụ đầy đủ cả sáu bước: ExampleServiceRequestReferral · ExampleTaskReferralDeclined · ExampleTaskReferralAcceptance · ExampleServiceRequestCounterReferral · ExampleTaskReferralAccepted · ExampleTaskReferralReturned · ExampleAppointmentReferralIntake.

7. Lỗi, thử lại và các nhánh không thành

8. Terminology

9. Danh sách kiểm tra trước khi tích hợp

• Mỗi Task có đúng một focus trỏ ServiceRequest, KHÔNG lặp lại ở basedOn.
• Task.owner là cơ sở được đề nghị, Task.requester là cơ sở chuyển đi.
• Nhánh từ chối luôn có statusReason.
• REF-ARRIVED/REF-COMPLETED có output trỏ Encounter của cơ sở nhận.
• Chuyển về dùng ServiceRequest mới với referralMode = 3, không sửa giấy chuyển đi.
• Trường hợp cấp cứu: hệ thống không cho phép trạng thái REF-DECLINED.

10. Khoảng trống hiện tại

• Chưa có ví dụ minh hoạ cho REF-SENT và REF-ARRIVED — hai trạng thái này thoáng qua, nhưng bộ ví dụ nên có để bên tích hợp thấy đủ vòng. Cổng validate-referral-state.py in rõ phần thiếu này thay vì báo xanh chung.
• Thời hạn không phản hồi chưa có mã lý do chuẩn; hiện dùng statusReason.text tự do.
• Chưa mô hình hoá việc vận chuyển người bệnh (xe cứu thương, bàn giao dọc đường).

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

Tình huống lâm sàng · Tuân thủ theo vai trò triển khai · Hành vi tìm kiếm · Hồ sơ FHIR

English Summary

This page defines the VN Core referral coordination workflow using a ServiceRequest as the referral order and a Task as the operational state carrier. It separates statutory referral data from project-assigned workflow codes, and documents retry, rejection, emergency, arrival, completion, and return-referral behavior for implementers.