Chuyển tuyến điện tử qua FHIR: ServiceRequest, Task và Composition

Bài toán và bối cảnh chuyển tuyến tại Việt Nam

Chuyển người bệnh giữa các cơ sở khám bệnh, chữa bệnh kết hợp quyết định lâm sàng, điều phối tiếp nhận và yêu cầu hành chính. Theo mô hình chuyên môn kỹ thuật hiện hành, một cơ sở cấp ban đầu có thể chuyển người bệnh đến cơ sở cấp cơ bản hoặc chuyên sâu phù hợp với năng lực; việc chuyển cũng có thể diễn ra giữa các cơ sở cùng cấp. Các tên gọi tuyến xã, huyện, tỉnh hoặc trung ương có thể còn xuất hiện trong hồ sơ legacy nhưng không nên dùng thay cho cấp chuyên môn hiện hành.

Quy trình phụ thuộc giấy có thể làm tăng nguy cơ đọc sai, nhập lại dữ liệu, thất lạc chứng từ và chậm chia sẻ thông tin với cơ sở đích. Nó cũng hạn chế khả năng kiểm tra tự động nguồn gốc chứng từ, thời điểm phát hành và trạng thái tiếp nhận. Mức độ rủi ro thực tế phụ thuộc quy trình của từng cơ sở; số hóa chỉ có giá trị khi đi kèm định danh, kiểm soát truy cập, chất lượng dữ liệu và audit trail phù hợp.

Thông tư 13/2025/TT-BYT quy định hồ sơ bệnh án điện tử phải được lập, cập nhật, hiển thị, ký hoặc xác nhận điện tử theo phương thức hợp pháp. Bệnh viện thuộc phạm vi thông tư có mốc hoàn thành chậm nhất 30/09/2025; cơ sở khám bệnh, chữa bệnh khác có điều trị nội trú, điều trị ban ngày hoặc điều trị ngoại trú có mốc 31/12/2026. Thông tư không quy định định dạng FHIR cho giấy chuyển cơ sở KCB, không yêu cầu ký cả ServiceRequest và Composition, và không đặt thuật toán BHXH xác định mức hưởng.

FHIR R4 cung cấp nhiều resource có thể kết hợp cho use case này. Trang này chọn ServiceRequest, Task và Composition làm một mẫu kiến trúc, kèm Provenance khi cần biểu diễn nguồn gốc hoặc chữ ký. Hệ thống triển khai phải công bố profile, interaction và yêu cầu bảo mật trong IG, CapabilityStatement và hợp đồng giao tiếp tương ứng.

Mẫu giấy chuyển viện hiện hành

Biểu mẫu và quy trình chuyển cơ sở KCB phải được đối chiếu với văn bản chuyên ngành, mẫu đang có hiệu lực và yêu cầu của bên tiếp nhận tại thời điểm triển khai. Bảng dưới dùng một tập trường thường gặp để minh họa: số giấy, ngày lập, cơ sở gửi và nhận, định danh người bệnh, chẩn đoán, lý do chuyển, thông tin điều trị, người xác nhận và tài liệu kèm theo. Đây không phải bản sao có giá trị pháp lý của một mẫu biểu cụ thể.

Mỗi trường có thể được phân tích theo kiểu dữ liệu và nguồn chịu trách nhiệm. Số giấy chuyển là identifier nghiệp vụ; ngày lập là timestamp; cơ sở và người yêu cầu có thể tham chiếu Organization, PractitionerRole hoặc Practitioner. VN Core dùng số định danh cá nhân/CCCD làm định danh lõi khi có, đồng thời mô hình hóa hộ chiếu, giấy khai sinh và trường hợp bất khả kháng theo profile. Chẩn đoán có thể dùng ICD-10 VN theo phiên bản được áp dụng. Chữ ký điện tử, dấu hoặc hình thức xác nhận không hoán đổi tự động: giá trị pháp lý phụ thuộc đối tượng ký, dữ liệu được ký, chứng thư/trust framework, thời điểm và quy trình xác minh.

Trong mẫu kiến trúc này, ServiceRequest biểu diễn yêu cầu, Composition biểu diễn tài liệu giải thích và Task theo dõi việc xử lý yêu cầu. Đây là lựa chọn thiết kế giúp tách nội dung lâm sàng khỏi trạng thái workflow; hệ thống vẫn có thể cần DocumentReference hoặc Binary cho tài liệu gốc theo yêu cầu lưu trữ và chứng cứ. Không nên suy ra rằng mọi biểu mẫu giấy phải được thay bằng đúng ba resource này.

Mapping mẫu giấy sang resource FHIR

Bảng dưới đối chiếu từng trường trong mẫu giấy chuyển viện hiện hành với phần tử FHIR R4 tương ứng. Đây là mapping mức nguyên tắc; profile VNCore sẽ ràng buộc chi tiết hơn về Must Support, slicing và terminology.

Mẫu phối hợp ServiceRequest, Task và Composition

ServiceRequest: lệnh lâm sàng

ServiceRequest mô tả yêu cầu thực hiện một dịch vụ y tế. Trong mẫu này, dịch vụ là tiếp tục đánh giá hoặc chăm sóc tại cơ sở đích và ServiceRequest là focus của Task. FHIR R4 không bắt buộc ServiceRequest, Composition hay resource nào trong workflow này phải có chữ ký số. Artifact cần ký, phạm vi dữ liệu được ký và phương thức xác minh phải do pháp luật áp dụng, IG và hợp đồng giao tiếp quy định.

{
  "resourceType": "ServiceRequest",
  "id": "sr-referral-001",
  "status": "active",
  "intent": "order",
  "priority": "urgent",
  "category": [{ "coding": [{ "system": "http://snomed.info/sct", "code": "306206005", "display": "Referral to service" }] }],
  "code": { "coding": [{ "system": "http://snomed.info/sct", "code": "3457005", "display": "Patient referral" }] },
  "subject": { "reference": "Patient/lan-001" },
  "encounter": { "reference": "Encounter/enc-tyt-001" },
  "authoredOn": "2026-04-30T10:00:00+07:00",
  "requester": { "reference": "PractitionerRole/bs-tyt-001" },
  "performer": [{ "reference": "Organization/bv-tinh-k" }],
  "performerType": { "coding": [{ "system": "http://snomed.info/sct", "code": "394579002", "display": "Cardiology" }] },
  "reasonReference": [{ "reference": "Condition/dx-stemi-001" }],
  "reasonCode": [{ "text": "Đau ngực kéo dài, ECG có ST chênh lên ở V1-V4, troponin tăng, nghi nhồi máu cơ tim cấp" }],
  "supportingInfo": [
    { "reference": "Observation/ecg-001" },
    { "reference": "Observation/troponin-001" }
  ]
}

Task: workflow giữa hai cơ sở

Task tách trạng thái workflow khỏi nội dung lâm sàng. Trong mẫu này, cơ sở đích cập nhật Task khi tiếp nhận, từ chối hoặc hoàn tất; ServiceRequest và Composition chỉ thay đổi theo quy tắc versioning của giao diện. Không nên gọi chúng là “tài liệu pháp lý đã ký” nếu chưa xác định dữ liệu ký, chữ ký hợp lệ và chính sách bất biến.

{
  "resourceType": "Task",
  "id": "task-referral-001",
  "status": "requested",
  "intent": "order",
  "priority": "urgent",
  "code": { "coding": [{ "system": "http://hl7.org/fhir/CodeSystem/task-code", "code": "fulfill" }] },
  "focus": { "reference": "ServiceRequest/sr-referral-001" },
  "for": { "reference": "Patient/lan-001" },
  "authoredOn": "2026-04-30T10:00:00+07:00",
  "requester": { "reference": "Organization/tyt-xa-h" },
  "owner": { "reference": "Organization/bv-tinh-k" },
  "businessStatus": { "text": "Chờ Bệnh viện tỉnh K. tiếp nhận" }
}

State machine đề xuất dùng requested → accepted → in-progress → completed; từ chối dùng rejected kèm statusReason, còn hủy theo chính sách dùng cancelled. Các bên phải thống nhất ai được chuyển trạng thái, điều kiện chuyển và xử lý retry/idempotency. Có thể dùng FHIR Subscription để nhận thông báo nếu server hỗ trợ và khai báo trong CapabilityStatement; polling hoặc message broker là phương án khác.

Composition: referral letter có cấu trúc

Composition có thể biểu diễn referral letter với lý do chuyển và tóm tắt thông tin lâm sàng. Trong FHIR R4, các phần tử bắt buộc của Composition gồm status, type, date, author và title; subject là 0..1 trong FHIR base nhưng nên được profile cho use case người bệnh. Khi section.text hiện diện, giá trị phải là Narrative XHTML { status, div }, không phải string thô.

{
  "resourceType": "Composition",
  "id": "comp-referral-001",
  "status": "final",
  "type": {
    "coding": [{ "system": "http://loinc.org", "code": "57133-1", "display": "Referral note" }]
  },
  "subject": { "reference": "Patient/lan-001" },
  "encounter": { "reference": "Encounter/enc-tyt-001" },
  "date": "2026-04-30T10:00:00+07:00",
  "author": [{ "reference": "PractitionerRole/bs-tyt-001" }],
  "title": "Giấy chuyển viện - TYT xã H. sang BV tỉnh K.",
  "attester": [{
    "mode": "professional",
    "time": "2026-04-30T10:05:00+07:00",
    "party": { "reference": "PractitionerRole/bs-tyt-001" }
  }],
  "section": [
    {
      "title": "Hành chính",
      "text": {
        "status": "generated",
        "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">Bệnh nhân Nguyễn Thị Lan, sinh 1962, thẻ BHYT HC4010112345678, đăng ký KCB ban đầu tại TYT xã H.</div>"
      },
      "entry": [
        { "reference": "Patient/lan-001" },
        { "reference": "Coverage/cov-bhyt-001" }
      ]
    },
    {
      "title": "Lý do chuyển",
      "text": {
        "status": "generated",
        "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">Đau ngực sau xương ức 30 phút, lan ra cánh tay trái, ECG có ST chênh lên V1-V4, troponin I tăng. Vượt khả năng chuyên môn của TYT xã.</div>"
      }
    },
    {
      "title": "Chẩn đoán",
      "text": {
        "status": "generated",
        "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">I21.0 - Nhồi máu cơ tim cấp xuyên thành thành trước</div>"
      },
      "entry": [{ "reference": "Condition/dx-stemi-001" }]
    },
    {
      "title": "Tiền sử và điều trị đã thực hiện",
      "text": {
        "status": "generated",
        "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">Tăng huyết áp 5 năm, đang dùng amlodipin 5mg/ngày. Tại TYT đã cho aspirin 300mg, clopidogrel 300mg, nitromint xịt dưới lưỡi.</div>"
      },
      "entry": [
        { "reference": "Condition/htn-001" },
        { "reference": "MedicationRequest/aspirin-loading-001" }
      ]
    },
    {
      "title": "Sinh hiệu và cận lâm sàng",
      "text": {
        "status": "generated",
        "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">HA 150/95 mmHg, mạch 92/phút, SpO2 96%. ECG: ST chênh lên V1-V4. Troponin I 2.3 ng/mL.</div>"
      },
      "entry": [
        { "reference": "Observation/bp-001" },
        { "reference": "Observation/ecg-001" },
        { "reference": "Observation/troponin-001" }
      ]
    },
    {
      "title": "Đề xuất tiếp theo",
      "text": {
        "status": "generated",
        "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">Đề nghị BV tỉnh K. tiếp nhận khẩn, đánh giá can thiệp mạch vành thì đầu (primary PCI) trong vòng 90 phút.</div>"
      }
    }
  ]
}

section.entry chứa tham chiếu đến resource trong Bundle hoặc trên server, còn section.text là narrative cho con người. Hai phần cần nhất quán theo quy tắc tạo narrative. Phạm vi người ký xác nhận phụ thuộc payload thực sự được ký và chính sách signature; Composition.attester không tự xác định narrative hay reference nào nằm trong chữ ký mật mã.

Workflow đầy đủ giữa hai cơ sở

Luồng dưới đây là một sequence tham chiếu, không phải quy trình tám bước bắt buộc. Trước khi áp dụng, hai cơ sở phải thống nhất endpoint, profile, xác thực/ủy quyền, trạng thái Task, lỗi và retry, thời hạn lưu trữ, dữ liệu tối thiểu và trách nhiệm xử lý.

Bước 1. Người hành nghề đánh giá và ghi nhận quyết định chuyển theo quy trình áp dụng
Bước 2. EMR tạo các resource mà IG use case yêu cầu, ví dụ ServiceRequest + Task + Composition
Bước 3. Hệ thống ký hoặc xác nhận artifact được chính sách chỉ định; Provenance ghi nguồn gốc khi áp dụng
Bước 4. Gửi Bundle/message qua endpoint đã thỏa thuận nếu CapabilityStatement và hợp đồng cho phép
Bước 5. Thông báo bằng Subscription, polling hoặc broker theo capability đã công bố
Bước 6. Cơ sở đích cập nhật Task theo state machine đã thống nhất
Bước 7. Khi người bệnh đến, Encounter.basedOn tham chiếu ServiceRequest nếu phù hợp
Bước 8. Hoàn tất workflow và tài liệu ra viện theo use case riêng

AuditEvent và Provenance phục vụ mục đích khác nhau: AuditEvent ghi sự kiện truy cập/vận hành, còn Provenance mô tả nguồn gốc hoặc tác nhân tạo/sửa dữ liệu. IG phải xác định sự kiện nào cần ghi, ai được đọc, thời hạn lưu, đồng bộ thời gian và dữ liệu cần giảm thiểu. Chỉ tạo hai resource này không tự bảo đảm tuân thủ Luật 91/2025/QH15 hoặc NĐ 356/2025/NĐ-CP.

Trong cấp cứu, ưu tiên ghi nhận chăm sóc thực tế trên Encounter và các resource lâm sàng tại đúng thời điểm. Nếu yêu cầu chuyển chỉ được tạo sau đó, authoredOn phải phản ánh thời điểm tạo thật; Provenance, nếu được dùng theo contract, cũng ghi thời điểm thật. Không backdate một order chưa tồn tại. Chỉ dùng occurrence[x] cho thời điểm dịch vụ được yêu cầu theo quy trình đã xác nhận, kèm lý do và liên kết sự kiện cấp cứu khi cần.

Đúng tuyến và trái tuyến BHYT

Luật 51/2024/QH15 sử dụng mô hình cấp khám bệnh, chữa bệnh ban đầu, cấp khám bệnh, chữa bệnh cơ bản và cấp khám bệnh, chữa bệnh chuyên sâu. Nghị định 188/2025/NĐ-CP (hiệu lực 15/08/2025) quy định chi tiết nhiều điều của Luật BHYT. Các nhãn tuyến hành chính cũ và tỷ lệ rút gọn theo “tuyến tỉnh/tuyến trung ương” không đủ để quyết định quyền lợi hiện hành, dù vẫn có thể xuất hiện trong dữ liệu chuyển tiếp.

Điều 22 của Luật BHYT đã sửa đổi quy định nhiều nhánh theo cấp chuyên môn, loại điều trị, đối tượng, tình trạng cấp cứu, phạm vi hưởng, trường hợp chuyển cơ sở và điều khoản chuyển tiếp. Vì vậy không nên diễn đạt một tỷ lệ đơn lẻ như quy tắc chung cho mọi ca tự đi KCB tại cấp chuyên sâu, cũng không nên gán nhãn “đúng tuyến” tự động chỉ từ một cờ cấp cứu trong dữ liệu. Quyền lợi và hồ sơ chứng minh phải được xác định theo văn bản có hiệu lực và tình tiết cụ thể của lượt KCB.

VN Core trial-use đặt vn-ext-insurance-visit-type trên Encounter để tương thích danh mục legacy MA_LYDO_VVIEN của QĐ 4210/QĐ-BYT (1=đúng tuyến, 2=cấp cứu, 3=trái tuyến, 4=thông tuyến); mã 5=KCB ban đầu là mở rộng dự án chờ nguồn. Chuẩn hiện hành dùng MA_DOI_TUONG_KCB với 27 mã theo QĐ 3276/QĐ-BYT. Extension vn-ext-referral-mode bảo toàn HTCHUYEN theo convention tích hợp hiện có (1=tự đến, 2=chuyển đến từ tuyến dưới, 3=từ tuyến trên, 4=cùng tuyến, 5=cấp cứu). Các tên “tuyến dưới/trên/cùng tuyến” ở đây là display của bộ mã nguồn, không thay thế mô hình ba cấp KCB hiện hành. Dùng Encounter.basedOn để liên kết ServiceRequest; Encounter.appointment chỉ tham chiếu Appointment. Payer hoặc dịch vụ adjudication xác định kết quả theo toàn bộ dữ liệu và quy tắc hiện hành, không chỉ hai extension này.

{
  "resourceType": "Encounter",
  "id": "enc-bv-tinh-001",
  "status": "in-progress",
  "extension": [
    {
      "url": "http://fhir.hl7.org.vn/core/StructureDefinition/vn-ext-insurance-visit-type",
      "valueCoding": {
        "system": "http://fhir.hl7.org.vn/core/CodeSystem/vn-insurance-visit-type-cs",
        "code": "1",
        "display": "Đúng tuyến"
      }
    },
    {
      "url": "http://fhir.hl7.org.vn/core/StructureDefinition/vn-ext-referral-mode",
      "valueCodeableConcept": {
        "coding": [{
          "system": "http://fhir.hl7.org.vn/core/CodeSystem/vn-referral-mode-cs",
          "code": "2",
          "display": "Chuyển đến từ tuyến dưới"
        }]
      }
    }
  ],
  "basedOn": [{ "reference": "ServiceRequest/sr-referral-001" }],
  "subject": { "reference": "Patient/lan-001" },
  "serviceProvider": { "reference": "Organization/bv-tinh-k" }
}

Tên extension cụ thể trong VN Core IG có thể thay đổi theo phiên bản; nguồn chính thức luôn là các file FSH trong input/fsh/extensions/ của repository.

Bundle transaction mẫu

Có thể dùng Bundle kiểu transaction khi server đích hỗ trợ interaction transaction và khai báo trong CapabilityStatement. Với transaction được chấp nhận, server xử lý tập entry theo ngữ nghĩa nguyên tử của FHIR; nếu endpoint không hỗ trợ, các bên phải dùng message, document hoặc API workflow khác và quy định rõ bù trừ/idempotency.

{
  "resourceType": "Bundle",
  "type": "transaction",
  "entry": [
    {
      "fullUrl": "urn:uuid:sr-referral-001",
      "resource": { "resourceType": "ServiceRequest", "id": "sr-referral-001" },
      "request": { "method": "POST", "url": "ServiceRequest" }
    },
    {
      "fullUrl": "urn:uuid:task-referral-001",
      "resource": { "resourceType": "Task", "id": "task-referral-001" },
      "request": { "method": "POST", "url": "Task" }
    },
    {
      "fullUrl": "urn:uuid:comp-referral-001",
      "resource": { "resourceType": "Composition", "id": "comp-referral-001" },
      "request": { "method": "POST", "url": "Composition" }
    },
    {
      "fullUrl": "urn:uuid:prov-001",
      "resource": {
        "resourceType": "Provenance",
        "target": [{ "reference": "Composition/comp-referral-001" }],
        "recorded": "2026-04-30T10:05:00+07:00",
        "agent": [{ "who": { "reference": "PractitionerRole/bs-tyt-001" } }],
        "signature": [{
          "type": [{ "system": "urn:iso-astm:E1762-95:2013", "code": "1.2.840.10065.1.12.1.1" }],
          "when": "2026-04-30T10:05:00+07:00",
          "who": { "reference": "PractitionerRole/bs-tyt-001" },
          "data": "..."
        }]
      },
      "request": { "method": "POST", "url": "Provenance" }
    }
  ]
}

Provenance.signature là nơi FHIR có thể mang biểu diễn chữ ký và metadata liên quan; nó không tự làm chữ ký có giá trị pháp lý. Việc kiểm tra cần biết chính xác payload được ký, canonicalization, thuật toán, certificate/trust chain, dấu thời gian, trạng thái thu hồi và chính sách nhận dạng người ký. Cơ quan hoặc bên chi trả chỉ nên sử dụng dữ liệu này theo thẩm quyền và quy trình xác minh đã công bố.

Câu hỏi thường gặp

Có bắt buộc phải dùng SmartCA hoặc USB token để ký mỗi referral không?

Thông tư 13/2025/TT-BYT không chỉ định SmartCA hoặc USB token. Văn bản cho phép ký điện tử hợp pháp, sinh trắc học hoặc hình thức xác nhận điện tử khác theo pháp luật về giao dịch điện tử. Một sản phẩm cụ thể chỉ được dùng khi đáp ứng yêu cầu pháp lý, trust framework, chính sách an toàn và phạm vi tài liệu của cơ sở; không thể suy ra rằng mọi hình thức nêu tên đều mặc nhiên hợp lệ cho mọi referral.

Cơ sở đích từ chối tiếp nhận, workflow ra sao?

Theo state machine đề xuất, Task chuyển sang rejected kèm statusReason. Cơ sở gốc nhận kết quả qua cơ chế đã thỏa thuận — Subscription nếu được hỗ trợ, polling hoặc message — rồi có thể tạo yêu cầu mới. Yêu cầu cũ được lưu hoặc chuyển trạng thái theo chính sách hồ sơ và quy tắc versioning; không xóa chỉ để che lịch sử nghiệp vụ.

Cấp cứu không có thời gian làm referral trước, xử lý thế nào?

Cơ sở tiếp nhận ghi nhận và xử trí cấp cứu theo quy trình áp dụng. Không tạo hoặc backdate ServiceRequest như thể một order đã tồn tại trước đó. Nếu quy trình sau cấp cứu thực sự phát sinh yêu cầu chuyển, tạo resource tại thời điểm thật, liên kết Encounter cấp cứu và ghi rõ bối cảnh; Provenance, khi được dùng, phản ánh thời điểm tạo thật. Quyền lợi BHYT do hệ thống có thẩm quyền xác định từ điều kiện pháp lý và hồ sơ chứng minh, không từ việc đặt priority=asap hay một mã FHIR đơn lẻ.

Bệnh nhân không có CCCD, làm sao tạo Patient hợp lệ?

FHIR base để Patient.identifier là tùy chọn, nhưng VNCorePatient trial-use yêu cầu tối thiểu một identifier và slice CCCD 1..1 như quy tắc conformance của dự án. Khi chưa có giá trị CCCD, slice này vẫn hiện diện với data-absent-reason và phải có căn cứ thay thế hợp lệ theo profile: extension lý do bất khả kháng, hộ chiếu hoặc giấy khai sinh. MRN có thể bổ sung định danh cục bộ nhưng không tự thay thế điều kiện trên. Đây là ràng buộc VN Core trial-use; Điều 1 khoản 3 TT 13/2025/TT-BYT chỉ yêu cầu kết nối thông tin bệnh án với số định danh cá nhân của các nhóm đối tượng được quy định và không tự đặt cardinality FHIR này hay cho phép tài khoản VNeID thay thế số định danh.

Tham chiếu

• HL7 FHIR R4 ServiceRequest: hl7.org/fhir/R4/servicerequest.html
• HL7 FHIR R4 Task: hl7.org/fhir/R4/task.html
• HL7 FHIR R4 Composition: hl7.org/fhir/R4/composition.html
• HL7 FHIR R4 Provenance và signature: hl7.org/fhir/R4/provenance.html
• Luật 51/2024/QH15 sửa đổi Luật Bảo hiểm y tế: congbao.chinhphu.vn
• Nghị định 188/2025/NĐ-CP hướng dẫn Luật BHYT: legal-corpus#ND-188-2025
• Thông tư 13/2025/TT-BYT về hồ sơ bệnh án điện tử: legal-corpus#TT-13-2025
• Nghị định 137/2024/NĐ-CP về giao dịch điện tử: legal-corpus#ND-137-2024
• Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP về bảo vệ dữ liệu cá nhân: legal-corpus#Luat-91-2025
• LOINC mã 57133-1 “Referral note”: loinc.org/57133-1
• VN Core IG canonical: fhir.hl7.org.vn/core

Đọc tiếp