Liên thông bệnh viện tỉnh ⇄ trạm y tế xã sau mô hình 2 cấp

Nghị quyết 202/2025/QH15 sắp xếp 34 đơn vị hành chính cấp tỉnh, còn Luật Tổ chức chính quyền địa phương 72/2025/QH15 chính thức đặt nền cho mô hình hai cấp tỉnh và xã. Mạng lưới y tế công lập theo đó co lại quanh hai trục: bệnh viện tuyến tỉnh và trạm y tế xã. Trang này hướng dẫn dùng HL7 FHIR R4 để liên thông hai chiều — giấy chuyển tuyến từ TYT xã lên bệnh viện tỉnh và tóm tắt xuất viện gửi ngược về xã để theo dõi.

Tóm tắt nhanh

  • Bài toán cốt lõi: bệnh nhân khám TYT xã cần chuyển lên BV tỉnh, BV tỉnh cần thấy hồ sơ xã, sau xuất viện TYT cần tóm tắt để theo dõi.
  • Pattern minh họa: FHIR R4 Composition (referral note + discharge summary) đóng gói trong document Bundle. Có thể dùng IHE MHD ITI-65 khi các bên chủ đích yêu cầu conformance MHD và đã thống nhất actor, option, version.
  • Tài nguyên chính: Patient, Encounter, Condition, Observation, MedicationRequest, Procedure, DocumentReference, Bundle.
  • Thông báo gần thời gian thực có thể dùng FHIR R4 Subscription (REST hook) khi server công bố hỗ trợ; nếu cần SubscriptionTopic phải khai báo phụ thuộc R5 Subscription Backport IG.
  • Thin-client PWA, trục FHIR cấp tỉnh, offline-first và sync queue là một phương án tham chiếu; quyết định triển khai phải dựa trên khảo sát kết nối, thiết bị, vận hành và ranh giới dữ liệu thực tế.

1. Bối cảnh pháp lý — NQ 202/2025/QH15 và Luật 72/2025/QH15

Hai văn bản nền đặt ra mô hình mới cần được đọc tách bạch. Nghị quyết 202/2025/QH15 (ban hành 12/06/2025, hoạt động chính thức 01/07/2025) quyết định sắp xếp các đơn vị hành chính cấp tỉnh, đưa Việt Nam từ 63 tỉnh, thành phố trực thuộc trung ương xuống còn 34 đơn vị, gồm 28 tỉnh và 6 thành phố. Luật Tổ chức chính quyền địa phương 72/2025/QH15 (ban hành 16/06/2025, hiệu lực 01/07/2025) thiết lập tổ chức chính quyền địa phương theo hai cấp: cấp tỉnh và cấp xã, gồm phường, xã và đặc khu, với khoảng 3.321 đơn vị cấp xã sau sắp xếp.

Y tế công lập đi theo cùng nhịp. Tuyến trung ương vẫn giữ vai trò đỉnh tháp, tuyến tỉnh đảm nhận điều trị chuyên sâu cấp khu vực, và trạm y tế xã (TYT xã) là điểm chăm sóc ban đầu gần dân nhất. Cấp huyện không còn là một cấp hành chính độc lập, do đó các trung tâm y tế huyện và bệnh viện huyện cũ phải được tổ chức lại theo quyết định của từng địa phương. Một số đơn vị chuyển hóa thành chi nhánh của bệnh viện tỉnh, một số trở thành phòng khám đa khoa khu vực gắn vào TYT xã, và giai đoạn chuyển tiếp này có thể kéo dài. Hệ quả với hệ thống thông tin: định danh tổ chức và mã đơn vị hành chính trong mọi giao dịch lâm sàng cần hỗ trợ song song mã cũ và mã mới trong nhiều quý.

Văn bản hợp nhất 06/2026/VBHN-BYT cụ thể hóa chức năng, nhiệm vụ của TYT xã, phường, đặc khu trong mô hình mới. Đó là cơ sở pháp lý cho phép TYT khám bệnh, kê đơn ngoại trú, chuyển tuyến và theo dõi sau xuất viện — chính là các kịch bản FHIR mà trang này mô tả.

2. Bài toán cụ thể qua câu chuyện Bà Lan 65 tuổi

Bà Lan, 65 tuổi, sống ở xã H. Sáng 30/04/2026 bà đau ngực dữ dội và đến TYT xã. Bác sĩ trực TYT đo huyết áp 170/100 mmHg, mạch 110, đo điện tim ba chuyển đạo và phát hiện ST chênh lên ở V2-V4. Năng lực TYT chỉ đủ chẩn đoán sơ bộ và xử trí ban đầu — bác sĩ quyết định chuyển ngay lên BV tỉnh K. cách đó 28 km. Đây là tình huống điển hình mà liên thông FHIR cần phục vụ.

Bốn yêu cầu thông tin xuất hiện đồng thời. Một, BV tỉnh phải thấy bệnh sử tăng huyết áp đã điều trị ba năm nay tại TYT, không cần khai thác lại từ đầu. Hai, hình ảnh ECG và sinh hiệu phải đến tay khoa cấp cứu trước khi xe đến cổng — để ê-kíp can thiệp tim mạch chuẩn bị phòng thông tim. Ba, đơn thuốc bà Lan đang dùng phải đi cùng để tránh tương tác và quyết định ngừng các thuốc chống ngưng tập tiểu cầu trước thủ thuật. Bốn, khi bà Lan ra viện sau đặt stent, TYT xã H. phải nhận được tóm tắt xuất viện đầy đủ để theo dõi huyết áp hằng ngày, chỉnh liều thuốc, và tái khám sau một tuần.

Mỗi yêu cầu trên ánh xạ sang một resource hoặc một workflow FHIR cụ thể. Phần còn lại của trang đi qua từng ánh xạ đó, kèm payload mẫu và lưu ý triển khai.

3. Kiến trúc FHIR cho liên thông tỉnh ⇄ xã

Kiến trúc dưới đây là một phương án tham chiếu: FHIR server có thể được vận hành ở cấp tỉnh hoặc tại bệnh viện đầu mối, còn TYT xã dùng client gọi API theo CapabilityStatement đã thỏa thuận. Kênh số hỗ trợ trao đổi dữ liệu nhưng không thay thế quy trình liên lạc lâm sàng, đặc biệt trong cấp cứu. Sơ đồ logic minh họa như sau.

[TYT xã (PWA, FHIR R4 client)]
       │  POST Bundle ITI-65 (referral)
       ▼
[FHIR R4 Server tại Sở/BV tỉnh]
       │  Subscription notification (rest-hook)
       ▼
[App BS BV tỉnh / khoa cấp cứu]
       │  POST Bundle ITI-65 (discharge summary)
       ▼
[FHIR R4 Server (cùng trục)]
       │  Subscription rest-hook → TYT xã
       ▼
[TYT xã PWA: hiển thị tóm tắt xuất viện, lập lịch tái khám]

Lưu ý phiên bản. VN Core đang cố định ở FHIR R4 (4.0.1). Trong R4, push real-time dùng resource Subscription với criteria dạng search string và channel.type = rest-hook. Cơ chế SubscriptionTopic chỉ tồn tại trong R4B/R5, hoặc trong R4 thông qua R5 Subscription Backport IG; nếu dự án muốn dùng topic-based subscription, phải khai báo phụ thuộc backport IG đó trong sushi-config và validate cẩn thận.

Định danh bệnh nhân dùng số định danh cá nhân (CCCD 12 số) làm primary identifier theo hệ http://fhir.hl7.org.vn/core/sid/cccd, kèm mã thẻ BHYT làm secondary. Định danh tổ chức dùng mã cơ sở khám chữa bệnh do BHXH cấp; mã đơn vị hành chính dùng danh mục 34 tỉnh và 3.321 xã theo Quyết định 19/2025/QĐ-TTg.

4. Kịch bản 1 — TYT xã chuyển lên BV tỉnh

Quy trình bốn bước. Bước một, TYT lập Encounter cho lượt khám, tạo Observation cho huyết áp, mạch, ECG, lập Condition cho chẩn đoán nghi nhồi máu cơ tim, ghi MedicationRequest cho thuốc đang dùng, rồi tổng hợp tất cả vào một Composition dạng giấy chuyển tuyến. Bước hai, TYT đóng gói Composition cùng các resource liên quan thành một Bundle dạng document, rồi gửi qua giao dịch IHE MHD ITI-65. Bước ba, FHIR server tỉnh nhận Bundle, lưu các resource và đẩy thông báo đến BV tỉnh qua Subscription. Bước bốn, hệ thống bệnh viện tỉnh tạo Encounter mới và tham chiếu ngược lên Composition referral để giữ liên kết hai chiều.

Composition cho giấy chuyển tuyến phải đầy đủ các trường bắt buộc theo FHIR R4: status, type, subject, date, author, title. Nếu một section có cả entrytext, text phải là Narrative dạng object { status, div } với div là XHTML hợp lệ — không bao giờ là chuỗi thuần.

{
  "resourceType": "Composition",
  "id": "comp-referral-lan-001",
  "status": "final",
  "type": {
    "coding": [
      { "system": "http://loinc.org", "code": "57133-1", "display": "Referral note" }
    ]
  },
  "subject": { "reference": "Patient/lan-001" },
  "encounter": { "reference": "Encounter/tyt-001" },
  "date": "2026-04-30T08:30:00+07:00",
  "author": [{ "reference": "Practitioner/bs-tyt-001" }],
  "title": "Giấy chuyển tuyến — TYT xã H. → BV tỉnh K.",
  "section": [
    {
      "title": "Lý do chuyển",
      "text": {
        "status": "generated",
        "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">Đau ngực cấp, ECG có ST chênh ở V2-V4, nghi nhồi máu cơ tim — vượt năng lực TYT.</div>"
      }
    },
    {
      "title": "Tiền sử",
      "entry": [{ "reference": "Condition/htn-001" }]
    },
    {
      "title": "Sinh hiệu và cận lâm sàng",
      "entry": [
        { "reference": "Observation/bp-001" },
        { "reference": "Observation/hr-001" },
        { "reference": "Observation/ecg-001" }
      ]
    },
    {
      "title": "Đơn thuốc đang dùng",
      "entry": [{ "reference": "MedicationRequest/mr-001" }]
    }
  ]
}

Ghi chú validate: Composition dùng mã LOINC 57133-1 cho referral note. Mỗi entry tham chiếu đến resource đầy đủ trong cùng Bundle (qua fullUrl) hoặc đến resource đã tồn tại theo quy tắc của profile áp dụng. Narrative không tự động được bảo đảm chỉ vì section có entry; hệ thống tạo tài liệu phải sinh, kiểm tra và duy trì Composition.section.text theo chính sách trình bày của mình.

5. Kịch bản 2 — BV tỉnh trả tóm tắt xuất viện về xã

Sau khi bà Lan được đặt stent động mạch vành phải và ổn định, bác sĩ điều trị tại BV tỉnh K. lập tóm tắt xuất viện. Cấu trúc Composition giống referral nhưng đổi type sang mã LOINC 18842-5 (Discharge summary) và đổi danh sách section sang chẩn đoán xuất viện, thủ thuật đã thực hiện, đơn thuốc tiếp tục, hướng dẫn theo dõi tại tuyến xã.

{
  "resourceType": "Composition",
  "id": "comp-discharge-lan-001",
  "status": "final",
  "type": {
    "coding": [
      { "system": "http://loinc.org", "code": "18842-5", "display": "Discharge summary" }
    ]
  },
  "subject": { "reference": "Patient/lan-001" },
  "encounter": { "reference": "Encounter/bv-tinh-001" },
  "date": "2026-05-05T14:00:00+07:00",
  "author": [{ "reference": "Practitioner/bs-bv-tinh-001" }],
  "title": "Tóm tắt xuất viện — BV tỉnh K.",
  "section": [
    {
      "title": "Chẩn đoán xuất viện",
      "entry": [{ "reference": "Condition/dx-001" }]
    },
    {
      "title": "Điều trị đã thực hiện",
      "entry": [{ "reference": "Procedure/proc-001" }]
    },
    {
      "title": "Đơn thuốc tiếp tục",
      "entry": [{ "reference": "MedicationRequest/mr-002" }]
    },
    {
      "title": "Hướng dẫn theo dõi tại TYT xã",
      "text": {
        "status": "generated",
        "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">Tái khám sau 1 tuần tại TYT xã H. Theo dõi huyết áp 2 lần/ngày. Báo BV tỉnh K. nếu đau ngực tái phát hoặc HA tâm thu &gt; 160 mmHg.</div>"
      }
    }
  ]
}

Trong kiến trúc minh họa, BV tỉnh đăng ký tài liệu bằng ITI-65 nếu môi trường đã chọn MHD; nếu không, các bên dùng giao dịch FHIR được quy định riêng trong hợp đồng tích hợp. Server có thể phát thông báo qua Subscription khi CapabilityStatement và chính sách subscription cho phép. Client tại TYT nhận thông báo, lấy tài liệu sau khi kiểm tra quyền truy cập và đưa hướng dẫn cho nhân viên xác nhận; không nên tự lập lịch từ narrative tự do nếu chưa có CarePlan/Task hoặc quy tắc chuyển đổi đã kiểm thử.

Section hướng dẫn theo dõi cố tình dùng Narrative thay vì entry — vì hướng dẫn là văn xuôi tiếng Việt do bác sĩ viết tay, không phù hợp ép vào CarePlan ngay lúc xuất viện. Nếu sau này TYT muốn nâng lên CarePlan có structured Goal và Activity, có thể chuyển hóa từ chính narrative này.

6. Resource pattern và mã LOINC

Bảng tổng hợp các resource FHIR R4 cần triển khai cho cả hai chiều liên thông.

Resource Vai trò Mã chuẩn
Patient Định danh bằng CCCD và mã thẻ BHYT, kèm địa chỉ xã/phường mới vn-core-patient
Organization Phân biệt TYT xã và BV tỉnh, gắn mã CSKCB BHXH cấp vn-core-organization
Encounter Một Encounter cho lượt khám TYT, một cho đợt điều trị BV tỉnh, liên kết qua partOf vn-core-encounter
Composition Giấy chuyển tuyến (LOINC 57133-1) và tóm tắt xuất viện (LOINC 18842-5) LOINC 57133-1, 18842-5
Condition Chẩn đoán theo ICD-10 VN (QĐ 4469/QĐ-BYT, bổ sung QĐ 98/QĐ-BYT) vn-icd10-cs
Observation Sinh hiệu, ECG, kết quả cận lâm sàng theo QĐ 1227/QĐ-BYT đợt 1 LOINC + QĐ 1227/QĐ-BYT
MedicationRequest Đơn thuốc theo TT 26/2025/TT-BYT (hóa dược ngoại trú) vn-medication-cs
Procedure Thủ thuật can thiệp theo ICD-9-CM bản 2026 (QĐ 387/QĐ-BYT) vn-procedure-cs
DocumentReference Index cho Bundle document, kèm bản PDF ký số nếu cần IHE MHD
Bundle type=document cho payload nội dung; type=transaction cho ITI-65 wrapper FHIR R4
Subscription Push thông báo cho cả hai chiều, channel rest-hook hoặc message FHIR R4 hoặc R5 backport

7. Đóng gói IHE MHD ITI-65 đúng chuẩn

IHE Mobile access to Health Documents (MHD) định nghĩa giao dịch ITI-65 Provide Document Bundle để Document Source đăng ký tài liệu với Document Recipient. Đây là một lựa chọn có profile, không phải cơ chế mặc định cho mọi kết nối FHIR. ITI-65 gửi POST [base] với Bundle dạng transaction; payload phải tuân thủ đúng profile SubmissionSet, DocumentReference và các tùy chọn của phiên bản MHD được tuyên bố. Một document Bundle dùng type=document là nội dung lâm sàng khác với transaction Bundle dùng để đăng ký nó.

{
  "resourceType": "Bundle",
  "id": "bundle-iti65-lan-001",
  "type": "transaction",
  "meta": {
    "profile": [
      "https://profiles.ihe.net/ITI/MHD/StructureDefinition/IHE.MHD.Comprehensive.ProvideBundle"
    ]
  },
  "entry": [
    {
      "fullUrl": "urn:uuid:list-submissionset-001",
      "resource": {
        "resourceType": "List",
        "status": "current",
        "mode": "working",
        "title": "Giấy chuyển tuyến — Bà Lan",
        "subject": { "reference": "Patient/lan-001" },
        "entry": [
          { "item": { "reference": "urn:uuid:docref-referral-001" } }
        ]
      },
      "request": { "method": "POST", "url": "List" }
    },
    {
      "fullUrl": "urn:uuid:docref-referral-001",
      "resource": {
        "resourceType": "DocumentReference",
        "status": "current",
        "type": {
          "coding": [
            { "system": "http://loinc.org", "code": "57133-1", "display": "Referral note" }
          ]
        },
        "subject": { "reference": "Patient/lan-001" },
        "author": [{ "reference": "Practitioner/bs-tyt-001" }],
        "content": [{
          "attachment": {
            "contentType": "application/fhir+json",
            "url": "Bundle/doc-referral-lan-001"
          }
        }]
      },
      "request": { "method": "POST", "url": "DocumentReference" }
    }
  ]
}

Trong payload trên, List đóng vai trò SubmissionSet và DocumentReference mô tả nội dung được đăng ký. Nếu cần kèm PDF hoặc FHIR document Bundle, cách biểu diễn attachment, Binary, URL và chữ ký phải theo profile MHD đã chọn, chính sách chữ ký điện tử và khả năng của hai actor; riêng việc thêm PDF không tự chứng minh hiệu lực pháp lý hay tính toàn vẹn.

Nếu dự án không yêu cầu ràng buộc IHE chặt chẽ — ví dụ pilot nội bộ một tỉnh — vẫn có thể đơn giản hóa bằng cách gửi thẳng Bundle dạng document qua POST /Bundle hoặc lưu vào endpoint /DocumentReference. Tuy nhiên cần ghi rõ trong tài liệu hệ thống rằng đây là cách tiếp cận FHIR-native chứ không phải IHE MHD ITI-65, để tránh hiểu lầm khi đối tác audit.

8. Triển khai TYT xã trong điều kiện hạn chế

Điều kiện nhân lực, kết nối, hỗ trợ IT và thiết bị khác nhau đáng kể giữa các TYT xã. Thiết kế phải bắt đầu bằng khảo sát từng nhóm cơ sở, thay vì giả định một cấu hình nhân sự hay phần cứng chung cho cả nước.

Bốn quyết định cần được đánh giá. Một, offline-first và hàng đợi đồng bộ chỉ dùng khi threat model, mã hóa thiết bị, xử lý xung đột và thu hồi dữ liệu đã được thiết kế. Hai, mô hình tập trung hay phân tán phải theo trách nhiệm vận hành, tính sẵn sàng và ranh giới dữ liệu. Ba, xác thực dùng cơ chế được cơ quan và hệ thống đích cho phép; tích hợp VNeID chỉ được mô tả khi có API và thỏa thuận được công bố cho phạm vi đó. Bốn, kênh dự phòng không được gửi dữ liệu y tế nhạy cảm qua SMS hay nền tảng nhắn tin nếu chưa có căn cứ, tối thiểu hóa nội dung và kiểm soát bảo mật phù hợp.

Danh mục thiết bị phải xuất phát từ khảo sát từng TYT: máy trạm chạy PWA, thiết bị in và các thiết bị đo chỉ đưa vào phạm vi khi workflow yêu cầu và có giao diện xuất dữ liệu được kiểm thử. Chi phí phụ thuộc hiện trạng, mua sắm, kết nối và bảo trì nên không thể ấn định một mức chung cho mọi xã. Kế hoạch đào tạo cũng cần đo bằng usability test và thời gian hoàn thành tác vụ; người dùng lâm sàng không cần học chi tiết FHIR, nhưng đội tích hợp và vận hành phải hiểu hợp đồng dữ liệu áp dụng.

9. Bài học triển khai và rủi ro

Tính đến tháng 5/2026, chưa có pilot công khai nào triển khai trọn vẹn pattern liên thông tỉnh ⇄ xã trên FHIR R4. Phần này tổng hợp bài học giả lập từ kinh nghiệm các dự án EMR và HIE tương tự ở Việt Nam, kết hợp với kinh nghiệm triển khai quốc tế của Omi HealthTech. Khi có pilot thực tế, trang sẽ được cập nhật.

  • Đào tạo UI thay vì đào tạo FHIR. Bác sĩ TYT không cần biết Composition là gì; họ cần một giao diện chỉ ba bước: nhập triệu chứng, chọn lý do chuyển, nhấn gửi. Mọi resource FHIR sinh ra ở back-end.
  • Subscription cần cơ chế phục hồi. Tùy SLA và rủi ro, có thể dùng retry, hàng đợi bền vững, dead-letter queue, reconciliation hoặc polling; ca khẩn cấp vẫn theo kênh liên lạc lâm sàng đã phê duyệt.
  • ECG attachment theo khả năng thiết bị. Dùng DICOM Waveform khi thiết bị và PACS hỗ trợ; nếu dùng PDF hoặc định dạng khác, DocumentReference phải mô tả đúng content type, nguồn và tính toàn vẹn.
  • Migrate dữ liệu trung tâm y tế huyện cũ. Bulk Data $export là một lựa chọn nếu hệ nguồn hỗ trợ. Có thể cần ETL riêng; Provenance chỉ ghi nhận các sự kiện nguồn gốc mà hệ thống thực sự theo dõi và chính sách yêu cầu.
  • Định danh chéo tuyến. Bệnh nhân khám tỉnh khác bằng CCCD phải resolve được sang Patient resource đúng tỉnh đăng ký BHYT — cần $match operation hoặc Patient Master Index liên tỉnh.

Rủi ro lớn nhất không phải kỹ thuật mà là quản trị: ai chịu trách nhiệm vận hành FHIR server cấp tỉnh, ai tài trợ băng thông cho TYT, ai đào tạo định kỳ. Đây là câu hỏi mà Sở Y tế, bệnh viện đầu mối và đơn vị tư vấn triển khai cần thống nhất trong thiết kế pilot.

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

TYT xã có cần một FHIR server riêng không?

Không. Mô hình khuyến nghị đặt FHIR server tập trung tại Sở Y tế hoặc bệnh viện tỉnh đầu mối. TYT là client gọi REST API. Cách này giảm chi phí vận hành và bảo trì, đồng thời tránh phân mảnh dữ liệu.

Internet TYT không ổn định thì sao?

PWA offline-first lưu giao dịch tạm thời vào IndexedDB, đẩy lên server khi có mạng. Với ca khẩn cấp như bà Lan, fallback SMS hoặc cuộc gọi vẫn cần thiết — FHIR không thay thế quy trình điện thoại trực tiếp giữa bác sĩ TYT và khoa cấp cứu BV tỉnh.

Sáp nhập trung tâm y tế huyện cũ thì migrate dữ liệu thế nào?

Bulk Data $export là một lựa chọn nếu hệ nguồn công bố hỗ trợ đúng IG/version; nếu không có thể cần ETL riêng. Provenance chỉ ghi nguồn gốc được theo dõi, không bảo đảm migration không mất dữ liệu. Cần kiểm kê nguồn, backup, quy tắc reconciliation, báo cáo sai khác và acceptance test trước khi ngừng hệ cũ.

BHYT thanh toán cross-tuyến trong mô hình mới ra sao?

Quy tắc mức hưởng và thanh toán phải được xác định theo Luật BHYT cùng văn bản hướng dẫn hiện hành cho đúng đối tượng, dịch vụ và tuyến chuyên môn; trang kiến trúc này không thay thế hướng dẫn nghiệp vụ BHXH. Dữ liệu đầu ra KCB hiện hành vẫn theo chuỗi QĐ 130/QĐ-BYT, QĐ 4750/QĐ-BYT và QĐ 3176/QĐ-BYT. Ánh xạ toàn bộ hồ sơ XML sang FHIR cần đặc tả chuyển đổi theo trường/cấu trúc và bộ kiểm thử; ConceptMap chỉ phù hợp cho quan hệ giữa các code system/value set, không phải phép biến đổi document end-to-end.

Có cần dùng SubscriptionTopic không?

Không bắt buộc với R4. Subscription truyền thống của FHIR R4 (criteria + rest-hook) đủ cho hầu hết trường hợp. Nếu đội kỹ thuật muốn dùng topic-based subscription, phải khai báo phụ thuộc R5 Subscription Backport IG trong sushi-config và validate cẩn thận — đừng phát minh schema riêng.

11. Tham chiếu pháp lý và kỹ thuật

Văn bản pháp lý Việt Nam

  • Nghị quyết 202/2025/QH15 ngày 12/06/2025 — Sắp xếp đơn vị hành chính cấp tỉnh, hoạt động chính thức 01/07/2025.
  • Luật 72/2025/QH15 ngày 16/06/2025 — Tổ chức chính quyền địa phương, mô hình hai cấp tỉnh + xã.
  • Thông tư 13/2025/TT-BYT ngày 06/06/2025 — Bệnh án điện tử, hiệu lực 21/07/2025, hoàn thành EMR cho cơ sở KCB chậm nhất 31/12/2026.
  • Văn bản hợp nhất 06/2026/VBHN-BYT — Chức năng, nhiệm vụ Trạm Y tế xã, phường, đặc khu.
  • Quyết định 19/2025/QĐ-TTg ngày 25/06/2025 — Mã đơn vị hành chính 34 tỉnh sau sắp xếp.
  • Nghị định 188/2025/NĐ-CP — Hướng dẫn Luật BHYT trong mô hình mới.
  • Nghị định 137/2024/NĐ-CP — Giao dịch điện tử và chữ ký số cho EMR.

Chuẩn quốc tế và đặc tả kỹ thuật