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 tuyến giữa các cơ sở khám chữa bệnh là quy trình hành chính kết hợp lâm sàng phổ biến nhất trong hệ thống y tế Việt Nam. Một bệnh nhân tăng huyết áp tại trạm y tế xã có thể được chuyển lên bệnh viện tỉnh khi xuất hiện cơn cấp tính. Một ca nghi ngờ nhồi máu cơ tim ở bệnh viện tỉnh được chuyển lên bệnh viện trung ương. Một bệnh nhi cần phẫu thuật tim chuyên sâu được chuyển từ bệnh viện đa khoa sang bệnh viện chuyên khoa nhi. Tất cả đều đi qua một mảnh giấy A4 in sẵn, được điền tay, đóng dấu đỏ và đưa cho bệnh nhân tự cầm.

Hiện trạng giấy mang lại nhiều rủi ro. Chữ viết tay khó đọc dẫn tới nhập sai dữ liệu tại cơ sở đích. Bệnh nhân làm mất giấy hoặc đến muộn khiến quy trình tiếp nhận bị gián đoạn. Cơ sở đích không có thông tin trước nên không chuẩn bị giường, trang thiết bị hay nhân lực. Cơ quan bảo hiểm xã hội không có cách kiểm tra nhanh xem ca chuyển có đúng tuyến hay không, dẫn đến tranh cãi thanh toán sau khi điều trị đã xong. Audit trail gần như không tồn tại, gây khó khăn khi cần truy vết sự cố y khoa.

Thông tư 13/2025/TT-BYT về hồ sơ bệnh án điện tử đặt nền móng pháp lý quan trọng. Văn bản yêu cầu các cơ sở khám chữa bệnh tạo, cập nhật, ký xác thực điện tử và tra cứu hồ sơ bệnh án bằng phương thức hợp pháp; bệnh viện phải hoàn thành EMR chậm nhất ngày 30/9/2025 và toàn bộ cơ sở khác chậm nhất 31/12/2026. Thông tư 13 không bắt buộc một định dạng cụ thể cho giấy chuyển viện điện tử, cũng không quy định thuật toán BHXH tự động xác minh đúng tuyến; tuy nhiên hệ sinh thái EMR mà thông tư tạo ra chính là nền để FHIR-based referral hoạt động được.

FHIR R4 cung cấp đúng ba resource cần thiết để mô hình hoá quy trình này: ServiceRequest cho lệnh lâm sàng, Task cho workflow xuyên cơ sở, và Composition cho tài liệu referral letter có cấu trúc. Bài viết tiếp theo sẽ đi sâu vào cách ánh xạ mẫu giấy hiện hành sang ba resource đó.

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

Mẫu giấy chuyển viện đang được dùng phổ biến tại Việt Nam là biểu mẫu một trang gồm các trường thông tin tương đối ổn định qua nhiều bản hướng dẫn của Bộ Y tế và Bảo hiểm xã hội Việt Nam. Mặc dù từng cơ sở có biến thể nhỏ về layout, các trường lõi gần như giống nhau: số giấy chuyển, ngày lập, cơ sở gốc, cơ sở đích, thông tin định danh bệnh nhân, chẩn đoán hiện tại, lý do chuyển, tiền sử và điều trị đã làm, đề xuất hướng tiếp theo, chữ ký bác sĩ và dấu đỏ của cơ sở.

Khi bóc tách từng trường, ta thấy mỗi trường mang một loại thông tin có thể ánh xạ trực tiếp vào FHIR. Số giấy chuyển là identifier nghiệp vụ. Ngày lập là timestamp. Cơ sở gốc cùng bác sĩ ký là cặp Organization và Practitioner. Bệnh nhân là Patient với các identifier như CCCD, mã thẻ BHYT, mã hồ sơ. Chẩn đoán dùng ICD-10 phiên bản Việt Nam theo QĐ 4469/QĐ-BYT (có bổ sung mã COVID-19 theo QĐ 98/QĐ-BYT). Lý do chuyển và đề xuất tiếp theo là văn bản tự do nhưng cần được lưu có cấu trúc để truy vấn được. Tiền sử và điều trị đã làm tham chiếu đến các Condition, MedicationRequest, Observation đã có trong EMR. Cuối cùng, chữ ký số thay thế chữ ký tay và dấu đỏ.

Một điểm cần lưu ý: mẫu giấy hiện hành không phân biệt rõ giữa “yêu cầu chuyển” và “tài liệu giải thích yêu cầu”. Trên giấy, hai khái niệm đó hoà làm một. Khi lên FHIR, chúng được tách rõ: ServiceRequest là yêu cầu (lệnh dịch vụ), Composition là tài liệu giải thích, còn Task là dòng trạng thái theo dõi việc thực thi yêu cầu đó. Sự tách lớp này là điều kiện để hai cơ sở có thể trao đổi và đồng bộ trạng thái mà không cần kéo nguyên cả tài liệu PDF qua lại.

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.

Ba resource cốt lõi: ServiceRequest, Task, 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 bài toán chuyển tuyến, dịch vụ chính là “tiếp tục chăm sóc cho bệnh nhân tại cơ sở đích”. Đây là resource duy nhất bắt buộc phải có chữ ký số, vì nó mang tính chất lệnh nghiệp vụ và là gốc tham chiếu cho cả Task lẫn Composition.

{
  "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 ra khỏi nội dung lâm sàng. Khi cơ sở đích chấp nhận, từ chối hay hoàn tất tiếp nhận, chỉ Task thay đổi; ServiceRequest và Composition vẫn giữ nguyên như tài liệu pháp lý đã ký. Cách tách lớp này phản ánh nguyên tắc thiết kế của FHIR: một resource một mục đích.

{
  "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" }
}

Task chuyển trạng thái theo trình tự requested → accepted → in-progress → completed. Khi cơ sở đích từ chối, dùng rejected kèm statusReason mô tả lý do. Khi bệnh nhân không đến trong thời gian thoả thuận, dùng cancelled. Cơ sở gốc theo dõi Task qua FHIR Subscription để cập nhật ngược lại EMR của mình.

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

Composition đóng vai trò referral letter — tài liệu giải thích lý do chuyển kèm tóm tắt thông tin lâm sàng. Đây là bản kế thừa số của “mặt sau giấy chuyển viện”, nhưng có cấu trúc rõ ràng hơn nhiều. FHIR R4 quy định Composition phải có đủ status, type, subject, date, author, title và mỗi section.text 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 các resource đã có trong Bundle hoặc trên FHIR server, còn section.text là phần văn bản hiển thị được cho con người. Hai phần phải nhất quán; người ký xác nhận chính phần Narrative chứ không phải các reference.

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

Quy trình chuyển tuyến điện tử end-to-end gồm tám bước, kéo dài từ khi bác sĩ tại cơ sở gốc nhận định cần chuyển cho đến khi cơ sở đích hoàn tất tiếp nhận và phản hồi.

Bước 1. BS tại TYT xã H. khám và quyết định chuyển BN
Bước 2. Hệ thống EMR tạo Bundle: ServiceRequest + Task + Composition + Provenance
Bước 3. BS ký xác thực điện tử (TT 13/2025) lên Composition và ServiceRequest
Bước 4. Bundle POST sang FHIR Server cấp tỉnh hoặc trục liên thông
Bước 5. FHIR Subscription đẩy thông báo sang BV tỉnh K. - Task.status = requested
Bước 6. BS BV tỉnh K. nhận, accept Task -> Task.status = accepted
Bước 7. BN đến BV - tạo Encounter mới reference ServiceRequest -> Task.status = in-progress
Bước 8. Sau điều trị, BV tỉnh tạo discharge Composition và set Task.status = completed

Mỗi bước đều ghi lại trong AuditEvent và Provenance để đảm bảo audit trail theo Luật 91/2025/QH15 về bảo vệ dữ liệu cá nhân và Nghị định 356/2025/NĐ-CP. Khi cần truy vết sự cố, ta có thể dựng lại toàn bộ chuỗi sự kiện thay vì phụ thuộc vào ký ức người tham gia.

Trong tình huống cấp cứu, quy trình có thể đảo ngược thứ tự: bệnh viện tiếp nhận xử trí trước, sau đó tạo retroactive ServiceRequest có occurrenceDateTime gắn với thời điểm cấp cứu thực tế và note ghi rõ lý do tạo sau.

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

Luật 51/2024/QH15 sửa đổi Luật Bảo hiểm y tế đã thay khung tuyến cũ (xã - huyện - tỉnh - trung ương) bằng mô hình ba cấp chuyên môn kỹ thuật: cấp ban đầu, cấp cơ bản và cấp chuyên sâu. Nghị định 188/2025/NĐ-CP hướng dẫn chi tiết quy tắc thanh toán theo mô hình này. Cách diễn đạt cũ “60% nội trú tỉnh, 40% tuyến trung ương” không còn phản ánh đúng quy tắc hiện hành.

Theo Điều 22 Luật BHYT (đã sửa đổi), bệnh nhân được thanh toán đầy đủ theo mức hưởng trong các trường hợp khám chữa bệnh tại cấp ban đầu, một số trường hợp tại cấp cơ bản, kèm các tình huống chuyển tiếp theo quy định cấp huyện cũ. Khi tự đi khám chữa bệnh nội trú tại cấp chuyên sâu mà không qua chuyển tuyến đúng quy định, mức hưởng còn 40% của mức hưởng theo quy định, ngoại trừ một số đối tượng đặc biệt được liệt kê. Cấp cứu luôn được coi là đúng tuyến bất kể bệnh nhân đến cơ sở nào.

Trên FHIR, ngữ cảnh đúng tuyến hay trái tuyến được biểu diễn ở Encounter của lần khám chữa bệnh tại cơ sở đích. VN Core IG sử dụng các extension vn-ext-insurance-visit-type để mô tả loại khám chữa bệnh BHYT (ban đầu, chuyển tuyến, cấp cứu, thông tuyến) và vn-ext-referral-mode ghi nhận hình thức chuyển tuyến HTCHUYEN theo QĐ 3176/QĐ-BYT (1=tự đến, 2=chuyển từ tuyến dưới, 3=từ tuyến trên, 4=cùng tuyến, 5=cấp cứu). Liên kết với ServiceRequest gốc nên thực hiện qua Encounter.basedOn hoặc Encounter.appointment, KHÔNG qua extension này. Việc xác định cuối cùng đúng tuyến hay không nên do hệ thống của cơ quan BHXH thực hiện, dựa trên ServiceRequest tham chiếu, cấp chuyên môn của hai cơ sở và đối tượng tham gia BHYT.

{
  "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": "referral",
        "display": "Khám chữa bệnh do chuyển 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 từ tuyến dưới"
        }]
      }
    }
  ],
  "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

Khi cơ sở gốc submit referral, toàn bộ ServiceRequest, Task, Composition và các resource phụ trợ được đóng gói trong một Bundle kiểu transaction. FHIR Server đích xử lý nguyên tử; nếu một entry lỗi, toàn bộ bị rollback để tránh trạng thái nửa vời.

{
  "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 giữ chữ ký số theo chuẩn HL7 và là bằng chứng pháp lý cho thao tác ký. Khi BHXH hoặc cơ quan thanh tra cần kiểm tra, họ truy Provenance.signature.data và xác thực với chứng thư của bác sĩ.

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?

Không. Thông tư 13/2025/TT-BYT yêu cầu tài liệu phải được ký xác thực bằng phương thức điện tử hợp pháp; SmartCA, USB token, sinh trắc học hoặc các hình thức xác thực điện tử khác đều có thể chấp nhận miễn là tuân thủ pháp luật về giao dịch điện tử (Nghị định 137/2024/NĐ-CP). Lựa chọn cụ thể phụ thuộc vào chính sách bảo mật của từng cơ sở.

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

Task chuyển trạng thái sang rejected kèm statusReason mô tả lý do (hết giường, chuyên khoa không phù hợp, vượt quá năng lực kỹ thuật). Cơ sở gốc nhận thông báo qua Subscription, có thể tạo ServiceRequest mới chỉ định cơ sở đích khác. ServiceRequest cũ không bị xoá; nó vẫn tồn tại trong audit trail.

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 xử trí cấp cứu trước. Sau khi tình trạng bệnh nhân ổn định, hệ thống tạo retroactive ServiceRequest với occurrenceDateTime gắn vào thời điểm cấp cứu, priority là asap, và note ghi rõ “tạo sau cấp cứu”. Provenance ghi nhận thời điểm tạo thực tế. Cấp cứu luôn được coi là đúng tuyến nên không ảnh hưởng đến thanh toán BHYT.

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

FHIR base Patient có identifier tuỳ chọn. Tuy nhiên VNCorePatient yêu cầu ít nhất một identifier; profile hỗ trợ slice cho hộ chiếu, giấy khai sinh, mã hồ sơ nội bộ và data-absent-reason cho các trường hợp bất khả kháng. Trẻ sơ sinh chưa có CCCD thường dùng giấy khai sinh; người nước ngoài dùng hộ chiếu. Các giấy tờ tạm thời như giấy tạm trú không nằm trong slice chuẩn của VNCorePatient ở thời điểm hiện tại.

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